はじめに

私はClaude CodeをAmazon Bedrock経由で利用するチームの運用を担当しているのですが、ずっと悩みの種だったのが認証とコスト管理です。
以前の記事ではメンバーごとにアプリケーション推論プロファイルを作成してコストを可視化する方法を紹介しましたが、正直に言うとこの運用はかなりしんどくなってきていました。

そんな中、Claude apps gatewayというソリューションが登場しました。
2026年7月にはAWS公式ブログでもBedrockと組み合わせた構成が紹介されています。

本記事では、Claude apps gatewayとは何者なのか、既存のCloudWatchダッシュボードによるメトリクス収集と何が違うのか、そして実際にAWSで構築したアーキテクチャとハマりどころをまとめます。

これまでの運用とつらみ

まず前提として、私たちの環境には社内コンプライアンス上の強い制約があります。(JTCあるある)
主には推論を国内リージョンに限定すること、そして入出力データを保持させないこと(ゼロデータ保持)です。
この要件を満たせるのがAmazon Bedrockだったため、Claude Codeは東京リージョンのBedrock経由で利用しています。
モデルはJPプレフィックス付きの国内クロスリージョン推論プロファイル(東京と大阪の間でのみルーティングされるプロファイル)を使い、推論が国外に出ないようにしています。

その上で、メンバーごとのLLM利用量を把握するために、アプリケーション推論プロファイルを個人単位かつモデル単位で発行してコスト配分タグを付けていました。
この方式は確かに動くのですが、運用負荷が重いのが難点でした。

新しいモデルがリリースされるたびに人数分のプロファイルを作成し、開発者が増えればモデル数分のプロファイルを作成します。
例えば、10人のチームでOpus,Sonnet,Haikuの3モデルを使うだけでプロファイルは30個です。
モデルの世代交代も頻繁にあるので、作っては消しの繰り返しで、管理台帳とAWS上の実体はすぐズレていきます。

認証まわりの開発者体験にも課題がありました。
開発者は毎朝 aws login を実行してブラウザで認証し、その一時クレデンシャルでBedrockにアクセスします。(これも社内制約でIdentityCenterによるSSOが使えないのが背景...)
このセッションは1日で切れるため、翌日また同じ操作が必要です。
Claude Codeを使いたいだけなのにAWSの認証操作が毎日挟まるのは、地味にストレスでした。

さらに、利用状況のメトリクス収集も自前で設計する必要がありました。
Claude CodeはOpenTelemetryでメトリクスを出せるのですが、どのメトリクスを収集するか、コレクターをどこに立てるか、ユーザーをどう識別するかを全部自分たちで決めて作り込む必要がありました。

Claude apps gatewayとは

Claude apps gatewayは、開発者のClaude Codeクライアントとモデルプロバイダーの間に立つセルフホスト型のゲートウェイです。
Anthropic自身が開発しているもので、私も最初見た時に驚いたのですがなんと claude バイナリに同梱されています。
つまりラップトップでClaude Codeを動かすのと同じ実行ファイルが、 claude gateway --config gateway.yaml と打つだけでゲートウェイサーバーになります。

出典: Introducing Claude apps gateway for AWS (AWS Machine Learning Blog)

開発者は個別のAPIキーやAWSクレデンシャルを一切持たず、会社のIdP(IDプロバイダー)へのSSOサインインだけでClaude Codeを使えるようになります。
Bedrockへの認証情報はゲートウェイだけが持ち、誰が何をどれだけ使えるかはゲートウェイが一元管理します。

AWSブログでは、ゲートウェイの責務として次の5つが挙げられています。

まずIdentityです。
OIDC(OpenID Connect)準拠のIdPと連携し、ブラウザSSOで短命トークンを発行します。
Okta、Microsoft Entra ID、Google Workspace、Keycloakなどが使えます。

次にPolicyです。
モデルのallowlistやmanaged settings(管理者が強制する設定)をIdPのグループ単位でサーバー側から配布し、開発者側では上書きできません。

3つ目はTelemetryです。
トークン数、モデル、ユーザーID、レイテンシといった利用メトリクスを、OTLP(OTELの転送プロトコル)でCloudWatchやPrometheusなどの好きな観測基盤に送れます。

4つ目はRoutingです。
クライアントはAnthropicのMessages APIを話し、ゲートウェイがBedrock、Claude Platform on AWS、Google Cloud、Microsoft Foundryといった各アップストリーム向けに変換します。
リージョンやプロバイダーの切り替え、フェイルオーバーも開発者に意識させず行えます。

最後にSpend capsです。
ユーザー、グループ、組織の単位で日次・週次・月次の支出上限を設定でき、超過するとリクエストがブロックされます。

インフラ要件はシンプルで、Linuxで動くコンテナ1つとPostgreSQL(サインイン状態や支出カウンタの保存先)だけです。
ただしセキュリティ上の設計として、ゲートウェイはプライベートネットワークのアドレスでしか動かせません。
Claude Code側が /login 時にゲートウェイのホスト名がプライベートIPに解決されることを検証するため、インターネットに公開する構成はそもそも組めないようになっています。

CloudWatchのダッシュボードとどう違うのか

「Claude Codeの利用状況を見るならCloudWatchのダッシュボードがすでにあるのでは」と思った方もいるはずです。
私も最初はそこが混乱したので、位置関係を整理します。

従来のOTELメトリクス収集

Claude Codeは、トークン使用量、セッション、コード編集、ツール呼び出し、コストといったメトリクスをOTELで送信できます。
AWS公式のサンプル実装であるGuidance for Claude Code with Amazon Bedrockは、OTel CollectorをECS Fargateに立ててこれらを集約し、ユーザー別のCloudWatchダッシュボードを構築する方式でした。
私たちが当初検討していたのもこの延長で、コレクターの設計もメトリクスの取捨選択も自前でやる前提です。

新機能のCloudWatch Coding Agent Insights

そこに2026年7月、CloudWatch Coding Agent Insightsが発表されました。
CloudWatchコンソールのGenAI Observabilityメニューに追加された、AIコーディングエージェント専用の組み込みダッシュボードです。
ダッシュボードを自分で作成したりインポートしたりする必要はなく、所定の形式のメトリクスが届き始めると自動で表示されます。
Claude Codeだけでなく、OpenAI CodexやGitHub Copilotにもエージェント別のタブで対応しています。

見られるのは、トークン消費量、ターンごとのレイテンシ、ツール呼び出し、APIリクエスト、承認操作などです。
これらを組織・部門・チーム・コストセンター・ユーザーといった組織属性でスライスして比較できるのが特徴で、どのチームで導入効果が出ているか、支出のトレンド、モデルごとの費用対効果といった、リーダー層が見たい切り口を最初から想定した作りになっています。
データはCSVでエクスポートでき、メトリクスはPromQL(Prometheus由来のクエリ言語)で検索できるので、独自のダッシュボードやアラームを組むこともできます。
料金は専用の課金があるわけではなく、CloudWatchの標準のOTELメトリクス取り込み料金だけで使えます。

1つ注意があるとすれば、ダッシュボードが期待するメトリクスの形が決まっていることです。
CloudWatchのOTLPエンドポイントに送ること、そして user.email や team.id などの識別属性をOTELのリソース属性として送ることが前提で、この形が崩れるとダッシュボードに反映されません。

ゲートウェイとの位置関係

そのCloudWatchのドキュメントでは、Claude Codeからメトリクスを送る設定として2つのパスが案内されています。
1つは各開発者のClaude CodeからbearerトークンでCloudWatchのOTLPエンドポイントに直送するパスで、個人や小規模チーム向けです。
もう1つが、Claude apps gatewayを経由して組織展開するパスです。

ではこの2つは何が違うのか。
ひとことで言うと、OTELメトリクスの直送は「観測」の仕組みで、ゲートウェイは「観測に加えて制御」の仕組みです。

観点	OTELメトリクス直送	Claude apps gateway
主な役割	利用状況の観測	アクセス・ポリシー・コストの制御
ユーザー識別	クライアント側の環境変数で自己申告	SSOサインインしたIdP上のID
設定の強制力	各開発者の設定次第	サーバー側で強制(テレメトリ送信先もピン留め)
支出上限	なし(見るだけ)	ユーザー/グループ/組織単位でブロック可能

従来方式では、メトリクス送信の設定は各開発者マシンの環境変数に依存します。
設定漏れがあればその人のメトリクスは欠落しますし、ユーザー識別も OTEL_RESOURCE_ATTRIBUTES に自分で名乗った値が使われるだけです。
つまり性善説の仕組みで、集計の網羅性を担保するには配布と統制の作り込みが別途必要でした。

ゲートウェイ経由では、利用の記録はSSOでサインインした本人のIDに紐づいてサーバー側で行われます。
テレメトリの送信先はゲートウェイが配布する設定でピン留めされ、ローカルの OTEL_* 環境変数より優先されるため、開発者側の設定ミスや細工で計測から漏れることがありません。
そして計測だけでなく、支出上限による自動ブロックまで踏み込めます。

大事なのは、この2つが排他ではないことです。
ゲートウェイはテレメトリをOTLPで任意の宛先にファンアウトできるので、CloudWatchのOTLPエンドポイントに送ればCoding Agent Insightsのダッシュボードがそのまま使えます。
私たちにとっては「収集と可視化はCloudWatchにお任せ、認証やコスト制御はゲートウェイ」という分担がそのまま組める形です。

導入すると何が嬉しいのか

最初で語った運用のつらみに対して、導入メリットを整理します。

【メリット1】アプリケーション推論プロファイルの量産からの解放

ゲートウェイはサインインしたユーザー単位で利用額を計測するため、個人を識別する目的でAWS側のリソースを分ける必要がなくなります。
Bedrock側は共通の推論プロファイルを1系統用意するだけでよく、個人単位×モデル単位のプロファイル発行は不要になります。

新モデルへの対応は gateway.yaml の models: にエントリを1つ追加して再デプロイするだけです。
開発者が増えたときはKeycloakにユーザーを追加するだけで、AWS側の作業はゼロです。
「モデルリリースのたびに人数分のプロファイルを作る」運用から解放されるのは、運用者としては一番嬉しいポイントでした。

【メリット2】毎朝のaws loginからの解放

開発者はAWSクレデンシャルを一切持たなくなります。
Bedrockへの認証はゲートウェイのECSタスクロールが担い、開発者はブラウザで1回SSOサインインするだけです。
セッションはTTL(この構成では8時間)の期限前にサイレント更新されるので、毎朝の認証儀式は不要になります。

【メリット3】社内ツールと認証を一元化できる

私たちはIdPとしてKeycloakを自前で立てており、GitLabやRedmineの認証もそこに集約しています。
ゲートウェイも同じKeycloakのレルムにクライアントとして登録したので、開発者から見れば「いつもの社内アカウント」でClaude Codeにもログインできることになります。
ツールごとのパスワード管理から解放されるうえ、退職者のアカウントをIdPで無効化すればゲートウェイのセッションもTTL以内に失効します。
オフボーディングの抜け漏れ対策として、これはかなり効きます。

【メリット4】メトリクス収集の設計をほぼお任せできる

どのメトリクスを取るか、ユーザーをどう識別するか、コレクターをどう立てるかを自前で設計しなくても、ゲートウェイが標準でトークン数・モデル・ユーザーID・レイテンシを記録してくれます。
誰がいくら使ったかはSpend limitsのAPIで取得でき、支出上限の変更履歴も監査APIで追えます。
なお、ゲートウェイはプロンプトや応答の中身を保存しません。
ログやトレースまで収集するかは宛先ごとにオプトインで選ぶ設計になっており、ゼロデータ保持の要件とも相性が良いです。

構築したAWSアーキテクチャ

AWSブログにはECS/EKS/EC2上にゲートウェイを置くリファレンス構成が載っています。

出典: Introducing Claude apps gateway for AWS (AWS Machine Learning Blog)

今回はこれをベースに、既存環境(VPCとKeycloak)へ相乗りする形で開発環境を構築しました。
実際の構成はこうなっています。

開発者は同一VPC内の仮想デスクトップ(WorkSpaces)から利用するため、Claude CodeのCLIもサインイン用ブラウザもVPC内で完結します。
ゲートウェイがプライベートアドレス必須という制約とも相性が良く、VPNやResolverエンドポイントの追加は不要でした。

ゲートウェイの設定ファイルの肝になる部分はこんな形です。

gateway.yaml(抜粋)

upstreams:
  - provider: bedrock
    region: ap-northeast-1
    auth: {}   # 空にするとFargateのタスクロールが自動で使われる

# 組み込みのモデルカタログはUS向けプロファイルを参照するため無効化し、
# 国内クロスリージョン推論プロファイルを明示的に指定する
auto_include_builtin_models: false
models:
  - id: claude-opus-4-8
    label: Claude Opus 4.8
    upstream_model: { bedrock: jp.anthropic.claude-opus-4-8 }
  - id: claude-sonnet-4-6
    label: Claude Sonnet 4.6
    upstream_model: { bedrock: jp.anthropic.claude-sonnet-4-6 }

managed:
  policies:
    - match: {}
      cli:
        availableModels: [claude-opus-4-8, claude-sonnet-4-6]
        enforceAvailableModels: true

モデルIDは環境によって異なるので、 aws bedrock list-inference-profiles で実際のIDを確認してから設定します。

開発者側の設定は、管理者が配布するmanaged-settings.jsonに2行書くだけです。

/etc/claude-code/managed-settings.json

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://gateway.claude.<ドメイン>"
}

これで開発者が claude を実行するとCloud gateway画面が開き、ブラウザでKeycloakなどのIdPにサインインすれば完了です。
モデルallowlistなどのポリシー本体は、サインイン後にゲートウェイ自身がIdPグループ単位で配信し、クライアントが起動時と1時間ごとのポーリングで適用します。
なので端末側にファイルとして配るのは、入口を指すこの2行だけで済みます。

支出上限はAdmin APIで設定します。
たとえば組織全体のデフォルトを月$500/人にするならこうです。

curl -sS https://gateway.claude.<ドメイン>/v1/organizations/spend_limits \
  -H "x-api-key: $WRITE_KEY" -H "Content-Type: application/json" \
  -d '{"scope": {"type": "organization"}, "amount": "50000", "period": "monthly"}'

設計にあたっての判断もいくつか記録しておきます。

IdPにCognitoではなくKeycloakを選んだのは、既存資産があったことに加えて、Cognitoが offline_access スコープに対応しておらずセッションのサイレント更新が効かない(1時間ごとに再ログインになるリスクがある)ためです。
Keycloakは公式ドキュメントに設定手順が載っている動作確認済みIdPなので、安心感もありました。

開発者向けの利用状況の可視化は、ALBのOIDC認証とLambdaを組み合わせたミニWebアプリにしました。
ゲートウェイのSpend limits APIをログイン本人のIDに絞って呼び出し、日次・週次・月次の利用額と上限を表示するだけの小さなものです。
Grafanaはユーザー単位課金が発生し、CloudWatchダッシュボードは「本人の分だけ見せる」制御ができないため、この方式に落ち着きました。
追加コストはほぼゼロです。
実際の画面はこんな形です。

新規に追加したインフラの月額は、Fargate、内部ALB、RDS(シングルAZ)、Secrets Managerなどを合わせて概算$85程度の見込みです(Bedrockの推論費は別)。
（結構高い...）

つまずいたところ

構築の過程でハマった点、事前に知らないと苦労する点を挙げます。

【つまずき1】公式のコンテナイメージが存在しない

ゲートウェイはバイナリ同梱とはいえ、公式のコンテナイメージなどは提供されていません。
イメージは公式インストールスクリプトで claude バイナリを取得して自前でビルドしました。

【つまずき2】組み込みモデルカタログはUS向け

デフォルトの auto_include_builtin_models: true のままだと、モデル名はUSのクロスリージョン推論プロファイル( us.anthropic.* )にマッピングされます。
東京リージョンで国内に閉じた推論をしたい場合はこれを無効化し、 models: ブロックでJPプレフィックスのプロファイルを明示指定する必要があります。
国内リージョン縛りの環境では必須の設定です。

【つまずき3】 ALBはIPv4専用にする

内部ALBをdual-stackにすると、パブリック扱いのIPv6アドレス(AAAA)が返ってしまい、Claude Codeの /login がプライベートアドレス検証で拒否します。
公式のトラブルシューティングにも記載のある既知の挙動で、ALBのIPアドレスタイプはipv4固定にしました。

【つまずき4】 Gateway の向き先は `managed-settings.json` 限定

ユーザー自身の settings.json に書いても無効。管理者配布である設定ファイルでしか効かないのでMDMツールなどによる配信が必要になります。
ただ、これに関してはGatewayによる一括統制が目的なのでコンセプトとしては一貫しているなと感じました。

知っておきたい制約

導入判断に関わりそうな制約もフェアに書いておきます。

まず、ゲートウェイ経由のセッションではWebSearchツールが使えません。
ゲートウェイがどのプロバイダーにルーティングするかをCLI側が確認できないため、無効化される仕様です。
1時間の拡張プロンプトキャッシュTTLも使えず、キャッシュは5分TTLになります。
WebSearchが使えないのは正直痛いなと思っているのですが、ちょうどBedrock AgentCore Gatewayのビルトインコネクタとしてマネージドなウェブ検索ツールが提供され始めたので、これをClaude CodeにMCPエンドポイントとして登録すれば代替になるんじゃないかと密かに目論んでいます。
うまくいったら別記事で書くつもりです。

CIなどの無人実行はゲートウェイ経由にできません。
サインインが必ずブラウザのデバイスフローを通るため、サービストークンのような仕組みがないからです。
私たちもCIパイプラインだけはBedrock直接続のまま残しています。

Spend limitsの金額はトークン数×定価から算出される概算で、AWSの割引は反映されません。
公式にも「請求書ではない」と明記されており、暴走を止めるサーキットブレーカーと割り切って、正式なコストはAWS請求で突合する運用です。
また、全員がゲートウェイの同一タスクロールでBedrockを呼ぶため、AWS側の請求では個人別の内訳が取れなくなります。
個人別の利用状況はゲートウェイのAPIかテレメトリで見る、という役割分担になります。

管理UIはなく、設定変更はYAMLを書き換えてコンテナを再デプロイするスタイルです。
モデル追加程度なら苦になりませんが、頻繁にポリシーをいじる運用を想定しているなら知っておいたほうがよいです。

動作確認

デプロイ後、Claude Code を実行すると、Cloud gateway画面が開きます。
managed-settings.jsonで配布したゲートウェイURLが最初から入力されているので、開発者はEnterを押すだけです。

Enterを押すとブラウザでデバイス確認画面が開きます。
CLI側に表示されたコードと一致していることを確認して続行します。

続いてKeycloakのサインイン画面にリダイレクトされるので、いつものアカウントでログインします。

サインインが完了するとブラウザに完了画面が表示され、CLI側も数秒で接続完了になりました。

以降の起動ではステータス表示にCloud gatewayと出るようになり、モデル選択も gateway.yaml のallowlistに沿った内容だけが表示されます。

まとめ

個人×モデルで推論プロファイルを量産する自前運用から、Claude apps gatewayによる一元管理へ移行する話を書きました。
国内リージョン縛りやゼロデータ保持といった制約のためにBedrock経由でClaude Codeを使っている組織は少なくないと思いますが、そういう環境ほど認証・コスト管理・メトリクスの作り込みが自前になりがちで、ゲートウェイの恩恵は大きいはずです。

一方で、WebSearchが使えない、CIは対象外といった割り切りも存在するので、全部をゲートウェイに寄せるのではなく、OTELベースのCloudWatchダッシュボードやBedrock直接続と組み合わせて適材適所で使うのが現実解だと感じています。

参考