pubsub-basics

GCP Pub/Sub の基本

このスキルでは、gcloud CLI から Google Cloud Pub/Sub を運用するための、安全で再現性のあるガイダンスを提供します。中核となるメッセージングの概念、リソースを操作するために必要な IAM ロール、トピックとサブスクリプションを作成するための手順を追ったレシピ、破壊的または曖昧な操作を防ぐ運用上のガードレールを解説します。イベント駆動型システム、ストリーミングパイプライン、非同期サービス連携向けに Pub/Sub インフラストラクチャを構築、確認、運用するときは、必ずこのガイダンスに従ってください。

概要

Google Cloud Pub/Sub は、メッセージのプロデューサーとコンシューマーを分離する、フルマネージドの非同期メッセージングサービスです。プロデューサーは誰がメッセージを消費するかを知らずにメッセージをパブリッシュし、コンシューマーは誰がメッセージを生成したかを知らずにメッセージを受け取ります。この分離により、回復力が高く、水平方向にスケーラブルなイベント駆動型アーキテクチャを実現できます。

中核となる概念

• トピック — プロデューサー（パブリッシャー）がメッセージを送信する、名前付きのリソースです。トピックは、システムに流入するデータの入口です。トピックでは、受信メッセージに対してスキーマを任意で適用できます。

• サブスクリプション — 単一のトピックからサブスクライブするアプリケーションに配信されるメッセージストリームを表す、名前付きのリソースです。各サブスクリプションは、作成後にトピックへパブリッシュされた各メッセージの独立したコピーを受け取ります。1 つのトピックに複数のサブスクリプションを設定できます。これがファンアウトの仕組みです。

• プル配信 — サブスクライバーアプリケーションが独自のスケジュールで（クライアントライブラリ、CLI、ストリーミングプル接続を使用して）サブスクリプションからメッセージを明示的に要求します。プルは、高スループットのバッチコンシューマーや、自身の同時実行数を制御するワーカーに適しています。メッセージの処理に成功した後、明示的に確認応答（ack）を返す必要があります。

• プッシュ配信 — Pub/Sub は、構成済みのエンドポイント（Cloud Run サービス、Cloud Functions 関数、または一般公開されている任意の HTTPS URL など）に HTTPS POST リクエストを送信して、各メッセージを積極的に配信します。エンドポイントは、成功を示す HTTP ステータス（102、200、201、202、204）を返してメッセージを確認応答します。プッシュは、サーバーレスコンシューマーや Webhook 形式の連携に適しています。

• 確認応答（ack）と ack 期限 — コンシューマーは、処理が成功したことを示すためにメッセージを確認応答する必要があります。サブスクリプションのack 期限内にメッセージが ack されない場合、Pub/Sub はそのメッセージを再配信します。この少なくとも 1 回の配信モデルでは、コンシューマーを冪等になるように設計する必要があります。

• デッドレタートピック（DLT） — サブスクリプションが、設定された最大回数（--max-delivery-attempts）を超えて配信に失敗したメッセージの転送先となるトピックです。デッドレタリングにより「ポイズン」メッセージを分離できるため、正常なトラフィックを妨げず、後から調査または再処理できます。Pub/Sub サービスアカウントには、デッドレタートピックへのパブリッシュと、ソースサブスクリプションへのサブスクライブの権限が必要です。

• スキーマ — トピックにパブリッシュされるメッセージの構造を制約する、任意のバージョン管理された定義（Avro または Protocol Buffer）です。トピックにスキーマとエンコーディング（JSON または BINARY）が関連付けられている場合、Pub/Sub はパブリッシュされたすべてのメッセージを検証し、準拠しないペイロードを拒否します。スキーマによってプロデューサーとコンシューマー間の契約が確立され、形式が不正なデータがパイプラインに入るのを防げます。

前提条件

操作を行う前に、以下の条件が整っていることを確認してください。

1. Pub/Sub API を有効にします。 対象プロジェクトで pubsub.googleapis.com サービスが 有効になっている必要があります。

   gcloud services enable pubsub.googleapis.com --project=PROJECT_ID
   

2. gcloud CLI をインストールして更新します。 このスキルの操作では、 最新の Google Cloud CLI を使用することを前提としています。インストール済みで、最新の状態であることを確認してください。

   gcloud version
   gcloud components update --quiet
   

3. CLI を認証します。 以下で説明する必要なロールを持つ ID（ユーザーまたはサービス アカウント）で認証します。

   gcloud auth login
   gcloud config set project PROJECT_ID
   

   自動化環境または非対話型環境では、専用のサービスアカウントに紐付いた アプリケーションのデフォルト認証情報を使用してください。

   gcloud auth activate-service-account --key-file=KEY_FILE_PATH
   

4. アクティブなプロジェクトとアカウントを確認します。 リソースを変更する前に、必ず実行 コンテキストを確認してください。

   gcloud config list --format="value(core.project,core.account)"
   

主な IAM ロール

タスクに必要な最小限の権限を付与してください。このスキルを通じて操作するプリンシパルには、担当する作業に合致するロールのみを付与してください。

ロール	ロール ID	目的
Pub/Sub Admin	roles/pubsub.admin	フルコントロール：トピック、サブスクリプション、スキーマの作成、更新、削除、および IAM ポリシーの管理を行います。プロビジョニング用の ID に限定してください。
Pub/Sub Publisher	roles/pubsub.publisher	トピックにメッセージをパブリッシュします。プロデューサーサービスに付与してください。
Pub/Sub Subscriber	roles/pubsub.subscriber	サブスクリプションからメッセージを取得し、確認します。コンシューマーサービスに付与してください。
Pub/Sub Viewer	roles/pubsub.viewer	トピック、サブスクリプション、スキーマ、設定を表示する読み取り専用アクセス権です。調査や監査用に付与してください。
Service Account User	roles/iam.serviceAccountUser	ID がサービスアカウントとして操作（偽装）できるようにします。サービスアカウント ID トークンを使ってサービスを呼び出す、認証済みプッシュサブスクリプションを設定する場合に必要です。

追加の注意事項：

• プライベートサービス（認証が必要な Cloud Run エンドポイントなど）を呼び出すプッシュサブスクリプションでは、プッシュ用のサービスアカウントに対象サービスの呼び出し元ロール（roles/run.invoker など）を付与する必要があります。また、設定する ID には、そのサービスアカウントに対する roles/iam.serviceAccountUser も必要です。
• デッドレター配信では、Pub/Sub サービスエージェント（[email protected]）に、デッドレタートピックでの roles/pubsub.publisher と、ソースサブスクリプションでの roles/pubsub.subscriber を付与する必要があります。

複合リソースのデプロイ手順

新しいスキーマに紐付いたトピックとサブスクリプションをまとめてプロビジョニングする場合は、この複合手順を使用してください。依存リソース（スキーマ -> トピック -> サブスクリプション）の設定、検証、作成を 1 つの実行ブロックで順に行い、シェルの実行回数を最小限に抑え、設定が不完全な状態で作成されることを防ぎます。

# Run as a single copy-pasteable execution block
(
  set -e

  # 1. Configuration Parameters
  PROJECT_ID="PROJECT_ID"
  SCHEMA_ID="SCHEMA_ID"
  SCHEMA_TYPE="avro"                 # avro or protocol-buffer
  SCHEMA_FILE="PATH_TO_SCHEMA_FILE"   # Local path to schema definition file
  ENCODING="json"                    # json or binary
  TOPIC_ID="TOPIC_ID"
  SUBSCRIPTION_ID="SUBSCRIPTION_ID"
  ACK_DEADLINE=60                    # Acknowledgement deadline in seconds

  echo "=== [1/5] Validating Schema Definition ==="
  gcloud pubsub schemas validate-schema \
    --type="${SCHEMA_TYPE}" \
    --definition-file="${SCHEMA_FILE}" \
    --project="${PROJECT_ID}"

  echo "=== [2/5] Creating Schema ==="
  gcloud pubsub schemas create "${SCHEMA_ID}" \
    --type="${SCHEMA_TYPE}" \
    --definition-file="${SCHEMA_FILE}" \
    --project="${PROJECT_ID}" \
    --quiet

  echo "=== [3/5] Creating Topic ==="
  gcloud pubsub topics create "${TOPIC_ID}" \
    --schema="${SCHEMA_ID}" \
    --message-encoding="${ENCODING}" \
    --project="${PROJECT_ID}" \
    --quiet

  echo "=== [4/5] Creating Subscription ==="
  gcloud pubsub subscriptions create "${SUBSCRIPTION_ID}" \
    --topic="${TOPIC_ID}" \
    --ack-deadline="${ACK_DEADLINE}" \
    --project="${PROJECT_ID}" \
    --quiet

  echo "=== [5/5] Verifying Resources ==="
  gcloud pubsub schemas describe "${SCHEMA_ID}" --project="${PROJECT_ID}"
  gcloud pubsub topics describe "${TOPIC_ID}" --project="${PROJECT_ID}"
  gcloud pubsub subscriptions describe "${SUBSCRIPTION_ID}" --project="${PROJECT_ID}"
)

スキーマの適用：「JSON」はメッセージのエンコーディングであり、スキーマの種類ではありません

これはほとんどのユーザーがつまずく点です。Google Cloud Pub/Sub にはスキーマの種類が 2 つあります。 AVRO と PROTOCOL_BUFFER です。JSON というスキーマの種類はなく、 gcloud pubsub schemas create --type=json は失敗します。

タスクで「JSON スキーマ」や「厳密な JSON 検証」が求められている場合、これは トピックが、関連付けられたスキーマに照らして JSON エンコーディングのメッセージを検証することを意味します。JSON はトピックに設定する --message-encoding であり、スキーマの種類ではありません。 スキーマ定義自体は通常 AVRO で記述します。

そのため、「厳密な JSON スキーマ」という要件は、次の 2 つに分かれます。

1. トピックに関連付けられたスキーマ（データコントラクト）。
2. トピックの schemaSettings.encoding が JSON に設定されていること（メッセージが JSON として検証されます）。

正しい設定例

SCHEMA="orders-schema"
TOPIC="orders-topic"

# 1. Create the schema. Type is AVRO; the definition is written in Avro JSON.
gcloud pubsub schemas create "$SCHEMA" \
  --type=AVRO \
  --definition='{"type":"record","name":"Order","fields":[
    {"name":"id","type":"string"},
    {"name":"amount","type":"double"}
  ]}'

# 2. Create the topic and bind the schema with JSON MESSAGE ENCODING.
#    --message-encoding=json is the part that makes it a "JSON schema".
gcloud pubsub topics create "$TOPIC" \
  --schema="$SCHEMA" \
  --message-encoding=json

# 3. Verify the contract: encoding must be JSON.
gcloud pubsub topics describe "$TOPIC" --format="value(schemaSettings.encoding)"   # -> JSON

トピックがすでに存在する場合は、次のコマンドでスキーマとエンコーディングを設定します。 gcloud pubsub topics update "$TOPIC" --schema="$SCHEMA" --message-encoding=json。

タスクでバイナリ形式が明示的に求められていない限り、JSON エンコーディングをデフォルトにしてください。 要件で指定されている場合に限り、 --message-encoding=binaryを使用してください。バイナリを選択する（またはエンコーディングを省略する）と、「JSON スキーマ」の 要件を満たしていないと判定されることがよくあります。スキーマは設定されているように見えても、 メッセージが JSON として検証されないためです。

トラブルシューティング

• 「スキーマは AVRO ですが、JSON が必要です」： これは種類の混同です。AVRO はスキーマの型で、JSON はメッセージエンコーディングです。AVRO スキーマを維持したまま、トピックの --message-encoding=jsonを設定してください。スキーマの型を変更しようとしないでください。
• エンコーディングが空欄／BINARY と表示される： トピックが--message-encoding=json（または--schema）を指定せずに作成されています。次のコマンドで再設定してください。 gcloud pubsub topics update --schema=... --message-encoding=json。

デッドレタートピック：ポリシーはメッセージを受信するサブスクリプションに設定します

デッドレターポリシーは、メイントピックからメッセージを取得するサブスクリプションに設定します。デッドレタートピックや、デッドレタートピックのサブスクリプションに設定するものではありません。ここで発生する失敗のほとんどは、ポリシーを誤ったサブスクリプションに設定することと、--max-delivery-attemptsを忘れることが原因です。

N 回配信に失敗した後にデッドレターに送るには：

DLQ_TOPIC="orders-dlq"
SUB="orders-sub"          # the subscription that consumes the MAIN topic
PROJECT="$(gcloud config get-value project)"

# 1. Create the dead-letter topic.
gcloud pubsub topics create "$DLQ_TOPIC" --project="$PROJECT"

# 2. Attach the dead-letter policy to the CONSUMING subscription.
#    --max-delivery-attempts is required; without it there is no dead-lettering.
gcloud pubsub subscriptions update "$SUB" \
  --project="$PROJECT" \
  --dead-letter-topic="$DLQ_TOPIC" \
  --max-delivery-attempts=5

# 3. Verify the policy is on the right subscription.
gcloud pubsub subscriptions describe "$SUB" \
  --project="$PROJECT" \
  --format="value(deadLetterPolicy.deadLetterTopic, deadLetterPolicy.maxDeliveryAttempts)"

Pub/Sub サービスエージェントに IAM 権限を付与してください。付与しないと、デッドレターへの転送は通知なく失敗します。
サービスエージェントservice-<project-number>@gcp-sa-pubsub.iam.gserviceaccount.comには、デッドレタートピックでroles/pubsub.publisherを、サブスクリプションで roles/pubsub.subscriberを付与する必要があります。これらの権限がないと、ポリシーが正しく設定されているように見えても、メッセージは DLQ に転送されません。

よくある間違い

• ポリシーを誤ったサブスクリプションに設定する。 ソーストピックからメッセージを受信するサブスクリプションに設定する必要があります。デッドレタートピックのサブスクリプションにデッドレターポリシーを設定しても、役に立ちません。
• --max-delivery-attemptsを省略する。 有効範囲は 5～100 です。タスクで「正確に N 回の試行」が求められている場合は、その N を明示的に指定してください。

トピックとサブスクリプションの作成

以下のコマンドでは、大文字のプレースホルダーを使用しています。実行前に、TOPIC_ID、 SUBSCRIPTION_ID、PROJECT_ID、ENDPOINTなどを具体的な値に置き換えてください。すべてのコマンドで--project=PROJECT_IDを明示してプロジェクトを指定し、 --quietを使って対話形式ではなく実行します。

1. トピックを作成する

gcloud pubsub topics create TOPIC_ID \
  --project=PROJECT_ID \
  --quiet

メッセージの保持期間を適用するトピック（サブスクリプションからもその期間内に再生できるトピック）を作成するには：

gcloud pubsub topics create TOPIC_ID \
  --message-retention-duration=7d \
  --project=PROJECT_ID \
  --quiet

既存のスキーマをトピックに関連付けるには：

gcloud pubsub topics create TOPIC_ID \
  --schema=SCHEMA_ID \
  --message-encoding=json \
  --project=PROJECT_ID \
  --quiet

2. Pull サブスクリプションを作成する

Pull サブスクリプションでは、コンシューマーが必要に応じてメッセージを取得できます。 --ack-deadlineは、再配信される前にコンシューマーがメッセージを確認するまでの時間を制御します。

gcloud pubsub subscriptions create SUBSCRIPTION_ID \
  --topic=TOPIC_ID \
  --ack-deadline=60 \
  --project=PROJECT_ID \
  --quiet

デッドレタートピックを関連付けて、再配信の試行回数を制限するには：

gcloud pubsub subscriptions create SUBSCRIPTION_ID \
  --topic=TOPIC_ID \
  --ack-deadline=60 \
  --dead-letter-topic=DEAD_LETTER_TOPIC_ID \
  --max-delivery-attempts=5 \
  --project=PROJECT_ID \
  --quiet

サーバー側のメッセージ属性フィルターを使って、このサブスクリプションが受信するメッセージを制限するには（以下の「データ削減」を参照）：

gcloud pubsub subscriptions create SUBSCRIPTION_ID \
  --topic=TOPIC_ID \
  --message-filter='attributes.eventType = "ORDER_CREATED"' \
  --project=PROJECT_ID \
  --quiet

3. Push サブスクリプションを作成する

Push サブスクリプションは、各メッセージを HTTPS のENDPOINTに配信します。メッセージを確認するには、エンドポイントが成功ステータスを返す必要があります。

gcloud pubsub subscriptions create SUBSCRIPTION_ID \
  --topic=TOPIC_ID \
  --push-endpoint=ENDPOINT \
  --ack-deadline=60 \
  --project=PROJECT_ID \
  --quiet

非公開サービスを対象とする認証済み Push サブスクリプションでは、Pub/Sub が署名付き OIDC トークンを送信するように、Push 認証用サービスアカウントを関連付けます。

gcloud pubsub subscriptions create SUBSCRIPTION_ID \
  --topic=TOPIC_ID \
  --push-endpoint=ENDPOINT \
  --push-auth-service-account=PUSH_SERVICE_ACCOUNT_EMAIL \
  --ack-deadline=60 \
  --project=PROJECT_ID \
  --quiet

4. 作成したリソースを確認する

作成後、設定に依存する前に、その内容を確認してください。

gcloud pubsub topics describe TOPIC_ID \
  --project=PROJECT_ID

gcloud pubsub subscriptions describe SUBSCRIPTION_ID \
  --project=PROJECT_ID

リソースの命名と確認チェックリスト

Pub/Sub のプロビジョニングタスクを完了する前に、次のチェックリストを確認し、すべてのリソースが想定どおりであることを確かめてください。

• リソース名が要件と一致することを確認する：プロンプトまたは仕様に記載された Schema、Topic、Subscription の正確な名前を照合してください。名前を推測しないでください。
• ラベルが適用されていることを確認する：プロンプトでラベル（windtunnel-eval など）が要求されている場合、Topic と Subscription の両方に適用されていることを確認してください。
• リソースの存在を確認する：Schema、Topic、Subscription に対して describe コマンドを実行し、出力に state: ACTIVE（Schema の場合）と正しい設定が表示されることを確認してください。

基本原則

これらの原則は必須です。すべての Pub/Sub 操作に適用してください。

コマンドの明示的な検証（必須）

• 変更を伴うコマンドを実行する前に、そのコマンドが何をどのリソースに対して行うのかを平易な言葉で言い直してください。リソース名、プロジェクト、および影響を確認してください。
• サブコマンドが対応している場合は --dry-run を使用するか、まず読み取り専用の describe／list 相当のコマンドを実行して現在の状態を確認してください。
• 影響を正確に予測できないコマンドは決して実行しないでください。結果が曖昧な場合は、いったん停止してから検証してください。

データの削減

取得、処理、返却するデータ量を最小限に抑えてください。フィルタリングされていない大量の読み取りは、時間がかかり、コストが高く、ノイズも多くなります。

• --limit — 一覧表示または取得時の結果数に上限を設定します。たとえば、gcloud pubsub subscriptions pull SUBSCRIPTION_ID --limit=10 のように指定します。
• サーバー側フィルタリング — 不要なメッセージを後から除外するのではなく、Subscription の作成時に --message-filter を適用し、不要なメッセージが配信されないようにしてください。対応している場合は、list コマンドで --filter を使用して、サーバー側で結果を絞り込んでください。
• フィールドの絞り込み — リソースの完全な表現を出力するのではなく、--format="value(...)" または --format="table(...)" を使用して、必要なフィールドのみを要求してください。

プロジェクトとロケーションの指定

• すべてのコマンドに必ず --project=PROJECT_ID を追加してください。現在の gcloud config プロジェクトだけに頼らないでください。明示的に指定することで、誤ったプロジェクトに対する操作を防げます。
• ロケーションまたはリージョナルエンドポイントに対応するリソースでは、デフォルトに依存せず、ロケーションを明示的に指定してください。

実行上の制約

• 非対話モード — 対話型プロンプトを抑制してコマンドを予測可能かつ自動化に安全なものにするため、--quiet（または -q）を追加してください。ただし、以下の「安全性」セクションに記載されている人間による承認要件を回避するために使用してはいけません。
• 単一コマンド — 個別の gcloud コマンドを一度に1つずつ実行してください。関連のない操作を1回の呼び出しにまとめないでください。
• シェル演算子を使用しない — Pub/Sub コマンドを組み合わせるために、シェルのパイプ（|）、リダイレクト（>、>>）、コマンド置換（$(...)）、バックグラウンド演算子（&）、または &&／; による連結を使用しないでください。各コマンドは単独で実行し、個別に監査できるようにしてください。

安全性とガードレール

注意

Pub/Sub の操作は破壊的で、取り消せない場合があります。Topic または Subscription を削除すると、未配信のメッセージが完全に破棄され、それに紐づくすべてのプロデューサーとコンシューマーに支障が生じます。IAM ポリシーを変更すると、本番サービスからのアクセスが気付かないうちに遮断される場合があります。明示的に問題がないと証明されていない限り、変更を伴うすべての操作は本番環境に影響するものとして扱ってください。

禁止されている操作（拒否リスト）

次の操作は、明示的な承認を記録して得ることなく実行してはなりません。タスクでこれらの操作が必要と思われる場合は、まず作業を止め、承認を求めてください。正確なコマンドと影響範囲を説明してください。

• トピックの削除 — gcloud pubsub topics delete ...。トピックが破棄され、すべてのサブスクリプションが切り離されます。
• サブスクリプションの削除 — gcloud pubsub subscriptions delete ...。そのサブスクリプションが保持している未確認メッセージがすべて恒久的に破棄されます。
• スキーマの削除または変更 — gcloud pubsub schemas delete ...、または処理中のプロデューサーを無効にする可能性があるスキーマのリビジョン変更。
• 破壊的な方法でのメッセージの消去／シーク — 現在のバックログを破棄するタイムスタンプまたはスナップショットを指定した gcloud pubsub subscriptions seek ...。
• 重要な IAM バインディングの変更 — 本番環境のトピックまたはサブスクリプションに対する roles/pubsub.admin、roles/pubsub.publisher、roles/pubsub.subscriber バインディングの追加、削除、置換、またはポリシー全体を置き換える set-iam-policy 操作。
• トピックの切り離し — gcloud pubsub topics detach-subscription ...。対象のサブスクリプションへの配信が直ちに停止します。

常に安全な操作

読み取り専用の確認コマンド（describe、list、診断のための自動確認なしの件数制限付き pull）は、上記のデータ削減の原則に従う限り、安全であり、検証に推奨されます。

トラブルシューティング／問題が発生した場合の対処方法

...権限エラー（PERMISSION_DENIED / 403）でコマンドが失敗する場合

1. アクティブな ID を確認します：gcloud config list --format="value(core.account)"。
2. リソースに設定されたロールが操作に合っていることを確認します（IAM テーブルを参照）。たとえば、パブリッシュには roles/pubsub.publisher、メッセージの受信には roles/pubsub.subscriber が必要です。
3. プライベートエンドポイントへのプッシュでは、プッシュサービスアカウントに対象サービスの呼び出し元ロールが付与されていること、および設定を行う ID にそのサービスアカウントの roles/iam.serviceAccountUser が付与されていることを確認します。
4. API が有効になっていることを確認します：gcloud services list --enabled --filter="pubsub" --project=PROJECT_ID。

...サブスクリプションのバックログが増加している場合（メッセージの消費が追いついていない）

1. Cloud Monitoring のメトリクス（subscription/num_undelivered_messages、subscription/oldest_unacked_message_age）で、バックログと未確認メッセージの最古の経過時間を確認します。
2. プルコンシューマーの場合は、コンシューマーインスタンスの数を増やすか、インスタンスあたりの並行処理数を増やし、合計スループットがパブリッシュレートを上回るようにします。
3. コンシューマーがメッセージを正常に確認していることを確認します。処理に失敗すると再配信が発生し、バックログが膨らみます。
4. --message-filter で配信量を減らすべきか、トピックが過剰にファンアウトされていないかを検討します。

...メッセージが未確認のまま蓄積する場合（再配信が繰り返される）

1. 正常に処理された後、コンシューマーが確認を呼び出していることを確認します。
2. --ack-deadline を確認します。処理に通常この期限を超える時間がかかる場合は、期限を延長するか、プログラムで期限を延長します。そうしないと、コンシューマーが処理を終える前に Pub/Sub がメッセージを再配信します。
3. コンシューマーがべき等であることを確認します。少なくとも 1 回の配信が保証されるため、重複が発生する可能性があり、べき等でないハンドラーでは問題が悪化します。
4. 特定の「ポイズン」メッセージの処理が繰り返し失敗する場合は、--max-delivery-attempts を指定して デッドレタートピック を関連付け、無限に再配信されるのではなく、個別に隔離されるようにします。

...スキーマの検証に失敗する（公開したメッセージが拒否される）

1. トピックにバインドされたスキーマとエンコーディングを確認します。 gcloud pubsub topics describe TOPIC_ID --project=PROJECT_ID。
2. 公開する前に、サンプルメッセージをスキーマに照らして検証します。 gcloud pubsub schemas validate-message ...。
3. プロデューサーがトピックの想定するエンコーディング（JSON と BINARY のどちらか）でシリアライズしていることを確認します。構造的に有効なデータでも、エンコーディングが一致しないと拒否されます。
4. スキーマを変更する必要が正当にある場合は、プロデューサーを場当たり的に編集するのではなく、互換性のある新しいスキーマリビジョンをコミットします。また、スキーマの削除は承認が必要な禁止操作として扱います。

リファレンスディレクトリ

タスクに応じた詳細については、以下のリファレンスドキュメントを参照してください。

• references/cli-usage.md — gcloud pubsub コマンドの包括的なリファレンスです。公開、プル、確認応答、シーク、スナップショット、出力形式のレシピを含みます。
• references/iam-security.md — IAM のロールとポリシー、最小権限のパターン、プッシュ配信用のサービスアカウント設定、デッドレターの権限設定に関する詳細なガイダンスです。
• references/client-libraries.md — プログラムからの公開とメッセージの受信に使える Google Cloud 公式クライアントライブラリへのリンクと、CLI より SDK のコードを優先すべき場合についての説明です。