外注しているエンジニアの納品コードを眺めていて、「これ、生成AIで書いたのでは？」と気づいた瞬間に、ふと不安がよぎる。そんな経験はないでしょうか。あるいは委託先から「効率化のためにGitHub CopilotやChatGPTを使っています」と申告を受け、どう返事をすればいいか迷ったまま放置している、というケースもあるかもしれません。
生成AIツールはすでにエンジニアの日常の一部です。外注先だけ使うなと言うのは現実的ではなく、かといって何も取り決めずに放置すれば、機密情報の漏えいや著作権の問題が自社に跳ね返ってくるかもしれません。「禁止すべきか、許可すべきか」「契約でどこまで縛れるのか」を判断する材料がないまま、宙ぶらりんの状態が続いてしまいます。
やっかいなのは、漠然とした不安のままでは方針を決められないことです。「機密が漏れたら」「著作権でもめたら」「品質が落ちたら」という心配はどれももっともらしく聞こえますが、自社の発注内容にとって本当に危ないのがどれなのかが見えていなければ、対策の優先順位もつけられません。さらに、利用ルールを細かく指示すると、今度は偽装請負という別のリスクが顔を出します。
本記事では、外注エンジニアの生成AI利用に対して発注者が取るべき対応方針を、4つのリスクの整理から始めて、「禁止・条件付き許可・許可」の判断軸、偽装請負を避けながら契約・利用ルールで取り決める方法、そして今日から着手できる対応ステップとチェックリストまで、順を追って解説します。読み終えたとき、自社の状況に当てはめて落としどころを判断できる状態を目指します。
外注エンジニアの生成AI利用が発注者にとって問題になる場面
最初に、発注者が「これは大丈夫なのだろうか」と立ち止まる典型的な場面を整理します。問題の輪郭をはっきりさせることが、方針づくりの出発点になります。
発注者が判断を迫られる典型シーン
外注エンジニアの生成AI利用が気になり始めるきっかけは、たいてい次のようなものです。
- 納品されたコードやコメント、調査資料の文体が、明らかに生成AI由来に見える
- 委託先から「GitHub CopilotやCursorを使って開発を効率化しています」と申告があった
- 短納期にもかかわらず大量のコードが上がってきて、本当に中身を理解して書いているのか不安になった
- 社内の上長や顧客から「外注先が生成AIを使っているなら、情報管理は大丈夫なのか」と問われた
ChatGPT・GitHub Copilot・Cursor といったツールは、いまやエンジニアの開発環境に標準的に組み込まれつつあります。コード補完や定型処理の生成、調査の下書きに使うのはごく一般的になっており、「外注先がまったく生成AIを使っていない」と考えるほうがむしろ実態に合わなくなってきました。だからこそ、申告の有無にかかわらず「使われている前提」で方針を考える必要があります。
「とりあえず禁止」も「とりあえず放置」もどちらも危ない理由
不安を感じたとき、発注者が取りがちな対応は両極端になりがちです。どちらにもデメリットがあります。
「とりあえず全面禁止」は一見安全に見えますが、実効性に乏しいのが難点です。外注先の手元の作業環境を発注者が常時監視することは現実的ではなく、禁止しても実態としては使われ続け、ルールが形骸化する恐れがあります。さらに、生成AIの活用を前提に見積もりや納期を設計している優秀な委託先を遠ざけてしまい、結果としてコストや納期の面で不利になることもあります。
逆に「とりあえず放置」は、何も決めていないがゆえに、いざ問題が起きたときに発注者が無防備になります。機密情報が外部サービスに入力されていた、納品物に第三者の著作物が混入していた、といったトラブルが起きてから「取り決めがなかった」と気づくのでは遅いのです。
つまり、発注者に求められているのは「禁止か放置か」の二択ではなく、リスクを見極めたうえで、自社の発注内容に見合った許容範囲を設計することです。次の章では、その判断材料となる4つのリスクを整理します。
発注者が押さえるべき4つのリスクと優先度
外注エンジニアの生成AI利用に伴って発注者が負いうるリスクは、大きく4つに分けられます。漠然とした不安を、この4つの論点に分解して捉え直すことが、優先順位づけの第一歩です。どのリスクが重いかは発注内容によって変わるため、最後に優先度の考え方も整理します。
リスク1: 機密情報・個人情報の漏えい
最も発注者が警戒すべきなのが、機密情報の漏えいです。外注エンジニアが、自社から預かったソースコード・仕様書・顧客データ・個人情報などを生成AIのプロンプトに入力すると、その情報が外部のサービス事業者のサーバに送信されます。サービスや契約の種類によっては、入力内容がモデルの学習に利用される可能性もあります。
ただし、このリスクは設定や契約形態で大きく軽減できます。法人向けの商用プラン（エンタープライズ版・API 経由の利用など）では、入力データを学習に使わない設定や、データを保持しない設定が選べる場合が多くあります。問題は「個人の無料アカウントで、機密情報をそのまま貼り付けてしまう」運用です。発注者としては、ここを線引きするだけでもリスクは大きく下がります。
リスク2: 著作権・ライセンスの問題
生成AIが出力したコードや文章が、第三者の著作物や、特定ライセンスのOSSコードに似てしまうリスクです。生成物が既存の著作物と「類似」しており、かつその著作物に「依拠」して作られたと判断される場合、著作権侵害が成立しうるとされています。
文化庁は2024年3月に「AIと著作権に関する考え方について」をとりまとめ、生成・利用段階での侵害は通常の著作物と同じく「類似性」と「依拠性」の双方で判断されるとの整理を示しています（文化庁「AIと著作権について」）。なお、この「考え方」自体に法的拘束力はなく、今後の議論で変わりうる点には注意が必要です。発注者の実務上は、納品物が第三者の権利を侵害していないことをどう担保するか（後述する非侵害の保証条項など）が論点になります。
リスク3: 品質・正確性（ハルシネーション）
生成AIは、もっともらしいが誤った内容（ハルシネーション）を出力することがあります。動作するように見えて実は要件を満たしていないコード、出典のない調査結果、古い情報に基づく実装などが、検証されないまま納品される恐れがあります。
外注先が生成AIの出力を十分にレビュー・検証せず、いわば「下書きをそのまま納品」している場合、品質低下の責任の所在が曖昧になりがちです。発注者としては、生成AIの利用そのものより「成果物が検証されているか」を問うほうが本質的です。
リスク4: 契約・責任の所在
生成AIを使って作られた成果物について、権利が誰に帰属するのか、瑕疵や第三者の権利侵害が見つかったときに誰が責任を負うのかが、契約で明確になっていないケースが多くあります。
「生成AIで作ったものに著作権は発生するのか」「侵害があった場合に発注者と委託先のどちらが責任を負うのか」といった点を取り決めないまま発注すると、トラブル時に拠り所がありません。これは生成AI特有というより、契約設計の不備が生成AIによって顕在化する問題と言えます。
4つのリスクの優先度をどう考えるか
4つのうちどれを重く見るかは、発注内容によって変わります。判断の目安は次のとおりです。
- 顧客の個人情報や機密性の高い業務システムを扱うなら、リスク1（機密情報の漏えい）が最優先
- 公開サービスやプロダクトのコードを納品させるなら、リスク2（著作権・ライセンス）とリスク4（責任の所在）の比重が上がる
- 調査・ドキュメント作成が中心なら、リスク3（品質・正確性）の検証体制が鍵になる
自社の発注がどれに当たるかを見極めれば、過不足のない対策に絞り込めます。
「禁止・条件付き許可・許可」をどう判断するか
リスクの輪郭が見えたら、次は「外注先に対してどういう方針を取るか」を決めます。選択肢は大きく3段階あります。それぞれが向くケースと、自社の状況に当てはめるための判断軸を示します。
3段階の方針と、それぞれが向くケース
- 禁止: 生成AIの利用を一切認めない方針。極めて機密性の高い情報を扱う案件や、規制業種で監査要件が厳しい場合に限られます。前章で触れたとおり実効性の担保が難しく、形骸化しやすいため、適用範囲は慎重に絞るのが現実的です。
- 条件付き許可: 一定の条件（機密情報を入力しない、学習させない設定の商用版を使う、利用を申告する、成果物を検証する等）を満たす範囲で利用を認める方針。多くの発注者にとって、もっとも現実的でバランスの取れた落としどころになります。
- 許可（自由利用）: 利用方法を委託先の裁量に任せる方針。機密性が低く、成果物の検収体制が整っている場合や、委託先の体制を信頼できる場合に向きます。
「全面禁止が一番安全」と考えがちですが、監視できない以上、禁止は宣言だけに終わりやすいのが実情です。多くの発注者は「条件付き許可」を軸に設計するのが妥当です。
判断軸（機密度 × 成果物の種類 × 検収体制）の当てはめ方
どの方針を選ぶかは、次の3つの軸で自社の状況を点検すると決めやすくなります。
- 扱う情報の機密度: 個人情報・顧客データ・未公開の事業情報など、外部に出てはいけない情報を委託先が触れるか。機密度が高いほど、入力制限を厳格にする（または禁止に寄せる）。
- 成果物の種類: 本番稼働するコードか、社内向けの調査・ドキュメントか。本番コードほど著作権・ライセンス・品質の担保が重くなる。
- 自社の検収体制: 納品物をレビュー・検証できる体制が自社（または信頼できる第三者）にあるか。検収できるなら許可寄り、検収が手薄なら条件を厚くする。
たとえば「顧客の個人情報を扱わない社内ツールの開発で、自社にコードレビューできる人がいる」なら、条件付き許可〜許可で十分です。逆に「顧客データに触れる本番システムで、納品物を十分に検証できない」なら、入力制限を厳しくした条件付き許可、あるいは該当部分のみ禁止が妥当です。
このように軸ごとに自社を当てはめれば、「なんとなく不安だから禁止」ではなく、根拠を持って方針を選べます。
契約・利用ルールでどこまで取り決められるか（偽装請負に注意）
方針が決まったら、それを契約や利用ルールに落とし込みます。ここで発注者が見落としやすいのが、「ルールを細かく指示しすぎると、業務委託のはずが偽装請負と評価されるリスクが生じる」という点です。本章では、盛り込める条項と、踏み越えてはいけない線引きを整理します。
契約・発注書に盛り込める条項例
外注先の生成AI利用について、契約・発注書・覚書などに盛り込める代表的な条項は次のとおりです。
- 機密情報の入力制限: 自社が提供する機密情報・個人情報・ソースコード等を、生成AIのプロンプトに入力することを禁止または制限する
- 学習させない設定の使用義務: 生成AIを利用する場合は、入力内容が学習に使われない設定（法人向け商用プラン等）を用いることを義務づける
- 生成AI利用の明示・申告: 成果物の作成に生成AIを利用した場合、その旨と利用範囲を発注者に明示・申告させる
- 成果物の権利帰属と非侵害の保証: 納品物の著作権等の権利が発注者（または委託先）に帰属することと、第三者の権利を侵害していないことを委託先に保証させる
これらは「どんな成果物・どんな条件で納品してほしいか」という成果物・仕様レベルの取り決めであり、業務委託でも問題なく定められます。
「条件の付与」と「作業手順への指揮」の違い ― 偽装請負を避ける線引き
注意すべきは、業務委託（請負・準委任）では、発注者が委託先の作業の進め方を細かく指揮命令することは認められない、という点です。実態として指揮命令を行うと、形式は業務委託でも「偽装請負」と評価され、労務上のリスクが生じます。
生成AI利用ルールに引き寄せて言えば、線引きはおおむね次のようになります。
- 問題になりにくい（成果物・条件レベルの取り決め）: 「機密情報を入力しないこと」「学習させない設定の商用版を使うこと」「成果物に第三者の権利侵害がないこと」など、納品物に求める品質・条件を定めること
- 偽装請負リスクが高まる（作業手順への指揮）: 「どのツールをどの工程で何回使うか」「作業時間中の操作手順」など、委託先の働き方・作業プロセスを細かく指示・管理すること
つまり「どんな成果物を納めてほしいか」を条件として示すのは問題になりにくい一方、「どう作業するか」を指揮し始めると線を越えやすくなります。生成AIのルールも、作業手順の管理ではなく成果物の条件として組み立てるのが安全です。指揮命令と偽装請負の線引きについては、業務委託契約全般の論点として別途整理が必要なため、不安がある場合は契約形態の見直しを含めて専門家に相談することをおすすめします。
経済産業省「AIの利用・開発に関する契約チェックリスト」を発注者がどう使うか
発注者が条項を検討するうえで、心強い一次ソースになるのが経済産業省です。経済産業省は2025年2月18日に「AIの利用・開発に関する契約チェックリスト」を公表しました（経済産業省 報道発表）。
このチェックリストは全44ページのPDFで、インプット（入力情報）の取扱い、アウトプット（生成物）の取扱い、個人情報、セキュリティ、契約の進め方まで、AI利活用に関する契約論点を整理しています（チェックリスト本文PDF）。法務の専任がいない発注者でも、自社の発注で論点になりそうな項目を拾い、委託先との取り決めに反映する「論点の地図」として使えます。
PDF全体を読み込むのはハードルが高いため、まずは前章の4つのリスク（機密情報・著作権・品質・責任の所在）に対応する箇所から目を通すと、自社の契約に何が足りていないかを効率よく把握できます。
発注者が今日から使える対応ステップとチェックリスト
最後に、ここまでの内容を発注者がすぐ着手できる順序に落とし込みます。外注先に提示する利用ルールのたたき台と、納品物の検収チェック項目もあわせて示します。
対応の5ステップ
- 現状把握: 委託先が生成AIを使っているか、使っているなら何のツールをどの工程で使っているかを確認する（責めるのではなく事実確認の姿勢で）。
- リスク評価: 自社の発注内容を4つのリスク（機密情報・著作権・品質・責任の所在）に照らし、どれが重いかを見極める。
- 方針決定: 機密度 × 成果物の種類 × 検収体制の3軸で、禁止・条件付き許可・許可のどれを取るかを決める。
- 契約・ルールへの反映: 決めた方針を、成果物・条件レベルの取り決めとして契約・発注書・利用ルールに落とし込む（作業手順への指揮にならないよう注意）。
- 検収プロセスへの組み込み: 納品物のレビュー・検証の観点に「生成AI起因のリスク」を加え、継続的にチェックできるようにする。
外注先に渡す生成AI利用ルールのたたき台（項目例）
そのまま叩き台として使えるよう、利用ルールに盛り込むとよい項目を挙げます。自社の状況に合わせて取捨選択してください。
- 当社が提供する機密情報・個人情報・ソースコードを、生成AIのプロンプトに入力しないこと
- 生成AIを利用する場合は、入力内容が学習に使われない設定（法人向け商用プラン等）を使用すること
- 成果物の作成に生成AIを利用した場合は、その旨と利用範囲を当社に申告すること
- 生成AIの出力をそのまま納品せず、内容の正確性・動作・権利関係を委託先が検証すること
- 納品物が第三者の著作権・ライセンスを侵害していないことを保証すること
納品物の検収チェックリスト
納品物を受け取る際に、生成AI起因のリスクを点検する観点です。
- 機密情報が外部サービスに入力された形跡はないか（委託先への確認・申告内容の照合）
- コードやドキュメントに、出所不明・ライセンス不明の流用が含まれていないか
- 動作・要件充足・出典の正確性が、委託先によって検証されているか
- 成果物の権利帰属・非侵害について、契約上の保証が取れているか
これらを習慣化すれば、「確認すべきことを確認した」と言える状態に近づきます。完璧を目指すより、まず現状把握と条件付き許可の設計から始めるのが、放置でも過剰禁止でもない現実的な第一歩です。
よくある質問（FAQ）
外注エンジニアの生成AI利用について、発注者からよく挙がる疑問をまとめます。
外注先に生成AIの利用を全面禁止できますか？
契約上「禁止」と定めること自体は可能ですが、委託先の作業環境を発注者が常時監視することは現実的でないため、実効性の担保が難しいのが実情です。形骸化しやすく、優秀な委託先を遠ざける副作用もあります。極めて機密性の高い案件に限って禁止し、それ以外は条件付き許可で設計するほうが現実的です。
外注先が生成AIを使ったかどうかを発注者が見抜く方法はありますか？
完全に見抜くことは困難です。出力の文体やコードの傾向から推測できる場合もありますが、確実ではありません。だからこそ「検知」に頼るのではなく、契約・利用ルールで「利用した場合は申告する」ことを義務づけ、申告を前提に運用するほうが実務的です。
生成AIで作られた成果物の著作権は誰のものになりますか？
AI生成物の著作物性は、個別具体的な事例ごとに、人間による創作的寄与がどの程度あるかなどを総合的に考慮して判断されるとされています（文化庁「AIと著作権について」）。発注者としては、著作物性の有無に関わらず、納品物の権利帰属を契約で明確に取り決めておくことが重要です。
生成AIの利用ルールを細かく指示すると偽装請負になりますか？
「どんな成果物・条件で納品してほしいか」という成果物・仕様レベルの取り決めは、業務委託でも問題になりにくい範囲です。一方、「どのツールをどの工程でどう使うか」など作業の進め方を細かく指揮・管理し始めると、偽装請負と評価されるリスクが高まります。ルールは作業手順の管理ではなく、成果物の条件として組み立てるのが安全です。
機密情報を入力されないようにするにはどうすればよいですか？
契約・利用ルールで「機密情報をプロンプトに入力しないこと」を明示したうえで、生成AIを使う場合は入力内容が学習に使われない法人向け商用プランの利用を義務づけるのが基本です。あわせて、そもそも委託先に渡す機密情報を必要最小限に絞る（マスキング・ダミーデータの活用など）と、入力されてしまった場合のリスクも下げられます。
