Claude Apps Gateway
Claude の法人導入の
「配線問題」を、静かに終わらせる。
Anthropic が公開した Claude apps gateway は、Claude Code / Claude Desktop を Amazon Bedrock や Google Cloud で動かす際の SSO・費用上限・失効管理を、たった 1 個のコンテナに寄せます。IdP から抜くだけでアクセスが 1 時間以内に消える——「配布と回収」の往復にかかっていた工数を、静かに刈り取る発表です。
The Bottleneck
Claude Code を配るのに、
なぜ半日かかっていたのか
Amazon Bedrock や Google Cloud で Claude Code を法人展開する際、これまでの現場は毎回同じ壁にぶつかっていました。開発者ごとに Bedrock / Vertex の IAM 資格情報を発行し、ローカルに埋め、退職や異動のたびに手作業で失効させる——AWS や GCP のログではなく Anthropic 側のセッションに紐付いた鍵なので、IdP を落としても API 呼び出しは残り続けます。Anthropic の 2026 年 6 月 29 日の告知は、この「鍵を配って回収する日常業務」を 1 個のコンテナに畳み込むものです。
そこには 費用の見えなさも乗っていました。誰がどのモデルにいくら使ったかは、Bedrock / GCP の請求書を後追いで割り出すか、CloudTrail の生ログを漁るしかない。予算上限もかけようがない。DevOps.com の解説は「情シスは、開発者に Claude Code を配りたいというより、配ったあとが怖い」と指摘しました。ゲートウェイはこの二つの摩擦——鍵の配布と、費用の後追い——を、同時に外しにいっています。
| 従来（直接接続） | Claude Apps Gateway 経由 |
|---|---|
| 開発者ごとに Bedrock / GCP の IAM 資格情報を配布 | 企業 SSO でログイン、1 時間の短命トークン |
| 退職者の失効は手作業、抜け漏れが出やすい | IdP で無効化すればセッション寿命内に消える |
| 予算上限やモデル制限は個別実装 | 組織 / グループ / ユーザー単位で支出上限 |
| 推論費用は請求書の後追いで判別 | ユーザー別に使用量と費用を集計 |
配ることより、
「抜くだけで消える」ほうが、法人には効く。
How It Works
1 コンテナに畳まれた
OIDC リレー
Gateway は Google Workspace / Microsoft Entra ID / Okta などの OIDC IdP に対する relying party として振る舞い、開発者の Claude Code から短命 bearer トークンを橋渡しします。
企業 SSO で開発者がサインイン
Claude Code のバイナリ内蔵のクライアントが企業 IdP に OIDC 認証を投げ、Gateway が発行する 1 時間寿命の bearer トークンを受け取ります。個人の Bedrock / GCP 資格情報を PC に置く必要が消えます。
Gateway が推論を経路制御
ゲートウェイは受けたリクエストをポリシーに従って Bedrock、Google Cloud、または Microsoft Foundry の Claude API に転送。障害時は自動フェイルオーバし、どの供給ラインが落ちても開発者側は気づきません。
IdP を落とせば、1 時間で消える
退職や役割変更時は IdP のユーザーを無効化するだけ。次のトークン更新は失敗し、既存トークンもセッション寿命内に切れます。Anthropic 側に個別の失効依頼を投げる運用が不要になります。
Under the Hood
単一コンテナに
畳み込まれた「制御面」
Gateway は開発者が既にインストールしている claude バイナリと同一で、Postgres を後ろに置いた 単一ステートレス コンテナとして社内に立てます。
ここで見落とせないのが データ経路です。Anthropic のドキュメントは、顧客が Claude API を直接契約していない限り「推論トラフィックも利用量データも Anthropic 側には流れない」と明記しました。つまり、Bedrock 契約企業のプロンプトは AWS の閉域から出ず、Gateway 経由でもテレメトリが Anthropic に返送されない。これはコンプライアンス部門にとっての決定打です。
費用上限は 組織 / グループ / ユーザーの 3 階層で設定でき、実行前ポリシー・実行後アラートの両方に効きます。InfoQ の解説は、Gateway の登場を「Bedrock Claude を触りたい情シスが待っていた最後のピース」と評しています。
Who Benefits
誰に、どう効くのか
同じゲートウェイでも、部門ごとに刺さる場所が違います。
情シス / セキュリティ
SSO 一元化と失効の即時性で、監査対応の詰め所が減ります。Bedrock / GCP を「使わせるが管理できる」形に置き直せる。
経営 / 財務
費用上限を組織単位で置けるので、AI 費の「青天井」感が消える。部門別使用量が可視化され、稟議がラクになる。
開発者 / エンジニア
個人トークンの管理から解放。SSO でログインすれば済み、AWS / GCP のどちらが落ちても Gateway が別ラインに逃がしてくれる。
What's Next / Risk
これで「配れる」フェーズに
入るが、罠も残る
Gateway の登場で Claude Code の法人配布は「配れないから見送り」の言い訳が使えなくなったと言えます。次に企業が問われるのは「配ったあと」——プロンプトの社内ガイドライン、監査ログの保存年限、失効テストの定期実施——といった運用側の詰めです。ゲートウェイ自体は運用を代行してくれません。
反対視点も要ります。第一に、Gateway は Anthropic ロックインを強めます。同じ設計思想の「gateway」を GPT や Gemini にも用意してもらわないと、複数モデル比較検証の摩擦が増える。第二に、Postgres バックエンドを社内で保守する運用負担が生じます。停止するとログイン全滅——SPOF 化しないよう HA 構成の設計が要ります。第三に、費用上限は「事前に切る」ではなく「超過を検知する」しくみなので、暴走エージェントによる短時間の莫大コストは防ぎきれない可能性がある。上限の粒度と、追加のレート制限を組み合わせる運用が現実解になります。
推奨アクションは 3 つ。（1）情シスは PoC で IdP 連携と失効テストを最初に通す。（2）財務は月次で ユーザー別支出レポートを回す運用に切り替える。（3）開発チームは Gateway 経由の フェイルオーバ挙動をカオステストで確認しておく。この 3 点が済めば、Bedrock Claude Code は「触れる SaaS」になります。