デベロッパー

Google Cloud 向け Claude アプリゲートウェイを使ってみる

2026年7月15日

Roy Arsan

Applied AI Engineer, Anthropic

Ivan Nardini

Sr. Developer Relations Engineer

Try Gemini Enterprise Business Edition today

The front door to AI in the workplace

Try now

※この投稿は米国時間 2026 年 7 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

Anthropic のエージェントコーディングツールである Claude Code が Google Cloud と連携するようになってから、しばらく経ちます。個々の開発者は簡単に、Google Cloud（GCP）プロジェクトを指すように CLAUDE_CODE_USE_VERTEX=1 を設定し、roles/aiplatform.user ロールを付与することができ、推論は Google Cloud の境界内に留まります。

このフローは、エンジニアが 1 人または数人の場合に最適です。しかし、組織全体に展開するには、企業が抱える摩擦に対処する必要があります。開発者ごとにクラウド認証情報を管理し、managed-settings.json を MDM 経由で各ノートパソコンに push する必要があり、また、ユーザーが適切に確認されないために、開発者ごとの使用状況を特定できなかったり、費用上限を簡単に適用できたりする状況にも対処する必要があります。

Claude アプリゲートウェイは、そのギャップを埋めるものです。同じ Claude バイナリが付属するセルフホスト型サービスで、ローカルの Claude Code クライアントと Google Cloud の間に直接配置されます。この投稿では、このゲートウェイを実行すべき理由と、Google Cloud での安全なデプロイの様子を詳しく説明します。

（注: 今すぐコードを参照するには、Google Cloud 上の Claude アプリゲートウェイのドキュメントで完全なチュートリアルをご覧ください。）

ゲートウェイを実行すべき理由

ゲートウェイを実行すると、開発者とプラットフォーム管理者がそれぞれ単独で行うガバナンス（ID、ポリシー、費用、ルーティングなど）を一元化できます。具体的には次のようになります。

ID: /login リクエストは、ID プロバイダ（IdP）である Google Workspace または OIDC（OpenID Connect）の ID プロバイダを経由してルーティングされ、ゲートウェイはトークンを有効期間の短いセッションに交換します。サービスアカウントキー、API キー、ANTHROPIC_VERTEX_PROJECT_ID などの機密情報が開発者のノートパソコンに保存されることはありません。オンボーディングは、ユーザーを IdP グループに追加するだけで行えます。オフボーディングも、ユーザーを削除するだけで行えて、そのユーザーの次のセッション更新は即座に失敗するようになります。

ポリシー: RBAC（ロールベースアクセス制御）ルールは gateway.yaml に一度だけ記述され、グループごとに解決されてサーバーサイドで適用されます。ゲートウェイは /v1/messages 呼び出しごとに availableModels を再チェックするため、ローカルの managed-settings.json を編集しても何も変わりません。ルールの更新は 1 時間以内にフリート全体に適用されます。

テレメトリー: すべての claude_code.token.usage 指標には、なりすましが可能な、クライアントで設定された OTEL_RESOURCE_ATTRIBUTES ではなく、セッション JWT（署名付きセッショントークン）からの確認済みのメールアドレスとグループが含まれます。ゲートウェイは、OTLP / HTTP 経由で、Cloud Monitoring、Grafana、Datadog など、ユーザーが実行するコレクタにそれらを送信します。

費用上限: 管理 API を使用して、ユーザー、グループ、組織ごとに 1 日、1 週間、または 1 か月あたりの費用上限を設定します。ゲートウェイは、Cloud SQL 台帳に対してトークンを測定し、上限に達すると 429 を返します。費用は正規料金で計算されるため、正確な請求料金の確認には使用せず、使用量の急増を防ぐためのガードレールとして使用してください（確約利用割引や交渉された料金は表示されません）。

ルーティング: 呼び出しは、単一の Cloud Run サービス ID で行われます。Agent Platform のグローバルエンドポイントに region: global を設定するか、2 つ目の upstreams: エントリを追加して、リストの順に 5xx / 429 / タイムアウトでフェイルオーバーします。どちらの場合でも、推論は GCP プロジェクト内に留まるため、割り当て、データ処理に関する契約、料金はすべて変更されません。

連携の仕組み

開発者のローカルまたはデプロイ済みの claude プロセスは、HTTPS 経由で推論トラフィックをゲートウェイに送信します。ゲートウェイは、以下に示すように Cloud Run 上のステートレスコンテナです。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_FY2cRbt.max-1200x1200.png

ゲートウェイは独自の署名なしセッショントークンを検証し（Google Workspace にはログイン時とトークンの更新時にのみアクセスします）、ポリシーをチェックし、Cloud Run サービスアカウントを使用してリクエストを Agent Platform に転送します。Cloud SQL はデバイスコードのログイン状態と費用台帳を保持し、OTLP コレクタは特定された指標を受け取ります。

Google Cloud での設定

完全なチュートリアル、すべての gcloud コマンド、完全な gateway.yaml リファレンスは、Google Cloud 上の Claude アプリゲートウェイのドキュメントに記載されています。簡易版は次のとおりです。

ステップ 1: GCP 基盤をプロビジョニングする

Agent Platform、Cloud SQL、Secret Manager の各 API を有効にし、roles/aiplatform.user を持つ claude-gateway サービスアカウントを作成します。また、状態を保存するための小規模な Cloud SQL Postgres データベースインスタンスを立ち上げます。ゲートウェイは、Cloud Run サービス ID として Agent Platform に対する認証を行います。サービスアカウントキーは作成しません。最後に、Google Cloud コンソールで新しい OAuth クライアント（種類: ウェブアプリケーション）を作成します。この例では、ゲートウェイは Google Workspace に対して OIDC の証明書利用者として開発者の認証を行い、このクライアントはハンドシェイク用の client_id と client_secret をゲートウェイに発行します。これらの 2 つの値は、次のステップの oidc: ブロックに渡されます。承認済みのリダイレクト URI は、ゲートウェイ URL がわかってから、後で追加します。

ステップ 2: ゲートウェイを構成する

Google Workspace OIDC クライアント、Postgres 接続文字列、アップストリームとしての Agent Platform を指す gateway.yaml を記述します。このファイルを、OIDC クライアントシークレット、Postgres URL、JWT 署名鍵とともに、Secret Manager に保存します。

読み込んでいます...

次に、https://<public_url host>/oauth/callback を Google OAuth クライアントの承認済みリダイレクト URI として登録します。これは listen.public_url と完全に一致する必要があります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_MvuTCiS.max-700x700.png

ステップ 3: Cloud Run にデプロイする

gcloud run deploy を使用して、サービスアカウントをアタッチし、VPC 上で Cloud SQL 接続を行い、Secret Manager から構成をマウントします。コンテナはステートレスで、Cloud Run ロードバランサの背後で水平方向にスケーリングされます。GKE は、すでにプラットフォームとして使用している場合は、変わらず問題なく機能し、デプロイマニフェストのみが変更されます。

読み込んでいます...

開発者は企業ネットワーク経由で接続します。内部アプリケーションロードバランサを使用してサービスをフロントエンドに配置できます。Cloud Run のプライベートネットワークに関するドキュメントをご覧ください。

公開か内部かを問わず、開発者は構成した URL にアクセスできる必要があります。または、Cloud Run のデフォルトの URL を使用することもできます。以下の例では、https://claude-gateway.example.internal を使用します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_nlczWOp.max-1100x1100.png

ステップ 4: 開発者をオンボーディングする

管理対象の設定を使用して、forceLoginMethod: "gateway" と forceLoginGatewayUrl を開発者のマシンに push します。これにより、手動で URL を入力しなくても、/login は接続先を把握します。組織への展開の場合は、MDM チャネルがこれに該当します。開発者は、ローカル管理者権限がある場合、MDM を使用しない最初の試行では、macOS の /Library/Application Support/ClaudeCode/managed-settings.json（または Linux の /etc/claude-code/managed-settings.json）に手動でファイルを書き込むことができます。

読み込んでいます...

開発者は Claude Code の起動時に、事前に入力されたゲートウェイのログイン画面で Enter キーを押して URL を確認します。ブラウザのゲートウェイの認証ページでデバイスコードを確認すると、Google Workspace にリダイレクトされるので、ログインします。その後、ブラウザで Google Workspace に対してデバイスコードフローを完了します。セットアップが正しく終了すると、以下のようにターミナルビューに Cloud Gateway が表示されます。

https://storage.googleapis.com/gweb-cloudblog-publish/original_images/Claude_Code_login_flow_with_gateway.gif

次のステップ

ここまでで、Google Cloud 上の Claude アプリゲートウェイを構成して使用する方法について理解を深められたはずです。おすすめする次のステップをいくつかご紹介します。

完全な構成リファレンス: すべての gateway.yaml フィールドは claude-apps-gateway-config にあります。IdP ごとの設定と GKE トラックは、claude-apps-gateway-deploy と claude-apps-gateway-on-gcp にあります。
グループスコープのポリシー: グループ対応の IdP でゲートウェイをフロントエンドに配置し、groups_claim を設定して、キャッチオールの上に match: { groups: [...] } ポリシーを追加し、チームごとに異なるモデルリストとツール権限を付与します。