NTTドコモR&Dの技術ブログです。

トップ > AWS > クラウドの不要なリソースと削減可能額を可視化するダッシュボードを作って全社公開した話

クラウドの不要なリソースと削減可能額を可視化するダッシュボードを作って全社公開した話

AWS クラウド 事例紹介 生成AI

こんにちは。ドコモ・テクノロジ株式会社 サービスインテグレーション事業部 スマートインテグレーション部の奥田絢香です。ドコモのCCoE（Cloud Center of Excellence）として、パブリッククラウドのコスト最適化やドコモグループ向け共通基盤運用の業務に携わっています。

今回は、2026年2月18日に開催されたNTT Tech Conference 2026にて「クラウドの不要なリソースと削減可能額を可視化するダッシュボードを作って全社公開した話」というテーマで登壇して来たので、当日のセッション内容を振り返りながら、技術的なハイライトをご紹介します。

発表の様子

クラウドに潜む「チリツモ浪費」の罠

皆さんは、自分が管理しているAWSアカウントの中に「不要なリソースは1つもない！」と自信を持って言えますか？パブリッククラウドは便利な従量課金制ですが、それは裏を返せば「使っていなくても、存在しているだけで課金され続ける」ということでもあります。

  • 終わった検証環境（停止し忘れたEC2やRDS）
  • 消し忘れた一時リソース（未使用のEIPや解放漏れのEBS）
  • 古いバックアップ（昔のEBSスナップショット）

これらを放置すると、塵も積もれば山となり、思わぬ浪費の山になってしまいます。過去には、ドコモCCoEチームで検証などに利用していたアカウントでリソースの総点検を実施した結果、アカウント内で発生していた利用料金の約60%が不要なリソースによるものだったという事例もありました。

ドコモグループ全体で利用しているAWSアカウント数はなんと2,400以上。これを各チームの自主的な管理だけで最適化し続けるのは至難の業です。 そこで全アカウントの不要リソースと削減可能額を一覧化し、誰でも確認できるダッシュボード「Cloud Frugal Dashboard」を構築することにしました。

「Cloud Frugal Dashboard」とは？

ドコモグループ全体に向けて公開したこのダッシュボードでは、現在以下の6項目について「不要なリソース」を検出し、可視化しています。

  • EC2: UnusedBox（未使用のオンデマンドキャパシティ予約）、InstanceIdleOrUnused（アイドル状態のインスタンス）
  • EBS: CreateSnapshotAndDelete（アタッチされていないボリューム）、DetachAndCreateSnapshotAndDelete（アタッチされているがインスタンスが使われていないボリューム）
  • RDS: ExtendedSupport（延長サポート利用中）、InstanceIdleOrUnused（アイドル状態のインスタンス）

Cloud Frugal Dashboard 画面イメージ

ダッシュボード上では、「1日/1ヶ月/1年あたりの推定削減可能額」がひと目で分かるサマリ画面や、組織部門・プロジェクトごとの削減可能額の割合を示す円グラフ、さらには対象リソースのARNや推奨事項などを一覧化した詳細テーブルを提供しています。また、対応が進んだことによる「削減達成額」も時系列で可視化し、モチベーションの向上に繋げています。 2025年8月のリリース以降、約20,000個もの不要リソース削減を達成しました！

失敗から学んだ最適なアーキテクチャ設計

このダッシュボード、実は本格的な仕様検討からリリースまで、私1人で約1ヶ月間で構築しました。

最初から完璧な構成が思いついたわけではなく、短期間でプロトタイプを作っては壊す（スクラップ＆ビルド）を繰り返しました。

プロトタイプ①：Trusted Advisorベース（運用面でNG）

最初はAWS Trusted Advisorの組織ビューを元データにしようと考えました。しかし、定期エクスポートやAPIに非対応であり、都度マネジメントコンソールから手動でエクスポートする必要がありました。日々データが更新されるダッシュボードにおいて、人間の手作業が介在するアーキテクチャはNGと判断しました。

プロトタイプ②：Cost Optimization Hubの生データ直入れ（性能面でNG）

次に、AWS Cost Optimization HubのデータをAWS Glue経由でS3に出力し、そのままBigQueryに日次でINSERTし続ける構成を試しました。 全データをINSERTするようにしていたため1日約70,000行分もあり、日次でデータが膨大に積み上がり、Looker Studio側でフィルタ処理をかけた結果、ビジュアライズに時間がかかりすぎて実用性に欠けるため、これもNGとなりました。

最終アーキテクチャ：Athenaで集計・加工してBigQueryへ

最終的に採用したのは、以下のマルチクラウドなサーバーレスアーキテクチャです。

  • データソース: AWS Cost ExplorerとCost Optimization HubのデータをS3にエクスポート
  • データカタログ: AWS Glueでテーブル定義
  • データ加工: Amazon EventBridge Schedulerで日次起動するAWS Lambdaから、Amazon Athenaを利用してSQLクエリを実行。前日分のデータのみを抽出し、必要な形に加工。
  • データウェアハウス: 加工後のデータをGoogle CloudのBigQueryに追記（INSERT/UPDATE）
  • 可視化: Looker Studioでダッシュボード化

Cloud Frugal Dashboard アーキテクチャ（システム構成）

この構成により、Looker Studioの描画パフォーマンス問題をクリアしつつ、サーバーレス構成によってシステム全体のインフラ費用を月額4,000円程度に抑えることができました。

生成AIをフル活用！「人間は一切コードを書かない」開発手法

1人で1ヶ月という短期間でこのシステムを構築できた最大の理由は、生成AI（GeminiとGitHub Copilot）のフル活用です。今回、Lambdaで実行するPythonコード（約300〜500行×2種）や、IaCのためのCloudFormationのYAMLファイルについて、私は一切ソースコードを書いていません。生成AIを活用することで、実装にかかる稼働の約80%を削減できました！ 具体的にどのようにAIを使ったのか、プロンプトの工夫をご紹介します。

1. Geminiで「仕様書」を作らせる

いきなりコードを書かせるのではなく、まずはGeminiに要件を伝えて仕様書を作成させました。 スキーマ情報は文字で打つのが大変なので、画面のスクリーンショットをそのままGeminiに読み込ませて理解させています。

【入力したプロンプトの例】

あなたはマルチクラウドソリューションエンジニアです。新しいシステムを構築します。（中略）

  • ソースコードの実行場所は AWS Lambdaです。
  • AWS Glue テーブルに格納されたデータを Athenaを利用して読み取り、Google CloudのBigQueryに対して INSERTします。
  • Athenaのスキーマはスクリーンショットの通りです。
  • BigQueryのスキーマの1つであるestimated_daily_cost_after_discountには、月額の1日あたりの金額を計算して格納します。

仕様書の作成にあたり他に必要な情報があれば聞いてください。

この「他に必要な情報があれば聞いてください」という指示で、Geminiから「実行頻度は？」「日時のフォーマットは？」と逆質問が来るため、それに答えるだけで堅牢な仕様書が完成します。

2. GitHub Copilotに仕様書を渡してコーディング

Geminiが生成した完璧な仕様書を、今度はGitHub Copilotにそのままプロンプトとして渡し、「この仕様に基づきPythonコードを生成して」と指示します。これだけで、Pandasを用いたデータ加工からBigQueryへのロード処理まで、ほぼ動くコードが生成されます。

3. ロジックの変更も言葉で指示

開発途中で「毎日全データをINSERTするのではなく、resource_arnをキーにして、既に存在すればUPDATE、無ければINSERTにしたい」という要件変更が発生しました。 これもCopilotに対して、「処理日の全データを取得後、1レコードずつBigQueryを確認し、存在する場合は〇〇をUPDATE、しない場合は新規INSERTして」と自然言語で指示するだけで、該当部分のコードを見事に修正してくれました。

4. エラー解決もAIにお任せ

CloudFormationのデプロイ時などにエラーが出た場合も、マネジメントコンソールに出力されたエラーログをそのままCopilotに貼り付けます。 AIは「IAMポリシーでParameter Storeの動的参照がうまく展開されていません」と原因を特定し、修正後のYAMLコードを提示してくれます。

生成AI活用における学びと、エンジニアの役割

今回、生成AIをフル活用して感じたことは、「コーディングはAIに任せられるが、ディレクション力と技術力は人間が必要不可欠である」ということです。 AIに適切な指示（プロンプト）を出すためには、「何のために何をしたいのか」「どのクラウドリソースを組み合わせるのが最適か」というアーキテクチャ設計や要件定義の能力が求められます。また、AIが出力したコードや解決策が本当に正しいのか、セキュリティ的に問題ないかを判断するベースの技術知識も当然必要です。 エンジニアの役割は「コードを書くこと」から、「システム全体の設計図を描き、AIをディレクションして実現させること」へとシフトしていると強く実感しました。

まとめと今後の展望

「Cloud Frugal Dashboard」によって、不要リソースの可視化と全社への透明性確保が実現し、定期的な見直しサイクル（定着）が回り始めました。ダッシュボードを公開して終わりではなく、調達部門と連携した利用者への対応プッシュや技術的サポートも継続して行っています。今後は、以下を検討しています。

  • 項目追加: AWSの他のサービスなどへの対応
  • 発生前の抑止: 「できてしまった不要リソースを消す」だけでなく、「不要なものを作らせない、放置させない」ための予防的な仕組み（ガードレール）の導入

これからも、CCoEとしてドコモグループ全体のクラウドコスト最適化と、効率的なクラウド活用の文化醸成に努めていきます。

当日の発表動画は下記からご確認いただけます。 youtube.com

最後までお読みいただきありがとうございました！