Amazon Web Services ブログ
自治体のためのクラウドコスト最適化 ①：定期レビューで回すコスト最適化の手順
「自治体のためのクラウドコスト最適化」シリーズについて
自治体がガバメントクラウド上で業務システムを運用する場合、クラウド利用料の管理はオンプレミスとは性質の異なる実務になります。従来は、機器を調達した時点で費用がほぼ固定され、その後の管理は保守契約の範囲で済みました。クラウドは使った分だけ課金されるため、構成を変えれば費用も変わります。移行後も構成の見直しをすることでコストを最適化することができます。
ところがこの見直し作業は、技術的な判断を伴うため日々の運用を担う事業者に委ねられがちです。結果として、自治体側に判断の材料が届かないまま請求額だけが確定していくことがあります。クラウド利用料は自治体の予算から支出され、住民や議会に説明する主体は自治体です。本シリーズは、自治体が自らクラウド費用を把握し、事業者と協働して最適化を続けられる状態を目標にしています。
ただしコスト最適化は、マネジメントコンソールで数値を確認する日々の運用から、調達仕様書への反映、予算要求・決算の手続き、システム基盤そのものの設計まで、性質の異なる複数の作業で成り立っています。これらは担い手も検討のタイミングも異なるため、本シリーズでは領域ごとに記事を分けています。
| # | タイトル | 扱う領域 | 自治体職員 | ベンダー | ||
|---|---|---|---|---|---|---|
| 情報政策 担当 |
財政担当 | 運用管理 補助者 |
ASP | |||
| ① | 定期レビューで回すコスト最適化の手順（本記事） | 日々の運用 | ● | ○ | ● | ○ |
| ②-1 | 運用管理補助者との協働体制を調達仕様書に落とし込む | 調達・契約 | ● | ○ | ○ | ○ |
| ②-2 | AI Agent でコスト分析を自動化する（公開予定） | 運用の効率化 | ● | ○ | ○ | |
| ③ | 予算要求・執行・決算の実務（公開予定） | 予算・会計 | ○ | ● | ||
| ④ | 20業務の最適化設計と実践（公開予定） | 基盤の設計 | ○ | ● | ● | |
補足： ②-2、③、④は今後公開予定です。公開時にはこの表からリンクします。
凡例：●は主な対象、○は関連する範囲で参考になる読者です。
- 情報政策担当：情報システム部門でクラウド環境の運用を所管する職員
- 財政担当：予算要求・執行・決算の手続きを担当する職員
- 運用管理補助者：ガバメントクラウドの運用管理を自治体から受託する事業者
- ASP：業務システム（パッケージ）を提供し、その動作保証を担う事業者
どこから読むか：情報政策を担当される方は①から、財政を担当される方は③から始めてください。運用管理補助者・ASP の方は④が中心になりますが、①も前提知識としてご確認ください。なお ASP が運用管理補助者を兼務する場合は、両方の役割の記述が該当します。
本記事について
クラウドの利用料がいくらかかっているか、自治体職員と運用管理補助者が同じ画面を見ながら把握できていますか？
本記事は、AWS を利用する自治体職員（情報政策担当）と運用管理補助者が、コスト最適化を定期的に回すための手順をまとめた実践ガイドです。マネジメントコンソールのどの画面を見て、どの数値をどう判断し、誰に何を依頼するかを具体的に解説します。読み終えると、自分の目でコスト状況を確認し、何にいくらかかっているかを把握して、削減余地を根拠とともに提案できるようになります。ガバメントクラウドに限らず、AWS 上で業務システムを運用する自治体であれば同じ手順が使えます。
読者別の使い方は次のとおりです。
| 読者 | 本記事の使い方 |
|---|---|
| 自治体職員 （情報政策担当） |
マネジメントコンソールでコスト状況を確認し、運用管理補助者との会議に備える |
| 運用管理補助者 | チェックリストに沿ってコストレポートを作成し、削減提案を行う |
| ASP | 運用管理補助者を兼務する場合に活用。パッケージの動作保証に関わる変更については 1.2 を参照 |
参考： デジタル庁が提供する GCAS ガイドの「継続的運用経費最適化(FinOps)ガイド」別紙2-1「クラウド管理画面の活用（AWS編）」は、コスト最適化に活用できる AWS ツールの一覧と公式ドキュメントへのリンクを整理した資料です。本記事は別紙2-1 で示されたツールを実際にどう使うかを、自治体の実務に即して解説するものです。GCAS ガイドは GCAS ポータルの「GCASガイド」からご参照ください。
目次
- はじめに — 同じ画面を見て話そう
- 1.1 前提条件
- 1.2 誰が何をするか
- 定期点検の進め方
- 2.1 なぜ定期的に点検するのか
- 2.2 年間スケジュール
- 2.3 定期点検チェックリスト
- 2.4 レビュー会議のアジェンダ例（60 分）
- 2.5 年次レビュー時の追加確認項目
- コスト確認に使う AWS サービス
- 3.1 Cost Explorer
- 3.2 コスト最適化ハブ
- 3.3 Compute Optimizer
- まとめ — 継続的改善に向けて
- 4.1 本記事のポイント
- 4.2 協働による効果
- 4.3 シリーズの他記事との接続
- Appendix: 各サービスの操作手順（マネジメントコンソールの画面遷移とクリック手順）
- Appendix A: Cost Explorer
- Appendix B: コスト最適化ハブ
- Appendix C: Compute Optimizer
1. はじめに — 同じ画面を見て話そう
本記事では、自治体職員と運用管理補助者が集まってコスト状況を確認する場を「レビュー会議」と呼びます。着手した当初は月次で始め、推奨事項への対応が一巡してきたら、間隔を空けたり時間を短くしたりと段階的に見直します（2.4参照）。本記事では月次で開催する前提で、その会議で何を見て、どう判断するかを具体的に示します。
1.1 前提条件
本記事は、自治体職員が以下のサービスについて閲覧（Read-Only）権限を付与されている環境を想定しています。
- AWS Cost Explorer
- コスト最適化ハブ（AWS Cost Optimization Hub）
- AWS Compute Optimizer
補足： マネジメントコンソールの閲覧権限がまだない場合でも、運用管理補助者に同様のレポートを提出してもらうことで、同じ流れで確認できます。
1.2 誰が何をするか
コスト最適化は、マネジメントコンソールで状況を確認する作業と、リソースを実際に変更する作業に分かれます。前者は自治体職員が自ら行えますが、後者は運用管理補助者への依頼が必要で、さらに変更内容によっては ASP の確認も必要になります。本記事はこの区別を明確にしながら解説します。
なお、一定期間の利用を約束することで割引を受ける仕組みとして リザーブドインスタンス / Savings Plans（以下 RI/SPs） があります。本記事では以降この略記を用います。
本記事には メトリクス という言葉がたびたび出てきます。CPU 使用率やディスクの読み書き量など、サーバーやストレージが実際にどれだけ使われているかを一定間隔で記録した数値のことです。AWS では Amazon CloudWatch が自動的に収集しており、「このサーバーは割り当てた性能に対して使われていない」といった判断は、この数値をもとに行われます。
自治体職員ができること／依頼が必要なこと
| 作業 | 自治体職員ができること | 依頼が必要なこと |
|---|---|---|
| コスト構造の把握 | サービス別・タグ別のコスト確認 | （職員自身で完結可能） |
| 推奨事項の確認 | コスト削減推奨・サイジング推奨の閲覧 | （職員自身で完結可能） |
| 監視メトリクスの確認 | （環境による） | 運用管理補助者にメトリクス取得・分析・レポート作成を依頼 |
| リソースの変更 | 推奨内容を確認するのみ | 運用管理補助者に業務影響評価・変更実施を依頼（変更内容により ASP の動作保証確認が前提） |
| RI/SPsの購入 | 購入前分析の確認は可能 | 運用管理補助者が購入提案・購入手続きを実施 |
リソース変更における運用管理補助者と ASP の関係
リソースの変更操作そのものは運用管理補助者が実施しますが、業務システム（パッケージ）の動作に影響しうる変更については、ASP が動作保証の範囲を判断する立場にあります。ASP が推奨構成として提示していない構成に変更した場合、障害発生時の切り分けや保守の対象外となる可能性があるためです。
| 変更の種類 | 判断・確認の主体 | 実施 |
|---|---|---|
| 未使用リソースの削除（未アタッチの Amazon EBS ボリューム、未使用の Elastic IP 等） | 運用管理補助者が影響を確認 | 運用管理補助者 |
| インスタンスタイプの変更、ストレージ種別の変更（gp2→gp3 等） | ASP が動作保証を確認した上で自治体が判断 | 運用管理補助者 |
| 稼働スケジュールの変更（夜間・休日停止等） | ASP が業務要件との整合を確認した上で自治体が判断 | 運用管理補助者 |
| RI/SPs の購入 | 運用管理補助者が提案し自治体が判断 | 運用管理補助者 |
補足： コスト最適化ハブや Compute Optimizer が「サイズを下げられる」と推奨していても、それは AWS 側のメトリクス分析による技術的な推奨であり、パッケージの動作保証を含むものではありません。ASP への確認手順や、動作保証が得られない場合の進め方は シリーズ④（公開予定）で詳しく扱います。
次章では、定期点検でやるべきことの全体像をチェックリスト形式で紹介します。
2. 定期点検の進め方
2.1 なぜ定期的に点検するのか
一度サイズを見直した構成も、運用が続けば数か月で実態と合わなる可能性があります。定期的な点検が必要な理由は次の3点です。
1. コストは放置すると増える
クラウドは、検証用に作成したリソースの停止忘れ、業務量の増加に伴うストレージの自然増、機能追加に伴うサーバー追加など、日々の運用の中でコストが増える要因を常に抱えています。
2. 推奨事項は時間とともに変わる
コスト最適化ハブや Compute Optimizer の推奨は、直近の利用実績（メトリクス）に基づいて算出されます。業務の繁忙期を過ぎればサイズダウンの推奨が新たに出ますし、逆に利用が増えれば推奨は消えます。ある時点で「対応不要」と判断した項目も、数か月後には状況が変わっている可能性があります。
3. 説明できる状態を保てる
議会や監査で「クラウド費用は適正か」と問われた際、日常的に点検し記録を残していれば、実績と改善の経過を示して回答できます。この点は シリーズ③（公開予定）で詳しく扱います。
職員が自ら確認する意味： 「コスト管理は運用管理補助者に任せている」という状態でも、請求額の説明責任は自治体側にあります。職員がマネジメントコンソールで数値を確認できるようになると、報告を受けて追認するだけの関係から、同じ画面を見て「この増加は何か」「この推奨は実施できないか」と踏み込んで議論できる関係に変わります。すべてを理解する必要はなく、本記事のチェックリストの範囲を確認できれば十分です。
2.2 年間スケジュール
図: 年間スケジュール
| 種別 | 実施時期 | 内容 |
|---|---|---|
| ▲ レビュー会議 | 前月実績の確定後（目安として7日以降） | 前月・先々月のコスト比較、推奨事項の確認、対応状況の追跡 |
| ★ 年次レビュー | 1月中旬 | 年間のコスト推移振り返り、次年度の RI/SPs 購入検討、予算策定への反映 |
| ● RI/SPs 購入 | 4月1日（年度開始） | 年次レビューで合意した RI/SPs の購入実施（運用管理補助者が実施） 参考: Amazon RDS リザーブドインスタンスの一括購入サンプルスクリプト ※ 4月も他月と同様にレビュー会議（7日以降）を実施します |
実施時期の考え方
レビュー会議を月初7日以降としているのは、前月分の請求額が確定してから確認するためです。月初の数日間は前月の利用料が確定しておらず、Cost Explorer の数値も変動します。
年次レビューを1月中旬に置いているのは、4月1日の RI/SPs 購入に間に合わせるためです。利用実績の分析から購入プランの検討、自治体内の意思決定、運用管理補助者への依頼までを考えると、2〜3か月の余裕が必要になります。次年度予算の編成時期とも重なるため、この時期の振り返りが予算要求の根拠にもなります（シリーズ③ 参照）。
2.3 定期点検チェックリスト
確認は次の流れで行います。各サービスの詳細（画面の見方や判断基準）は第3章で解説しているので、チェックリストの参照先（3.1〜3.3）から辿ってください。
- 自治体職員が Cost Explorer で過去 6 か月のコスト推移を見て、総額の変化と急な増減がないか確認する（→ 3.1）
- 自治体職員がコスト最適化ハブで推奨事項の全体像と推定削減額を確認する（→ 3.2）
- サイジングが気になるリソースがあれば、Compute Optimizer で個別に掘り下げる（→ 3.3）
- 以上の確認内容をレビュー会議で運用管理補助者と共有し、対応を協議する
- 合意した施策を運用管理補助者が実施する（→ シリーズ④）
「まず総額と増減を把握し、次に削減できる余地を探す」という順序で確認します。
【自治体職員（情報政策担当）の事前確認】
月初（前月実績の確定後、目安として7日以降）に実施し、先月分と先々月分を比較確認：
| No | 確認項目 | 参照章 | 確認欄 |
|---|---|---|---|
| 1 | Cost Explorer で前月のサービス別コスト上位 5 を確認した | 3.1 | □ |
| 2 | 前月比 ±10% 以上、かつ増減額が一定額以上のサービスがないか確認した | 3.1 | □ |
| 3 | 増減があった場合、その要因となったサービスを特定した | 3.1 | □ |
| 4 | コスト最適化ハブで推奨事項の総数と推定削減額を確認した | 3.2 | □ |
| 5 | コスト最適化ハブで未使用・低稼働のリソースへの推奨を確認した | 3.2 | □ |
| 6 | Compute Optimizer で「過剰なプロビジョニング」の件数を確認した | 3.3 | □ |
| 7 | 気になる点をレビュー会議の議題リストにまとめた | – | □ |
チェックリストに出てくる用語： 内容の詳細は第3章で解説します。
- 未使用・低稼働のリソース：稼働しているものの、ほとんど使われていないリソース。停止忘れのサーバーや、削除されずに残ったストレージなどが該当します。
- 過剰なプロビジョニング：割り当てた性能に対して実際の使用率が低く、サイズを下げられる可能性があるリソース。
- プロビジョニング不足：逆に性能が不足しており、業務への影響が出る前に増強を検討すべきリソース。
個々のリソースについて「本当に下げてよいか」は運用管理補助者と ASP の判断が必要になるため、レビュー会議の議題として持ち込んでください。
【運用管理補助者の事前準備】
レビュー会議までに以下を準備：
| No | 準備項目 | 参照章 | 確認欄 |
|---|---|---|---|
| 1 | コストレポートを作成した（サービス別・業務別内訳含む） | 3.1 | □ |
| 2 | 前月比で増減が大きいサービスについて、変動要因を分析した | 3.1 | □ |
| 3 | コスト最適化ハブ推奨の対応状況を整理した（優先度 A/B/C 別） | 3.2 | □ |
| 4 | コスト最適化ハブ推奨のうち未使用・低稼働リソースへの対応状況を整理した | 3.2 | □ |
| 5 | Compute Optimizer 推奨の対応状況を整理した | 3.3 | □ |
| 6 | Amazon CloudWatch メトリクスからサーバー別の利用状況レポートを作成した | シリーズ④ | □ |
| 7 | 稼働時間・ストレージ最適化施策の実施状況を整理した（Instance Scheduler on AWS、gp2→gp3 移行、未使用リソース等） | シリーズ④ | □ |
| 8 | 新規の最適化提案を作成した（削減額・作業負荷・業務影響・ASP 確認の要否を添えて） | シリーズ④ | □ |
準備項目 8 は毎回求めてください。 既存推奨への対応状況の報告とは別に、運用管理補助者側から新たな削減余地を提案する項目です。レビュー会議は状況確認の場であると同時に、次の施策を決める場でもあります。提案がなければ会議は報告のみで終わり、開催する意味が薄れます。
実務上は「削減余地は必ずどこかにある」という前提で臨むことをお勧めします。サイズの適正化が一巡しても、稼働スケジュールの見直し、ストレージ階層の変更、RI/SPsの適用範囲の拡大、ログ保持期間の見直しなど、切り口は残っています。すべてを実施する必要はなく、選択肢として挙がっていることが重要です。
提案が出てこない場合は「提案なし」で済ませず、なぜ現状が最適と判断したのかを説明してもらってください。「サイズは Compute Optimizer で最適と判定されている」「夜間停止は業務要件で不可」といった根拠が示されれば、それ自体が有益な情報になり、次回以降の議論の出発点になります。この項目を調達仕様書の要求水準に落とし込む方法は シリーズ②-1 で扱います。
2.4 レビュー会議のアジェンダ例（60 分）
| 時間 | 議題 | 参照章 | 主担当 |
|---|---|---|---|
| 0:00〜0:05 | 前月分の議事録・宿題事項確認 | – | 情報政策担当 |
| 0:05〜0:20 | コストレポートの共有（前月のコスト総額と要因分析） | 3.1 | 運用管理補助者 |
| 0:20〜0:35 | コスト最適化ハブの推奨事項レビュー（推定削減額・優先順位、Idle リソース対応状況） | 3.2 | 運用管理補助者 |
| 0:35〜0:45 | Compute Optimizer 推奨への対応状況、稼働時間・ストレージ最適化の進捗 | 3.3 | 運用管理補助者 |
| 0:45〜0:55 | 新規最適化提案・次回までの施策の決定 | 全章 | 運用管理補助者・情報政策担当 |
| 0:55〜1:00 | アクションアイテムの整理（担当者・期限の確認） | – | 全員 |
この会議で最低限おさえる4点
会議の時間が限られる場合でも、自治体側として次の4点は確認してください。
| # | 確認すること | 判断すること |
|---|---|---|
| 1 | 前月のコスト総額と、前月比の増減 | 増加が想定内か。想定外なら要因は何か |
| 2 | 増減の要因となったサービスと、その理由 | 一時的な要因か、今後も続く増加か |
| 3 | 未対応の推奨事項の件数と推定削減額 | 対応しない理由が妥当か（業務要件・ASP の制約等） |
| 4 | 前回のアクションアイテムの結果 | 実施できたか。できていない場合の障害は何か |
運用管理補助者に提出を依頼する資料
上記を議論するために、会議の前に以下の提出を依頼します。これらは 2.4 の準備項目と対応しており、調達仕様書の要求水準として明記しておくと、毎回の依頼が不要になります（シリーズ②-1 参照）。
| 資料 | 内容 | 対応する準備項目 |
|---|---|---|
| コストレポート | サービス別・業務別の内訳と前月比 | 1 |
| 変動要因の分析 | 増減が大きいサービスの原因と、継続性の見立て | 2 |
| 推奨事項の対応状況一覧 | 対応済み・対応予定・対応しない（理由付き）の3分類 | 3〜5 |
| 新規の最適化提案 | 削減額・作業負荷・業務影響・ASP 確認の要否 | 8 |
補足： 「対応しない」と判断した推奨事項については、その理由を記録に残すことが重要です。業務要件上サイズを下げられない、ASP の動作保証が得られないなど、理由が明確であれば監査や議会説明の際の根拠になります。逆に理由が記録されていないと、次回のレビューで同じ議論を繰り返すことになります。
レビュー会議自体のコストにも注意： 本記事が扱うのはクラウド利用料の最適化ですが、これとは別に運用管理補助委託料（運用管理補助者への委託費）という費目があり、レビュー会議は運用管理補助者の稼働を伴うため、こちらに影響します。クラウド利用料を削減できても、会議のために委託料が膨らんでは本末転倒です。GCASガイドの「継続的運用経費最適化(FinOps)ガイド」では、クラウド利用料とは別に運用管理補助委託料の最適化が扱われており、そのアプローチとして「システム利用状況は職員がダッシュボード等を用いてモニタリングするとし、事業者の定期報告頻度を削減する」ことが挙げられています。クラウド利用料の最適化に着手した直後は確認・判断すべき事項が多いため月次での開催をお勧めしますが、最適化が進み推奨事項への対応が一巡してきたら、職員自身によるマネジメントコンソールでの確認（本記事 1.2 の「自治体職員ができること」の範囲）を基本とし、会議は隔月・四半期に減らす、時間を30分に短縮するなど、委託料の観点からの見直しも検討してください。
2.5 年次レビュー時の追加確認項目
年 1 回、以下を追加で確認します：
| No | 確認項目 | 参照章 |
|---|---|---|
| 1 | RI/SPs の更新時期と効果測定 | 3 |
| 2 | ストレージライフサイクルポリシーの有効性 | シリーズ④ |
| 3 | 年間コスト推移と来年度予算への反映 | シリーズ③ |
3. コスト確認に使う AWS サービス
本章では、以下に紹介する3つのサービスをコスト最適化の確認に使います。それらについて、何を見て、どう判断するかを解説します。画面をクリックする手順そのものは Appendix にまとめており、本章と Appendix は次のように役割を分けています。
| 扱う内容 | 読み方 | |
|---|---|---|
| 第3章（本章） | 各サービスで何が分かるか、数値をどう判断するか、役割ごとの使い方 | 通して読む |
| Appendix | マネジメントコンソールの画面遷移とクリック手順（画面キャプチャ付き） | 実際に操作する際に手元で開く |
初めてマネジメントコンソールを開く際は、本章で「何のために見るのか」を把握した上で、Appendix を見ながら操作すると迷いません。すでに操作に慣れている場合は本章の判断基準だけで足ります。
3つのサービスの使い分け
3つは役割が重なる部分もあるため、先に整理します。
| サービス | 主な用途 | 見るタイミング |
|---|---|---|
| Cost Explorer | 実際にかかった費用の把握と、増減要因の分析 | 毎回。まず総額と推移を見る |
| コスト最適化ハブ | 削減余地の一覧と、優先順位付け | 毎回。次に何を削れるかを見る |
| Compute Optimizer | 個別リソースのサイジング推奨の詳細確認 | ハブでサイジング推奨を見つけたとき |
Cost Explorer は「今いくらかかっているか」、残る2つは「いくら削れるか」を示すサービスです。後者2つの関係は 3.3 で改めて整理します。
3.1 Cost Explorer
AWS Cost Explorer は、AWS の利用料を時系列・サービス別・タグ別等で可視化するサービスです。グラフの形を見るだけで、急に増えた月や右肩上がりのサービスに当たりをつけられます。
図 1: Cost Explorer の利用料グラフ
利用方法：
AWSマネジメントコンソールから「請求とコスト管理」にアクセスし、左メニューの「Cost Explorer」を開きます。
何ができるか：
- サービス別で月次のコスト推移を確認する
- フィルターを設定して特定のサービスやコスト配分タグで深掘りする対象を絞り込む
- グループ化の条件（ディメンション）を切り替えて異なる切り口でコスト増減の要因を特定する
- 任意の2か月間のコストを比較し、変動要因を特定する
- Amazon Q に日本語で質問し、対話形式でコスト分析する
Amazon Q について： Amazon Q は AWS が提供する生成 AI アシスタントです。Cost Explorer の画面上部にある「質問する」から、「先月コストが最も増えたサービスは？」のように日本語で入力すると、回答とグラフが表示されます。フィルターやグループ化の設定方法が分からない場合の入口として使えます。操作手順は Appendix A の STEP 5 を参照してください。なお、より踏み込んだ分析を AI Agent に任せる方法は シリーズ②-2 で扱います。
判断のポイント：
まず総額の推移を見て、次に増減があった場合はその要因を掘り下げます。
| 見えた状態 | 確認すること |
|---|---|
| コストが月を追って増加している | 放置してよい増加か、対策すべき増加かを判断する（データ量の自然増なら許容、リソースの追加忘れなら対処） |
| 特定の期間だけ急増している | 一時的な要因か確認し、不要なリソースが残っていれば対処する |
| 前月比で大きく増加している | リソース追加等の意図した増加か、想定外の増加かを確認する |
増減の要因を特定する手順は次のとおりです。上から順に絞り込んでいくと、どのサービスの何が原因かが見えてきます。
| 手順 | 操作 | 分かること |
|---|---|---|
| 1 | 「比較」機能で前月と先々月を比較 | 増減額の大きいサービスの順位と、上位のコスト要因 |
| 2 | 該当サービスでフィルターし、粒度を「日別」に変更 | いつから増えたのか（月中の特定日か、月初からか） |
| 3 | グループ化を「使用タイプ」に変更 | そのサービスの何が増えたのか（ストレージ容量／転送量／稼働時間など） |
| 4 | グループ化を「タグ」に変更（タグ運用がある場合） | どの業務システムの費用が増えたのか |
補足： 手順3の「使用タイプ」は
APN1-BoxUsage:m5.largeのような表記になります。意味が分からない場合は AWS サポートに問い合わせるか、運用管理補助者に確認を依頼してください。職員側では「どのサービスのどの費目が増えたか」まで絞り込めれば十分で、そこから先の技術的な原因究明は運用管理補助者の役割です。
タグによる業務別の内訳： 業務システムごとのコストを把握するには、リソースにコスト配分タグを設定しておく必要があります。タグが未設定の場合は業務別の按分ができないため、運用管理補助者にタグ付けの実施を依頼してください（タグ設計は シリーズ④ で扱います）。
活用パターン（役割別）：
- 自治体職員（情報政策担当）：前月の請求額確定後に前々月と前月を比較し、気になるコスト変動をレビュー会議の議題として準備する
- 運用管理補助者：コストレポート（サマリー/アカウント別内訳/サービス別内訳/変動要因のリスト）を作成する
- ASP・ベンダー：コスト変動要因の分析やコスト最適化の進捗状況の確認に役立てる
詳細手順: Appendix A
3.2 コスト最適化ハブ
コスト最適化ハブは、AWS アカウント全体のコスト最適化推奨を一元集約するサービスです。リソースの適切なサイジング、アイドル状態のリソースの削除、RI/SPs の購入推奨など、複数ソースの推奨を一つの画面で確認でき、何から手をつけるべきかの優先順位付けができます。
図 2: コスト最適化ハブの潜在的な削減額
利用方法：
AWSマネジメントコンソールから「請求とコスト管理」にアクセスし、左メニューの「コスト最適化ハブ」を開きます。
何ができるか：
- 潜在的な削減額の合計を一目で把握する
- 推奨を削減額順にソートし、優先度の高いものから確認する
- 推奨の種類（サイズの適正化 / 不要リソースの削除 / RI/SPs の購入等）でフィルターする
- 各推奨の作業の容易さを確認し、優先順位を付ける
判断のポイント：
推奨は「毎月の推定削減額」と「実装作業の負荷」の2軸で整理します。ただしどの推奨であっても、実施前に業務影響の確認は必要です。作業負荷が低いことは「業務影響が小さいこと」を意味しません。例えばインスタンスタイプの変更は操作自体は数分で終わりますが、パッケージの動作保証に関わるため ASP の確認が必要です（1.2 参照）。
| 削減額 | 作業負荷 | 対応の方針 |
|---|---|---|
| 大きい | 非常に低い〜低い | 業務影響を確認した上で優先的に実施する |
| 大きい | 中以上 | 業務影響と作業計画を評価し、計画的に実施する |
| 小さい | 非常に低い〜低い | まとめて一括で実施する。個別に会議で議論するとかえって工数がかかるため、運用管理補助者の裁量で進められる範囲を事前に取り決めておくとよい |
| 小さい | 中以上 | 当面は保留とし、他の作業と合わせて実施できる機会を待つ。保留の判断も記録に残す |
補足： 削減額が小さい推奨は件数が多くなりがちです。一件ごとに判断していると会議が終わらないため、「未使用リソースの削除は運用管理補助者の判断で実施し、結果を報告する」といった運用ルールをあらかじめ決めておくことをお勧めします。
活用パターン（役割別）：
- 自治体職員（情報政策担当）：ダッシュボードで推定削減額の合計と件数を確認し、今月の削減余地としてレビュー会議に持ち込む
- 運用管理補助者：推奨を作業の負荷・削減額で優先順位付けし、対応計画をレビュー会議で自治体と合意する
- ASP・ベンダー：推奨事項を確認し、自治体と合意した最適化施策を実行する
詳細手順: Appendix B
3.3 Compute Optimizer
AWS Compute Optimizer は、Amazon EC2 インスタンス・Amazon EBS ボリューム・Amazon RDS 等の利用状況を Amazon CloudWatch メトリクスに基づき機械学習で分析し、最適なリソースサイズを推奨するサービスです。
コスト最適化ハブとの関係
コスト最適化ハブにもサイジングの推奨が表示されるため、両者の違いが分かりにくいところです。実際、コスト最適化ハブに表示されるサイジング推奨は Compute Optimizer が算出したものが取り込まれており、推奨の内容そのものは同じです。違いは粒度と情報量にあります。
| コスト最適化ハブ | Compute Optimizer | |
|---|---|---|
| 範囲 | サイジング推奨に加え、未使用リソースの削除、RI/SPs の購入推奨など複数の種類を集約 | コンピューティングリソースのサイジング推奨に特化 |
| 粒度 | 削減額と作業負荷による優先順位付け（一覧での俯瞰） | リソース単位の推奨候補、変更前後のメトリクス、パフォーマンスリスク |
| 主な用途 | 「今月はどこから手をつけるか」の判断 | 「このリソースを実際にどのサイズに変えるか」の判断 |
使い分けは次のようになります。まずコスト最適化ハブで削減余地の全体像と優先順位を把握し、サイジング推奨に着手する段になったら Compute Optimizer で個別リソースの詳細（推奨候補の比較、パフォーマンスリスク）を確認します。職員側の定期点検ではコスト最適化ハブでの件数確認までで十分なことが多く、Compute Optimizer は運用管理補助者が変更内容を検討する際、および職員が推奨の妥当性を確認したい場合に開くサービスと考えてください。
図 3: Compute Optimizer の EC2 インスタンスの適切なサイズ設定の推奨事項
利用方法：
AWSマネジメントコンソールから「Compute Optimizer」を検索してアクセスします。
何ができるか：
- リソースごとの判定結果（最適化済み / 過剰なプロビジョニング / プロビジョニング不足）を確認する
- 推奨3案（オプション1/2/3）を比較し、コスト削減額とパフォーマンスリスクを天秤にかける
- EC2 以外にも EBS ボリュームや RDS の最適化推奨を確認する
判断のポイント（例：EC2インスタンスの適切なサイズ設定）：
- 過剰なプロビジョニングかつパフォーマンスリスクが低い → サイズダウンを検討
- プロビジョニング不足 → 性能問題が発生する前にスケールアップを検討
活用パターン（役割別）：
- 自治体職員（情報政策担当）：過剰なプロビジョニングの件数を定期的に追跡し、改善の進捗を確認する
- 運用管理補助者：推奨3案を比較し、パフォーマンスリスクと削減額のバランスから最適な変更先を提案する
- ASP・ベンダー：インスタンスの推奨を確認し、ライトサイジングの実施計画を自治体に提案する
詳細手順: Appendix C
4. まとめ — 継続的改善に向けて
4.1 本記事のポイント
本記事では、AWS を利用する自治体が定期的に実践するコスト最適化の手順を解説しました。
持ち帰っていただきたい判断基準は次の4点です。
- 確認できる範囲と依頼が必要な範囲は分かれている。インスタンスタイプやストレージ種別の変更は ASP の動作保証確認が前提になる（1.2）
- 前月比 ±10% 以上の変動があれば要因を特定する。「比較」機能から日別・使用タイプへと絞り込む（2.3、3.1）
- 推奨事項は削減額と作業負荷の2軸で仕分ける。ただしどの推奨でも業務影響の確認は必要（3.2）
- 「対応しない」と判断した推奨は、理由を記録に残す。監査や議会説明の根拠になる（2.4）
4.2 協働による効果
レビュー会議を何度か回すと、請求額の内訳を自分の言葉で説明できるようになります。そうなると、運用管理補助者からの報告を受け取るだけの関係から、数値を挟んで具体的に相談できる関係に変わります。
自治体職員が数値を確認して可否を判断し、必要な作業を依頼する。運用管理補助者が要因を分析して施策を提案し、合意を得て実施する。この往復を定期的に回しながら、削減を積み重ねていってください。
4.3 シリーズの他記事との接続
本記事は「確認して判断する」ところまでを扱いました。その先は次の記事が引き受けます。
- シリーズ②-1『運用管理補助者との協働体制を調達仕様書に落とし込む』: 本記事の手順を組織的に運用する体制づくり、調達仕様書への反映
- シリーズ②-2『AI Agent でコスト分析を自動化する』（公開予定）: 本記事のツールを AI Agent と組み合わせ、AWS 経験が浅い職員でも会話形式で活用する実践事例
- シリーズ③『予算要求・執行・決算の実務』（公開予定）: 本記事で削減した成果を次年度予算に反映する方法
- シリーズ④『20業務の最適化設計と実践』（公開予定）: 本記事の手順を運用管理補助者視点で具体化した実践例
免責事項: 本記事の内容は情報提供を目的としたものであり、特定の環境や要件に対する推奨を保証するものではありません。実際の削減効果は個別の環境・構成により異なります。AWS サービスの料金は変更される場合がありますので、最新の料金情報は AWS 料金ページ をご確認ください。
ガバメントクラウドに関するご相談: ガバメントクラウドの利活用に関するご質問やご相談は、AWS ガバメントクラウド相談窓口 までお問い合わせください。
Appendix: 各サービスの操作手順
第3章で示した「何を見て、どう判断するか」を実際のマネジメントコンソールで行うための、画面遷移とクリック手順をまとめます。初めて操作する際は、この Appendix を開きながら進めてください。
マネジメントコンソールの画面構成は更新されることがあるため、本 Appendix のキャプチャと実際の画面が異なる場合は、メニュー名を手がかりに読み替えてください。
Appendix A: Cost Explorer 詳細手順
A.1 画面への遷移手順
- AWS マネジメントコンソールにサインイン
- 画面上部の検索バーに「Cost Explorer」と入力、または画面右上のアカウント名をクリックし「請求とコスト管理 (Billing and Cost Management)」を選択
- 左側のナビゲーションメニューから「Cost Explorer」を選択
A.2 基本操作の手順
STEP 1：まず全体像を見る
Cost Explorer を開くと、デフォルトで過去6か月分のコスト推移が棒グラフで表示されます。画面右上のレポートパラメーターの日付範囲が過去6ヶ月間、粒度が月別、グループ化の条件（ディメンション）がサービスになっていることを確認します。これが基本画面です。
図 A-1: Cost Explorer の利用料グラフ
確認のポイント： 特定のサービスが月を追うごとに右肩上がりに増えていないか、ある月だけ突然スパイク（急増）していないかを確認します。
STEP 2：気になる対象を絞り込む
STEP 1で右肩上がり、またはスパイクしているサービスが見つかったら、画面右側のフィルターでその対象のサービスだけに絞り込みます。これで対象が明確になります。この例ではFSxでフィルターしています。
図 A-2: 表示対象をフィルター
確認のポイント： 絞り込んだグラフで、増加が一時的なものか・継続しているのかを見ます。
STEP 3：粒度やディメンションを変えて深掘りする
対象サービスを絞り込んだ状態で、粒度を「月別」から「日別」に切り替えます。また、グループ化の条件（ディメンション）を「使用タイプ」に切り替えます。そして、グラフの種類を折れ線グラフにします。これでいつからどのようなアクションによりコストが増えたのかが見えてきます。今回の場合、APN1-ThroughputCapacity.MultiAZやAPN1-Storage.MultiAZ:SSDが増加しています。これは、FSx for Windows File Serverのマルチ AZ 配置でのスループットキャパシティやストレージに基づくコストで、12月中旬から徐々に増えていることがわかります。
図 A-3: ディメンションやグラフの種類を変えて詳細を深掘り調査
活用のポイント： グループ化のディメンションを切り替えると、グラフの色分け基準を変えることができます。同じコストでも違う切り口で可視化することで原因が見えてきます。例えばディメンションを「使用タイプ」や「APIオペレーション」にすると、そのサービスの中でタイプ別・操作別に色分けされ、どの費目で増えたかを切り分けられます。また、グラフの種類（棒グラフ／折れ線グラフ／積み上げ棒グラフ）を変えるとトレンドが掴みやすくなる場合もあります。それぞれの使用タイプが何を表すかご不明な場合はAWSサポートへお問い合わせください。
STEP 4：先月と先々月を比較して変動要因を特定する
Cost Explorer 右上の「比較」を選択します。任意の2か月を並べられ、デフォルトでは先月と先々月が対象になります。画面には各サービスの金額・増減比率と、増減の上位要因が一覧で表示されます。グラフを深掘りして読み取るよりも早く変動の原因にたどり着けます。
図 A-4: 比較機能による前月と前々月のコストの比較
確認のポイント： デフォルトでは増減割合が大きいサービスから順に並んでいます。画面下部の表の「表示する」ボタンからそのコスト比較要因のグラフを表示することもできます。
STEP 5：Amazon Q に質問する
フィルターやグループ化の設定に迷ったときは、Amazon Q に日本語で尋ねる方法があります。画面上部の「質問する」から入力すると、回答とあわせてグラフが自動で更新されます。
図 A-5: Amazon Q を利用した自然言語クエリ
Appendix B: コスト最適化ハブ 詳細手順
B.1 ダッシュボード画面の確認
コスト最適化ハブのトップ画面では、潜在的な削減額の合計、推奨事項の件数、推奨の種類別の内訳が一目で確認できます。「機会を見る」を押すと、具体的な推奨事項が表形式で表示されます。各推奨行をクリックすると詳細画面が開き、対象リソースを扱うサービスの画面へのリンクが示されます。
図 B-1: 推奨事項の詳細
B.2 推奨の優先順位付けの考え方
推奨は表にある「毎月の推定削減額」と「実装作業の負荷（作業の難易度）」の2軸で優先順位を判断します。
| 優先度 | 条件 | 例 |
|---|---|---|
| 高（即実施） | 削減額が大きく、実施難易度が「非常に低い(Very low)〜低い(Low)」 | 未使用 EBS ボリュームの削除 |
| 中（計画的に） | 削減額が大きいが、実施難易度が「中(Medium)」 | インスタンスタイプの変更 |
| 低（検討） | 削減額が小さい or アプリケーションの互換性確認が必要 | 実行環境の変更を伴う最適化（ASP の動作保証確認が必要なもの） |
Appendix C: Compute Optimizer 詳細手順
C.1 EC2 インスタンスの推奨確認
C.1.1 画面遷移
- Compute Optimizer の左メニューのレコメンデーションから対象を選択
- 推奨事項の一覧が表示される
図 C-1: 推奨事項の一覧