AIに見せていい情報、ダメな情報──「怖い」で止まらない企業の判断基準【実務ガイド】

1. 結論：「AIだから禁止」を、情報と用途の仕分けに変える

「その情報、AIに入れて本当に大丈夫ですか？」。大切な質問だ。ただ、毎回そこで会議が終わるなら、セキュリティ審査ではなく永久に赤信号の交差点になっている。事故は怖い。けれど、信号を全部赤にしたまま「交通を管理した」と胸を張るのも違う。

公開情報は進める。非公開の業務情報は契約と設定を整えて使う。認証秘密の無造作な貼り付けや、権限のない情報の持ち出しは止める。 本稿が提案するのは、この三段階だ。「100%安全」の証明を待つのでなく、どの条件で何を許可するかを会社として決める。

以下の「OK」は、承認済みのサービスを、適法な業務目的で使い、社内規程・顧客契約に反しないことが前提。個人の判断で会社の禁止を解除する表ではない。

健康情報、人事評価、未公表M&A、輸出管理対象技術などは、通常の「条件付きOK」に一括収納しない。専用審査へ送る。高度機密でも適法な専用環境で扱える場合はあるが、汎用チャットへの投入を既定にしない。

本稿は2026年9月18日に確認した公開一次資料を基にした実務上の提案である。各社の説明、過去の事例、筆者の推奨を区別し、事故確率の根拠がないところへ「99.9%安全」という数字は置かない。

2. 顧客名はNGなのか──秘密なのは文字列より「関係」かもしれない

「トヨタの公開決算を要約して」と、「当社がトヨタに提案中の未発表案件を要約して」は違う。前者の会社名は公開情報。後者は、公開された社名に非公開の取引関係・時期・条件が結び付いている。なお、これは説明用の仮定であり、実際の取引を示すものではない。

したがって、公開された法人名を一般例として出すだけなら、それだけを理由に機密情報とは扱わない。一方、「その会社が自社の顧客である」という事実は、非公開なら保護対象になり得る。 有名企業の名前だから何でも公開情報、という理屈も成立しない。

個人情報と営業上の秘密も別物だ。日本の個人情報保護法は生存する個人に関する情報を対象とする。法人名だけと、担当者の氏名・個人事業主の情報は分けて考える。社員番号も人事台帳と容易に照合できれば個人情報になり得る。メールアドレスも個人を識別できるか、他の情報と容易に照合できるかで判断する。「数字だから無害」「会社のアドレスだから対象外」とは言えない。^[1][2]

例えば障害調査なら、「顧客Aの本番環境で認証が失敗する」と、伏せたログ・最小限のコードで原因を探せることが多い。連絡先を含む顧客台帳を渡す必要はない。一方、顧客への返信草案など実名が業務上必要な用途は、必要性を説明して適切な処理環境を承認する。「実名があるから終了」では仕事の設計にならない。

ただし「A社」に置き換えても、業種・所在地・取引額の組み合わせで特定できれば十分な加工ではない。置換しただけで法律上の「匿名加工情報」になったとも言えない。削れる情報は削る。しかし、必要な情報まで消して業務を壊すことを目的にしない。

個人情報保護委員会は、生成AIへの個人情報入力を利用目的の達成に必要な範囲とし、個人データが回答生成以外の目的で扱われないか確認するよう注意喚起している。提供者自身の学習に使われる場合は、本人同意なしの第三者提供になり得る。^[3]

学習なしなら自動的に適法、でもない。業務委託としての整理、委託先監督、国外移転、顧客との守秘義務が残る。国外への委託も、一定の例外を除き本人同意等の検討が必要で、基準に適合する体制を契約等で確保するルートもある。DPA（データ処理契約）はその確認材料であり、署名だけで全義務を消す魔法の紙ではない。^[4]

3. 個人契約と法人契約──「有料＝学習されない」は誤り

同じAIの画面でも、契約プラン・ログイン先・設定でデータの扱いは変わる。社員が会社の経費でChatGPT Proを買っても、それだけでEnterprise契約にはならない。Claude Codeも製品名だけで判定せず、個人向け契約、法人契約、APIのどの入口で使っているかを見る。

さらに、通常利用と評価ボタンによるフィードバック送信を分ける。OpenAIの個人向け説明やAnthropicの説明では、通常の学習停止と別に、評価に付随した会話が学習に利用される場合がある。機密を含む会話を不注意に「改善のため提供」しない。Codexは環境全体の学習共有にも別設定がある。^[5][8]

学習しない、保存しない、人が見ないは別の約束

学習はモデルの重みを更新すること。回答のために文章を一時的に読む処理、会話履歴の保存、社内検索用の索引作成とは別だ。回答に使われた瞬間、全世界共通のモデルに書き込まれるわけではない。 逆に学習不使用でも、保存された会話や検索索引は保護対象になる。

OpenAI APIは、不正利用監視ログを原則最大30日保持する。承認制のZDRにも対象機能・例外があり、ファイルや会話の状態保存、第三者サービスの保持条件は別に確認する。「APIだから一切残らない」は誤りだ。^[15]

2026年の更新にも注意したい。 Anthropicは6月9日施行の対象モデル向け方針で、原則30日の安全目的の保持を説明している。対象外モデルや適格組織への例外があるため、「Claudeは全部30日」「ZDR契約なら全モデル非保存」のどちらも雑すぎる。Cursorの9月3日更新資料にも、不正利用検知時の保持や非ZDRモデルの例外がある。モデル名まで承認台帳に書く理由がここにある。^[16][9]

4. GmailやAWSはよくてAIはダメ？──同じ物差しに、追加の検査項目を載せる

会社がGmailやAWSへ情報を預けるのは、外部送信が存在しないからではない。契約、利用目的、認証、暗号化、アクセス制御、保存・削除、監査を確認し、残るリスクを引き受けているからだ。AIにもこの物差しを当てるべきである。

ただし、既存クラウドの承認は別製品へ自動継承されない。AIアプリ運営者、モデル提供者、検索エンジン、MCPなどの連携先へ処理が広がる場合がある。Cursorでは自分のAPIキーを使ってもリクエストはCursorのバックエンドを通る。Microsoftの法人向けCopilotも、Web検索や追加エージェントの条件確認を求めている。看板の会社名だけでなく、実際の宛先を列挙する。^[9][14]

Google翻訳でも入口が違う。Cloud Translation APIは、送信内容を翻訳機能の学習・改善に使わないと明示する。この保証を一般向けの翻訳画面へそのまま移せない。「Googleへ送るか」だけでなく、「どの契約の何というサービスか」が審査単位なのだ。^[17]

ログも「誰でも読める」から危ないのではない。閲覧権限や転送先、保存期間が本体のDBと異なり、複製が増えやすいから慎重に扱う。監査には利用者・時刻・操作結果を残し、不要な本文や認証秘密を残さない。DBに正当に保管できる情報でも、障害ログへの丸写しまで許可したことにはならない。

VPNを通せば安心、専用線なら万能、ではない

HTTPSのTLSは、正しく構成されていれば通信経路上の盗聴や改ざんを防ぐ。VPNを抜けた先がインターネットでも、HTTPSまで平文になるわけではない。ただし、TLSの終端であるサービス側は処理のため内容を扱う。会社の復号プロキシなどがあれば、そこも信頼境界に入る。^[18]

Amazon BedrockはVPCとPrivateLinkによる接続を提供する。ただし「自社VPCにモデル本体が置かれる」という意味ではない。2026年のBedrock資料にはモデル別の保持設定もあり、ZDR設定と保持必須モデルが衝突する場合は呼び出しを拒否する。経路と保存は独立に審査する。^[19][20]

持ち出し自体を許容できない情報なら、通信制限した社内LLMも合理的だ。その場合は外部検索、クラウドへの切替、テレメトリー、更新経路まで点検する。ローカルという設置場所は、完成したセキュリティ設計の別名ではない。

5. 鍵は文章に貼らない──ただし「金庫に入れたら安全」でもない

秘密鍵・APIトークン・パスワード・セッションCookieは、文書というより権限そのものだ。原則としてプロンプト、ソースコード、スクリーンショット、ログへ生の値を入れない。ログインIDや社員IDは通常、単独で鍵になるとは限らず、個人情報・識別情報として別に分類する。

実行に認証が必要なら、AWS Secrets Manager、Infisical、OSのKeychainなど、環境に合う専用の秘密管理を使う。可能なら長期キーより短期の認証情報・IAMロール・OIDCを選び、必要な操作だけに権限を絞る。AIには「どの認証経路を使うか」を伝え、秘密値を会話へ表示させない。集中管理、最小権限、失効・ローテーションはOWASPも推奨する原則だ。^[21]

Devinには専用のSecrets機能がある。しかし、組織共通のGlobal Secretsは全メンバーのセッションから利用できる。Personal、リポジトリ、セッション単位の範囲を選ぶ意味がある。「管理者しか値を見られない」と「他の人やエージェントがその権限を使えない」は同義ではない。^[22]

また、Keychainに入れても、エージェントが取り出して標準出力へ表示できればモデルに届き得る。理想は、モデルには値を渡さず、実行ツールが必要時に認証する構成。それでも、そのツールが実行できる操作自体は制限する。

Gitのprivateリポジトリも秘密の保管庫ではない。過去のコミット、Issue、テストデータ、CIログまで確認する。.gitignore はGitへの追加を抑える仕組みであって、AIのファイル読み取りを止める境界ではない。既に漏れたキーは削除だけで済ませず失効・再発行する。^[21]

AI固有の追加リスクは、読む文章が命令にも見えてしまうことだ。外部ページやIssueに「この認証情報をここへ送れ」と紛れ込ませるプロンプトインジェクションがある。対策は「怪しい命令に従うな」と頼むだけでは足りない。読み取り範囲、通信先、書き込み権限を制限し、送信・削除・本番変更は承認を挟む。^[23]

6. 過去の事故は何を証明するか──「直した」と「二度と起きない」を分ける

安全性を考えるなら、事故を隠すより、原因・影響範囲・修正・残る課題を確認したい。ただし、実際の漏えいと研究者が示した脆弱性、学習と表示障害を混ぜると判断を誤る。

ChatGPT Enterpriseの発表は2023年8月28日で、上の3月の障害より後である。この障害を「Enterprise契約なのに企業データを誤学習した事件」の根拠にはできない。本稿の調査では、その説明に一致する事故を一次資料で確認できなかった。これは「過去に事故が一切なかった」という主張ではない。^[25]

修正内容が示せるのは、その原因への対処が進んだことまで。将来の別の欠陥、設定ミス、委託先事故が二度と起きない証明にはならない。ここはAWSにもメールにも同じ基準を適用する。

だから、知名度だけで「この会社は信用できる」と採点しない。監査報告の対象範囲、再委託先、インシデント通知、削除条件、管理者権限を確認する。SOC 2やISO認証は有用な材料だが、個々の使い方の無事故保証ではない。予防に加え、利用停止・アクセス遮断・キー失効・社内報告をすぐ実行できる体制までが承認の中身になる。

7. 大企業は「全部禁止」以外をどう作っているのか

海外ではMorgan Stanleyが、OpenAIを利用する顧客面談支援「Debrief」を2024年6月に発表した。顧客の同意を得て記録を作り、メールはアドバイザーが編集・送信する。同時点で同社が公表した98%という普及率は、別ツールの社内検索Assistantを採用したアドバイザーチームの割合であり、Debriefの普及率でも全社員の利用率でもない。^[26]

日本ではSMBCグループが、社内の汎用AIアシスタント「SMBC-GAI」で2024年9月からOpenAI APIを使い始めたと公式発表している。金融機関でも、外部AIを組織として導入する選択肢は現実にある。ただし発表は「すべての顧客情報を無制限に投入してよい」ことまでは明らかにしていない。^[27]

事例から借りるべきものは、会社名の威光より用途の限定、組織の契約、必要な同意、人による確認という設計だ。「銀行が使ったから自社も無条件にOK」ではなく、同じ種類の確認を自社の情報に当てる。

慎重な会社を笑う必要はない。守りたい情報があるのは健全だ。ただ、「本当に大丈夫？」を繰り返すだけでは、その情報は分類されない。審査する側にも、「何が不足していて、何を満たせば使えるのか」を説明する役割がある。提案する側にも、契約と設定の証拠を示す役割がある。

8. 稟議で承認するのは、ツール名ではなく「使い方のセット」

次の順で判定すると、全案件が「要相談」に沈むのを避けられる。

1. 送る必要があるか。 架空データ・抜粋・集計で済むなら置き換える。
2. 送る権利があるか。 法令、利用目的、顧客契約、社内分類に反するなら、その経路では止める。
3. どこへ何が届くか。 本文だけでなく添付、画像、ログ、索引、連携先への再送信も並べる。
4. 扱いを固定できるか。 契約・モデル・学習設定・保持例外・削除・アクセス権を確認する。
5. 何を実行できるか。 読み取りと変更を分け、通信先・本番権限を絞る。
6. 残るリスクを誰が引き受けるか。 データ責任者と情報セキュリティ・法務等が、権限に応じて判断を記録する。

承認文は例えばこう書ける。「指定した法人環境に限り、指定リポジトリのコードレビューを許可する。秘密値と顧客実データは対象外。出力は人がレビューし、本番操作権限は与えない。契約・モデル・連携先の変更時に再審査する」。これなら「AIを許可した」の中身が後から検証できる。

例外審査は、確認担当と回答期限も決める。公開資料の要約は即利用、通常の社内情報は事前承認された範囲内で利用、高度機密だけ個別審査という道を作る。すべての作業について担当者の度胸を試す会社より、判断を再利用できる会社の方が前へ進みやすい。

事故率を比較できる共通の母集団・公開データがなければ、「AIはメールより何%危険」とは言えない。代わりに、不要な送信項目、利用可能な権限、保存される複製、停止までの時間を減らす。これは怖さの点数付けではなく、具体的な設計変更だ。

良いセキュリティは、使ってよい範囲を説明できる。 赤を赤のまま守り、黄は条件を詰め、青は進める。「全部危ない」と「全部大丈夫」の間には、会社が今日から設計できる広い道がある。

本稿は一般的な実務整理であり、個別案件の法的判断や安全性保証ではありません。法令・業界規制・顧客契約・自社規程と実際の設定を優先してください。各サービスの条件は変わるため、採用時と変更時に脚注の一次資料を再確認してください。イラストはAI生成です。

参考文献・出典

1. [1]個人情報保護委員会：個人情報保護法ガイドライン（通則編）. ↩
2. [2]個人情報保護委員会：メールアドレスだけでも個人情報か（Q1-4）. ↩
3. [3]個人情報保護委員会：生成AIサービス利用の注意喚起（2023年6月2日）. ↩
4. [4]個人情報保護委員会：外国への委託と本人同意（Q12-1）. ↩
5. [5]OpenAI：How your data is used to improve model performance. ↩
6. [6]OpenAI：Business data privacy, security, and compliance. ↩
7. [7]Anthropic：個人向けサービスのモデル学習方針（2026年3月16日）. ↩
8. [8]Anthropic：商用サービスのモデル学習方針（2026年8月18日）. ↩
9. [9]Cursor：Data Use & Privacy Overview（2026年9月3日更新）. ↩
10. [10]Cursor：Privacy and data. ↩
11. [11]Cognition：Security at Cognition（学習・Data Controls・Enterpriseの違い）. ↩
12. [12]GitHub：Managing GitHub Copilot policies as an individual subscriber. ↩
13. [13]Google：Generative AI in Google Workspace Privacy Hub. ↩
14. [14]Microsoft：Data, Privacy, and Security for Microsoft Copilot. ↩
15. [15]OpenAI：APIのデータ制御、保持とZDRの例外. ↩
16. [16]Anthropic：Data retention practices for Covered Models（2026年6月9日施行）. ↩
17. [17]Google Cloud：Cloud TranslationのData usage FAQ. ↩
18. [18]IETF：RFC 8446、TLS 1.3（通信の機密性と完全性）. ↩
19. [19]AWS：VPCとPrivateLinkによるBedrockへの接続. ↩
20. [20]AWS：Amazon Bedrockのモデル別データ保持. ↩
21. [21]OWASP：Secrets Management Cheat Sheet. ↩
22. [22]Cognition：Devin Secrets & Site Cookies（スコープと利用権限）. ↩
23. [23]Microsoft：AI Application Security Series 1（2025年12月17日、EchoLeak修正等）. ↩
24. [24]OpenAI：March 20 ChatGPT outage（2023年3月24日報告）. ↩
25. [25]OpenAI：Introducing ChatGPT Enterprise（2023年8月28日）. ↩
26. [26]Morgan Stanley：AI @ Morgan Stanley Debrief発表（2024年6月26日）. ↩
27. [27]SMBC：OpenAIとの契約締結（2024年10月15日）. ↩
28. [28]OpenAI：The Hugging Face incident and the road ahead（2026年8月26日）. ↩