Enterprise契約なのに「野良AI」？

Codex／Claude Codeと通常APIキーの落とし穴の裏で進む、見えない社内リスク

※本稿は2026年7月24日時点の各社公式文書を基にしている。仕様・契約条件は変更されるため、導入時には最新情報と個別契約を確認してほしい。

---

「学習されるか」だけでは本質を見失う

生成AIの業務利用では、「入力した情報がAIの学習に使われるのではないか」がよく議論される。

しかし、CodexやClaude Codeのように、社内のコードやファイルを読み、コマンドを実行できるエージェント型AIでは、学習利用だけを見ていては本質を見失う。

より重要なのは、次の問いだ。

• どのアカウントで認証しているか
• どのAPI Organizationに所属しているか
• どの契約が適用されるか
• 誰が権限とログを管理しているか
• どこへデータが送信されるか
• 会社が強制停止できるか

特に注意したいのが、Enterprise契約をしている会社で、従業員が個人または別Organizationで取得したAPIキーをCodexやClaude Codeに設定するケースである。

画面上はEnterprise製品を使っているように見えても、その通信までEnterprise管理下にあるとは限らない。

---

Enterpriseは製品名ではなく「管理境界」で考える

Enterpriseという言葉は、少なくとも次の意味で使われている。

1. ChatGPT EnterpriseやClaude Enterpriseという製品契約
2. OpenAI APIやAnthropic APIのOrganization契約
3. AWS、Google Cloud、Microsoftなどのクラウド契約
4. SSO、IAM、監査ログ、保持期間などの管理機能
5. 個別に交渉したZDRやデータ処理契約

これらは同じではない。

たとえば、会社がChatGPT Enterpriseを契約していても、従業員が別Organizationで発行したOpenAI APIキーをCodexへ設定すれば、その利用はChatGPT Enterpriseの管理境界から外れる可能性がある。

Claude EnterpriseとAnthropic ConsoleのAPIキーも同様に、サブスクリプションとAPI利用は別経路として考える必要がある。

したがって、

Enterprise製品にAPIキーを入れたから、その通信もEnterpriseになる

とは限らない。

ただし、「Google CloudやAmazon Bedrockを経由して初めてEnterpriseになる」という表現も正確ではない。

これらは、IAM、監査ログ、請求、ネットワークなどを既存のクラウド基盤で統制できる有力な経路だが、唯一の方法ではない。

正しくは、

どの経路なら、自社が認証・契約・権限・ログ・保持・停止を一元管理できるか

で判断すべきである。

---

ChatGPT Enterprise＋通常のOpenAI APIキーはどうなるか

OpenAIのCodexは、ChatGPTアカウントによる認証と、APIキーによる認証に対応している。

OpenAIは公式文書で、認証方法によって適用される管理設定が変わると説明している。

• ChatGPTでサインインした場合
  CodexはChatGPTワークスペースの権限、RBAC、Enterpriseの保持・データレジデンシー設定に従う。

• APIキーを使用した場合
  APIキーが所属するAPI Organizationの保持・データ共有設定に従う。

つまり、ChatGPT Enterpriseを契約している会社でも、Codexへ通常のAPIキーを設定すれば、その通信はAPIキーが所属するOpenAI Platform側のOrganization／Projectに従う。

個人が取得したAPIキーなら、会社側のChatGPT Enterprise管理者が、そのキーを停止したり、設定を監査したりできない可能性がある。

OpenAI APIへ送信した入力・出力は、明示的に共有へオプトインしない限り、デフォルトではモデル学習に使われない。

一方、標準設定では不正利用監視ログに顧客コンテンツが含まれ、最大30日保持される場合がある。対象企業は審査・契約を経て、Zero Data RetentionやModified Abuse Monitoringを設定できる。

重要なのは、

学習されないことと、Enterprise管理下にあることは別

という点だ。

通常のAPIキーでも学習利用はデフォルトで無効だが、会社のSSO、監査、保持設定、退職時の停止管理から外れていれば、企業統制上は「野良API」になり得る。

---

Claude Enterprise＋通常のAnthropic APIキーはどうなるか

 

Anthropicでも、ClaudeのサブスクリプションとAnthropic ConsoleのAPI利用は分けて考える必要がある。

公式資料では、Claude for Teams／Enterprise、Anthropic Console、Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundryなどが、別々の導入経路として整理されている。

Claude Enterpriseを契約していても、別途取得したConsole APIキーをClaude Codeへ設定すれば、そのAPI利用がEnterprise組織のSSOや管理ポリシーへ自動統合されるとは限らない。

ただし、Anthropic APIは商用利用に該当するため、コードやプロンプトは、明示的にモデル改善へ提供しない限り、デフォルトでは生成モデルの学習に使われない。

標準のサーバー側保持期間は30日。対象組織はZDRを利用できるが、ZDRは標準のEnterpriseプランへ一律に付属するものではなく、Organization単位での適格性確認と有効化が必要になる。

また、Claude Codeはローカル端末の~/.claude/projects/にセッショントランスクリプトを保存する。標準では30日後に削除される設定だが、サーバー側がZDRでも端末側の履歴管理は別問題である。

さらに、/feedback、/bug、/shareなどで明示的に送信した会話やコードは通常利用とは別に扱われ、長期間保持される場合がある。

「APIだから学習されない」で確認を終えると、認証経路、保持、ローカル履歴、フィードバックという重要な論点が抜け落ちる。

---

Google CloudやBedrockを経由すると何が変わるのか

 

Google CloudやAWSを経由する最大の利点は、「Enterprise」という称号ではない。

既存のクラウド統制へAI利用を組み込めることにある。

Google Cloud経由

Claude CodeをGoogle CloudのAgent Platform、旧Vertex AI経由で利用する場合、GCPの認証情報、IAM、請求管理、Cloud Audit Logsなどを利用できる。

Google Cloudは、顧客の許可なくCustomer Dataをモデルの学習やファインチューニングへ使用しないと公式条件で説明している。

会社が既にGCPを統制しているなら、個人APIキーよりも次を適用しやすい。

• IAMによる最小権限
• プロジェクト別の請求
• 監査ログ
• 利用停止
• リージョン管理
• 組織ポリシー

Amazon Bedrock経由

AWSは、Amazon Bedrockの入力・出力をAWSや第三者モデル提供者の学習に使用しないと説明している。

また、AWSの公式文書では、モデル提供者はBedrockの顧客プロンプト、応答、ログへアクセスできないとしている。

Bedrock経由なら、IAM、CloudTrail、VPC、PrivateLink、KMSなど、AWS側の既存統制を活用できる。

ただし、Google CloudやBedrockを使えば自動的に安全になるわけではない。

IAMを広く設定し、ログを確認せず、本番データへ到達できる状態なら、クラウドの看板が立派になっただけである。

---

接続経路を比較する

---

なぜ各社は、この違いを大きく発信しないのか

「発信していない」と断定するのは公平ではない。各社は公式文書に記載している。

問題は、認証、料金、プライバシー、Enterprise導入、データ保持、クラウド連携など、情報が複数のページへ分散していることだ。

また、次の構造も考えられる。

• 簡単に始められることを強調したい
• 認証境界の説明は複雑になりやすい
• 契約ごとに条件が異なる
• 「学習しない」という説明だけが独り歩きしやすい
• APIとサブスクリプションが別請求になっている
• セキュリティ情報が管理者向け文書へ追いやられやすい

公式文書には書いてある。しかし、利用開始画面で最も目立つ場所に書かれているとは限らない。

本来必要なのは、APIキーを設定する際に、

このAPIキーによる通信には、現在のEnterpriseワークスペース設定が適用されない可能性があります

と明示するような、誤解しにくい設計である。

---

なぜSNSの「すごい勢」は扱わないのか

SNSでは、安全性より成果物のほうが評価されやすい。

• 一日でアプリを作った
• AIだけでサービスを公開した
• MCPを大量に接続した
• 全自動で開発させた
• 承認を外したら爆速になった

こうした投稿は分かりやすく、画面映えし、拡散される。

一方で、

• APIキーがどのOrganizationに所属するか
• どの契約が適用されるか
• 何日保存されるか
• 監査ログがどこにあるか
• 退職時に誰が停止するか

という話は地味である。

生成AIは「作る能力」を民主化したと言われる。しかし実際には、技術力より先に実行権限を民主化したのかもしれない。

以前は、ネットワーク、認証、クラウド、データベースを理解していなければ途中で止まった。今はAIの案内に従えば、仕組みを理解しなくても本番公開まで到達できる。

「動いた」という成功体験が、危険性への警戒を弱める。

問題は初心者が開発できることではない。

自分が何を知らないか分からないまま、強い権限を使えることだ。

「俺、すごいものを作った」は事実かもしれない。
同時に「どこへ何を送ったか説明できない」も事実になり得る。

---

会社が最低限確認すべきこと

1. 個人APIキー・個人OAuthを業務利用させない
2. APIキーの所属Organizationと契約主体を確認する
3. Enterprise認証とAPI認証を混同しない
4. 学習利用、保持期間、ZDRを別々に確認する
5. ローカル履歴と認証情報の保存先を管理する
6. 外部通信、MCP、WebFetch、フィードバック機能を審査する
7. 本番認証情報や顧客データを開発端末へ置かない
8. AIをコンテナ、隔離環境、最小権限で動かす
9. コマンドの全面的な自動承認を禁止する
10. AIの変更をPull Request、人間レビュー、CI経由にする
11. 退職・異動時に認証情報を停止できるようにする
12. 禁止だけでなく、便利な会社承認環境を用意する

---

では、企業は結局どうすればよいのか

結論は単純である。

個人が取得したAPIキーをEnterprise製品へ接続するのではなく、会社が管理できる認証・契約・クラウド環境の中でAIを使う。

第一選択：Enterpriseの標準認証

ChatGPT Enterpriseなら、会社のChatGPTワークスペースからCodexへ認証する。

Claude Enterpriseなら、会社のClaude組織アカウントからClaude Codeへ認証する。

SSO、RBAC、管理ポリシー、保持設定、退職時の停止を、Enterpriseのエコシステム内で完結させる。

第二選択：会社管理のクラウド基盤

既にAWSやGoogle Cloudを統制している会社なら、Claude CodeをAmazon BedrockやGoogle Cloud経由で利用する。

IAM、監査ログ、請求、ネットワーク、暗号鍵、利用停止を、既存のクラウド統制へ組み込めるためだ。

第三選択：会社管理のAPI Organization

API連携が必要なら、個人APIキーではなく、会社契約のOpenAI／Anthropic API Organizationから発行する。

そのうえで、次を会社側で管理する。

• データ共有設定
• 保持期間
• ZDRの適用範囲
• Project単位の権限
• 利用上限
• 監査ログ
• キーの定期更新
• 退職・異動時の失効

APIそのものが危険なのではない。

APIキーの持ち主と管理境界が曖昧なことが危険なのである。

---

最低限、禁止すべき構成

次の使い方は、原則として業務利用を禁止すべきだ。

• 個人契約のAPIキーを会社端末へ設定する
• 個人アカウントで社内コードを扱う
• APIキーを社員間で共有する
• 本番認証情報がある端末でAIを動かす
• コマンド承認を全面的に省略する
• 未審査のMCPやゲートウェイへ接続する
• 適用される契約が不明なまま利用する

確認すべきなのは、次の一本の線である。

会社契約 → 会社認証 → 会社管理の権限 → 会社管理の通信 → 会社の監査ログ → 会社による停止

この線が途中で個人APIキーへ切り替われば、そこから先はEnterpriseの外側と考えるべきだ。

---

最終結論――正面はテーラースーツ、背面は裸

現状のEnterprise製品には、正面から見ると立派なテーラースーツを着ているように見えても、認証経路を一歩間違えると、背面が丸ごと開いている構成が存在する。

SSOというネクタイを締め、Enterpriseという上着を着ていても、個人APIキー、未管理のMCP、無制限のコマンド実行、本番認証情報へのアクセスが残っていれば、後ろ姿は裸に近い。

だから企業が選ぶべきなのは、単に「Enterprise」と書かれた製品ではない。

認証、契約、権限、通信、保持、監査、停止まで、会社の管理境界で閉じられる利用経路である。

基本はEnterpriseの標準認証。
必要に応じて、会社管理のAWS、Google Cloud、OpenAI API Organization、Anthropic API Organizationを使う。
個人APIキーは業務環境へ持ち込ませない。

そしてAIエージェントは、隔離環境、最小権限、通信制限、人間によるレビューを前提に運用する。

「学習されないから安全」ではない。

「会社が最後まで管理できるから、ようやく業務利用を検討できる」のである。

テーラースーツを選ぶなら、正面の仕立てだけでなく、まず背面に布があるかを確認したい。

---

主な公式資料

• OpenAI：Codex Authentication
• OpenAI：API Data Controls
• Anthropic：Claude Code Enterprise Setup
• Anthropic：Claude Code Data Usage
• Anthropic：Legal and Compliance
• Anthropic：Organization Data Retention
• AWS：Amazon Bedrock Data Protection
• Google Cloud：Service Specific Terms