放置されたリソースをゼロへ！Cloud Asset Inventoryで進めるGoogle Cloud資産整理実践

TL;DR

Google Cloudのリソース管理に課題を感じていませんか？「どのリソースがどのチームのものか分からない」「不要なリソースが放置されてコストが膨らんでいる」といった悩みを解決するため、Cloud Asset Inventoryを活用した実践的な資産管理手法をご紹介します。

1. 自己紹介

NTTドコモデータプラットフォーム部（以下DP部）黒須です。DP部では社内データ活用プラットフォームPochiを開発・運用しております。

プラットフォームの運用拡大に伴い、アプリの増加やLLMの導入により Google Cloud 上のリソースが増加しました。その結果、どのリソースがどのチームのもので何の目的で作られたのかが不明瞭になり、現状把握が難しくなっていました。リソースの用途や所有が明確でないと、未利用の資産が放置されてコストが増大するほか、責任者不在のリソースがセキュリティ上のリスクとなる可能性があります。加えて、監査時に利用目的や管理責任を説明できないと運用上の重大な問題につながります。これらの課題を解消するため、リソースを整理して不要なものを削除し、残す資産については役割を明確にして適切に管理する必要がありました。

本記事は、当部で実施したGoogle Cloud資産の棚卸事例を紹介いたします。記事の詳細部分については業務委託先メンバーであるウショウさん・藤井さんに執筆協力をいただきました。この場を借りてお礼申し上げます。

社内データ活用プラットフォームPochi※1とは

私たちDP部は社内のデータ民主化を目指し、StreamlitとGoogle Cloudで圧倒的に使いやすいデータ活用プラットフォームを開発・推進しています。このプラットフォームは、24年度は30万時間もの業務効率化を実現し、直近では5,000人以上の社員に利用が拡大しています。

ASCII.jp：NTTドコモ、Streamlit利用の"ポチポチ分析アプリ"開発で社内データ活用を促進 (1/3)

※1: Pochiは社内の開発コードネームです

対象読者

Google Cloudのリソース管理に課題を感じている方
Google Cloudにおけるリソース管理方法に興味がある方

2. 方針

本取り組みは、CIS Critical Security Controls Version 8.1 の「企業資産のインベントリ作成と管理」を起点に開始しました。同方針を参考に、全資産のインベントリを継続的に更新することで、以下のリスクを低減することが出来ます。

未許可資産の混入によるセキュリティリスク増大
最新インベントリ欠如による監視・制御の不備
重要データと事業部門の紐付け不十分
全資産の追跡・責任所在の不明瞭化（監査困難）

3. 資産管理方法の検討

本記事では、前述の課題を解決するため、Cloud Asset Inventoryを用いた資産管理方法を検討しました。Cloud Asset Inventoryは、プロジェクトや組織内のリソースを一元的に収集・可視化・検索できる Google Cloud のサービスです。コンソールなどへエクスポートしてダッシュボード化することで、リージョンやサービスごとの内訳を把握したり、リソース一覧を絞り込んでLabelやDescriptionから担当者や用途を確認できます。さらにフィード機能で差分を監視し通知に繋げることもできるため、可視化と運用の両面で管理体制を強化できます。

まずCloud Asset Inventoryのエクスポート機能を用いて、全リソースをCSV形式で一括取得しました。しかし取得したインベントリには所有者や用途といった説明が一切なく、各リソースの所有者や用途が全く分からない状態でした。メタデータが欠如しているため、検索・フィルタリング機能を活かせず、このままではCloud Asset Inventoryの強力な機能を十分に活用できません。結果として「このリソースは誰が何のために使っているのか」を特定できず、資産整理を進めることができませんでした。

資産（リソース集合）を整理・管理するには個々のリソースへのメタデータ付与が不可欠です。そこで、各リソースにLabelやDescriptionといったメタデータを付与し検索・分類可能な状態にする必要があると判断しました。Google CloudのLabel付与のベストプラクティスでも推奨されているように、すべてのリソースにLabelを付与することを第一方針としました。

しかし調査の結果、一部のリソースタイプではLabelを付与できないことが判明しました。また、Labelを付与できる場合でも、key-value形式では表現しきれない詳細情報を管理したいケースもありました。そこで以下の優先順位で管理方法を決定しました:

Label付与可能 → Labelで管理
Label不可かつ Description可能 → Descriptionで管理
いずれも不可又はより詳細な情報管理が必要 → 個別管理手法を検討

この方針により、各リソースの特性に応じて管理手法を使い分ける体系を構築しました。具体的には、Label又はDescriptionでメタデータを付与してCloud Asset Inventoryで一元管理する方法と、それが困難なリソースについては個別に管理情報を保持する方法の組み合わせです。この体系により、全体として統一的な資産（リソース集合）管理を実現しました。

3-1. Label・Descriptionによる一元管理

LabelはGoogle Cloudのベストプラクティスを参考に、以下の項目を定義しました:

キー	値例	説明
environment	prod / dev / mtn	利用環境の識別
state	active / readytodelete / unknown	リソースの状態
team	team-a / team-b / team-c	担当チーム

Labelを付与できないリソースについては、Descriptionフィールドを活用しました。設計にあたっては、前述のLabel項目(environment/state/team)に準拠した情報を含めることで、管理の一貫性を保つ方針としました。例えばService Accountの場合、「mtn環境のCloud Functions用サービスアカウント(team-a担当)」のように、環境・用途・担当チームを一文にまとめて記載しました。

最終的に、リソース所有者へのヒアリングを通じて担当者・用途・削除可否を確認し、確定した情報を各リソースに付与しました。

以下はCloud Asset InventoryでSecret Managerを対象にし、さらにenvironment=devで絞り込んだ例です。

3-2. 個別管理が必要なリソースへの対応

LabelもDescriptionも付与できないリソースについても、社内資産管理・棚卸の用途で台帳としてまとめて管理する必要がありました。今回個別管理が必要となったリソースは以下の通りです:

VPCとCloud Load Balancing

これらのリソースはLabelやDescriptionの設定ができず、当プロジェクトでは構成が定期的に見直されることから、個別リソース単位での管理には適していません。今後の管理方法については、継続検討としています。

IAM Group

IAMの権限管理はグループ単位で行っているため、個別リソースとしてではなくグループ全体の管理が必要です。ただし、組織レベルでのグループ管理には当チームの権限上の制約があるため、今回は対象外とし、VPCやCloud Load Balancingと同様、今後の管理方法については継続検討としています。

Firestore

FirestoreではLabelの付与は可能ですが、管理情報としては不足するため、各データベースにメタデータ専用コレクションを追加して補完する方針を採用しました。

メタデータコレクションの構造:

フィールド	値例	説明
オーナー	team-a / team-b / team-c	責任者
データの詳細な説明	dev環境のギャラリーページのアプリ登録データ	データ用途概要
環境	prod / dev / mtn	データが属する環境
メタデータ作成日	2025-10-03T12:34:56Z	メタデータ作成時刻
メタデータ更新日	2025-11-18T09:12:00Z	メタデータ最終更新時刻

この構造により、Firestoreコンソールから各データベースを開くと追加したメタデータを直接確認できるようになり、詳細な情報管理と検索性の向上を実現しました。

4. 結果

本取り組みにより、Cloud Asset Inventoryを有効活用するための基盤を整備できました。

各リソースにLabelやDescriptionを付与したことで、Cloud Asset Inventoryの検索・フィルタリング機能が実用的になりました。具体的には以下のような検索が可能になっています:

特定チームが管理するリソースの一覧表示
環境(prod/dev/mtn)ごとのリソース絞り込み
削除予定(state=readytodelete)リソースの抽出

また、LabelやDescriptionで対応できないリソースについても、個別管理手法を確立し、全体として統一的なリソース管理の仕組みを構築できました。

これにより、「このリソースは誰が何のために使っているのか」という問いに対し、Cloud Asset Inventoryを起点に迅速に回答できる体制が整いました。

さらに、本取り組みを通じて予想以上の成果が得られました。例えばSecret Manager、Cloud Run jobs、Firestoreの3つのサービスにおいて、利用されていないリソースを特定したところ、約半数が不要なリソースであることが判明しました。これらを削除した結果、コスト削減という具体的な成果を上げることができただけでなく、管理対象リソースの削減により運用負荷の軽減にもつながりました。