こんにちは、ひろかずです。
Claude CodeをAmazon Bedrockなどのクラウド基盤経由で利用する構成のなかには、開発者ごとにAWS IAMのアクセスキーといった長期クレデンシャルを発行・配布して運用しているケースがあり、その管理に頭を悩ませている人もいるのではないでしょうか。
Anthropicからその悩みに一石を投じるリリースがありましたので、共有します。
忙しい人向けの要約
- Claude apps gatewayとは何ですか？ — Claude CodeのSSO認証・ポリシー強制・テレメトリ・支出上限を一元管理する、Anthropic提供の自社ホスト型コントロールプレーンです。
- Anthropicは2026年6月29日、Claude Code向けの自社ホスト型コントロールプレーン「Claude apps gateway」をAmazon BedrockとGoogle Cloud向けに公開しました。SSO認証、ポリシー強制、テレメトリ、推論ルーティング、支出上限（spend caps）を1つのコンテナで担います。
- 2026年7月にはAWSが「Claude apps gateway for AWS」を発表し、Claude Codeに加えてClaude Desktopを対象に含むデプロイ構成を示しました。Google CloudもCloud Runでのデプロイ手順を公開しており、各社の一次デプロイガイドが揃っています。
- 最大の意味は「Bedrock / Vertex経由のClaude Code利用」というserver-managed settingsが届かなかった領域に、IdP起点の統制を通せるようになったことです。開発者端末に長期クレデンシャルを置かない構成を取りやすくなります。
- 支出上限は日次・週次・月次で、組織・グループ・ユーザー単位に設定できます。コスト管理を「請求書を見て驚く」から「事前にガードレールを敷く」運用へ近づけられます。
- ゲートウェイを入れても、端末側managed settings・MCP統制・ログ設計が不要になるわけではありません。既存の3層設計（プロビジョニング／ポリシー強制／標準環境配布）に「経路の統制」として追加する位置づけで考えるべきです。
何が起きているの？
Claude Codeを組織展開している会社の多くが、以下のような壁に当たってきました。
- Bedrock経由で長期のアクセスキーを端末へ配布する構成では、開発者ごとに認証情報を発行し、設定ファイルを各端末へ手で配り、支出は請求書をあとから眺める運用になりがちである（IAM Identity Centerやロール引受による短期認証情報の構成も取れるが、その場合も設定配布と利用可視化の課題は残る）。
- IdPで一元管理しているはずのID基盤が、AIコーディングエージェントの経路だけ素通りになる。
この構造に対して、Anthropicが2026年6月29日に出した答えがClaude apps gateway（以下、ゲートウェイ）です。
ゲートウェイは、Linux上で動く単一のステートレスコンテナとPostgreSQLで構成される自社ホスト型のコントロールプレーンです。Anthropicの発表によれば、担う機能は5つあります。
| 機能 | 内容 |
|---|---|
| アイデンティティ | OIDCリライングパーティとしてGoogle Workspace・Microsoft Entra ID・Okta等のIdPに対して認証し、短命セッションを発行する |
| ポリシー | サーバー側で一度定義した管理設定をサインイン時に配布し、全リクエストで強制する |
| テレメトリ | リクエストごとの利用メトリクスを自社運用のコレクタへOTLPで中継する |
| ルーティング | 上流クレデンシャルをゲートウェイ側が保持し、Claude API・Amazon Bedrock・Google Cloudへ推論を振り分ける |
| 支出上限 | 日次・週次・月次で、組織・グループ・ユーザー単位に設定できる |
Google CloudもCloud Runでのデプロイ手順を公開しており、Anthropic・AWS・Google Cloudの一次デプロイガイドが揃った状態です。公式ドキュメントによれば、上流にはAmazon Bedrock・Claude Platform on AWS・Google Cloud・Microsoft Foundry・Claude APIを利用でき、上流間のフェイルオーバーにも対応します。ゲートウェイは開発者が既にインストールしているClaude Code CLIバイナリに同梱されます。Bedrock上流へのアクセスにはコンテナのIAMタスクロールなどAWSの認証情報チェーンを使うため、静的クレデンシャルは不要です。
オンボーディングはIdPにユーザーを追加すること、オフボーディングはIdPから削除することである、とAnthropicは説明しています。ただし失効は即時ではなく、公式ドキュメントによれば、IdPで無効化されたユーザーのアクセスはセッション有効期間（既定1時間）内に失効します。退職者処理をIdP起点でAI利用の失効まで一気通貫に設計できるのがゲートウェイの核心です。即時の緊急失効が必要な場合の手順は、運用設計の段階で別途確認してください。
なぜ情報システム・セキュリティ担当者に関係するの？
情報システム部門とセキュリティ部門にとって、Claude apps gatewayの論点は「新しいAIツールの導入方法」ではありません。開発者が使うAIエージェントを、既存のID管理・端末管理・監査・コスト管理の枠内に戻せるかという統制設計の問題です。
特にAmazon BedrockやGoogle Vertex AI経由でClaude Codeを使う場合、Claude.ai管理コンソールから配信するserver-managed settingsは適用されず、Claude Code Analytics APIの追跡対象にもBedrock / Vertex経由の利用は含まれません。データ所在や契約、課金処理手続きの都合でAmazon BedrockやGoogle Vertex AI経由でのClaude Codeの利用を選んだ組織ほど、中央からの設定強制と利用可視化が弱くなるという図式でした。
これは情報システム部門にとって、アカウント管理・端末配布・退職者対応の抜け漏れにつながります。セキュリティ部門にとっては、誰が、どの経路で、どのモデルを、どれだけ使ったかを説明しづらい状態になります。
ゲートウェイは、この空白を「経路の統制」で埋めるための部品です。認証をIdPに寄せ、ポリシーをサーバー側で定義し、テレメトリを自社コレクタに集め、上流クレデンシャルをゲートウェイだけが保持する。開発者端末に長期の鍵を残さない構成にできます。Anthropicは、Claude APIを上流に設定しない限り、推論トラフィックも利用データもAnthropicへは送られないと明記しています。
情報システム部門が得られる価値
AI利用のライフサイクルを人事イベントと連動させやすくなることです。オンボーディングはIdPグループへの追加、オフボーディングはIdPからの削除で設計できます。個別端末に配ったAWS IAMアクセスキーや設定ファイルを後から回収する運用より、棚卸しと失効の責任範囲が明確になります。
セキュリティ部門にとっての価値
AI利用の証跡を自社側に集約できることです。利用メトリクスを自社コレクタに集められれば、「誰が・いつ・どの経路で・どの程度使ったか」をSIEMや監査ログの設計に載せられます。ただし、テレメトリを取得できること自体は監査証跡としての完全性を保証しません。取得項目・保持期間・時刻同期・アクセス制御・改ざん防止は別途設計する必要があります。
また、日次・週次・月次のspend capsをユーザー・グループ・組織単位で設定できるため、異常利用や想定外の大量利用をコスト面からも抑制できます。
つまりClaude apps gatewayは、Claude Codeの便利さを説明する機能ではなく、情報システム部門とセキュリティ部門が「導入を許可できる状態」を作るための統制点です。AI利用統制を考えた時に最初に詰まるのは、モデル選定よりも「誰に使わせ、どの経路に限定し、どう止め、どう説明するか」です。ゲートウェイは、その問いに答えるための有力な選択肢になります。
よくある誤解
「ゲートウェイを入れれば端末側の統制は不要になる」
ゲートウェイが強制できるのは、ゲートウェイを経由するリクエストに対するポリシーです。
端末上でユーザーがログイン先を切り替えたり、別のツールを使ったりする行為そのものは、クライアント側のmanaged settings（forceLoginMethod / forceLoginGatewayUrl）をMDM等で配布して対応します。実際、Anthropicのロールアウト手順自体が、クライアント側のmanaged-settings.jsonでゲートウェイ強制を設定する構成を前提にしています。 経路の統制と端末の統制は別物であり、それぞれ対応する必要があります。
「サードパーティのLLMゲートウェイと同じもの」
この見方も正確ではありません。モデルプロバイダ自身がクライアントとゲートウェイを一体で開発しているため、/loginフローがゲートウェイ対応で、サインイン時に管理設定が自動適用されます。 クライアントと一体で開発されているぶんサインイン時の設定適用などの統合は密ですが、Anthropic一社のモデルに閉じる点は割り切りが必要です。
Anthropicはゲートウェイのプロトコルを公開し、他のゲートウェイ開発者が同じ機能を実装できるようにするとしています。 マルチモデル環境の統制点をベンダーごとに持つか、中立な一点に寄せるかは、これから各社が自社の状況に合わせて判断することになるでしょう。
実務で問題になりやすいポイント
ゲートウェイが新しい重要インフラになる
上流クレデンシャルを一手に握り、全開発者の認証セッションを仲介するコンポーネントであるため、その可用性・パッチ適用・アクセス制御・監査は、IdPやリバースプロキシと同格の扱いになります。公式ドキュメントによれば、PostgreSQLはサインインフローの状態とレート制限カウンタを保持します。保持データは比較的短命ですが、バックアップ・暗号化・障害時の復旧要件（RPO/RTO）は自社構成に応じて設計・検証が必要で、コンテナ自体の運用責任も自社側にあります。
テレメトリの設計
利用メトリクスは自社のコレクタに、自社のネットワークと保持スケジュールで蓄積することになります。 誰がどのモデルをどれだけ使ったかは部門別コスト配賦や監査に使える資産になりますが、それ自体が管理対象の増加になります。利用開始前に取得項目と保持期間を決めましょう。
例外経路の扱い
公式ドキュメントによれば、開発者がサインイン済みの端末では、非対話のclaude -p実行やAgent SDK経由のセッションもゲートウェイのセッションとポリシーの対象になります。一方、人間のサインインを伴わないCI/CDやワークロードとしての利用をどう統制するかは設計上の論点として残るため、そうした自動化はIAMロールやサービスアカウントで別建てにする分離設計を検討することになるでしょう。
技術的・運用的な確認ポイント
導入検討では、次を具体的に確認してください。
- IdP側の準備：IdPにゲートウェイ用のSSO連携アプリを1つ登録します。次にゲートウェイの設定ファイル（gateway.yaml）に、「どのIdPで認証するか」（OIDC issuer）と「上流の推論基盤に接続するための認証情報」の2つを書き込んで、認証まわりの基本構成を作ります。この時、IdP側でグループを部署単位にするか、チームやプロジェクト単位にするかで、「誰に何をどこまで許すか」を制御できる細かさ（グループクレーム）を決定します。
- 上流の選定：Amazon Bedrock（AWS境界内にデータを保つ）、Claude Platform on AWS、Google Cloud、Microsoft Foundry、Claude APIのどれを使うかを検討します。この5つの上流とフェイルオーバーへの対応は、Anthropicの公式ドキュメントに明記されています。Bedrock利用時は、コンテナのIAMタスクロールなどAWSの認証情報チェーンを利用するため、静的鍵なしに接続できます。
- クライアント強制：managed-settings.jsonのforceLoginMethod / forceLoginGatewayUrlをどのような手段（MDMまたはfile-based配布）で配るか
- spend capsの初期値：組織・グループ・ユーザーの3階層のどこに、どの周期で上限を置くか。最初は緩めに敷いて実測し、四半期などのある程度長めのスパンで見直すといいでしょう。なお、上限は利用を抑制するガードレールとして扱い、請求金額を厳密に統制する仕組みと同一視しないよう、集計タイミングや障害時の挙動もあわせて確認してください
- テレメトリ：OTLPコレクタの受け口、取得項目、保持期間、SIEM連携の要否を検討します
- 既存統制との整合：MCP許可リスト、permissions、hooksなど既存のmanaged settings体系とゲートウェイ配布ポリシーの責務分担を整理します
対応方針の比較表
| 方針 | 統制の実態 | コスト可視化 | 退職者対応 | 向いている組織 |
|---|---|---|---|---|
| 現状維持（開発者ごとにクラウド認証情報を配布） | 端末に長期鍵が残る。設定は手配布 | 請求書ベースで事後把握 | 鍵の棚卸しと手動失効が必要 | 小規模な検証段階 |
| server-managed settingsのみ | Claude API直の利用には有効。Bedrock / Vertex経由には適用されない | Analytics APIの範囲内 | IdP＋管理コンソールで対応 | Claude.ai Team / Enterprise中心の組織 |
| Claude apps gateway導入 | IdP認証・サーバー定義ポリシー・全リクエスト強制。鍵はゲートウェイのみ保持 | ユーザー単位の利用計測＋3階層spend caps | IdPでの削除後、セッションTTL（既定1時間）内に失効 | Bedrock / Google Cloud経由で本格展開する組織 |
| サードパーティLLMゲートウェイ | マルチモデル横断の統制点を持てるが、クライアント統合は自前 | 実装依存 | 実装依存 | 複数ベンダーのモデルを併用する組織 |
導入・見直し時のチェックリスト
- 現在、開発者端末に配布済みのクラウド認証情報・APIキーを棚卸ししたか
- Bedrock / Vertex経由のClaude Code利用者数と月間コストを把握しているか
- IdPのグループ設計が、モデル・権限・上限のグループ別制御に使える状態か
- ゲートウェイ自体の運用責任者・パッチ適用・監視の担当を決めたか
- spend capsの初期値と超過時の運用（通知先・解除フロー）を決めたか
- CI/CD・SDK経由の自動化利用を、人間のSSOフローと分離して設計したか
- クライアント側managed settingsでゲートウェイ強制を配布する手段（MDM / file-based）があるか
- テレメトリの取得項目・保持期間・閲覧権限を定めたか
経営層・監査部門への説明ポイント
経営層には、次の3点で説明できます。
- AI開発ツールのアクセス権が人事イベント（入社・退職・異動）と自動連動する構成になり、退職者のアクセス残存という定番の監査指摘のリスクを低減できること（失効はセッションTTL内で完了）。
- AI利用コストが事後の請求把握から、部門・個人単位の事前上限と実測に変わること。
- 開発者端末から長期クレデンシャルを排除することで、端末侵害やシークレット漏えい時の影響範囲が縮小すること。
監査部門に対しては、「誰が・いつ・どのモデルを・どれだけ使ったか」の記録が自社管理のコレクタに、自社の保持ポリシーで残る点を示せます。ベンダー側のログ提供範囲に依存しない証跡設計ができる点を、内部統制との整合の観点から説明できます。
実務担当者が次に取るべき対応ステップ
- 【今週】Claude Codeの利用経路（Claude API直 / Bedrock / Vertex / 個人アカウント）と配布済みクレデンシャルを棚卸しする
- 【2週間以内】Anthropic公式ドキュメントとAWSまたはGoogle Cloudのデプロイガイドを読み、自社の上流（Bedrock / Claude Platform on AWS / Google Cloud）を仮決めする
- 【1か月以内】検証環境でゲートウェイをデプロイし、IdP連携・spend caps・OTLPテレメトリの3点を確認する。対象は1チームを選抜し、小規模で試行運用を開始します。
- 【四半期内】クライアント側managed settingsでのゲートウェイ強制を含めた本番展開計画を作り、CI/CD等の例外経路の設計と利用規程の改訂をセットで進める
まとめ
Claude apps gatewayは、Claude Codeの企業統制で最後まで残っていた「Bedrock / Vertex経由の空白」と「開発者ごとの鍵配布」を、モデルプロバイダ自身が埋めにきたプロダクトです。
既存のmanaged settings・MDM・MCP統制を置き換えるものではなく、経路の統制として重ねる一枚です。
ゲートウェイの構築に着手する前に、まずは自社のClaude Code利用経路の棚卸しから始めてください。鍵がどこに何本あるか分からない状態でゲートウェイだけ足しても、空白は埋まりません。
FAQ
Q1. Claude apps gatewayとは何ですか？
A. Claude apps gatewayとは、Claude CodeおよびClaude Desktop（ゲートウェイ側でのオプトイン設定が必要）の認証・ポリシー・テレメトリ・推論ルーティング・支出上限を一元管理する、Anthropic提供の自社ホスト型コントロールプレーンです。単一のステートレスコンテナとPostgreSQL（14以降）で動作し、2026年6月29日に公開されました。
Q2. どのIdPと連携できますか？
A. 公式にはGoogle Workspace、Microsoft Entra ID、OktaなどのOIDC準拠IdPが例示されています（SAML・LDAPは非対応）。ただしOIDC実装には差があるため、必要なクレーム（email・グループ）、issuer、リダイレクトURIの整合を事前に検証してください。開発者はブラウザのSSOでサインインし、短命セッションを受け取ります。
Q3. コスト上限はどの単位で設定できますか？
A. 日次・週次・月次の支出上限を、組織・グループ・ユーザーの各単位で設定できます。
Q4. 利用データはAnthropicに送られますか？
A. Anthropicの発表では、上流にClaude APIを設定しない限り、推論トラフィックも利用データもAnthropicへは送信されないとされています。テレメトリは自社が運用するコレクタへOTLPで送られます。
Q5. Amazon Bedrock経由の場合、データはどこで処理されますか？
A. AWSの発表では、Bedrock経由のデプロイは推論リクエストをAWSのセキュリティ境界内に保ち、他のBedrockワークロードと同じデータ取り扱い統制を継承するとされています。
Q6. 既存のmanaged settingsやMDM配布は不要になりますか？
A. なりません。クライアントにゲートウェイ経由を強制するには、managed-settings.jsonのforceLoginMethod / forceLoginGatewayUrlを端末側に配布する必要があり、MCP統制やpermissionsなど既存のポリシー体系も引き続き併用します。
おわりに
Claude Codeをはじめとする生成AI・AIエージェントの組織展開では、「どの経路で使わせるか」「誰がいくら使えるか」「辞めた人のアクセスをどう消すか」の設計が先に要ります。
この記事が誰かの役に立てば嬉しいです。
