本文へ移動

コスト上の課題とコスト最適化のポイントは?(共創PFキャンプin広島 ガバメントクラウド編)

共創プロットフォーム参加者である3名の男性がPC画面をのぞき込む様子の写真。写真左上に「ガバメントクラウド」の記載、右上にデジタル庁ニュースのロゴ。下部には、「潜入!共創PFキャンプ コスト最適化のポイントとは?」の文字。

目次:

2025年7月24日、デジタル庁は広島市で「共創PF(プラットフォーム)キャンプ」を開催しました。 デジタル改革共創プラットフォーム(共創PF) は、地方公共団体や政府機関の職員が自由に意見を交わせるオンライン上のコミュティです。また、「共創PFキャンプ」と題して、年に数回オフラインの勉強会も実施しています。

7月の勉強会では、ガバメントクラウドのコスト最適化のアプローチを実践的に学ぶワークショップを実施。中国地方を中心に、ガバメントクラウド導入を目指す19自治体から28人が参加し、デジタル庁ガバメントクラウド班の職員が解説・講師を担当しました。この記事では、主に地方公共団体の方を想定し、勉強会の内容を紹介します。

●当日の様子は、デジタル庁ニュースの動画でもご紹介しています。あわせてご覧ください。

コスト最適化に向けた実践ポイント(担当:ガバメントクラウド班・武田)

共創PFキャンプin広島 ガバメントクラウド編の様子。スクリーンに映し出された画面を参加者たちが眺めている。
(共創PFキャンプ in 広島 ガバメントクラウド編の様子)

この記事では、当日のコスト最適化ワークショップの中から、ガバメントクラウドのコスト最適化のアプローチを検討する上で、すぐに実践できるものをアプローチガイドにあるポイント3点を紹介します。今回は、参加自治体の大半がアマゾン ウェブ サービス(AWS)を利用していたことから、AWSを題材としています。

1.インスタンスを適正化する

クラウド環境では、仮想サーバのスペックがコストに直結します。ただ、適切なクラウド利用をすることで、十分にコストを下げられる余地があります。そこで、仮想サーバに割り当てるインスタンスタイプを適正化し、費用を抑えることができます。
コスト最適化アプローチの解説のスライド。「r5a.2xlarge」というインスタンスタイプの場合、「r」はインスタンスファミリー(仮想マシンの用途・特性の表記)、「5」はインスタンス世代(インスタンスの世代番号。数字が大きい方が新しい世代)、「a」はオプション(cpuのメーカーや、その他オプション記号。iはintel製CPU、aはAMD製CPU)、「2xlarge」はインスタンスサイズ(コア数とメモリ数の組み合わせたサイズ表記)を表す。
(インスタンスタイプについて)

インスタンスタイプは、たとえば「r5a.2xlarge」のように表記されます。コスト最適化で重要な二つの項目について説明します。

最初のアルファベットはインスタンスファミリーの項目で、用途や特性を表します。例の「r」はメモリをよく使うシステムに向いています。この他、CPUとメモリのバランスが良い汎用向けの「m」、CPUを多く搭載した「c」などがあります。

「2xlarge」の部分はインスタンスサイズの項目で、コア数とメモリ数を組み合わせたサイズの表記です。「large」「xlarge」「2xlarge」「4xlarge」と大きくなるにつれて、CPUコア数やメモリ容量とともに費用も増えていきます。

インスタンスサイズは、まずCPUやメモリをサイジングし、それに基づいて決めていくことが基本です。ポイントとなるCPU利用率は、7割~9割が目安です。ぎりぎりを攻めていただくとコスト効果は高くなりますし、「仮決め」をしてから必要に応じてサイズを調整するアプローチが有効です。

また、メモリもコストに影響します。インスタンスファミリーは汎用性が高い「m」を出発点に考え、メモリ容量が多すぎる場合は「c」のインスタンスタイプを、不足する場合は「r」のインスタンスファミリーを選び、必要量を満たすようにします。

2.稼働時間のコントロール

コスト最適化アプローチの解説のスライド。稼働時間最適化によるコスト効果と対策の業務影響を勘案し、バランスの取れた稼働時間の最適化を行うことが肝要です。業務影響が低い順に「開発/テスト/検証環境:利用時間以外の停止(夜間や休日の停止)」、「本番環境:年間の中で特定の期間しか利用しないシステムの停止」、「本番環境:利用頻度が低い業務影響のないサーバーの停止(例:本番アクセス用の踏み台サーバの利用時のみの稼働)」、「本番環境:特定の時間帯しか利用しない業務系サーバー(例:夜間バッチ処理にのみ利用するバッチサーバの日中停止)」、「本番環境:サービス提供時間以外のシステム停止(例:サービス提供がない夜間・休日のサーバ停止)」。
(稼働時間の調整)

クラウドではサーバを止めている間は課金が発生しません。使わない時間はサーバを停止することで、コストを減らすことができます。

また、どのサーバを停止するかについては、停止によるコスト削減効果と業務への影響度を総合的に勘案して決めることが重要です。検証環境等の利用頻度が低いサーバや年間でも一定の時期しか使われない本番サーバは積極的に止めることを推奨しますが、利用頻度が高く業務時間外も稼働しているサーバは止めにくいので、コスト効果と業務への影響のバランスを考えましょう。

3.ストレージの適正化

コスト最適化アプローチの解説のスライド。ストレージ容量の適正化がよりコスト最適化の効果が高いです。検討順番として「ストレージ容量の最適化」、「ストレージタイプの最適化」が挙げられます。ストレージ容量の最適化では、「必要以上のマージンの適正化」「需要に応じた定期的なストレージ拡張運用を前提としたサイジング(5年後を見据えた容量確保の是正)」をします。これが本日の説明と検討範囲となります。
(ストレージ選定・容量の変更)

コストの最適化には、ストレージ(EBS)の最適化も重要です。まず前提として、ストレージは一度大きく作って、後からサイズを落とすことはハードルが高いことをおさえていただければと思います。

ストレージ最適化には「ストレージ容量の最適化」「ストレージタイプの最適化」の二つの観点があります。高いコスト削減効果が得られるのは「容量の最適化」です。

ログが削除されず蓄積され続けたり、バックアップがEBSに残り続けていたりするような、ストレージ容量が時間とともに増え続けるようなシステムは見直す余地があります。

まずはそれらのログやバックアップデータの保管が真に必要なものかの観点で保管の期間や世代を見直します。その上で必要なデータであると判断した場合は、安いストレージに定期的に移したり、別のふさわしいログのサービスを導入したりことでコストを抑えることができます。

EBSのサイズについては、現在のデータ量が100GBの場合、EBSは1.2~1.5倍程度の容量(120〜150GB)を確保することが目安となります。利用率としては60~80%程度になるようにEBSのサイズを決めます。データの増加に合わせて、年1回程度の拡張を前提に運用することで、コストの肥大化を防ぐことができます。

ワークショップ(想定シナリオ:ガバメントクラウドを活用したシステム移行)

共創PFキャンプin広島 ガバメントクラウド編の様子。参加者が手元に付箋を貼っている写真。
(共創PFキャンプ in 広島 ガバメントクラウド編の様子)

勉強会では、架空の自治体がガバメントクラウドを活用し税務システムを1年かけて移行するという想定の下、参加者たちはコスト上の課題抽出とコスト最適化のアプローチを検討する実践的なワークショップに臨みました。

ワークショップで使用した資料

ワークショップ用シナリオ:

パッケージ製品の伴走型コスト最適化ワークショップのシナリオ。【状況】みなさんは人口6万人のマイナ市の職員です。現在税務システムをガバメントクラウドを活用し移行するプロジェクトを担当しています。プロジェクトは設計3ヶ月、構築&単体テスト4ヶ月、結合&総合テスト4ヶ月、移行1ヶ月の12ヶ月のプロジェクトで、現在設計が完了しこれから構築フェーズに入る段階です。【課題】新首長が打ち出した新施策の費用捻出のため、翌年度予算にてあらゆる経費の削減が求められています。本システムも対象であり来年度のあらゆる経費の削減が必要であり、クラウド利用料もできる限りの低減が求められています。【ゴール】クラウド利用料について一層の最適化が可能な箇所を探し、(1)本プロジェクトのリリースまでに行う対策と、(2)リリース後に行う対策の2つについて方針を策定してください。

システムの構成に含まれる対象業務機能:

パッケージ製品の伴走型コスト最適化ワークショップのシステム概要。税務システムの構成に含まれる対象業務機能が図の赤枠部分で示されている。

次期税務システムの構成概要図と要件(環境は(1)本番&災対、(2)運用管理、(3)検証の3環境):

パッケージ製品の伴走型コスト最適化ワークショップのシステム概要。次期税務システムの要件が図で示されている。

現行システムと次期システムの比較表:

パッケージ製品の伴走型コスト最適化ワークショップのシステム概要。次期システムのサーバサイジングは、現行システムを踏襲する方針です。ただし開発事業者は、クラウドの仮想サーバ(インスタンス)の仮想CPU(vCPU)は、オンプレミスのサーバの物理コアの半分の性能しか出ないと主張し、次期システムのインスタンスは、現行の物理コア数の倍のvCPUを実装するものを採用しています。

ワークショップ参加者の実践例

ワークショップでは、参加者たちがコスト上の課題を指摘。その後、グループに分かれて、参加者同士でコスト最適化のアプローチを検討しました。

参加者が指摘した課題例:

  • CPUのピーク時の利用率が10%と低すぎる(70~90%が望ましい)
  • 踏み台サーバの稼働時間が過剰(週16時間しか使わないのに常時稼働になっている)
  • DBサーバのストレージ利用率が低すぎる(利用率50%、初期3,000GB設定、年間200GB増える)
  • 拡張について、どのタイミングで対応するべきか

参加者が示したコスト最適化のアプローチ例:

  • インスタンスを8vCPUから4vCPU、または2vCPUにダウンサイジング(2xlargeをxlargeに変更する)
  • 稼働時間を常時稼働(100%)から16時間に変更
  • ストレージを2,200GBに見直す(最初の1,500GB+1年後に増えた200GB=1,700GBが80%程度になるように計算)、拡張は年次が現実的
  • 検証環境ではバッチ処理が主に行われると想定。稼働時間を毎日2時〜6時の4時間に限定して設定
  • データ転送量を10分の1程度に圧縮

ワークショップの最後には、想定シナリオにおけるコスト最適化のアプローチの検討例とポイントをデジタル庁ガバメントクラウド班が解説しました。

解説:コスト上の課題とコスト最適化のアプローチ例(担当:ガバメントクラウド班・武田)

パッケージ製品の伴走型コスト最適化ワークショップの「講師からコスト最適化方針例の解説」のスライド。次期税務システムにおけるコスト上の課題およびコスト最適化アプローチ例は以下の通りです。【インスタンスサイズ最適化】現行のCPU使用率等から必要vCPU数を予想/vCPU数に応じたインスタンスサイズを再選定/インスタンス世代が古い場合、最新化も検討する【インスタンス稼働時間最適化(本番・運用)】システム利用実態を確認/利用時期や時間帯が限定的、もしくは利用頻度が低いシステムは特定時期・時間帯に停止、稼働時間を削減【インスタンス稼働時間最適化(検証)】環境の用途・利用実体を確認/利用しない曜日・時間帯は自動停止機能により積極的に停止、稼働時間を削減【ストレージサイズ最適化】EBS容量を現行データ量・将来の増加量に基づき削減/増加量に応じてEBS容量を段階的に拡張する運用とすることで、ストレージへの課金を削減【通信量最適化】日次でEC2停止後にEBSスナップショットを取得/初回はフル、2回目以降は変更されたデータ量のみ。大阪リージョンに転送することで通信料金を削減【マネージドサービス活用】Session Manager
(コスト最適化方針例の解説1)

パッケージ製品の伴走型コスト最適化ワークショップの「講師からコスト最適化方針例の解説」のスライド。コスト最適化アプローチ実施後のカリキュレーターの入力値とポイントが示されている。【インスタンスサイズ】vCPU数が全体では20%程度まで縮小/メモリ等も加味するとインスタンスファミリーの変更、世代の最新化等の検討も可能/検証環境はt系やMediumサイズ以下の活用も検討可【稼働時間】稼働時間が全体では50%程度まで縮小/職員リハサーバでは利用頻度が低いため大幅に削減/検証サーバは平日9時間稼働、夜間・土日停止前提のため稼働時間=課金時間が25%に縮小【EBS容量】EBS容量が全体では43%程度まで縮小/現行サーバのディスク量に年間増加量を加えた容量が80%の使用率となるEBS容量を算出し、毎年EBS容量を拡張する前提とした【通信量】年間通信量1700GB(初回1500GB+年間増加200GB)を12ヶ月で平均
(コスト最適化方針例の解説2)

今回のシナリオにおけるコスト最適化のアプローチの検討例とポイントについて、簡単に紹介します。

まず、EC2のCPUサイズが過大だったため、vCPUのサイズを下げました。検証サーバの稼働時間も稼働の実態に合わせて、運用時間で設定しました。これだけでも大きな削減になります。この点はご参加いただいた皆さんからもご指摘いただきましたが、大正解です。

次にDBの論理バックアップについて。大阪リージョンにフルバックを毎日送っている場合、20TBという相当のデータになります。ただ、毎日フルでバックアップを送るのではなく、初回だけフルとし、2回目以降は変更された分だけを送る「増分バックアップ」とすることでコストを削減できそうです。

また、データは年間200GB増える想定なので、月あたりに直すと16GB~17GB程度になります。初回のフルと、あとは17GBが毎月送られるだけと考えると、かなり減らすことができると思います。

「踏み台サーバ」もマネージドサービスに置き換えることができ、サーバをなくすと非常に大きなコスト削減に繋がることもわかりました。

なお、コスト最適化はカリキュレーターを使うだけでなく、リリース後の継続的な確認と改善が重要です。実績に基づいて対策を繰り返すことが、さらなるコスト最適化につながります。

以上、ガバメントクラウドのコスト最適化のアプローチ例をご紹介しました。ぜひ、皆さまの参考になれば幸いです。

共創PFでは参加者を随時募集中

共創PFでは、部門や組織の垣根を越えた情報共有や意見交換などを気軽に行うことができます。

今回の共創PFキャンプでテーマとしたガバメントクラウドを始め、マイナンバーカードや窓口DXなど、様々な政策テーマに関し相談等できる環境が整備されており、施策の実効性向上にも役立てていただいております。

地方公共団体(全国地方公共団体コードを有する「広域連合、一部事務組合等」を含む)、または政府機関の職員の方であれば誰でもご参加いただくことができます。現在1479の地方自治体から約1万1500人、41の政府機関から約2200人が参加しています(2025年6月1日時点)。

参加登録方法は、以下のリンクをご確認ください。
デジタル改革共創プラットフォームへの参加登録方法|デジタル庁

皆さまのご参加をお待ちしています。


●イベントのご案内:
静岡・愛知エリアの自治体職員の方を対象に、「共創PFプチキャンプin磐田 ガバメントクラウド編」を2025年11月7日に開催します。参加希望の方は以下のリンクからお申込みください。

●関連情報は、以下のリンクをご覧ください。

●デジタル庁ニュースの最新記事は、以下のリンクからご覧ください。