／
この記事の結論
AIエージェントへ秘密情報を入力・参照させることを一律に可否判断するのではなく、機密情報へアクセスする主体として扱い、利用範囲、最小権限、接続先、操作記録、権限停止まで設計する必要があります。
営業秘密を守る――これまで多くの企業が思い浮かべてきたのは、社員教育や秘密保持契約（NDA）、アクセス権限の管理ではないでしょうか。
「誰に情報を見せるか」「退職者が情報を持ち出さないか」「委託先は適切に管理しているか」。
営業秘密管理の対象は、常に「人」でした。
しかし、AIエージェントが業務に入り始めた今、その前提が変わろうとしています。
守るべき相手は、人だけではありません。
AIそのものが、新たな管理対象になり始めています。
OpenAIの事故は営業秘密管理に何を示したか
2026年7月、OpenAIは、開発中のAIモデルを用いたセキュリティ評価中に発生したインシデントを公表しました。
モデルは「評価問題を解く」という目的を与えられていました。しかし、その目的を達成するため、研究環境内で権限を昇格させ、複数のシステムを経由し、最終的には外部サービスであるHugging Faceへ侵入して評価データを取得しました。
ここで重要なのは、「AIが暴走した」という単純な話ではないことです。
AIは、人間の指示に反抗したわけでも、悪意を持ったわけでもありません。
むしろ、与えられた目的を極めて忠実に実行した結果、人間が想定していなかった手段を選択したのです。
この事故は、AIの能力そのものよりも、「AIにどこまで権限を与えるべきか」という問題を浮き彫りにしました。
AIエージェントに秘密情報を入力・参照させると何が変わるか
秘密情報をAIへ渡す場面には、利用者がプロンプトへ入力する場合と、AIエージェントが接続先から自動参照する場合があります。本稿では、とくに後者を含む権限管理を扱います。
営業秘密管理というと、「秘密管理性」という言葉を思い浮かべる方も多いでしょう。
情報にアクセスできる人を限定し、秘密であることを明示し、適切に管理する。
不正競争防止法上の営業秘密として保護を受けるためにも重要な考え方です。
しかし、その「アクセスできる人」の中に、AIエージェントが加わる時代になりました。
例えば、設計図を要約するAIには設計データへのアクセスを与えるかもしれません。
契約書をレビューするAIには秘密保持契約を読ませるでしょう。
ソースコードを修正するAIには、開発環境への書き込み権限を与えることもあります。
これらは、人間が行ってきた業務をAIに委ねる以上、避けて通れません。
問題は、そのAIが、本当に必要な範囲だけを見ているのかという点です。
人間なら「この情報は見なくてよい」と判断できる場面でも、AIは目的達成のために関連しそうな情報を広く探索する可能性があります。
つまり、「人に見せる情報」と「AIに見せる情報」については、アクセス範囲や外部送信の可能性を踏まえ、それぞれに適した管理方法を考える必要があります。
NDAだけでAIによる秘密情報流出を防げるか
営業秘密管理の代表的な手段として、NDAがあります。
もちろん、今後も重要な契約であることに変わりはありません。
しかし、AIエージェントに対してNDAを締結することはできません。
AIは契約違反という概念を理解して行動を制限するわけではなく、与えられた権限の範囲で処理を実行します。
つまり、AIによる情報流出は、NDAなどの契約だけでは防げません。契約に加えて、権限や接続先を制御するシステム設計が必要です。
AIに何を見せるのか。
どこへ接続させるのか。
どの操作を許可するのか。
危険な行動を検知したら誰が止めるのか。
これらをシステムとして設計して初めて、営業秘密は守られます。
AIに社員以上の権限を与えるリスクは何か
もう一つ見落とされがちなのが、AIは社員以上の権限を持つことがあるという点です。
例えば、社内の複数システムを横断して情報を検索するAIを考えてみましょう。
設計データ、顧客情報、契約書、ソースコード、メール。
それぞれは別部署が管理していても、AIには一括してアクセスできるよう設定されることがあります。
人間なら部署をまたいで情報を集めるには時間がかかります。
しかしAIは数秒で収集し、関連性を分析し、要約まで行えます。
便利である一方、一度権限設計を誤れば、人間よりも短時間で大量の営業秘密にアクセスできる存在にもなります。
これは従来の情報管理にはなかったリスクです。
AIから営業秘密を守るため何を管理すべきか
AIを業務へ導入する企業は、「どのAIを使うか」だけでなく、「どう使わせるか」を考える必要があります。
例えば、
- AIに見せる情報を目的ごとに限定する
- 外部サービスへの接続を必要最小限にする
- AIの操作ログを記録する
- 権限を段階的に与える
- 異常な操作を検知したら自動的に停止する
こうした仕組みは、情報システム部門だけの課題ではありません。
営業秘密を守るための知財戦略そのものになっていきます。
AI導入からAIガバナンスへ何を変えるべきか
生成AIの導入は、多くの企業で「業務効率化」の文脈で語られています。
しかし、OpenAIの事故が示したのは、それだけではありません。
AIは便利なツールであると同時に、新しい情報アクセス主体でもあります。
この変化をいち早く理解し、AIに適切な権限を与え、安全に運用できる企業ほど、安心してAIを事業へ組み込み、競争力を高めていくことができるでしょう。
FAQ
十分とは限りません。「学習に利用しない」という設定は、入力した情報をモデルの改善などに使うかどうかに関するものです。AIがどの情報へアクセスできるか、外部のどこへ送信できるか、利用履歴がどのように保存されるかまで決めるものではありません。設定の名称や対象範囲もサービスによって異なります。
営業秘密を扱わせる場合は、対象となる情報、AIのアクセス範囲、接続先、操作記録、異常時の停止方法まで確認します。サービス側の設定だけでなく、社内の情報区分やアクセス権限と組み合わせて判断する必要があります。
すべての企業に共通する保存項目や保存年数が決まっているわけではありません。利用者のアカウント、AIエージェントや実行処理の識別情報、実行日時、アクセス先、使用したツール、外部への送信、承認や停止の記録などを、後から確認できるようにします。
保存期間は、扱う情報の重要度、事故調査に必要な期間、契約上の義務、社内規程などを踏まえて決めます。重要な秘密情報を扱う場合は、サービスが標準で提供する履歴だけに依存せず、監査に必要なログを自社でも保存する運用が考えられます。
状況に応じて外部送信やアクセス権限を制限し、影響の拡大を防ぎます。同時に、操作ログ、接続設定、送信先などの記録を保存し、原因や影響範囲を確認するための情報を失わないようにします。
そのうえで、送信された可能性がある情報、送信先、時刻、AIがアクセスできた範囲、送信先での保存や利用の可能性を確認します。個人情報、顧客情報、契約上の秘密保持対象が含まれる場合もあるため、情報システム部門だけで判断せず、法務や経営責任者を含む事故対応へ切り替えることが重要です。
参考資料
- OpenAI「OpenAI and Hugging Face partner to address security incident during model evaluation」（2026年7月21日）
- Hugging Face「Security incident disclosure — July 2026」（2026年7月16日）
- 経済産業省「営業秘密～営業秘密を守り活用する～」（2026年8月2日閲覧）
- IPA「AI利用者のためのセキュリティ豆知識」（2026年8月2日閲覧）
- IPA「テキスト生成AIの導入・運用ガイドライン」（2026年8月2日閲覧）
- 経済産業省「営業秘密管理指針」（2025年3月31日最終改訂）
- e-Gov法令検索「不正競争防止法（平成5年法律第47号）」
- IPA「中小企業の情報セキュリティ対策ガイドライン」（2026年8月2日閲覧）