Google Cloud 上で Claude apps Gateway を動かす（シンプル版）

2026-07-23

こんにちはエヌデーデーの関口です。

前回、Claude apps Gateway を Google Cloud、Cloudflare Zero Trust、Microsoft Entra ID を組み合わせて利用する方法を紹介しました。

Claude apps Gateway を Google Cloud＋Cloudflare Zero Trust＋Entra ID で試してみた

前回は、社外へ持ち出した PC から Google Cloud のプライベートネットワーク内にある Gateway へ接続するため、Cloudflare Zero Trust を利用しました。

Cloudflare Zero Trust は、社内外を問わず端末からプライベートネットワークへ接続できるため、常設のアクセス環境としては便利です。

一方、検証目的で少人数が利用するだけなら、少々大がかりです。

Cloudflare One Client の導入や端末登録、トンネル、スプリットトンネル、DNS、ファイアウォールポリシーなど、いくつかの設定が必要です。また、企業ネットワークの構成によっては、Cloudflare One Client の通信要件を満たすためにプロキシやファイアウォールの設定変更が必要になることもあります。

そこで今回は、Cloudflare Zero Trust を使わず、Google Cloud の Identity-Aware Proxy(IAP) の TCP 転送を利用します。

前回構築したClaude apps Gateway や内部アプリケーションロードバランサー、Cloud SQL、Entra IDによるGateway へのログインは、そのまま利用します。

変更するのは、クライアント PC から Google Cloud 内部へ到達する経路だけです。

検証用途であれば、こちらのほうがずっと簡単です。

検証時点
本文は2026年7月時点の仕様を基にしています。Claude apps GatewayおよびGoogle Cloudの仕様は変更される可能性があるため、実施時には公式ドキュメントも確認してください。

Contents

1. Identity-Aware Proxy とは
2. 今回の構成
- 2.1. Entra IDは引き続き利用する
3. Claude Code から見た接続先
4. 事前に確認すること
- 4.1. IAP から踏み台 VM へのファイアウォール
- 4.2. 踏み台 VM から内部ロードバランサーへの通信
5. 利用者の IAM ロール
6. IAP 経由でポートフォワードを開始する
7. Claude Codeを実行する
8. この構成のメリットと制約
9. まとめ

Identity-Aware Proxy とは

Identity-Aware Proxy(IAP)は、Google Cloud 上のリソースへアクセスする際に、利用者の ID と IAM 権限を使ってアクセスを制御する仕組みです。

IAP には、Web アプリケーションへのアクセスを保護する機能のほかに、Compute Engine の VM へ TCP トンネルを作成する機能があります。

Compute Engine への SSH 接続を IAP 経由で行うこともできます。

通常、インターネット経由で Compute Engine へ SSH 接続するには、VM へ外部 IP アドレスを割り当てたり、VPN などで Google Cloud の VPC へ接続したりする必要があります。

IAP を利用すれば、VM へ外部 IP アドレスを割り当てなくても、Google Cloud IAM で認可されたユーザーだけがSSH 接続できます。

今回は、IAP 経由で cloudflared 用 VM へ SSH 接続し、SSH のローカルポートフォワード機能を利用します。

※ cloudflared 用 VM という名称がややこしいので、今回は「踏み台 VM」と以降は呼称します。

ローカルポートフォワードでは、クライアント PC 上のポートに送信された通信を、SSH 接続先の VM を経由して、VM から到達可能な別の宛先へ転送できます。

今回の場合、クライアント PCの 443 番ポートを、Google Cloud 内部にある内部アプリケーションロードバランサーの 443 番ポートへ転送します。

今回の構成

前回の構成では、クライアント PC から Gateway までの構成は次のようになっていました。

今回は、Cloudflare に関係する部分を IAP 経由の SSH ポートフォワードへ置き換えます。

踏み台 VM には、前回 cloudflared を実行していた Compute Engine を流用します。

ただし、今回は踏み台 VM 上で cloudflared を動かす必要はありません。

SSH のローカルポートフォワード機能が、踏み台 VM から内部アプリケーションロードバランサーへの通信を中継します。

今回の構成では、次のようなポートの対応になります。

場所	ポート	用途
クライアントPC	443	Claude Codeが接続するローカルポート
踏み台 VM	22	IAP経由のSSH接続
内部ロードバランサー	443	Claude apps GatewayのHTTPS
Cloud Run	8080	Gatewayコンテナの待受ポート

Entra IDは引き続き利用する

Cloudflare Zero Trust を外しても、Claude apps Gateway の OIDC 設定を変更する必要はありません。

Gateway へのログインには、引き続き Entra ID を使用します。

ただし、今回の構成には二つの認証があります。

認証対象	認証・認可の仕組み
踏み台 VM へ SSH 接続できるか	Google Cloud IAM
Claude apps Gatewayを利用できるか	Microsoft Entra ID

IAP 経由で SSH 接続する際には、gcloud で認証している Google Cloud 側のユーザーに権限が必要です。

その後、Claude Code から Gateway へログインする際には、前回と同じく Entra ID による認証が行われます。

つまり、IAP は Google Cloud 内部への通信経路を作るための入口で、Entra ID は Claude apps Gateway を利用するための入口です。

Claude Code から見た接続先

SSH のローカルポートフォワードを開始すると、クライアント PC の 443 番ポートが、内部アプリケーションロードバランサーの 443 番ポートへ転送されます。

Claude Code からは、前回と同じ Gateway の URL へ接続します。

https://claude-gateway.private.example.co.jp

ただし、このホスト名をインターネット上や Google Cloud 内部の IP アドレスへ名前解決すると、通信は SSH トンネルを通りません。

そこで、クライアント PC の hosts ファイルを編集し、Gateway のホスト名をループバックアドレスへ向けます。

127.0.0.1 claude-gateway.private.example.co.jp

Windows の場合は、管理者権限で C:\Windows\System32\drivers\etc\hosts ファイルを編集します。

この状態で、Claude Code が https://claude-gateway.private.example.co.jp へ接続すると、

名前解決結果は 127.0.0.1 となり、クライアント PC の 443 番ポートへ通信します。

その通信は、SSH のローカルポートフォワードによって内部アプリケーションロードバランサーへ転送されます。

ホスト名自体は変更されないため、内部アプリケーションロードバランサーに設定した TLS 証明書も、そのまま利用できます。

gateway.yaml の public_url も変更しません。

listen:
  host: 0.0.0.0
  port: 8080
  public_url: https://claude-gateway.private.example.co.jp

Claude Code 側の Gateway URL も、前回と同じです。

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.private.example.co.jp"
}

Entra ID へ登録しているリダイレクト URI (https://claude-gateway.private.example.co.jp/oauth/callback)も変更する必要はありません。

事前に確認すること

IAP 経由の SSH ポートフォワードを利用する前に、次の設定を確認します。

IAP から踏み台 VM へのファイアウォール

IAP 経由で SSH 接続する場合、Google が管理する IAP プロキシから踏み台 VM の 22 番ポートへ通信が行われます。

IPv4 の場合、IAP TCP 転送で使用される送信元範囲を 35.235.240.0/20 とします。

踏み台 VM の 22 番ポートに対し、この範囲からの受信を許可します。

例えば、踏み台 VM へ次のネットワークタグを付けているとします。

例: claude-gateway-connector

前回の記事で作成済みではありますが、この場合のファイアウォールルールの作成方法は次の通りです。

gcloud compute firewall-rules create allow-iap-ssh-to-gateway-connector \
  --project="$PROJECT_ID" \
  --network="$VPC_NETWORK" \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:22 \
  --source-ranges=35.235.240.0/20 \
  --target-tags=claude-gateway-connector

踏み台 VM から内部ロードバランサーへの通信

SSH のローカルポートフォワードでは、内部アプリケーションロードバランサーへの TCP 接続は踏み台 VM から行われます。

そのため、踏み台 VM から内部ロードバランサーの 443 番ポートへ接続できることを確認します。

オーナーロールなどで踏み台 VMへ接続して、次のコマンドを実行します。

curl -v "https://claude-gateway.private.example.co.jp/healthz"

こちらも前回の記事と同じですが、次のような内容であれば OK です。

"
* Host claude-gateway.private.example.co.jp:443 was resolved.
* IPv6: (none)
* IPv4: 10.50.20.10
*   Trying 10.50.20.10:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
......
> GET /healthz HTTP/1.1
> Host: claude-gateway.private.example.co.jp
> User-Agent: curl/8.21.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< x-content-type-options: nosniff
< x-frame-options: DENY
< referrer-policy: no-referrer
< cross-origin-opener-policy: same-origin
< x-request-id: ....
< content-type: text/plain;charset=utf-8
< x-cloud-trace-context: .....
< date: Thu, 23 Jul 2026 07:59:45 GMT
< server: Google Frontend
< content-length: 2
< via: 1.1 google
<
ok* Connection #0 to host claude-gateway.private.example.co.jp:443 left intact

なお、ここでは、前回同様 10.50.20.10 を内部アプリケーションロードバランサーの IP アドレスとしています。

この通信で失敗する場合は、IAP ではなく、踏み台 VM からロードバランサーまでの経路、DNS、ファイアウォール設定を確認します。

利用者の IAM ロール

IAP 経由で踏み台 VM へ SSH 接続するユーザー（オーナー以外）には、IAP トンネルを利用する権限と、Compute Engine へ SSH ログインする権限が必要です。

API の有効化

IAP を利用するので、Cloud Identity-Aware Proxy API を有効化します。

gcloud services enable iap.googleapis.com

Compute Engine の OS Login の有効化

IAP でログインするにあたって、踏み台 VM の OS Login が有効化されているかを確認します。

Compute Engine の VM インスタンス画面から作成済みの踏み台 VM を選択して、カスタムメタデータ に enable-oslogin が TRUE とされていなければ、インスタンスを編集してメタデータを入れておきましょう。

IAP を利用する権限

IAP を利用するためと、gcloud compute ssh が対象インスタンスを参照、ログイン、それから GCE のサービスアカウントとして振る舞えるように、次のロールを与えます。

roles/iap.tunnelResourceAccessor (IAP で保護されたトンネルユーザー)
roles/compute.viewer (Compute 閲覧者)
roles/compute.osLogin (Compute OS ログイン)
roles/iam.serviceAccountUser (サービスアカウントユーザー)

gcloud projects add-iam-policy-binding $PROJECT_ID" \
    --member="user:ユーザーのメールアドレス" \
    --role="roles/iap.tunnelResourceAccessor"

gcloud projects add-iam-policy-binding $PROJECT_ID" \
    --member="user:ユーザーのメールアドレス" \
    --role="roles/compute.viewer"

gcloud projects add-iam-policy-binding $PROJECT_ID" \
    --member="user:ユーザーのメールアドレス" \
    --role="roles/compute.osLogin "

gcloud projects add-iam-policy-binding $PROJECT_ID" \
    --member="user:ユーザーのメールアドレス" \
    --role="roles/iam.serviceAccountUser"

なお、--member 部分は運用面を考慮するとグループを指定した方が現実的です。

IAP 経由でポートフォワードを開始する

クライアント PC へ Google Cloud CLI をインストールし、対象プロジェクトへアクセスできるユーザーでログインします。

gcloud auth login

次に、IAP 経由で踏み台 VM へ SSH 接続し、ローカルポートフォワードを開始します。

gcloud compute ssh claude-gateway-cloudflared-vm \
  --project=$PROJECT_ID \
  --zone=$ZONE \
  --tunnel-through-iap \
  --ssh-flag="-L 443:10.50.20.10:443" \
  --ssh-flag="-N"

各オプションの意味は次のとおりです。

オプション	内容
`--tunnel-through-iap`	IAP 経由で SSH 接続する
`-L 443:10.50.20.10:443`	ローカルの 443 番を内部 LB の 443 番へ転送する
`-N`	リモート側でコマンドやシェルを実行しない

10.50.20.10 には、内部アプリケーションロードバランサーのIPアドレスを指定します。

コマンドを実行すると、Windows であれば、PuTTY が起動して、そのまま待機状態になります。

このコマンドを実行している間だけ、クライアント PC の 443 番ポートから内部ロードバランサーへの通信が可能になります。

別の PowerShell などのターミナルを開き、接続を確認します。

curl -sS https://claude-gateway.private.example.co.jp/.well-known/oauth-authorization-server

前回の記事同様に JSON レスポンスが返ってくれば成功です。

Claude Codeを実行する

Claude Code の managed-settings.json の内容は前回と全く同じです。

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.private.example.co.jp"
}

IAP 経由の SSH ポートフォワードを実行したまま、別のターミナルで次のコマンドを実行して、前回までの Claude Code のセッションをログアウトしておきましょう。

claude auth logout

続いて Claude Code を起動します。

claude

起動したら Claude Code 上でログインを実行します。

/login

未認証であれば、ブラウザに Entra ID のログイン画面が表示されます。

認証済みであれば下図のような画面が表示されるので、前回と同様に認証すると Claude Code が利用できるようになります。

/status を実行して状況を確認してみた様子です。

API Provider や Gateway URL が変わっているのがわかると思います。

ここで認証を行うと、Gatewayから短期トークンが発行され、Claude Codeを利用できるようになります。

適当な質問を入力して、モデルから応答が返ることを確認します。

現在の作業ディレクトリにあるファイルを確認してください。

この構成のメリットと制約

今回の構成には、次のメリットがあります。

Cloudflare Zero Trust の契約や初期設定が不要
Cloudflare One Client を端末へ導入しなくてよい
Cloudflare Tunnel や Private Hostname の設定が不要
既存の踏み台 VM と内部ロードバランサーを流用できる
踏み台 VM に追加の TCP リレーを構築しなくてよい
Google Cloud IAM で利用者を制御できる
踏み台 VM に外部 IP アドレスを付けなくても利用できる
Gateway の Entra ID 認証をそのまま利用できる
Gateway URL や Entra ID のリダイレクト URI を変更しなくてよい

一方、制約もあります。

クライアント PC へ Google Cloud CLI が必要
利用者は Google Cloud 側でも認証する必要がある
利用者に踏み台 VM への SSH 接続権限が必要
Claude Code を利用する前に SSH ポートフォワードを開始する必要がある
SSH を実行しているターミナルを閉じると接続も終了する
hosts ファイルの設定が必要
クライアント PC の 443 番ポートが空いている必要がある
多数の利用者へ恒常的に提供するには運用が煩雑になる

少人数による検証や、管理者、一部の開発者だけが利用する場合には、非常に簡単な構成です。

一方、多数の一般ユーザーへ常設の接続環境を提供する場合には、利用者全員へ Google Cloud IAM と SSH ログイン権限を付与する必要があります。

そのような場合は、Cloudflare Zero Trust、Cloud VPN、Cloud Interconnect などを利用する構成のほうが適しています。

まとめ

今回は、Cloudflare Zero Trust を使わず、IAP 経由の SSH ローカルポートフォワードを利用して、Claude Code から Google Cloud 内部の Claude apps Gateway へ接続しました。

前回に比べて、まずは試してみたいというだけならば、今回のように IAP という選択肢の方が良いかもしれません。

次回こそは Spend Limits などを調べてみようと思います！

Anthropic,Google Cloud,実装例Claude,Google Cloud Platform(GCP),Identity-Aware Proxy(IAP)

Posted by 関口貴生