業務委託で生成AIの利用を禁止する・条件付きで認める条項

先に決めること　禁止か許可かの前に、現場で何が起きているか

業務委託契約に生成AIの条項を入れるとき、最初に出てくる問いは「禁止にするか、認めるか」です。ただ、この問いに答える前に、確かめておくことが三つあります。受託者が実際に生成AIを使っているか、使うとしてどの作業か、そして発注者自身の側に外部サービスを使う前提があるか、の三つです。

生成AI（文章・画像・音声などを、指示（入力）に応じて作り出すAI。この条項では、外部の事業者が提供するサービスとして使うものを主に指す）は、いまや文章の下書き、翻訳、要約、議事録の作成、画像の生成など、ごく普通の作業の道具になっています。受託者が黙って使っているのか、使っていないのかが分からないまま「一切禁止」と書いても、実態に合わない条項になりがちです。逆に、使っていると分かっているのに何も書かなければ、秘密情報や個人情報が外部のサービスに渡る経路が契約の外に残ります。

公的な資料も、この順序を前提にしています。総務省・経済産業省の「AI事業者ガイドライン」第1.2版（令和8年3月31日）は、AIを使う事業者の取組事項として、個人情報や機密情報を不適切に入力しないことなどを挙げています。^［1］あわせて、法令になくても、当事者間の契約でデータの利用が禁止されている場合があることに注意を促しています。^［1］取引先から預かった情報を、受託者が生成AIに入れてよいかどうかは、その情報を預かったときの契約が許しているかで決まる、ということです。

このページでは、取引相手（受託者）の生成AI利用を取り決める条項を、禁止型と条件付き許可型に分けて見ていきます。ここで扱うのは、契約の実務で見られる書き方と、その書き方に起こりやすい問題の型です。AIを使って作った契約書の下書きに見つかった誤りの話ではない点は、先に断っておきます。なお、生成AIを提供する側の利用規約や契約は、別サイトの外部AIモデル・API依存サービスの規約で扱っており、読者の立場が異なります。

契約の実務で見られる2つの型と件数

点検の実務で、業務委託やNDA（秘密保持契約）で取引相手の生成AI利用を取り決めていた25依頼者分の記録を整理すると、取り決め方は大きく二つに分かれました。秘密情報などを承諾なく生成AIに入れることを原則として禁じる「禁止型」が9、利用を認めたうえで条件を付ける「条件付き許可型」が16です。この数は、確認できた範囲の資料で数えたもので、全体の傾向を示すものではありません。

禁止型の9のうち、NDAに置かれたものが7を占めます。つまり、禁止型は、相手から預かった秘密情報の扱いを定めるNDAに置かれることが多い型です。条件付き許可型は、実際に生成AIを使う作業が前提になる契約で、使い方まで取り決める型だといえます。

表を見ると、条件の中心は「学習に使われないこと」です。16のうち12がこの条件を置いていました。一方で、条件を満たしているかを確かめる手段に当たる「申告・記録」と「停止指示」は、それぞれ3にとどまります。条件は置いたが確かめる手段は置いていない、という組み合わせが多いことは、次のページ生成AI利用の申告・記録・停止指示・違約金の付け方で詳しく見ます。

禁止型　三点セットと、広すぎる禁止の問題

禁止型は、書き方が単純なので、一見すると問題が少なそうに見えます。しかし、点検の実務では、禁止型の条項にも次のような問題の型が繰り返し見られました。

一つ目の「承諾の方法が決まっていない」は、禁止型で起きやすい問題です。「事前の書面による承諾なく入力してはならない」と書いてあっても、承諾をどの方式で取るのかが書かれていないと、受託者が承諾を取らずに進めたのか、口頭やメールで取れていたのかで争いになります。承諾の方式は、後の見出し「承諾の方式と例外の設計」で三つの型に分けて整理します。

二つ目の「広すぎる禁止」は、実務と契約書のずれが最も目に見える形で出る問題です。「生成AIを一切利用してはならない」と書くと、文章の校正支援、翻訳、画像の背景除去のような補助的な作業まで違反になります。発注者側の他の条項や、発注者自身の運用と矛盾して、契約の初日から違反になる構造になっていた例もありました（点検記録でおおむね3依頼者分。このほかに、生成AIを提供する側の書類で1例）。禁止の射程を実際の作業に合わせて絞ることが、条項を「守れる条項」にする第一歩です。

三つ目の「入力だけで終わる禁止」は、条項の組み立ての問題です。派生情報（入力した情報をもとにAIが出した要約・分析・翻訳など、元の情報から作られた二次的な情報）を契約でどう扱うかを決めておかないと、禁止に違反して入力してしまった場合や、承諾のうえで入力した場合に、できあがった結果物の扱いが争点になります。

条件付き許可型　条件の組み合わせ方

条件付き許可型は、実務の実態に合わせやすい一方、条件の置き方で出来が大きく変わります。点検の実務で見られた問題の型を整理すると、次のようになります。

この中で、条件付き許可型に特有なのは最初の問題です。「学習に使われない」という条件は、サービスの契約条件や設定画面で確かめられる事実ですが、確かめた結果を誰がどこに残すのかを書かなければ、後から確認できません。この点は、次のページで申告・記録の条項として扱います。

入力する情報の区分も、条件付き許可型の中心です。三段（入れてよい・設定などの条件付きで入れてよい・入れてはならない）に区分した例が、16のうち3ありました。区分の考え方は生成AIに入力してよい情報・いけない情報の取り決めで詳しく整理します。

「AI」の定義、承諾の方式、例外の設計

「AI」の範囲を決める

禁止でも許可でも、「AI」「生成AI」「外部サービス」の範囲が書かれていない契約は、読み手によって意味が変わります。点検の記録では、定義がなく範囲が不明なものが2依頼者分、定義を置いたものが5依頼者分ありました（概数）。生成AIを広く定義すると翻訳ソフトや検索の要約機能まで入り、狭く定義すると新しい形のサービスが漏れます。

定義は、禁止したい行為から逆算して作るのが実務的です。たとえば、秘密情報の流出を防ぐことが目的なら、「事業者が提供する外部のサービスで、入力した情報を送信して処理させるもの」と、機能ではなく情報の流れで書きます。自社のパソコンの中だけで動くものまで含めるかは、別に書き分けます。

承諾の方式　三つの型

承諾の方式は、点検の記録では三つの型が見られました。方式を書かずに「事前の承諾」とだけ書く条項は、この三つのどれなのかが読めません。

三つの型のうち、実務で扱いやすいのは「まとめて承認」です。記録では、使ってよいサービスと保存先を条文や別紙でまとめて示す方式を入れ、さらに、学習に使われないことが確認できるサービスなら個別の承諾を要しない、という定めを置いた例が見られました（1依頼者。例として）。禁止から一覧と申告の組み合わせに改めることで、禁止が実務と合わず形骸化するのを避けた例もあります（1依頼者。例として）。

例外を設計する

全面禁止の書き方は、補助的な編集や一般的な事務作業まで巻き込みます。例外を明示した例では、「補助的な編集に限り、書面による承諾を得て行うことができる」とした型と、「教材や秘密情報、顧客の個人情報を使わない一般的な事務作業は対象外」とした型が見られました。例外は、広げすぎると禁止が空洞になるので、例外に当たる作業の範囲を短く具体的に書くのが基本です。

公的資料と法令から見た位置づけ、立場による重さの違い

生成AIの利用を契約で取り決める根拠は、一つの法律にまとまっているわけではありません。実務で参照される公的資料と法令を、条項の論点ごとに整理すると、次のようになります。

文化庁のチェックリストは、AIを業務で使う人が著作権のリスクを下げるための取組を、項目として整理した資料です。令和6年7月31日の版で、内部ルールの策定、侵害が起きた場合の対応手順の事前の想定、生成物を使う前の類似性の確認などが挙がっています。^［2］全部をやれば責任を問われないという趣旨ではないと、資料自身が述べています。契約に取り込むなら、「受託者は既存の著作物を指示として入力しない」「生成物を納品する前に既存の著作物と似ていないか確認する」のように、守れる行為として書くのが現実的です。

営業秘密との関係は、慎重に考える必要があります。営業秘密として法律の保護を受けるには、持ち主が秘密として扱ってきた事実が前提になります。^［3］秘密情報が外部のサービスに渡り、学習などに使われうる状態になると、管理の状況を後から説明しにくくなる場面があり得ます。だからこそ、入力を制限する条項に加えて、使えるサービスと設定を特定しておくことが、管理の実態を説明する材料にもなります。

裁判例についても、事実のとおり書いておきます。生成AIの利用を取り決めた契約条項の解釈が争われた裁判例は、裁判所の裁判例検索で確認できませんでした。^［6］確認できる裁判例はまだ少ないため、本ページは裁判例ではなく、契約の実務での書き方と、公的資料・法令にもとづいて整理しています。

立場によって、条項の重さは変わる

同じ条項でも、発注者の立場か受託者の立場かで、重く感じる部分が変わります。発注者は、禁止と確かめる手段（申告・記録）を厚くしたい。受託者は、実務で守れる範囲に禁止を絞り、開示や記録の義務を軽くしたい。点検の実務でも、受託者側の立場から、開示・記録の提出義務を外す方向に見直した例がありました（1依頼者。例として）。

ここで大切なのは、どちらが正しいかを決めることではありません。自分が結ぶ契約の立場で、守れる義務だけを書くことです。守れない義務を書いた契約は、問題が起きたときに、書いた側の不利に働きます。たとえば、「生成AIを一切使わない」と約束した受託者が、翻訳ソフトを使っていた場合、約束違反を指摘される材料になります。

また、ひとつの業務委託契約の中でも、NDA（別紙のものを含む）、業務委託契約、確認書、ガイドラインが重なる場合があります。それぞれに生成AIの定めがあるときは、どれが優先するのかを決めておくことが必要です。この優先関係は、次のページで扱います。NDA側の記載はNDA（秘密保持契約）のよくある誤りで、書類の種類ごとの確認点をまとめています。

見つけ方と直し方　点検の手順

条項の点検と仕上げの進め方

生成AIの条項は、条文そのものよりも、契約書の他の部分（秘密情報の定義、再委託、損害賠償、NDAの返還・消去）とつなげて読んだときに、はじめて不具合が見つかることが多いものです。条項だけを切り出して直しても、ほかの条項との食い違いが残ります。点検と仕上げの全体の流れはAIで作った契約書の点検と仕上げの流れに、渡していただく資料も含めて整理しています。料金の目安とご相談の枠は、このページの末尾の案内にまとめています。急ぎでなければ、まず上の10項目で自分の契約書を読み返し、気になる点を書き出してみてください。

他の分野の契約での生成AIの扱いは、別サイトにも解説があります。NDAについてはNDAと生成AI・外部サービスへの入力、フリーランスが受け取るNDAの点検は受け取ったNDA・秘密保持条項を受注者側から点検、制作の現場でのAIの使用は制作での生成AIの使用と契約、漫画制作でのアシスタントへの取り決めは漫画制作と生成AIの契約条項、AI機能付きのSaaSを使う側の契約は生成AI機能付きSaaSの契約条項を参照してください。それぞれ読者の立場が異なるので、役割を分けて読むと整理しやすくなります。また、成果物の権利や表明保証の書き方は生成AIを使った成果物の権利と表明保証、取引先や社内のルールとして整える手順はAI利用のルールで扱います。

よくあるご質問

あわせて読みたいページ

本ページは一般的な情報提供です。個別の書類が有効か無効か、どの条項を直すべきかは、事業の実際の流れ、取引の相手、書類の全体の構成によって異なります。書き方の例として紹介している内容は、型として作り直した一般的な例で、特定の事業者や書類を示すものではありません。条文は e-Gov法令検索（法令API）で2026年10月23日時点のものを確認しています。参考: e-Gov法令検索 / 文化庁 / 個人情報保護委員会 / 法務省 / 消費者庁