「うちのソースコードや仕様書が、外部の AI に送られていないか確認しておいて」。委託先の開発者が GitHub Copilot や Cursor を日常的に使っていると知った上長から、そう指示された情報システム担当の方は少なくないのではないでしょうか。ところが手元にある社内の生成AI利用ガイドラインを開くと、適用範囲は「当社従業員」。委託先には一行も効いていないことに気づきます。
やっかいなのは、この状態が「方針が決まっていない」のではなく「方針はあるのに届いていない」ことにある点です。AI の利用を全面禁止しても、委託先の開発環境まで踏み込んで検知する手段はありません。かといって全面的に容認したままでは、監査や顧客審査で「委託先の AI 利用はどう管理していますか」と問われたときに答えられません。禁止と放置のあいだで、どこまで書けば「管理している」と説明できる状態になるのかが見えず、着手できないまま時間だけが過ぎていきます。
この問題は、AI 利用の是非を考え直すことでは解決しません。解決の鍵は、既存の社内ルールの適用範囲を委託先まで届く形に書き換えること、そして規程では縛れない部分を契約・確認シートに振り分けることにあります。作業としては、ゼロから新しい規程を作るより、はるかに小さい範囲で済みます。
本記事では、外注先が AI コーディングツールを使う前提で発注者が確認すべき5項目を整理し、それぞれを「社内規程に書くこと」「契約・NDA に書くこと」「委託先への確認シートで聞くこと」に仕分ける方法まで解説します。最後に、既存のガイドラインをどう改訂し、どの順番で着手するかの手順をまとめます。ツールの仕様や公的ガイドラインは更新が速いため、引用元は出典リンク付きで示します。
なお、契約条項に関する記述は実務の考え方を整理したもので、法的な助言ではありません。実際の条文化にあたっては弁護士等の専門家にご確認ください。
フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド
この資料でわかること
業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。
こんな方におすすめです
- フリーランス新法への対応状況を社内で点検したい企業担当者
- 業務委託契約書・NDAの記載事項を確認したい法務担当者
- 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー
入力いただいたメールアドレスにPDFをお送りします。
外注先のAIコーディングツール利用に社内ルールが追いつかない理由
受託開発会社やフリーランスの開発現場では、AI コーディングツールの利用がすでに前提になりつつあります。コード補完だけでなく、テストコードの生成、リファクタリング、エラー原因の調査まで日常的に使われており、「使わないでください」という要求は、実質的に生産性と単価の再交渉を意味します。
一方で、発注者側の生成AI利用ガイドラインの多くは、社内で ChatGPT の利用が広がった時期に整備されたものです。想定していたのは「社員がチャット画面に情報を貼り付ける」場面であり、「委託先の開発者がエディタ上でリポジトリを扱う」場面ではありません。この想定のズレが、管理しているつもりで管理できていない状態を生みます。
本記事は「使われる前提で自社ルールを整える」立場を取ります。禁止を選ぶ場合でも、それを実効性のある形にするには、結局は本記事で挙げる確認項目と同じ内容を契約と確認シートに落とす必要があるためです。
社員向けの生成AI利用ガイドラインは委託先に効かない
社内規程は、原則として自社の従業員を拘束するために作られています。多くのガイドラインは冒頭の「適用範囲」で「本ガイドラインは、当社の役員および従業員に適用する」と定義しており、この一文がそのまま壁になります。業務委託先は自社の指揮命令下にある従業員ではないため、規程を配布しただけでは相手を拘束できません。
ここで発注者側が取りうる選択肢は、大きく3つです。
- 適用範囲の条文を「当社の役員および従業員、ならびに当社が業務を委託する事業者およびその履行補助者」に広げ、契約でその遵守を義務づける
- 従業員向けの規程はそのままにして、委託先向けの別紙（AI ツール利用に関する要求事項）を新設し、契約書の添付資料として位置づける
- 規程には書かず、必要事項をすべて個別契約書・NDA・作業要領に直接書き込む
どれを選んでも、「規程を改訂しただけでは効力が届かない」点は共通です。委託先に守らせたい事項は、最終的に契約で参照される形にする必要があります。この切り分けは記事後半の「確認項目3」で詳しく扱います。
AIコーディングツールが汎用チャットAIと違う3つの挙動
委託先の AI コーディングツール利用を、社内の ChatGPT 利用と同じ枠組みで考えると、リスクの見積もりを誤ります。開発向けツールには、汎用チャット型 AI にはない次の3つの挙動があるためです。
1つ目は、コンテキストの自動送信です。 チャット型 AI では、利用者が意識的に貼り付けた文字列だけが送信されます。一方、AI コーディングツールは補完精度を上げるため、開いているファイルの前後、同一ワークスペース内の関連ファイル、プロジェクトの設定ファイルなどを自動でコンテキストとして参照します。開発者本人が「機密情報は入力していません」と考えていても、周辺のコードや設定値が一緒に送られている可能性があります。「入力しない」というルールだけでは制御しきれないのはこのためです。
2つ目は、エージェント機能による自動実行です。 近年のツールは、指示に応じてファイルの新規作成・書き換え、依存パッケージの追加、コマンドの実行までを自律的に行います。これは開発速度を大きく高める一方で、意図しない外部通信や、レビューを経ない変更が混入する経路にもなります。
3つ目は、生成コードへの公開コード由来の断片の混入です。 生成されたコードが既存の公開コードと近い場合、そのライセンス条件が自社の成果物側に影響する可能性があります。この点は多くのツールに緩和機能が用意されており、後述の「確認項目4」で扱います。
社内ルール未整備のまま外注を続けると起きること
リスクを漠然と怖がっても、ルール文書は書けません。ここでは、発注者側に実際に跳ね返る影響を4つに整理し、それぞれ「どういう条件で起きるか」とセットで確認します。この対応関係が分かると、後半の5項目が何を潰すための項目なのかが見えてきます。
起きること | 発生条件の例 | 対応する確認項目 |
|---|---|---|
自社のコード・仕様・データが外部サービスへ送信される | 個人プランの利用、学習利用オプトアウト未設定、コンテキスト除外の未設定 | 確認項目1・2 |
生成コードのライセンス条件が自社成果物に及ぶ | 公開コード一致のブロック機能が無効、依存ライセンスの未確認 | 確認項目4 |
誰も説明できないコードが納品され保守が属人化する | レビュー体制・記録要求の欠如 | 確認項目5 |
顧客監査・ISMS 審査で委託先管理の不備を指摘される | 委託先の AI 利用に関する要求事項・確認記録の不在 | 確認項目3・5 |
情報の流出経路は「入力」だけではない
情報の流出経路として真っ先に思い浮かぶのは、開発者が機密情報をプロンプトに貼り付ける場面でしょう。しかし実務上、より把握しづらいのは前述したコンテキストの自動送信と、送信後のデータ保持です。
サービス側がどの範囲のデータをどれだけの期間保持し、モデルの改善に利用するかは、製品ごと・プランごとに定められています。したがって発注者が確認すべきなのは「機密を入力していないか」という自己申告ではなく、どの製品のどのプランを、どの設定で使っているかという事実です。この観点は「確認項目2」で具体化します。
権利・ライセンスの問題が自社製品側に残る理由
情報流出は「起きたかどうか」がある程度わかりますが、ライセンスの問題は納品後に長く残る点が異なります。生成コードに公開コード由来の断片が含まれていた場合、そのライセンス条件（例えばソースコードの開示義務を伴うもの）が、自社が保有・販売する成果物に影響する可能性があります。委託先の作業に起因していても、成果物を利用し続けるのは発注者です。
生成AIと著作権の関係を体系的に確認したい場合は、生成AIの著作権リスクもあわせてご覧ください。本記事では、ルール文書に書ける運用条件に絞って後述します。
監査・顧客審査で問われるのは委託先ではなく発注者
ISMS の維持審査や、大口顧客からのセキュリティチェックシートでは、外部委託先の管理状況が定番の確認項目です。ここで問われるのは委託先の社内体制そのものではなく、「発注者が委託先に何を要求し、どう確認しているか」です。
つまり、委託先が優れた管理をしていても、発注者側に要求事項と確認記録がなければ「管理していない」と評価されます。逆に言えば、確認シート1枚と回答記録があるだけで、説明できる状態に大きく近づきます。委託先管理を含む情報セキュリティの基本的な考え方は、発注者が知るべき情報セキュリティの基礎で整理しています。
確認項目1｜使用ツールと入力してよい情報の線引きを決める
ここからが本題の5項目です。1つ目は、委託先が使うツールと、そこに入力してよい情報の範囲を決めることです。AIコーディングツールのセキュリティ対策は、この線引きから始まります。
承認単位は「製品名＋プラン＋テナント」で定義する
よくある失敗は、承認済みツールを製品名だけで管理してしまうことです。「GitHub Copilot は可、それ以外は不可」という書き方では、同じ製品でも個人プランと法人プランでデータの扱いが異なる点を捉えられません。
承認の単位は、次の3つをセットにして定義することをおすすめします。
- 製品名: GitHub Copilot、Cursor、Claude Code など
- プラン: 個人向けか法人向けか（Free / Pro / Business / Enterprise 等）
- テナント: どの組織アカウント配下で利用するか（委託先の組織テナントか、発注者が発行したアカウントか）
テナントまで指定する意味は、組織テナント配下であれば管理者側でポリシーを一括設定でき、設定値を証跡として確認できる点にあります。例えば GitHub Copilot では、組織や Enterprise のポリシー設定が配下のユーザーに継承されます（GitHub Docs: 組織の Copilot ポリシー管理）。
新しいツールを使いたい場合は事前申告と承認を求める、という運用（承認済みリスト方式）にしておくと、ツールの入れ替わりが速い状況にも耐えられます。
情報区分ごとに入力可否を決める
「機密情報は入力しない」という書き方は、現場では判断できません。何が機密かの解釈が人によって違うためです。自社の情報区分ごとに可否を明示する表の形にすると、委託先も判断に迷わなくなります。
以下は書き方の例です。区分と可否は自社の情報資産管理規程に合わせて調整してください。
情報区分 | 例 | 入力可否の記載例 |
|---|---|---|
顧客の個人情報 | 氏名・連絡先・購買履歴 | 不可（テストデータは匿名化データを使用） |
顧客から預かった業務データ | 実データのCSV・帳票 | 不可 |
未公開の仕様・企画情報 | 新機能の要件定義書 | 承認済みツールかつ法人プランに限り可 |
本番環境の設定値・認証情報 | 接続文字列・APIキー | 不可（除外設定の対象とする） |
自社が権利を持つソースコード | リポジトリ内のコード | 承認済みツールかつ法人プランに限り可 |
公開情報 | 公開ドキュメント・OSSコード | 可 |
あわせて、認証情報や設定ファイルをツールの参照対象から外す仕組み（コンテンツ除外機能など）の利用も要求事項に含めておくと、運用者の注意力に頼らずに済みます。GitHub Copilot にはリポジトリ単位・パス単位で参照対象から除外する機能があります（GitHub Docs: コンテンツの除外）。
委託先に配る確認シートには、次のような設問を並べます。
- 本案件で使用する AI コーディングツールの製品名・プラン・利用テナントをご記入ください
- 認証情報・設定ファイルを AI の参照対象から除外する設定を行っていますか（設定名と対象パスをご記入ください）
- 本案件で新たなツールを追加する場合、事前にご連絡いただけますか
確認項目2｜学習利用のオプトアウトとプラン設定を確認する
2つ目は、入力したデータがモデルの改善に利用されるかどうかを、設定値レベルで確認することです。ここは精神論ではなく、確認すれば白黒がつく事実として扱えます。
プランによって学習利用の扱いが変わる
同じ製品でも、個人向けプランと法人向けプランでデータの扱いは異なります。GitHub Copilot を例にすると、2026年4月24日以降、Copilot Free / Pro / Pro+ の利用者については、入力・出力・コードスニペットおよび関連コンテキストがモデルの学習・改善に利用される扱いとなり、利用者は設定画面からオプトアウトできます。一方、Copilot Business および Enterprise の利用者は契約条項によって保護されており、この設定自体が表示されません（GitHub Docs: アカウントのポリシー管理、GitHub Blog: Copilot インタラクションデータ利用ポリシーの更新）。
同じページでは、公開コードと一致する提案の扱いも設定できます。ブロックを選ぶと、提案とその周辺コード（約150文字）を公開コードと照合し、一致する提案を表示しない挙動になります。この設定は「確認項目4」で扱うライセンス対策にも直結します。
つまり、委託先が「GitHub Copilot を使っています」と回答しただけでは判断材料になりません。どのプランで、学習利用の設定がどうなっているかまで聞いて初めて、上長に説明できる材料になります。
なお、こうしたポリシーや設定項目は製品側の判断で更新されます。本記事の記述は2026年9月時点の公開情報に基づくものです。実際の確認時には、必ず各ツールの公式ドキュメントで最新の扱いをご確認ください。
発注者が受け取るべきエビデンスと、再確認のタイミング
口頭やメール本文での回答だけでは、監査の場面で証跡になりません。確認シートの回答に加えて、次のいずれかを受け取る運用にしておくと扱いやすくなります。
- 管理コンソールのポリシー設定画面のスクリーンショット（該当項目のみ、日付が分かる形で）
- 組織テナントの管理者名義による設定値の書面申告
- 発注者が発行したアカウントを使う場合は、発注者側で設定して証跡を保持する
再確認のタイミングは、案件開始時に加えて、契約更新時、そして年1回程度の定期確認を目安にすると運用が破綻しにくくなります。ツール側のポリシー変更があった場合は臨時で確認する、という一文を要求事項に加えておくと、変更のたびに交渉し直す手間を減らせます。
フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド
この資料でわかること
業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。
こんな方におすすめです
- フリーランス新法への対応状況を社内で点検したい企業担当者
- 業務委託契約書・NDAの記載事項を確認したい法務担当者
- 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー
入力いただいたメールアドレスにPDFをお送りします。
確認項目3｜契約・NDAに書くことと社内ルールに書くことを切り分ける
3つ目は、多くの担当者が最初につまずく論点です。社内ルールをどれだけ丁寧に書いても、それだけでは委託先を拘束できません。効力が届く範囲で書き分ける必要があります。
規程は自社従業員、委託先は契約——効力の届く範囲で書き分ける
整理すると、次のような役割分担になります。
文書 | 効力が及ぶ相手 | 書くべき内容 |
|---|---|---|
社内規程・ガイドライン | 自社の役員・従業員 | 委託先を選ぶ際の基準、確認の実施義務、承認済みツールリストの維持、違反時の社内対応 |
個別契約書・NDA | 委託先（および再委託先） | 秘密情報の AI への入力制限、生成AI利用の申告義務、第三者権利の非侵害、再委託先への同等義務 |
作業要領・仕様書 | 委託先（契約で参照される形） | 成果物の品質要件、レビュー記録の提出、インシデント連絡の手順 |
確認シート | 委託先（事実確認の手段） | 使用ツール・プラン・設定値・体制の申告 |
社内規程に「委託先は◯◯すること」と書くこと自体は問題ありませんが、それが相手を拘束するのは契約で参照されている場合に限られます。規程の改訂と契約書の改訂は、セットで進める前提で計画を立ててください。
契約・NDAに追加する条項の型
生成AIの秘密保持契約の条項として、実務でよく論点になるのは次の4つです。いずれも、たたき台として社内で議論するための出発点であり、条文化の際は弁護士等にご確認ください。
1. 秘密情報の生成AIへの入力制限
秘密情報を生成AIサービスに入力することを原則禁止した上で、発注者が事前に承認したツール・プラン・設定の範囲でのみ例外を認める、という構成が扱いやすい形です。全面禁止だけを書くと実態と乖離し、かえって申告されなくなる点に注意が必要です。
2. 成果物への生成AI利用の申告義務
成果物の作成過程で生成AIを利用した場合に、使用ツールと利用範囲を発注者に申告する義務を定めます。申告を求める目的は禁止ではなく、後述するライセンス確認と検収の判断材料を得ることにあります。
3. 第三者の権利を侵害していないことの表明保証
成果物が第三者の著作権その他の権利を侵害しないこと、およびオープンソースソフトウェアを利用する場合はそのライセンス条件を発注者に開示することを求めます。開示された条件を受け入れるかどうかは発注者側の判断になります。
4. 再委託先への同等義務の設定
委託先がさらに別の事業者や個人に再委託する場合、同等の義務を課すことを求めます。AI ツールの利用は個々の開発者の環境に依存するため、再委託の連鎖まで届く条項がないと実効性が落ちます。
条項のひな形を探す際は、公的団体が公開している資料が出発点として使いやすく、社内稟議でも根拠として示しやすくなります。日本ディープラーニング協会（JDLA）は2025年9月19日に「生成AI開発契約ガイドライン」を公開しており、NDA・アセスメント契約・開発契約などの契約書ひな形を含む資料編が無償で提供されています（JDLA: 『生成AI開発契約ガイドライン』を公開）。
指示と要求の境目（偽装請負と受け取られない書き方）
見落とされがちなのが、要求の書き方によっては請負・準委任契約における指揮命令の問題が生じうる点です。労働者派遣事業と請負により行われる事業との区分に関する基準（いわゆる37号告示）では、発注者が受託者の労働者に直接指揮命令を行っている実態がある場合、契約の形式にかかわらず労働者派遣に該当すると整理されています（厚生労働省: 「労働者派遣事業と請負により行われる事業との区分に関する基準」（37号告示）に関する疑義応答集）。
AI ツールに関する要求も、書き方によっては「作業方法の指示」に近づきます。区別の目安は次のとおりです。
避けたい書き方（作業方法の指示に近い） | 望ましい書き方（成果物・情報の取扱いに関する要求） |
|---|---|
開発者は補完機能をオフにして作業すること | 成果物には、承認外のツールを経由して生成されたコードを含めないこと |
1日の作業終了時に AI 利用ログを担当者へ提出すること | 成果物の納品時に、生成AIの利用範囲を記載した申告書を提出すること |
このファイルの編集時は AI を使わないこと | 別紙に定める区分の情報は、承認済みの環境以外で取り扱わないこと |
要点は、誰がどう作業するかではなく、成果物と情報がどういう状態であるべきかを書くことです。この整理は、委託先の自律性を尊重する形にもなり、交渉の場でも受け入れられやすくなります。
確認項目4｜生成コードの権利とOSSライセンスの扱いを決める
4つ目は、生成AIのコードに関する著作権とライセンスの扱いです。「著作権が心配」という漠然とした不安は、そのままではルール文書に落とせません。運用条件の形に変換していきます。
生成コードの権利帰属は契約で決める
前提として、成果物の権利がどちらに帰属するかは、AI を使ったかどうかにかかわらず契約で定める事項です。したがって、既存の業務委託契約に「成果物の著作権は検収完了時に発注者に移転する」といった条項があれば、その枠組み自体は AI 生成コードにも適用できると考えるのが自然です。
実務上の論点は、権利の移転そのものよりも、移転される成果物が第三者の権利を侵害していないかという点に移ります。だからこそ、前述した非侵害の表明保証と、次に述べるライセンス確認の運用が重要になります。生成AIと著作権をめぐる論点全体を確認したい場合は、生成AIの著作権リスク対策を参照してください。
OSSライセンス混入を減らす3つの運用
ルール文書に書ける、具体的な運用条件は次の3つです。
1. 公開コードとの一致をブロックする設定を有効にする
多くの AI コーディングツールには、生成した提案が公開コードと一致する場合にその提案を表示しない機能があります。GitHub Copilot の場合、公開コードと一致する提案の設定をブロックにすると、提案と周辺のコードを公開コードと照合し、一致・近似する提案を出さない挙動になります（GitHub Docs: アカウントのポリシー管理）。この設定を有効にすることを、承認条件として要求事項に含めます。
2. 依存ライセンスのスキャンを実施する
AI が追加した依存パッケージは、人間が選んだものより見落とされやすい傾向があります。依存関係の一覧（SBOM）を作成し、ライセンスをスキャンする工程を、誰が・いつ実施するかまで含めて決めておきます。委託先が実施して結果を提出するのか、発注者側の環境で実施するのかを明記してください。
3. ライセンス表記の確認プロセスを納品条件にする
利用しているOSSのライセンス表記（著作権表示・ライセンス全文の同梱など）が、条件どおりに用意されているかを確認する工程を、検収条件の一部として定めます。これは AI 利用の有無にかかわらず必要な工程ですが、AI の利用によって依存の追加が増えるほど重要性が高まります。
品質管理や検収の詳細、不具合が発生した場合の責任分配は本記事の範囲を超えるため、契約実務の観点で別途整理することをおすすめします。
確認項目5｜レビュー・記録・インシデント連絡の運用を決める
5つ目は、納品後まで含めた運用の話です。AI 生成コードの比率が上がるほど、「動くけれど、誰も設計意図を説明できないコード」が増えていきます。発注者側でコードレビューができない前提でも、プロセスの要求によって一定の歯止めをかけられます。
発注者がレビューできなくても成立させる要求の書き方
技術的な内容を評価できなくても、次の3点は要求できます。
- 人間による確認者の明示: 委託先の体制内で、生成コードを含む変更を確認する担当者を明示してもらいます。「AI が生成したコードも、必ず人間の確認を経て提出する」という原則を作業要領に書きます
- 変更履歴とレビュー記録の保存: プルリクエスト単位のレビュー記録を、契約期間終了後も一定期間保存し、求めに応じて提出できる状態にしてもらいます
- 設計意図の記録: 主要な設計判断について、判断理由を残してもらいます。保守フェーズで別の事業者に引き継ぐ場合、この記録の有無が引き継ぎコストを大きく左右します
一方で、要求水準を上げすぎると委託先の工数が増え、見積単価に跳ね返ります。すべての案件で同じ水準を求めるのではなく、扱う情報の機微度と、システムの重要度で段階を分ける設計にしておくと現実的です。例えば、個人情報を扱う基幹システムは全項目を要求、社内向けの試作は申告のみ、といった具合です。
インシデント時の連絡経路と時限を先に決めておく
秘密情報を誤って AI に入力してしまった、生成コードに公開コード由来の断片が含まれている疑いが出た、といった事態は、起きてから連絡経路を考えるのでは遅くなります。次の4点を、あらかじめ契約または作業要領に書いておきます。
- 報告対象: どのような事象が報告対象か（承認外ツールの利用、承認外の情報区分の入力、権利侵害の疑い、など）
- 連絡先: 発注者側の一次連絡先と、その不在時の代替連絡先
- 時限: 事象を認識してから何時間以内に第一報を入れるか（例: 認識後24時間以内）
- 初動: 一次対応として委託先に求める措置（該当アカウントの利用停止、該当データの削除申請、証跡の保全など）
報告してもすぐに責任追及されるという空気があると、報告そのものが上がってこなくなります。第一報を早く上げることを優先する運用方針を、要求事項の中に明記しておくと機能しやすくなります。
5項目をAIコーディングツールの社内ルールに落とし込む手順
ここまでの5項目を、実際のドキュメントに反映していきます。生成AIの社内ルールの作り方として、次の4ステップで進めると着手しやすくなります。
適用範囲の書き換え（または委託先向け別紙の追加）
最初にやるのは、新しい文書を作ることではなく、既存の生成AI利用ガイドラインの適用範囲条文を開いて確認することです。冒頭の一文が「当社の役員および従業員に適用する」となっているなら、選択肢は2つです。
- 適用範囲を広げる: 「当社が業務を委託する事業者およびその履行補助者を含む」と書き換え、契約で遵守を義務づける。既存の規程体系を大きく変えずに済みます
- 委託先向け別紙を新設する: 「AI ツール利用に関する委託先要求事項」を1枚の別紙として作り、契約書の添付資料に位置づける。委託先に渡す文書量が減り、交渉もしやすくなります
社内の規程改訂手続きに時間がかかる場合は、別紙方式のほうが早く着手できることが多くなります。全社的なガバナンス体制から整えたい場合は、生成AIガバナンスの構築ステップもあわせてご確認ください。
規程・契約・確認シートへの仕分け表
次に、5項目を3つの文書に仕分けます。以下は仕分けの例です。自社の契約書の構成に合わせて調整してください。
確認項目 | 社内規程に書く | 契約・NDAに書く | 確認シートで聞く |
|---|---|---|---|
1. 使用ツールと入力情報の線引き | 承認済みツールリストの維持責任、情報区分ごとの入力可否 | 承認外ツールの使用禁止、承認手続きの遵守 | 使用製品・プラン・テナント、除外設定の有無 |
2. 学習利用のオプトアウトとプラン設定 | 確認の実施義務と頻度 | 発注者の求めに応じた設定状況の開示 | 学習利用設定の状態、証跡の提出可否 |
3. 契約と規程の切り分け | 委託先選定・契約時のチェック実施 | 入力制限、利用申告、非侵害の表明、再委託 | 再委託の有無と再委託先の管理方法 |
4. 権利とOSSライセンス | ライセンス確認工程の社内担当 | 権利帰属、非侵害の表明保証、OSS開示 | 公開コード一致ブロックの設定、依存スキャンの実施状況 |
5. レビュー・記録・連絡 | インシデント受領時の社内対応手順 | レビュー体制、記録の保存期間、報告義務と時限 | 確認者の体制、記録の保存方法、連絡先 |
この表を埋めていくと、「社内規程に書き足すべきこと」が思ったより少ないことが見えてきます。ボリュームの大半は契約側と確認シート側に寄るためです。完璧な規程を作ろうとして止まっていた場合、この仕分けだけで着手のハードルが下がります。
なお、社内で合意を取る際は、公的なガイドラインを土台に置くと議論が進みやすくなります。経済産業省・総務省が公開している「AI事業者ガイドライン」は、AI に関わる主体を「AI開発者」「AI提供者」「AI利用者」に整理し、それぞれが取り組むべき事項を共通の指針としてまとめたものです。最新版は2026年3月31日に公表された第1.2版で、AI エージェントやフィジカル AI に関する記述の追加、AI によるリスクの記載の見直しが行われています（経済産業省: AI事業者ガイドライン（第1.2版）、経済産業省: AI事業者ガイドライン検討会）。委託先の AI コーディングツール利用は、自社が「AI利用者」として担う責務の範囲に入ります。エージェント機能に関する記述が追加された点も、前述した自動実行の挙動を社内で説明する際の土台になります。自社ルールの構成をこうした公的文書に対応づけておくと、監査対応の説明もしやすくなります。
委託先への確認シートを作り、既存案件から適用する
3ステップ目は、確認シートを作って実際に回すことです。新規案件は契約締結時に組み込めますが、既存案件は契約が動いている最中です。現実的には、次の順で進めます。
- 確認シート（1枚、10問程度）を作り、まず現在進行中の案件に情報提供のお願いとして送る
- 回答をもとに、リスクが高い案件（個人情報・本番データを扱う案件）から個別に相談する
- 契約書への条項追加は、次回の契約更新のタイミングに合わせる
契約更新を待たずに全案件へ条項を追加しようとすると、交渉が同時多発して止まります。確認シートによる事実把握を先行させ、契約は更新サイクルで置き換えていくほうが、結果的に早く全体をカバーできます。
改訂サイクルと責任者を決める
最後に、見直しの仕組みを決めます。AI ツールの仕様やポリシーは短期間で変わるため、一度作ったルールは前提が崩れます。次の3点を決めておいてください。
- 改訂サイクル: 半期または年次での定期見直し
- 改訂責任者: 情報システム部門の誰が改訂案を作り、誰が承認するか
- 臨時改訂の条件: 承認済みツールのポリシー変更や、新しいツールの利用申請があった場合
「誰が見直すか」が決まっていないルールは、1年後には形骸化します。改訂責任者を決めるところまでを、最初の作業に含めてください。
まとめ｜AIコーディングツールの社内ルールは適用範囲の見直しから始める
外注先の AI コーディングツール利用に対して、発注者が確認すべき5項目を振り返ります。
- 使用ツールと入力してよい情報の線引きを決める: 承認単位は「製品名＋プラン＋テナント」。入力可否は情報区分ごとに表で示す
- 学習利用のオプトアウトとプラン設定を確認する: プランによって扱いが変わるため、設定値を証跡として受け取る
- 契約・NDAに書くことと社内ルールに書くことを切り分ける: 規程は自社従業員、委託先は契約。作業方法の指示ではなく成果物・情報の取扱いへの要求として書く
- 生成コードの権利とOSSライセンスの扱いを決める: 公開コード一致のブロック、依存ライセンスのスキャン、表記確認を運用条件にする
- レビュー・記録・インシデント連絡の運用を決める: 確認者の明示、記録の保存、連絡先と時限を先に決めておく
着手の順番としては、適用範囲の確認 → プラン・設定の確認 → 契約への反映 → 運用ルールの整備が進めやすい流れです。最初の2つは既存文書を開いて確認シートを送るだけで完了し、それだけでも「委託先の AI 利用状況を把握し、要求事項を整理中です」と説明できる状態になります。
完璧な規程を最初から作る必要はありません。確認シート1枚から始めて、回答を見ながら要求事項を具体化し、契約更新のタイミングで条項に反映していく。この進め方であれば、今週中にでも最初の一歩を踏み出せます。
社内の生成AI利用ルールをこれから整備・改訂される方向けに、ルール策定の手順と展開テンプレートをまとめた資料をご用意しています。社内で ChatGPT を使い始めるための実践ガイドからダウンロードいただけます。
関連情報
フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド
この資料でわかること
業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。
こんな方におすすめです
- フリーランス新法への対応状況を社内で点検したい企業担当者
- 業務委託契約書・NDAの記載事項を確認したい法務担当者
- 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 委託先のAIコーディングツール利用を全面禁止にすれば、社内ルールを整備しなくても済むのではないですか？
禁止しても委託先の開発環境まで検知する手段はなく、実効性を確保するには結局、本記事の確認項目と同じ内容を契約・確認シートに落とし込む必要があります。禁止でも整備の手間は変わらないため、使われる前提で進める方が現実的です。
- 委託先がすでに個人プランでAIコーディングツールを使っていることが分かった場合、どう対応すればよいですか？
まず学習利用オプトアウトの設定状況を確認し、可能であれば法人プラン（Business/Enterprise 等）への切り替えを求めます。切り替えが難しい場合は、対象の情報区分を限定するなど暫定的な運用条件を設けて段階的に是正します。
- 法務が専任でない会社でも、この5項目を自社だけで整備できますか？
確認シートの作成や社内規程の適用範囲見直しは自社だけで着手できます。契約・NDA条項の条文化は法的判断を伴うため、確認シートで実態を把握したうえで、条文化の段階のみ弁護士等の専門家に確認する進め方がおすすめです。
- すでに契約が動いている既存案件には、いつから5項目を適用すればよいですか？
確認シートによる事実把握は契約更新を待たずに今すぐ送付できます。契約書・NDAへの条項追加は交渉が同時多発して停滞しないよう次回更新時に反映しつつ、既存案件のリスクは確認シートの回答をもとに運用ルールで先行して是正するのが現実的です。
- 委託先が確認シートに正直に回答してくれるか不安です。どう運用すればよいですか？
全面禁止ではなく、承認済みツール・プランの範囲で例外を認める構成にすると申告するメリットが生まれます。インシデント報告でも責任追及より第一報の早さを優先する方針を明記すると、正直な回答が上がりやすくなります。
