AIに見せていい情報、ダメな情報──社内コードと顧客ログの許可基準【実務ガイド】

1. 結論：この条件なら使ってよい、を先に決める

「本当に大丈夫ですか？」で会議を終わらせない。その質問に必要なのは、もう一枚の注意書きより、利用を許可する条件と、その条件を確認する担当者だ。信号機の仕事は、赤く光ることだけではない。青になったら進めることまで含む。

本稿は、通常の企業開発・SaaS運用向けの導入基準案だ。2026年9月19日時点の公開一次資料を根拠に、情報を分類する。法令・顧客契約・自社規程を確認し、次の表を会社のルールとして採用するために使ってほしい。

ここでの「許可」は、無事故の予言ではなく組織が認める業務行為を意味する。機密コードを適切な委託先に処理させることと、そのコードを世界へ公開することは別だ。社内規程が一律禁止なら、この基準を規程改定の提案として使う。

この方向は、単なる楽観論でもない。経済産業省の技術流出対策ガイダンスは、生成AIや翻訳等を禁止するだけでなく、契約上の利用制限と社内ルールで安全な利用環境を整える考え方を示す。^[1] NISTも、導入可否の最低基準を定め、リスク許容度を見直すことを勧めている。^[2]

忙しい人は第3章のリポジトリ基準、第4章の障害調査、第8章の承認文から読んでほしい。 「6条件」「30日試行」は公式原則を業務に落とした本稿の提案であり、当局やベンダーが認定した共通規格ではない。

2. まず「業務情報を入れてよい環境」を一つ作る

各社員に規約を読ませ続けるより、管理者が製品・プラン・組織・モデル・連携先の組を承認台帳に登録する。会社負担のChatGPT Proも個人向け契約であり、Claude Codeもログイン経路によって条件が変わる。

通常の社内情報を扱う環境は、次の四点で合格を判定する。

• 処理目的：業務上必要な処理に利用を限定し、提供者のモデル学習への利用を止める。機密会話のフィードバック提供も無効化、または運用で禁止する。
• 保存と削除：会話・添付・索引・監視ログそれぞれの期間、例外、人による閲覧条件、退会時の扱いが分かり、自社の分類と顧客条件に適合する。通常コードに30日の監視保持を認める会社なら、その条件で許可できる。
• 管理と経路：会社管理のアカウント、MFA、退職時の失効、必要な閲覧権限を設定。アプリ、モデル提供者、検索・MCP等の送信先を把握し、未承認の連携は止める。
• 契約と事故対応：守秘・目的外利用・再委託・国外処理・削除・事故通知の条件を確認し、データ責任者が承認する。必要なDPAや顧客承認もここで揃える。

学習とはモデルの重みの更新で、回答のための処理や会話保存とは違う。入力した文章が、回答のたびに全世界共通のモデルへ書き込まれる仕組みではない。 管理者は「学習不使用」と「保持条件」を別々の欄に記録すればよい。

例えばOpenAI APIの不正利用監視ログは原則最大30日で、承認制ZDRには対象機能と例外がある。^[13] Anthropicは2026年6月9日施行の対象モデル向け方針で、原則30日の安全目的の保持を説明している。適用モデル・適格組織の例外を確認する。Cursorの9月3日更新資料にも保持例外がある。保存禁止の契約なら、そのモデルを外す。保存可能なら、許容期間を記録して使う。^[14][7]

OpenAIやAnthropicも新興企業も、この組み合わせで審査する。監査報告は対象サービスと範囲を確認して証跡にする。

3. 社内リポジトリは、この6条件を満たしたら参照を許可する

対象は、通常の自社アプリの実装・テスト・技術文書。顧客所有コード、未公表の重要技術、規制対象データは第5章へ送る。通常コードまで、全単語を匿名化する必要はない。 社名、クラス名、業務ロジックが残っていても、それを扱える法人環境なら承認対象にできる。

この6条件と第2章を満たした通常コードは、社内ルール上「利用可」にする。 「まだ何かあるかも」で追加審査を続けるのではなく、未解決の対象を特定する。秘密スキャンが見ない営業上の機密は、リポジトリ責任者が分類して補う。

GitHubのsecret scanningは全ブランチのGit履歴等を対象にする。^[15] 履歴もAIに渡すなら、現行ファイルだけの検査では範囲が合わない。急ぐ場合は、必要な現在のコードだけを取り出した、履歴のない作業コピーから始められる。元リポジトリや周辺ディレクトリへのアクセスも遮断する。

混入したキーは、削除より先に失効・再発行する。失効済みの値は有効な秘密と区別し、併記された顧客情報は別途扱う。検出0件という見た目より、処置を説明できることが大切だ。

除外設定は使う機能で試す。GitHubは2026年9月2日にCopilot app・CLIのcontent exclusions一般提供を発表した一方、IDEのEdit／Agentモードには公式文書上の制限がある。^[16][17] 「同じCopilotだから効く」と考えず、無害な検証用文字列を置いて、除外先への読取りがブロックされるか確認する。.gitignoreはGit登録の制御なので、読取り権限の代わりにはしない。

どこまでやれば十分か：通常コースと追加対策を分ける

通常コースは上の6条件。全履歴の匿名化、全ファイルの二人確認、専用線を一律に必須としない。送信対象外まで全社一斉に清掃する必要はない。 既存の秘密漏えいへの対応は並行して行う。

高機密の独自アルゴリズムや顧客専用環境は、別リポジトリへの分割、個別契約、保存制限、専用環境、二人承認を追加する。基準を分ける理由は、対象と被害の大きさが違うからだ。これはリスクに応じて対策を選ぶ設計であって、スキャンで未知の欠陥まで消えたという主張ではない。

4. 障害調査は「原因が分かる最小セット」を渡す

SaaSの障害調査で必要なのは、顧客台帳一式より、エラー、時系列、バージョン、該当コード、再現手順である。次の加工を標準にすれば、担当者が毎回ゼロから悩まずに済む。

架空例なら、「customer=実名、email=実アドレス、token=秘密値、HTTP 401」から、「tenant=TENANT_01、user=USER_01、HTTP 401、token_expired=true、SDK 2.4、更新後だけ発生」へ。秘密値なしでも、更新処理や時刻ずれの調査は始められる。

合格条件は、認証秘密と不要な識別情報がなく、必要な再現条件が残り、その情報区分を承認した環境へ送ること。担当者は加工後のログを一度読み、パターン検出が苦手な自由記述・画像も確認する。問題が再現しなければ、次に必要な項目だけ追加する。

顧客名そのものが重要な不具合もある。特殊文字、長さ、Unicode正規化が原因なら、同じ性質の架空名で再現する。それでも実データが必要なら、第5章の委託処理として承認し、対象顧客・項目・期間を限定する。個人情報保護委員会も、保守で実データを扱う場面について、本人同意や委託としての整理を示している。個人情報がある業務を全面停止する制度ではない。^[18]

置換しても対応表や組合せで特定できるなら、残る性質に沿って管理する。法律上の「匿名加工情報」と決めつけず、「何を消し、何を残したか」を記録する。

5. 企業ごとに判断するのはここ：顧客契約と実データの扱い

「トヨタの公開決算を要約して」は公開情報。「当社がトヨタに提案中の未発表案件を要約して」は、非公開の取引関係を含む。これは説明用の仮定だが、社名の文字列ではなく、その社名に何を結び付けたかで判断が変わる。

法人名だけと、担当者の氏名・個人事業主・容易に照合できる社員番号は区別する。メールアドレスも個人を識別できるかで判断する。^[19][20] 公開法人名が含まれるだけなら、削除を利用許可の条件にする必要はない。

契約担当者へは、「AIは大丈夫？」ではなく、次の具体的な照会を渡す。経産省の契約チェックリストも、入力データの利用範囲などを検討するための資料になる。^[21]

個人データは、利用目的に必要な処理か、提供者自身の学習等へ使われないかを確認する。^[22] 国外委託は、原則として同意の検討が必要で、同等水準の国や基準適合体制等の例外もある。「DPAがある」から一足飛びに決めず、法務・個人情報管理者が採用する法的な根拠を一行で記録する。^[23]

SLAはサービス水準に関する合意、SLOは達成したい水準の目標である。^[24] 可用性99.9%という数字を、顧客情報を送れる根拠や漏えいを許す割合へ読み替えない。情報の取扱いはNDA・DPA・セキュリティ別紙等、停止時の業務継続はSLA・SLOと代替手順で確認する。同じ契約書に両方ある場合も、見る条項を分ける。

判断が残ったら、「この条項が再委託を含むかを法務が確認」「顧客承認を営業が取得」と、担当・問い・期限に分解する。新しいAI論点で結論が固まらない間も、公開情報、自社所有コード、架空データの仕事は先に進められる。権利不明の実データを試験投入して確かめる必要はない。

6. 通信と秘密管理は、要件に合うコースを選ぶ

GmailやAWSを認めるときと同じく、AIも目的・契約・認証・保存・監査で審査する。そのうえで、AIには外部文書の命令混入と、エージェントの実行権限を追加項目として載せる。

通信方式は、次の選び方でよい。

• 通常の社内コード：社内基準が公衆網経由を認めるなら、TLSで保護された承認済み法人サービスを選ぶ。AI利用だけを理由に専用線を必須にしない。
• 閉域接続が契約・規程で必要：対応するPrivateLink等を選び、DNS・経路・接続先を検証する。
• 外部での処理自体が禁止：外部送信を制限した社内LLM、または顧客が承認した環境で処理する。検索・テレメトリー等の出口も確認する。

HTTPSはTLSで端末からサービスの終端までの通信を保護する。VPNを抜けた後もHTTPSが平文に変わるわけではない。社内の復号プロキシがあれば、そこも管理対象になる。^[25] BedrockのPrivateLinkは接続経路の選択肢で、モデル別の保持条件は別の設定として選定する。ZDR条件に合わない保持必須モデルを拒否する仕組みもある。^[26][27]

サービス名も正確に指定する。Google Cloud Translation APIは学習・改善への不使用を明示している。^[28] 一般向け翻訳画面まで同じ承認に含めない。Cursorは自分のAPIキーを使ってもバックエンドを経由し、Copilotの検索・追加エージェントには追加の処理先がある。承認台帳には入口から連携先まで書く。^[7][12]

認証は、AWS Secrets Manager、Infisical、OSのKeychain等へ分離し、短期資格情報・IAMロール・OIDCを優先する。モデルには秘密値ではなく利用する認証経路を伝え、実行ツールが必要時に認証する。ログインIDは単独で鍵になるとは限らず、識別情報として分類する。^[29]

DevinのSecretsも、Global、Personal、リポジトリ、セッション等の範囲を用途に合わせる。Global Secretsは全メンバーのセッションで利用できるため、顧客Aの調査用認証なら限定したスコープを選ぶ。^[30] Keychainから秘密を取り出して画面へ表示する権限まで与えず、まず読み取り専用・対象限定で始める。

Google SAIFはエージェントの最小権限や利用者による操作の承認を整理している。^[31] Claude CodeやCodexのサンドボックスも使い、「読める」「外へ送れる」「書き換えられる」を個別に制御する。 設定名だけで判断せず、ファイル読取りとネットワークの実際の範囲を確認する。^[32][33] 通常の導入では、コード参照・修正案作成を許可し、本番反映・外部送信・削除には人の確認を置けばよい。

7. 過去の事故は、採用基準のどこへ反映するか

事故一覧を読んで不安を増やすだけなら、業務設計には使えない。原因ごとに、採用時の確認項目へ変換する。

2023年3月の障害は、8月発表のChatGPT Enterpriseより前で、学習混入の報告でもない。「Enterprise契約なのに誤学習した事故」の根拠に流用しない。^[37] 今回の調査では、その説明に一致する一次資料は確認できなかった。

将来の欠陥をゼロと証明する代わりに、対象を絞り、提供者の修正・通知能力を確認し、検知時に止められる構成で利用を認める。これはメールやクラウドにも通用する審査の仕方だ。事故率の比較データなしに「AIはメールより何%危険」と採点するより、送信対象と操作権限を具体的に減らせる。

大企業から借りるのは、名前より運用の設計

Morgan Stanleyは2024年6月、OpenAIを用いる顧客面談支援「Debrief」を発表した。顧客の同意を得て記録し、メールはアドバイザーが編集・送信する。発表にある98%は、別の社内検索Assistantを採用したアドバイザーチームの割合だ。同意・用途限定・人の確認があれば、顧客対応を含む業務にも設計の道がある。^[38]

日本のSMBCグループも、社内アシスタント「SMBC-GAI」で2024年9月からOpenAI APIを利用したと公表した。^[39] この発表から読み取れるのは、金融機関にも組織として外部AIを導入する選択肢があること。個別データの投入可否は自社の契約と分類に当てはめる。

自社へ移すなら、「議事録草案まで許可、送信は担当者」「指定コードの調査まで許可、マージはレビュー後」と仕事の途中に境界を置く。会社丸ごと許可か禁止か、という大きすぎる二択から降りると、実装できるルールになる。

8. そのまま稟議に使える承認文と、30日間の進め方

以下は通常コード向けの承認文例だ。製品名・範囲・担当者を埋め、証跡を添えて使ってほしい。

当社は、［組織・製品・プラン・モデル］において、［リポジトリと参照範囲］のコード調査、テスト作成、修正案作成を許可する。第2章の環境条件と第3章の6条件を［担当者・日付］に確認した。同じ範囲の利用は都度申請を不要とする。顧客実データ・認証秘密・指定高機密は対象外とする。本番変更は人の承認を、新たな外部送信先の追加は別途審査を要する。契約・モデル・連携先・情報区分の変更時、および［見直し日］に再評価する。

添付は、①用途と対象範囲、②契約条項と設定の証跡、③スキャン結果と処置、④読取り・通信・操作制限の確認結果、⑤責任者・停止手順。本文や秘密値そのものを監査記録に複製する必要はない。

導入案は、通常リポジトリ1件・1チーム・30日間。期間は効果と制御を評価するための区切りだ。

1. 開始前：データ所有者と管理者が基準を確認。法務への照会は、未解決の条項に限定する。通常コードと加工済みログから始める。
2. 試行中：調査時間、修正案の採用率、レビューで見つけた欠陥、禁止データの検出・誤検知を記録。速くなったかと、制御が働くかを一緒に見る。
3. 直ちに止める条件：有効な秘密の送信、想定外の顧客データへのアクセス、未承認先への転送、権限を超えた操作。対象連携・資格情報を止め、証拠を保全し、契約に沿って連絡する。
4. 見直し時：効果と制御の証拠が揃えば同種のリポジトリへ拡大。誤検知は例外を明文化し、機微度や処理先が変われば条件を強化する。承認記録に次の確認日を残す。

法的な解釈待ちは法務、契約上の同意待ちは営業・顧客窓口、技術的な隔離不足は管理者へ。例えば5営業日で「許可・追加条件・代替案」を返す社内目標を置く。期限が来たら自動許可するのではなく、判断が止まっている理由と次の選択肢を返す。

NISTの導入可否基準と見直しの考え方は、こうした運用を支える。^[2] 事故ゼロ日数だけを根拠に緩和せず、同じデータ区分と制御が維持されているかで拡大する。

「この条件なら使ってよい」と繰り返せる仕事の仕組みを作ろう。守る対象を特定し、条件を満たした仕事は進める。審査する側も「何が不足しているか」「どうすれば許可できるか」まで答える。それを、AI利用の標準にしよう。

本稿の合格条件・承認文は導入規程のひな形です。法令・顧客契約・自社の情報分類に合わせて採用してください。参照した公式資料と本稿の提案を区別し、導入時・変更時に条件を確認します。既存イラストはAI生成です。

参考文献・出典

1. [1]経済産業省：技術流出対策ガイダンス2.0（対策事例、p.89）. ↩
2. [2]NIST AI 600-1：生成AIプロファイル（GV-1.3-002、006、007）. ↩
3. [3]OpenAI：How your data is used to improve model performance. ↩
4. [4]OpenAI：Business data privacy, security, and compliance. ↩
5. [5]Anthropic：個人向けサービスのモデル学習方針（2026年3月16日）. ↩
6. [6]Anthropic：商用サービスのモデル学習方針（2026年8月18日）. ↩
7. [7]Cursor：Data Use & Privacy Overview（2026年9月3日更新）. ↩
8. [8]Cursor：Privacy and data. ↩
9. [9]Cognition：Security at Cognition（学習・Data Controls・Enterpriseの違い）. ↩
10. [10]GitHub：Managing GitHub Copilot policies as an individual subscriber. ↩
11. [11]Google：Generative AI in Google Workspace Privacy Hub. ↩
12. [12]Microsoft：Data, Privacy, and Security for Microsoft Copilot. ↩
13. [13]OpenAI：APIのデータ制御、保持とZDRの例外. ↩
14. [14]Anthropic：Data retention practices for Covered Models（2026年6月9日施行）. ↩
15. [15]GitHub：Secret scanningの検査範囲. ↩
16. [16]GitHub：Content exclusionと機能別の制限. ↩
17. [17]GitHub：Copilot app・CLIのcontent exclusions一般提供（2026年9月2日）. ↩
18. [18]個人情報保護委員会：保守業者による個人データの取扱い（Q7-55）. ↩
19. [19]個人情報保護委員会：個人情報保護法ガイドライン（通則編）. ↩
20. [20]個人情報保護委員会：メールアドレスだけでも個人情報か（Q1-4）. ↩
21. [21]経済産業省：AIの利用・開発に関する契約チェックリスト（2025年2月）. ↩
22. [22]個人情報保護委員会：生成AIサービス利用の注意喚起（2023年6月2日）. ↩
23. [23]個人情報保護委員会：外国への委託と本人同意（Q12-1）. ↩
24. [24]Google SRE：Service Level Objectives（SLI・SLO・SLAの定義）. ↩
25. [25]IETF：RFC 8446、TLS 1.3（通信の機密性と完全性）. ↩
26. [26]AWS：VPCとPrivateLinkによるBedrockへの接続. ↩
27. [27]AWS：Amazon Bedrockのモデル別データ保持. ↩
28. [28]Google Cloud：Cloud TranslationのData usage FAQ. ↩
29. [29]OWASP：Secrets Management Cheat Sheet. ↩
30. [30]Cognition：Devin Secrets & Site Cookies（スコープと利用権限）. ↩
31. [31]Google SAIF：Controls（Agent Permissions、Agent User Control等）. ↩
32. [32]Anthropic：Claude Codeのサンドボックス. ↩
33. [33]OpenAI：Agent approvals and security. ↩
34. [34]OpenAI：March 20 ChatGPT outage（2023年3月24日報告）. ↩
35. [35]Microsoft：AI Application Security Series 1（2025年12月17日、EchoLeak修正等）. ↩
36. [36]OpenAI：The Hugging Face incident and the road ahead（2026年8月26日）. ↩
37. [37]OpenAI：Introducing ChatGPT Enterprise（2023年8月28日）. ↩
38. [38]Morgan Stanley：AI @ Morgan Stanley Debrief発表（2024年6月26日）. ↩
39. [39]SMBC：OpenAIとの契約締結（2024年10月15日）. ↩