業務委託で生成AIを使うときの契約・機密情報の注意点｜客先案件の実務

客先案件で生成AIを使う実務が抱える主なリスク

結論：客先案件で生成AIを使う最大のリスクは、機密情報の外部流出と契約違反の同時発生です。技術的な問題ではなく、契約と情報取扱いの問題として整理する必要があります。

生成AIサービスに入力したテキストは、サービスの種類と設定次第で学習データや運用ログとして扱われる可能性があります。個人向けプラン（無料版や個人契約の有料版）では、入力内容の取扱いがサービスによって異なり、モデル改善への利用可否・オプトアウトの初期状態も一様ではありません。客先の業務コードや設計書を送信すれば、その時点で「第三者への開示」に該当し得ると考えるのが安全側の判断です。特に秘密情報の定義が広い契約、第三者サービス利用に承認が必要な契約、クライアント規程で外部AI利用を制限している案件では該当しやすくなります。

学習データ利用による情報流出

結論：入力データを学習利用しない契約プランを使うのが基本です。

多くの主要サービスでは、法人向けプラン（Team/Enterprise/Business）やAPI経由の利用に対して、既定で入力データをモデル学習に使わない扱いが用意されています。ただし具体的な条件はサービスごとに異なるため、各サービスの法人向けドキュメントで最新の仕様を確認してください。個人向けの無料プラン・標準プランでは、設定変更やオプトアウト操作が必要な場合があります。

学習利用がオフになっても、運用ログとしての一時保存や不正利用検知目的での短期保管は残るケースがあります。「学習に使わない＝一切保持されない」ではない点に注意します。

NDAで禁じる第三者開示に該当するケース

結論：秘密情報を生成AIに送信する行為が「第三者開示」に該当するかは、契約書の定義次第で判断が分かれます。

NDAでは通常、秘密情報を「業務遂行に必要な範囲」に限定して利用でき、それ以外への開示は禁じられます。生成AIサービス提供者は法的には第三者に当たるため、送信＝開示と解釈する立場があります。契約書に「業務効率化ツールを含む第三者サービスへの入力を含む」といった明文があれば明確ですが、多くのNDAはそこまで書かれていません。

境界が曖昧な領域は、事前確認で潰しておくのが安全側の実務対応として広く採られています。

生成物の著作権・成果物帰属の曖昧化

結論：生成AIで作成したコードや設計書の著作権帰属は、業務委託契約と各サービス規約の双方で整理する必要があります。

多くの業務委託契約では、成果物の権利をクライアントに譲渡または利用許諾する条項が入ります。一方、生成AIの利用規約は「生成物の権利は利用者に帰属する」と定めるものが多いですが、他者の生成物と類似する可能性・学習元データの権利関係については免責しない書き方もあります。

成果物にAI生成部分が含まれる場合、その旨をクライアントに開示するかどうかも論点です。契約時に確認しておくと後日のトラブルを避けやすくなります。

セキュリティインシデント時の責任範囲

結論：入力データが原因で情報漏洩が起きた場合、生成AIサービス提供者ではなくフリーランス本人が一次的な責任を負うケースが多くなります。

主要な生成AIサービスの利用規約では、ユーザー側の入力内容に起因する損害を利用者側の責任とする条文構造が採られる例があります。責任制限条項により、補償額が利用料金を上限として限定される規約も見られます。契約時に責任制限条項を必ず確認し、事故が起きたときに生成AI提供者に補填を求める前提を持たない設計が現実的です。

ミニFAQ：客先案件のリスク

Q. 個人アカウントのChatGPT無料版で、クライアントのコードを一時的に使ってよいですか？

A. 契約で明示的に許諾されていない限り、避けるのが安全です。無料版は入力データの取扱いが法人向けプランと異なり、業務用途を想定した保護が用意されていないケースがあります。

Q. NDAに「生成AIへの入力」が書かれていない場合、勝手に使ってもよいですか？

A. 書かれていないから禁じられていない、とは限りません。「第三者開示」の定義次第で入力行為が該当する読み方があります。クライアントに確認するのが実務の基本です。

業務委託契約書・NDAで必ず確認する4つの条項

結論：契約書レビューで押さえるべき条項は、AIツール利用の可否・秘密情報の定義・成果物の権利帰属・データ利用のオプトアウトの4点です。

契約書の全文精査は現実的でない場合も多いですが、この4点は最低限のチェックポイントとして扱うのが安全です。以下、それぞれの見方を整理します。

AIツール利用の明示的許諾条項

結論：契約書に「生成AI利用可」「利用不可」「事前承認制」のいずれかが明記されているか確認します。

実務では、生成AI利用の可否を明記する条項を含む業務委託契約が見られるようになりました。契約書の典型的なパターンは以下の3種類です。

記載なしの場合が最も判断に悩みます。この場合、後述の秘密情報条項と組み合わせて解釈することになりますが、書面で確認しておくとリスクを減らせます。

秘密情報の定義・第三者開示の範囲

結論：契約書の「秘密情報」の定義に、業務上知り得た情報全般が含まれる書き方かを確認します。

秘密情報の定義には、狭い書き方と広い書き方があります。

• 狭い定義例：「秘密情報とは、書面またはデータ媒体で秘密表示のうえ開示された情報をいう」

• 広い定義例：「秘密情報とは、本契約に関して知り得た一切の情報をいう。口頭で開示された情報、業務環境で知り得た情報を含む」

広い定義の場合、業務コード・議事録・仕様書はもちろん、リポジトリ名やプロジェクトのコードネーム、社内Slackで飛び交う情報まで秘密情報に含まれます。この情報を生成AIに送信する行為は、契約違反と評価される可能性が高くなります。

第三者開示の範囲については、多くのNDAが「事前の書面同意なしに第三者に開示・漏洩しない」と定めます。生成AIサービスが第三者に当たるかは解釈の余地がありますが、安全側で「該当し得る」と考えて事前確認するのが実務の主流になりつつあります。

成果物の権利帰属と派生物の扱い

結論：成果物の著作権譲渡条項がある場合、生成AI利用のプロセスで発生した中間生成物の扱いも確認しておきます。

業務委託契約では、成果物の著作権・二次的著作物の権利をクライアントに譲渡する条項が入るケースがあります。この条項がある場合、以下を確認します。

• 生成AIで作成した中間物（プロンプト・出力例・試行錯誤のログ）が「成果物」に含まれるか

• 派生物・改変版の権利がどう扱われるか

• 生成物にオープンソースライセンスのコードが含まれた場合の対応

プロンプト自体をフリーランス側のノウハウとして残せるかは、契約時に確認しておくと今後の実務に効きます。プロンプトを「成果物」に含める書き方だと、次案件で類似のプロンプトを再利用しにくくなる可能性があります。

学習データ利用オプトアウトの前提

結論：生成AIサービスの学習利用オプトアウトを、フリーランス側で必ず設定する運用にします。

契約書に「生成AIへの入力データが学習に利用されないこと」を要求する条項が含まれるケースがあります。この場合、以下の対応が必要です。

• 使うサービスの学習利用設定を確認し、オプトアウトまたは初期設定でオフのプランを選ぶ

• 設定画面のスクリーンショットや管理コンソールの証跡を残す

• 監査・確認を求められた場合に、記録を提示できる状態にしておく

設定の変更履歴まで残せる法人向けプランを選ぶと、事故発生時の説明責任を果たしやすくなります。

主要生成AIサービスの機密情報取扱いポリシーの基礎

結論：業務利用では、入力データが既定で非学習扱いになる法人向けプランまたはAPI経由の利用が基本です。個人向け標準プランは業務用途を想定していない箇所があるため、切り分けて考えます。

以下、主要サービスの取扱いの整理です。利用規約は改定されるため、契約時点の公式ドキュメントを必ず確認してください。

ChatGPT（Team／Enterprise／API）

結論：業務利用ではTeam・Enterpriseプラン、またはAPI経由の利用を選ぶのが基本です。

• Team・Enterprise：入力データは既定で学習利用されない扱いです。管理者コンソールで組織単位の設定管理ができます

• API：入力データは既定で学習利用されない扱いで、短期のログ保持のみ行われる設計になっています

• Plusプラン（個人向け）：設定でチャット履歴を無効化すると学習利用も無効になる方式のケースがあります。設定の反映範囲は公式ドキュメントで確認します

• 無料版：業務用途を想定した保護は用意されていないため、業務利用は避けるのが安全です

詳細はOpenAIのEnterprise Privacyおよびプライバシーポリシーで最新情報を確認してください。API利用時のデータ取扱いはOpenAI API data usage policies（提供されている場合）で確認できます。

Claude（Team／Enterprise／API）

結論：Anthropic社のClaudeも、Team・Enterpriseプランおよび標準API利用ではモデル学習に用いない扱いが基本です。

• Team・Enterprise：企業向けの契約で入力データの学習利用は行わない設計です

• API：一般利用の入力データは学習利用されない扱いです

• Claude.ai個人プラン（Free / Pro）：規約と設定を都度確認する必要があります

Claudeの詳細はAnthropicのプライバシーポリシーを参照してください。ClaudeのAPI利用については、当サイトのClaude APIの使い方も参考になります。

GitHub Copilot（Business／Enterprise）

結論：Copilot Business・Enterpriseでは、入力・出力コードをモデル学習に使わない設定が既定です。

• Copilot Individual：個人向けプランで、公開コードとの類似検出などのオプションが選べる方式です

• Copilot Business：入力・出力コードは学習利用されない設計です。組織単位のポリシー設定が可能です

• Copilot Enterprise：Businessと同等の保護に加え、リポジトリ横断のチャット機能などがあります

業務コードに触れる案件では、個人プランではなくBusiness以上を導入依頼する、またはクライアント側のライセンスを使う運用が実務で採られています。詳細は当サイトのGitHub Copilotの使い方に加え、GitHub Docs：Copilot Business/Enterpriseのデータ取扱いを確認してください。

Cursor／Windsurf等のAIコードエディタ

結論：AIコードエディタは「プライバシーモード」の設定と、バックエンドで使うLLM提供者の両方を確認します。

• Cursor：Privacy Modeを有効化すると、コードがCursor社のサーバー側に保存されない設定が用意されています

• Windsurf：エンタープライズ向けにデータ保持ポリシーを選べる設計があります

• 共通の注意点：エディタ自体の設定に加え、内部で呼び出しているOpenAI・Anthropic等の利用規約も確認対象です

AIコードエディタは複数のLLMプロバイダーを内部で切り替える構造を採るサービスがあります。エディタベンダーのポリシーだけでなく、実際にコードが渡るLLM提供者のポリシーも確認します。関連情報はCursorとはでも整理しています。各エディタの最新仕様は、公式のSecurity／Privacy／Data Policyページで確認してください。

ミニFAQ：サービス選択

Q. 個人開発の副業と客先案件で、同じサービスの同じアカウントを使ってよいですか？

A. アカウントを分けるのが安全です。個人開発では自由に使えるサービスでも、客先案件では契約プランが指定されるケースがあります。アカウント分離で運用ルールの取り違えを防ぎやすくなります。

客先案件で入力してよい情報・NGな情報の見分け方

結論：判断は「秘密情報の定義に含まれるか」「代替表現で置き換え可能か」の2軸で切り分けます。

情報を4つのカテゴリに分けて考えると、判断がぶれにくくなります。

判断フロー

結論：入力前に3つの問いを通す運用にします。

1. この情報は契約上の秘密情報に該当するか：Yes→2へ／No→入力可

2. 契約で明示的にAI利用が許諾されているか：Yes→指定プランで入力可／No→3へ

3. 代替表現で置き換えても目的を達成できるか：Yes→抽象化して入力／No→クライアントに確認

2で許諾がなく、3でも代替表現に置き換えられない場合は入力しない判断が安全です。判断に迷うときは、案件担当者やエージェント経由で書面確認を取ります。

マスキング・匿名化のパターン

結論：機密性を落とすには、代表的な3種類の変換パターンを組み合わせます。

• 固有名詞の変数化：AcmeCorp → ClientA など、実際の顧客名・製品名を汎用名に置換

• 数値・時刻のダミー化：実際の金額・件数・日時を近い桁の別数値に置換

• 構造の一般化：業務固有の処理を一般的なパターンに書き換えたうえで質問

コードのマスキング例は以下です。

変数化しても構造が固有な処理は依然として機密性が残る点に注意します。ビジネスロジック自体が競争優位性である場合、変数化では守り切れないため、そもそも入力対象から外します。

よくある誤解

結論：以下は現場で頻出する誤解パターンです。

• 「無料版なら学習利用オフの設定があるから大丈夫」：設定の反映範囲・遡及効・オプトアウトの完全性は個別に確認が必要です

• 「短時間の入力なら痕跡が残らない」：一時ログでも記録は残り、監査対象になり得ます

• 「セキュリティ研究者も生成AIを使っている」：研究環境と客先の業務環境は情報取扱いが異なります

ケース別対応：契約形態で変わる実務

結論：契約形態によって、AI利用の判断主体・確認先・記録責任が変わります。

以下、代表的な4パターンでの実務対応を整理します。生成AIの契約実務全般については、フリーランスエンジニア向けの秘密保持契約（NDA）のチェックポイントもあわせて参照してください。

SES・準委任常駐案件

結論：常駐先のセキュリティルールと社内制度に従うのが基本です。

• 常駐先が用意する法人向けAIアカウントを使う

• 個人アカウントを常駐先PCで使わない

• 判断に迷ったら常駐先の情報システム部門または委託元エージェントに確認

• 「持ち込みデバイスでの個人利用」の可否も別途確認する

準委任契約では、業務指揮命令はフリーランス自身にありますが、常駐先の情報取扱ルールは順守義務があります。契約書に加えて常駐先のセキュリティポリシー・情報取扱規程まで確認する運用が安全です。

フルリモート受託

結論：契約書で許諾範囲を書面化し、使うサービスとプランを合意しておきます。

• 契約書に「生成AIの利用可否・使用可能サービス・データ保存場所」を明記

• 開発環境（ローカルPC・クラウドIDE）と生成AI連携の経路を整理

• クライアントに提出するチェックリストで運用ルールを共有

フルリモートでは、常駐案件よりもフリーランス側の判断余地が大きくなります。その分、判断の説明責任もフリーランス側に生じやすくなります。

直請けの個別契約

結論：契約書の起案段階で生成AI関連条項を盛り込むのが実務的です。

直請け案件では、フリーランス側からも契約条件を提案しやすい立場です。以下の条項を組み込む提案が有効です。

• 使用可能な生成AIサービスと必要なライセンス提供者（クライアント／フリーランス）の合意

• 学習利用の禁止・オプトアウトの前提

• インシデント時の通知義務と責任範囲の切り分け

• 契約終了後のログ・履歴の削除ルール

契約書のひな型は、経済産業省・特許庁「秘密情報の保護ハンドブック」などが参考になります。

エージェント経由の間接契約

結論：エージェントを介した契約では、二者間の確認だけでは不十分なケースがあります。

• エージェント側の規約と、エンドクライアントの規約が二重に適用される

• 生成AI利用可否の最終判断者はエンドクライアント側にあることが多い

• エージェント担当者に書面確認を依頼し、記録を残す

エージェント側が生成AI関連の確認プロセスを整備しているかは担当者と会話しておくと安心です。「担当者経由でエンドクライアントに書面確認を取る」フローが用意されているエージェントを選ぶと、都度の判断負荷を減らせます。

参画前チェックリスト

結論：以下の10項目を案件開始時に確認しておくと、後日のトラブルを大幅に減らせます。

チェックリストの一部は書面確認が難しいケースもありますが、メールやチャットでの回答も記録として保存しておくと、後日の説明に使えます。

よくある失敗と対策

結論：失敗パターンは3種類に集約されます。事前に把握しておくと回避しやすくなります。

失敗1：プロンプトへの丸ごとコード貼り付け

発生パターン：エラーの原因調査で、業務コードを丸ごとChatGPTに貼り付けて質問する。

問題点：業務コードにはクライアント名・APIキー・DB接続情報・内部URL等が含まれるケースがあります。丸ごと貼り付けると、意図せず秘密情報も送信することになります。

対策：貼り付け前に以下を確認します。

• 変数化・匿名化の3種類の変換を実施

• コメント・ログ出力に含まれる固有名詞の削除

• 認証情報・接続情報のダミー化

• クライアント固有のビジネスロジックを一般化

失敗2：議事録・仕様書の要約

発生パターン：長い会議の議事録や仕様書をAIで要約させて、時短しようとする。

問題点：議事録には未公開の意思決定・体制情報・関係者名が含まれます。要約タスクは大量の秘密情報を一度に送信することになり、リスクが高いカテゴリです。

対策：以下のいずれかで対応します。

• 議事録は原文のまま入力せず、要点を人手でメモ化してから抽象論で相談

• 議事録要約が業務要件の場合は、契約でクライアント指定のプラン利用を確認

• ローカル動作のLLMや、クライアント環境内で完結するサービスを検討

失敗3：顧客固有情報の変数化忘れ

発生パターン：普段は変数化しているが、急いでいるときに変数化を忘れて送信してしまう。

問題点：一度送信された情報は取り戻せません。取消・削除の依頼をしても、既に運用ログに残った可能性は排除できません。

対策：ヒューマンエラーを前提とした運用にします。

• 客先案件専用のブラウザプロファイル・アカウントを用意する

• 送信前チェックのテンプレートを用意し、貼り付け前に必ず通す

• 個人プランのアカウントには、業務コードを扱うプロジェクトのブックマークを置かない

ミニFAQ：失敗回避

Q. うっかり業務コードを送信してしまったとき、どう対応すればよいですか？

A. まず案件担当者またはエージェント経由でクライアントに報告し、指示を仰ぐのが基本です。事故報告のスピードが信頼の毀損幅を左右します。生成AIサービス側にも、削除要請や履歴消去の手続きを申請します。

単価・案件選びに与える影響

結論：生成AI関連の契約実務に慣れていることは、単価交渉と案件選定の両方でプラスに働きます。

案件によっては、契約・情報取扱いの説明ができることが評価材料になる場合があります。生成AI活用が前提の開発案件では、Cursor・Copilot Enterprise等の実務経験が評価対象になる例も見られます。

案件選びの視点では、以下を確認しておくとミスマッチを減らせます。

• クライアント側の生成AI利用ポリシーが整備されているか

• 使用可能なサービスとライセンス提供者が明確か

• インシデント時のフローが用意されているか

契約実務の全体像は、エンジニアの生成AI活用術でツール選定の観点とあわせて整理しています。案件条件に合わせた単価レンジの目安を知りたい方は、無料のフリーランスエンジニア単価診断を利用できます。

まとめ

迷ったら、契約確認→書面確認→非学習プラン利用→匿名化の順で判断するのが、業務委託で生成AIを使うときの実務の基本です。技術的にどう使えるかよりも、契約上どう使ってよいかを先に整理する順序で進めます。

要点は以下です。

• 契約書のAI利用条項・秘密情報の定義・成果物の権利帰属・データ利用の前提を確認する

• 個人アカウントの無料版に客先の業務情報を入力しない。Team/Enterprise/APIの非学習前提を使う

• 判断は「秘密情報に該当するか」「代替表現で置き換え可能か」の2軸で切り分ける

• 契約形態（SES・受託・直請け・エージェント経由）ごとに確認先を整理する

• 参画前チェックリストを用意し、開始時に運用をすり合わせる

• 契約解釈やNDAの適用範囲は個別事情で変わり得るため、重要案件では弁護士・法務部門の確認を得る

契約実務の隣接領域として、フリーランスエンジニア向けの秘密保持契約（NDA）のチェックポイント、およびエンジニアの生成AI活用術を参考にしてください。案件条件に合わせた単価レンジの目安は、無料のフリーランスエンジニア単価診断で確認できます。

参照した一次情報

• OpenAI・プライバシーポリシーおよびデータ利用

• Anthropic・プライバシーポリシー

• 経済産業省・特許庁「秘密情報の保護ハンドブック」