Amazon Web Services ブログ
自治体のためのクラウドコスト最適化 ③:予算要求・執行・決算の実務
「自治体のためのクラウドコスト最適化」シリーズについて
自治体がガバメントクラウド上で業務システムを運用する場合、クラウド利用料の管理はオンプレミスとは性質の異なる実務になります。従来は、機器を調達した時点で費用がほぼ固定され、その後の管理は保守契約の範囲で済みました。クラウドは使った分だけ課金されるため、構成を変えれば費用も変わります。移行しただけでは費用は下がらず、稼働後に構成を見直し続けることで効果が出ます。
ところがこの見直し作業は、技術的な判断を伴うため日々の運用を担う事業者に委ねられがちです。結果として、自治体側に判断の材料が届かないまま請求額だけが確定していくことがあります。クラウド利用料は自治体の予算から支出され、住民や議会に説明する主体は自治体です。本シリーズは、自治体が自らクラウド費用を把握し、事業者と協働して最適化を続けられる状態を目標にしています。
ただしコスト最適化は、コンソールで数値を確認する日々の運用から、調達仕様書への反映、予算要求・決算の手続き、システム基盤そのものの設計まで、性質の異なる複数の作業で成り立っています。これらは担い手も検討のタイミングも異なるため、本シリーズでは領域ごとに記事を分けています。
| # | タイトル | 扱う領域 | 自治体職員 | ベンダー | ||
|---|---|---|---|---|---|---|
| 情報政策 担当 |
財政担当 | 運用管理 補助者 |
ASP | |||
| ① | 定期レビューで回すコスト最適化の手順 | 日々の運用 | ● | ○ | ● | ○ |
| ②-1 | 運用管理補助者との協働体制を調達仕様書に落とし込む | 調達・契約 | ● | ○ | ○ | ○ |
| ②-2 | AI Agent でコスト分析を自動化する(公開予定) | 運用の効率化 | ● | ○ | ○ | |
| ③ | 予算要求・執行・決算の実務(本記事) | 予算・会計 | ○ | ● | ||
| ④ | 20業務の最適化設計と実践(公開予定) | 基盤の設計 | ○ | ● | ● | |
補足: ②-2、④は今後公開予定です。公開時にはこの表からリンクします。
●は主な対象、○は関連する範囲で参考になる読者です。
- 情報政策担当:情報システム部門でクラウド環境の運用を所管する職員
- 財政担当:予算要求・執行・決算の手続きを担当する職員
- 運用管理補助者:ガバメントクラウドの運用管理を自治体から受託する事業者
- ASP:業務システム(パッケージ)を提供し、その動作保証を担う事業者
どこから読むか:情報政策を担当される方は①から、財政を担当される方は③から始めてください。運用管理補助者・ASP の方は④が中心になります。
本記事について
シリーズ②-1では、GCASガイド「継続的運用経費最適化(FinOps)ガイド」において、クラウドサービスの利用実績の可視化、削減提案、翌事業年度の改善提案・目標設定等に取り組むこととされていることを紹介しました。これらを実現するためには、運用管理補助者・ASP、政策担当原課、情報システム部門、財政部門が各々の立場で役割を果たすことが必要になります。
そこで今回は、クラウドコストの予算管理等をテーマとし、特に、財政部門の皆さまがクラウド経費の予算査定・執行管理を行う際の実務的な視点で記載しています。
目次
1. はじめに ― 従量課金等のクラウドサービスの特徴に伴う運用の違い
1.1 クラウドサービス利用料の特徴
自治体の予算制度は単年度が原則です。従来のオンプレミス方式(庁舎内又はデータセンターにサーバーを設置する方式)では、5年リースの契約時に年間費用が確定し、リース料を長期継続契約や債務負担行為により複数年にわたる経費の平準化と予算の見通しを確保してきました。
一方、クラウドサービスは初期投資不要/従量課金で利用できる特性を有するため、システム利用状況に合わせて無駄なく利用できる一方、予算の編成や執行等において、従来のオンプレミスとは異なる運用が必要になります。例えば、AWSのクラウドサービスの利用料には、次のような特徴があります。
- 従量課金:使った分だけ請求される仕組みであり、月ごとに金額が変動します。繁忙期(確定申告時期等)にはリソースを拡張し、閑散期には縮小することで無駄を抑制できます。
- USD(米ドル)建て:ガバメントクラウド(AWS)の利用料は米ドルで計算されるため、為替レートの変動が円換算後の支出に影響します。なお、為替を固定する契約方式も選択肢として存在します。
- 運用中のリソース最適化・コスト最適化が可能:オンプレミスでは契約更新時にしかコスト見直しができませんが、クラウドでは稼働中に随時リソースの追加・削減が可能です。
つまり、クラウドの予算管理では「予算要求時の見積もり精度」と「年度途中の予実管理」の双方が重要になります。
1.2 クラウドの特性を踏まえた新たな予算管理の考え方
また、オンプレミスの情報システムの構成をそのままクラウドに移行する「単純リフト」では、クラウドの特性を活かしきることができず、サーバーの規模が過大なまま稼働するなどにより、利用料がオンプレミス時代を上回るおそれがあります。デジタル庁による先行・検証事業等においても、単純移行ではコスト増となる事例が報告されています。
こうしたなか、財政部門としては、予算査定の際に「コスト最適化計画」の実行状況を確認することが有効となります。クラウドの費用対効果を発揮するには、移行後にコスト適正化(不要リソースの削減、サーバー規模の見直し等)を継続的に実施することが重要になります。デジタル庁が整備しガバメントクラウドに関する情報を提供しているGCASガイドにおいても、本番稼働後に継続的なコスト最適化へ取り組むことの重要性が示されています。
1.3 コスト最適化への取組
クラウドは本番稼働後がコスト最適化のスタート地点です。財政課としては、最適化の取組が継続的に行われているかを経年の予算査定や四半期報告の中で確認することが考えられます。従来、運用経費としてまとめられている経費の詳細な内訳、費目、区分が判然とせず、算出することも困難な状況にありました。しかし、クラウドサービスの特徴と、AWS Cost Explorer、AWS Budgets 等の管理ツールにより、リアルタイムで状況を可視化できます。毎月の従量課金の請求を踏まえることで、どのサービスを、どのように活用しているのか、関連する運用の人件費との切れ目はどうなっているのか、工数・人月・単価は適切かどうか、人件費のほかシステムやサービス利用料以外が過大になっていないかなどを精査できるようになります。
例えば、クラウド利用料だけを見ると「新規コストが発生した」ように見える場合であっても、オンプレミス時代には「見えにくい形」で発生していた「隠れたコスト」を含めた総保有コスト(TCO)で比較すると、クラウド移行によりシステム全体のコストが削減されているケースもあります。
(隠れたコストの例)
- データセンターの電気代・空調費(施設管理費の中に含まれていたもの)
- 職員がサーバー管理に費やしていた工数(人件費の中に含まれていたもの)
- 5年ごとのハードウェア更新費用(更新年度に一括計上されていたもの)
- 災害対策用のバックアップ設備投資
このように、コスト最適化の取組によりクラウドサービスに適した運用管理を実施していくためには、事業者(ASP/運用管理補助者)も含め、各部門が連携するスキームを確立して運用することが重要です。また、各部門の役割分担と報告ルート(情報システム部門→原課→財政課)を予め明確にしておくことで、PDCAサイクルに基づく継続的なコスト適正化が実現します。
また、例えば、情報システム専任部署を持たない小規模団体においては、ASP事業者からの月次コストレポートを受領することを基本とし、四半期ごとに財政担当が確認するという簡易な運用から始めることも方法のひとつです。この場合、ASP契約仕様書において、コストレポート(利用量・費用明細)の月次提出義務を含めておくことが考えられます。
なお、このコスト最適化には、予算を縮減することばかりが含まれるのではなく、より適切なサービスを利用するため、あるいは、より適した人材をアサインするために予算の枠内で割り当てを再分配したり、必要な経費等を増加させることも含まれる点にご留意ください。
(参考) 利用方式や環境によっては、AWS マネジメントコンソール(AWS Cost Explorer、AWS Budgets 等を含む)の閲覧権限が自治体職員に付与される場合があり、従来はASP(事業者)経由でしか確認できなかったコスト情報を、自治体職員が自ら確認できる事例も出ています。閲覧権限の付与を運用管理補助者に求める際の調達仕様書の記載例は、シリーズ②-1 の 3.1 で紹介しています。
以降、自治体の予算サイクル(予算要求→執行→決算)に沿って、クラウドコストの管理方法を具体的に解説します。
図: クラウドコストと自治体の予算サイクル(括弧内は本記事の対応章)
2. 年度予算要求時のコスト見積もり
原課又は情報システム担当から提出されるクラウド利用料の予算要求書を査定する際に、財政課が確認するとよいポイントを解説します。なお、ガバメントクラウドの利用形態は「共同利用方式」と「単独利用方式」に大別され、それぞれ見積もり精査のポイントが異なります。本記事では主に共同利用方式を念頭に記載しますが、単独利用方式の場合は、AWS アカウント内のリソースがすべて自団体の費用等となるため按分が不要となり、見積もりにおいて、共同利用方式と比較して考慮事項等が少ない特徴があります。
2.1 移行初年度の見積もり
ガバメントクラウドへの移行初年度は、過去の実績データがないため、見積もりの難度が最も高い年度です。主に、AWS Pricing Calculator を用いて概算を行います。現行システムの構成(サーバー台数、CPU/メモリ/ディスク等)を整理し、対応するAWSサービスにマッピングして試算します。また、デジタル庁がGCAS上で提供する利用料比較の仕組み(提供状況・利用方法はデジタル庁の案内をご確認ください)を活用し、人口規模や業務内容が類似する他団体の利用実績を参考値(メルクマール)とすることで、見積もりの妥当性を検証することも重要です。財政部門が予算査定を行う際は、これらの比較データの提示を求めることが有効です。
また、クラウドへの移行完了までの既存システム運用費が見落とされてしまうと、システム停止を余儀なくされてしまう可能性があります。このような移行過渡期に係る費用についても適切に計上されていることを確認してください。なお、クラウド移行に当たっては、テスト環境の稼働、一時的なスケールアップ、想定外のデータ転送等のコストの考慮も必要になります。提供する行政サービス等の停止等を防ぐためにも、初めてのシステムの移行は抜け漏れなく慎重に、かつ従量課金を加味してバッファを持つことが考えられます。そのため、類似する、あるいは先行する同規模の事例を参照した上で、初年度は特に余裕を持った予算を確保することを推奨します。
| 確認項目 | 主なチェックポイント |
|---|---|
| 見積もり根拠 | AWS Pricing Calculator 等のツールを使った試算結果が添付されているか |
| スペック | インスタンスサイズ(サーバー規模)が現行システムの実使用量に対し適正か。類似規模の他団体における実績値と大きく乖離していないか |
| クラウド利用料・移行スケジュール | ・何月からクラウド利用料が発生するか(月数 × 月額で積算されているか) ・テスト環境稼働から移行完了後年度末までの月数分が適切に計上されているか |
| 移行作業費 | データ移行、環境構築、テスト等に要する作業費用が適切に計上されているか |
| 環境稼働 | ・テスト環境の稼働時間が限定されているか(24時間稼働は不要) ・共同利用方式の場合、運用管理部分(監視・バックアップ等)及びネットワーク部分の費用が適切に按分されているか ・開発環境・テスト環境が移行計画に沿ったタイミングで縮退・終了される計画となっているか(稼働後も残存していないか) |
| 並行稼働費 | 移行完了までの既存システム運用費が適切に計上されているか |
| 為替考慮 | 為替変動と為替固定の双方の契約方式における費用や差異を比較しているか |
査定のコツ: 初年度は「不確実性が高い」ことを前提に、予算を認める代わりに「四半期ごとの実績報告」を条件として付すことで、執行段階での管理を担保できます。
2.2 2年目以降の見積もり
2年目以降は、前年度の実績データが最も信頼できる見積もり根拠になります。
見積もり手順:
- 前年度の月別利用実績(USD)をAWSの請求データから取得します。
- 季節変動(確定申告時期の負荷増、年度末処理等)による増減を考慮します。
- 新規サービスの追加・既存サービスの廃止の影響を加味します。
- 前年度に実施したコスト最適化施策の通年効果(年度途中の実施分を12か月に拡張)を反映します。
- 為替レートを設定してJPYに換算します。
- 予見し難い環境変化への対応に要する経費として予備的な経費を上乗せします。なお、予算査定においては、予備的な経費分の予算については執行保留分とする運用も考えられます。いずれにせよ、予備的な経費の設定にあたっては根拠の明示が重要です。
(参考)計算例:前年度の月平均利用額が$4,200の場合、通年換算で$50,400。変動要因(+$5,100)と最適化効果(▲$4,800)を加味すると$50,700。レート160円/USDで換算すると約811万円。予備的な経費として仮に12%(97万円)を加えると、予算要求額は908万円となります(12%は計算のための仮の値です)。
長期利用割引(リザーブドインスタンス・Savings Plans)を適用している場合、または適用を予定している場合の予算上の扱いは、Appendix で補足しています。
| 確認項目 | 主なチェックポイント |
|---|---|
| 前年度実績 | 月別実績データ(USD)が添付されているか。根拠のない増額要求になっていないか |
| 変動要因 | 増額の場合:具体的な理由(利用者増、新機能追加等)が示されているか |
| 最適化効果の反映 | 前年度の削減施策の効果が次年度見積もりに反映されているか(反映されていなければ過大) |
| リスク予見・予備的な経費 | 過去1年間の実際の変動幅に対して上乗せ幅が過大でないか(2年目以降も初年度と同じ上乗せ幅のままになっていないか) |
3. 年度途中のコスト変動への対応
情報システム担当または原課から四半期ごとに報告を受ける際、次の観点で確認します。
| 確認項目 | 主なチェックポイント |
|---|---|
| 予算消化率 | 経過月数に対し、許容範囲であるかどうか |
| 年度内の予算消化 | 予算内に収まる見通しかどうか |
| 為替の影響 | 実績が予算レートを上回っている場合、予算の枠内に収まる見込みかどうか |
| 最適化の取組 | 施策が実施されているか(「特になし」は要確認) |
3.1 AWS Budgets による予算設定・予算超過の防止
GCASガイドの予実管理では、AWS Budgets に月次予算を設定することとされています。年間予算額(USD)を利用月数で除算して月次予算額を算出しつつ、季節変動を考慮し、繁忙月(確定申告時期の1〜3月等)は多めに、閑散月は少なめに配分されていることを確認してください。これらの設定を行うことで、予算超過が見込まれる場合に事前アラートにより早期検知と対策が可能になります。アラートの主な設定方法としては、①AWS Budgetsにより閾値を設定して予算上限超過を監視する、②AWS Cost Anomaly Detectionによりコスト急騰などの異常検知を行う、の2つが挙げられます。
アラートが発報された場合の原課の主な対応は、次のとおりです。
- 設定ミスや不要リソースの放置であれば即時是正
- 月末までと年度末までの累計見込みを算出し、意思決定権者に報告
予算超過が見込まれる場合に事前アラートの通知先に、財政課を含めておくことで、財政課側から対応を指示することが可能となり、早期の対策による予算超過の予防にも繋がります。
図: (参考)AWS Budgets と AWS Cost Anomaly Detection による予算超過・異常の検知
3.2 執行残発生時の扱い
従量課金では、利用が少なかった場合に執行残が発生します。発生要因には、次のようなケースがあります。
- コスト最適化施策の成果(積極的な取組の結果)
- 想定より利用量が少なかった(利用者数が見込みを下回った等)
- 為替レートが有利に推移した(外部要因)
- 見積もり時の予備的な経費の設定が過大だった
このうち、最適化の成果による執行残は、クラウドサービス及びFinOpsの活動の優れた成果になります。一方で、執行残が発生したことを理由に、翌年度予算を機械的に削減することにはリスクもあります。最適化の取組の再現性の検証、関連システムも含めた全体最適としての運用の確認等、次年度以降の変動事由の考慮等を踏まえる必要があります。そこで、最適化の効果が生じた翌年度(N+1年度)は、効果が継続しているかを検証する期間とし、効果が定着したことを確認できた段階で、翌々年度(N+2年度)の予算の見直しに反映するといった段階的な扱いも考えられます。政策目的に照らした適切なシステム運用等を目指しつつ、原課の意欲を最大限発揮することが可能な仕掛けで、FinOpsと効果検証を着実に進めることが重要です。
また、クラウドサービスの強みは、柔軟な機能拡張やログ分析基盤をスピーディに構築し、最新技術の短期間の試験運用等が可能である点です。これらは、住民サービスの向上、DXの加速化、セキュリティ強化にも直結するものであり、さらなる利便性と安心の好循環を生み出すことが期待されます。また、平時の運用管理やシステム/サービスを活用した執務の遂行について、更なる業務効率化に向け、最新のデジタル技術やAI等の活用を図ることも効果的です。
そのため、最適化の取組等により発生した執行残について、予算活用の短期・中期の運用サイクルとして、本来的な政策目的等を含め、原課・情報システム課・財政課その他の関係機関で認識合わせを行うことが重要です。その際、例えば、予算執行のルールの範囲内において、執行残をうまく活用しつつ、FinOpsの結果の定性化や最新技術の試用や実証実験等への活用を選択肢の一つとして検討することで、コスト最適化の取組を継続する動機付けにもなり得ると考えられます。
4. まとめ
以上、クラウドコストの予算管理をテーマとし、クラウド経費の予算査定・執行管理を行う際の実務的な視点についてご紹介いたしました。
繰り返しになりますが、クラウドは本番稼働後がコスト最適化のスタート地点です。クラウドサービス利用料の適正化によるコスト削減に努めつつ、柔軟な機能拡張やログ分析基盤をスピーディに構築し、最新技術の短期間の試験運用等を通じて、住民サービスの向上、DXの加速化、セキュリティ強化に取り組むことが期待されます。クラウドサービスの利用実績の可視化、削減提案、翌事業年度の改善提案・目標設定等のサイクルを効果的に実施することで、デジタル技術を使いこなし、効率的な行政運営と豊かで便利な社会を実現していただければと存じます。
より詳しく知りたい方へ
本記事で扱わなかった日々のコスト確認や調達仕様書への反映などは、シリーズの他の記事で解説しています。
| やりたいこと | 参照先 |
|---|---|
| 定期的なコスト確認の手順・チェックリストを知りたい | シリーズ① |
| 調達仕様書へのFinOps要件の反映方法を知りたい | シリーズ②-1 |
| 生成 AI を使ったコスト確認の効率化を知りたい(公開予定) | シリーズ②-2 |
| 運用管理補助者・ASPとして具体的に何をすべきか知りたい(公開予定) | シリーズ④ |
Appendix
長期利用割引(リザーブドインスタンス・Savings Plans)の予算上の扱い
AWSには、一定期間(1年又は3年)の利用を約束(コミット)することで割引を受けられる仕組みがあります。これは、自治体が複合機やコピー用紙を「年間契約」することで単価が下がるのと同じ考え方です。
- 通常利用(従量課金):毎月、使った分だけ定価で請求されます。
- 長期利用割引適用後:Savings Plans は「1時間あたりの利用金額(USD)」、リザーブドインスタンスは「インスタンスの種類と台数」を単位としてコミットし、コミット分には割引単価が適用されます。コミットを超えた利用分は通常の従量課金単価で請求されます。
購入・設定の流れ
ガバメントクラウドでは、リザーブドインスタンス・Savings Plans のいずれも、自治体と合意した内容に基づいて運用管理補助者が購入・設定します。財政部門としては、購入の時期・期間・コミットの水準が予算と整合しているかを、情報システム担当とあらかじめ確認しておくことが考えられます。コミットは期間中の変更・取消が原則できないため、確実に利用する水準で設定することが重要です。購入時期の考え方は、シリーズ①の 2.2 で紹介しています。
- 自治体が過去の利用実績を基に、確実に利用する最低水準のコミット額を算出します。
- デジタル庁に対して長期利用割引の適用を申請します。
- デジタル庁が申請を取りまとめ、一括で割引を購入・適用します。
- 割引効果が自治体の月次利用料に反映されます。
※ コミットは期間中の変更・取消が原則できないため、確実に利用する最低水準で設定することが重要です。申請手続きの詳細や最新の運用は、デジタル庁の案内をご確認ください。
免責事項: 本記事の内容は情報提供を目的としたものであり、特定の環境や要件に対する推奨を保証するものではありません。実際の効果は個別の環境・構成により異なります。AWS サービスの料金は変更される場合がありますので、最新の料金情報は AWS 料金ページ をご確認ください。
ガバメントクラウドに関するご相談: ガバメントクラウドの利活用に関するご質問やご相談は、AWS ガバメントクラウド相談窓口 までお問い合わせください。

