外注が生成AIで書いたコード｜品質管理と著作権・バグ責任の契約

外注しているフリーランスや業務委託のエンジニアが、GitHub Copilot・Cursor・ChatGPT を使ってコードを書いていることに気づき、対応に迷っている方は多いのではないでしょうか。納品コードの英語コメントや、明らかに冗長で似通った実装、「AI活用による短納期見積もり」といったサインから外注先の生成AI利用に気づいたものの、全面禁止は現実的ではなく、放置もできない状態だと思います。

社内には生成AI利用ガイドラインがあっても社員向けにとどまり、外注先には適用されていない。既存の業務委託契約書のひな型も生成AI利用を前提にしていない。コードを一行ずつレビューできる技術力はなく、法務専任もいない。そんな状況で、成果物の品質・著作権・バグ責任をどう固めればいいのか、判断材料が見つからず困っている発注者の方は少なくありません。

結論を先に言えば、外注先が生成AIを使うこと自体を無理に止める必要はありません。防御すべきポイントは3つに絞れます。「動くが誰も中身を説明できないブラックボックスコード」を検収で弾く仕組み、「学習データ由来のOSSライセンス違反・第三者著作権侵害」を契約と検収の両面で抑える仕組み、そして「不具合が出ても『AIが書いたので分かりません』で逃げられない」契約不適合責任の設計です。この3点は、既存の業務委託契約書と検収フローに追加条項とチェック項目を差し込むだけで、法務専任がいなくても運用開始できます。

なお、そもそも外注先の生成AI利用を「許可するか／条件付きで許可するか／禁止するか」という方針決定のフェーズについては、本記事では扱いません。本記事は、既に「使わせている」または「使わせざるを得ない」と判断した後の運用フェーズ、つまり受入検査と契約設計をどう組み立てるかに絞って解説します。

本記事では、生成AI由来コードが発注者に跳ね返ってくる3つの実害を整理したうえで、既存の検収フローに追加すべき4項目、著作権・OSSライセンス・契約不適合責任の条項パターン、偽装請負を避ける指示の書き方、そして「今日から動かせる」運用フローの3点セットまでを、社内で実行に移せる粒度で解説します。

外注エンジニアが生成AIで書いたコードで、発注者が直面する3つの実害

発注者として最初に押さえたいのは、「生成AIを使わせるか否か」の総論ではなく、「使われている前提で自社にどんな実害が跳ね返ってくるか」という具体像です。実害の輪郭がはっきりすれば、契約と検収のどこを固めるべきかも自ずと決まります。方針決定フェーズそのもの（禁止すべきか／条件付き許可か／全面許可か）の判断軸を求めている場合は、外注エンジニアの生成AI利用、発注者は禁止すべき？対応方針の決め方を先に参照してください。本記事は、その方針が「使わせる」で決着した後の実行フェーズを扱います。ここでは3つの類型に整理します。

動くが誰も中身を説明できない「ブラックボックス化」

生成AIが書いたコードは、動作としては要件を満たしているものの、そこに至るまでのロジック選択や設計上のトレードオフを、書いた本人（外注エンジニア）が説明できないケースが増えています。特に「バイブコーディング」と呼ばれる、自然言語プロンプトで指示して出力をほぼそのまま採用するスタイルでは、生成物の内部構造が本人にも把握されないまま納品されることがあります（用語の詳細はバイブコーディングとは？意味・仕組み・実務での使い方を参照）。

これが問題になるのは、納品後の保守・障害対応フェーズです。本番でバグが出た際、外注エンジニアに「なぜこの実装にしたのか」「この分岐の条件は何を意図しているか」を問うても回答が得られず、結局発注者側で全面的に読み解き直す羽目になる、あるいは別の外注先に高額な調査費用を払うことになります。「動くコード」を納品してもらったはずが、実質的には「保守不能な負債」を抱え込んでいた、という事態です。

学習データ由来のOSSライセンス・第三者著作権が混入するリスク

生成AIのコーディングツールは、学習データに大量のOSS（オープンソースソフトウェア）を含んでいます。GitHub 自身が公式サイトで「Copilot の提案が学習に用いられたコード例と一致するのは、自社の調査に基づけばまれなケース（1%未満）である」と説明しています（GitHub Copilot 公式サイト、Responsible AI セクション内の記述）。ただし、この「1%未満」は「発生しない」を意味するものではなく、商用プロジェクトでは残る1%が依然として法的リスクを伴うことになるとする第三者の解説もあります（GitHub Copilotと著作権：企業がおさえるべきリスクと具体的な対策）。

さらに論点になるのが、依拠性の推認に関する整理です。文化庁の「AIと著作権に関する考え方について」（2024年3月15日、文化審議会著作権分科会法制度小委員会）では、生成物と既存著作物との類似性のみをもって直ちに「享受目的あり」と推認されるわけではないとしつつ、AI 開発段階で当該既存著作物が学習データに含まれていた場合には、客観的にはアクセスがあったものとして依拠性が認められる余地があるという方向性が示されています。また、生成AI が既存著作物に類似した生成物を著しく高い頻度で出力する事情は、学習段階での依拠性の判断において考慮しうる一要素として位置づけられている、と読み取れる整理になっています（文化庁『AIと著作権に関する考え方について』（令和6年3月15日）、イノベンティア『AIと著作権に関する考え方について』の公表について）。

つまり、外注エンジニアが「AI にコードを書かせただけで、そもそも元のOSSを見たこともない」と主張しても、類似性が認められれば依拠性が問題視される可能性は残ります。加えて、GPL・AGPL などのコピーレフト系ライセンスのコードが混入すれば、自社の商用プロダクト側にもソースコード開示義務が波及する可能性があります。

不具合発生時に「AIが書いたコードなので分かりません」で責任所在が曖昧になる

3つ目の実害は、契約不適合責任（旧・瑕疵担保責任）の追及局面で表面化します。納品後に想定と異なる動作・データ破損・セキュリティ脆弱性が発覚した際、外注エンジニアから「そこは AI が書いた部分なので、なぜそうなっているか分からない」「AI の一般的な癖なので免責事項に当たる」と主張されるケースです。

契約書に生成AI利用に関する条項がない状態で、外注エンジニアに「AI が書いた／人間が書いた」の内訳を証明する義務を課していなければ、責任追及の交渉は非常にやりづらくなります。結果的に、修補（無償改修）を求めるにも、損害賠償を請求するにも、「そもそも誰の意思決定で入ったコードか」の争点で消耗することになります。

3つの実害はどう繋がっているか——受入検査 × 契約の両輪で対処する

3つの実害は独立しているようで、実は同じ根に繋がっています。それは「外注先の生成AI利用を、発注者側が把握・記録できていない」という運用の穴です。この穴を埋める打ち手は、受入検査フローの追加と契約条項の追加の両輪で実行するのが現実的です。

• 受入検査：生成AI由来コードを見分けるための追加チェック項目を、既存の検収フロー（プルリクレビュー・CI・テスト網羅率など）に差し込む
• 契約：著作権帰属・OSSライセンス・契約不適合責任・免責範囲を、生成AI利用を前提にして書き直す

このあと、この両輪を順に組み立てていきます。

生成AIコードの成果物品質管理——既存の検収フローに追加する4項目

本章で扱うのは、生成AI由来コード固有の追加チェック項目に絞った内容です。プルリクレビュー運用・CI導入・テスト網羅率のチェックなど、業務委託全般に共通する検収フレームは、既存の別記事業務委託エンジニアの成果物検収・品質管理を仕組み化する方法に譲ります。ここでは「AI 利用を前提にした場合に、既存の検収フローに何を追加するか」を4項目に整理します。

技術力が乏しくても実行できる代替手段も併記するので、社内のレビュー体制と照らして取り入れやすいものから運用を始めてみてください。

出所開示——どの生成AIツール・どのプロンプトで作られたか

第1の追加項目は、生成AIツールの利用実態を書面で提出させる「出所開示」です。開示させる情報は、以下の3点で十分です。

1. 利用したツール名とプランのエディション（例: GitHub Copilot Business、Cursor Pro、ChatGPT Enterprise 等）
2. プロンプトの概要と、主要な生成箇所の記録（プルリクの説明欄に「AI 生成 or 補助あり」のラベル付けを求めるなど、簡易な形式でも可）
3. 利用ツール側の学習利用停止設定・コンテンツフィルタの有効化状況

なぜツール名とエディションの申告まで求めるかというと、後述の著作権侵害補償（インデムニティ）の適用範囲がプランによって大きく変わるためです。例えば Microsoft は GitHub Copilot Business / Enterprise の利用者に対して「Copilot Copyright Commitment」として、コンテンツフィルタを有効にした状態で使う限り、第三者からの著作権侵害訴訟に伴う防御費用と賠償金を負担すると発表しています（Microsoft、生成AI「Copilot」サービス利用による著作権侵害の賠償金を肩代わりすると発表）。無料プランや個人プランは対象外のため、外注先がどのプランで使っているかを把握していないと、いざ紛争になった際に補償の傘に入れているのかどうかすら分かりません。

技術力が乏しい発注者でも、プルリク説明欄への「AI 利用ラベル」記入運用と、契約書別紙での利用ツール申告書式の提出を求めるだけで、この項目は運用可能です。

OSSライセンス・依存関係スキャン——SCAツール活用と結果報告の受領

第2の追加項目は、SCA（Software Composition Analysis）ツールによるOSSライセンス・依存関係スキャン結果の受領です。SCA ツールは、ソースコードや依存パッケージを自動スキャンし、含まれているOSSコンポーネントとそのライセンス条件を抽出する仕組みで、OSSライセンス違反の予兆を検知するのに使われます（SCA（ソフトウェアコンポジション解析）とは？）。

生成AI が学習データからOSSコードの断片を出力してしまうリスクは前述の通りゼロにはできないため、SCA スキャン結果の提出を検収条件に加えることで、意図せず混入したライセンスの重い（GPL・AGPL 等の）OSS を発見しやすくなります。運用上は、以下の粒度で契約に組み込むのが現実的です。

• スキャン責任：外注エンジニア側で SCA スキャンを実施し、結果報告書を納品成果物に含める
• スキャンツール：自社側で指定するか、外注先の選定に委ねるかを明記（社内標準ツールがなければ、外注先の選定に委ねてよい）
• NG ライセンス一覧：混入を許容しないライセンス種別（コピーレフト系など）を別紙で列挙

自社に技術力がなくても、SCA スキャン結果の PDF レポートを見て「NG ライセンス欄が空欄になっているか」を確認するだけであれば、非エンジニアの担当者でも対応可能です。

コードレビュー観点の追加——「エンジニアが理解して書いたか」を確かめる問いと再現テスト

第3の追加項目は、コードレビュー時に「エンジニアが自分の理解の範囲内で書いたか」を確かめる問いを1つ追加することです。これは、前述のブラックボックス化を防ぐための最も安価な打ち手です。

具体的には、プルリクレビューの一部として、レビュアー（自社の別の外注エンジニアや社内メンバー）が以下の質問を投げます。

• 「このモジュールの主要な分岐条件は何を意図していますか？」
• 「エラーハンドリングでこのパターンを選んだ理由は？」
• 「もし要件が◯◯に変わった場合、どの箇所を変更しますか？」

回答が「AI が書いたので分からない」「動いているのでそのままにしています」で終わる場合、そのコードは保守不能な負債になる可能性が高いと判断し、書き直しか説明の追記を求めます。この観点は、生成AI 由来か人間が書いたコードかを問わず適用できますが、生成AI 利用が申告されているプルリクでは特に厳格に運用するのが実務的です。

保守性の担保——生成AI由来コードで特に脆弱になりやすい点に絞ったチェック

第4の追加項目は、生成AI由来コードで特に脆弱になりやすい3つの観点に絞った保守性チェックです。

1. テストコードの不在または表面的なテスト：生成AI は本体コードを書いた勢いでテストも生成できますが、境界値や例外パスがカバーされないことが多い。テストの網羅率数値だけでなく、境界値ケースが最低1件は含まれているかを確認する
2. 過度な抽象化・不要な設計パターンの導入：生成AI は「教科書的な設計」を出しがちで、要件に対して過剰なインターフェース分離や DI コンテナ導入が入る場合がある。要件に対して抽象化が過剰でないかを、レビュー時に問う
3. 不要な依存パッケージの追加：生成AI は「よくあるライブラリ」を提案しがちで、実際には数行の自作コードで済む部分に外部依存を導入することがある。依存追加の是非を、追加時にレビューで問う

これら3つの観点は、業務委託全般の検収でも重要ですが、生成AI 利用が申告されている場合には特に頻度が上がるため、既存の検収フローに追加する形で明文化しておくのが安全です。

著作権とライセンスリスクを契約で取り決める

前章の受入検査だけでは、著作権侵害やライセンス違反が発覚した際の責任・費用の分担が明確になりません。契約書に条項として盛り込むことで、事後の紛争リスクを事前に切り分けます。ここでは、生成AI利用を前提にした4つの条項パターンを紹介します。なお、フリーランス（受注側）の立場から見た同じ論点の整理はフリーランスエンジニアが AI コードを書いた際の著作権リスクと契約にまとめているため、発注者・受注者の両視点で著作権論点を俯瞰したい場合は併せて参照してください。

法務専任がいなくても、既存の業務委託契約書ひな型に「別紙」または「特約」として追加する形で運用可能です。

生成AIコードの著作物性——人間の関与によって帰属の考え方がどう変わるか

まず前提として、生成AIが単独で生成したコードそのものの著作物性については、日本の現行法上「思想又は感情の創作的な表現」（著作権法第2条1項1号）に該当しないため、著作物として保護されない可能性が高いと解釈されています。文化庁の「AIと著作権に関する考え方について」でも、人間の関与の度合いによって著作物性の有無が変わるという整理が示されています（TD SYNNEX BLOG：生成AIに関する著作権法上のリスクは？）。

この整理を発注者側の契約設計に落とし込むと、以下の3点を明文化するのが実務的です。

• 成果物の著作権帰属：完成した納品物全体の著作権を発注者に帰属させる（この点は生成AI利用の有無にかかわらず、業務委託契約で通常明記する条項）
• 人間の関与レベルの表明：外注エンジニアが「生成AIの出力を確認・修正した上で自らの判断で採用した」ことを表明保証させる
• 著作者人格権の不行使特約：生成AIコードに関する著作者人格権の主張リスクを事前に排除する

「成果物の著作権を発注者に帰属させる」条項があっても、AI 出力そのものが著作物でない場合には、そもそも「帰属させる対象」が存在しないという逆説的な問題が起こり得ます。この論点を回避するために、「本件成果物のうち著作物性が認められる部分について、その著作権は発注者に帰属する」という条件付きの書き方や、著作物性の有無にかかわらず利用権限を発注者に留保する条項を組み合わせるのが安全です。

OSSライセンス混入リスクへの対応——表明保証条項とSCAスキャン結果の提出義務

OSSライセンス違反のリスクを契約で吸収するには、表明保証（representations and warranties）条項が最も強力です。以下のような趣旨を条文化します。

• 納品成果物には、発注者が事前に別紙で許可した OSS 以外のオープンソースコードが含まれていないこと
• 含まれる OSS がある場合、そのライセンス条件は別紙のリストに従っており、発注者の商用利用に支障を与えないこと
• 前章で解説した SCA スキャン結果を、納品時に併せて提出すること

表明保証違反が発覚した場合の効果として、無償での差し替え（該当箇所の再実装）と、それに関連して発注者側で負った費用（法務相談費用・第三者への差替え委託費用等）の賠償を明記します。損害賠償の範囲・上限については後述の契約不適合責任の項で扱います。

第三者著作権侵害への補償・防御費用の分担条項

第三者から著作権侵害の主張・訴訟を受けた場合の対応も、契約書に事前に定めておくのが有効です。「インデムニティ条項」と呼ばれる型で、以下の要素を組み合わせて設計します。

• 通知義務：発注者が第三者からクレームを受けた場合、外注エンジニアに速やかに通知する義務
• 防御費用の分担：クレーム対応のための弁護士費用・和解金・判決による賠償金を、どの範囲で外注エンジニアが負担するか
• 上流ベンダーへの求償ルート：外注エンジニアが使った生成AI ツール（Copilot 等）のベンダーが補償プログラムを提供している場合、その補償を求償するための協力義務

前述の通り、Microsoft の Copilot Copyright Commitment はコンテンツフィルタ有効化などの条件下で商用プラン利用者に補償を提供します。外注エンジニアが個人プランで使っている場合はこの補償が及ばないため、契約書で「商用プランを利用すること」を義務化するか、少なくとも「利用プランを申告し、変更時は通知すること」を求めるのが実務的です。

秘密情報を生成AIに入力させない条項——学習利用停止設定の要求含む

最後に、機密情報・個人情報の保護に関する条項です。生成AIツールに社内情報や顧客データを入力すると、それが学習データとして再利用され、他の利用者への出力に含まれるリスクが指摘されています。この観点から、以下を条文化します。

• 入力禁止情報の範囲：発注者から提供された機密情報・個人情報・顧客データを、生成AIツールに入力してはならない
• 学習利用停止設定の義務：業務で使う生成AIツールについて、入力データを学習に利用しない設定（例: ChatGPT の「Chat history & training」オフ、API 利用など）を有効にすること
• 違反時の効果：違反が判明した場合の即時契約解除・損害賠償請求権

「学習利用停止設定を有効にしている状態のスクリーンショットを、契約締結時に提出する」といった運用上の履行確認策も、契約書ではなく別紙のチェックリストに落として運用するとよいでしょう。

バグ責任——「AIが書いたコード」の契約不適合責任をどう定義するか

著作権と並んで、発注者の関心が高いのが「納品後にバグや不具合が出た時、どこまで責任を追及できるか」です。契約書に生成AI利用を前提にした条項がない状態で、外注エンジニアから「AI が書いた部分なので分からない」と主張されると、責任追及の交渉が消耗戦になります。ここでは、契約不適合責任・準委任と請負の違い・免責の書き方について整理します。

契約不適合責任の一般原則と生成AIコードでの当てはめ

2020年4月に施行された改正民法により、業務委託契約における「瑕疵担保責任」は「契約不適合責任」に置き換えられました。改正のポイントは、受託者が納品したものが契約内容に適合していない場合、発注者は「追完請求（無償修補）」「代金減額請求」「損害賠償請求」「契約解除」を選択できるようになったことです（マネーフォワード クラウド契約：準委任契約に契約不適合責任は当てはまる？）。

改正前の瑕疵担保責任では受託者は無過失責任を負っていましたが、改正後は帰責事由（受託者側の落ち度）が必要になった点も重要です。この整理を生成AIコードに当てはめると、以下の考え方が導けます。

• 生成AI が書いたコード部分であっても、その採用・納品を判断したのは外注エンジニア本人であるため、契約内容に適合しない不具合が生じた場合の帰責事由は外注エンジニアにある、と主張する余地がある
• ただし、契約書に「AI が書いた部分は免責」といった条項があると、この主張の余地が失われる。免責事由の書き方には注意が必要（詳細はこの節の末尾で扱います）

つまり、契約書のデフォルト設計としては「生成AI 利用の有無を問わず、外注エンジニアが選択・採用した納品コードは、契約不適合責任の対象になる」と明記しておくのが安全です。

請負と準委任で責任範囲がどう変わるか——発注者側の意思決定への影響

業務委託契約は法律上「請負契約」と「準委任契約」の2種類に大別されます。契約不適合責任は請負契約に適用され、準委任契約には原則として適用されないという違いがあります。準委任契約の場合は「善管注意義務」が代替的な責任根拠になります。

発注者の意思決定として、生成AIコードの品質リスクを重視するなら、契約類型を明示的に「請負」に寄せる方が防御的です。特に「特定の機能・システムを完成させて納品する」タイプの委託では、請負契約を明記した上で契約不適合責任条項を組み込むのが実務的です。

一方、「エンジニアリング作業に一定期間従事する」タイプの委託（いわゆる SES 型・準委任型）では、契約類型が準委任になるケースが多く、契約不適合責任の追及は難しくなります。この場合は、成果物単位ではなく「作業プロセスの品質」（コードレビュー通過率・テスト網羅率等）を成果基準として設定し、善管注意義務違反として追及する枠組みに切り替える必要があります。

検収基準・不具合修補期間・損害賠償上限の明文化

契約不適合責任を実際に発動する際の運用ルールも、契約書に明文化しておくべきポイントです。

• 検収基準：どの状態をもって「契約に適合した」とみなすか（受入テスト合格基準・SCA スキャン結果の適合・出所開示の完了など）
• 契約不適合の通知期間：発注者が不適合を発見してから通知するまでの期間（改正民法では「知った時から1年以内」の通知が原則）
• 修補期間：外注エンジニア側が修補を完了すべき期限
• 損害賠償の上限：契約金額の何倍までを賠償上限とするか

損害賠償の上限については、外注エンジニア側から「委託料の総額を上限とする」旨の条項を求められるケースが多く、実務では受け入れざるを得ないこともあります。ただし、以下の例外を上限の外に置くことは交渉可能です（業務委託契約書における損害賠償条項に関する注意点）。

• 故意または重過失による損害
• 第三者知的財産権侵害（前章のインデムニティ条項の対象）
• 秘密保持義務違反

これらは生成AI利用に伴うリスクと直接関係するため、上限外の除外事項として明記できるかどうかが、契約交渉の勝負どころになります。

免責事由の書き方——「AIツールの一般的な不具合」を免責しないための限定条項

外注エンジニア側から「生成AI ツールに起因する不具合は責任範囲外」といった免責条項の追加を求められる場合があります。この文言をそのまま受け入れると、実質的にほぼ全ての不具合が「AI 起因」と主張され、責任追及ができなくなるリスクがあります。

免責範囲を限定するために、以下の絞り込みを契約書で行います。

• 免責の対象外：外注エンジニアが「生成AI の出力を確認・修正した上で採用した」コードに関する不具合は免責しない（採用判断の帰責が外注側にあるため）
• 免責の対象：生成AI ツール自体のサービス停止・アカウント凍結など、外注エンジニアの選択・行動と因果関係のない事象のみ

「AI が書いたコードだから分からない」という主張を封じるには、契約書側で「本件成果物は、生成AI の利用有無を問わず、乙（外注エンジニア）が最終的に採用・納品したものとみなす」といった規定を置くのが実務的です。

偽装請負を避けながら「AI利用ルール」を取り決める

前章までは「契約書と検収でどこまで固められるか」の視点でしたが、逆方向のリスクも押さえる必要があります。それは「発注者が細かい指示を出しすぎると、業務委託ではなく偽装請負とみなされる」という規制上のリスクです。

厚生労働省の告示（労働者派遣事業と請負により行われる事業との区分に関する基準を定める告示）では、発注者と受注者の労働者との間に「実質的な指揮命令関係」が存在するか否かで偽装請負が判断されます（東京労働局：偽装請負について）。生成AI 利用ルールを外注先に守らせる指示がどこまで許されるかを、この基準と照らして整理します。

業務委託で発注者ができる指示・できない指示の原則

偽装請負の判断基準として、東京労働局の資料でも整理されている通り、業務委託契約における発注者から受注者への指示は、「業務の目的・成果物の要求水準」に関するものに限られ、「作業手順・作業時間・作業場所」など労働者への具体的な業務遂行方法の指示は許されないとされています。

この原則を生成AI 利用に当てはめると、以下のように整理できます。

つまり、「成果物の品質を担保するために必要な条件」として書ける範囲であれば、AI 利用ルールも契約に組み込めます。逆に「作業の進め方」レベルまで踏み込むと、指揮命令関係が疑われる領域に入ります。

「利用ツールの禁止・限定」は指揮命令になるか——判断の考え方

「特定の生成AIツールの利用を禁止する」「学習利用停止設定を義務付ける」といった条項は指揮命令に当たるのでしょうか。これは、その指示が「成果物の要求水準」として書けるか、「作業手順」として書かざるを得ないかで判断が分かれます。

たとえば、「機密情報を学習に使われるリスクを避けるため、学習利用停止設定を有効にしたツールで作成された成果物のみを納品対象とする」という書き方は、成果物側の要求として整理できるため、指揮命令のリスクは低いと解釈できます。一方で、「業務中の作業をログとして提出せよ」「使用ツールを毎日申告せよ」といった作業プロセスの指示は、指揮命令の色合いが強くなります。

判断に迷う場合は、「その指示が守られたかどうかを、成果物や納品書類だけで判定できるか」を基準にすると分かりやすいです。成果物や納品書類の側だけで判定できるものは成果物への要求、判定できず作業中の状態を監視しないと確認できないものは作業手順への指示、と整理できます。

契約書と別紙の使い分け——成果物の要求水準か、作業ルールか

以上の整理を踏まえ、契約書本体と別紙の役割分担は以下のように設計するのが実務的です。

• 契約書本体：成果物の要求水準として書ける事項（著作権帰属・表明保証・SCA スキャン結果の添付・契約不適合責任・損害賠償など）
• 別紙（成果物仕様書・受入基準）：具体的な検収チェックリスト、NG ライセンス一覧、機密情報の取扱い基準、成果物として満たすべき生成AI利用条件
• 参考資料（拘束力なし）：発注者側の生成AI利用ガイドラインや推奨ツール一覧など、参考として渡すもの（「拘束力はないが参考として共有する」旨を明記）

「作業手順としては書けないが、成果物の性質としては要求したい」内容は、別紙の受入基準に落とし込むことで、偽装請負リスクを回避しながら実効性を確保できます。この設計は、法務専任がいなくても、既存の業務委託契約書ひな型の別紙構成を少し組み替えるだけで導入可能です。

発注者が今日から動かせる運用フロー——契約 × 検収 × 記録の3点セット

ここまで解説した論点を、「発注時 → 開発中 → 検収時 → トラブル発生時」の時系列に沿って、社内で運用開始できる粒度に落とし込みます。既存の業務委託運用に追記する差分として整理するので、明日から社内で回せるレベルの型として持ち帰ってください。

発注時——契約書に追記する条項ドラフトの骨子と外注先へのヒアリング項目

発注時のアクションは、契約書への条項追加と、外注先へのヒアリングです。契約書の追加条項の骨子は以下の通り。

1. 生成AI利用の申告義務：使用するツール・プラン・学習利用停止設定の状況を、契約締結時と変更時に申告
2. 著作権帰属と表明保証：本件成果物の著作権を発注者に帰属させ、第三者知的財産権を侵害しないことを表明保証
3. SCA スキャン結果の提出：納品時にスキャン結果を添付。NG ライセンスは別紙参照
4. 契約不適合責任：改正民法に準拠。生成AI利用の有無を問わず、外注エンジニアが採用・納品したコードを対象とする
5. 免責範囲の限定：外注エンジニアが確認・採用したコードに関する不具合は免責しない
6. 秘密情報の生成AI入力禁止：機密情報・個人情報・顧客データの生成AIツールへの入力禁止と、学習利用停止設定の義務

外注先へのヒアリング項目としては、以下を契約締結前に確認します。

• 現在使用している生成AIツール名とプラン
• チーム内の生成AI利用ガイドライン（外注先自身のもの）の有無
• 過去に SCA スキャンツールを使った経験と、指定ツールへの対応可否
• 学習利用停止設定の有効化状況

これらのヒアリング結果は、契約書の別紙や覚書に落として保存しておくと、後日の紛争時の証拠になります。

開発中——生成AI利用記録・OSSスキャン結果の途中提出を運用に組み込む

開発中のフェーズでは、記録を残す運用が中心になります。特に以下の3点は、途中提出を求める形で運用フローに組み込むと、検収時の消耗を大幅に減らせます。

• プルリク説明欄への AI 利用ラベル：AI 生成 or AI 補助あり or 人手のみ、の3種類を選択する形式
• 月次または反復開始時の SCA スキャン結果の提出：最終検収時に一括ではなく、開発途中で見つけられるようにする
• 重要な設計判断の記録：AI が提案した設計と、外注エンジニアが最終的に採用した設計の差分と理由

これらの記録は、成果物の要求水準として位置づけることで、偽装請負リスクを避けながら実装可能です。「途中提出物として何を含めるか」を成果物仕様書の別紙に明記しておくのがポイントです。

検収時——受入検査チェックリスト

検収時の受入検査チェックリストは、以下の項目を追加します。既存の検収項目（プルリクレビュー通過・CI ビルド成功・テスト網羅率など）に、生成AI 由来コード固有の追加項目を差し込む形です。既存項目そのものの整備・運用の解説は業務委託エンジニアの成果物検収・品質管理を仕組み化する方法にあり、本記事はその上に載せる差分を扱います。

• 生成AI利用申告書の最新版が提出されているか（利用ツール・プラン・学習利用停止設定）
• SCA スキャン結果の PDF レポートが添付されているか。NG ライセンス欄が空欄か
• 主要モジュールについて、外注エンジニアが分岐条件・エラーハンドリング・変更点を説明できるか（口頭確認可）
• 境界値ケースを含むテストコードが最低限含まれているか
• 過度な抽象化・不要な依存追加が含まれていないか（レビュアーの主観チェックで可）

チェックリスト自体は、社内の非エンジニアの担当者でも項目ごとに「○／×／不明」を付けられる粒度にしておくと、レビュー体制が薄い発注者側でも運用できます。「不明」に付いた項目のみ、社内の技術者や別の外注レビュアーに確認を回す運用が現実的です。

トラブル発生時——「AIが書いたから」の申告があった場合の対応順序

最後に、納品後に不具合や著作権クレームが発生し、外注エンジニアから「AI が書いた部分なので分からない」といった申告があった場合の対応順序を整理します。

1. 契約書の該当条項を確認：契約書に「AI 利用の有無を問わず、採用・納品したコードは外注エンジニアの責任」旨の規定があるかを確認
2. 申告内容の記録：外注エンジニアの申告内容（口頭・メール・チャット）を書面化し、日付付きで保存
3. 修補要求：契約不適合責任に基づく修補を、期限付きで書面で要求
4. 応じない場合の措置：契約解除・損害賠償請求・第三者への修補委託と費用求償を、契約条項に基づき順次実行
5. 再発防止：他の外注先・他の案件でも同様のリスクがないか、契約書と検収チェックリストの更新余地を検討

第三者から著作権侵害のクレームが来た場合は、上記に加えて、外注エンジニアが使っていた生成AI ツール（Copilot 等）のベンダー補償プログラムの適用可否を、契約書のインデムニティ条項に基づいて確認・活用します。

外注先の生成AI利用は今後も広がり続けます。禁止でも放置でもなく、契約書と検収チェックリストの2つの型を先に整えておくことで、外注エンジニアが自由に生成AIを活用しながらも、発注者側のリスクは抑えられる状態を作れます。本記事の内容を、既存の業務委託運用に少しずつ差分として追加していってください。