AIを使う案件で、あとから揉めないための3つの確認

打ち合わせの最後に、空気が少し固まった

「ちなみに、今回の実装ではAIも使って進めます」

契約前の打ち合わせで、何気なくそう伝えたとします。相手は最初、「便利そうですね」とうなずきます。空気も悪くありません。むしろ、開発が早く進むなら歓迎、という雰囲気すらあります。

ところが、帰り際に担当者が少しだけ真顔になります。

「それって、うちの仕様書やログもAIに入れるんですか？」

この一言で、急に話が現実味を帯びます。こちらとしては、AIで実装のたたき台を作る、テスト観点を出す、調査メモを整理するくらいのつもりだったかもしれません。でも相手から見ると、仕様書、既存コード、本番ログ、個人情報まで外部に出るのではないか、という話に見えます。

さらに、別の人がこう続けるかもしれません。

「AIが書いたコードに不具合があったら、誰が責任を持つんですか？」

ここで焦って、「そこは大丈夫です」とだけ返すと危ないです。大丈夫な理由が言葉になっていないからです。あとから揉めるのは、AIを使ったことそのものより、相手の不安に答えないまま始めてしまった時 です。

Stack Overflow の 2025 Developer Survey でも、開発でAIツールを使う、または使う予定がある人は多い一方で、AI出力の正確性には不信も残っています。つまり、AIを使うこと自体は珍しくなくなっている。でも、「出てきたものをそのまま信じてよい」とは見られていないわけです。

この記事では、AIを使う案件であとから揉めないために、契約前に確認したい3つのことを、ストーリーに近い形で整理します。

揉める火種は、AIの中ではなく空白に残る

AI利用の話が分かりにくくなるのは、いろいろな不安が一つに混ざるからです。情報管理の不安、品質の不安、納品後の責任の不安。これを全部まとめて「AI利用の責任」と呼ぶと、急に大きな話になります。

たとえば、小さな管理画面の改修を受けたとします。エラー原因の調査、ボタンの表示条件の修正、テストケースの追加。作業としてはよくある内容です。AIを使えば、既存コードの読み取りメモや、テスト観点の下書きはかなり早く出せます。

でも、顧客の頭の中では別の映像が流れています。社内のログがそのまま貼られるのではないか。AIが出したコードを人が見ずに納品されるのではないか。あとで不具合が出た時に「AIがそう出したので」と言われるのではないか。

こちらに悪気がなくても、相手は空白を不安で埋めます。だから、契約前に確認したいのは難しい条文より先に、次の3つです。

• AIに何を入れないか
• AIが出したものを誰が確認するか
• どこまで直す約束にするか

この3つが言えるだけで、AI利用の話はだいぶ落ち着きます。相手も質問しやすくなりますし、こちらも作業中に迷いにくくなります。

1つ目は、「AIに入れないもの」を先に言う

一番先に決めたいのは、入力する情報です。AIに何を入れてよいかが曖昧だと、作業効率化のつもりでも、相手から見ると情報管理の問題に見えます。

たとえば、エラー原因を調べるためにログをAIへ貼る場面を想像してください。本人にとっては普通の調査です。「このエラー、どう見ればいい？」と聞きたいだけかもしれません。

でも、そのログに顧客名、メールアドレス、社内URL、未公開の業務ルールが入っていたら、かなり話が変わります。相手からすれば、「効率化のため」では済みにくい。便利な使い方ではなく、情報管理の不安になります。

ここで「機密情報は入れません」とだけ言うと、まだ少し弱いです。現場で迷うのは、機密かどうかがはっきりしないものだからです。仕様書はどうか。既存コードはどうか。ログはどうか。匿名化した要約ならよいのか。

まずは、こう分けるだけで十分です。

• 公開情報や一般的な技術情報は使ってよい
• 顧客固有の仕様、未公開コード、本番ログ、個人情報は入れない
• どうしても必要な場合は、匿名化してから相手に確認する

打ち合わせでは、こう言うと伝わりやすいです。

調査整理や一般的な実装案の比較にはAIを使うことがあります。ただし、顧客固有の仕様、未公開コード、本番ログ、個人情報は、許可なく外部AIへ入力しません。

これだけで、相手の顔つきは変わります。AIを使うかどうかではなく、何を入れないかまで考えている人 だと伝わるからです。

2つ目は、「誰が最後に見るのか」を決める

次に決めたいのは、確認する人です。AIが作ったコードをそのまま渡すのか。自分がレビューしてから渡すのか。顧客側の確認まで含めて完了なのか。ここが曖昧だと、後で不具合が出た時に説明が苦しくなります。

実務では、AI出力は「完成品」ではなく「材料」として扱う方が分かりやすいです。コードなら、既存仕様、権限、エラー処理、テスト、ログを人が見る。ドキュメントなら、事実関係や表現を人が見る。

ここにも、小さな落とし穴があります。AIにテスト観点を出してもらうと、それっぽい一覧はすぐに出ます。正常系、異常系、境界値。見た目はかなり整っています。でも、実際の業務で怖いのは、支払い済みなのに再請求される、管理者だけが見られる情報が一般ユーザーに出る、通知が二重に飛ぶ、のような固有の事故です。

AIは一般論を出すのが得意です。一方で、現場固有の怖さは、人が見ないと落ちやすい。だから、確認責任を「AIが出したかどうか」ではなく、「誰が採用判断をしたか」に戻します。

言い方としては、こうです。

AIは初稿づくりや観点出しに使います。ただし、採用するコードは人がレビューしてから提出します。

これだけでも、相手の受け取り方は変わります。AIを使うことより、最後に人が見ているかどうか が知りたいからです。

OWASP Top 10 for LLM Applications 2025 でも、機密情報の開示、不十分な出力検証、過剰な自動化などがリスクとして整理されています。難しい言葉にしなくても、現場では「出力をそのまま納品しない」と言い換えれば十分使えます。

3つ目は、「どこまで直すか」を早めに分ける

最後に、修正範囲です。AIで初稿が早く出ると、相手もこちらも「ほぼ完成している」と感じやすくなります。でも、初稿が早いことと、受け入れ可能な状態まで整っていることは別です。

ここを決めないまま進めると、あとで会話がねじれます。

「AIで作ったなら、この修正もすぐできますよね？」

気持ちは分かります。AIで初稿が速く出るなら、追加修正もすぐ終わるように見えます。でも実際には、仕様確認、影響範囲の確認、テスト、レビュー、説明、再修正には時間がかかります。AIが一瞬で案を出しても、それを受け入れ可能な状態にするのは別の仕事です。

だから、契約前に次を分けておきます。

• 何をもって完了とするか
• 検収後の修正はどの範囲まで含むか
• 追加の仕様変更は別扱いにするか
• AIで作ったかどうかに関係なく、人が確認する観点は何か

IPA の「情報システム・モデル取引・契約書（第二版）」でも、仕様、プロジェクト管理方法、検収方法などを契約時に対話することの大切さが示されています。AI利用が入るなら、この会話はなおさら先に置いた方がいいです。

ここで大事なのは、相手を警戒することではありません。任せてもらう範囲をはっきりさせることです。AIで速く出せる部分と、人が責任を持って整える部分を分ける。 それだけで、あとからの期待値のズレはかなり減ります。

見積りには、一枚のメモで残せばいい

AI活用の契約というと、難しい条文を作らないといけない気がします。でも、最初の相談ではそこまで固くしなくて大丈夫です。法律判断が必要なところは専門家に確認するとして、現場ではまず一枚のメモに落とすくらいで進めやすくなります。

メモに残すのは、次の5つです。

• AIを使ってよい作業
• AIに入力しない情報
• 人が確認する観点
• 受け入れ条件
• 再利用できるもの、できないもの

たとえば、調査整理、初稿作成、テスト観点の洗い出しにはAIを使う。ただし、顧客固有情報、本番データ、認証情報は許可なく入れない。AI出力はそのまま納品せず、担当者が確認したものを成果物として扱う。

このくらいまで言えると、AI利用は「なんとなく不安なもの」ではなく、管理できる作業になります。

見積りや提案書に入れるなら、こう書けます。

• AI補助は、調査整理、初稿作成、テスト観点の洗い出しに使うことがあります
• 顧客固有情報、本番データ、認証情報は、許可なく外部AIへ入力しません
• AI出力はそのまま納品せず、担当者が確認したものを成果物として扱います
• 検収後の修正は、合意した受け入れ条件との差分を対象にします

これなら、契約書の条文より手前の作業ルールとして置けます。相手も質問しやすいですし、自分も作業中に迷いにくくなります。

AIの話は、防御ではなく安心を作る話

AIの責任範囲というと、防御の話に聞こえます。問題が起きた時に怒られないようにする、契約で揉めないようにする。もちろん、それも大事です。

でも、本当は価値の話でもあります。AIで初稿を出すだけなら、単なる時短に見えます。けれど、入力情報を守り、出力をレビューし、受け入れ条件を整え、再利用範囲まで分けるなら、それは品質保証や進行設計の仕事です。

最初の打ち合わせに戻ると、相手が聞きたいのは「AIを使うんですか？」だけではありません。本当は、その奥にある不安を聞いています。

• 自社の情報は守られるのか
• できあがったものを人が見てくれるのか
• 不具合や修正の話になった時、逃げずに対応してくれるのか

ここに答えられる人は、AIを隠さなくていいです。むしろ、AIを使う前提で、どう安全に使うかを話せる人になります。

NIST の AI RMF Generative AI Profile でも、生成AIでは機密情報、出力の検証、知的財産やプライバシーなどのリスクが扱われています。個人や小さな受託案件でも、考える順番は同じです。難しい言葉にしなくても、「入れない」「人が見る」「勝手に広げない」と言い換えれば、かなり使えます。

もし受託側がAI出力のレビュー、テスト、品質説明、修正対応まで広く持つなら、その分は条件にも戻した方がいいです。レビュー範囲、修正回数、検収期限、追加調査の扱い。責任だけ広げて、条件が据え置きだと苦しくなります。

ここで大事なのは、相手を警戒することではありません。任せてもらう範囲をはっきりさせることです。AIを使うほど、人がどこで責任を持つかを見えるようにする。 それが、安心して進めるための土台になります。

最後に

AIを使う案件であとから揉める時、問題はたいてい「AIを使ったこと」だけではありません。何を入れないかを話していなかった。誰が確認するかを決めていなかった。どこまで直すかを曖昧にしていた。そういう小さな空白が、あとで大きくなります。

全部を一度に完璧に決めなくて大丈夫です。次の案件で、まず3つだけ確認してみてください。AIに入れないもの、最後に確認する人、修正範囲。この3つです。

そのうえで、見積りや提案書には5つだけメモする。AIを使う作業、入力しない情報、人の確認、受け入れ条件、再利用できるもの。これだけで、AI利用の話はかなり落ち着きます。

AIを隠す必要はありません。でも、便利さだけで始めないこと。先に線を引ける人ほど、AI時代の契約では安心して任せられる人になります✨

参考にした情報

• Stack Overflow「2025 Developer Survey: Artificial intelligence」（2025年版、2026年7月8日確認）
• 総務省・経済産業省「AI事業者ガイドライン（第1.2版）」（最終更新日 2026年4月1日、2026年7月8日確認）
• IPA「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公開、2025年6月17日最終更新、2026年7月8日確認）
• NIST「AI Risk Management Framework」（2023年1月26日公開、2026年7月8日確認）
• NIST「AI RMF Generative AI Profile」（2024年7月26日公開、2026年7月8日確認）
• OWASP「Top 10 for LLM Applications 2025」（2025年版、2026年7月8日確認）