はじめに

本稿の前編では、生成AIへの個人情報・営業秘密・機密情報の入力のうち、個人情報・自社営業秘密について論じた。後編では、最もコンセンサスが得られていないと思われる「第三者から預かっている機密情報の入力」について論じるとともに、全情報に共通する実務上の問題（生成AIサービス提供事業者（以下「AIサービス事業者」という」）の約款による責任制限との関係、社内ルールの作り方、情報収集に自律性があるAIエージェント等との関係）について論じる。

第三者から預かっている機密情報の入力について^注1

論点と問題の所在

第三者から預かっている機密情報の入力における主な論点は、当該第三者との機密保持契約（NDA）や機密保持義務の中の、

①　第三者開示の禁止

②　目的外利用の禁止

③　第三者との契約終了時等の返還・削除義務との関係で違反が生じないか

の3点である^注2。

この問題が難しいのは、当該第三者との機密保持契約（NDA）や機密保持義務の合理的意思解釈の問題となるため、コンセンサスが得られにくいという点である。行政法規としての個人情報保護法の解釈や、自己責任といえる自社営業秘密の管理に関する解釈とはこの点が異なる。

目的外利用の問題

NDA・機密保持義務で定められた目的外利用禁止との関係で、利用目的との整合性を要検討なのは、生成AIを使わないケースと同様である。たとえば、A社からA社のプロジェクトために預かった機密情報をB社のプロジェクトのために流用すれば目的外利用になる^注3。この点、自分で認識している資料を自分で生成AIに読み込ませるのであれば、目的外利用か判断は容易だが、蓄積されているファイルが自動でプロンプトに取り込まれるような仕組みになっている場合は、認識せずに目的外利用がされてしまう可能性があることに留意が必要である。この点は、Ⅴで後述する。
上記のような一般的な目的外はない前提で、生成AIへの入力自体が目的外利用にならないかが問題となる。
NDA・機密保持義務において、生成AIへの入力が明確に禁止されていれば、入力はそれ自体目的外利用になるであろう。しかし、明確な禁止があるケースはそれほど多いわけではない。問題は、明確な禁止がないケースである。
前編Ⅱ3.（3）（b）で述べたとおり、利用者がプロンプトに入力した個人データが、AIサービス事業者側の学習に①利用されない場合、②汎用的な学習目的（例：当該AIサービス事業者の自社サービスの改善・改良目的）に利用される場合、③ユーザへのサービス提供に必要な範囲内でのみ学習目的に利用される場合がありうる（経済産業省｢AIの利用・開発に関する契約チェックリスト」（令和7年2月）の27頁参照）。
②については、目的外利用に該当する可能性が一般的に高いように思われる。③についても、当事者間の合理的意思解釈の難しい問題が残る^注4が、②と同じ帰結になる可能性がある。
他方、①の場合は、委託先への開示自体は、それだけでは直ちに目的外利用の問題にはならないと考えてもよいかもしれないが、いずれにせよ、3.の第三者開示の禁止の論点が生じるので、そちらで論じることにする。

第三者開示の禁止

まず、AIサービス事業者への機密情報開示が、NDA・機密保持義務の「第三者開示の禁止」に抵触する可能性について論じる。この点、柴山＝古川＝寺前｢クラウド・生成AI時代における機密保持契約―SaaS利用を踏まえた実務的考察｣（NBL1308号）の33、34頁は、

（ⅰ）そもそも｢開示｣にあたらない可能性

（ⅱ）｢開示｣にあたっても、明示または黙示の同意があるといえる可能性^注5

（ⅲ）法的に、厳密には上記いずれも難しいとしても、実務上現実的にはリスクがとれる可能性

について言及して議論しており大いに参考になる。なお、上記論文は、（ⅰ）については、個人情報保護法のクラウド例外の議論（前編Ⅱ3.（2）参照）を応用する可能性を示している。
NDA・機密保持義務において、生成AIへの入力が明確に禁止されていれば、入力は明確な違反となるため困難になるが、明確な禁止があるケースはそれほど多いわけではない。問題は、明確な禁止がないケースである。
前述のとおり、利用者がプロンプトに入力した個人データが、AIサービス事業者側の学習に①利用されない場合、②汎用的な学習目的（例：当該AIサービス事業者の自社サービスの改善・改良目的）に利用される場合、③ユーザへのサービス提供に必要な範囲内でのみ学習目的に利用される場合があり得る（経済産業省の｢AIの利用・開発に関する契約チェックリスト ｣の27頁参照）。
②については、(2)で前述したとおり、目的外利用に該当する可能性が一般的に高いが、｢開示｣該当性も肯定され、黙示の同意もないと解される可能性が一般的に高いように思われる。③についても、当事者間の合理的意思解釈の難しい問題が残る^注6が、②と同じ帰結になる可能性がある。
他方、①の場合は、②や③に比べて、「開示」該当性が否定できるが、黙示の同意が認められ、入力が許容できる可能性が相対的に高いが、この場合には、「委託先への機密情報の開示の可否」の論点を考えることになる。具体的には、以下のようなケースに分けて検討することが考えられる。
NDA・機密保持義務において委託先への開示全般を広く許容している場合には、生成AIについても、入力が許容されると考えられる。しかし、現実的には無制限に委託先への開示を許容するNDA・機密保持契約は多くない。委託先への開示について言及があるNDA・機密保持義務では、一般に、「委託先との間で同等の機密保持義務を締結すれば委託先への開示は可能」と定めてあるケースが多い。この場合、元のNDA・機密保持義務の内容が、入力先の生成AIサービスの機密保持義務と同等性があるという前提をおくことができれば、入力は許容されることになる。実際に各取引先との個別に異なるNDAとの同等性を厳密に網羅的に検証しようとすると現実的でない面があるが、ある程度柔軟に解釈しつつ、最終的には上記（ⅲ）のリスクベースの検討も視野に入れることはありうるように思われる。
さらに問題があるのは、NDA・機密保持義務に委託先への開示についてまったく言及がない場合であり、ここについては、一般論としても見解が分かれ、契約当事者間の合理的意思解釈としても難しい問題が残るところであるといえる。いずれにしても、通説・判例があるわけではなく、各社ごとに見解の相違があることを理解しておく必要がある。
この点、（ⅲ）のリスクベースの検討については、中崎尚『生成AI法務・ガバナンス　未来を形作る規範』（商事法務、2024年）91頁では、｢機密保持義務･･･に形式的に違反したとしても、それによって事業者に生じうる損害が限定的であれば、リスクを承知で、生成AIによる処理に踏み切ることも考えられる｣としている。また、福岡＝松下『生成AIの法的リスクと対策[増補改訂版]』214頁は、M&Aのデューデリジェンス（DD）の場合の機密情報の相手方への開示も完全に適法とする根拠を見いだすことは困難でありながらも、実務上行われていることを引き合いに、生成AIへの機密情報の入力について「秘密情報の内容（形式的に秘密指定されているものもある）、提供の必要性と契約の相手方から契約違反を主張されるか否か、主張された場合の損害額等のリスクを踏まえて、AI提供者に対して提供するか否かの判断をするというのが一つの考え方」であるとしている。さらに、前掲柴山＝古川＝寺前論文の34頁でも、M&AのDDの場合の機密情報の相手方への開示の問題を引き合いに出しつつ、「一般論として、法務が相談を受ける多くの場所においてリスクが０であることはむしろ少なく、リスクを評価したうえで、低減する手段についても検討し、リスクとベネフィットを比較したうえで場合によってはリスクテイクすることが必要であるといえよう」としている。
リスクベースの検討にあたっては、想定される相手方の損害の有無と金額も問題となるといえる。

第三者との契約終了時等の返還・削除義務の問題

NDA・機密保持義務では、一般に、「契約終了時の機密情報の返還・削除義務」が定められている。前掲柴山＝古川＝寺前論文35頁では、SaaS等の関係でこの論点を論じ、上記の3.の｢開示｣の（ⅰ）〜（ⅲ）と同じ枠組みで検討することを提案しており参考になる。クラウドサービスの場合には情報の継続的保存が想定されるため、この論点が顕在化するが、生成AIの場合は、プロンプトの処理のためだけに情報が用いられて即時に削除される場合には本論点は問題とならないと考えられる。生成AIの場合にも、不正監視のための一定期間の保存をする場合や利用履歴（ログ）情報として保持し続けられる場合では問題となりうるが、たとえば、保存期間が30日以内等の比較的短期であれば現実的には顕在化しづらいとも思われる。また、事後的な機械学習のために生データとして機密情報をAIサービス事業者が保持し続けているような場合は正面から抵触が問題となるが、そもそもこの場合は、｢開示｣や目的外利用の論点でも抵触があるため、本論点のみ固有の高度なリスクがあるともいえないようには思われる。

実務上の取扱い

以上のとおり、第三者から預かった機密情報については、当事者間のNDA・機密保持義務の合理的意思解釈の問題が生じ、コンセンサスが得られにくい面があることを前提に各社で立場を決める必要がある。AIサービス事業者との契約で、当該事業者による学習やその他の目的外利用がないこと、および第三者開示をしないことが担保されていれば、明文でAI利用が禁止されている第三者以外の機密情報を生成AIに入力する余地は、一定のリスクをとる前提に立てばあると考えられる。
もっとも、特に重要度の高い機密情報やNDA違反時のリスクが高いケースについて本当に入力する必要があるか慎重に検討すべきであると思われ、この点はⅣ2.で後述する。AIエージェント等が自律的に機密情報を拾ってしまう可能性については、Ⅴで後述する。

NDAや機密保持義務の改訂の可能性

上記のとおり、現状の一般的なNDAや機密保持義務との関係では、生成AIへの第三者から預かった機密情報の入力については疑義が生じてしまうことになる。この点、包括的に生成AI全般への入力を許容する定めをNDAにおくことはいかなる生成AIが含まれるかも不明であるから適切でなく、実務上も合意を得られないと思われる。個別の特定の生成AIをホワイトリスト方式にして承認を得ておくことは一案である。ただし、特定の生成AIを使うことが決まっていればワークするが、将来の追加・変更可能性を踏まえると柔軟性に欠ける面がある。前掲柴山＝古川＝寺前論文では、35、36頁で、SaaS等に機密情報を入力するための条件を定めており^注7、参考になる。包括的な条件を定めるのみではガバナンス上不安があるということであれば、包括的な条件を定めて当該条件を充足する生成AIサービスであれば機密情報入力に事前承諾は不要としつつ、機密開示元の第三者に異議権を与え、新たな生成AIサービス利用前に通知を行ない、あらかじめ定めておいた一定の期間内に異議がなければ入力できるという形にすることも一案かもしれない。
この点、現時点では確立した実務はなく、今後の検討が進むことが期待される。個別のケースごとでの交渉であり、両者の間である程度生成AI利用の必要性について共通理解があれば、NDAや機密保持義務の修正についての建設的な議論と合意が可能になる可能性は十分ある。他方、全社のNDAを一律に見直し、全取引先との間で条件の合意に至ることは現時点ではハードルが高いように思われ、提案する内容次第では、むしろ、寝た子を起こしてしまい、実務が回らなくなってしまうような事態になる可能性も否定できないと思われる。

AIサービス事業者の約款による責任制限との関係

生成AIへの個人情報・営業秘密・機密情報の入力については、本記事で論じてきたとおり、必要な内容の契約がAIサービス事業者との間で締結できていることを前提に、一定の立場に依拠すれば、可能であると考えることはできると思われる。
もっとも、AIサービス事業者による契約違反が疑われるような事由があった場合にも、すべての損害をAIサービス事業者に賠償請求できるとは限らないということには留意が必要である。まず、そもそも契約違反および債務不履行に基づく損害賠償請求のための立証が容易でない可能性がある。また、AIサービス事業者との約款に損害賠償の制限条項（損害額の上限規定や損害の範囲・種類の限定）が入っていた場合には、原則として、その制限に服することになる。
したがって、いずれにせよ、いざという時は、AIサービス事業者が全面的に責任を負ってくれるとの前提での検討は実態に合わないことがあり、生成AIへの個人情報・営業秘密・機密情報の入力を認めるとしてもどこまで積極的に認めるかや何らかの留保をつける必要がないかの検討は必要であろう。これについては、Ⅳで後述する。

社内ルールの作り方

情報入力を認める場合の実務的対応

実務的には、生成AIへの個人情報・営業秘密・機密情報の全部または一部を入力することを許容する場合は、「入力して問題ない」との整理ができている生成AIをホワイトリスト化しておき、当該ホワイトリスト化された生成AIについては当該情報の入力を可能とし、それ以外の生成AIについては、これらの情報の入力を禁止するか、そもそも会社として当該生成AIの利用自体を認めないという方針をとることが考えられる。会社が利用を認めた生成AIについては、すべて一律これらの情報の入力を許容する方針としたいのであれば、それ以外のAIについては利用自体を禁止する必要が生じる。他方、これらの情報を入力できる生成AIとそうではない生成AIがあってよいと考えるのであれば、両者を区別しておき、その区分に従った運用を各役職員に求めることが考えられる。

情報入力への注意喚起や制限の要否の検討

Ⅲで前述したとおり、生成AIへの個人情報・営業秘密・機密情報の入力を認めるとしても、どこまで積極的に認めるかや、何らかの留保をつける必要がないかの検討は必要であろう（図表1）。
まず、リスクを低減するために、必要性が高い場合に限ってこれらの情報を入力することを許容する（情報入力しなくても同等の目的が達成できるのであれば、入力を避けてもらう）という運用は一案である。本来は必要がなかったのに入力した結果として何らかの問題が起きてしまった際に、「入力しなければよかった」という後悔を避けることが目的である。しかし、入力した方が利便性が高く、実際に入力せずとも同等の目的が達成できるかなど、入力してみなければわからないこともあるだろう。この点をあまりに厳しいニュアンスで伝えると、「リスクがあるのであれば、入力は原則やめよう」という結果につながり、生成AI利活用が進まなくなることもありうるため、さじ加減は各社の考え方に照らして検討する必要がある。
また、一般的に情報入力を認めるとしても、例外的に、入力を禁止すべき場合がないかを検討する必要がある。
個人情報との関係では、たとえば、要配慮個人情報（個人情報保護法2条3項）、機微（センシティブ）情報（金融分野における個人情報保護に関するガイドライン5条 ）、不正に利用されることにより財産的被害が生じるおそれがある個人情報^注8などは、入力禁止情報の候補になりうる。ただし、「何がこれらの情報に該当するか」を現場の役職員に周知することは必要になる。また、大量の個人情報の入力を禁止するという量的制限を設けることも一案であるが、大量該当性が個々人の判断に委ねられると判断がバラバラになるという問題が残る。一定の数を定めてしまうことも一案であるが、どこで線を引くかが難しい問題であるように思われる^注9。また、この場合、分割して入力することで規制を僭脱することがないように注意を促すことが考えられる。さらに、必要がない限り、提供先（AIサービス事業者）において特定の個人が識別できるような個人情報の入力はしないようにするといったことも考えられるが、現場役職員による必要性の判断と加工の手間が実務上問題となる。そもそも個人情報保護法についての一定程度の知見が現場役職員になければ、個人情報の入力の全面禁止や制限的なルールを定めたところで現場での遵守は進まないことになるため、個人情報関係の現場向け研修等も必要になってくる。
営業秘密との関係では、自社の営業秘密区分との関係性を意識したうえで、ルールを作ることが一般的である。たとえば、極秘については入力を禁止するといったことが考えられる。第三者から預かっている機密情報についても同様に自社の営業秘密区分に従った管理がされていればこれに沿った扱いをすることが想定される。第三者との機密保持契約において、機密保持義務違反について高額な違約金・違約罰があるケースや、取引契約の即時解除事由になっているケース、賠償額の制限規定の適用除外となっているケース等もあるため、そのような違反時のリスクが相対的に高いNDAとの関係の整理は、本来問題となる。現場の役職員に実際に個別に入力する情報について毎回個別のNDAとの紐づけのリスク判断をさせることは現実的でない面があり、リスクが高いと判断されるNDAに紐づけられた情報はあらかじめ生成AIに入力することがないように別領域で別管理しておくことも考えられる^注10。
また、これらの入力情報の制限ルールを人間に対して設けても、AIエージェント等を導入した場合、人間が意図的に情報を入力しなくても、AIエージェント等が自動的に情報を拾ってしまうことの制御がかかっていなければ結局ルールは守られないことになってしまう。この問題はⅤで後述する。

図表1　社内ルール策定時の検討事項（入力を認める場合）

情報収集に自律性があるAIエージェント等との関係

情報収集に自律性があるAIエージェント等（Microsoft社のCopilot等を含む）を導入した場合、人間が意図的に情報を入力しなくても、AIエージェント等が自動的に情報を拾ってしまう可能性を考慮しておく必要がある。AIエージェント等は目的達成のために、これらが情報を拾うことが制限されていない領域からさまざまな情報を拾う可能性がある。したがって、Ⅳのような制限を社内ルールで置く場合には、AIエージェント等が導入されても、社内ルールが守られる状態にしておく必要がある。
まず、上記IV2.で入力自体を禁止した情報（例：個人情報の一部の類型や営業秘密のうちの極秘情報）は、あらかじめAIエージェント等が情報を拾う可能性がある領域とは別の領域で保存しておく必要があることになる。
課題があるのは、入力自体が禁止されているわけではない情報についてである。
特に、Ⅱ3.で前述したとおり、機密情報の目的外利用の防止との関係では課題が残ることになるであろう。AIエージェント等が個別に目的外利用に当たらないかの判断を毎回正確にすることができるという前提を置くことができないのであれば、目的外利用の可能性を避けるためには、第三者から預かった機密情報についてはすべてAIエージェント等が情報を拾う可能性がある領域とは別の領域で保存しておくことも想定される。AIエージェント等がメールを添付ファイルを含めて拾う設定になっている場合、添付ファイル自体が第三者から預かった機密情報である場合には、これも拾われて目的外利用がされる可能性を想定した技術的対応を検討する必要が生じる。
自社の営業秘密との関係でも、AIエージェントが自動的に営業秘密を取り込んだが、AIエージェントが出力したものには自社営業秘密であるとの表示がない場合には、AIエージェントの出力を見た者がそれが営業秘密だと認識することができなくなり、秘密管理性に問題が生じてしまう可能性があるため、そのようなことが起きないような技術的対応の検討が求められる。
また、前記Ⅳ2.のように、人間向けに個人情報・営業秘密・機密情報の入力に高い必要性を要求したり、入力の量的な制限をルールとして入れたりしている場合は、これをAIエージェント等にどうやって守らせるかに関しての技術的対応についても検討する必要が生じるであろう。
このように、情報収集に自律性があるAIエージェント等の普及により、意図しない生成AIへの個人情報・営業秘密・機密情報の取り込みが起こることへのリスクの認識と対応の検討が、今後ますます重要になると思われる。

1. 本テーマについては、AI法研究会プライバシー部会での部会員の議論から様々な示唆を受けている。特に、杉浦健二弁護士からは、本稿の原案について、貴重なご指摘をいただいたのでここに記して感謝申し上げたい。[↩]
2. 機密保持義務違反になるのみならず、不正競争防止法2条1項７号（営業秘密を保有する事業者･･･からその営業秘密を示された場合において、不正の利益を得る目的で、又はその営業秘密保有者に損害を加える目的で、その営業秘密を使用し、又は開示する行為）および不正競争防止法21条2項2号違反にあたる可能性もあることに留意が必要である。[↩]
3. いったん生成AIを離れて考えるに、たとえば「こういった業務は一般的にはこのように進めている」「この業務でこういった場合は、大抵こうするとうまくいく」「このようなサービスの価格の相場はだいたいこの程度である」といった一般的な知識に昇華したものを使うのであれば、通常、目的外利用にはならないと思われる。理論上は、これと同じことを生成AIがしているだけということが技術的に担保できるのであれば、目的外利用になる範囲を狭くすることもできそうであるが、そのような制御について担保ができるのかについて課題があると思われる。[↩]
4. 前述のとおり、最終的に一般的な知識に昇華したものを使っているのと同視できる状態だといえれば、そのような範囲の学習については、目的外利用とはいえないとの考え方が理論的にはありうるように思われる。[↩]
5. （ⅰ）のように、当事者の合理的意思解釈として「開示」該当性を否定するのか、（ⅱ）のように形式的には、「開示」該当性を肯定しつつ、「開示」に（黙示の）同意があると考えるかは理論的説明の仕方に過ぎず、構成を変えることで事案の帰結が変わるような性質のものではないように思われる。個人的には、黙示の同意が認められるのであれば、そもそもその黙示の同意の意思を文言の合理的意思解釈として「開示」該当性に読み込んで該当性を否定してしまう方がすっきりする面があるように思うが、ここは見解が分かれるかもしれない。結局のところ、当該事案においてはNDA違反とならないと考えられるのであれば、（ⅰ）または（ⅱ）のいずれかにより違反該当性を否定するというだけの話であろう。[↩]
6. 最終的に一般的な知識に昇華したものを使っているのと同視できる状態だといえれば、そのような範囲の学習については、目的外利用と同様に、開示の論点もクリアできるという立場はありうるかもしれない。[↩]
7. 中小企業庁の機密保持契約書ひな形（中小企業庁「知的財産取引に関するガイドライン・契約書のひな形について」を原案とした、同論文の筆者らによる修正版のNDAのファイルは、商事法務のウェブサイトで公開されている。[↩]
8. 漏えい等の報告義務（個人情報保護法26条）のトリガーとなる類型として、個人情報保護委員会規則7条2号に定められているものを参照。[↩]
9. この点、漏えい等の報告義務（個人情報保護法26条）との関係では、個人情報保護委員会規則7条4号では1,000名が基準とされていることは参考にはなるが、これが生成AIへの入力との関係で適切な閾値といえるとは限らない。[↩]
10. いずれにせよ、Ⅴで述べる、情報収集に自律性があるAIエージェント等との関係では、このような情報保存場所を分ける対応を検討する必要がある。[↩]