Cloud Runに独自ドメインを設定する：3つの方法の選び方と手順

Cloud Runにデプロイしたサービスには、run.app で終わるURLが自動で割り当てられます。
動作確認には便利ですが、企業サイトや利用者向けのサービスでは、www.example.com のような独自ドメインで公開したいところです。
Cloud Runで独自ドメインを使う方法は1つではなく、どれを選ぶかで、使えるリージョンや機能、運用の手間が変わります。
この記事では、3つの方法の違いと選び方、推奨される方法の手順、DNSや証明書でつまずきやすい点を説明します。

独自ドメインを設定する3つの方法

Cloud Runの公式ドキュメントでは、次の3つの方法が案内されています。

ドメインマッピングは、2026年11月12日時点の公式ドキュメントで「プレビュー」とされ、レイテンシの問題から本番環境での利用は推奨されていません。
検証環境や社内向けの小さなサービスならドメインマッピング、本番の公開サービスならロードバランサ、と分けて考えると判断しやすくなります。

ドメインマッピングの制約を知っておく

手軽なドメインマッピングを選ぶ前に、次の制約に当てはまらないかを確認します。

• 対応リージョンは限られる（東京の asia-northeast1 は対象で、大阪の asia-northeast2 は対象外）。
• マッピングできるのはルートパス（/）だけで、/users のようなパス単位の振り分けはできない。
• ワイルドカード証明書は使えず、独自の証明書もアップロードできない。
• TLS 1.0と1.1を無効にできない（TLS 1.2以上に限定したいなら、ロードバランサかFirebase Hostingを使う）。
• 最初に使うときは、ベースドメイン（www.example.com なら example.com）の所有権を、Google Search Consoleで確認する必要がある。

設定手順は公式ドキュメント（Mapping custom domains）を参照してください。

ロードバランサで設定する手順

本番で推奨されるロードバランサの構成は、「静的IP → 転送ルール → HTTPSプロキシ（証明書）→ URLマップ → バックエンドサービス → サーバーレスNEG → Cloud Run」という流れです。
サーバーレスNEG（ネットワークエンドポイントグループ）は、Cloud Runのサービスをロードバランサのバックエンドとして登録するための部品です。
gcloudでは、次の順に作成します（名前やリージョンは例です）。

# 1. グローバルな静的IPアドレスを予約する
gcloud compute addresses create web-ip --network-tier=PREMIUM --ip-version=IPV4 --global

# 2. Cloud RunのサービスをサーバーレスNEGにする
gcloud compute network-endpoint-groups create web-neg \
    --region=asia-northeast1 --network-endpoint-type=serverless \
    --cloud-run-service=SERVICE

# 3. バックエンドサービスを作り、NEGを追加する
gcloud compute backend-services create web-backend \
    --load-balancing-scheme=EXTERNAL_MANAGED --global
gcloud compute backend-services add-backend web-backend --global \
    --network-endpoint-group=web-neg --network-endpoint-group-region=asia-northeast1

# 4. URLマップ、5. Googleマネージド証明書、6. HTTPSプロキシ
gcloud compute url-maps create web-map --default-service web-backend
gcloud compute ssl-certificates create web-cert --domains example.com,www.example.com
gcloud compute target-https-proxies create web-proxy \
    --ssl-certificates=web-cert --url-map=web-map

# 7. 443番ポートの転送ルール
gcloud compute forwarding-rules create web-https \
    --load-balancing-scheme=EXTERNAL_MANAGED --network-tier=PREMIUM \
    --address=web-ip --target-https-proxy=web-proxy --global --ports=443

最後に、予約したIPアドレスを確認し、DNSのAレコードに登録します。

gcloud compute addresses describe web-ip --format="get(address)" --global

この例のように、証明書に複数のドメイン（example.com と www.example.com）を入れた場合は、ドメインごとにAレコードを作ります。

NAME   TYPE   DATA
www    A      （予約したIPアドレス）
@      A      （予約したIPアドレス）

この設定は、コンソールでロードバランサを作る場合の項目です。
HTTPでアクセスされたときにHTTPSへ転送したい場合は、コンソールのフロントエンド設定で「HTTPからHTTPSへのリダイレクトを有効にする」を選ぶと、同じIPアドレスにリダイレクト用の設定が作られます。

つまずきやすい点

証明書がなかなか有効にならない

Googleマネージド証明書は、DNSのレコードがロードバランサ（またはドメインマッピング）を向くまで発行されません。
ドメインマッピングの場合、発行にはおよそ15分、長いと24時間かかると案内されています。
DNSの変更も、レジストラやTTLによっては反映に数時間かかります。
既存のサイトを移行するときは、切り替え中にHTTPSが使えない時間が出ることを見込んで、アクセスの少ない時間帯に作業します。
HTTPSでつながらないときは、証明書の状態が ACTIVE になっているかを確認します。

CAAレコードやCDNが検証を妨げる（ドメインマッピング）

この節は、ドメインマッピングを使う場合の注意です。
DNSにCAAレコードを設定している場合、ドメインマッピングでは pki.goog と letsencrypt.org の両方を許可する必要があります。
また、CDNの設定によっては証明書の検証が通らないことがあり、公式ドキュメントでは、Cloudflareの「Always use https」を無効にするよう案内されています。

run.app のURLから直接アクセスできてしまう

ロードバランサを置いても、Cloud Runの既定のURLが開いたままだと、Google Cloud Armor（不正なアクセスを遮断するWAFの機能）などの保護を通らずに、直接アクセスできてしまいます。
ingressの設定を、外部ロードバランサ経由のアクセスだけを受け付ける値に変えます。

gcloud run services update SERVICE --ingress internal-and-cloud-load-balancing

既定のURL自体が不要なら、gcloud run services update SERVICE --no-default-url で無効にできます。
どちらの設定も、独自ドメインでサービスが表示されることを確かめてから実行します。
先に実行すると、外部からサービスにアクセスできなくなることがあります。

まとめ

Cloud Runに独自ドメインを付けるときは、最初に「本番で使うか」「どのリージョンか」「パスの振り分けやGoogle Cloud Armorが必要か」を確認し、方法を選びます。
本番の公開サービスでは、手順が多くてもロードバランサを使い、ingressを internal-and-cloud-load-balancing に絞るところまでを1セットで設定します。
検証用ならドメインマッピングで手軽に始められますが、プレビューであることと対応リージョンの制約を前提に使います。
どの方法でも、DNSの反映と証明書の発行には時間がかかるため、切り替えの作業は余裕を持った日程で計画してください。

情報は2026年11月12日時点のものです。