ベンダーから届いた提案書に「生成AIを活用した開発体制」と書かれている。期待できそうな一方で、入力したデータがどう扱われるのかについては一行も触れられていない。稟議書の情報管理の欄を書こうとして手が止まり、経営層から「うちのデータがAIの学習に使われたりしないよな」と聞かれて、その場で答えられなかった。AI 機能を含むシステム開発を外部に発注するとき、こうした場面は起こりうるものです。
困るのは、調べても欲しい答えが出てこないことです。「AI オプトアウト」で検索すると、ほとんどが ChatGPT の設定画面をどう操作するかという手順の記事です。自分で AI ツールを使う人には役立ちますが、発注する側が委託先に対して何を確認すればよいのかは書かれていません。さらに「オプトアウト」という語は個人情報保護法にも登場するため、同じ言葉なのか違う言葉なのかという段階で迷ってしまいます。
この状態を抜け出す道筋は、実はそれほど複雑ではありません。まず「オプトアウト」という語を正しく切り分けて、ベンダーと会話するための共通言語を持つこと。次に、発注という取引のなかで入力データの学習利用が起こりうる場面を分解して、確認すべき対象を特定すること。そして、確認した内容を口頭の約束ではなく書面の証跡と契約条項に変えること。この3段階を踏めば、「確認済み・記録済み」と社内に説明できる状態まで到達できます。
本記事では、AIのオプトアウトの意味と混同しやすい他制度との違いを整理したうえで、AI開発の発注で学習利用が問題になる3つの場面、発注前にベンダーへ確認する7つの項目、委託契約でオプトアウトを担保する条項の考え方、そしてオプトアウトだけでは埋まらないリスクと補完策までを順に解説します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
AIのオプトアウトとは｜入力データを学習に使わせないための設定・申し出
AIのオプトアウトとは、AIサービスに入力したデータを、そのサービス提供者がモデルの学習（再学習・改善）に利用することを拒否する設定、または拒否する旨の申し出を指します。「学習オプトアウト」とも呼ばれます。英語の opt out は「抜ける」という意味で、既定では対象に含まれている状態から、利用者の意思表示によって外れるという構図を表しています。
ここで押さえておきたいのは、オプトアウトが対象としているのは「入力データがモデルの中身に取り込まれるかどうか」という一点だという事実です。入力したデータがサービス提供者のサーバーに一定期間保存されるかどうか、保存されたデータを人間が閲覧しうるかどうかは、オプトアウトとは別の論点として扱われます。この区別が曖昧なまま「オプトアウトしているので安心です」という説明を受け入れてしまうと、本来確認すべきだった保存やレビューの話が抜け落ちます。
発注の場面に引き寄せると、オプトアウトとは「委託先が自社のデータをAIに入力したとき、そのデータが委託先の使うAIサービスのモデルに取り込まれないようになっているか」を問う言葉になります。モデルに取り込まれたデータは、理論上、別の利用者への出力に影響を与える可能性があります。自社の設計思想や未公開の業務ロジックが、まったく無関係の第三者の手元に断片として現れうるということです。この可能性を遮断する最初の一手がオプトアウトの確認にあたります。
なお、そもそも AI が何をどう学習しているのかという前提から整理したい場合は、AI学習データとは？発注者が知っておくべき基礎と品質管理のポイントも参考になります。本記事では学習データそのものの中身には立ち入らず、発注側がどう確認するかに絞って進めます。
学習オプトアウトとオプトインの違い
オプトアウトとオプトインは、同意の初期状態が逆になっている仕組みです。
方式 | 初期状態 | 利用者の操作 | 操作しなかった場合 |
|---|---|---|---|
オプトイン | 学習に使われない | 同意して初めて学習対象になる | 学習に使われない |
オプトアウト | 学習に使われる | 拒否して初めて学習対象から外れる | 学習に使われ続ける |
この違いが実務上重要なのは、「何もしなければどうなるか」が正反対だからです。オプトイン方式のサービスであれば、担当者が設定を忘れていても学習には使われません。一方、オプトアウト方式のサービスでは、設定を忘れた瞬間から入力データが学習対象になります。
一般に、消費者向けの無料プラン・個人向け有料プランではオプトアウト方式（既定で学習対象）が採られることがあり、法人向けプランや API ではオプトイン方式（既定で学習対象外）が採られる傾向があります。ただしこれはあくまで傾向であり、サービスやプランの版によって異なります。確認の際は「オプトアウトしていますか」ではなく「このサービスのこのプランは、既定で学習対象ですか、対象外ですか。対象なら、どの設定でいつ外しましたか」という聞き方をすると、相手の理解度も含めて測れます。
個人情報保護法の「オプトアウト制度」とは別物
検索して混乱しやすいのが、個人情報保護法にも「オプトアウト」という言葉が存在する点です。こちらは個人情報保護法第27条第2項に基づく制度で、本人の同意を得ずに個人データを第三者へ提供する場合に、あらかじめ本人に通知等を行ったうえで個人情報保護委員会へ届け出る、という手続きを指します（個人情報保護委員会「オプトアウト届出」）。
両者はまったく別の話です。
項目 | AIの学習オプトアウト | 個人情報保護法のオプトアウト制度 |
|---|---|---|
対象 | AIサービスへの入力データ全般（個人情報に限らない） | 個人データ |
誰が誰に対して行うか | 利用者がAIサービス提供者に対して拒否する | 個人データを第三者提供する事業者が、本人に通知し委員会へ届け出る |
根拠 | 各AIサービスの利用規約・設定 | 個人情報保護法第27条第2項 |
止めたいこと | モデルへの取り込み | 本人の同意なき第三者提供 |
稟議書や契約書で「オプトアウト対応済み」とだけ書くと、読み手によってどちらの意味にも取れてしまいます。社内文書では「生成AIへの入力データを学習に利用しない設定（学習オプトアウト）を適用済み」のように、何を止めたのかを明記すると誤解が生じません。
マーケティング文脈でもメール配信や Cookie の「オプトアウト」という語が使われており、検索結果にはこれらが混在します。語の意味は文脈ごとに固定されるため、ベンダーとの会話の冒頭で「ここでいうオプトアウトは、入力データをモデルの学習に使わせない設定のことです」と前置きしておくと、以降のやり取りが噛み合います。
オプトアウトは設定時点以降にしか効かない
もう一つの重要な性質は、オプトアウトが将来に向かってのみ効力を持つという点です。設定をオフにしたタイミング以降の入力は学習対象から外れますが、それ以前に入力したデータが自動的に取り消されるわけではありません。たとえば ChatGPT のデータコントロールにおける「Improve the model for everyone」の設定は、オフにすると以降の新しい会話が学習に使われなくなる、という形で説明されています（OpenAI「Data controls in ChatGPT」）。
発注の場面では、この性質が次の問いにつながります。「ベンダーは、いつからその設定を適用していたのか」。プロジェクト開始から3ヶ月が経ってから慌てて設定したのであれば、その3ヶ月間に入力された資料は別の扱いになります。すでに入力してしまったデータについては、サービス提供者への削除申請やデータ削除リクエストといった別の手続きが必要になる場合があります。
したがって確認すべきは「設定していますか」という現在形の質問だけでは足りず、「いつから適用していますか」「適用前に入力されたデータはありますか」「あるなら、どのような対応をしましたか」という時間軸の質問まで含める必要があります。発注前の段階であれば、契約開始前に設定完了を確認し、その時点を起点として記録しておくのが最も単純です。
AI開発の発注で入力データの学習利用が問題になる3つの場面
「AIに自社データが流れる」と一口に言っても、発注という取引のなかでは発生場所が複数あります。場所が特定できていないと質問も作れないため、まず地図を描きます。発注の局面で学習利用が問題になるのは、主に次の3つの場面です。
# | 場面 | 誰が入力するか | 対象になるデータ | 契約上の受け皿 |
|---|---|---|---|---|
1 | 開発作業中の生成AI利用 | ベンダーの開発メンバー | 仕様書・設計書・既存コード・議事録 | 秘密保持条項、AI利用に関する特約 |
2 | 構築したシステムからのAPI呼び出し | 自社のエンドユーザー（本番運用時） | 本番の業務データ・顧客情報 | 要件定義書、システム仕様、個人データの取扱い条項 |
3 | 学習・検証用データの提供 | ベンダー（自社から受領後） | 自社が提供した業務データ・教師データ | データ提供に関する条項、目的外利用禁止条項 |
この3つは、確認する相手も、契約上の受け皿も、起きるタイミングもそれぞれ違います。順に見ていきます。
開発作業中にベンダーが AI へ自社の仕様書・設計書・コードを入力する
現在、ソフトウェア開発の現場では AI コーディング支援ツールやチャット型の生成AIが日常的に使われています。ベンダーの開発者が設計レビューのために仕様書を貼り付ける、既存システムの改修で古いコードを読ませる、打ち合わせの議事録を要約させる。いずれも生産性の観点では合理的な行為ですが、入力されるのは発注側から預かった情報です。
この場面の特徴は、発注側から見えにくいことです。成果物の品質には現れませんし、ベンダーの作業環境は通常こちらの管理下にありません。提案書に「生成AIを活用」とあれば分かりやすいのですが、書かれていないからといって使っていないとは限りません。むしろ「個々の開発者が自分の判断で使っている」状態のほうが、組織として統制されていないぶんリスクが高くなります。
確認すべきは、ベンダー側に生成AI利用に関する社内規程があるか、どのサービスを承認しているか、承認外のサービス利用をどう防いでいるかです。「会社として許可しているツールはこれとこれで、学習オプトアウト済みの法人契約です」と即答できる組織と、「特にルールはないが、常識的に判断している」と答える組織では、信頼できる水準が大きく異なります。
構築されるシステム自体が外部の AI API を呼び出し、本番データが社外へ出る
2つ目は、開発が終わった後の話です。納品されたシステムが外部の AI サービスを呼び出す設計になっている場合、本番稼働後に流れるのは実際の業務データです。問い合わせ対応を自動化するシステムなら顧客からの問い合わせ文面が、文書要約機能なら社内文書そのものが、API を通じて社外のサーバーへ送られます。
開発作業中の利用と違い、こちらは仕様として明確に定義できます。どのサービスのどのエンドポイントを呼ぶのか、送信するデータ項目は何か、個人情報を含むのか含まないのか。要件定義の段階でこれらを決めておけば、後から「そんなデータまで送っていたのか」という事態を避けられます。
逆に言えば、要件定義書に「AI による要約機能」とだけ書かれていて、裏側で何を呼んでいるかが書かれていない状態は危険です。発注側が仕様として明示していなければ、ベンダーは開発しやすい方法を選びます。送信データ項目の一覧と、呼び出し先サービスの名称・プランを、仕様書に記載させるところまでを発注側の責任範囲として設計してください。
この場面で発生するデータの扱いは、運用フェーズに入ってからも継続します。AI エージェントのような継続稼働型のシステムで発生するデータの二次利用については、AIエージェントの二次利用データとは？発注時に確認する7項目で運用面を含めて整理しています。
学習・検証用に提供した自社データが、ベンダー側の汎用モデル改善や他案件へ流用される
3つ目は、発注側が能動的にデータを渡す場面です。AI モデルのチューニングや精度検証のために、自社の過去データや業務データをベンダーへ提供することがあります。このデータは本来、当該プロジェクトのためだけに使われるべきものですが、ベンダー側が「ノウハウの蓄積」としてモデルや派生物を社内に残し、別の顧客向け案件で再利用する可能性があります。
これは外部の AI サービス提供者による学習ではなく、ベンダー自身による流用です。オプトアウトの設定をいくら確認しても防げません。契約で明示的に禁止するか、許諾の範囲を限定するしかない論点です。
実務では、提供データの利用目的を「本契約に基づく開発業務の遂行」に限定し、派生物（学習済みモデル・中間生成物・統計データを含む）の取扱いまで明記する形が採られます。ベンダー側が汎用的な知見の蓄積を望む場合もあるため、完全に禁止するか、匿名化・統計化された形であれば許容するか、許容する代わりに価格を調整するかといった交渉になります。いずれにせよ、曖昧なまま進めないことが重要です。
AIサービスのオプトアウト既定値は契約形態で変わる
ベンダーから「学習に使われないサービスを使っています」と説明されたとき、それを検証するための観点を持っておきます。同じサービス名でも、契約形態によって既定値が変わるためです。
ここで扱う内容は本記事執筆時点（2026年10月）の一般的な傾向であり、各サービスの規約は改定されます。実際の確認にあたっては、必ず当該サービスの最新の利用規約・データ処理条項を参照してください。
消費者向けプランは既定で学習 ON のことがある
一般消費者向けに提供されている対話型 AI サービスの無料プランや個人向け有料プランでは、入力内容がモデル改善に利用される設定が既定で有効になっていることがあります。利用者が設定画面から明示的にオフにして初めて、学習対象から外れます。
ChatGPT の場合、設定内の「データコントロール」から「Improve the model for everyone」をオフにすることで、以降の会話が学習に使われなくなります（OpenAI「Data controls in ChatGPT」）。操作自体は数クリックで完了しますが、問題は「誰のアカウントで、いつ設定したか」が組織として把握されているかどうかです。
発注の文脈では、ベンダーの開発者が個人アカウントの消費者向けプランを使っている状態が最も管理しづらい形になります。設定が各人任せになり、退職時の引き継ぎもなく、監査も効きません。ベンダーが「個人の裁量で使っている」と答えた場合は、それだけで確認が必要な水準だと判断できます。
API・法人向けプランは既定で学習対象外が主流だが、規約の版で変わる
一方、API や法人向けプランでは、顧客の入力データをモデル学習に利用しないことが既定とされているケースが主流です。
OpenAI は、API 経由で送信されたデータを既定でモデルの学習に使用しないこと、および ChatGPT Team・ChatGPT Enterprise を含む法人向け製品でも同様であることを公開しています（OpenAI「Data controls in the OpenAI platform」）。Microsoft も、Azure OpenAI（Microsoft Foundry）において顧客のプロンプト・応答・埋め込み・トレーニングデータを基盤モデルの学習に使用しないことを明記しています（Microsoft Learn「Azure が販売する Foundry モデルのデータ、プライバシー、セキュリティ」）。
ただし「主流だから大丈夫」と一般論で片づけてはいけません。確認すべきは、ベンダーが使っているのが本当にその契約形態なのか、という点です。「API を使っています」という説明の裏で、実際には開発者が検証目的で Web 版を併用していることがあります。また、ファインチューニングや追加学習を行う構成では、データの流れ方が通常の推論とは異なります。サービス名だけでなく、契約プラン名・エンドポイント・利用形態（推論のみかチューニングを含むか）まで分解して確認してください。
「学習しない」と「保存しない」は別物
最後に、この章で最も見落とされやすい論点です。モデルの学習に使わないことと、データを保持しないことは別の約束です。
多くの AI サービスは、不正利用の監視や法令遵守のために、入力データと出力結果を一定期間サーバーに保存します。保存されたデータは、不正利用の疑いがある場合に限って人間が確認することがあります。
OpenAI は API について、大半のエンドポイントで不正使用監視のログを最大30日間保持すると公開しており、より厳格な要件を持つ顧客向けには、ログから顧客コンテンツを除外するゼロデータ保持（Zero Data Retention）の選択肢を用意しています（OpenAI「Data controls in the OpenAI platform」）。Microsoft も Azure OpenAI（Microsoft Foundry）の不正使用監視について、人的レビュー用にプロンプトと応答を保存するデータストアを設けており、人間のレビュー担当者がアクセスできるのは不正使用監視システムによってフラグが付けられた場合、または不正利用が疑われる使用パターンの一部である場合に限られると説明しています。あわせて、承認を受けた顧客にはこの保存と人的レビューを行わない「変更済み不正使用監視」が適用されるとしています（Microsoft Learn「Azure が販売する Foundry モデルのデータ、プライバシー、セキュリティ」）。
つまり「学習には使われません」という回答は正しくても、「データは一切残りません」という意味にはなりません。確認項目としては、次の3つを分けて聞く必要があります。
- 学習利用: 入力データがモデルの学習に使われるか
- 保存期間: 入力データがサービス提供者側に何日間保存されるか
- 人的レビュー: 保存されたデータを人間が閲覧しうるか、どのような条件でか
さらに、データが処理・保存される地理的な場所（リージョン）も別の論点です。国内のデータを国外のサーバーで処理する構成では、個人データの越境移転に関する検討が必要になる場合があります。これらをまとめて「セキュリティは大丈夫です」で済ませないことが、確認の質を分けます。
発注前にベンダーへ確認する7つの項目
ここまでの整理を、打ち合わせでそのまま使える形にまとめます。経済産業省は2025年2月18日に「AIの利用・開発に関する契約チェックリスト」を公表しており、AI サービスを利用する事業者が契約時に確認すべき点を、提供するデータ（インプット）側と生成物（アウトプット）側に分けて整理しています（経済産業省「AIの利用・開発に関する契約チェックリスト」を取りまとめました）。以下の7項目は、このうちインプット側の論点を中心に据えたうえで、成果物の権利面というアウトプット側の論点を1つ加えて、発注実務で使える質問文の形に落としたものです。
7項目の一覧
# | 確認項目 | ベンダーへの質問文 | 期待する回答の形式 | 残すべき証跡 |
|---|---|---|---|---|
1 | 使用する AI サービス名と利用工程 | 本プロジェクトで使用する生成AI・AI支援ツールをすべて挙げてください。それぞれどの工程で使いますか | サービス名の列挙と、要件定義・設計・実装・テスト等の工程の対応 | 回答書（サービス名と工程の一覧表） |
2 | 契約プラン・エンドポイントと学習利用の既定値 | 各サービスの契約プラン名と利用形態（Web版／API／法人プラン）を教えてください。入力データの学習利用は既定でどうなっていますか | プラン名の明示と、既定値が「対象」か「対象外」かの明言 | 利用規約・データ処理条項の該当箇所、設定画面のスクリーンショット |
3 | 入力データの保存期間と人的レビューの有無 | 入力データはサービス提供者側に何日間保存されますか。人間が閲覧しうる条件はありますか | 保存期間の日数と、人的レビューの有無・条件 | サービス提供者の公開ドキュメントの該当箇所 |
4 | 処理・保存されるリージョン | データはどの国・地域のサーバーで処理・保存されますか | 国名またはリージョン名の明示 | 構成図またはサービス設定の記録 |
5 | 再委託先での利用可否 | 再委託先はいますか。再委託先も同じ生成AI利用ルールに従いますか。どう担保していますか | 再委託先の有無と、遵守させる具体的な方法 | 再委託先一覧、再委託契約の該当条項の写し |
6 | 成果物への AI 生成物の混入状況 | 納品するコード・ドキュメントに AI が生成した内容は含まれますか。ライセンス面の確認はどう行っていますか | 含まれる箇所の範囲と、権利確認の手順 | 回答書、社内レビュー手順の説明資料 |
7 | 設定・規約の証跡の提示方法 | 上記の内容を書面で提示いただけますか。どの形式で提出可能ですか | 提出可能な資料の種類と提出時期 | 提出された資料一式 |
項目1から5までがインプット側、すなわち自社のデータがどこへ流れ、どう扱われるかに関する確認です。項目6だけはアウトプット側の論点で、納品物に AI 生成物が混入した場合の権利関係を扱います。発注実務では両者を同じ場で聞くことになるため、ひとつのリストにまとめています。項目7は、1から6の回答を記録に変えるための手続き確認です。
7項目を一度に投げると相手が身構えることがあります。打ち合わせの場では1から4を口頭で確認し、5から7を書面で依頼する、という分け方が進めやすい形です。
口頭回答を証跡に変える
打ち合わせで良い回答が得られても、議事録に「学習には使っていないとの説明あり」と一行書いただけでは、後から検証できません。回答を証跡に変える作業までを確認のプロセスに含めます。
証跡には、強さの異なる3つの段階があります。
- ベンダーの回答書: 確認項目に対する回答を、ベンダー名義の文書として提出してもらう形式。最も手軽ですが、内容の裏付けは取れていません
- 設定画面のスクリーンショット・管理コンソールの表示: ベンダーが実際に適用している設定を画像として残す形式。撮影時点の状態しか担保できませんが、回答書より具体的です
- サービス提供者の公開ドキュメント・利用規約の該当箇所: サービス側の約束として公開されている記述。版の明示（取得日・文書バージョン）とセットで保存します
実務上は、1を基礎として2と3で裏付ける構成が現実的です。公的機関でも同様の運用が始まっています。大阪市は業務受託事業者向けの生成AI利用ガイドラインにおいて、生成AIを利用する場合は入力情報を学習しない設定（オプトアウト）で利用することを要件とし、所定の様式による確認を求めています（大阪市「業務受託事業者等向け生成AI利用ガイドライン」）。口頭確認ではなく書面で確認するという実務が、すでに調達の現場で動いているということです。民間企業の発注でも、同じ水準を求めることに無理はありません。
情シスと法務の役割分担
7項目を誰が確認するかを決めておかないと、「法務が見ているはず」「情シスが技術的に確認しているはず」という相互の思い込みで、結局誰も見ていない状態が生まれます。目安としての分担は次のとおりです。
項目 | 主担当 | 補足 |
|---|---|---|
1〜4（サービス構成・既定値・保存・リージョン） | 情報システム部門 | 技術仕様の読解が必要。回答の妥当性を判断できるのは技術側 |
5（再委託先） | 法務・調達部門 | 契約の連鎖構造の問題。情シス単独では担保手段を設計できない |
6（成果物へのAI生成物混入） | 法務部門（情シスと協働） | 権利関係の判断が中心だが、どこに混入しうるかの特定には技術知識が要る |
7（証跡の提示） | 調達・発注担当 | 提出依頼と受領管理。保管場所とレビュー時期を決める |
小規模な組織で両部門を兼務している場合は、技術的妥当性のチェックと契約上の担保のチェックを別々の作業として時間を分ける、という形でも機能します。重要なのは、どちらかに吸収されて片方が抜け落ちることを防ぐことです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
AI開発の委託契約でオプトアウトを担保する条項の考え方
確認した内容を契約に落とす段階です。ここでは条項の文案そのものではなく、どの論点をどの条項で受けるかという対応関係を整理します。実際の文案の採用にあたっては、自社の取引実態と事業リスクを踏まえ、弁護士または法務部門への相談を前提としてください。
なお、AI 固有の論点の外側にある委託契約一般のセキュリティ要件については、システム開発の外注契約で押さえる情報セキュリティ条項チェックリストにまとめています。この章では、その上に AI 特有の論点を重ねる形で読み進めてください。
秘密保持条項・目的外利用禁止条項だけでは学習利用を止めきれない理由
多くの開発委託契約には、すでに秘密保持条項と目的外利用禁止条項が入っています。「これで足りるのではないか」と考えたくなりますが、AI の学習利用に関しては不十分になりがちです。理由は3つあります。
第一に、秘密保持条項が規律するのは通常「第三者への開示」です。ベンダーが社内の開発者の判断で AI サービスに入力する行為が「開示」にあたるかは、文言次第で解釈が分かれます。クラウドサービスの利用は従来から秘密保持義務の例外として整理されることも多く、AI サービスもその延長と受け取られる余地があります。
第二に、目的外利用禁止条項の「目的」は通常、当該プロジェクトの遂行と定義されます。開発作業の効率化のために AI を使う行為は、まさに目的内の行為です。入力した結果としてモデルに取り込まれることまでを禁止するには、別の言葉が必要になります。
第三に、秘密情報の定義に該当しないデータが対象外になります。「秘密」と明示していない設計資料や、公開情報を組み合わせた分析結果などは、秘密保持条項の網から漏れます。
したがって、「本件に関して受領した情報を、生成AIその他の機械学習モデルの学習・再学習・改善に利用し、または利用させてはならない」という趣旨を独立した条項として明記するのが安全です。あわせて、利用する場合の条件（事前の書面承諾、学習オプトアウトが適用されたサービスに限る、等）を定めておくと、ベンダーの業務効率を過度に損なわずに統制できます。生成AIの利用を全面禁止すると、現実には隠れて使われるだけという結果になりかねません。条件付きで認める設計のほうが、実効性が高くなります。
再委託・再々委託への遵守義務の連鎖
システム開発では、ベンダーがさらに別の企業や個人事業主へ作業を委託することが珍しくありません。契約相手との間で AI 利用のルールを定めても、再委託先に届いていなければ実効性がありません。再々委託まで発生すれば、発注者から見える範囲はさらに遠のきます。
契約上の受け皿としては、次の3点を組み合わせる形が基本です。
- 再委託の事前承諾制: 再委託を行う場合は発注者の事前の書面承諾を要する、とする
- 同等義務の承継: 再委託先に対して、本契約と同等以上の義務（AI 学習利用の禁止を含む）を課す契約を締結する義務をベンダーに負わせる
- ベンダーの責任: 再委託先の行為についてベンダーが発注者に対して責任を負う、と明記する
実務では、承諾制だけを入れて同等義務の承継を書き忘れるケースがあります。承諾しても中身が担保されなければ意味がないため、3点はセットで設計してください。加えて、再委託先の一覧を定期的に提出させる運用を入れておくと、契約期間中に体制が変わった場合にも気づけます。
フリーランスや小規模事業者が再委託先に含まれる場合、その事業者が個人アカウントの消費者向け AI サービスを使う可能性が相対的に高くなります。承諾の判断にあたっては、再委託先の生成AI利用体制まで確認対象に含めるのが望ましい運用です。
違反が判明したときの報告義務・是正措置・監査の受け入れ
禁止を定めるだけで、違反が起きたときの扱いを決めていない契約は多くあります。AI の学習利用は、起きてしまうと原状回復が困難な性質を持つため、発見と初動の設計が特に重要です。
契約に盛り込む要素は次のとおりです。
要素 | 内容 | 設計のポイント |
|---|---|---|
報告義務 | 禁止された利用が判明した場合、ベンダーは速やかに発注者へ報告する | 「速やかに」を具体的な時間（例: 判明後24時間以内）で定めると実効性が上がる |
報告内容の特定 | 入力された情報の範囲、入力日時、使用サービス、想定される影響 | 報告フォーマットを別紙で定めておくと初動が早い |
是正措置 | サービス提供者へのデータ削除申請、設定の是正、再発防止策の提出 | 削除申請が可能かはサービスによるため、できる範囲を事前に把握しておく |
監査の受け入れ | 発注者またはその指定する第三者による確認への協力義務 | 全面的な立入監査は現実的でないことが多い。書面による報告と設定画面の提示を中心に設計する |
契約解除・損害賠償 | 重大な違反時の解除権と賠償の範囲 | 既存の一般条項でカバーされることも多いため、重複に注意 |
監査条項については、発注者側に実施能力がなければ形骸化します。実際に運用するつもりがあるのか、年1回の書面報告で足りるのかを、契約前に自社内で決めておいてください。
経済産業省「AIの利用・開発に関する契約チェックリスト」の使い方
自社の確認項目を一から作るのは負担が大きいため、公的な整理を土台にするのが効率的です。経済産業省が2025年2月に公表した「AIの利用・開発に関する契約チェックリスト」は、AI の技術や法務に必ずしも習熟していない事業者を想定読者に含めており、法務部門だけでなく事業部門が初期検討を行う場面も対象としています（経済産業省のプレスリリース、チェックリスト本体（PDF））。
使い方としては、次の順序が実務に馴染みます。
- チェックリストを読み、自社が提供するデータ（インプット）側の項目から、自社案件に該当するものを抜き出す
- 抜き出した項目を、本記事の7項目のような質問文の形に書き換える
- 質問文を自社の調達フォーマット（RFP の付属資料、ベンダー回答様式）に組み込む
- 案件ごとの回答を蓄積し、次回以降の標準様式として更新する
一度この様式を作ってしまえば、案件ごとにゼロから考える必要がなくなります。稟議の情報管理欄も、様式への回答を添付する形で埋められるようになります。
オプトアウトを設定しても残るリスクと補完策
確認と契約を整えても、それで完結するわけではありません。オプトアウトはモデルへの取り込みを止める仕組みであって、情報が社外のサーバーを経由すること自体を止めるものではないからです。残るリスクと、現実的な補完策を3つ挙げます。
そもそも機密情報・個人情報を入力させない運用ルール
最も確実なのは、入力そのものを制限することです。オプトアウトが適用されていても、通信経路の問題、サービス提供者側の事故、設定ミスといった可能性はゼロになりません。入力されなければ、これらのリスクは発生しません。
運用ルールとして定めるのは、入力してよい情報と入力してはならない情報の線引きです。典型的には、個人情報・顧客の秘密情報・未公開の経営情報・認証情報は入力禁止とし、それ以外は許可するという形になります。ただし「機密情報は入力禁止」とだけ書いたルールは、現場で判断がつかず機能しません。具体例を添えてください。
扱い | 例 |
|---|---|
入力禁止 | 顧客の氏名・連絡先を含むデータ、本番データベースの抽出結果、APIキー・パスワード、未公開の価格表 |
マスキングのうえ入力可 | 氏名を記号に置換した問い合わせ文面、ダミー値に置き換えたサンプルデータ |
入力可 | 公開済みの製品仕様、一般的な技術的質問、自社で作成した汎用的な設計パターン |
マスキングを前提とする場合、誰がマスキングを行い、誰が確認するかまで決めておかないと、作業の省略が常態化します。マスキング済みデータを事前に用意してベンダーへ渡す運用にすると、現場の判断を減らせます。
閉域・専用環境という選択肢とコストのトレードオフ
扱うデータの機微性が高い場合、外部のパブリックな AI サービスを使わない構成を選ぶ選択肢があります。クラウド事業者が提供する専用環境を使う、自社のネットワーク内にモデルを配置する、といった形です。この構成では、データが社外のサービス提供者へ渡らないため、学習利用の懸念自体が小さくなります。
一方でコストは上がります。専用環境の利用料、構築・運用の工数、モデルの更新への追従、必要となる技術者のスキルセット。いずれも通常の API 利用と比べて負担が増えます。また、利用できるモデルの選択肢が狭まったり、最新モデルの提供が遅れたりすることもあります。
判断の目安は、扱うデータが漏洩した場合の影響の大きさです。事業の継続に関わる情報や、法令上の厳格な管理義務がある情報を扱うのであれば、追加コストを払う合理性があります。逆に、公開情報の整理や社内文書の体裁を整える程度の用途であれば、学習オプトアウトを適用した法人向けサービスで十分というケースも多くあります。全社一律で決めるのではなく、用途ごとに水準を分ける設計が現実的です。
自社の生成AI利用ガイドラインと委託先ルールの整合
最後に見落とされがちなのが、社内ルールと委託先ルールのちぐはぐさです。社内では生成AIの利用を厳しく制限している一方、委託先には何も求めていない、という状態は珍しくありません。これでは、社内で禁止した行為が委託先で行われるだけになります。
逆のパターンもあります。委託先に厳格な要件を課しておきながら、自社の社員が個人アカウントで無規制に使っている状態です。この場合、ベンダーに対する要求の正当性が揺らぎますし、何より自社側から情報が出ていきます。
整合を取る作業は、次の手順で進められます。
- 自社の生成AI利用ガイドラインを確認する（なければ、まず作る）
- ガイドラインの要件のうち、委託先にも適用すべき項目を抽出する
- 抽出した項目を、委託先向けの要件文書として整理する
- 新規契約時は契約書・RFP に組み込み、既存契約については覚書または次回更新時の反映を検討する
公的機関では、職員向けのガイドラインと業務受託事業者向けのガイドラインを別文書として整備する例が見られます。先に紹介した大阪市の業務受託事業者等向けガイドラインもその一つです。自社でも、社内向けと委託先向けを別文書に分け、内容を対応させる形が管理しやすくなります。
まとめ｜AIのオプトアウト確認を発注プロセスに組み込む
AIのオプトアウトとは、入力したデータを AI サービス提供者がモデルの学習に使うことを拒否する設定・申し出のことです。個人情報保護法の第三者提供に関するオプトアウト制度とは別の話であり、設定した時点以降にしか効力が及びません。この3点を押さえておくだけで、ベンダーとの会話の精度が変わります。
AI 開発の発注では、学習利用が問題になる場面が3つあります。開発作業中にベンダーが自社の資料を AI に入力する場面、納品されたシステムが本番データを外部 AI API へ送る場面、そして学習・検証用に提供したデータがベンダー側で流用される場面です。それぞれ確認する相手も契約上の受け皿も異なるため、分けて扱います。
確認の実務では、使用サービスと工程、契約プランと既定値、保存期間と人的レビュー、リージョン、再委託先、成果物へのAI生成物の混入、証跡の提示方法という7項目を質問文の形で持ち込みます。得られた回答は、ベンダーの回答書・設定画面の記録・サービス提供者の公開ドキュメントという3段階の証跡に変換します。公的機関の調達では、すでに所定の様式による書面確認が運用されています。
契約では、秘密保持条項や目的外利用禁止条項とは別に、機械学習への利用を禁止する条項を独立して設けます。再委託先への同等義務の承継、違反時の報告義務と是正措置までを一体で設計し、文案の採用は法務・弁護士への相談を前提としてください。そのうえで、機密情報を入力させない運用ルール、必要に応じた閉域環境の選択、社内ガイドラインとの整合という補完策を重ねます。
次に取る一手として現実的なのは、次回のベンダー打ち合わせに7項目を持ち込むことです。すべてに完璧な回答が返ってこなくても構いません。どの項目に即答できて、どの項目で詰まったかが分かるだけで、そのベンダーの統制水準が見えます。そして「確認した」という事実が記録として残り、稟議の情報管理欄を埋められるようになります。
関連情報
AI 開発の発注にあたって社内で整理しておきたい観点をまとめたお役立ち資料をご用意しています。システム開発 完全チェックリストをダウンロードいただけます。
AI 機能を含むシステム開発の発注を検討中で、データの取扱い方針や要件の整理段階からご相談されたい場合は、お問い合わせフォームよりご連絡ください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- ベンダーが「オプトアウト済みです」と言えば、口頭の説明だけで発注して問題ありませんか。
口頭だけでは後から検証できないため、避けるのが安全です。ベンダー名義の回答書に加え、契約プランと設定内容が分かる画面や規約の該当箇所を書面で受け取り、版や取得日も記録したうえで稟議書の情報管理欄に添付してください。
- プロジェクトが始まってから、ベンダーの設定が遅れていたと分かった場合はどうすればよいですか。
まず設定の適用日と、それ以前に入力された資料の範囲をベンダーに特定・報告してもらってください。オプトアウトは遡って効かないため、必要に応じてサービス提供者へのデータ削除申請を求め、対応経過を記録に残します。
- ベンダーに生成AIの利用そのものを禁止したほうが安全ではないですか。
全面禁止は、実際には隠れて使われるだけになりかねず、統制が効きにくくなります。事前の書面承諾や学習オプトアウト適用済みサービスに限るといった条件付きで認め、その旨を独立した条項にするほうが実効性があります。
- 打ち合わせまで時間がない場合、最低限どの項目から確認すればよいですか。
使用するAIサービス名とプラン、学習利用の既定値、入力データの保存期間の3点を最優先で聞いてください。この3点にその場で即答できるかどうかで、ベンダーの情報統制の水準をおおよそ判断でき、残りの項目を書面依頼にするか見極められます。
- 法務部門が少人数でAIの契約論点に詳しくない場合、自社だけでどこまで進められますか。
確認項目の質問文づくりと、回答・証跡の収集までは情報システム部門だけでも進められます。ただし条項の文案を採用する段階では、自社の取引実態に合うかを含め、弁護士または法務部門に相談したうえで決めるのが安全です。
