Cloud Storageの異常課金を追う、Advisorで最初に見る4項目

Cloud Storageの利用料が想定より増えたら、Storage Intelligence advisorの「Top findings」で、ColdlineまたはArchiveデータへのClass A/B操作、429エラー、リージョン間転送、保存量の異常を最初に確認する。組織またはフォルダから影響プロジェクトを選び、プロジェクト、バケット、prefixの順に降りると、増加に寄与した範囲とAPIリクエストを送ったサービスアカウントまで絞り込める。

Advisorは請求明細そのものではなく、Cloud Storageのメトリクスから通常傾向を外れた動きを見つける機能だ。異常課金の調査では、ここで原因候補を特定したうえで、同じ期間、プロジェクト、SKUの請求データと照合する。

Storage Intelligence advisorは組織、フォルダ、プロジェクトを横断してCloud Storage環境を監視・管理する機能として、2026年9月10日に一般提供されたことが Cloud Storageのリリースノート で確認できる。一般提供というステータスは機能の利用可能性を示すものであり、請求額を確定する機能であることを意味しない。

調査前にIAM権限と対象範囲を確認する

Advisorを開く前に、対象リソースでStorage Intelligenceが構成されていることを確認する。閲覧に必要な権限をまとめて付与する代表的な方法は、調査対象のプロジェクト、フォルダ、または組織にStorage Admin（roles/storage.admin）ロールを付与することだ。

GoogleのAdvisor操作手順 では、概要の閲覧にstorage.intelligenceConfig.get、findingとバケット詳細の閲覧にstorage.buckets.viewIntelligenceDetailsが必要とされている。Cloud Monitoringのダッシュボード、グループ、時系列、リソース情報を扱う権限も必要で、カスタムロールや別の事前定義ロールで満たせる場合がある。Geminiによるトラブルシューティングを使う場合は、cloudaicompanion.instances.completeTaskも必要だ。

組織やフォルダのカードを閲覧できても、配下のプロジェクトに必要な権限がなければ詳細には進めない。Projects with findingの表に権限不足の表示が出た場合は、集約画面だけで判断せず、そのプロジェクトを調査できる担当者に引き継ぐか、必要な範囲に限定して権限を追加する。

組織からプロジェクト、バケットへ降りる

Google CloudコンソールでStorage Intelligence Advisorを開き、リソースピッカーから組織、フォルダ、またはプロジェクトを選ぶ。「At a glance」にはストレージクラス別の合計保存量、オブジェクトを含むバケット数、オブジェクト数、平均オブジェクトサイズが表示される。全体像はここで把握し、異常の調査は「Top findings」から始める。

複数プロジェクトを管理している場合は、組織またはフォルダを起点にする。findingカードの「View details」を開き、影響を受けたプロジェクトについて、Project IDまたは名前、検出された変化、最終更新時刻、権限状態を比較する。変化の大きいプロジェクトを開くと、スコープがそのプロジェクトに切り替わる。

プロジェクトのFinding detailsでは、カテゴリ、最終更新、Common factors、プロジェクト全体の増加量を確認する。次に「Buckets with largest increases」から寄与の大きいバケットを選び、Bucket activity、増加の大きいprefix、APIリクエストを送ったprincipalまたはサービスアカウントを確認する。集約済みのバケットメタデータとアクティビティデータは390日間保持され、削除済みバケットの情報も表示され得るため、名称だけで現行リソースと判断しない。

最初に見る四つのfinding

Googleのfinding分類 では、次の四つのうち三つをUsage optimization、429エラーをPerformanceに分類している。請求増加の調査でも429を確認するのは、同じバッチ処理やアクセス集中が操作数とエラーを同時に増やしていないかを切り分けるためだ。

1. ColdlineまたはArchiveデータへのClass A/B操作急増。バケット詳細のClass A/B operationsと増加率を確認する。低頻度アクセス向けのデータが分析ジョブなどから頻繁に操作されている場合は、増加したprefixとサービスアカウントを手掛かりにワークロードを特定する。継続的なアクセスなら、キャッシュの利用、ジョブ頻度の調整、StandardやNearlineなど利用実態に合うストレージクラスを検討する。
2. 429 Too Many Requestsの急増。Number of 429 errorsと増加率を見て、特定のバケットやprefixにリクエストが集中していないかを調べる。429はCloud Storageによるレート制限を示し、レイテンシーやタイムアウトにつながる。主体が判明したら、そのサービスアカウントを使うアプリケーションやバッチの指数バックオフ、リクエスト増加のさせ方、アクセスの集中箇所を確認する。
3. リージョン間egressの急増。Cross-region egress volumeと増加率を確認する。これは、あるリージョンのCloud Storageバケットから別リージョンのGoogle Cloudサービスへ転送されるデータが、過去の傾向を上回った状態だ。対象バケットだけでなく、アクセス元サービスの配置を確認し、可用性や移行コストを踏まえて同一リージョンへの配置またはバケット再配置を検討する。
4. 過去30日の傾向を上回る保存量増加。Storage volume growthと増加率を確認し、At a glanceや時系列でオブジェクト数と平均サイズの変化を照合する。増加したprefixから、バックアップ、ログ、生成物など蓄積したデータ群を特定する。非現行オブジェクトの版が残り続けているならObject Lifecycle Management、アクセスパターンに応じたクラス管理が必要ならAutoclassを候補にする。

prefixとサービスアカウントまで縦に掘る

原因主体を探すときは、複数のfindingを浅く眺めるより、費用への寄与が疑われるfindingを一つ選び、同じ経路を縦に掘る。画面上の順序は次のとおりだ。

1. 組織またはフォルダのTop findingsで、対象のfindingを選ぶ。
2. Projects with findingで、変化が大きいプロジェクトを開く。
3. Finding detailsで、全体の増加量、Common factors、最終更新を確認する。
4. Buckets with largest increasesから、寄与の大きいバケットを開く。
5. Bucket activityで、finding固有の値と増加率を確認する。
6. Prefixes with largest increasesで、変化したデータ範囲を特定する。
7. リクエストに関係するfindingでは、Service accounts with largest increasesから送信主体を特定する。

prefixは「どのデータ群で変化したか」、サービスアカウントは「どのワークロードがAPIリクエストを送ったか」を示す手掛かりになる。たとえば、同じprefixでClass A/B操作と429が増え、同一のサービスアカウントが上位に現れた場合、そのアカウントを使うジョブの実行頻度、対象範囲、再試行設定を優先して調べる。ただし、これは相関による絞り込みであり、Advisorだけでコード変更や設定変更を原因と断定するものではない。

保存量だけが増えて操作数や429に変化がなければ、リクエスト処理より、生成データ量、オブジェクトのバージョン、ライフサイクル設定、保持要件を先に確認する。リージョン間転送だけが増えた場合は、サービスアカウントに加えて、アクセス元となるGoogle Cloudサービスのリージョンを確認する。

請求データと変更履歴で原因を確定する

Advisorでバケットやワークロードの候補を絞ったら、検出期間と同じ期間の請求データをプロジェクト、サービス、SKU単位で照合する。findingの増加率はメトリクスの変化であり、そのまま請求額の増加率を表すものではない。ストレージクラス、ロケーション、操作種別、転送経路によって費用への影響が異なるからだ。

最後に、候補となったサービスアカウントが使われたジョブやアプリケーションの変更履歴、対象prefixの用途、バケットの保持要件を確認する。変更後の即時確認にはCloud Monitoringやログを使い、Advisorには前日の活動が翌日に反映されるfindingがあるため、翌日以降に同じスコープとfindingを再確認する。