Claude apps gateway for AWSとは？Bedrock接続の構成要件と導入判断

Claude apps gatewayは、開発者の手元のClaude Codeと社内が契約するモデル提供元の間に置く、自社ホスト型のゲートウェイです。上流にAmazon Bedrockを選べば推論トラフィックは自社のAWSアカウント内で完結し、開発者はAPIキーもAWSの資格情報も持たずに社内のSSOでサインインします。AWSのAI系公式ブログは2026年7月8日付でこの構成を紹介し、ECS FargateまたはEKS、Amazon RDS for PostgreSQL、AWS Secrets Managerを使った参照構成を示しました。この記事では、AWS上での構成要素、導入前の前提要件、ゲートウェイ経由で使えなくなる機能、受託開発の現場で採用してよい条件と見送る条件を整理します。仕様は2026年8月10日時点の公開ドキュメントに基づきます。

まとめ：Claude apps gateway for AWSの採用条件と見送る判断

この制御面が効くのは、Claude Codeを部署をまたいで配り始め、開発者ごとにAWSの資格情報を配るのが限界に来た組織です。上流の資格情報はゲートウェイ側だけが持ち、開発者は社内IdPのアカウントでサインインする。退職者の遮断はIdPの無効化で完結し、既定1時間のセッション寿命の範囲で失効します。開発者が10人に満たない規模なら、導入の意味は薄い。

採用の前提は4つ揃っているかで判断できます。Claude Codeがサーバ側と開発者側の両方でv2.1.195以降、OIDCに対応したIdPを運用中、プライベートネットワーク上にHTTPSの内部エンドポイントを立てられる、ゲートウェイサーバをLinuxで動かせる。SAMLやLDAPしか使えない組織、Windowsサーバしか置けない組織は、この時点で対象外です。

見送るべき場面もはっきりしています。CIパイプラインの認証をここに寄せる計画なら、設計を見直してください。無人実行向けのサービストークンがなく、サインインは必ずブラウザのデバイスフローを通ります。すでにLiteLLMなどで要件を満たせているなら、乗り換えない。複数顧客のテナントを1台にまとめる構想も成立しません。受け付けるOIDC issuerが1つだけだからです。

Claude apps gatewayの位置づけとAWS上流2系統の選び分け

この製品が既存のAIゲートウェイ製品群のどこに入るかを先に押さえます。汎用のLLM中継層ではなく、Claude CodeとClaude Desktopという特定のクライアントのための制御面です。

claudeバイナリ同梱のセルフホスト制御面という位置づけと5つの役割

Claude apps gatewayは独立した配布物ではありません。開発者のPCでClaude Codeを起動するのと同じclaudeバイナリに同梱されており、サーバ側ではclaude gateway --config gateway.yamlで起動します。CLIが送るヘッダやフィールドを運用側が許可リストで追いかける作業は発生しません。

公式ドキュメントは、この層が担うものを5つ挙げます。上流の資格情報を自社インフラ内だけに置く保管、IdPのグループをモデル許可リストへ対応づけるアクセス制御、claude.ai管理コンソール経由のサーバ管理設定を置き換える設定配信、OTLPで自社の収集基盤へ流すテレメトリ、プロバイダやリージョンをまたぐ上流ルーティング。既存のAPIゲートウェイとの違いはAIゲートウェイとは何か（役割と導入判断）で整理しています。

BedrockとClaude Platform on AWSという2つの上流の選び分け

AWS上の上流は2つです。Amazon Bedrockは、AWSのセキュリティ境界の内側で推論を回す構成。Claude Platform on AWSは、Anthropicが運用するClaude APIをAWSの認証とAWS Marketplaceの請求で使う構成です。ゲートウェイから見ると、上流エントリと資格情報、必要なIAM権限が変わるだけで、他は共通になります。

データ所在地の要件が明文化されている案件なら、Bedrockに寄せる判断が先に来ます。両方を登録してフェイルオーバー順を決めることもでき、開発者側は設定を変えずに切り替えを受け取れる。なおBedrockでも対象はbedrock-runtimeエンドポイントで、Mantleエンドポイントは非対応です。提供形態そのものはAWS上でClaudeを利用する仕組みと提供形態の全体像で扱っています。

導入前に満たす前提要件とプライベートネットワーク限定という制約

導入判断の大半は、機能比較ではなく前提要件の可否で決まります。ここを飛ばして構築に入ると、サインインの段階で止まる。

Claude Codeの必須バージョンとOIDC専用という2つの前提条件

バージョン要件は3段階です。claude gatewayサブコマンドとゲートウェイ経由のサインインはv2.1.195で入り、サーバとすべての開発者のPCの両方がこれ以降でなければ動きません。Claude Platform on AWSを上流にするならサーバ側にv2.1.198以降、Claude Desktopを接続するならv2.1.203以降。さらにサーバはネイティブバイナリが必須で、Node上で動くClaude Codeでは起動時に止まります。

認証はOIDC専用で、Okta、Microsoft Entra ID、Google Workspace、Keycloak、Dexなど準拠のIdPなら動きます。SAMLとLDAPは対象外で、必要ならOIDCブリッジを前段に置く構成に。ストアはPostgreSQL 14以降で、支出上限を設定しないうちは短命の認証状態が数KB載るだけ。有効にすると支出・監査・IDのテーブルが永続化されるため、その時点からバックアップ対象に入れてください。

公開アドレスを拒否するログイン検査とLinux限定というサーバ制約

もっとも見落とされやすいのがネットワークの条件です。Claude Codeはサインイン時にゲートウェイのホスト名を解決し、返ってきたIPアドレスがすべてプライベート範囲であることを確認します。RFC 1918、リンクローカル、CGNATの100.64.0.0から始まる範囲、IPv6のULA、ループバックのいずれにも収まらなければ拒否。信頼したゲートウェイは開発者のPCでコマンドを走らせる設定を配れる立場にあるため、公開アドレスでの運用が禁じられています。

検査は解決されたすべてのIPに対して走ります。実務でよく踏むのが、内部ALBをデュアルスタックで作ったときに公開レンジのAAAAレコードが出て、サインインが拒否される事象。ALB作成時に--ip-address-type ipv4を指定して回避します。サーバのOSはLinuxのみで、macOSはローカル開発用途に限られ、Windowsサーバは対象外です。

AWS上の参照構成とECS Fargate・EKSで分かれる資格情報の渡し方

公式ドキュメントのAWS向けページは、本番構成そのものではなく「顧客管理インフラの動く例」として参照構成を示しています。部品の役割を理解して置き換える前提の資料です。

内部ALBとRDS・Secrets Managerで組む参照アーキテクチャの構成要素

参照構成の要素は6つ。ECS on FargateのサービスまたはEKSのDeployment、イメージを置くAmazon ECRリポジトリ、プライベートサブネットに置く公開アクセス無効のRDS for PostgreSQL、JWT署名鍵とOIDCクライアントシークレットとPostgres接続文字列を入れるSecrets Managerの3シークレット、Bedrock呼び出し権限を持つIAMロール、HTTPSを受ける内部ALBです。

セキュリティグループは3段の鎖で組みます。社内ネットワークからALBへ443、ALBからゲートウェイへ8080、ゲートウェイからPostgresへ5432。データベースはPostgres 16に固定した例が示され、インスタンスクラスdb.t4g.micro、ストレージ20GBで足ります。パラメータグループにrds.force_ssl=1を入れて平文接続を拒否し、接続文字列はsslmode=verify-fullで証明書の連鎖とホスト名まで検証する形に。ECSのタスク定義例はCPU 1024、メモリ2048、X86_64です。

ECSタスクロールとEKSのIRSAで分かれるBedrock権限の与え方

Bedrockを呼ぶ権限はbedrock:InvokeModelとbedrock:InvokeModelWithResponseStreamの2つ。注意点は付与先のARNで、クロスリージョン推論プロファイルのARNと、その裏側にあるファウンデーションモデルのARNの両方を対象にする必要があります。片方だけだと呼び出しが通りません。米国リージョン以外なら、そのジオの推論プロファイルIDを設定に書き、ポリシーのARNプレフィックスもそろえます。

資格情報の渡し方はコンピュート基盤で分かれます。ECSではタスクロール、EKSではIRSAを使い、設定ファイル側の上流ブロックはauthを空にしてAWSの既定資格情報チェーンに任せる形。静的なアクセスキーをコンテナに埋めません。ECSではもう1つ、イメージのpullとシークレット注入のための実行ロールが要ります。このロールのSecrets Manager読み取り権限は、シークレットごとのARNを個別に列挙する書き方が推奨。末尾をアスタリスクにすると前方一致になり、同じ接頭辞の別シークレットまで読めてしまうためです。

構築でつまずきやすい4つの設定値と公式ドキュメントが示す回避手順

公式のトラブルシュート表から、AWS固有でつまずきやすいものを挙げます。

1. 内部ALBはIPv4のみで作成し、公開レンジのAAAAを出さない
2. ALBのアイドルタイムアウトを既定60秒から3600秒へ引き上げる
3. RDSの証明書バンドルをイメージに同梱し、CA信頼の環境変数を設定する
4. ヘルスチェックは、ストア到達性まで確かめる待機用のパスを指定する

2つ目のアイドルタイムアウトは、長いプロンプト処理や拡張思考で出力が途切れた区間にストリーミング接続が切られる事故につながります。3つ目のRDS証明書も見落としやすい箇所。sslmode=verify-fullを指定する以上、AWSのRDS証明書バンドルをイメージに入れて信頼させないと起動時にTLS検証エラーで落ちます。

開発者への配布方法とゲートウェイセッションに強制される5つの制約

ゲートウェイが動いても、接続先が開発者のPCに届かなければ誰もサインインできません。

MDMで配る3つの設定キーと開発者が手動では設定できない理由

配るのはマネージド設定ファイルの3つのキーです。ログイン方式をゲートウェイに固定するキー、ゲートウェイのURLを指すキー、Claude Desktopが起動する子セッションへ送信先の許可リストを引き継がせるマージ指定。macOSならプロファイル、WindowsならHKLMのポリシーとしてMDMで配布します。

開発者が自分で設定することはできません。ログイン画面の選択肢にゲートウェイの項目が現れず、開発者自身の設定ファイルに書いたURLは無視されます。方式だけ指定してURLが届いていないと「IT管理者に連絡してください」で止まるので、2つのキーは同時に配ってください。もう1つ運用で効くのが証明書のピン留めです。CLIは初回接続時にTLSリーフ証明書をホスト名ごとに記憶し、サインイン画面にSHA-256ダイジェストの先頭16文字が出ます。期待値を事前に配らないと、開発者は照合のしようがありません。

モデル許可・資格情報・起動時の挙動で強制される5つの制約の内訳

サインイン済みのセッションには、ローカル設定で覆せない制約がかかります。第一にモデルアクセスで、ポリシーが許可していないモデルへのリクエストはサーバ側で400を返し、モデル選択画面も許可リストで絞られます。第二に資格情報で、ゲートウェイのトークンがセッション唯一の資格情報になり、環境変数のAPIキーや以前のclaude.aiログインは無視される。第三はテレメトリの送信先で、CLIはローカルで宛先を指定していてもゲートウェイへ送ります。

第四は起動時の挙動で、ゲートウェイへ到達できないとおよそ10秒後にエラー終了し、設定が効かないまま起動することはありません。第五がデプロビジョニングで、IdPで無効化されたユーザーのセッションは次回のリフレッシュ失敗時に失効します。組織が見えるのは利用者のID・トークン数・モデル・レイテンシで、プロンプトと応答の本文は記録も保存もされない。この境界の説明は生成AIのリスクとガバナンス対策で扱っています。

ゲートウェイ経由で利用できなくなる機能と運用側で作り込む範囲

導入の代償も明示されています。知らずに全社展開すると、開発者から不満が出る箇所です。

Web検索とプロンプトキャッシュ1時間TTLが使えなくなる影響

サーバサイドのWeb検索は無効になります。CLIはゲートウェイがどの上流へ流しているかを知る手段がなく、対応可否を確認できないため、機能ごと落とす設計。調査を伴う作業をClaude Codeに任せている現場では、代替の手段を先に決めてから切り替えてください。

プロンプトキャッシュも条件が変わります。cache_controlのブレークポイント自体はすべての上流へ転送されるので標準のキャッシュは効きますが、1時間TTLの拡張は使えず5分TTLに戻る。長い設計文書を何度も参照する使い方では、ヒット率が落ちてトークン費用に跳ねます。グローバルキャッシュスコープやトークン効率化ツールなど一次プロバイダ限定の高速化も同様に無効。この差はテレメトリのトークン数で観測できるので、切り替え前後を比較できる形にしておくと判断が早い。計測の組み立て方はAPMとOpenTelemetry計装の実装判断が使えます。

管理UIとHelmチャートが提供されない前提での運用設計の要点

管理画面はありません。設定はYAMLファイルがすべてで、変更のたびに再デプロイします。グループごとのモデル許可を頻繁に変える運用なら、その変更フローをCI側に作り込む前提で見積もってください。Helmチャートも提供されず、EKSでは標準的なステートレスDeploymentとして自分で書きます。

テレメトリはOTLPのHTTPのみで、gRPCは非対応。宛先ごとにメトリクス・ログ・トレースを個別にオプトインする形で、既定はメトリクスのみです。SSRF対策がループバック接続を遮断するため、同一タスク内にサイドカーのコレクタを置く構成は届きません。ログの扱いも基盤で差が出ます。ECS Fargateなら標準のログドライバが監査イベントを含む標準エラー出力をCloudWatch Logsへ運びますが、EKSではログ収集を入れるまで監査証跡が残りません。

複数顧客を抱える受託開発の現場での採用条件と見送るべき3つの場面

ここからは判断の話です。受託開発の会社が自社の開発体制に入れる前提で、採用してよい条件と見送る場面を条件つきで示します。

1ゲートウェイ1 issuerが顧客ごとの別インスタンスを強いる制約

設計上もっとも効いてくる制約が、マルチテナント非対応です。1つのゲートウェイが扱えるOIDC issuerは1つだけで、複数のIdPを1台に相乗りさせる構成は成立しません。公式の案内も「インスタンスを分けて動かす」というもの。

自社の開発者だけが使うなら、issuerは自社のIdP1つで済みます。ところが顧客のIdPで開発者をサインインさせる要件が出た瞬間、顧客ごとにゲートウェイ、RDS、内部ALB、シークレット群を1式ずつ立てる話になる。3社なら3式です。顧客ごとのAWSアカウント分離が要件なら理にかなった構成ですが、自社アカウントに集約したい動機で検討しているなら、先に潰しておくべき前提になります。マルチアカウント構成の設計を外部に相談したいなら、AWSのインフラ構築・設計の受託のようにVPC設計からIAM・監視まで通しで見られる相手を選ぶと、後から分離要件が出たときの手戻りを減らせます。

CIパイプラインで使えない理由と認証経路を切り分ける判断基準

無人実行向けのサービストークンフローは用意されていません。サインインは必ずブラウザのデバイスフローを通るため、承認する人間がいないCIジョブは認証を通せない。公式ドキュメントは、そうしたジョブをプロバイダへ直接つなぐよう明示しています。

つまり認証経路は2系統に分かれる前提で設計します。開発者の対話セッションはゲートウェイ経由、CIのジョブはBedrockのIAMロールで直結。全部をゲートウェイに寄せると、どこかで詰まります。逆に、一度開発者がサインインしたマシンの上では、非対話の実行やAgent SDK経由のセッションも同じポリシーの下で動く。手元のバッチ処理まで統制が及ぶ一方、共有ランナー上のCIには及びません。

既存のLLMゲートウェイを運用中なら乗り換えないと判断する条件

すでにLiteLLMなど自前のLLMゲートウェイを動かしていて、コスト可視化と上限管理の要件を満たせているなら、乗り換えないでください。公式ドキュメント自身が「要件を満たすゲートウェイを既に運用しているなら使い続けてよい」と明記し、既存ゲートウェイへ向ける設定方法も案内しています。乗り換えの動機になるのは、CLIが送るヘッダの許可リストを保守し続ける負担と、マネージド設定をIdPグループ単位で配る機能の2点に絞られます。

逆に、Claude Code以外のアプリからもモデルを呼んでいる組織では、この製品だけでは足りません。対象クライアントはClaude CodeとClaude Desktopで、社内Webアプリからの呼び出しは統制の対象外。汎用のAIゲートウェイを併存させる設計になります。中継層が不要になった例は公式対応でゲートウェイが不要になった接続方法と判断基準で扱っています。

よくある質問

検討の場でよく挙がる論点に、実装目線で簡潔に答えます。

Claude apps gatewayは無償で使えますか？

ゲートウェイのソフトウェア自体はClaude Codeのバイナリに同梱されており、別途のライセンス費用は案内されていません。ただし動かすためのAWS費用は自社負担。参照構成ではECS Fargate、RDS、内部ALB、NATゲートウェイが常時稼働します。推論費用は上流の課金がそのまま発生するため、制御面の運用費が上乗せされる前提で見積もってください。

開発者はclaude.aiのアカウントやAPIキーが必要ですか？

不要です。開発者は社内の業務アカウントでブラウザのサインインを1回通すだけで、claude.aiのアカウントもAPIキーもサブスクリプションも要りません。モデルへのリクエストは組織が持つ上流の資格情報でゲートウェイが実行します。ローカルのAPIキーや以前のclaude.aiログインは無視されるため、事前にログアウトさせる手順も省けます。

Claude Desktopもゲートウェイ経由にできますか？

できます。Claude Desktop側のマネージド構成でブートストラップURLを指定し、ゲートウェイのポリシー側でデスクトップ用のキーを有効にする2段構え。サーバ側にClaude Code v2.1.203以降が要ります。CLIとDesktopのセッションは共有されないので、両方使う開発者はそれぞれでサインインします。

既存の監視基盤に利用状況を取り込めますか？

取り込めます。CLIはOTLPでメトリクスを出し、ゲートウェイセッションではIdPで認証されたユーザーID・メールアドレス・所属グループが各エクスポートに付与される仕組み。開発者ごとの集計のために各PCへ環境変数を配る作業が要りません。AWSではADOTコレクタ経由でCloudWatchやAmazon Managed Service for Prometheusへ流します。

ゲートウェイが落ちたら開発者は作業できなくなりますか？

サインイン済みのセッションでも、起動時にゲートウェイへ到達できなければおよそ10秒でエラー終了します。設定が効かないまま起動する挙動を避けているためで、可用性の設計は必須。複数レプリカとマルチAZのRDS、障害時にプロバイダ直結へ切り替える手順を、導入と同時に用意しておくのが現実的です。

関連記事

• AIゲートウェイとは？役割・LLMゲートウェイとの関係と導入判断：中継層を挟むべきかという一段手前の判断を扱っています。
• AWS上でClaudeを利用する仕組みと提供形態の全体像整理：提供形態の違いを、導入の前提知識として確認できます。
• APIゲートウェイとは？リバースプロキシ・サービスメッシュとの違いと導入判断：土台となる役割を実装寄りに押さえられます。
• Sakana FuguをClaude Codeで使う設定手順｜ゲートウェイが不要になった判断基準：中継層を挟まない選択が成立する条件を比較できます。