営業秘密の秘密管理性は生成AIへの入力で失われるか — Claudeの設定との関係

結論:入力しただけで秘密管理性が消えるとは読めない

生成AIに営業秘密を入力すると、それだけで不正競争防止法の保護が失われるのでしょうか。経済産業省の管理指針(本記事が引用するのは平成31年1月改訂版の本文です)を読む限り、そうは書かれていません。指針は、外部のクラウドに営業秘密を保管しても「秘密として管理されていれば、秘密管理性が失われるわけではない」としています。

ただし、安心してよいという意味でもありません。秘密管理性が問われるのは、会社が「これは秘密だ」という意思を、従業員に具体的な措置で示せていたかどうかです。生成AIの利用ルールが曖昧なまま情報を入力させていると、問題は入力の瞬間ではなく、日頃の管理体制の側に現れます。

Claudeの学習・保持設定は、この論点に2通りで関わります。

• 秘密管理性: 社内でどのアカウント・どのプランなら入力してよいかを決め、周知することが「秘密管理措置」の一部になる
• 非公知性: 学習に使われた情報が「公然と知られている」状態に当たるかは、平成31年1月改訂版の指針に書かれていない

本記事は一般的な整理であり、法的助言ではありません。個別の事案は弁護士などの専門家に確認する前提で読んでください。

営業秘密の3要件と、生成AIが絡む場所

不正競争防止法の第2条第6項は、営業秘密を「秘密として管理されている生産方法、販売方法その他の事業活動に有用な技術上又は営業上の情報であって、公然と知られていないもの」と定義しています。経済産業省の管理指針はこれを次の3要件に分けて説明します。3つすべてを満たして初めて、法に基づく保護を受けられます。

経済産業省の営業秘密ポータルは、秘密情報が持ち出されるなどの被害にあったとき、民事上・刑事上の措置をとるには、その情報が不正競争防止法の営業秘密として管理されている必要があると説明しています。防御の入口は、いつも秘密管理性です。

有用性は、秘密管理性と非公知性を満たす情報であれば通常認められると指針が述べています。生成AI利用の文脈で争点になりやすいのは、残る2要件です。

秘密管理性が求めるのは「意思の明示」と「認識可能性」

指針は、秘密管理性要件の趣旨を、企業が秘密として管理しようとする対象が従業員に明確になることで、従業員の予見可能性を確保する点に置いています。

要件を満たすには、会社の秘密管理意思が秘密管理措置によって従業員に明確に示され、従業員がそれを容易に認識できる必要があります。「会社が内心で秘密だと思っている」だけでは足りません。

措置の中身は表示・契約・アクセス制御を含む

指針の脚注は、秘密管理措置を「アクセス制限」に狭めず、「秘密としての表示」や「秘密保持契約等の契約上の措置」まで広く含めて考えるとしています。電子ファイルなら、次のような方法が典型例として挙がっています。

• 電子ファイル名やフォルダ名へのマル秘の付記
• ファイルを開いたとき画面にマル秘と表示されるようにする
• ファイルやフォルダの閲覧にパスワードを設定する

また、措置は企業の規模・業態・情報の性質によって異なり、「鉄壁の」管理を求めるものではないと明記されています。中小企業にも高度な対策を一律に課さない、という趣旨です。

外部クラウドの利用そのものは要件を壊さない

指針は電子媒体の管理方法として、外部のクラウドで保管・管理する場合も、秘密として管理されていれば秘密管理性が失われるわけではないとし、階層制限に基づくアクセス制御を例に挙げています。

生成AIサービスはクラウドサービスの一種です。この記述と並べれば、「外部の事業者のサーバーに情報が送られた」という事実だけで秘密管理性が否定される、という読み方は取りにくいでしょう。

ただし、この一文は保管・管理を想定した記述で、生成AIへの入力を名指ししたものではありません。平成31年1月改訂版の本文に、生成AIを名指しした判断は見当たりません。経済産業省のポータルには2025年3月改訂の表記がありますが、その改訂版の本文は本記事の執筆時に取得できていません。生成AIへの言及があるかは、最新版を直接確認してください。

生成AIへの入力で秘密管理性が揺らぐのはどんな場面か

入力そのものではなく、次のような運用の穴が論点になります。

何も措置がない場合

指針は、従業員が実際に秘密だと認識していれば措置が不要になるわけではなく、法文が「秘密として管理されている」とする以上、何らの秘密管理措置もない場合は要件を満たさないと述べています。

生成AIの利用ルールを一切定めず、機密表示もない情報を各自が自由に入力している状態は、これに近づきます。

継続的な不徹底が公然の事実になっている場合

指針は、複数の管理単位がある場合について、ある単位で措置が欠けていても、原則として別の単位の秘密管理性は否定されないとしています。例外は、その不存在が継続的で社内の公然の事実になり、従業員の認識可能性が損なわれている場合です。一時的・偶発的な不徹底では、直ちに秘密管理性は失われません。

この記述は生成AIを扱ったものではありません。ただ、「個人アカウントへの入力を黙認する状態が常態化し、誰も咎めない」ときに何が起きるかを考える手がかりにはなります。

委託先・提供先の内部管理は自社の秘密管理性に影響しない

指針は、複数の法人間で同じ情報を保有するケースで、別法人内部での情報の管理状況は、自社の秘密管理性に影響しないことが原則だと述べています。子会社や委託先が念頭にあります。

Anthropicのようなサービス提供事業者が自社サーバー内でデータをどう扱うかは、この原則の射程に近い論点です。一方で、営業秘密を示された相手が不正に使った場合に差止請求をするには、その相手に自社の秘密管理意思が明確に示されていることが必要とも書かれています。契約でどう縛るかが、ここで意味を持ちます。

Claudeの設定は何を左右し、何を左右しないのか

Claudeでの入力データの扱いは、契約形態で大きく分かれます。学習利用の既定はClaudeを学習させない設定で、プランごとの詳しい手順を扱っています。ここでは営業秘密の観点で必要な部分だけ取り上げます。

商用契約は契約条項で線が引かれている

Commercial Termsは、顧客が入力(Inputs)に関するすべての権利を保持し、出力(Outputs)を所有すること、そしてAnthropicが顧客のコンテンツ(Customer Content)でモデルを学習してはならないことを定めています。さらに、Customer Contentは顧客の機密情報(Confidential Information)だと位置付けられ、受領側は合理的な注意を下回らない水準で保護する義務を負います。

この構造は、営業秘密管理の実務で言う「取引相手への秘密保持契約」に相当する役割を果たします。指針が秘密管理措置の例に「秘密保持契約等の契約上の措置」を挙げていることを踏まえると、商用契約の条項は、社内規程と並べて管理措置の説明に使える材料になる場合があります。契約書のどの条項が、自社の秘密管理措置としてどこまで通用するかは、個別に確認が必要です。

商用契約でも例外はあります。明示的にフィードバックやバグ報告を送ると、その会話が学習に使われる場合があります。Team・Enterpriseの管理者は、組織設定の「Rate chats」でメンバーのフィードバック送信を無効にできます。

個人向けプランは「許可」が学習と長期保持の両方を動かす

個人向けプランでは、モデル改善の設定を許可すると、会話やコーディングセッションが学習に使われます。許可した場合は、匿名化した形で最長5年、学習用のパイプラインに保持されると案内されています。この保持は、許可後の新規または再開したチャットに適用されます。

設定をオフにすれば、以後の新しいチャットは将来の学習に使われません。一方で、すでに開始済みの学習や、すでに学習済みのモデルには反映されたままです。経緯はClaude Consumer Terms改定の解説にまとまっています。

設定がオフでも、安全性の分類器にフラグされた会話は、安全性向上のために使われることがあります。「オフにすれば何も使われない」とは言い切れません。

業務利用で個人アカウントを許すこと自体が管理上の論点になる

営業秘密の管理という観点では、設定の中身以上に、どのアカウントで入力を許すのかが効きます。個人アカウントは従業員が設定を変えられ、会社が既定を強制できません。会社契約のアカウントなら、管理者が組織設定を握ります。

情報の区分と利用先を決めておけば、従業員は「どの情報をどこに入れてよいか」を読み取れます。これは、指針の言う「認識可能性」を高める方向の措置です。機密情報全般の扱いはClaudeに機密情報を入力しても安全かが整理しています。

非公知性との関係は指針から断定できない

「学習に使われた情報が、モデルを通じて第三者に知られてしまうのではないか」という懸念は、非公知性の問題です。

指針は「公然と知られていない」状態を、一般的に知られた状態になっていない、または容易に知ることができない状態と定義します。具体的には、合理的な努力の範囲内で入手可能な刊行物に載っておらず、公開情報から容易に推測・分析できず、保有者の管理下以外では一般に入手できない状態です。

また、特定の者が事実上秘密を維持していれば、なお非公知と考えられる場合があるとも述べています。特許法の公知の考え方とは一致しません。

この基準に学習利用を当てはめた記述は、平成31年1月改訂版の指針にも、Anthropicの公開資料にもありません。学習に使われた入力が、出力を通じて一般に知られる状態に当たるかどうかは、これらの資料からは判断できません。

したがって、この点は不確実性が残るものとして扱うのが妥当です。営業秘密として守りたい情報ほど、学習に使われる可能性のある経路を、そもそも作らない選択が現実的になります。商用契約の利用や、個人アカウントの禁止がその例です。

社内ルールに落とすときの書き方

秘密管理措置は、ルールを決めて周知し、守られているかを確認するところまでで完成します。次に、規程と設定の例を示します。文面は一例で、自社の状況に合わせた調整と、法務の確認を前提とします。

情報区分ごとに入力先を決める

例えば次のように、区分と入力先の対応を規程の別表にします。

【生成AI入力可否表(例)】
区分A(営業秘密として管理する情報: 未公開の設計書・原価表・顧客名簿)
  → 会社契約のClaude(Team/Enterprise/API)のみ。個人アカウントへの入力は禁止。
  → ファイル名またはヘッダーに「マル秘」を付記する。
区分B(社外秘だが営業秘密として指定していない情報)
  → 会社契約のClaudeのみ。
区分C(公開済みの情報)
  → 制限なし。

区分Aに「マル秘」表示を求める点は、指針が電子ファイルの典型的な管理方法に挙げる表示の付記と同じ発想です。表示と入力ルールが揃っていれば、従業員は「これは会社が秘密として扱う情報だ」と認識できます。

Claude Codeでは読み取らせない範囲を設定で固定する

ソースコードや設計資料をClaude Codeで扱う組織は、営業秘密を含むディレクトリに、権限ルールで読み取り禁止を設定できます。Claude Codeの権限設定は、Read の拒否ルールでファイルやディレクトリの読み取りを止められます。例えば次の形です。

{
  "permissions": {
    "deny": [
      "Read(./trade-secrets/**)",
      "Read(./.env)"
    ]
  }
}

拒否ルールの効き方には限りがあります。Bashのコマンドが対象のファイルを名指ししない場合や、PythonやNodeのスクリプトが直接ファイルを開く場合は、拒否ルールの対象外です。すべてのプロセスからのアクセスを止めたい場合は、サンドボックスで強制する必要があります。権限設計全体はClaude Codeセキュリティ・権限ガイドで扱っています。

この設定は、営業秘密の保護策であると同時に、「会社が秘密として管理しようとしている範囲」を技術的に示す措置にもなります。指針も、通常の状況では高度な情報漏えい対策は秘密管理性の必須要件ではないと述べています。設定は秘密管理性のために必須ではなく、漏えいリスクを下げる追加の対策として位置付けるのが正確です。

運用の確認項目

導入後は、次の点を定期的に点検すると、ルールが形だけになるのを避けられます。

1. 区分Aの情報が、個人アカウントのチャット履歴に残っていないか(削除した会話は30日以内に削除される、という保持の仕様も確認する)
2. Team・Enterpriseの管理者設定(フィードバック送信の可否など)が、意図した状態か
3. 委託先や取引先に営業秘密を示す際、生成AIの利用可否を秘密保持契約に含めているか
4. 規程を周知した記録(研修の実施記録や同意書)が残っているか

まとめ

生成AIへの入力だけで秘密管理性が消えるとは、平成31年1月改訂版の指針からは読めません。問われるのは、会社が秘密管理意思を従業員に示せているかです。決めることは3つあります。情報の区分、区分ごとの入力先、個人アカウントを許すかどうかです。決めたら周知し、記録を残します。

学習に使われた情報が非公知性にどう響くかは、指針からも公開資料からも断定できません。守りたい情報ほど、学習に使われる経路を作らない構成が現実的です。

規程全体の項目は社内AI利用規程にAI事業者ガイドラインは何を求めるか、契約形態の選び方はClaude法人プランの契約ガイドにあります。