Google Cloudがストレージ異常を自動検知、追加設定は不要

Google Cloudは2026年9月18日、Cloud Storage向けのStorage Intelligence Advisorが正式提供（GA）になったと告知した。Google Cloudの9月18日付更新 によると、通常時の活動を基準に操作量、リージョン間送信量、エラーなどの異常を自動検知し、原因となるリソースと推奨対応を示す。

追加の異常検知ルールや独自の集計画面は必要ない。コンソールで組織、フォルダまたはプロジェクトを選び、「Top findings」から異常を開けば、影響を受けたプロジェクトやバケットへ絞り込める。ただし、Storage Intelligenceそのものの構成とIAM権限は前提となる。9月11日公開のクラウド更新まとめ も、9月10日付の公式リリース情報に基づき、GAと組織・フォルダ・プロジェクトをまたぐ対象範囲を伝えている。

自動検知するのは4種類の変化

Advisorは単なる容量一覧ではなく、過去の傾向から外れた活動を「finding」として抽出する。Google Cloudの操作文書 は、4種類のfindingに加え、Storage Intelligenceの事前構成、必要なIAM権限、組織・フォルダ・プロジェクト別の閲覧手順、390日間の履歴保持、削除済みバケットが表示される場合を説明している。

• ColdlineまたはArchiveデータに対するClass A/B操作の急増：低頻度アクセス向けのストレージクラスで、操作量が通常の基準を上回った状態を示す。アクセス頻度とストレージクラスが合っていない可能性を調べる手掛かりになる。
• 429エラーの急増：Cloud Storageがリクエストをレート制限している兆候で、遅延やタイムアウトにつながり得る。性能上の問題を起こしているバケットやリクエスト主体を追跡できる。
• リージョン間送信量の急増：あるリージョンのCloud Storageバケットと、別リージョンのGoogle Cloudサービスとの間で送信量が増えた状態を捉える。想定外の転送費用やリソース配置のずれを調べる入口となる。
• 保存バイト数が過去30日間の傾向を上回って増加：通常の増加傾向を超えたストレージ消費を示す。不要なオブジェクト世代や想定外のデータ投入など、容量増加の原因を絞り込むためのfindingだ。

公式上の分類は「利用最適化」と「性能」で、前者にはClass A/B操作、リージョン間送信、保存量の変化が、後者には429エラーが含まれる。Advisorが提供するのは異常の特定と推奨手順であり、バケットの移動やストレージクラスの変更を自動実行する機能としては案内されていない。

「At a glance」から「Top findings」へ進む

コンソールのStorage Intelligence Advisorページを開いたら、リソースピッカーで対象のプロジェクト、フォルダまたは組織を選ぶ。選択範囲に応じて「Project at a glance」「Folder at a glance」「Organization at a glance」が表示され、ストレージクラス別の総容量、オブジェクトを含むバケット数、総オブジェクト数、平均オブジェクトサイズを確認できる。

異常調査は「Top findings」から始める。対象のfindingカードで「View details」を開くと、カテゴリー、最終更新時刻、共通要因、選択範囲全体での増加量が示される。「Buckets with largest increases」には、その変化への寄与が大きいバケットが並ぶ。

利用前にはStorage Intelligenceを構成し、対象のプロジェクト、フォルダまたは組織に対する閲覧権限を用意する必要がある。事前定義ロールではStorage Admin（roles/storage.admin）が案内されている。カスタムロールを使う場合は、finding概要を取得するstorage.intelligenceConfig.get、詳細とバケットへのドリルダウンに使うstorage.buckets.viewIntelligenceDetailsのほか、Cloud Monitoringのダッシュボード、グループ、時系列、リソース情報に関する権限が必要になる。

組織からプロジェクト、バケットへ絞り込む

組織またはフォルダの画面では、findingカードが配下の複数プロジェクトの異常を集約する。詳細を開くと、影響を受けたプロジェクトのIDまたは名称、検知された変化、最終更新時刻を一覧できる。特定プロジェクトへの権限が不足している場合は、その行に警告が表示される。

一覧からプロジェクトを選ぶと、対象プロジェクトのfinding詳細が別タブで開く。そこで増加への寄与が大きいバケットを選び、バケット固有の活動指標へ進む。さらに、増加が大きいオブジェクトのプレフィックスや、APIリクエスト増加に関係したサービスアカウントまで確認できる。

表示される指標はfindingによって異なる。Class A/B操作では操作数と増加率、429エラーではエラー数と増加率、リージョン間送信では送信量と増加率、保存量の異常ではストレージ増加量と増加率が調査材料になる。この階層構造により、組織全体の異常から個々のバケットを順番に探し直す必要がなくなる。

390日履歴には削除済みバケットも残る

Advisorは集約したバケットのメタデータと活動データを390日間保持する。保存量のfindingが過去30日間の傾向を基準にすることと、画面で参照できる履歴の保持期間が390日であることは別の条件だ。

履歴には削除済みバケットの情報が含まれる場合がある。見慣れないバケットが表示されても、現在稼働している未知のリソースとは限らないため、リソースの現状とfindingの最終更新時刻を照合する必要がある。これは過去の活動を保持する仕組みに伴う表示上の注意点で、削除済みバケットが復元されたことを意味しない。

「設定不要」が指す範囲

今回不要になるのは、個々の異常を見つけるための検知ルール、データ処理パイプライン、集計画面を一から用意する作業だ。一方で、Storage Intelligenceの構成、適切なIAM権限、findingの内容確認、推奨策を実行するかどうかの判断は引き続き管理者が担う。

正式提供で整ったのは、自動検知した異常から組織、フォルダ、プロジェクト、バケット、プレフィックスやサービスアカウントへ進む一連の調査経路である。9月18日の告知時点で4種類のfindingと操作手順は公開されているが、findingが示した変更を自動適用する仕組みではない。