AI・セキュリティ支援の修正を何回まで受けるか｜先に決めておく

AI・セキュリティ支援の仕事で、納品したあとの修正対応がいつまでも終わらない。この悩みは、技術力の問題ではなく取り決めの問題であることがほとんどだ。結論から書くと、修正は回数ではなく「ラウンド」で数え、受注前に上限と期限をセットで文書化しておけば、ほぼ止まる。この記事では、AI・セキュリティ支援という仕事の性質にあわせて、修正の種類の分け方、上限の決め方、見積書と契約書に入れる具体的な文言、そして上限を超えたときの伝え方までを順番に整理する。

AI・セキュリティ支援で修正対応が長期化しやすい構造

修正対応の話に入る前に、なぜこの領域でだけ修正が長引くのかを押さえておきたい。原因が分かれば、どこに線を引くべきかが自動的に決まる。

成果物が「動くもの」ではなく「判断の文書」だから

Webサイト制作なら、成果物は画面として目に見える。動くか動かないかで検収の判断がつく。ところがAI・セキュリティ支援の成果物は、社内ガイドライン、リスク評価シート、診断報告書、運用ルール、チェックリスト、教育資料といった「判断を書いた文書」であることが多い。文書は、読む人が変わると評価も変わる。情報システム部門が納得した資料に、法務部門が別の指摘を入れ、そのあとに役員が三つ目の観点を出してくる。成果物そのものは何も間違っていないのに、レビューする人の数だけ修正の波が来る。

ここが決定的な違いだ。画面の修正は「直せば終わる」が、判断の文書の修正は「関係者が納得するまで終わらない」。関係者の人数を確認しないまま着手すると、修正の総量が読めない。

発注側も何が正解か分かっていないから

もうひとつの構造的な理由が、発注側が答えを持っていない点だ。生成AIの業務利用ルールを整備したい、社内の情報漏えいリスクを洗い出したいという依頼は、そもそも「どこまでやれば十分か」の基準が社内に存在しない状態で始まる。だから初稿を見て初めて、発注側は自社が何を心配していたのかに気づく。初稿は「答え」ではなく「叩き台」として機能する。

これは発注側が悪いのではなく、この分野の依頼が持つ性質だ。だからこそ、初稿に対する大きめの修正は最初から想定に入れ、そのぶんを見積もりの中に織り込んでおく。想定していないから「タダ働きが増えた」と感じる。想定して値段に入れておけば、同じ作業でも消耗しない。

外部環境が動くと成果物が古くなるから

AI・セキュリティ支援は、外部の状況が動いた瞬間に成果物の前提が変わる。新しい攻撃手法が出れば診断の観点が増え、生成AIサービスの規約や機能が変われば社内ルールの記述が合わなくなる。運用の現場では、この「外部要因による更新」が修正依頼の顔をしてやってくる。

AIを利用したシステムを、24時間365日体制で常時監視。攻撃や異常を即座に検知・対処します。独自開発の検知APIにより、新たな攻撃手法にも迅速に対応可能。特許出願中の技術を用いて、高精度な防御を実現します。 出典: nri-secure.co.jp

大手が「常時監視」を商品として売っているのは、この領域が一度作って終わりにならないからだ。個人で受ける側も同じ構造の中にいる。違うのは、個人には常時監視を無償で抱える体力がない点だけだ。だから、外部要因による更新は修正ではなく別契約に切り出す。この線引きを最初にやっておくかどうかで、半年後の負荷がまったく変わる。

修正を三つに分けて考える

「修正は何回まで」という問いに答える前に、そもそも何を修正と呼ぶのかを決める必要がある。ここを曖昧にしたまま回数だけ決めても、意味のある防波堤にならない。実務では次の三分類が使いやすい。

一つ目、こちらの誤りの訂正

誤字脱字、参照している条文番号の間違い、図表と本文の不一致、設定手順の抜け。これはこちらの品質不良なので、回数に数えず無償で直す。上限にも含めない。ここを「修正1回目」と数えると発注者との信頼関係が壊れるし、そもそも直す義務がある。

見積書には「誤記および仕様との不一致の訂正は修正回数に含まない」と書いておく。この一文があるだけで、発注者は安心して指摘を出せる。指摘が早く出るほど納品全体が早く終わるので、こちらの利益にもなる。

二つ目、合意した範囲の中での調整

こちらは正しく作っているが、表現や粒度、優先順位の付け方について発注側の好みが入る修正だ。リスクの重大度の書き分けをもう少し細かくしてほしい、経営層向けに要約ページを一枚足してほしい、章の順番を入れ替えてほしい。この種類が、いわゆる「修正」の本体になる。

ここに回数の上限を設定する。目安は2回から3回だ。初稿に対する一回目、修正稿に対する二回目、最終確認としての三回目。この三段で収束しない案件は、範囲の定義そのものが失敗している。回数を増やして粘るより、範囲を切り直したほうが早い。

三つ目、前提が変わったことによる作り直し

対象システムが増えた、社内規程が改定された、レビュアーの部署が追加された、生成AIの利用範囲が拡大した。これは修正ではなく新しい依頼だ。名前が「修正」でやってくるだけで、実態は再作業になる。

ここを修正として飲み込むと、いくら回数を決めても意味がなくなる。見積書に「前提条件の変更に伴う再作成は別途見積もり」と明記し、前提条件そのものを見積書の中に列挙しておく。列挙していない前提は「変わった」と主張できないからだ。前提条件の書き方は、後述の見積書の項目で具体的に示す。

回数ではなく「ラウンド」で数える

修正上限を決めるときにいちばん多い失敗が、「修正3回まで」とだけ書いて、その3回の数え方を決めていないことだ。

一往復を1ラウンドとする

修正依頼が来るたびに1回と数えると、発注者が思いついた順に一項目ずつ送ってきた場合、三日で上限に達する。逆にこちらが不利になることもある。発注者が二十項目まとめて送ってきたものを1回と数えるなら、こちらの作業量は青天井だ。

そこで「ラウンド」という単位を使う。こちらが成果物を提出してから、発注者が指摘をまとめて返し、こちらが反映して再提出するまでを1ラウンドと数える。指摘は原則としてまとめて一度に受け取る。この定義を先に共有しておけば、発注者側も社内の意見を集約してから送ってくれるようになる。関係者が多い案件ほど、この定義が効く。

指摘の提出期限を必ず添える

回数の上限と同じくらい重要なのが、期限だ。「修正3ラウンドまで」とだけ書くと、三ヶ月後に一ラウンド目の指摘が来る可能性が残る。そのころには当時の判断の背景を忘れているし、他の案件も動いている。

提出物ごとに「受領後5営業日以内にご指摘をまとめてご返送ください。期限内にご連絡がない場合は検収完了とみなします」と書く。この「みなし検収」の一文は、フリーランス側の防御としてかなり強い。発注者にとっても、社内レビューの締切ができることで動きやすくなる。

反映にかかる期間もこちらから提示する

期限を発注者にだけ課すのは片手落ちだ。こちらも「ご指摘の受領後3営業日で修正稿をご提出します」と書く。双方に期限があると、案件全体の終わりが見える。終わりが見える案件は、発注者も安心して次を依頼してくる。

現場で見ていると、修正対応でこじれる案件の多くは、こちらが返信を遅らせたことをきっかけに相手の要求が膨らんでいる。待たされた側は「せっかく待ったのだから全部言っておこう」という心理になる。反映が早いほど指摘は小さくなる。これは経験則ではなく、待ち時間と指摘件数の関係としてかなり再現性がある。

見積書に書く具体的な文言

決めたことは、必ず見積書の中に文字として置く。口頭合意は、担当者が異動した瞬間に消える。

見積書の備考欄に入れる四行

見積金額の下に、次の四行を置く。

一行目、修正の範囲。「本見積もりに含まれる修正は、納品物の内容に関するご指摘の反映を最大3ラウンドまでとします」。

二行目、ラウンドの定義。「1ラウンドとは、成果物提出からご指摘の一括受領、修正版の再提出までを指します」。

三行目、対象外。「対象範囲の追加、前提条件の変更、第三者からの新規要望による再作成は別途お見積もりとなります」。

四行目、期限。「ご指摘は成果物受領後5営業日以内にお願いいたします。期限内にご連絡がない場合は検収完了とみなします」。

この四行が、修正対応のトラブルの大半を止める。逆に言えば、この四行を書かずに受注した案件は、修正が伸びたときに交渉の根拠が何もない。

前提条件を箇条書きで列挙する

備考欄とは別に、「本見積もりの前提条件」という項目を作って列挙する。AI・セキュリティ支援なら、対象となるシステムやサービスの数、ヒアリング対象の部署数と人数、レビューに関わる関係者の範囲、参照する社内規程の版、想定する成果物のページ数や章立て、対象とする生成AIサービスの種類あたりが該当する。

なぜ列挙するかというと、「前提が変わったので別途見積もり」と言うためには、変わる前の前提が文書に残っていなければならないからだ。列挙されていない前提は、あとから「そんな話は聞いていない」と言われて終わる。逆に列挙してあれば、「当初は対象を2システムと伺っておりましたので、追加分をお見積もりします」という会話が事務的に成立する。感情の話にならず、事務の話にできる。これが列挙の最大の効果だ。

分割納品にして検収を刻む

大きめの案件では、成果物を一括で出さず、章単位や工程単位で分けて出す。構成案の段階で一度検収、初稿で一度検収、最終稿で一度検収という形だ。

分割すると修正ラウンドも分割される。全体で3ラウンドではなく、各段階で1ラウンドずつになる。発注者から見ると細かく確認できるので安心感があり、こちらから見ると「構成案の検収が終わったあとで構成をひっくり返す指摘」を別料金として扱える。手間が増えるように見えるが、実際には手戻りが減るぶん総工数は下がる。

契約書に入れておく条項

見積書は提案の書類なので、金額の合意で役目を終える。継続的に取引するなら、業務委託契約書のほうに条項として置く。

検収の条項

「甲は、成果物の受領後5営業日以内に検査を行い、合格または不合格を乙に通知する。期間内に通知がない場合、当該成果物は検収に合格したものとみなす」。この「みなし合格」があると、検収が宙に浮いたまま報酬が支払われない状態を避けられる。

なお、報酬の支払いについては、発注者側に法律上の義務が課されている。取引の条件を書面で明示すること、成果物を受領した日から一定期間内に報酬を支払うことなどが定められている。詳細な要件は取引の形態によって変わるため、条件を確認したい場合は公正取引委員会や中小企業庁の案内を参照するのが確実だ。制度の一次情報は公正取引委員会と中小企業庁で公開されている。

修正の条項

「成果物に対する修正は、検収前のものに限り、3ラウンドを上限とする。上限を超える修正、および本契約に定める業務範囲を超える追加作業については、別途協議のうえ有償とする」。

「別途協議のうえ有償とする」という言い方が実務的だ。金額をここで固定すると、内容が読めないうちから縛られる。有償であることだけを確定させ、金額は都度決める。

秘密保持と成果物の扱い

セキュリティ支援では、診断結果や社内の弱点そのものが機密になる。NDAは締結して当然として、そのうえで「成果物の第三者提供」「実績としての公開可否」を条項で決めておく。実績に使えるかどうかは営業に直結するので、締結時に確認する。ここを詰めておかないと、後述する実績の見せ方で困ることになる。

修正が膨らむ案件を初回で見抜く

上限を決めても、そもそも膨らむ案件は膨らむ。着手前に見抜けるサインがいくつかある。

決裁者が打ち合わせに出てこない

窓口担当者だけで話が進み、決裁者が一度も顔を出さない案件は要注意だ。初稿を出した段階で決裁者が登場し、方向性から覆る。初回の打ち合わせで「最終的に承認されるのはどなたですか」「その方は途中のレビューにも入られますか」と確認する。これは失礼な質問ではなく、進行を設計するための実務的な確認として普通に受け入れられる。

現行のルールや規程が存在しない

生成AIの利用ルールを作りたいという依頼で、社内に情報セキュリティ規程そのものがない場合、作業の下地から作ることになる。既存文書の有無は初回で必ず確認し、無ければその整備を別工程として見積もる。

「とりあえず叩き台を」と言われる

叩き台という言葉が出たら、初稿が大きく変わることを発注者自身が予告している。この場合は、初稿の前に構成案の合意を挟む工程を提案する。構成案なら作り直しが軽い。文章にしてから構成を変えるのがいちばん重い。

社内に技術が分かる人がいない

判断を全部こちらに委ねてくる案件は、一見やりやすいが、レビューの基準が存在しないので指摘が感想ベースになる。「なんとなく物足りない」という指摘は、何回直しても収束しない。この場合は、判断基準そのものを最初の成果物として作り、それを合意してから本編に入る。

参考になる観点として、AI領域のリスク対応では人の検証工程を明示的に置くことが推奨されている。

権利侵害を防ぐためには、たとえば文章コンテンツを外部に発信する場合、AIが生成した原稿を人間が詳細に検証し、必要に応じて大幅な修正を加えることが重要です。また、より安全なアプローチとして、AIには文章の骨組みや構成のみを作成させ、実際の執筆作業は人間が担当する手法も有効です。 出典: lac.co.jp

検証工程を誰がどの基準でやるのかを決めておく話は、そのまま修正ラウンドの設計と同じ問題になる。基準がないところに検証は成立しない。

上限を超えたときの伝え方

決めた上限に達したとき、どう伝えるかで関係が決まる。ここを感情的にやると、正しいことを言っていても次が来なくなる。

断らずに、条件を示す

「もうできません」は最悪の返し方だ。正しいのは「できます、条件はこうです」と返すこと。

具体的には、現状を事実として置き、選択肢を二つ出す。「本日いただいたご指摘で、お見積もり時にご案内した3ラウンド目の修正が完了となります。追加でご希望の変更は、内容を拝見したところ2点は誤記の訂正に該当しますので無償で対応します。残りの5点は仕様の追加にあたるため、追加分としてお見積もりを本日中にお送りします。あるいは、優先度の高い2点のみを今回の範囲内で対応し、残りを次回にまとめる形でも進められます」。

この形にすると、発注者は「拒否された」ではなく「選べる」と受け取る。しかも、こちらが誤記を無償で拾っていることが明示されるので、金を取ることだけが目的ではないと伝わる。

記録を根拠にする

伝えるときに効くのが、指摘の一覧表だ。指摘ごとに、受領日、内容、分類（誤記の訂正か、範囲内の調整か、範囲外の追加か）、対応状況を並べた表を作っておく。これをそのまま添付する。

議論が「言った言わない」にならず、「この行はどちらに分類されますか」という具体的な話になる。表があるだけで、交渉の温度が下がる。表計算ソフトで十分なので、案件開始と同時に作る。

三ラウンド目の提出時に予告する

上限に達してから伝えるのではなく、達する直前に予告する。三ラウンド目の修正稿を出すときに「今回で当初お見積もりの範囲は完了となります。追加のご要望がある場合はお気軽にお知らせください、別途お見積もりいたします」と一行添える。

予告があると、発注者は最後のラウンドに指摘を集中させる。予告がないと、上限に達したあとに残りが出てきて、そこから交渉が始まる。順番が違うだけで、まったく違う結果になる。

この分野に固有の落とし穴

一般的な受託仕事の修正管理に加えて、AI・セキュリティ支援ではもう二つ気をつける点がある。

再診断は修正ではない

脆弱性診断やリスクアセスメントを納品したあと、指摘事項を発注者が直し、「直したので再度見てほしい」と依頼が来る。これは修正ではなく再診断であり、独立した作業だ。初回の見積もりに再診断を含めるなら回数と範囲を明記し、含めないなら「修正対応に再診断は含まない」と書く。

ここを曖昧にすると、対応が終わらない。発注者が直すたびに見るのは、実質的に運用支援であって、単発の診断ではない。運用支援として月額で受けるほうが、双方にとって健全な形になる。

ツールの自動修正と人の判断を混同しない

コードやシステムを対象にする場合、自動修正機能を備えたツールが使われる場面が増えている。

業界をリードする DevSecOps プラットフォームの Snyk Code では、LLM を活用した脆弱性の自動修正機能である DeepCode AI Fix を提供しています。このツールは、開発者の作業フローを妨げることなく、安全でないコードを検出して自動修正するため、生成 AI ツールの安全な利用が可能になります。 出典: snyk.io

自動修正が普及すると、発注者は「修正は簡単にできるもの」という感覚を持ちやすい。だが機械が直せるのは既知パターンの一部であり、支援業務の価値は「どのリスクを優先して、どこまでやるかを決める」判断のほうにある。この違いを提案の段階で説明しておくと、修正依頼の中身が「作業のやり直し」から「判断の相談」に変わる。判断の相談なら、単発の修正ではなく継続の契約として話が進む。

修正管理を毎回同じ手順に落とす

線引きを決めても、案件ごとに違うやり方をしていると運用が続かない。道具立てを固定して、考えずに回せる形にする。

案件開始時に作る三つのファイル

一つ目が前提条件シートだ。見積書に書いた前提条件をそのまま転記し、変更があった日付と内容を追記していく。これが「前提が変わった」と主張するときの唯一の根拠になる。二つ目が指摘管理表で、受領日、指摘内容、分類、対応状況、反映した提出版を列に持つ。三つ目が提出履歴で、いつ何版を出し、いつ指摘が返り、いつ再提出したかを並べる。

三つとも表計算ソフト一枚で足りる。凝ったツールは不要で、むしろ発注者と共有しやすい形式のほうがいい。共有できると、分類の食い違いをその場で潰せる。

提出時のメール文面を定型化する

成果物を送るメールに、毎回同じ四要素を入れる。今回が何ラウンド目か、残りが何ラウンドか、指摘の返送期限はいつか、指摘は一括でお願いしたい旨。この四つを毎回書くだけで、上限に達したときの説明がほぼ不要になる。すでに全部伝えてあるからだ。

定型文にしておくと、忙しいときに省略してしまう事故も防げる。修正対応がこじれる案件を振り返ると、たいてい忙しい時期にこの一文を書き忘れている。

分類の判断に迷ったときの基準

指摘が「範囲内の調整」か「範囲外の追加」か迷う場面は必ず来る。判断の基準を一つ持っておくと速い。使いやすいのは「この指摘を最初の打ち合わせで聞いていたら、見積もりの工数が変わったか」という問いだ。変わるなら範囲外、変わらないなら範囲内になる。

この基準は発注者にも説明しやすい。工数が増えるから追加費用が発生する、という因果が直線でつながっているからだ。感覚で線を引くと説明できないが、この問いなら説明できる。説明できる線だけが、実際に守れる線になる。

迷ったら一件だけサービスする

分類がきわどい指摘が数件あるとき、全部を範囲外として押し切るより、一件だけ無償で拾って残りを有償にするほうが結果的に通りやすい。発注者から見ると、こちらが機械的に線を引いているのではなく、内容を見て判断していると伝わる。

ただし、サービスした事実は必ず指摘管理表に「無償対応」と記録して相手にも見える形にする。黙ってやると、次から同じ扱いが当然になる。記録に残すのは請求のためではなく、線が動いていないことを示すためだ。

独自データから見える受注の広がり

修正対応の設計は、単発の案件を守る話にとどまらない。この分野の仕事の取り方そのものと関係している。

AI関連の在宅・業務委託の募集を分類すると、大きく三つの入口がある。ひとつは業務の棚卸しからルール整備までを担うAIコンサル・業務活用支援のお仕事で、社内の使い方を決める役割が中心になる。ふたつめは実装寄りのAIチャットボット・アプリ開発のお仕事、みっつめは制作寄りの画像生成AI（Stable Diffusion等）のお仕事だ。修正対応の設計がいちばん重くなるのは一つ目で、成果物が判断の文書だからだ。実装寄りの仕事は動作で検収できるぶん、線引きが楽になる。

技術の土台を職種として整理したいならソフトウェア作成者の年収・単価相場で仕事の中身と求められる経験の幅を確認できる。資格で入口を作る場合は、業務利用の基礎知識を体系立てて示せる生成AIパスポートが、非技術職の発注者に対する説明材料として機能しやすい。

在宅ワークとフリーランスの市場を20年見てきた運営者の立場から言えば、長く続いている人ほど、修正対応の線引きを冷たくやっていない。線は引いているが、引いた線を最初に開示している。開示しているから、線に達したときに揉めない。逆に、優しさのつもりで線を引かずに受け続けた人が、半年後に疲れ切って単価を上げられなくなる場面を何度も見てきた。線引きは相手を突き放す道具ではなく、次の依頼を受けられる状態を保つための道具だ。

もうひとつ、運営者として見てきた限りでは、中間マージンが乗らない直接取引の効き方は金額の大小より「配分の自由度」に出る。仲介手数料が抜かれない手数料0%の取引では、同じ予算で発注者はより多くの工程を頼めるし、受け手は手取りが厚くなるぶん、修正ラウンドを一回多めに見込むといった余裕を最初から設計に入れられる。修正対応が消耗戦になるのは、たいてい取り分が薄くて余裕がないときだ。余裕があると、線引きが交渉ではなく設計の話になる。この差は、案件が三つ、四つと重なったときに効いてくる。

AI領域でどう案件を取っていくかという全体像はフリーランス AI案件の獲得術！生成AI時代に年収を倍増させる戦略に整理されている。修正対応の取り決めは、案件を取ったあとの守りの話に見えて、実は次の案件を取るための攻めの準備でもある。終わりが見える進め方をする相手には、発注者は次も頼みたくなる。

よくある質問

Q. 修正回数の上限は何回に設定するのが妥当ですか？

成果物の内容に関する調整であれば、2ラウンドから3ラウンドが実務的な目安になる。初稿への指摘、修正稿への指摘、最終確認という三段で収束しない案件は、回数を増やすより範囲の定義を見直したほうが早い。誤記や仕様との不一致の訂正は回数に含めず無償で直すと明記しておくと、発注者が指摘を出しやすくなり全体が早く終わる。

Q. 「修正1回」の数え方はどう決めればよいですか？

指摘の件数ではなく往復で数える。成果物を提出し、発注者が指摘をまとめて返し、こちらが反映して再提出するまでを1ラウンドとする定義を、見積書に書いておく。この定義があると、思いついた順に一項目ずつ送られて上限に達する事態も、二十項目まとめて送られて作業量が青天井になる事態も両方避けられる。

Q. 見積もりの範囲を超える依頼が来たとき、どう断ればよいですか？

断らずに条件を示す形にする。今回の指摘で当初の範囲が完了することを事実として伝え、そのうえで追加分を有償で見積もる案と、優先度の高い項目だけを範囲内で対応して残りを次回にまとめる案の二つを出す。選択肢があると拒否と受け取られない。指摘の受領日と分類を並べた一覧表を添えると、議論が事務的に進む。

Q. 指摘がいつまでも来ない案件はどう扱えばよいですか？

成果物ごとに提出期限を設ける。受領後5営業日以内に指摘をまとめて返送してもらい、期限内に連絡がない場合は検収完了とみなす旨を、見積書と契約書の両方に書いておく。この「みなし検収」の一文があると、検収が宙に浮いたまま案件が終わらない状態を防げる。発注者側にも社内レビューの締切ができるため、進行が動きやすくなる。

Q. 納品後に発注者が直した箇所を再確認する依頼は修正に含まれますか？

含まない。脆弱性診断やリスク評価のあとに「直したので再度見てほしい」と依頼されるのは再診断であり、独立した作業にあたる。初回の見積もりに含めるなら回数と範囲を明記し、含めないなら修正対応に再診断は含まない旨を書く。継続的に見る必要がある場合は、単発ではなく月額の運用支援として契約したほうが双方にとって健全になる。