【Claude Code 連載 第49回】Claude アプリゲートウェイ — 自社インフラに置く「認証・統制・計測」の関所

スポンサーリンク
【Claude Code 連載 第49回】Claude アプリゲートウェイ — 自社インフラに置く「認証・統制・計測」の関所 用語解説
【Claude Code 連載 第49回】Claude アプリゲートウェイ — 自社インフラに置く「認証・統制・計測」の関所
この記事は約24分で読めます。
よっしー
よっしー

こんにちは。よっしーです(^^)

スポンサーリンク

背景

この連載では、Claude Codeの公式ドキュメントを1ページずつ読み解いていきます。公式ドキュメントは情報が網羅されている分、「結局どの機能を、どんな場面で使えばいいのか」は自分で考える必要があり、読むのに意外と時間がかかります。そこで、私が実務で使うために読み込んだ内容を「使う場面→実例コード」の順に整理して残していくことにしました。専門家の解説というより、一次情報を読んだ記録です。推測や動作を確認していない部分には、その都度そう書きます。

1. 一言でいうと何か

Claude アプリゲートウェイは、開発者の Claude Code クライアントとモデルプロバイダーの間に自分で立てるサーバーです。

何のために立てるのか。ひとことで言えば、開発者から API キーとクラウド認証情報を取り上げるためです。従来、Amazon Bedrock で Claude Code を使うなら、各開発者のマシンに AWS の認証情報が要ります。ゲートウェイを挟むと、アップストリームの認証情報はインフラ内にだけ存在し、開発者は企業の ID プロバイダー（IdP）でサインインして短期間有効なベアラートークンを受け取ります。デフォルトのセッション有効期間は1時間。オフボーディングは IdP 側で完結し、ユーザーをプロビジョニング解除すればセッション有効期間内にゲートウェイアクセスも失効します。

そして面白い実装上の事実がひとつ。**これは claude バイナリに含まれています。**ラップトップで Claude Code を動かしているのと同じ実行ファイルが、claude gateway --config gateway.yaml でゲートウェイサーバーになります。別製品をインストールするわけではありません。

ゲートウェイが提供するものは5つに整理できます。

  • 認証情報の隔離：アップストリームのキーは自社インフラ内のみ。開発者は SSO。
  • アクセス制御：IdP グループがモデル許可リストと管理設定ポリシーにマップされる。モデルアクセスはサーバー側で強制され、許可されていないモデルのリクエストは拒否される。チームごとに違うモデル・ツール・権限を与えられ、開発者はロックされたものをオーバーライドできない。
  • 設定配信：管理設定をサインイン済みクライアントに配信する。claude.ai 管理コンソールからのサーバー管理設定（前回・第48回）の役割をここが引き継ぐ。
  • テレメトリ：Datadog、Splunk、ClickHouse などへ OTLP メトリクス（トークン数、モデル、ユーザーアイデンティティ、レイテンシ）をリレー。ログとトレースは宛先ごとのオプトイン。
  • アップストリームルーティング：クライアントは Anthropic Messages API をゲートウェイに話し、ゲートウェイが各アップストリーム（Amazon Bedrock、Claude Platform on AWS、Google Cloud の Agent Platform、Microsoft Foundry、Anthropic API）向けに変換し、フェイルオーバーもする。開発者が気づくことも再設定することもなく、リージョンやプロバイダーを変更できます。

データの流れについて明確な保証があります。**ゲートウェイ独自のデータプレーンは、Anthropic API が設定されたアップストリームでない限り、Anthropic インフラに何も送信しません。**テレメトリ、監査ログ、管理設定、開発者の IdP アイデンティティがどこへ行くかは組織が制御し、ゲートウェイはそのいずれも Anthropic に送りません。

そもそも自分で立てるべきか

公式ドキュメントは冒頭で釘を刺しています。Claude アプリゲートウェイは、データレジデンシー要件などで、自分のクラウドプロバイダー経由で推論をルーティングする必要がある／したい組織向けの設計です。その要件がなく、SCIM プロビジョニングやウェブ・モバイル上の Claude Code といった機能が欲しいなら、Claude Enterprise のほうが適切かもしれない、と。

また、要件を満たす LLM ゲートウェイや API ゲートウェイをすでに運用しているなら、それを使い続けてよいとも明言されています。Claude apps ゲートウェイの利点は、Anthropic 自身のゲートウェイであり claude バイナリに組み込まれ、各リリースと一緒にテストされているため、Claude Code が送るヘッダーとリクエストフィールドを、オペレーターが個別の許可リストを維持せずに転送できる点にあります。

2. どういう場面で役立つか

シーン1：データレジデンシー要件があり、推論を自社クラウドに閉じたい

これが第一の想定用途です。規制や契約で「推論トラフィックは自社の AWS / GCP / Azure 内で処理する」ことが要求される組織。Bedrock や Foundry を直接使えばそれは満たせますが、今度は認証情報の配布と統制が問題になる。ゲートウェイはその両方を同時に解きます。

シーン2：開発者マシンからクラウド認証情報を消したい

AWS のアクセスキーを開発者のラップトップに置きたくない、という要求は普遍的です。ゲートウェイなら、開発者が持つのは1時間で切れる SSO トークンだけ。退職者のアクセス遮断は IdP の操作で完結します。

シーン3：チームごとにモデルと権限を分けたい

「ML チームは Opus を使ってよいが、業務委託メンバーは Haiku のみ」「本番リポジトリを触るチームには厳しい権限ポリシー」——こうした区別を IdP グループで表現し、サーバー側で強制できます。第48回のサーバー管理設定が全ユーザー均一（グループ別未サポート）だったのに対し、ゲートウェイはグループごとにポリシーを出し分けられる。ここは明確な機能差です。

シーン4：使用状況を自社の可観測性スタックで見たい

誰が、どのモデルで、どれだけトークンを使ったか。OTLP でファンアウトできるので、既存の Datadog / Splunk / ClickHouse にそのまま流せます。ユーザーごと・グループごとの支出制限も利用可能です。

不要・向かないケース

  • データレジデンシー要件がない組織。Claude Enterprise のほうが機能面で有利な可能性が高い。運用負荷を背負う理由がありません。
  • すでに要件を満たすゲートウェイを運用している組織。乗り換える必要はありません。
  • CI パイプラインや無人ジョブ。**無人パイプライン向けのサービストークンフローはありません。**ゲートウェイのサインインは常にブラウザデバイスフローなので、承認する開発者がいない CI ジョブは認証できません。これらはプロバイダーに対して直接設定してください。
  • SAML / LDAP しかない環境。OIDC のみ対応です。必要なら OIDC ブリッジを前段に置くことになります。
  • マルチテナント運用。ゲートウェイ1つにつき OIDC 発行者は1つ。複数必要なら個別インスタンスを立てます。
  • Windows サーバーで動かしたい場合。サーバーは Linux のみ（macOS はローカル開発用）。
  • 管理 UI や Helm チャートを期待する場合。どちらもありません。設定は YAML ファイルで、変更は再デプロイ。
  • サーバー側ウェブ検索を使いたい場合。ゲートウェイセッションでは WebSearch が無効化されます（後述）。

3. 前提条件と、構築の実例

セキュリティ上の大前提：プライベートネットワークに置く

コードより先にこれを書きます。**Claude Code は、アドレスがプライベートであるゲートウェイにしか接続しません。**これは仕様として組み込まれたセキュリティガードで、理由も明示されています——信頼されたゲートウェイは、開発者マシンでコマンドを実行する設定をプッシュできるからです。管理設定を配信できる立場は、それだけ強い権限だということです。

したがって、ゲートウェイは内部ロードバランサーか VPN の背後に置き、プライベート IP にのみ解決するホスト名を付けます。/login はホスト名が解決する各 IP をチェックし、ひとつでもパブリックなら URL を拒否します。許容されるのは RFC 1918、CGNAT 100.64.0.0/10、IPv6 ULA fc00::/7、ローカル開発用のループバックです。

例外は Anthropic が運用するパブリックゲートウェイエンドポイントだけで、これは Claude Code にコンパイル済みの固定リストです。設定でホスト名をリストに追加することはできず、自分でホストするゲートウェイが免除対象になることはありません。（v2.1.206 より前は、/login はそれらのエンドポイントも他のパブリックアドレスと同様に拒否していました。）

開発者マシンが HTTPS を企業プロキシ経由でルーティングする場合、プロキシホストもプライベートアドレスに解決される必要があります。そうでなければゲートウェイホストを NO_PROXY に追加して直接接続させてください。

そのほかの前提条件

  • Claude Code v2.1.195 以降。claude gateway サブコマンドとゲートウェイサインインフローはこのバージョンから。サーバーを動かすマシンと各開発者のマシンの両方が必要です。claude update で更新します。Claude Platform on AWS アップストリームはゲートウェイサーバー側に v2.1.198 以降が必要。
  • OIDC ID プロバイダー。Okta、Microsoft Entra ID、Google Workspace、Keycloak、Dex、PingFederate など。標準の OIDC ディスカバリーと認可コードフローを実行します。SAML と LDAP は非対応。
  • PostgreSQL 14 以降。デバイスサインインフロー（ブラウザのコールバックが書き込み、ポーリングする CLI が読む）とレート制限カウンターに使います。最小層の管理 Postgres で十分。支出制限を使わないなら、保存されるのは数 KB の短期認証状態だけです。支出制限を使う場合は、バックアップが必要な耐久的な支出・監査・アイデンティティのテーブルも保持します。?sslmode=require 経由の TLS 推奨。
  • モデルアップストリームの認証情報。複数指定可、フェイルオーバーあり。
  • HTTPS。開発者のラップトップとブラウザから https:// で到達できる必要があります（デバイス検証ページを同じリスナーで提供するため）。listen.tls で証明書を渡すか、TLS 終端イングレスの背後で listen.public_url を設定します。プレーン http:// はローカル開発のループバックのみ。
  • Linux ランタイム。サーバーはネイティブ Linux バイナリでのみ動作。

最後に見落としやすい要件。**ゲートウェイサーバーはネイティブ claude バイナリを必要とします。**Node 配下で動く Claude Code では利用できないランタイム機能を使うためです。起動時に requires the native binary と出たら、スタンドアロンのインストール方法に切り替えてください。

手順1：IdP に OAuth クライアントを登録する

リダイレクト URI を先に決める必要があるので、まずゲートウェイのホスト名を決めます。OIDC ウェブアプリケーションを新規作成し、リダイレクト URI を https://claude-gateway.<your-domain>/oauth/callback に設定。このホストは後の listen.public_url と同じ値です。client_id と client_secret を控えます。

手順2：PostgreSQL を用意する

Postgres 14 以降なら最小の管理層で構いません。ゲートウェイは起動時に自分でスキーママイグレーションを実行するので、DB ユーザーに CREATE TABLE 権限が要ります。セキュリティポリシーがアプリケーションロールからの DDL を禁じているなら、スキーマを事前作成してください。

手順3：gateway.yaml を書く

シークレットは ${ENV_VAR} 展開で読まれるので、このファイル自体はバージョン管理に置けます。最小設定は5セクション、他はすべてデフォルトがあります。

listen:
  host: 0.0.0.0
  port: 8080
  # TLS 終了プロキシの背後で必須。IdP
  # redirect_uri とディスカバリードキュメントに使用されます。
  public_url: https://claude-gateway.internal.example.com
oidc:
  issuer: https://login.example.com        # /.well-known/openid-configuration を提供する必要があります
  client_id: 0oa1example2
  client_secret: ${OIDC_CLIENT_SECRET}
  allowed_email_domains: [example.com]        # 組織外の id_tokens を拒否します
  userinfo_fallback: true                  # id_token が email/groups を省略する IdP の場合。それ以外の場合は無害です
session:
  jwt_secret: ${GATEWAY_JWT_SECRET}        # openssl rand -base64 32
  ttl_hours: 1                             # IdP プロビジョニング解除時の失効レイテンシもバウンドします
store:
  postgres_url: ${GATEWAY_POSTGRES_URL}    # 管理 Postgres の場合は ?sslmode=require を追加します
upstreams:
  - provider: bedrock
    region: us-east-1
    auth: {} # 空：AWS デフォルト認証情報チェーン
# （IRSA、EC2/ECS タスクロール、環境変数、~/.aws）
# モデルはアップストリームごとに自動的に変換されます。組み込みカタログ
# は claude-opus-4-8 を us.anthropic.claude-opus-4-8 にマップし、
# Bedrock がサポートするすべての Claude モデルに対して同様にマップします。false に設定し、
# `models:` リストを追加して、特定のモデルのみを公開します。
auto_include_builtin_models: true

ttl_hours のコメントが本質を突いています——これは単なるセッション長ではなく、IdP でプロビジョニング解除したときの失効レイテンシの上限でもあります。短くすればオフボーディングが速くなり、長くすれば再サインインの頻度が下がる。そのトレードオフです。

Bedrock アップストリームには IAM 要件があります。inference-profile/us.anthropic.* ARN と、その基礎となる foundation-model/anthropic.* ARN の両方に対して bedrock:InvokeModel と bedrock:InvokeModelWithResponseStream を持つプリンシパルが必要で、Bedrock コンソールで対象モデルのモデルアクセスが有効になっている必要があります。認証情報は静的キーではなく、EKS の IRSA、ECS タスクロール、EC2 インスタンスプロファイルで渡すよう勧められています。

手順4：実行する

イメージ要件を満たすコンテナイメージを claude バイナリの周りに作り、Postgres と一緒に動かします。

services:
  gateway:
    image: <your-registry>/claude-gateway:<version>
    ports: ["8080:8080"]
    volumes: ["./gateway.yaml:/etc/claude/gateway.yaml:ro"]
    environment:
      OIDC_CLIENT_SECRET: ${OIDC_CLIENT_SECRET}
      GATEWAY_JWT_SECRET: ${GATEWAY_JWT_SECRET}
      GATEWAY_POSTGRES_URL: postgres://gw:pw@postgres/gateway
      # AWS 認証情報：本番環境では、これらを省略し、インスタンス
      # ロールを使用します。ローカル Compose テストの場合、独自のものを渡します。
      AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
      AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
      AWS_SESSION_TOKEN: ${AWS_SESSION_TOKEN}
    depends_on:
      postgres:
        condition: service_healthy
  postgres:
    image: postgres:16-alpine
    environment: { POSTGRES_USER: gw, POSTGRES_PASSWORD: pw, POSTGRES_DB: gateway }
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U gw"]
      interval: 5s
    volumes: ["pgdata:/var/lib/postgresql/data"]
volumes: { pgdata: }

起動シーケンスは設定読み込み → OIDC ディスカバリー → Postgres スキーママイグレーション → アップストリームクライアント構築 → リッスン開始という単一の Linux バイナリです。重要なのは、この4つはすべて fail-closed だということ。設定、5秒タイムアウト付きの Postgres 接続、OIDC ディスカバリー、アップストリームクライアント構築のいずれかが到達不能か設定ミスなら、ゲートウェイは劣化した状態でトラフィックを流さず、エラーで終了します。

ただし注意点。**起動が成功しても推論パスは検証されていません。**Bedrock と Agent Platform のインスタンス認証情報は、起動時ではなく最初のリクエストで解決されるためです。

stderr を監視します。ログ行は [gateway] <timestamp> <level> <message> 形式、監査イベントは evt フィールド付きの単一行 JSON です。

{"ts":"2026-06-10T17:03:21.114Z","evt":"config.load","path":"/etc/claude/gateway.yaml","sha256":"…"}
[gateway] 2026-06-10T17:03:21.408Z info migration 1 applied
[gateway] 2026-06-10T17:03:21.512Z info claude gateway listening on http://0.0.0.0:8080

claude gateway listening on の行より前に終了した場合、stderr の最後の行が原因を名指しします。想定される原因は4つ：到達不能な Postgres、DDL 権限のない Postgres ロール、到達不能または無効な OIDC ディスカバリードキュメント、違反フィールドパスを含む設定スキーマ違反。

すでに TLS 終端イングレスがあるなら Compose を飛ばして claude gateway --config gateway.yaml で直接動かし、public_url をイングレスのオリジンに、listen をループバックかクラスター内アドレスにバインドします。

手順5：認証サーフェスを3段階で確認する

この3つのチェックは、失敗した最初のチェックが原因を切り分けてくれる設計になっています。順に実行してください。

なお Windows PowerShell では curl.exe を使います。素の curl は Invoke-WebRequest のエイリアスで、これらのフラグを拒否します。

**チェック1：ディスカバリードキュメントを取得する。**ゲートウェイが起動し、設定が有効で、起動チェックがすべて通ったことを確認します。

curl -s https://claude-gateway.internal.example.com/.well-known/oauth-authorization-server | jq

**チェック2：デバイス認可をリクエストする。**デバイスサインインフローが機能し、Postgres が到達可能かつ書き込み可能であることを確認します。

curl -s -X POST https://claude-gateway.internal.example.com/oauth/device_authorization | jq

{
  "device_code": "…",
  "user_code": "WDJB-MJHT",
  "verification_uri": "https://claude-gateway.internal.example.com/device",
  "verification_uri_complete": "https://claude-gateway.internal.example.com/device?user_code=WDJB-MJHT",
  "expires_in": 600,
  "interval": 5
}

チェック3：ブラウザレッグをテストする。verification_uri_complete をブラウザで開き、コードを確認します。IdP のサインインページにリダイレクトされ、サインイン後にゲートウェイへ戻ってサインイン確認に着地すれば成功です。

切り分けは次のとおり。

  • 1が失敗 → 起動が完了していない。stderr を確認。
  • 2が失敗 → Postgres がゲートウェイから到達不能か、ロールが書き込めない。接続文字列と権限を確認。
  • 3で IdP に到達しない → IdP のリダイレクト URI が https://<gateway>/oauth/callback と正確に一致しているか確認。
  • 3で IdP に到達するがエラーで戻る → ゲートウェイの監査ログを読む。email domain not allowed などの理由を含め、すべての認証拒否が記録されています。

開発者を接続する

開発者側に手動セットアップはありません。管理者が管理設定ファイルに2つのキーを置いて配布します。

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com"
}

これで /login は URL が入った状態の Cloud gateway 画面で直接開き、開発者は Enter を押すだけです。

ここには落とし穴が3つあります。**ログインピッカーに開発者が手動で選べるゲートウェイオプションはありません。**そして **forceLoginGatewayUrl は開発者自身の設定ファイルでは無視されます。**さらに、URL なしで forceLoginMethod だけを置くと、開発者は「IT 管理者に連絡してください」というメッセージで止まります。両方のキーは、マシンにプッシュするファイルに置くものであり、ゲートウェイの managed.policies[].cli ブロックに置くものではありません（そちらはすでに接続済みのクライアントにしか届かないため）。

TLS フィンガープリントのピン留め

CLI は初回接続時にゲートウェイの TLS リーフ証明書をフィンガープリントし、ホスト名ごとにピン留めします。管理者は期待される SHA-256 フィンガープリントをゲートウェイ URL と一緒に公開し、開発者が照合できるようにしてください。証明書ファイルからは次で取得できます。

openssl x509 -noout -fingerprint -sha256 -in cert.pem

/login のプロンプトは、ダイジェストの先頭16文字を小文字16進数・区切りなしで表示します。

そして運用上の注意：**証明書をローテーションすると、全開発者に再び信頼プロンプトが出ます。**計画されたイベントとして扱い、フィンガープリントを再公開してください。

開発者に強制されること

サインイン済みセッションには次の保証がすべて適用されます。

  • モデルアクセス：ポリシーが許可しないモデルへのリクエストは 400 を返し、/model ピッカーは availableModels にフィルタされる。ポリシーで enforceAvailableModels: true を設定すると、Default オプションが Claude Code 組み込みのデフォルトではなく availableModels 内のモデルに解決される。設定しないと Default は選択可能なまま残り、そのモデルが許可されていなければリクエスト時に拒否される。
  • テレメトリ宛先：テレメトリ転送が設定されていれば OTLP エクスポート先はゲートウェイにピン留めされ、ゲートウェイがプッシュした設定がローカルの OTEL_* 変数を上書きする。
  • 認証情報：ゲートウェイトークンがセッション唯一の認証情報。ANTHROPIC_AUTH_TOKEN、ANTHROPIC_API_KEY、apiKeyHelper、以前の claude.ai ログインはサインイン中は無視されるので、開発者が先に claude.ai からログアウトする必要はない。
  • 管理設定：ロックされたキーはローカルで上書きできない。起動時と毎時ポーリングで適用。
  • 起動：サインイン済みセッションは、ゲートウェイが到達不能なら約10秒後にエラーで終了する。設定なしで起動することはない。
  • プロビジョニング解除：IdP で無効化されたユーザーのセッションは、次の更新が失敗した時点で ttl_hours 以内に期限切れになる。

開発者がサインインすると、そのマシンでのすべての Claude Code 呼び出しがゲートウェイセッションを使います。非対話の claude -p 実行も Agent SDK が開始したセッションも含め、ゲートウェイポリシーがすべてに適用されます。

なおディスプレイのないリモート開発ボックスでも使えます。デバイスフローはポーリングする CLI と承認するブラウザを分離しているので、SSH 越しにリモートで /login を実行し、手元のラップトップのブラウザで検証リンクを開く運用が成立します。

組織が見えるもの／見えないもの

テレメトリは開発者のアイデンティティ、トークン数、モデル、レイテンシを組織のコレクターに伝えます。ゲートウェイはプロンプトや完了内容をログにも保存にも残しません。ただし、コマンドやファイルパスを含みうるログやトレースといった、より豊富なテレメトリを収集するかどうかは組織の宛先ごとの選択です。ここは自分たちで決める領域だ、ということです。

可用性と制限（要点）

機能状態
推論転送（Bedrock / Claude Platform on AWS / Agent Platform / Foundry / Anthropic）利用可能（モデル変換とフェイルオーバー付き）
IdP グループによるモデルアクセスと管理設定利用可能（モデルアクセスはサーバー側強制）
テレメトリファンアウト（OTLP/HTTP）利用可能
OIDC ID プロバイダー利用可能
ユーザーごと・グループごとの支出制限利用可能
標準プロンプトキャッシング利用可能
オートモード利用可能（サードパーティプロバイダールールに従う）
サーバー側ウェブ検索利用不可
1時間キャッシュ TTL利用不可（5分 TTL になる）
ファーストパーティのみの最適化（グローバルキャッシュスコープ等）利用不可
OTLP/gRPC、SAML/LDAP、マルチテナント、Windows サーバーサポートされていない
Helm チャート、管理 UI利用不可

「利用不可」の理由は共通しています。CLI はゲートウェイセッションで一部のベータを省略するからです。ゲートウェイはすべてのアップストリームに anthropic-beta 値を配信するため、オペレーターがベータ許可リストを維持する必要はありません（Bedrock 向けにはヘッダーを無視してボディの anthropic_beta フィールドに移し替えます）。しかし CLI 側が、ファーストパーティのみのベータと拡張キャッシュ TTL ベータを送らない。だから1時間 TTL とファーストパーティ最適化が使えません。ウェブ検索については理由が別で、CLI はゲートウェイがどのアップストリームにルーティングするか見えないため、ウェブ検索サポートを検証できず、無効化するという判断です。

オートモードについては、v2.1.207 より前はゲートウェイセッションで CLAUDE_CODE_ENABLE_AUTO_MODE=1 が必要でした（管理ポリシーの env ブロックで配信可能）。現在は不要です。

Amazon Bedrock の Mantle エンドポイントはサポート対象のアップストリームではありません。

（各行の詳細な注記は公式の表を参照してください。）

4. まとめ ＋ 次回予告

  • Claude アプリゲートウェイは、自社インフラに立てる自己ホスト型サービス。claude バイナリに同梱され、claude gateway --config gateway.yaml で起動する。
  • 目的は認証情報の隔離・グループ別のアクセス制御・管理設定の配信・テレメトリ・アップストリームルーティングの5つ。
  • 主対象はデータレジデンシー要件がある組織。要件がなければ Claude Enterprise、既存ゲートウェイがあればそれを継続、が公式の推奨。
  • プライベートネットワーク必須。/login は解決先 IP がひとつでもパブリックなら拒否する。理由は「ゲートウェイは開発者マシンでコマンドを実行する設定をプッシュできる」から。
  • 必要なのは v2.1.195 以降（サーバー・クライアント両方）、OIDC IdP、Postgres 14 以降、アップストリーム認証情報、HTTPS、Linux、そしてネイティブ claude バイナリ。
  • 起動は設定・Postgres・OIDC・アップストリーム構築で fail-closed。ただし推論パスは初回リクエストまで検証されない。
  • 確認は3段階のチェック（ディスカバリー → デバイス認可 → ブラウザレッグ）。最初に失敗したものが原因を指す。
  • 開発者側は forceLoginMethod と forceLoginGatewayUrl の2キーを管理設定ファイルで配るだけ。片方だけでは動かない。開発者自身の設定ファイルに書いても無視される。
  • TLS フィンガープリントはピン留めされる。証明書ローテーションは計画イベントとして扱う。
  • CI や無人ジョブは認証できない（サービストークンフローなし）。プロバイダー直結で構成する。
  • ゲートウェイセッションではウェブ検索が無効、キャッシュ TTL は5分、ファーストパーティ最適化は無効。
  • ゲートウェイはプロンプトや完了内容を保存しない。何を収集するかは組織の選択。

第48回のサーバー管理設定と対比すると位置づけが鮮明です。claude.ai 経由の設定配信ができない環境（Bedrock / Agent Platform / Foundry）で、その役割を引き受けるのがこのゲートウェイです。しかもグループ別ポリシーという、サーバー管理設定にない能力を持っています。代償は自分でサーバーを運用すること。

次回予告（暫定）：クイックスタートが書いた gateway.yaml の全オプションを扱う**設定リファレンス（claude-apps-gateway-config）**を取り上げる予定です。managed.policies によるグループ別 RBAC、telemetry のファンアウト、マルチアップストリームのフェイルオーバーなどが対象になります。

※連載の実際の次テーマは未確定です。

よっしー
よっしー

何か質問や相談があれば、コメントをお願いします。また、エンジニア案件の相談にも随時対応していますので、お気軽にお問い合わせください。

それでは、また明日お会いしましょう(^^)

コメント

タイトルとURLをコピーしました