1. はじめに

1.1. 本書の位置づけ

本書は、国の行政機関及び地方公共団体の情報システムをガバメントクラウドへ移行する過程において、「適切なクラウド利用」によるコスト最適化の実現を図るための役割を担うものである。
本書は、システムをガバメントクラウドに移行する際の見積り等で活用されることを想定しており、システムの運用中に継続的にランニングコストを削減していくためのガイドは「継続的運用経費削減(FinOps)ガイド」を参照すること。

1.2. 本書の前提事項

■ 対象読者

• 国の行政機関におけるPMO、PJMO
• 国の行政機関以外の行政機関におけるPMO、PJMO
• 地方公共団体の情報政策担当課長、情報システム担当職員、標準準拠システムの担当課の職員
• ガバメントクラウド上の情報システムを管理（支援・補助）する立場にある事業者

■ 想定するシステム

• ガバメントクラウドで想定する移行パターンのうちR1（Replatform）の段階にあるシステムを対象とする 。

■ 補足資料

• ランニングコストの削減を検討するために、事業者に提供を求める情報は「コスト最適化のアプローチ実施時に収集すべき情報の一覧」を参照すること。

コスト最適化のアプローチ実施時に収集すべき情報の一覧（第1.0版） .xlsx

• クラウド利用経費の見積りを各CSPが提供するカリキュレーター（見積りサービス）上で確認する手順・観点は「2025年4月17日、4月18日　ガバメントクラウドの利用等に関する説明会配布資料」（メンバー専用ページ）の「資料6-3_見積りの確認観点（第1.0版）.pdf」を参照すること。

2. 本書のねらい

2.1. 本書の背景、目的

ガバメントクラウドのランニングコスト（クラウド利用経費等）は、システム移行をモダン化と併せて行うことで低く抑えることができる。

しかし、モダン化まで至らず、見積りの中にオーバースペックなサーバーや不要リソースが含まれている等、クラウドに適さない積算が散見される。

これらの課題に対し、本書では職員が主体的に事業者と協力してランニングコストを最適化できるように、ガバメントクラウド移行時の見積り最適化に向けたアプローチを提供する。

2.2. ランニングコスト最適化に向けたプロセスの全体像

ガバメントクラウドへの単純移行では、費用削減に限界がある。ガバメントクラウドにおける効率的なシステム運用によりランニングコストを最適化するため、4章にて適切なクラウド利用について、5章にてアプローチを実践した地方公共団体の事例について情報提供する。

図2-1.ランニングコスト最適化に向けたプロセス

3. 経費項目の分類とコスト最適化アプローチについて

3.1. ガバメントクラウドにおけるコストの考え方

オンプレミスとガバメントクラウドでは、コストに対する考え方が大きく異なる。
本書のコスト最適化アプローチ例を実施する際は、これらの考え方を念頭に置いていただきたい。

3.2. 本書におけるコスト最適化アプローチ範囲

本書では、ガバメントクラウドの利用において最も削減しやすく、コスト削減効果が高く他項目に波及しやすい「クラウド利用経費」に着目したアプローチを推奨する。
なお、下表は「ガバメントクラウド先行事業（基幹業務システム）における投資対効果」（令和5年12月発出）におけるランニングコストを基に、各経費項目についてまとめた表であり、「クラウド利用経費」がランニングコスト全体の1/4程度を占めていることがわかる。

3.3. 一般的なクラウド利用経費の内訳と効果的な見直し方法

一般的に、クラウド利用経費はサーバーとデータベースの費用が約9割を占める傾向にある。
クラウド利用経費のうち、経費割合が高いサービスから見直すことで効果的にコスト最適化を進められたい。

図3-1.一般的なクラウド利用経費内訳 ^*1

*1 仮想サーバーのみを利用した単純移行の構成を想定してデジタル庁が試算したもの。

4. 現行環境からガバメントクラウド移行によるランニングコスト最適化に向けたアプローチ

4.1. ランニングコスト最適化に向けたアプローチ概要

本章では、「2.2. ランニングコスト最適化に向けたプロセスの全体像」で示した各フェーズのうち「③適切なクラウド利用」に係る個々のアプローチについて説明する。

クラウド利用経費・運用保守作業費・ソフトウェア借料・保守費のそれぞれについて、削減に向けたアプローチの概要と効果、優先度を以下に整理する。

アプローチの採用に当たっては、優先度の高い順での実施を推奨する。

■ クラウド利用経費削減に向けたアプローチ

■ 運用保守作業費削減に向けたアプローチ

■ ソフトウェア借料・保守費削減に向けたアプローチ

*1 ネットワーク通信料金はクラウド利用経費全体において大きな割合を占めないため、コスト削減アプローチの対象とはしない。

*2 アプローチの実施難易度及びコスト削減効果を基にA～Cの優先度を定義した。

4.2. クラウド利用経費削減に向けたアプローチ例

「4.1.現行環境からガバメントクラウド移行によるランニングコスト最適化に向けたアプローチ概要」で整理した各アプローチの詳細を示す。

なお、既に構築・稼働しているシステムに対しては、各アプローチの実施前にCSPが提供するアセスメントサービスの活用を推奨する。

＜留意事項＞

優先度A・Bの項目については「アプローチを適用した場合のコスト削減効果例」としてアプローチを適用した場合のコスト削減効果例を併記するが、金額はあくまで試算であることに留意すること。

試算の前提は以下の通りである。

• 試算はサンプルであり、必ずしも記載する削減率が達成されるとは限らない。
• 詳細な試算手順は「クラウド利用経費の算出に係る手順書」を参照すること。
• 試算は令和6年8月時点のAWSにおけるサービス仕様・利用料を例として提示、ガバメントクラウドの他CSPでも同じ考え方を適用可能である。
• コスト削減効果例については以下の前提で試算している。
  • 費用は年額
  • 為替は1ドル=150円
  • システム構成は以下の通り。

4.2.1. インスタンスサイズの選定

■ 概要

リソースの利用状況を踏まえ、より適切なインスタンスサイズに見直すことで、コスト削減を図ることができる。
クラウドではインスタンスサイズの引き上げが容易であるため、最初から安全マージン（バッファ）を含めた過剰なインスタンスで見積る必要はない。実際の使用量に合わせた必要最低限のCPUコア数を想定してインスタンスサイズを選定し、検証を通じて必要であればサイズを大きくする。

＜インスタンスサイズの見直しによるコスト削減効果イメージ＞

図4-1.アプローチ概要（インスタンス選定・サイズの変更）

■ アプローチの流れ

■ ポイント・注意点

• クラウドではインスタンスサイズが柔軟に変更が可能（再起動が伴うのみ）である。
• 5年先の使用量予測やピーク時に合わせたサイジングは不要であり、通常時の使用量に基づきサイジングを行い、需要に応じてサイズを変更する。
• 通常時のインスタンスサイズを決定する際には、現行環境のCPU使用率等を確認し、実容量に基づいたサイジングを行う。
• インスタンスサイズ変更はクラウドサービスの機能で自動化するか、手動拡張する運用プロセスを事前に整備する。

■ アプローチを適用した場合のコスト削減効果例

*1 本例では1/2のサイズに変更した場合を想定している。

4.2.2. インスタンスタイプの選定

■ 概要

クラウドに移行する際は、CSPが提供する各種のインスタンスから適切なものを選択する必要がある。

コスト効率の高いインスタンスを選定することで、単位時間当たりのコストを低減することができる。

＜インスタンスタイプとユースケース＞

クラウドでは用途に応じてチューニングされたインスタンスが用意されている。システム特性に応じたインスタンスを選定することが重要である。

例えば、一時的に負荷が上がるシステムでは、バースト可能インスタンスを利用することで時間当たりの利用料が安価に抑えることができる。

また、機能面にフォーカスして利用される開発環境や検証環境、業務影響のない本番環境等、厳密に性能が求められないインスタンスでは、安価なバースト可能インスタンスの利用もコストを抑える有効な手段となり得る。ただし、安定した性能を提供しないバースト可能インスタンスを利用する際は、事前に十分な検証を行うこと。

＜世代の最新化＞

パブリッククラウドのインスタンスは、vCPUやメモリ容量が旧世代と同じであっても、最新世代の方が高性能、低価格になる傾向がある。

最新世代のインスタンスタイプを採用することでリソース利用料が安価になる他、インスタンスのサイズダウンが可能になるケースがあり、コスト削減を図ることが可能である。

• 継続してリソースの世代に係る最新情報を収集し、最適な世代について検討することが重要である。
• 設定内容やアプリケーション等との互換性、セキュリティパッチ情報等を事前に業務要件等に応じて確認することが重要である。

■ アプローチの流れ

4.2.3. 稼働時間の調整

■ 概要

システム稼働時間を定義し、定義した稼働時間外はシステムの稼働を停止することで、コスト削減を図ることができる。

稼働時間の定義にあたっては、以下のようなシステムに関する要件・プロセスも含めて見直しの余地があるか検討する。

• 夜間の定期処理を業務時間内で実行
• 依存関係を確認し、定期処理を並列で実行

■ アプローチの流れ

■ ポイント・注意点

• クラウドでは利用時間に対して料金が発生するため、リソースを停止することが利用料の削減に大きく影響する。
• システムが遊休状態（システムが必要な処理をしていない時間が多い状態）になっている場合は、システムの稼働時間を極力削減することでコスト削減を図る。
• 稼働時間の調整にあたっては事前にテストを実施する等、業務や連携先システムへの影響を与えないことを確認する。
• 稼働時間は運用フェーズにおいても定期的に見直しを行い、不要なリソースの停止、処理データの増加や業務時間の変更が発生した場合には、稼働時間を再検討する。
• クラウド側のキャパシティ不足によるエラーが発生しリソースを起動できない場合があるため、稼働時間の調整に当たっては、コスト削減効果と業務への影響とのバランスを慎重に見極める必要がある。開発環境や検証環境については、稼働時間の調整を検討しやすい領域である一方で、本番環境や運用環境については、利用頻度の低い踏み台サーバーや夜間バッチ処理用サーバー等、通常業務への影響が小さいものについて稼働時間の調整を検討する。
• クラウド側のキャパシティ不足によるエラーの発生頻度は限定的だが、業務上重要なサーバーについて起動停止する場合は、当該リスクを考慮して、以下のいずれか、又は複数の対応を含むリソース起動の自動化の仕組みを検討する。なお、業務開始直前（日本時間7時00分から9時00分など）、月末月初、きりのよい時間（日本時間の9時00分など）等の需要の集中が想定される時間帯においては、起動リクエストを避けることも有用である。
• クラウドのキャパシティは頻繁に変動する場合があるため、数分待ってから、起動リクエストを再送信する（リトライ）。
• 一回で起動するインスタンス数を減らし、新しい起動リクエストを送信する。例えば、15 のインスタンスを起動する単一の起動リクエストを送信している場合は、5つずつ3回の起動リクエスト、又は1つずつ15回の起動リクエストに分割する。
• 同一スペックのインスタンスの起動時に、複数回キャパシティ不足となる場合は、CPU（コア）数、メモリサイズを変更して新しい起動リクエストを送信する。
• 起動可能なゾーン（ドメイン）を複数指定し新しい起動リクエストを送信する。又は、現在指定しているゾーンが1つである場合は、現在と異なるゾーンへインスタンスの起動リクエストを送信する。

■ アプローチを適用した場合のコスト削減効果例

4.2.4. ストレージ選定・容量の変更

■ 概要

最低限必要なデータ容量から利用を開始することで、不要なストレージ利用料を抑止し、コスト削減を図ることができる。

クラウドでは必要に応じてストレージ容量を拡張できるため、数年後を見据えた大きな容量を利用開始時点で確保しておく必要はない。最低限のストレージ容量に変更し、年次又は隔年で容量を拡張していく。

図4-2.アプローチ概要（ストレージ選定・容量の変更）

■ アプローチの流れ

■ ポイント・注意点

• クラウドはストレージサイズの拡張が容易なため、数年先を見越した容量のサイジングは不要であり、実使用量に数%のバッファを持たせてサイジングする。
• 可用性はCSP側で担保するため、RAIDを考慮したストレージ構成（RAID分のストレージ容量等）やスペアディスクの考慮は不要である。
• ログや一時ファイルの保管場所となるストレージについては「4.2.8 不要なログの削減 」も参照すること。

■ アプローチを適用した場合のコスト削減効果例

*1 1TBのストレージ領域のうち50%を使用しており毎日10GBの更新があるストレージを毎日バックアップ（7世代保管）すると仮定し試算している。

4.2.5. 運用のマネージドサービス化

■ 概要

バックアップや監視などの運用管理機能をマネージドサービスを用いて実現することで、バックアップサーバーや監視サーバーや運用管理系ソフトウェアが不要となり、コスト削減を図ることができる。

＜マネージドサービスで代替できる機能例＞

• バックアップ：CSPの標準機能を活用し、ストレージやシステムのバックアップを行うことで、サーバーの常時稼働が不要になりコストを削減できる。
• セキュリティ対策：システムの脆弱性を早期に発見し対策を講じることで、セキュリティインシデントを防止。これにより、セキュリティ対策に必要な人材確保や研修、製品導入と運用、脆弱性調査等のコストを削減する。
• 監視：CSPが24時間365日の監視を提供。これにより、内部のITチームが監視に費やす時間が削減され、他の重要な業務に集中できコストを削減する。
• ロギング：ログ管理ツール等を使用して、システムのログを自動的に収集し、分析。これにより、システムのパフォーマンスの最適化、問題の迅速な特定、工数の低減等につながり、コストを削減する。

＜バックアップにおけるマネージドサービスの活用例＞

バックアップサーバーを用いたバックアップでは、サーバー構築に係る開発費や24時間365日サーバーを稼働させるための利用料金が発生する。

マネージドサービスを用いたバックアップに変更することで、マネージドサービスの設定のみで実現可能となり、バックアップ対象データ量等に応じて課金されるためコスト削減が可能となる。

■ アプローチの流れ

■ ポイント・注意点

• クラウドでは基本的な運用管理機能がマネージドサービスとして提供されており、サーバーを構築・運用する場合と比較してコスト減となる可能性が高い。
• マネージドサービスでの実現が難しい運用作業は、要件の見直しやマネージドサービスで実現可能な運用への変更可否を検討する。
• 独自の運用管理システム（バックアップ、ジョブ管理等）の構築は避け、可能な限りマネージドサービスへの代替を検討する。

■ アプローチを適用した場合のコスト削減効果例

4.2.6. DR構成の選定

■ 概要

クラウド利用時はIaC等の活用により環境構築が迅速に実現できるため、スタンバイ環境の削減が検討可能。オンプレミス環境と同様のDR構成を採用している場合、見直しにより費用削減が期待できる。

＜DR構成の種別例＞

システムが求める要件と許容可能なコストに応じてDR構成を検討する。

職員向けシステムや、一部領域や地域の国民向けサービスなど、停止することで即座に国民生活に影響のない「バックアップ」を検討することになると想定する。

DR構成の検討にあたっては「ガバメントクラウド手続き概要」（メンバー専用ページ）や地方公共団体向けの「ガバメントクラウド利用における推奨構成」も参照すること。

• ガバメントクラウド利用における推奨構成
  https://www.digital.go.jp/policies/local_governments#recommendationopen_in_newOpens in new tab

＜バックアップ構成のイメージ＞

DR構成のうち「バックアップ」について、AWS Backupのクロスリージョンバックアップを用いて以下データをS3バケットに格納する構成のイメージを示す。

• システムデータ：　AMI（OSイメージ）、プログラム、IaCコード等
• 業務データ：　RDSスナップショット、ファイル等

図4-3.バックアップ構成のイメージ

■ アプローチの流れ

■ ポイント・注意点

• DR構成の選定に当たっては、各ガバメントクラウド利用機関にて定める非機能要件を基に検討する。
• 災害対策関連要件の見直しを行い、災害時に必要となる業務継続性とそれに伴うコストを確認し、DR構成の検討・選定を行う。
• 本アプローチ及び試算では、本番環境と利用者拠点とのNW回線を考慮していないため、実際にDR構成を検討する場合にはNW回線の構成についても併せて検討を行う。

■ アプローチを適用した場合のコスト削減効果例

*1　毎日10GBのデータ更新がある場合、S3に対し月次500GBのフルバックアップ及び日次10GBの増分バックアップ（7世代保管）をすると仮定している。

4.2.7. ストレージクラス選定とライフサイクル管理

■ 概要

データのアクセス頻度・世代・保管期間に基づきデータ保管先として適切なストレージクラスを選定し、データのライフサイクルを管理することで不要なストレージ利用料を削減する。

＜ストレージクラスの特徴＞

適切なストレージクラスを選択し、過剰なスペックを備えないことが重要である。

＜ライフサイクル機能の利用イメージ＞

時間経過に伴いアクセス頻度が下がるデータはより安価なストレージへ自動移行し、保管期間が過ぎたデータは削除するようにライフサイクルを設定する。

図4-4.ライフサイクル機能の利用イメージ

■ アプローチの流れ

■ ポイント・注意点

• オブジェクトストレージ利用時は、アクセス頻度等に応じてバケット単位でデータ格納場所を分け、アクセス頻度等に応じて適切なストレージクラスを選定する。
• ライフサイクルの設定はオブジェクトストレージの付随機能で実現可能であり、サードパーティー製品を導入せずに自動化可能である。
• データの種類、保存要件等を確認し、業務データ並びに運用管理上必要となるデータのライフサイクルを定め、適切な時期にデータを削除することでリソースを無駄に消費し続けることのないよう設計・構築する。

■ アプローチを適用した場合のコスト削減効果例

4.2.8. 柔軟なリソース確保

■ 概要

負荷量に応じてリソースを柔軟に増減させ、余剰なリソースの発生を抑止することで、コスト削減を図ることが可能である。

新しいインスタンスが自動的に作成され、既存のインスタンスが削除される可能性がある。これによりデータが損失することを防止するため、一部のサーバーに依存しない（各種リクエストの独立化等）構成が必要である。

• データはDBやオブジェクトストレージに保存することで、オートスケーリング時のデータ損失を防止する。
• セッション情報（ユーザーの状態等）は外部のストレージに保存する。ユーザーが複数のサーバー間で移動するときに、そのユーザーの状態を一貫して保持し可用性を向上させる。

＜オートスケーリング機能の利用イメージ＞

図4-5.オートスケーリング機能の利用イメージ

■ アプローチの流れ

■ ポイント・注意点

• インスタンスが負荷に応じて追加（スケールアウト）、削除（スケールイン）するため、アプリケーションが状態を保持しない（ステートレス）必要がある。 そのため、利用するアプリケーションがステートレスか確認し、セッション情報等が必要な場合には、外部に保持する改修が可能か検討する。
• アプリケーション負荷の最大と最小を確認し、インスタンスの最大値（サイズ、台数）と最小値を検討する。
• これまでの負荷状況を確認し、スケールアウト・スケールインするトリガーを決める。負荷の増減が不定期の場合は、CPU使用率やメモリ使用率をトリガーとし、定期的（例えば月末のみ等）の場合は、スケジューリングによるオートスケールも可能である。

■ アプローチを適用した場合のコスト削減効果例

4.2.9. 不要なログの削減

■ 概要

必要なログ及びログの保存期間を再定義し、必要最低限のログをマネージドサービスに保存することで、コスト削減を図ることが可能である。

また、マネージドサービスは保存量に応じて課金されるため、サーバーには最低限のシステム運用に必要なデータのみを残し、保存の必要があるログの出力先は可能な限りマネージドサービスに移行する。

＜設計の見直し・マネージドサービスへの移行イメージ＞

また、ログや一時ファイル等、保管の必要がないデータは仮想サーバーに溜め込まず、削除・退避する設計を行う。

• 保管が必要なデータはブロックストレージでなくオブジェクトストレージに移動させることで、保管コストを抑えることができる。
• 不要な一時ファイルは定期的に削除する運用とし、格納データが単調増加することを前提とした過剰な見積りは行わない。

■ アプローチの流れ

4.3. システム運用作業費削減に向けたアプローチ例

4.3.1. 定量的計測の実現

■ 概要

マネージドサービスを活用して定量的計測を実現し、サービス監視に移行することで、不要な工数の発生を抑止しコスト削減が図れる。

＜サービス運用の観点＞

マネージドサービスを利用することで、インフラリソースの構成に縛られることなく本来のサービス改善とその運用に取り組む。ログや各種メトリクスを記録する仕組みを活用し、サービスを常に改善していく観点から運用を考える。サービスを継続的に改善していくか、利用者の利便性を継続的に高めていけるのかが重要となる。

＜サービス監視への移行例＞

事業者がそれぞれのサービスを独自の方法で監視する運用では、データの分断により、原因究明やIT担当者間の情報共有に時間を要する。

マネージドサービスを活用し適した運用体制に移行することで、相関分析により原因解明を迅速化でき、IT担当者間の情報連携が容易となる。

図4-6.サービス監視への移行例

■ アプローチの流れ

4.3.2. IaC・マネージドサービス活用による自動化

■ 概要

マネージドサービスとIaCを活用することで、インフラストラクチャの運用管理を自動化でき、不要な工数の発生を抑止しコスト削減を図ることができる。

例えば、手順書に基づき手作業で実施していた構築作業をIaC・マネージドサービスによる自動実行（ビルド・テスト・デプロイ）に置き換えることで、運用工数を削減するとともに速度と正確性を向上させることができる。

＜IaC活用の効果＞

• 迅速なインフラ構築：　手動操作が不要になり、迅速に環境を整えることができる
• 一貫性と再現性：　異なる環境でも一貫したインフラ構成を再現できる
• 透明性の向上：　ブラックボックス化を防ぎ、誰でも構成内容を確認できる
• 変更管理の効率化：　変更履歴が明確になり、変更の追跡やレビューが容易

IaC活用に当たってはパイプライン及び運用の整備を併せて実施する必要がある。

• パイプラインの整備
  • 構築（設定）等を手動で実施する運用は、人的ミス等につながり時間が掛かる。
  • 構築や手順作成等をIaCに代替することで、品質の向上、工数の削減につながる。
• 運用の整備
  • ログ管理、バックアップ・リストア等の運用を手動で実施する運用は、復旧対応の遅延につながる。
  • マネージドサービスを活用することで、自動化、対応の迅速化、運用工数の削減につながる。

■ アプローチの流れ

4.4. ソフトウェア借料・保守費の削減に向けたアプローチ例

クラウド移行時には必要となるソフトウェアライセンスを精査し、マネージドサービス利用による持ち込みソフトウェアライセンスを削減することで、コスト削減を図ることができる。

4.4.1. クラウド移行によるソフトウェアライセンスの見直し・削減

■ 概要

クラウド移行時には必要となるソフトウェアライセンスを精査し、マネージドサービス利用による持ち込みソフトウェアライセンスを削減することで、コスト削減を図ることができる。

• マネージドサービス（PaaS・SaaS）利用時に不要となるライセンス
  • バックアップ、監視、セキュリティ等のソフトウェアをマネージドサービスに置き換えることで、当該ソフトウェアのライセンス調達が不要となる。
  • マネージドサービスのインフラ（サーバー）は各CSPにより運用保守されるため、OS・ウイルス対策ソフト等の調達が不要となる。
• IaaS利用時に不要となるライセンス
  • Amazon EC2等のIaaSサービスではOSやDBのライセンスが利用料に含まれる提供形態が存在するため、調達不要となる場合がある。
• クラウドで共通して不要となるライセンス
  • OSより下層のレイヤー（物理サーバー、クラウド内のNW、仮想化等）の運用保守は各CSPが担うため、関連ソフトウェアは調達不要である。

■ アプローチの流れ

5. 地方公共団体のコスト削減事例

5.1. 事例1

現行リソースのスペックや利用状況を踏まえ、見積りに対する縮小等の見直しを行い、見積りに含まれるクラウド利用料の46%を削減した事例である。

■ 団体の情報

■ アプローチ別削減効果

*1 構成等の確認が必要でありシステムごとに判断が必要なアプローチであるため、本書としては掲載対象外

5.2. 事例2

リソース構成のレビューや要件の再整理を行い過剰なリソースやDR構成を見直すことで見積りに含まれるクラウド利用料の68%を削減した事例である。

■ 団体の情報

■ アプローチ別削減効果

*1 構成等の確認が必要でありシステムごとに判断が必要なアプローチであるため、本書としては掲載対象外とした。

6. 用語の定義

本文書における用語の定義を下表に示す。
本章の用語のうち、GCASガイド全体で利用している共通的な用語については「はじめにお読みください」の「用語集 」を参照すること。

以上

改訂履歴