チェックサムは、データから計算する検査値です。送信側と受信側が値を照合し、転送中の偶発的な破損を検出します。公式データ検証仕様

受信後にサーバだけで計算する方式では、クライアントの元データからサーバの計算開始までに内容が変わっても、検出できない場合があります。ここでは、対応クライアントが転送前に計算したチェックサムを送る場合を考えます。サーバは、その値と受信データから計算した値を比べ、クライアントからサーバへの転送中に生じた不一致を検出できます。公式データ検証仕様

対応する版のSDK（ソフトウェア開発キット）は、書き込み時のチェックサムを既定で計算します。書き込み時のチェックサム計算には、Go SDK 1.60.0以降とPython SDK 3.7.0以降が対応しています。公式対応表

各クライアントの版は「書き込みのチェックサム既定計算に対応するクライアント版」の表にまとめました。利用者は、読み取り時の自動検証条件を、利用する版の公式リファレンスで確認してください。

Cloud Storageに保存するデータ単位をオブジェクトと呼びます。

書き込みのチェックサム既定計算に対応するクライアント版

以下は公式データ検証仕様の対応表を2026年10月2日に確認したものです。対象は、object writes（オブジェクト書き込み操作）でのチェックサムの既定計算です。

ダウンロードの自動検証やgRPC（遠隔手続き呼び出しに使う通信方式）に対応する版を保証する表ではありません。

クライアント書き込みの既定計算に対応する版
C++2.46以降
Go1.60.0以降
Java2.62以降
Node.js7.19.0以降
PHP1.51.0以降
Python3.7.0以降
Ruby1.60.0（公式表の記載）
.NET2.3.0以降。サーバ側検証には4.15.0を推奨
Cloud Storage FUSE（Cloud Storageをファイルシステムとして扱うツール）3.8.0以降
Cloud Storage connector（Hadoop/Spark向け）3.0系は3.0.18以降、3.1系は3.1.14以降、4.0系は4.0.3以降

通常のHTTP Range（指定したバイト範囲だけを取得する要求）は、取得した部分データをオブジェクト全体のチェックサムと照合できません。gRPC範囲読み取りでは、応答チャンク（データを分割した単位）ごとのCRC32C（偶発的な破損を検出するチェックサム方式）で検証します。操作条件は後述します。公式データ検証仕様[8]

公式ブログは、最新SDKで転送前のチェックサムを既定で計算し、サーバへ渡すと説明しています。同ブログは、ダウンロードとgRPC範囲読み取り（一部のバイト範囲だけを取得する操作）の検証も案内しています。公式ブログ

一方、公式データ検証仕様には、ダウンロード時に自動検証しないライブラリもあるという注意があります。その箇所には対象ライブラリ・版の一覧がありません。利用者は、使う版の公式リファレンスで、読み取り時の検証条件と範囲指定時の制約を確認してください。

利用者は、その他のSDKについても、公式対応表のクライアント別リンクから利用する版のリファレンスを確認してください。

利用者は、更新前後に次の点を確認してください。

  • プロジェクトで実際に使うライブラリと版を、書き込み対応表に照合してください。
  • 実際に使う操作を確認してください。全体読み取りは、オブジェクト全体の取得です。範囲読み取りは、指定したバイト範囲だけの取得です。圧縮展開は、圧縮データを展開して返す処理です。検証対象のバイト列も確認してください。
  • 転送経路と、検証を明示的に無効にする設定の有無を確認してください。

利用者は、gRPCに対応するクライアントを接続案内で別に確認します。同案内はC++・Go・Javaのライブラリなどを挙げています。

たとえばGo向け案内には、1.46.0以降でNewGRPCClientを使う手順があります。書き込みの既定計算に対応する1.60.0以降とは別の条件です。認証や実行環境も同案内で確認してください。

チェックサムが埋める転送の穴

保存後のダウンロードでも、クライアントが受信したバイト列からチェックサムを計算し、保存時の値と照合できます。冗長保存は障害に備える仕組み、暗号化は内容の機密性を守る処理、チェックサムはデータの一致確認を担います。公式データ検証仕様

Googleの公式ブログは、暗号化に伴うデータのコピーでも検証を引き継ぐと説明しています。Cloud Storageは、暗号化後のチェックサムを計算し、復号（暗号化されたデータを元に戻す処理）した平文（暗号化前のデータ）を元のデータと比較します。Cloud Storageは、不一致を検出した場合、対象データを破棄して処理をやり直します。

後輩保存先で無事に保管できていることと、届いた内容が元と同じことは別の確認なんですね。

先輩そうだね。チェックサム値を比べて、転送中の偶発的な破損を検出するんだよ。

後輩では、保存の冗長性や暗号化だけでは、転送経路の確認を置き換えられないんでしょうか。

先輩役割が異なるため、転送の前後で値を比べる工程が必要だね。

操作ごとに異なる検証範囲

CRC32Cは、データの偶発的な破損を検出するチェックサム方式です。

Googleの複合オブジェクト仕様は、内容を書き換えても検証値が一致する攻撃への保護をCRC32Cの目的としていません。検証値の一致だけで、データの完全な同一性は保証できません。

公式データ検証仕様はCRC32Cを推奨しています。メタデータ仕様では、CRC32（別のチェックサム方式）とCRC32Cを区別しています。

MD5もデータから比較用のハッシュ値を計算する方式です。メタデータは、オブジェクトに付随する情報です。

APIは、ソフトウェアが他のソフトウェアの機能を呼び出すための窓口です。XML APIは、Cloud Storageを操作する通信仕様の一つです。multipartは、データを複数部分に分けて送る方式です。

複合オブジェクト（複数のオブジェクトを合成したもの）には、MD5値を示すメタデータがありません。XML APIのmultipart方式で作成したオブジェクトにも、MD5メタデータはありません。メタデータ仕様

HTTP Range（指定範囲の取得）は、指定したバイト範囲だけを取得する要求です。gRPCは、遠隔のサービスの機能を呼び出す通信方式です。応答を順に送るストリームでは、チャンク（データを分割した単位）ごとに検証できます。公式データ検証仕様

アップロード時のサーバ検証

サーバは、クライアントが送ったチェックサムと、受信データから計算した値を比べます。不一致の場合、サーバはHTTP 400（エラー応答コード）で書き込みを拒否します。公式データ検証仕様[6]

アップロード後のクライアント検証

クライアント側で検証する場合、利用者は保存後のメタデータと期待値を比べてください。運用者は、不一致のオブジェクトを削除してください。転送開始時に期待値が不明でも、この方式は利用できます。公式データ検証仕様

全体ダウンロード

利用者は、全体ダウンロードを検証する際、受信データから計算したチェックサムを保存時の値と比べてください。利用者は、使うライブラリの自動検証の有無を確認してください。公式データ検証仕様

HTTP Rangeによる部分取得

クライアントは、指定したバイト範囲だけを取得します。その部分データを、オブジェクト全体のチェックサムと直接照合することはできません。全体取得を再開した場合は、完了後に全体の値を照合できます。公式データ検証仕様

gRPC範囲読み取り

gRPCでは、応答チャンクごとにCRC32Cが付与されます。対応クライアントは、その値と受信チャンクから計算した値を比べて検証できます。オブジェクト全体の値では、取得した部分範囲を検証できません。公式データ検証仕様[8]

圧縮を展開して返す読み取り

展開トランスコードは、圧縮データを展開して返す処理です。クライアントは、展開されたデータを受け取ります。保存時のチェックサムは圧縮状態に対応するため、クライアントは展開後の値と直接比較できません。公式データ検証仕様

gRPC範囲読み取りの検証条件

gRPC範囲読み取りでは、応答チャンクごとのCRC32Cを照合します。ストリームに含まれる全体チェックサムで全体を検証するには、オブジェクト全体のデータを取得・集計して比較する必要があります。公式データ検証仕様[8]

送信側のgRPCでは、最初または最後のWriteObjectメッセージで全体のチェックサムを指定できます。メッセージ単位のチェックサムも指定でき、送信するデータチャンクは最大2 MiB（1 MiBは1,048,576バイト）です。公式データ検証仕様

並列合成アップロードの検証条件

並列合成アップロードは、データを分割して並列にアップロードし、最後に合成する方法です。転送元から保存後までのデータの完全性（内容が保たれていること）を確認するには、合成元のオブジェクトをクライアント側でそれぞれ検証してください。複合オブジェクト仕様

compose（複数のオブジェクトを合成する操作）には、競合を防ぐため、世代番号などの事前条件を指定してください。世代番号はオブジェクトの版を識別する値で、想定した版かを条件にすることで競合を防ぎます。複合オブジェクト仕様[3]

composeは、呼び出し側が渡した全体チェックサムと照合するサーバ側検証を行いません。転送元から保存後までの完全性を確認するには、合成後のオブジェクトもクライアント側で検証してください。MD5メタデータがないため、CRC32Cを扱えるクライアントか確認してください。複合オブジェクト仕様[4]

更新前後に確認する失敗対応と運用条件

アップロード時にチェックサムが一致しない場合、サーバは書き込みを拒否します。ダウンロード時に不一致を検出した場合は、破損データを破棄してください。推奨される再試行ロジックに従って、要求を再試行してください。公式データ検証仕様[7]

gcloudはGoogle Cloudのコマンドラインツールです。gcloudは、コピー・移動・rsyncで作成したオブジェクトの確定後にチェックサムを照合します。不一致オブジェクトが1〜3秒見える場合があり、検証前にツールが中断すれば残る可能性もあります。公式データ検証仕様[1]

rsync（ファイル同期ツール）の変更検出は、転送したデータの整合性確認とは別です。両側にmtime（最終更新時刻）があれば、サイズとmtimeを比較します。両側がCloud Storageで双方にMD5またはCRC32Cがある場合などは、チェックサムを比較します。公式データ検証仕様[2]

Cloud Storageのバケット（オブジェクトを格納する領域）からローカルへ同期する場合、rsyncは元オブジェクトの作成時刻をmtimeの代用にし、チェックサムを比較しません。公式データ検証仕様

mtimeもチェックサムも使えない場合は、サイズだけで変更を判断します。どの比較条件が使われるかを確認し、同期対象の選別と転送結果の検証を区別してください。公式データ検証仕様

運用者は、gcloudの並列合成アップロード後に終了ステータスを確認します。中断分の一時オブジェクトは、運用者が手動で削除します。保持ポリシー（一定期間の削除を制限する設定）があると、その期間中は一時オブジェクトを削除できません。並列合成アップロード仕様

既定ホールドは、新しいオブジェクトに自動適用される削除制限です。運用者は、ホールドを解除してから一時オブジェクトを削除してください。並列合成アップロード仕様[5]

本稿は2026年10月2日時点の公式資料に基づく解説です。