7月15日、Steef-Jan Wiggersが「AWS Ships Claude Apps Gateway as Self-Hosted Control Plane for Claude Code and Claude Desktop」と題した記事を公開した。AWSがClaude CodeおよびClaude Desktop向けにセルフホスト型コントロールプレーン「Claude Apps Gateway」を提供開始したというニュースだ。企業がAIコーディングツールを全社展開しようとすると、決まって同じ壁にぶつかる。セキュリティ部門とファイナンスが「誰が何にいくら使っているか見えない」と言い出し、パイロットから先に進めなくなる。このGatewayが直接狙い撃ちにするのは、まさにその問題だ。支出上限・ポリシー強制をサーバーサイドで完結させる単一のコントロールポイントを提供することで、組織ガバナンスの欠如がAI展開を止めるという構造的な詰まりを解消する。

エンタープライズ展開を阻む「可視化の壁」

Claude Apps Gatewayは、開発者ごとのクラウド認証情報・手動配布の設定ファイル・個別の支出管理ツールをまとめて置き換える単一のコントロールポイントとして機能する。推論リクエストはAmazon BedrockまたはClaude Platform on AWSへルーティングされる。

エンタープライズ営業のChristopher Dorseyは、このコスト可視化機能の意義をLinkedInでこう語っている。

Every enterprise AI rollout I've been around stalls in the same spot: the champion loves it, then IT and finance can't see who's spending what, so the whole thing gets capped at a pilot. Spend caps and visibility enforced server-side make that pretty much moot.

（意訳：どの企業AIロールアウトも同じ場所で止まる。現場は好きでも、ITとファイナンスが支出を把握できず、パイロット止まりになる。サーバーサイドでの支出上限と可視化でその問題はほぼ解消される。エンタープライズへの販売で「ノー」が出る理由は、製品ではなくセキュリティと調達部門がガバナンスを取れないことだった。）

ゲートウェイが担う5つの責務

Gatewayは以下の5機能をカバーする。

• アイデンティティ: OpenID Connect（OIDC）準拠のIdPに対するリライングパーティとして機能。開発者はブラウザSSO（シングルサインオン）でサインインし、短命トークンを受け取る。IdPからユーザーを削除するとセッションは設定した有効期限内に失効する。
• ポリシー: 管理者がIdPグループ単位でマネージド設定を定義。許可モデル、ツール権限、デフォルト値を指定でき、開発者がローカルで上書きすることはできない。
• テレメトリ: クライアントがすべてのリクエストに使用メトリクスを付与し、ゲートウェイがOpenTelemetry Protocol（OTLP）経由でAmazon CloudWatchやAmazon Managed Service for Prometheusなどのコレクターに転送する。
• ルーティング: ゲートウェイが上流クレデンシャルを保持し、開発者の代わりにリクエストを転送。AWSリージョンやアカウントをまたいだフェイルオーバーも設定可能。
• 支出上限: 組織・グループ・ユーザーごとに日次・週次・月次の上限を設定でき、超過すると以降のリクエストをブロックする。

デプロイ構成：ステートレスコンテナ一本

デプロイ構成はシンプルだ。ステートレスコンテナ一本で動作し、Amazon ECS・EKS・EC2上に内部向けApplication Load Balancer経由で配置できる。短命なサインイン状態とレートリミットカウンターはAmazon RDS for PostgreSQLが保持する。

設定は起動時に読み込む単一のYAMLファイルで完結する。BedrockへのアクセスはコンテナのIAMタスクロールを使うため、静的クレデンシャルは不要だ。モデル識別子はAnthropicのAPIと同じ形式で記述でき、Bedrock ARNや推論プロファイルを意識する必要はない。

なお、元記事ではゲートウェイコンポーネントがClaude Code CLIと密接に統合された形で提供されると説明されており、すでにCLIをインストール済みの開発者は追加の専用バイナリなしに利用できるとされている。

Bedrockとの組み合わせで「データがAWS外に出ない」

Bedrockと組み合わせた場合、推論リクエストはAWSのセキュリティ境界内にとどまり、他のBedrockワークロードと同じデータ取り扱いコントロールを継承する。データレジデンシー要件（データの保存・処理を特定の地域に限定すること）がある組織向けにAWSはBedrockを推奨している。Claude Platform on AWSはAnthropicのネイティブプラットフォーム体験を求めつつ、AWSの認証・課金から離れたくないチーム向けに位置づけられている。

対応する上流は、Amazon Bedrock・Claude Platform on AWS・Google CloudのAgent Platform・Microsoft Foundry・Anthropic APIと幅広い。

リリース直後に浮かんだ「ワークロードアイデンティティ」問題

リリース翌日には、ゲートウェイがまだカバーしきれていないエッジケースについての議論がLinkedInに上がった。Christoph Klingspor氏は、AWSでAnthropicを利用していない通常サブスクリプション企業を念頭に、Claude CodeにIAMロール付きのアイデンティティを持たせる方法を問い、AWS Private CAを使う案を提示した。

AWSのセキュリティリードであるShweta S.氏はこれに対し、IAM Roles Anywhereとの組み合わせを補足した。

Good instinct on Private CA — but the piece that gives it an identity+role is IAM Roles Anywhere. Private CA (or your own existing CA) issues the X.509 cert; Roles Anywhere swaps it for temporary AWS creds tied to an IAM role, so no long-lived keys.

（意訳：Private CAの勘は正しい。ただ、アイデンティティとロールを結びつけるのはIAM Roles Anywhereだ。Private CA（または既存CA）がX.509証明書を発行し、Roles Anywhereが一時的なAWSクレデンシャルに交換する。長命なキーは不要になる。）

IAM Roles AnywhereはAWS外のワークロードに対してIAMロールを付与する仕組みで、X.509証明書を使って一時クレデンシャルを取得できる。OIDC認証が前提のGatewayと組み合わせることで、通常サブスクリプション環境でも長命なキーを排除した構成が取れる点は、セキュリティチームにとって注目すべき具体策だ。

コントロールレイヤーの所在地が変わる

このリリースは、AIコーディングツールのコントロールレイヤーがどこに置かれるかという問いを提起している。エンタープライズ向けのアイデンティティ管理・ポリシー・コスト帰属・支出上限が、これまでサードパーティゲートウェイや内製ツールが担っていた領域を、モデルプロバイダー自身がファーストパーティインフラとして提供する形になった。

Anthropicは、ゲートウェイが使用するプロトコルを公開すると表明しており、他のゲートウェイ開発者も同じ機能を実装できるとしている。今後のプラットフォームチームが向き合う問いは、「ベンダーごとのゲートウェイか、マルチモデルをまとめる中立的なコントロールポイントか」になるだろう。

なお、同様のゲートウェイはGoogle CloudもCloud Run向けのデプロイ手順を公開しており、AWS・Anthropic・Google Cloudの三社がそれぞれ同一コントロールプレーンのファーストパーティ展開ガイドを出した状態だ。

Claude Apps GatewayはすでにGAとなっており、Claude Codeのドキュメント（※リンク先URLは公開前に要確認）およびAWSのサンプルリポジトリでデプロイ例が公開されている。

詳細はAWS Ships Claude Apps Gateway as Self-Hosted Control Plane for Claude Code and Claude Desktopを参照していただきたい。