G-gen の佐々木です。当記事では、Cloud Run サービスに https://<サブドメイン>.cloud.run 形式の短い URL を割り当てる機能、 カスタム URL （Custom URLs）について解説します。 概要 Cloud Run とは カスタム URL とは ドメインマッピングとの違い カスタム URL の基本 仕組み 命名規則 文字と長さの規則 サブドメインの一意性 使用できない単語 認証 ID トークンの検査 カスタムオーディエンス 設定の有無による応答の違い 制限事項 注意点 上り（内向き）を制限したサービス 削除したサブドメインは第三者が取得できる サービスを削除してもマッピングは残る 反映には時間がかかる 料金 設定手順 事前準備 新規サービスへの割り当て 既存サービスへのマッピング カスタムオーディエンスの設定 カスタム URL の削除 別のサービスへの移動 動作確認 カスタム URL へのアクセス デフォルト URL の無効化 audience ごとの認証結果 サービスを削除した場合 概要 Cloud Run とは Cloud Run は、Google Cloud のサーバーレスなコンテナ実行サービスです。HTTP リクエストを処理する サービス （service）をデプロイすると、サービスごとに HTTPS のエンドポイントが自動で割り当てられます。 当記事では、この自動で割り当てられる URL を デフォルト URL と呼びます。デフォルト URL は、サービス名、プロジェクト番号、リージョンから決まる run.app ドメインの URL です。 参考 : HTTPS リクエストで呼び出す - 決定論的 URL Cloud Run の基本については、以下の記事を参照してください。 blog.g-gen.co.jp カスタム URL とは カスタム URL （Custom URLs）は、Cloud Run サービスに https://<サブドメイン>.cloud.run 形式の URL を割り当てる機能です。サブドメインの部分はユーザーが指定します。 URL の種類 形式 デフォルト URL https://<サービス名>-<プロジェクト番号>.<リージョン>.run.app カスタム URL https://<サブドメイン>.cloud.run 参考 : カスタム URL を作成する カスタム URL の使用に当たり、独自ドメインの取得、DNS レコードの設定、ロードバランサの構築はいずれも不要で、コマンド1つで URL を割り当てられます。サービスを短く覚えやすい URL で共有したい場面で使用できます。 Cloud Run のカスタム URL には、以下の特徴があります。 https://<サブドメイン>.cloud.run という短い形式の URL をサービスに割り当てられる デフォルト URL と同様に、どこからでもアクセスできる 新しいリビジョンをデプロイせずに、URL の割り当てや解除、別のサービスへの割り当て直しができる 1つのサービスに複数のカスタム URL を割り当てられる 2026年10月現在、カスタム URL は Preview 公開の機能です。Preview 段階の機能は、サポートが限定される場合や、一般公開（GA）までに仕様が変わる可能性があるため、本番環境での使用は推奨されません。 参考 : Preview版のサービスを使うとはどういうことなのか - G-gen Tech Blog ドメインマッピングとの違い Cloud Run ではカスタム URL とは別に、独自ドメインをサービスに割り当てる ドメインマッピング という機能があります。カスタム URL は、gcloud CLI ではドメインマッピングと同じコマンドで操作しますが、性質は異なります。 カスタム URL は、Google が管理する cloud.run ドメインのサブドメインを使用します。ドメインマッピングの設定に必要なドメインの所有権確認や DNS レコードの設定は、カスタム URL では不要です。 比較項目 カスタム URL ドメインマッピング URL のドメイン cloud.run （Google が管理） ユーザー独自のドメイン ドメインの所有権確認 不要 必要 DNS レコードの設定 不要 必要 TLS 証明書 発行を待つ必要がない マッピング後に自動発行（通常15分程度、最大24時間） 提供ステータス Preview 公開 Preview 公開 なお、ドメインマッピングには、東京リージョン（asia-northeast1）などで呼び出しのレイテンシが非常に大きくなる既知の問題があり、2026年10月現在も解消されていません。 本番環境で独自ドメインを使用したい場合は、グローバル外部アプリケーションロードバランサを使用する方法が推奨されています。 参考 : カスタム ドメインのマッピング 参考 : Cloud Run の既知の問題 - 一部のリージョンからの呼び出し時にカスタム ドメインでリクエスト レイテンシが増加する カスタム URL の基本 仕組み カスタム URL は、サブドメインとサービスを対応付ける マッピング として管理されます。マッピングはサービスとは独立したリソースです。 そのため、マッピングの作成や削除では、サービスの新しいリビジョンは作成されません。1つのサービスに複数のマッピングを作成することもできます。 サブドメインは Google Cloud 全体で一意ですが、マッピング自体はサービスと同じリージョンに作成されるリージョンリソースです。 1つのサービスに複数のマッピングを作成できる cloud.run ドメインは未使用のサブドメインを含めてワイルドカードで名前解決され、TLS 証明書も *.cloud.run のワイルドカード証明書が使用されます。 そのため、マッピングごとに DNS の反映や証明書の発行を待つ必要がありません。ただし、マッピングの作成後、リクエストが安定してサービスに届くまでには時間がかかります。この点は注意点の節で説明します。 命名規則 文字と長さの規則 サブドメインは、以下の規則に従って指定します。 長さは6〜63文字 使用できる文字は小文字の英数字とハイフン 先頭と末尾は小文字の英数字 規則に違反するサブドメインを指定すると、以下のエラーになります。 # 5文字のサブドメインを指定した場合 $ gcloud beta run domain-mappings create \ --service = my-service-b \ --region = asia-northeast1 \ --project =< プロジェクトID > \ --domain = sshun.cloud.run ----- 出力例 ----- ERROR: ( gcloud.beta.run.domain-mappings.create ) INVALID_ARGUMENT: metadata.name: The subdomain ' sshun ' cannot be used as a valid custom URL. It must be 6-63 characters long, start and end with a lowercase alphanumeric character, and can only contain lowercase alphanumeric characters and hyphens. - ' @type ' : type .googleapis.com/google.rpc.BadRequest fieldViolations: - description: The subdomain ' sshun ' cannot be used as a valid custom URL. It must be 6-63 characters long, start and end with a lowercase alphanumeric character, and can only contain lowercase alphanumeric characters and hyphens. field: metadata.name 検証では、大文字を含むサブドメインも作成できました。ただし、小文字のサブドメインとは別のマッピングとして登録され、2つのマッピングが併存する状態になります。URL のホスト名は大文字と小文字を区別しないため、サブドメインは小文字で指定してください。 参考 : カスタム URL を作成する - 制限事項 サブドメインの一意性 サブドメインは Google Cloud 全体で一意です。すでに使用されているサブドメインを指定すると、以下のエラーになります。 # 別のプロジェクトで使用中のサブドメインを指定した場合 $ gcloud beta run domain-mappings create \ --service = hello \ --region = asia-northeast1 \ --project =< 別のプロジェクトID > \ --domain =< サブドメイン > .cloud.run ----- 出力例 ----- ERROR: ( gcloud.beta.run.domain-mappings.create ) Domain mapping to [< サブドメイン > .cloud.run ] already exists in this region. メッセージには「in this region」とありますが、他のリージョンや他のプロジェクトで使用中の場合も同じメッセージが表示されます。リージョンを変えても解決しないため、別のサブドメインを指定します。 使用できない単語 一部のサブドメインは使用が制限されています。2026年10月現在、制限対象の一覧は公式ドキュメントに記載されていません。 検証では、ハイフンで区切った単語のいずれかが特定の単語と一致する場合に、以下のエラーになりました。 # 末尾の単語が lb のサブドメインを指定した場合 $ gcloud beta run domain-mappings create \ --region = asia-northeast1 \ --project =< プロジェクトID > \ --service = my-service-c \ --domain = sasashun-ingress-lb.cloud.run ----- 出力例 ----- ERROR: ( gcloud.beta.run.domain-mappings.create ) INVALID_ARGUMENT: metadata.name: The subdomain ' sasashun-ingress-lb ' contains the prohibited term ' lb ' and cannot be used in Cloud Run custom URL. - ' @type ' : type .googleapis.com/google.rpc.BadRequest fieldViolations: - description: The subdomain ' sasashun-ingress-lb ' contains the prohibited term ' lb ' and cannot be used in Cloud Run custom URL. field: metadata.name 検証で拒否された単語は google 、 youtube 、 gemini 、 internal 、 lb 、 admin 、 www 、 auth の8つです。Google の製品名だけでなく、環境や用途を表す一般的な単語も含まれます。 一方、 internal2 のように単語が完全には一致しない場合や、ハイフンで区切らずに他の文字列と連結した場合は作成できました。ここに挙げた単語は検証で確認できた例であり、制限対象のすべてではありません。 参考 : カスタム URL を作成する - 制限事項 認証 ID トークンの検査 カスタム URL 経由のリクエストにも、デフォルト URL と同じくサービスの IAM 認証が適用されます。認証が必要なサービスでは、呼び出し元は Google が署名した ID トークンをリクエストに付与します。認証が必要なサービスは、受け取った ID トークンを2段階で検査します。 まず、トークンの宛先を示す audience （ aud クレーム）がサービス宛てかを確認します。次に、トークンの主体がサービスを呼び出す権限（Cloud Run 起動元、 roles/run.invoker ）を持つかを IAM で確認します。 audience が一致しない場合の応答は 401 です。トークンがない場合や、トークンの主体に権限がない場合の応答は 403 です。カスタム URL が関係するのは、前者の audience の検査だけです。 参考 : サービス間認証 カスタムオーディエンス Cloud Run がサービス宛てと判定する audience は、サービスのデフォルト URL です。サービス側で受け入れる audience の値を追加する設定を、Cloud Run では カスタムオーディエンス と呼びます。 カスタム URL をマッピングしても、カスタム URL が自動で audience として受け入れられることはありません。以下は、Cloud Run や Compute Engine 上で動作する呼び出し元が、メタデータサーバーから audience を指定して ID トークンを取得する例です。 # audience にデフォルト URL を指定して ID トークンを取得 $ curl -s -H " Metadata-Flavor: Google " \ " http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://<サービス名>-<プロジェクト番号>.<リージョン>.run.app " # audience にカスタム URL を指定して ID トークンを取得 $ curl -s -H " Metadata-Flavor: Google " \ " http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://<サブドメイン>.cloud.run " 1つ目のコマンドで取得したトークンは、カスタムオーディエンスを設定しなくても、カスタム URL 経由の呼び出しに使用できます。 2つ目のコマンドで取得したトークンは、カスタムオーディエンスを設定していないサービスでは使用できません。audience がサービス宛てと判定されず、応答は 401 になります。 このトークンを使用するには、サービスに https://<サブドメイン>.cloud.run をカスタムオーディエンスとして設定します。 カスタムオーディエンスが必要になるのは、呼び出し元が audience にカスタム URL を指定する場合です。 Cloud Scheduler や Pub/Sub の push サブスクリプションのように、呼び出し先の URL をそのまま audience にするサービスから、カスタム URL 宛てに呼び出す構成が典型です。 参考 : サービスにカスタム オーディエンスを設定する 設定の有無による応答の違い サービスの認証設定、ID トークンの audience、カスタムオーディエンスの組み合わせごとに、カスタム URL を呼び出した結果を整理すると以下のとおりです。 サービスの認証設定 ID トークンの audience カスタムオーディエンス 応答 未認証アクセスを許可 トークンなし 設定の有無に無関係 200 認証が必要 トークンなし 設定の有無に無関係 403 認証が必要 デフォルト URL 設定の有無に無関係 200 認証が必要 カスタム URL 設定なし 401 認証が必要 カスタム URL カスタム URL を設定 200 カスタムオーディエンスの設定で結果が変わるのは、表の下2行だけです。サービス側の設定手順は、「カスタムオーディエンスの設定」の節で説明します。 制限事項 2026年10月現在、カスタム URL には以下の制限事項があります。 デフォルトでは、1つのプロジェクトにマッピングできるドメインは最大50件 カスタム URL だけを一時的に無効化することはできず、トラフィックの提供を止めるにはマッピングを削除する 上り（内向き）の設定を「内部」または「内部と Cloud Load Balancing」に制限しているサービスではサポートされない Terraform はサポートされない 不正利用の防止や商標の保護などを理由に、Google がサブドメインを取り消す、または再割り当てする場合がある なお、カスタム URL はデフォルト URL から独立しています。サービスのデフォルト URL を無効化しても、カスタム URL は引き続き使用できます。 参考 : カスタム URL を作成する - 制限事項 参考 : Cloud Run のネットワーク上り（内向き）を制限する - デフォルトの URL を無効にする 注意点 上り（内向き）を制限したサービス 上り（内向き）を「内部」または「内部と Cloud Load Balancing」に制限しているサービスは、カスタム URL をサポートしていません。 検証では、上り（内向き）を「内部」に制限したサービスに対しても、マッピングの作成はエラーにならず、マッピングの状態も正常と表示されました。しかし、インターネットからカスタム URL にアクセスすると 404 が返ります。 設定が成功したように見えても、インターネットからはアクセスできない状態になります。このようなサービスでは、カスタム URL を使用せず、デフォルト URL を使用してください。 参考 : Cloud Run のネットワーク上り（内向き）を制限する 削除したサブドメインは第三者が取得できる マッピングを削除すると、そのサブドメインは即座に他のユーザーが取得できる状態になります。 第三者に同じサブドメインを取得されると、以前の URL を知っている利用者が第三者のサービスにアクセスするおそれがあります。一度設定したマッピングの削除には、このリスクが伴います。削除は必要な場合に限り、削除と再作成を繰り返す運用は避けてください。 参考 : カスタム URL を作成する - カスタム URL を削除する サービスを削除してもマッピングは残る マッピング済みのサービスを削除しても、マッピングは自動では削除されません。サブドメインは占有されたままになり、プロジェクトあたりの上限も消費し続けます。 検証では、残ったマッピングは、同じ名前のサービスを再度デプロイすると新しいサービスへルーティングされました。意図しないサービスがカスタム URL で公開されないよう、不要になったマッピングは明示的に削除することを推奨します。 反映には時間がかかる 公式ドキュメントでは、既知の問題として、マッピングの作成後に完全に動作するまで数秒かかる場合があるとされています。 検証では、作成から約2分間は、正常な応答と 404 が混在しました。別のサービスへ移動した場合も、移動前のサービスがしばらく応答を続けます。詳細は動作確認の章で示します。 参考 : カスタム URL を作成する - 既知の問題 料金 2026年10月現在、カスタム URL の使用に追加の料金はかかりません。サービスの実行にかかる料金は、カスタム URL の有無で変わりません。 設定手順 事前準備 以降では、gcloud CLI でカスタム URL の割り当て、確認、削除、移動を行います。コンソールでも同等の操作が可能で、サービスの作成フォームやドメインマッピングのページからカスタム URL を追加できます。 検証は東京リージョン（asia-northeast1）で行いました。gcloud CLI のバージョンは以下のとおりです。 # gcloud CLI のバージョンを確認 $ gcloud version ----- 出力例 ----- Google Cloud SDK 587 . 0 . 0 beta 2026 . 09 . 25 // 省略 core 2026 . 09 . 25 // 省略 2026年10月現在、カスタム URL の操作には gcloud beta run コマンドを使用します。 gcloud CLI のバージョンが古い場合、 --domain に .cloud.run のサブドメインを指定すると以下のエラーになります。 # 古いバージョンの gcloud CLI でカスタム URL を指定した場合 $ gcloud beta run domain-mappings create \ --service = my-service-a \ --domain =< サブドメイン > .cloud.run \ --region = asia-northeast1 \ --project =< プロジェクトID > ----- 出力例 ----- ERROR: ( gcloud.beta.run.domain-mappings.create ) The provided domain does not appear to be verified for the current account. To verify it, run: $ gcloud domains verify < サブドメイン > .cloud.run Once verified, try this command again. Currently verified domains: * < 所有権を確認済みのドメイン > メッセージはドメインの所有権確認を案内していますが、 cloud.run は Google が管理するドメインであり、ユーザーが所有権を確認することはできません。このエラーが表示された場合は、 gcloud components update コマンドで gcloud CLI を更新します。 マッピングはリージョンリソースのため、操作時にはリージョンの指定が必要です。gcloud CLI の run/region プロパティを設定していない環境で --region を省略すると、 You must specify a region. というエラーになります。 当記事のコマンドは、すべて --region を指定しています。 マッピングを作成、更新、削除するユーザーには、プロジェクトレベルで Cloud Run 管理者（ roles/run.admin ）が必要です。 参考 : カスタム URL を作成する - 必要なロール 新規サービスへの割り当て gcloud beta run deploy コマンドの --domain に <サブドメイン>.cloud.run を指定すると、サービスのデプロイと同時にカスタム URL を割り当てられます。 コンテナイメージには、Google が提供するサンプルイメージ us-docker.pkg.dev/cloudrun/container/hello:latest を使用しました。 # カスタム URL を指定してサービスをデプロイ $ gcloud beta run deploy my-service-a \ --image = us-docker.pkg.dev/cloudrun/container/hello:latest \ --domain =< サブドメイン > .cloud.run \ --region = asia-northeast1 \ --project =< プロジェクトID > ----- 出力例 ----- Allow unauthenticated invocations to [ my-service -a] ( y/N ) ? Deploying container to Cloud Run service [ my-service -a] in project [< プロジェクトID >] region [ asia-northeast1 ] Deploying new service... Creating Revision................................................................done Creating domain mapping................................................done Routing traffic...done Creating domain mapping...done Done. Service [ my-service -a] revision [ my-service-a-00001-fmh ] has been deployed and is serving 100 percent of traffic. Service URL: https://my-service-a- < プロジェクト番号 > .asia-northeast1.run.app Proxy locally with: gcloud run services proxy my-service-a --region asia-northeast1 --project < プロジェクトID > 出力の Creating domain mapping の行が、カスタム URL のマッピングの作成を示しています。 Service URL にはデフォルト URL のみが表示され、カスタム URL は表示されません。 作成されたマッピングは、 gcloud beta run domain-mappings list コマンドで一覧表示できます。複数のリージョンにサービスがある場合は、リージョンごとに実行します。 # リージョン内のマッピングを一覧表示 $ gcloud beta run domain-mappings list --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- DOMAIN SERVICE REGION ✔ < サブドメイン > .cloud.run my-service-a asia-northeast1 マッピングの詳細は gcloud beta run domain-mappings describe コマンドで表示します。 # マッピングの詳細を表示 $ gcloud beta run domain-mappings describe \ --domain =< サブドメイン > .cloud.run \ --region = asia-northeast1 \ --project =< プロジェクトID > ----- 出力例 ----- apiVersion: domains.cloudrun.com/v1 kind: DomainMapping // 省略 spec: routeName: my-service-a status: conditions: - lastTransitionTime: ' 2026-09-30T06:27:48.748572Z ' status: ' True ' type: Ready - lastTransitionTime: ' 2026-09-30T06:27:48.748572Z ' status: ' True ' type: DomainRoutable mappedRouteName: my-service-a observedGeneration: 1 参考 : gcloud beta run deploy 既存サービスへのマッピング 既存のサービスにカスタム URL をマッピングするには、 gcloud beta run domain-mappings create コマンドを使用します。 --service にサービス名、 --domain に <サブドメイン>.cloud.run を指定します。 # 既存のサービスにカスタム URL をマッピング $ gcloud beta run domain-mappings create \ --service = my-service-a \ --domain =< サブドメイン > .cloud.run \ --region = asia-northeast1 \ --project =< プロジェクトID > ----- 出力例 ----- Creating...... .............done. サブドメインを変えて同じコマンドを繰り返すと、1つのサービスに複数のカスタム URL をマッピングできます。 参考 : gcloud beta run domain-mappings create カスタムオーディエンスの設定 audience にカスタム URL を指定した ID トークンを受け入れるには、サービスにカスタムオーディエンスを設定します。 カスタムオーディエンスの値は、トークンの audience と文字列として完全一致で照合されます。 https:// の有無や末尾のスラッシュが異なるだけでも一致しません。 たとえば <サブドメイン>.cloud.run のようにスキーム（ https:// ）なしの値を設定した場合、受け入れられるのは audience が <サブドメイン>.cloud.run のトークンだけです。 audience に https://<サブドメイン>.cloud.run を指定したトークンは 401 になります。 呼び出し元が audience に指定する値は、呼び出し先の URL 全体（ https:// 付き）であるのが通例です。そのため当記事では、 https://<サブドメイン>.cloud.run をカスタムオーディエンスとして設定します。 以下は、カスタム URL をマッピング済みで認証が必要なサービス my-service-b に設定する例です。 # サービスにカスタムオーディエンスを追加 $ gcloud beta run services update my-service-b \ --add-custom-audiences = https:// < サブドメイン > .cloud.run \ --region = asia-northeast1 \ --project =< プロジェクトID > ----- 出力例 ----- Deploying... Creating Revision.............................................................done Routing traffic.....done Done. Service [ my-service -b] revision [ my-service-b-00003-fbp ] has been deployed and is serving 100 percent of traffic. Service URL: https://my-service-b- < プロジェクト番号 > .asia-northeast1.run.app Proxy locally with: gcloud run services proxy my-service-b --region asia-northeast1 --project < プロジェクトID > マッピングの作成や削除とは異なり、カスタムオーディエンスの設定では新しいリビジョンが作成されます。 呼び出し元では、ここで設定した値と同じ文字列を audience に指定して ID トークンを取得します。Cloud Scheduler や Pub/Sub の push サブスクリプションのように、audience を設定項目として持つサービスでは、同じ値を設定します。 参考 : カスタム URL を作成する - カスタム オーディエンスで保護する カスタム URL の削除 カスタム URL を削除するには、 gcloud beta run domain-mappings delete コマンドを使用します。 # カスタム URL のマッピングを削除 $ gcloud beta run domain-mappings delete \ --domain =< サブドメイン > .cloud.run \ --region = asia-northeast1 \ --project =< プロジェクトID > \ --quiet ----- 出力例 ----- Deleting [< サブドメイン > .cloud.run ] ... ..............done. Mappings to [< サブドメイン > .cloud.run ] now have been deleted. 前述のとおり、削除したサブドメインは即座に他のユーザーが取得できる状態になります。今後も使用する可能性があるサブドメインは、削除せずに保持してください。 参考 : gcloud beta run domain-mappings delete 別のサービスへの移動 カスタム URL のマッピング先を直接変更するコマンドはありません。カスタム URL を別のサービスへ移動するには、マッピングを削除してから、移動先のサービスを指定して同じサブドメインのマッピングを作成し直します。 # 削除したサブドメインを、移動先のサービスにマッピング $ gcloud beta run domain-mappings create \ --service = my-service-b \ --domain =< サブドメイン > .cloud.run \ --region = asia-northeast1 \ --project =< プロジェクトID > ----- 出力例 ----- Creating...... ...........done. 削除から再作成までの間は、サブドメインが解放された状態になります。第三者に取得されないよう、削除と再作成は続けて実行します。 動作確認 カスタム URL へのアクセス カスタム URL をマッピングしたサービスを、カスタム URL 経由で呼び出します。サービスは認証が必要な設定のため、実行ユーザーの ID トークンをリクエストに付与します。 # ID トークンを付けてカスタム URL を呼び出し、ステータスコードを表示 $ curl -s -o /dev/null -w ' %{http_code}\n ' \ -H " Authorization: Bearer $( gcloud auth print-identity-token ) " \ https:// < サブドメイン > .cloud.run/ ----- 出力例 ----- 200 ただし、マッピングの作成直後は 404 が返る場合があります。以下は、マッピングの作成直後から2秒間隔でカスタム URL を呼び出した結果です（時刻は UTC）。マッピングの作成が完了した時刻は 06:29:47 です。 # ID トークンを取得 $ TOKEN = $( gcloud auth print-identity-token ) # 2秒間隔でカスタム URL を呼び出し、時刻とステータスコードを表示 $ for n in $( seq 1 75 ) ; do STATUS = $( curl -s -o /dev/null -w ' %{http_code} ' \ -H " Authorization: Bearer $TOKEN " \ https:// < サブドメイン > .cloud.run/ ) echo " $( date -u +%H:%M:%S ) $STATUS " sleep 2 done ----- 出力例 ----- 06:29:49 404 06:29:51 404 06:29:53 404 06:29:55 404 06:29:57 404 06:29:59 404 06:30:02 200 06:30:04 200 06:30:06 200 06:30:08 200 06:30:10 200 06:30:12 404 06:30:14 200 06:30:16 200 06:30:19 200 06:30:21 404 06:30:23 200 06:30:25 200 06:30:27 404 06:30:29 404 06:30:31 200 // 省略 最初の 200 は作成完了の15秒後に返りましたが、その後も 200 と 404 が混在しました。最後の 404 は作成完了の111秒後で、それ以降はすべて 200 でした。 この 404 は、未使用のサブドメインにアクセスした場合と同じ応答です。マッピングの作成後は、2分程度待ってから動作を確認してください。 別のサービスへ移動した場合は、切り替えがさらに不連続になります。検証では、マッピングの削除後も約10秒間は移動前のサービスが応答しました。 再作成後の約2分間は、移動前のサービスの応答、移動先のサービスの応答、404 が混在しました。移動前のサービスの応答は、削除の約6分後にも1回観測しています。 カスタム URL の移動は、切り替えの瞬間を制御できません。移動前と移動先のどちらのサービスが応答しても問題のない状態で実施してください。 デフォルト URL の無効化 カスタム URL をマッピングしたサービスのデフォルト URL を無効化し、カスタム URL だけで呼び出せることを確認します。デフォルト URL は、 gcloud run services update コマンドの --no-default-url で無効化します。 # サービスのデフォルト URL を無効化 $ gcloud run services update my-service-a \ --no-default-url \ --region = asia-northeast1 \ --project =< プロジェクトID > ----- 出力例 ----- Updating... Done. Service [ my-service -a] has been updated. 無効化の前後で、ID トークンを付けて各 URL を呼び出した結果は以下のとおりです。 呼び出し先 無効化前 無効化後 デフォルト URL 200 404 カスタム URL 200 200 デフォルト URL を無効化した後も、カスタム URL は引き続き使用できます。デフォルト URL を元に戻すには --default-url を指定します。 参考 : Cloud Run のネットワーク上り（内向き）を制限する - デフォルトの URL を無効にする audience ごとの認証結果 認証が必要なサービス my-service-b に対して、audience の異なる ID トークンでカスタム URL を呼び出し、カスタムオーディエンスの設定による違いを確認します。 audience を指定した ID トークンは、サービスアカウントの権限借用で発行します。ユーザーアカウントの ID トークンは audience を指定できないためです。サービスアカウントには、サービスレベルで Cloud Run 起動元（ roles/run.invoker ）を付与しています。 以下は、カスタムオーディエンスを設定していない状態で、audience にカスタム URL を指定したトークンを使用した例です。 # audience を指定して ID トークンを発行 $ TOKEN = $( gcloud auth print-identity-token \ --impersonate-service-account =< サービスアカウントのメールアドレス > \ --audiences = https:// < サブドメイン > .cloud.run ) # ID トークンを付けてカスタム URL を呼び出し、ステータスコードを表示 $ curl -s -o /dev/null -w ' %{http_code}\n ' \ -H " Authorization: Bearer $TOKEN " \ https:// < サブドメイン > .cloud.run/ ----- 出力例 ----- 401 カスタムオーディエンスの設定前後で、3種類の audience で呼び出した結果は以下のとおりです。 トークンの audience カスタムオーディエンス設定なし https://<サブドメイン>.cloud.run を設定 デフォルト URL 200 200 https://<サブドメイン>.cloud.run 401 200 https://<サブドメイン>.cloud.run/ 401 401 末尾にスラッシュを付けた audience は、設定後も 401 です。カスタムオーディエンスの値と、呼び出し元が指定する audience は、末尾のスラッシュの有無まで一致させる必要があります。 audience が一致しない場合の応答は以下のとおりです。 # audience が一致しない ID トークンで呼び出した場合 $ curl -si -H " Authorization: Bearer $TOKEN " https:// < サブドメイン > .cloud.run/ ----- 出力例 ----- HTTP/ 2 401 www-authenticate: Bearer error = " invalid_token " error_description = " The access token could not be verified " // 省略 サービスを削除した場合 カスタム URL をマッピング済みのサービス my-service-d を削除し、マッピングの状態を確認します。サービスの削除後にマッピングを一覧表示すると、マッピングは残っており、先頭の記号が X に変わっています。 # サービスの削除後にマッピングを一覧表示 $ gcloud beta run domain-mappings list --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- DOMAIN SERVICE REGION // 省略 X < サブドメイン > .cloud.run my-service-d asia-northeast1 この状態でカスタム URL にアクセスすると 404 が返ります。 残ったマッピングのサブドメインを、他のサービスや他のプロジェクトから指定しても、使用中のエラーになります。サブドメインを解放するには、マッピングを明示的に削除する必要があります。 続けて、同じ名前のサービスを再度デプロイすると、残っていたマッピングは新しいサービスへルーティングされ、カスタム URL は再デプロイの直後から 200 を返しました。 サービスを削除するときは、マッピングも合わせて削除するか、保持する場合は同じ名前のサービスが意図せず公開されないよう管理してください。 佐々木 駿太 (記事一覧) クラウドソリューション部 クラウドエンジニアリング1課 北海道在住 大学院まで社会心理学を専攻し、AI に興味を持ち IT 業界へ。2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。最近は時計と007(映画)がマイブーム Follow @sasashun0805

G-gen の今村です。Google グループにおいて、メンバーが投稿したメッセージが「保留」スレッドに入り配信されない事象の原因と対処法を解説します。 事象 原因 一時的な対処法 根本的な対処法 メッセージの管理設定の変更 新しいメンバーの投稿管理設定の変更 スパムメッセージの処理設定の変更 その他の設定 保留時の管理者への通知設定 コンテンツ管理者の確認方法 特定のメンバーに対する投稿制限 事象 Google グループにおいて、メンバーがメッセージ（メールや Web 画面からの投稿）を送信した際、メッセージが即座に配信されず「保留」スレッドに入ってしまうケースがあります。 メッセージが保留に入ると、グループ管理者による手動承認が行われるまで、グループの参加メンバー宛にメッセージが配信されません。 保留中のメッセージ一覧 原因 この事象は、グループのメッセージ管理設定が原因である場合や、Google のシステムによってスパム（迷惑メール）として判定された場合に発生します。 Google グループには、メッセージがどの条件によって保留されたのかを特定するエラーログや診断機能は用意されていません。そのため、発生時はまず一時対処法で該当のメッセージを配信し、その後に根本対処法に記載されている各設定項目を順に確認・見直す必要があります。 ・参考 : グループ宛ての正当なメールが迷惑メールに分類される 一時的な対処法 保留されたメッセージをすぐに配信したい場合は、グループ管理者が Web コンソールから手動で承認します。 対象のグループの [スレッド] から [保留] を開きます。 該当のメッセージを確認し、[承認] または [拒否] を選択します。 メッセージの承認または拒否 処理対象のメッセージが複数ある場合は、チェックボックスで選択して一括で承認または拒否を行うこともできます。 メッセージをまとめて承認または拒否 根本的な対処法 メッセージの管理設定の変更 グループの設定で、メンバーの投稿が管理者の承認を必要とする状態になっているケースです。この設定を「管理しない」に変更することで、承認なしでメッセージが配信されるようになります。 左側のメニューから [グループ設定] をクリックします。 [メッセージの管理] の項目で、[管理しない] を選択します。 対象のグループを選択 [メッセージの管理] > [管理しない] を選択 この設定により、通常の投稿は管理者の承認を経ずに配信されます。なお、この設定はグループごとに個別に行う必要があります。 参考 : 新しいメッセージを承認またはブロックする 新しいメンバーの投稿管理設定の変更 新しくグループに参加したメンバーの投稿が、自動的に保留される設定になっているケースです。 新しいメンバーからの投稿の安全性が確認できている場合 は、この制限を解除します。 対象のグループの [グループ設定] を開きます。 [新しいメンバーの制限] の項目で、[新しいメンバーの投稿制限なし] を選択します。 [新しいメンバーの制限] > [新しいメンバーの投稿制限なし] を選択 これにより、新しく入ったメンバーからのメッセージも、管理者の承認を待たずにグループへ配信されます。 なお、Google グループにおける「新しいメンバー」には、「追加されてから〇日以内」といった具体的な数値の定義はありません。公式ドキュメントには「グループ内で一度もメッセージを投稿していないメンバー」と記載されています。該当メンバーの初回投稿時に制限が適用される仕様です。 参考 : グループを作成し、グループ設定を選択する - 投稿ポリシー スパムメッセージの処理設定の変更 「メッセージの管理」などを「管理しない」に設定していても、メッセージの内容や送信元によって Google のシステムにスパムと判定されると、投稿が保留に入ります。 参加しているメンバーや送信元の安全性が確認できている場合は、スパム処理設定の緩和を検討します。ただし、設定を緩和するとフィッシング詐欺や関係者を装ったなりすましメールなどが届くリスクが高まります。これらのリスクを十分に理解したうえで、慎重に設定してください。 対象のグループの [グループ設定] を開きます。 [スパムメッセージの処理] の項目で、[グループ宛の疑わしいメッセージの投稿を許可] を選択します。 [スパムメッセージの処理] > [グループ宛の疑わしいメッセージの投稿を許可] を選択 これにより、スパムの疑いがあると判定されたメッセージであっても保留されず、グループに配信されます。 ・参考 : グループ宛ての正当なメールが迷惑メールに分類される - グループの迷惑メールの設定を調整する その他の設定 保留時の管理者への通知設定 スパム判定等によってメッセージが保留された際、管理者に通知メールを送信するように設定できます。 対象のグループの [グループ設定] を開きます。 [スパムメッセージの処理] の項目で、[管理してコンテンツ管理者に通知] を選択します。 [スパムメッセージの処理] > [管理してコンテンツ管理者に通知] を選択 この設定を行うと、メッセージが保留されたタイミングでコンテンツ管理者宛に通知が送信されます。 コンテンツ管理者の確認方法 コンテンツ管理者とは、Google グループ内でメッセージの管理権限を持つ役割を指します。デフォルトでは、グループの「オーナー」および「マネージャー」にこの権限が割り当てられています。 コンテンツ管理者が誰であるかを確認、または権限を変更するには、以下の手順を実施します。 対象のグループの [メンバー] を開きます。 [オーナー] または [マネージャー] の役割が割り当てられているユーザーを確認します。 コンテンツ管理者を確認 保留時の通知メールは、ここで確認できるユーザーのアドレス宛に届きます。 参考 : 閲覧、投稿、管理できるユーザーを設定する 特定のメンバーに対する投稿制限 特定のメンバーからの投稿のみを個別に保留・ブロックしたい場合は、メンバーごとの投稿権限を設定できます。 対象のグループの [メンバー] を開きます。 対象となるメンバーの [投稿] 列の設定を変更します。 投稿を制限する場合は、[不承認] または [管理対象] を選択します。 特定のメンバーに対する投稿制限 今村 壱生 (記事一覧) クラウドソリューション部 ソリューションアーキテクト課 2026年3月にG-genへ入社。約7年間 Web 広告運用やウェブ解析に携わり、その後は社内 SE として開発業務に従事。広告運用の現場感と技術的な視点、その双方を併せ持つ経験をベースに、現在は Google Cloud のスキルアップに注力。データ活用とクラウド技術を融合させ、お客様のビジネス成長を支えるエンジニアを目指している。 Follow

はじめに 最近、AIエージェントやコーディングアシスタントの界隈で「Skill（スキル）」という言葉をよく見かけるようになりました。 「サブエージェント（Subagents）と何が違うの？」 「どうやって書けばAIがうまく使ってくれるの？」 そんな方に向けて、この記事では Google 公式の Agent-CLI で実際に使われている Skill のコードを見ながら、その仕組みと書き方のテクニックをわかりやすく解説します。 1. 最近よく聞く「Skill（スキル）」って結局なに？ なぜ「サブエージェント」を増やすだけでは限界があるのか？ AIに高度な作業をさせたいとき、これ