ドメイン不要！Cloud Run のカスタム URL を使ってみた

はじめに

DX開発事業部の田村です。
2026年9月28日の Cloud Run リリースノート に、次の文が追加されていました。

Create custom URLs, like example.cloud.run, that are easy to remember and globally available for your Cloud Run services. No DNS configuration, load balancers, or extra costs required.

Cloud Run のサービスに、https://好きな名前.cloud.run という URL を付けられる機能です（Preview）。独自ドメインの取得も、DNS の設定も、ロードバランサも不要で、追加料金もかからないと書かれています。

Cloud Run の URL は長くて覚えにくい、と感じている方は多いと思います。PoC やデモで URL を共有するたびに「この長い URL、どうにかならないかな」と思っていたので、さっそく使ってみました。

TL;DR

Cloud Run の URL 形式を整理する

Cloud Run のサービスには、これまで2種類の URL が発行されていました。今回のカスタム URL を加えると3種類になります。

決定的 URL の登場で、デプロイ前に URL が分かるようにはなりました。それでも人に伝えるには長く、プロジェクト番号も見えてしまいます。カスタム URL なら、この2つをまとめて解決できます。

独自ドメインを使う方法との比較

分かりやすい URL で公開したいだけなら、これまでも独自ドメインを使う方法がありました。主な選択肢と比べると、次のようになります（2026年9月29日時点の情報です）。カスタム URL は Preview のため、今後の GA までに内容が変わる可能性があります。

ひとことで言えば、手間ゼロで覚えやすい URL が手に入る代わりに、名前は自分のものではない機能です。本番サービスのドメインにするより、PoC、デモ、社内ツール、ハッカソンなどで、とりあえず短い URL を共有したい場面に向いていると感じました。

なお、従来のドメインマッピングが使えるのは10リージョンだけで、大阪（asia-northeast2）は含まれません。カスタム URL は大阪のサービスでも問題なく使えました。

やってみた：コンソールから設定する

コンソールでは、2か所から設定できます。

既存のサービスに付ける

Cloud Run の「ドメイン マッピング」画面を開くと、従来の「マッピングを追加」の隣に「カスタム URL を追加」ボタンが増えています。

サービスを選んで、サブドメインの部分を入力するだけです。.cloud.run はあらかじめ固定で入っています。

比較のために、従来の「マッピングを追加」ダイアログも載せておきます。こちらは「ドメインを入力 → DNS レコードを更新する」の2ステップで、独自ドメインと DNS の設定が前提です。

「続行」を押すと、すぐに一覧に追加されます。

新しくサービスを作るときに付ける

サービスの作成画面にも「カスタム URL」欄が追加されていて、作成と同時に付けられます。

作成の進行状況には「カスタム URL の作成」というステップが表示されます。サービス詳細の URL 欄にも、cloud.run の URL が表示されました。

ブラウザでアクセスすると、ちゃんとサンプルページが表示されました。

やってみた：gcloud から設定する

gcloud の場合は、従来のドメインマッピングと同じ gcloud beta run domain-mappings コマンドを使います。--domain に xxx.cloud.run を指定するだけです。

gcloud beta run domain-mappings create \
  --service=crurl-verify-echo \
  --domain=crurl-tmr0929.cloud.run \
  --region=asia-northeast1

describe で中身を見ると、リソースは従来と同じ DomainMapping でした。

apiVersion: domains.cloudrun.com/v1
kind: DomainMapping
metadata:
  labels:
    cloud.googleapis.com/location: asia-northeast1
    serving.knative.dev/service: crurl-verify-echo
  name: crurl-tmr0929.cloud.run
spec:
  routeName: crurl-verify-echo
status:
  conditions:
  - status: 'True'
    type: Ready
  - status: 'True'
    type: DomainRoutable
  mappedRouteName: crurl-verify-echo

独自ドメインのマッピングでは、CertificateProvisioned という条件や、DNS に登録するレコード（resourceRecords）が出力されます。カスタム URL ではどちらもありません。証明書の発行も DNS の設定も不要なので、その分がなくなっているようです。

名前のルールと禁止ワード

違反したときのエラーメッセージによると、サブドメインのルールは次のとおりです。

• 6〜63文字
• 英小文字・数字・ハイフンのみ
• 先頭と末尾は英数字

ドキュメントには「一部のサブドメインは制限されている」としか書かれていません。ところが実際に試すと、禁止ワードが想像以上に多いことが分かりました。ハイフンで区切った一部に含まれているだけでも弾かれます。

ERROR: (gcloud.beta.run.domain-mappings.create) INVALID_ARGUMENT: metadata.name:
The subdomain 'crurl-verify-tmr0929' contains the prohibited term 'verify'
and cannot be used in Cloud Run custom URL.

今回弾かれた単語は次のとおりです。

禁止ワードの一覧や理由はドキュメントに書かれていません。ただ、ドキュメントには「不正利用の防止や商標の保護などのためにサブドメインを管理する」とあるので、同じような目的だと思われます。xxx-api や xxx-demo のような、ありがちな名前が使えないのは地味に困りますね。

コンソールでは、入力した時点でエラーが表示されます。

ほかにも、名前について次のような点に気づきました。

• 名前は Google Cloud 全体で一意です。同じプロジェクトでも、別のリージョンで同じ名前は作れませんでした。
• 大文字を含む名前は避けたほうが無難です。TMR0929UP.cloud.run は作成できてしまいましたが、20分以上たっても 404 のままでした。
• portfolio や chatbot のようなありがちな名前も、空いていればそのまま作成できました（確認したあとすぐに削除しています）。ドキュメントには、ほかのユーザーが使っている名前はエラーになると書かれているので、名前は早い者勝ちのようです。

証明書はどうなっているのか

従来のドメインマッピングでは、ドメインごとに Google マネージド証明書が発行されます。発行まで15分、長いと24時間かかります。カスタム URL ではどうなっているのかを見てみました。

経路の途中で証明書が書き換わることがないよう、Google Cloud 内の Cloud Build 上で確認しています。

echo | openssl s_client -connect crurl-tmr0929.cloud.run:443 -servername crurl-tmr0929.cloud.run 2>/dev/null \
  | openssl x509 -noout -issuer -subject -ext subjectAltName

issuer=C=US, O=Google Trust Services, CN=WE2
subject=CN=cloud.run
X509v3 Subject Alternative Name:
    DNS:cloud.run, DNS:*.cloud.run

発行者の CN は、実行のたびに WE2 と WR2 のどちらかになりました（どちらも Google Trust Services の中間 CA です）。

証明書は Google Trust Services が発行した *.cloud.run のワイルドカード証明書でした。まだ誰もマッピングしていないサブドメインにアクセスしても、同じ証明書が返ってきます。

カスタム URL ごとに証明書を発行するのではなく、*.cloud.run 共通のワイルドカード証明書を使っているようです。証明書の発行を待たなくていいのはこのためですね。

独自の証明書を持ち込むことはできないので、それが必要なら従来どおり LB を使うことになります。

DNS とルーティング：独自ドメインとの違い

独自ドメインでドメインマッピングを使う場合は、Cloud Run が表示する DNS レコード（A / AAAA / CNAME）を、自分でレジストラや DNS に登録します。その後、DNS の反映（数分〜数時間）と証明書の発行（15分〜24時間）を待つ必要があります。

カスタム URL ではこの手順がまるごとありません。実際の名前解決がどうなっているのか、dig で見てみました（公開リゾルバの 8.8.8.8 に問い合わせています）。

dig +noall +answer @8.8.8.8 crurl-lookup-tmr0929.cloud.run A

crurl-lookup-tmr0929.cloud.run. 300 IN  A   34.143.75.2
crurl-lookup-tmr0929.cloud.run. 300 IN  A   34.143.73.2
crurl-lookup-tmr0929.cloud.run. 300 IN  A   34.143.79.2
（ほか5件。合計8件で、34.143.72.2〜34.143.79.2）

マッピング済みの名前、まだ誰も使っていない名前、run.app の URL を比べると、次のようになりました。

cloud.run の権威 DNS は ns1〜4.google.com で、*.cloud.run のワイルドカードレコードが登録されていました。マッピングを作っても DNS の応答は変わらず、どの名前を引いても同じ Google のアドレスが返ります。どのサービスに届けるかは、DNS ではなく Google 側が接続先のホスト名を見て振り分けているようです。

公開ログにホスト名が載るか

独自ドメインで証明書を発行すると、そのホスト名は Certificate Transparency（CT）ログに記録され、crt.sh などで誰でも検索できます。カスタム URL の場合を crt.sh で検索してみました。

共通のワイルドカード証明書を使う今の仕組みでは、自分のカスタム URL のホスト名が CT ログに載ることはありません（2026年9月29日に crt.sh で確認）。

「グローバル」の意味

リリースノートには globally available とあります。ドキュメントでは、run.app の URL と同じようにどこからでもアクセスできる、という意味で説明されています。DNS も run.app と同じアドレスを返していたので、仕組みは従来の run.app と同じと考えてよさそうです。

念のため、東京リージョンのサービスに東京と米国（us-central1）の Cloud Build からアクセスして、時間を測ってみました（5回測定し、初回を除いた代表値です）。

米国からでも接続そのものはすぐに確立し、応答までの時間は東京との距離の分だけ伸びています。サービス自体は東京にあるので、遠い地域からは距離の分だけ応答が遅くなります。

認証付きのサービスで使う

--no-allow-unauthenticated で認証を必須にしたサービスでも試しました。サービスアカウントの ID トークンを、audience を変えながら発行して送っています。

まず、run.app の URL を audience にしたトークンは、カスタム URL でもそのまま使えました。既存のクライアントは、宛先の URL を変えるだけで動きそうです。

カスタム URL 自体を audience にしたい場合は、ドキュメントにあるとおりカスタム オーディエンス（custom audience）を追加します。

gcloud beta run services update crurl-verify-private \
  --add-custom-audiences=crurl-priv-tmr0929.cloud.run \
  --region=asia-northeast1

ここで一つ注意があります。audience は文字列の完全一致で判定されます。

Google の認証ライブラリなどは宛先の URL を audience に使うことが多いので、https:// 付きの値も登録しておくと安心です。

gcloud beta run services update crurl-verify-private \
  --add-custom-audiences=https://crurl-priv-tmr0929.cloud.run \
  --region=asia-northeast1

run.app の URL を無効にする

--no-default-url で run.app の URL を無効にしても、カスタム URL は動き続けます（ドキュメントにも書かれている挙動です）。

gcloud beta run services update crurl-verify-echo \
  --no-default-url \
  --region=asia-northeast1

コンソールでは、サービス詳細の「ネットワーキング」タブにある「デフォルトの HTTPS エンドポイント URL」がオフになります。その下の「ドメイン マッピング」欄にカスタム URL の一覧が表示されます。

これで cloud.run の URL だけで公開する構成が作れます。プロジェクト番号入りの URL を外に出したくないときに便利です。

付け替えと削除

別のサービスへ付け替える

カスタム URL には更新コマンドがありません。別のサービスへ移すには「削除 → 再作成」をします。

大阪のサービスから東京のサービスへ移しながら curl を送り続けたところ、200 以外が返ったことは一度もありませんでした。削除した後も約1分半（85秒）は古いサービスが応答し、しばらく新旧の応答が混ざってから切り替わりました。

ただし削除から再作成までの数秒間、その名前は誰でも取れる状態になります。ドキュメントでも、頻繁な削除はドメインスナイピング（名前を横取りされること）のリスクがあるので避けるよう書かれています。大事な名前ほど、付け替えはなるべくしないほうが安全です。

サービスを削除した場合

サービスを削除してもマッピングは残り、名前も確保されたままでした。アクセスすると 404 が返ります。コンソールの一覧では、マッピング先のサービス名に ⚠ マークが付きます。

名前をもう使わないときは、マッピングを明示的に削除する必要があります。

ドキュメントに書かれていない挙動のまとめ

使っていて気づいた、ドキュメントには書かれていない（または書き方と少し違う）挙動をまとめておきます。

まとめ

Cloud Run のカスタム URL は、独自ドメインも DNS も証明書の準備もなしで、xxx.cloud.run という覚えやすい URL を付けられる機能でした。

名前が自分のものにならないこと、Preview であること、Terraform に対応していないことを考えると、今のところ本番サービスのドメインには向きません。本番は従来どおり、独自ドメインと LB の組み合わせが良いと思います。

一方で、PoC やデモ、社内向けのちょっとしたツールなら、URL を伝えやすくなるだけでもかなり便利です。長い run.app の URL をチャットに貼っていた方は、ぜひ一度試してみてください。

参考

• Cloud Run release notes
• Custom URLs for Cloud Run services
• Mapping custom domains | Cloud Run
• Invoke with an HTTPS request | Cloud Run