Claude apps gateway for AWS を手元で動かして理解する

今日はAWSが2026年7月8日にリリースした、`Claude apps gateway for AWS` を触っていきます。Claude Code や Claude Desktop を「チームや組織で」使い始めると、個人利用では見えなかった悩みが一気に出てきます。開発者ごとに認証情報を配る、設定を全端末に手で撒く、誰がどれだけ使ったか把握できない――。Claude apps gateway は、この「アクセス・コスト・ポリシーの一元管理」を1つのコントロールプレーンに集約する仕組みです。

前半でこの機能が何なのかを整理し、後半で Dex + PostgreSQL + ゲートウェイ を Docker Compose で丸ごとローカルに立てて、実際にサインインして推論を流すところまで をStepごとに解説します。

Claude apps gateway とは何か

解決する課題

Claude Code を組織展開しようとすると、たいてい次の壁にぶつかります。

• 認証情報のばらまき：開発者ごとにクラウド認証情報やAPIキーを発行・管理する必要がある
• 設定配布の手作業：managed-settings.json のような設定を全ラップトップにMDMなどで撒かないといけない
• コストの不可視性：誰が・どのモデルを・どれだけ使ったかが、請求が来るまで分からない
• 統制の分散：上記を各チームが独自ツールで場当たり的に埋めることになる

Claude apps gateway は、これらを組織が自前で動かす単一のコントロールプレーンに寄せることで解消します。開発者はAPIキーを持たず、会社のSSO（IdP）でサインインし、ゲートウェイが上流の認証情報を握って推論を取り次ぎます。

アーキテクチャの要点

ゲートウェイは、開発者がすでに使っている claude バイナリの中に同梱されています。Claude Code を動かすのと同じ実行ファイルが、claude gateway --config gateway.yaml でゲートウェイサーバーとしても動く、という設計です。実体は次のとおりです。

• 1つのステートレスなLinuxコンテナとして動く
• 背後に PostgreSQL を持ち、デバイスサインインの状態やレート制限カウンターを保存する
• クライアントとゲートウェイが一緒にビルドされているため、/login フローが最初からゲートウェイを認識する

オンボーディング／オフボーディングは既存のIdPに開発者を足す・消すだけで完結し、開発者のマシンに長期的なシークレットが残りません。IdPからユーザーを消せば、そのセッションは設定した有効期限（デフォルト1時間）内に失効します。

ゲートウェイが担う5つの役割

いつ使い、いつ使わないか

このゲートウェイは「自社クラウド経由で推論を通す必要がある（データレジデンシー要件など）」組織向けです。逆に、そうした要件がなく、SCIMプロビジョニングやWeb/モバイル版Claude Codeが欲しいだけなら、Claude Enterprise の方が適していることもあります。個人が試すだけなら、そもそもゲートウェイは不要で、Claude Code を入れて普通にログインすれば済みます。

さっそくやってみる

「読むだけ」だと腹落ちしないので、ローカル1台で一式立ち上げて、サインインして推論を流すところまでやります。組織で使う本番構成ではなく、あくまで感触を掴むための検証環境です。

構成の方針

簡単に試したいとき一番のハードルは OIDCのWebアプリ登録です。OktaやEntraを持っていない／管理権限がないと、ここで詰まります。そこで今回は、Dex という軽量な自己完結型OIDCサーバーをローカルに立てます。

Dex は、CoreOS 発祥（現在は CNCF 傘下）のオープンソースのOIDCプロバイダーです。自分では利用者アカウントを持たず、Google・GitHub・LDAP・SAML などの既存IDソースを裏で束ね、それらを標準的な OpenID Connect として手前のアプリに見せる「認証の仲介役（アイデンティティブローカー）」として働きます。

今回のように、設定ファイルにユーザーとOAuthクライアントを直書きする軽量モードもあるため、本物のIdP（OktaやEntra）を用意せずにOIDCの動作確認をしたいときの代役として重宝します。

以下のスタックでテスト環境を構成します。

• IdP：Dex（設定ファイルにユーザーとクライアントを直書き）
• 状態ストア：PostgreSQL
• 上流：Anthropic API キー（AWS不要で一番手軽なため）
• オーケストレーション：Docker Compose

AWSの発表Blogだと Claude Platform on AWS か Bedrock をLLMバックエンドとしていますが、実はそのまま Anthropic APIを直接呼ぶ場合でも問題なく動作します。この記事ではよりシンプルにするため直接Anthropicを呼び出します。

ファイル構成

同じフォルダに次の7ファイルを置きます。

• Dockerfile … ネイティブ claude バイナリを含むゲートウェイイメージをビルド
• dex-config.yaml … ローカルIdP本体＋テストユーザー＋OAuthクライアント
• gateway.yaml … ゲートウェイのサーバー設定（Anthropic API上流）
• docker-compose.yaml … 3サービスの結線
• .env … APIキーと各種シークレット
• managed-settings.json … Claude Code をゲートウェイに向ける設定
• README.md … 手順書

https://github.com/harunobukameda/Claude-apps-gateway-for-AWS

にファイルを一式配置していますのでこちらからダウンロードして単一フォルダに展開しておいてください。

主要な3ファイルを見ておきます。

gateway.yaml これが今回のメイン機能本体の設定ファイルです。

listen:
  host: 0.0.0.0
  port: 8080
  # ループバック + 平文http はローカル開発時のみ許可される。
  # IdP の redirect_uri とデバイスページもこの値から組み立てられる。
  public_url: http://localhost:8080

oidc:
  issuer: http://gateway-idp.localtest.me:5556   # ローカルの Dex
  client_id: claude-gateway
  client_secret: ${OIDC_CLIENT_SECRET}
  allowed_email_domains: [example.com]           # *@example.com のみサインイン可
  userinfo_fallback: true

session:
  jwt_secret: ${GATEWAY_JWT_SECRET}              # openssl rand -base64 32
  ttl_hours: 8                                   # 検証中は長めにして再ログインを減らす

store:
  postgres_url: ${GATEWAY_POSTGRES_URL}

upstreams:
  # ローカル検証で一番手軽なのは Anthropic API キー直接。
  - provider: anthropic
    auth:
      api_key: ${ANTHROPIC_API_KEY}

auto_include_builtin_models: true

dex-config.yaml staticPasswords にテストユーザーを、staticClients にOAuthクライアントを直書きしているため、「Webでのアプリ登録」など通常のOIDC認証で必要なステップを省略して今回のテストに集中できるようにしています。 <bcryptハッシュ> と OIDC_CLIENT_SECRET と一致させる> の値はGitHub上にファイルにはそのまま動作する用ダミーの値を書き込んであります。

issuer: http://gateway-idp.localtest.me:5556
storage: { type: memory }
web: { http: 0.0.0.0:5556 }
oauth2: { skipApprovalScreen: true }

enablePasswordDB: true
staticPasswords:
  - email: "dev@example.com"
    hash: "<bcryptハッシュ>"     # 平文 "password" のbcrypt
    username: "dev"
    userID: "0001-local-dev"

staticClients:
  - id: claude-gateway
    secret: "<OIDC_CLIENT_SECRET と一致させる>"
    name: "Claude apps gateway (local)"
    redirectURIs:
      - http://localhost:8080/oauth/callback

docker-compose.yaml Gatewayを動作させるために必要な Dex や ステータス管理に用いる PostgreSQL 、そして今回のメインである gateway を纏めてコンテナで起動させる設定ファイルです。

services:
  postgres:
    image: postgres:16-alpine
    environment: { POSTGRES_USER: gw, POSTGRES_PASSWORD: pw, POSTGRES_DB: gateway }
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U gw -d gateway"]
      interval: 5s

  dex:
    image: ghcr.io/dexidp/dex:latest
    entrypoint: ["dex", "serve", "/etc/dex/config.yaml"]
    volumes: ["./dex-config.yaml:/etc/dex/config.yaml:ro"]
    ports: ["5556:5556"]

  gateway:
    build: .
    depends_on:
      postgres: { condition: service_healthy }
      dex: { condition: service_started }
    ports: ["8080:8080"]
    volumes: ["./gateway.yaml:/etc/claude/gateway.yaml:ro"]
    extra_hosts:
      # ブラウザが使うのと同じURLでゲートウェイからも Dex に到達させるための仕掛け
      - "gateway-idp.localtest.me:host-gateway"
    environment:
      OIDC_CLIENT_SECRET: ${OIDC_CLIENT_SECRET}
      GATEWAY_JWT_SECRET: ${GATEWAY_JWT_SECRET}
      ANTHROPIC_API_KEY: ${ANTHROPIC_API_KEY}
      GATEWAY_POSTGRES_URL: postgres://gw:pw@postgres:5432/gateway
      CLAUDE_GATEWAY_ALLOW_LOOPBACK: "1"

OIDCでは、issuer URL が「ブラウザが叩くURL」「ゲートウェイが叩くURL」「トークンの iss クレーム」の3か所で完全一致していないと成立しません。ここがDocker環境だと厄介です。

今回は gateway-idp.localtest.me を使いました。これはどのマシンからでも 127.0.0.1 に解決される公開ドメインで、/etc/hosts を編集せずに済みます。ブラウザ（ホスト側）はこの名前を素直に 127.0.0.1 → 公開したDexポートに解決します。一方でゲートウェイコンテナからは 127.0.0.1 だと自分自身を指してしまうので、Composeの extra_hosts: host-gateway でこの名前をDockerホストに向け直し、ホストが公開しているDexポートへ到達させています。これで3者のURLが一致します。

ローカルのループバック解決IdPをSSRFガードに通すため、CLAUDE_GATEWAY_ALLOW_LOOPBACK=1 も入れてあります。

Step 0：前提を確認する

• Docker + Docker Compose
• Claude Code v2.1.195 以上（ゲートウェイ対応はこのバージョンから）
• Anthropic Console（platform.claude.com）のAPIキー

この手順では WSL2 を使っています。

docker --version && docker compose version
claude --version

Step 1：APIキーを入れる

.env の ANTHROPIC_API_KEY= に自分のキーを貼ります。JWTやOIDCのシークレットは事前に生成済みでそのまま動く値を入れてあります。

Step 2：スタックを起動する

docker compose up --build

初回はゲートウェイイメージのビルド（Dockerfile 内で claude バイナリを取得）が走るので少し時間がかかります。次の行が出れば起動成功です。

[gateway] ... info claude gateway listening on http://0.0.0.0:8080

このとき、ゲートウェイは fail-closed で起動します。config・Postgres接続・OIDCディスカバリ・上流クライアント構築のどれかが失敗すると、中途半端に動かさずエラー終了して、最後のstderr行に原因を出します。

Step 3：起動を検証する

別ターミナルで、認証面が立ち上がっているか確認します。

curl -s http://localhost:8080/.well-known/oauth-authorization-server | head

次のようなJSONが返れば、config読み込み・OIDCディスカバリ（Dexへの到達）・Postgres接続がすべて通っています。

{"issuer":"http://localhost:8080","device_authorization_endpoint":"...","token_endpoint":"...","grant_types_supported":["urn:ietf:params:oauth:grant-type:device_code","refresh_token"], ...}

Step 4：Claude Code をゲートウェイに向ける

forceLoginGatewayUrl はOSの管理設定パスからしか効きません（個人の ~/.claude/settings.json では無効）。WSL/Linuxなら次の場所へ置きます。

sudo mkdir -p /etc/claude-code
sudo cp managed-settings.json /etc/claude-code/managed-settings.json

managed-settings.json の中身はこれだけです。

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "http://localhost:8080"
}

Step 5：サインインする

docker compose up を動かしたまま、別ターミナルで開発者側のCLIを起動します。

claude

• /login を実行（場合のよっては勝手に実行されるケースもあります）
• Cloud gateway 画面が出るので Enter（URL入力済み）
• ブラウザが開き、ゲートウェイのデバイス確認ページ → Dexログイン画面へ

Dexの画面では、dex-config.yaml に登録したユーザーで入ります。

• Email：dev@example.com
• Password：password

Step 6：動作を確認する

サインインが完了したら、そのままCLIで何か質問してみます。成功していれば、docker compose up 側のログに一連の成功が刻まれます。

dex-1     | ... msg="login successful" ... email=dev@example.com
gateway-1 | {"evt":"session.mint","result":"success","email":"dev@example.com","ttl_hours":8}
gateway-1 | {"evt":"inference","email":"dev@example.com","path":"/v1/messages","model":"claude-opus-4-7","upstream":"anthropic","status":200,"ms":2256}

まとめ

Claude apps gateway は、Claude Code / Desktop を組織で安全に展開するための「入口の一元管理装置」です。認証は既存のIdP、ポリシーは中央、コストはユーザー単位で追跡、上流は自社クラウドか直APIか自由に選べます。