メニュー

デジタル庁GCASガイド

継続的運用経費削減(FinOps)ガイド

2025/10/29 公開

本書はガバメントクラウド利用者のためのドキュメントです。
参照利用は自由ですが、質問・コメントは利用者に限定させていただきます。

はじめに

ガバメントクラウド移行にあたって、クラウドの見積もりが高い、本番運用が始まったがクラウド利用料が高止まりしている、という状態になることは考えられる。そこには、実際のコストが上昇しているということよりも、従来のITコストの考え方との違いが原因になっている部分が多くある。クラウドは、オンプレミスと違い、見積額が契約額となり支払うコストになるということにはならず、本番稼働後実際に使われた分だけが課金され支払うコストとなる。したがって、契約時ではなく本番稼働後にどうコストを下げていくかが重要となる。

運用しながらクラウドコストやその運用コストを下げてコストを削減していく営みをFinOpsと呼ぶ。本「継続的運用経費削減(FinOps)ガイド」では、このFinOpsについて説明すると同時に、ガバメントクラウドでどう具体的にFinOpsを実践するかをガイドする。なお、本ガイドで記載する内容は初回公開以降も、改善に向けた更新を随時図っていく予定としている。

なお、本ガイドは、「コスト最適化アプローチガイド *1」、「継続的運用経費削減ガイド」、「運用モダン化ガイド（仮称）」、「インフラモダン化ガイド（仮称）」「アプリケーションモダン化ガイド（仮称）」の5部作の第2部となる。今後も、コスト削減やクラウドの最適な利用に資するガイドの提供を計画している。

*1 地方公共団体向けに発出している「ガバメントクラウドの適切な利用によるコスト最適化のアプローチガイド」を指す。今後、GCASガイドに掲載する予定としている。

FinOpsの概要

FinOpsの概要と目的

FinOps（継続的運用経費削減）とは一般的には、「Finance（財務）」と「DevOps（開発・運用）」を組み合わせた概念であり、システム運用開始後に、IT部門・実務部門・財務部門が連携してクラウド利用料の継続的な管理と削減を目指す取組である。クラウドは従量課金制のため、運用開始後も利用料の見直し等によるコスト削減が大いに期待できる。

他方、ガバメントクラウド移行においては、移行後の運用経費増加の声が寄せられており、増加対象はクラウド利用料だけでなく、運用保守作業費も含まれている。この運用保守作業費の増加は、クラウド環境でありながら運用が十分にクラウドに最適化されず、従来のオンプレミスに最適化していた運用方式を踏襲し、クラウドの特性を活かしきれていないことが要因である可能性がある。

クラウド利用料と同様に、運用保守作業費においても、運用開始後に運用作業の見直し、クラウド標準機能の活用による効率化等を通じて削減ができる余地がある。

そのため、ガバメントクラウドにおけるFinOpsは、クラウド利用料に加えて運用保守作業費も含めた移行後のランニングコストを継続的に削減していく取組とし、システム運用保守業務で発生するコストに対して、可視化、削減計画の検討、最適化の実践を経て、予算執行額や次年度の予算要求額を削減していくことを目指す。

想定する読者

本ガイドは国の行政機関のPMO、PJMO、地方公共団体の情報政策担当課長、情報システム担当職員、標準準拠システムの担当課の職員を主な読者と想定している。
特に、ガバメントクラウド移行後にランニングコストが増加しており、削減方法を検討中の地方公共団体の職員においてはコスト削減のヒント集として参考とされたい。

※地方公共団体に特有の記載事項については【地方公共団体向け】と明記している。地方公共団体の職員は該当箇所を参照されたい。

想定するシステム構成

本ガイドではガバメントクラウドで想定する移行パターンのうちR2(Rebuild)未満の段階にある利用システムを対象と想定している。

モダンアプリケーションに相当するR2(Rebuild)相当の移行を実現できている利用システムでは、FinOpsの取組と合わせて「運用モダン化ガイド（仮称）」に詳述する運用保守作業のモダン化も検討すること。　　

ガバメントクラウドにおけるFinOpsのポイント

FinOps実践の前提

FinOps実践の前提となるポイントを以下に記載する。

クラウド利用料は本番稼働がコスト削減のスタート地点

オンプレミスをはじめとする従来のシステム利用形態においては、ハードウェアを中心とした基盤に掛かるコストは契約時に複数年度分の金額で決定されていた。

一方、クラウドは実際に利用したサービスとその利用量に対して料金を支払う従量課金制である。

契約金額ではなく実際の利用状況に基づくコストを把握・管理し、リソース量を最適化することで契約期間中にも速やかにコストを削減することが可能である。

  • クラウド上での稼働実績がない時点では移行後のリソースの過不足を事前に把握できないため、稼働時点のシステムは余剰リソースや過剰なスペックを含む可能性が高く、その分運用開始後にコスト削減の余地があると言える。
  • クラウドではリソースの柔軟な変更が可能であり、利用状況に基づいたシステム見直しにより利用開始後もクラウド利用料を下げることが可能である。

コスト把握・削減計画の主体は利用職員

従来のシステム利用では契約期間中固定されていたコストを削減するためには、職員がFinOpsの主体となって事業者を含む関係者に働きかける必要がある。

コストを把握するためのツール利用や、運用保守契約での取り決めを通じて、利用職員がコストを管理できる仕組みを整えることができる。

  • 利用職員がコスト管理・削減の意識を持ち、事業者をはじめとする関係者に働きかけてFinOpsを推進する。
  • 事業者は、職員の求めに応じて改善策の提案やシステム変更に取り組む。
  • 共同利用方式を採用する地方公共団体では、ガバメントクラウド運用管理補助者との協業が必要になるため、運用保守業務の仕様書に要件を盛り込む。

FinOpsの成果を調達仕様書・契約に反映する

FinOpsによるコスト削減の成果は、運用保守業務の調達仕様書や契約内容に反映する必要がある。

最適化されたシステム構成や運用保守作業を前提とした調達を行うことで、FinOpsの成果を支出の削減に繋げることができる。

  • 事業者と複数年度にわたる運用保守契約を締結する場合であっても、年度ごとに契約内容や金額の見直しを行うことを前提とした調達を行う。
  • FinOpsを通じて支出が削減された結果として当該年度の予算に余剰が生じることも考えられるが、コストが最適化された結果として捉え、行政サービスの向上へ資する取組へ充当していく。

本ガイドが対象とするFinOpsのスコープ

本ガイドでは、ランニングコストの経費項目のうち、職員による継続的な改善が可能な「クラウド利用料」と「運用保守作業費」を対象にFinOpsの取組を示す。

国の行政機関の職員はガバメントクラウド利用にあたって契約する運用・保守事業者等に働きかけ、各コストの削減に取り組むものとする。

地方公共団体の職員は主にガバメントクラウド運用管理補助者及びASPと連携してコスト削減に取り組む。

【地方公共団体向け】FinOpsに関係する事業者と各事業者の取組範囲

ガバメントクラウドを利用する地方公共団体はガバメントクラウド運用管理補助者、ASP、回線運用管理補助者及び通信回線事業者との契約関係を持つ。

FinOpsの取組では、主にガバメントクラウド運用管理補助者及びASPとの契約範囲を対象とすることを想定する。

ガバメントクラウド利用時に関係する事業者

地方公共団体がガバメントクラウドの利用にあたって契約関係を持つ事業者と、事業者ごとに想定される役割は以下のとおり。

ただし実際の役割や事業者ごとの責任範囲は各団体の調達仕様によって異なる。

事業者役割
ガバメントクラウド運用管理補助者・クラウドインフラの設計（権限管理含む）、構築、運用、保守、継続的な改善
・地方公共団体がクラウドサービス等を利用し、運用管理する際の技術的助言、補助等
・地方公共団体がデジタル庁に支払うクラウドサービス等利用料の集計、複数の地方公共団体間での按分等の調整
ASP・アプリケーション等の設計と構築
・アプリケーション等の修正及び性能を改善するための検証から本番環境への適用
・アプリケーション等の稼働状況の分析とそれを踏まえた運用改善提案
回線運用管理補助者・ネットワーク構成の設計、設定およびネットワーク管理のための環境構築、運用、保守
・複数の地方公共団体がネットワークを共同利用する場合の統括的な検討支援
・地方公共団体に対し複数のガバメントクラウド運用管理補助者やASPがアプリケーションを提供する場合の統括的なネットワーク管理、検討支援
通信回線事業者・庁内ネットワークとガバメントクラウド接続拠点（ロケーション）を接続する通信回線（拠点接続サービス）の提供
・ガバメントクラウド接続拠点（ロケーション）とガバメントクラウドを接続する通信回線（クラウド接続サービス）の提供
・庁内ネットワークと回線領域を接続する機器の提供、設置、設定

事業者ごとのFinOpsの取組範囲

クラウド利用料の削減における留意点と、運用保守作業費の削減における対象範囲は以下のとおり。

対象クラウド利用料の削減における留意点運用保守作業費の削減における対象範囲
ガバメントクラウド運用管理補助者共同利用方式の場合、団体間で共有する運用管理のためのリソースや、団体共有で実施している運用保守作業をFinOpsの対象とするには団体間での調整を要する。主に以下の作業を対象とする
・インフラ運用保守
・管理業務
・運用補助業務
ASP共同利用方式（アプリケーション分離）の場合はコンピューティングリソースやDB等も共有するため、他団体への影響を考慮しながら取組を検討する。主に以下の作業を対象とする
・アプリケーション運用保守
・管理業務
回線運用管理補助者-本ガイドでは想定対象としない
通信回線事業者-本ガイドでは想定対象としない

FinOpsの実施ステップ

ガバメントクラウドにおけるFinOpsの取組は以下の4つのステップに沿って実践することを推奨する。（各ステップの詳細は次章移行で詳述）

STEP1：コスト構造を把握する
STEP2：コスト削減計画を検討する
STEP3：コスト削減計画を実行する
STEP4：調達仕様書・契約に反映する

クラウド利用料、運用保守作業費双方に対し、上記ステップのサイクルを月単位や年単位で繰り返すことによって、継続的なコスト改善を目指す。

FinOpsのサイクル（クラウド利用料）

クラウド利用料の改善は月次や四半期サイクルで実施する。

  • ダッシュボード等により、クラウド利用料の内訳や推移からコスト構造を把握し、削減箇所のあたりをつける。

  • CSPが提供するコスト削減レコメンデーションサービス等により、改善余地のあるリソースを特定し、最適化を行う。

  • 最適化の実施後は成果を定量的に測定する。

    図 1 FinOpsのサイクル（クラウド利用料）
    図 1 FinOpsのサイクル（クラウド利用料）

FinOpsのサイクル（運用保守作業費）

運用保守作業費の改善は年次～複数年度をかけたサイクルで実施する。

  • 運用保守契約を締結する際、運用作業項目を明細化し、改善対象とする作業を特定する。

  • 対象とする運用作業と最適化アプローチの方法により、最適化を実施するタイミングとサイクルが異なる。

    • 業務開始時や契約見直しのタイミングでは、運用作業の明細や見積もり根拠を確認して見積もり金額自体を適正化する。
    • 月次や四半期ごとのタイミングで、作業の廃止やフローの見直しにより即座の改善が可能な作業を最適化し、次年度の運用保守業務の仕様書及び契約内容に反映する。
    • システム変更等を伴う大幅な運用変更は、翌年度以降に運用保守計画の改善検討をし、その後の契約に反映する等、複数年で取り組むことも検討する。

    図 2 FinOpsのサイクル（運用保守作業費）
    図 2 FinOpsのサイクル（運用保守作業費）

【地方公共団体向け】共同利用方式における検討のポイント

共同利用方式を採用する地方公共団体においては以下の制約があるため留意すること。

制約事項STEP職員の対応留意事項
同じ環境に他団体のシステムを含むため、職員は環境ごとの管理コンソールを参照できない。STEP1・地方公共団体向けGCASコストダッシュボードで全体コスト推移を把握する。
・システム利用状況の情報提供をガバメントクラウド運用管理補助者に依頼する。		・地方公共団体向けGCASコストダッシュボードのサービス別コスト画面は、アカウント分離方式のみ利用可能である。
・システム利用状況の提供にはCSVファイルのエクスポートなどのほか、個別ダッシュボードの構築、利用が有効である。
STEP2・コスト削減レコメンデーションサービスの推奨事項の情報提供をガバメントクラウド運用管理補助者に依頼する。
・ガバメントクラウド運用管理補助者にコスト改善提案の提示と費用対効果の説明を求める。		・共有リソースの変更にあたっては、他団体影響など包括的な視点が必要となるため占有リソースを中心とした改善提案を優先されたい。
共用リソースの按分後コストは前月請求金額からでないと可視化できない。STEP1運用管理アカウントや他団体と共用するリソースのコスト情報は以下で確認すること。
・地方公共団体向けGCASコストダッシュボード：費用按分後のコスト（前月費用請求時の費用）
・請求書：費用按分後のコスト
・管理コンソール：費用按分前のコスト		・共用リソースの費用請求は按分されるため、費用按分後のコストで可視化する必要がある。詳細情報はガバメントクラウド運用管理補助者に説明を求めること。
・事業者は地方公共団体向けGCASコストダッシュボードを閲覧できないことに留意すること。

ここまで記載したFinOpsガイドの概要、ポイントを前提としていただき、以下に記載するSTEP1〜4に沿ってFinOpsを実践する。

STEP1 コスト構造を把握する

FinOpsにおいては、まずはじめに、削減対象となるコストを可視化することで何にどれだけのコストがかかっているのかを把握する必要がある。

STEP1では、クラウド利用料、運用保守作業費それぞれについてコストの発生状況を可視化する方法を案内する。

クラウド利用料の可視化

クラウド利用料の可視化においては管理コンソールで請求金額がいつでも確認できるほか、ダッシュボードなどのツールを利用して一元的に必要な情報を表示することも可能である。

STEP1では可視化における確認のポイントとガバメントクラウドで利用できるツールの利用方法などを解説する。

クラウド利用料の構造

コスト削減余地のあたりをつけるために、まずはクラウド利用料を環境別に可視化し、大きな割合を占める部分を優先的に確認する。

利用料の大きな割合を占める環境において、クラウド利用料の構造を確認する。（例：本番環境で発生するコストの割合が高い場合、まずは本番環境でのコストを削減することが効果的となる）

  • 一般的なクラウドのコスト構造では、仮想サーバーとデータベースで利用料の8割を占める。一般的な構造と比較して大きな利用料を占めるサービスがあればコスト削減の余地があるため、用途や妥当性を確認する。（例：一般的な構造と比較してデータ通信費が多い場合、課金対象となる通信の量や頻度を確認し最適化余地を検討する）

  • クラウド利用料の推移を確認し、前年比や前月比で急増した環境・サービスがあれば、増加要因（利用量の一次的な増加、設定変更、障害等）を特定する。

    図 3 クラウド利用料の構造の確認
    図 3 クラウド利用料の構造の確認

クラウド利用料の構造（モダン化後）

クラウド利用に最適化していないシステム（モダン化していないシステム）では仮想サーバーの利用量が多くなる。仮想サーバー自体のクラウド利用料に加え、運用保守に掛かるコストも必要であり全体的なコスト高に繋がる。

モダンなシステムでは仮想サーバーの利用量を削減し、運用負荷の低いマネージドサービス等の利用量が相対的に高くなることで、全体としてコストを削減することができる。

図は一般的なWebアプリケーションの基本構成をモダン化の度合いごとに3段階に分け、クラウド利用料（年額）を比較したものである。

「1.旧来型の構成（非モダン化構成）」は仮想サーバーのみを用いた極端な単純移行時の構成である。

「3.モダン化構成」への移行によってクラウド利用料の削減が見込まれるため、ガバメントクラウド利用機関においては段階的に「3.モダン化構成」への移行を目指されたい。

構成の詳細と試算の前提は以下のとおりである。金額はあくまで試算であることに留意されたい。

  • AWSの東京リージョンで構成する本番環境のみを想定する。

  • セキュリティ統制関連機能、CI/CD関連機能、NW関連機能は安価かつ構成間で差異がほとんど出ないため試算対象外とする。

  • 「1.旧来型の構成（非モダン化構成）」は仮想サーバーのみを利用した単純移行の構成である

  • 「2.部分的モダン化構成」は業務系基盤、DB、管理系基盤をフルマネージドとし、アプリケーションをコンテナ化した構成である

  • 「3.モダン化構成」は管理系基盤をフルマネージドとし、業務系基盤・DBにサーバレスサービスを用いた構成である

    図 4 モダン化度合い別のクラウド利用料の比較
    図 4 モダン化度合い別のクラウド利用料の比較

コスト可視化のためのツール

クラウド利用料を可視化するツールはCSPから標準提供される管理コンソールのほか、任意でダッシュボードを構築することが考えられる。

また、地方公共団体にはGCASから利用可能な地方公共団体向けGCASコストダッシュボードが提供される。

利用機関・利用方式によってツールの利用方法や利用制約などの留意点が存在するので注意すること。

ツール概要国の行政機関、地方公共団体（単独利用方式）地方公共団体（共同利用方式）
管理コンソール・各CSPが提供するコンソールサービス
・監視サービス等と連携し、環境ごとの状況を閲覧可能である
　・AWS - アカウントごと
　・Google Cloud - プロジェクトごと
　・Azure - サブスクリプションごと
　・OCI - テナンシーごと
　・さくらのクラウド - アカウントごと		・リソース群毎や各種レコメンドサービスを利用可能である・環境ごとに含まれる全団体分の情報を管理するサービスであるため、職員に閲覧可能な権限を付与することができない
コスト最適化ダッシュボード（任意）・利用者が可視化したいメトリクスに合わせて事業者に構築を依頼し、作成するダッシュボード
・実装にあたってはGCASガイド「定量的計測の実装方法」及びこれと合わせてデジタル庁が提供するサンプルIaCファイルを参照する		・管理コンソールで取得できないメトリクスを可視化したい場合に構築が必要となる・管理コンソールを閲覧できない職員向けに任意で構築する
・団体ごとに利用するリソースのコストを可視化できるように構築する
・団体ごとに閲覧可能な範囲を設定し、意図しない情報にアクセスできないよう権限を制御する
地方公共団体向けGCASコストダッシュボード・地方公共団体がGCASから利用できるコストダッシュボード
・アカウント別コスト画面とサービス別コスト画面で、月次コスト推移と利用サービスの割合を確認できる
・請求書と連動しており、月次請求のタイミングで情報反映される		・アカウント別コスト画面とサービス別コスト画面が利用可能
・サービス別コスト画面ではサービス単位の情報が表示される		・アカウント別コスト画面のみ利用可能であり、サービス別コスト画面は利用不可
・（アカウント分離のみ）サービス別コスト画面ではサービス単位の情報が表示される

本項では、「管理コンソール」と「地方公共団体向けGCASコストダッシュボード」の利用方法を案内する。

管理コンソールの利用方法

管理コンソールの利用方法

各CSPはコスト可視化・分析のためのサービスを提供しており、それを利用することでクラウド利用料を把握することが可能である。

以下GCASガイド上で案内するCSP別のコスト可視化サービスの活用方法を参照し、管理コンソールからクラウド利用料とその内訳を確認する。

共同利用方式を採用する地方公共団体の職員は管理コンソールにアクセスできないため、以下の「地方公共団体向けGCASコストダッシュボードの利用方法」を参照の上、コストの可視化に取り組むこと。

また、「【地方公共団体向け】共同利用方式におけるコスト把握のポイント」を参照すること。

【地方公共団体向け】地方公共団体向けGCASコストダッシュボードの利用方法

【地方公共団体向け】地方公共団体向けGCASコストダッシュボードの利用方法
  • 地方公共団体向けGCASコストダッシュボードの操作方法、ビューの仕様などはマニュアルを参照すること
  • 画面は開発中のデモ画面であるため、実際の画面とは異なる場合がある

＜共通＞月次コスト推移の確認方法

  • 地方公共団体向けGCASコストダッシュボードでは自団体が利用しているシステムのコスト推移が利用者の環境ごとに確認できる。
  • 「アカウント別コスト」ビューでは月次のコスト推移が表示される。合計金額推移グラフで全体的なコスト傾向を把握する。

図 5 GCASコストダッシュボード アカウント別コストビュー
図 5 GCASコストダッシュボード アカウント別コストビュー

図 6 GCASコストダッシュボード 利用CSP比率と月額推移
図 6 GCASコストダッシュボード 利用CSP比率と月額推移

  • 「システム名を選択」または「アカウントIDを選択」フィルターを使用して、システムまたは利用者環境を切り替えることで、システムごとまたは環境ごとのコスト推移を確認する。これによって、コストが増加しているシステムや環境を特定する。

図 7 GCASコストダッシュボード システム名によるフィルタ
図 7 GCASコストダッシュボード システム名によるフィルタ

＜単独利用方式/共同利用方式（アカウント分離方式）＞サービス別コストの確認方法

  • 地方公共団体向けGCASコストダッシュボードの「サービス別コスト」ビューでは利用サービスごとのコスト割合を可視化する。
  • サービス別コストは単独利用方式および共同利用方式（アカウント分離）の環境で利用できる。
  • ネットワーク分離およびアプリケーション分離については「サービス別コスト」ビューの利用ができないため、サービスごとのコスト割合を確認する場合はガバメントクラウド運用管理補助者に情報提供依頼を行うこと。
  • 「システム名を選択」または「アカウントIDを選択」フィルターで対象となるシステムや環境を選択する。「請求年月を選択」フィルタで対象の請求月を選択し、対象となる請求月における利用サービス比率を表示することができる。比率の高いサービスに対して、削減可能か、ガバメントクラウド運用管理補助者に利用実績や詳細なリソース情報の提供を求める。また、典型的なクラウド利用料の構造から逸脱しているサービスがないか確認する。

図 8 GCASコストダッシュボード サービス別コスト
図 8 GCASコストダッシュボード サービス別コスト

図 9 GCASコストダッシュボード 利用サービス比率

＜共通＞エクスポートされるCSVからコストを確認する方法・手段

  • 「アカウント別コスト」「サービス別コスト」画面は右上の3点リーダーからエクスポートできる。この時、画面に適用しているフィルタ条件が反映されて出力される。

図 10 GCASコストダッシュボード 3点リーダー

  • 任意のファイル名でCSV形式やスプレッドシート形式でファイルがダウンロードされる。

図 11 GCASコストダッシュボード CSVエクスポート

【地方公共団体向け】共同利用方式におけるコスト把握のポイント

クラウド利用料の可視化にあたり、共同利用方式を採用する団体の職員は管理コンソールを参照できない。

必要に応じてガバメントクラウド運用管理補助者に情報提供を依頼し、コストを把握すること。

提供を依頼するコスト情報の例

カテゴリ情報
サービス情報• サービス名
• サービス単価
• 課金対象利用量
リソース情報• リソースID
• リージョン、ゾーン
• タグ
コスト情報• 月次コスト
• 日次コスト
• 対象期間

図 12 共同利用方式における情報提供依頼フロー
図 12 共同利用方式における情報提供依頼フロー

運用保守作業費の可視化

運用保守作業費は運用事業者から提示される見積を、要求事項に照らして詳細化することが必要となる。

現在の運用保守契約において、どのような作業にどれだけの工数が費やされているかを把握することが目的となる。

運用保守作業の明細化

運用保守作業一式といった費目での一括契約を避けるため、運用保守作業の明細を作成し、作業ごとに発生するコストや削減余地を可視化する。

  • 作業項目の明細化
    • 運用保守作業の委託契約時や業務開始時に、「単純移行で想定される運用作業」を例として、事業者が実施する運用保守作業の明細化を求める。ただし、既存の運用保守計画書・実施要領等に同様の作業項目一覧が含まれる場合はそれらを利用することも妨げない。
    • 明細化の例として「単純移行で想定される運用作業」を以下に示す。なお、「単純移行で想定される運用作業」は運用作業項目の一例でありこれに則ることを要請するものではない。事業者より類する資料を提示いただき、運用改善を検討されたい。
  • 作業頻度の把握
    • 各作業の実施頻度やその要因（定期的に実施する作業や要求仕様で頻度を定めた作業／利用状況によって頻度が変動する作業）を確認する。
    • 各作業の頻度の実績は以下のような記録・資料や運用保守作業の報告書を参考に確認する。
      • インフラ保守：監視ログ、ジョブ実行履歴等
      • 運用補助業務：作業依頼履歴、問い合わせ記録台帳、研修資料等
      • 管理業務：課題管理台帳、ドキュメント更新履歴、構成管理台帳等
      • 障害対応：障害報告書、インシデント報告書等
      • アプリケーション保守：リリース計画書、監視ログ等
  • 作業の性質の把握
    • 運用保守作業には、定型的な手順に則り定期的に実施するものと、障害などの突発的な事象や問い合わせなどの不定期に発生するものへ対応する非定型な作業が存在する。
    • 運用改善においては定型的な作業をコード化・自動化することをまず検討する。これにより定量的に費用対効果を見積もることができる。
  • 価格の可視化
    • 利用職員は事業者に作業分類レベル、または必要に応じて作業項目レベルで価格の提示を求め、コスト構造を把握する。
    • 事業者は、提示した明細からコード化や自動化が可能である作業やその費用対効果を職員と協議、検討する。

単純移行で想定される運用作業項目例

単純移行で想定される運用作業項目例

*地方公共団体でのみ発生する作業項目

作業分類作業項目説明頻度定型/非定型価格地方公共団体における作業者
インフラ保守環境変更作業インフラ環境変更、OS,ミドルウェアのバージョンアップ、作業手順書の作成非定型ガバメントクラウド運用管理補助者
インフラ保守インフラ監視リソース監視、ログ監視、ジョブ監視、セキュリティ監視定型ガバメントクラウド運用管理補助者
インフラ保守バックアップ定期バックアップ、スポットバックアップの取得定型ガバメントクラウド運用管理補助者
インフラ保守ジョブ運用定期ジョブ運用、不定期ジョブのカレンダー投入定型ガバメントクラウド運用管理補助者
インフラ保守クラウドリソース管理クラウドリソースの管理運用定型ガバメントクラウド運用管理補助者
インフラ保守ウイルス対策エンドポイントセキュリティの管理、パターンファイル管理定型ガバメントクラウド運用管理補助者
インフラ保守端末運用運用端末、業務端末、プリンタの運用管理、キッティング等定型ガバメントクラウド運用管理補助者
インフラ保守ユーザーメンテナンスアカウント管理、ユーザ追加削除、PW変更、ユーザ棚卸対応など定型ガバメントクラウド運用管理補助者
インフラ保守ネットワーク管理ネットワーク構成管理、ネットワーク機器管理、LAN構成管理、CIDR管理非定型回線運用管理補助者
運用補助業務データ運用補助データ調査、データ補正、オペレーションミス対応非定型ガバメントクラウド運用管理補助者
運用補助業務ヘルプデスク・研修QA受付、回答。問い合わせ状況管理、研修の実施非定型ガバメントクラウド運用管理補助者
運用補助業務ユーザー運用補助大量帳票印刷、配布対応、外字作成*定型ガバメントクラウド運用管理補助者
運用補助業務閉庁日オンライン対応*閉庁日利用に際するシステム起動停止対応非定型ガバメントクラウド運用管理補助者
管理業務課題管理課題管理非定型ガバメントクラウド運用管理補助者/ASP
管理業務ドキュメント管理仕様書、設計書類、操作マニュアル等の管理定型ガバメントクラウド運用管理補助者/ASP
管理業務システム構成管理アプリケーションのバージョン、インフラ構成、OS,PPバージョン,ライセンス、証明書ほか構成情報の管理非定型ガバメントクラウド運用管理補助者/ASP
管理業務リリース管理インフラ構成変更作業計画と作業管理、アプリケーションのリリース計画と作業管理非定型ガバメントクラウド運用管理補助者/ASP
管理業務セキュリティ管理内部/外部セキュリティ監査の対応、監査ログの取得、情報提供定型ガバメントクラウド運用管理補助者
管理業務物理的セキュリティ対策運用環境の物理的点検定型ガバメントクラウド運用管理補助者
管理業務セキュリティインシデント対応セキュリティインシデント対応、インシデント管理ガバメントクラウド運用管理補助者/ASP
管理業務月次稼働報告システム稼働状況、障害発生状況の定期報告定型ガバメントクラウド運用管理補助者/ASP
障害対応障害管理障害履歴、是正対応の管理、障害管理DB非定型ガバメントクラウド運用管理補助者/ASP
障害対応障害受付オンコール対応非定型ガバメントクラウド運用管理補助者/ASP
障害対応一時対応障害の一時復旧非定型ガバメントクラウド運用管理補助者/ASP
障害対応障害解析障害原因の特定非定型ガバメントクラウド運用管理補助者/ASP
障害対応障害是正障害是正対応、ポストモーテム非定型ガバメントクラウド運用管理補助者/ASP
アプリケーション保守アプリケーションリリースアプリケーションの検証、本番環境へのリリース非定型ASP
アプリケーション保守アプリケーション監視アプリケーションログ監視、アプリジョブ監視定型ASP
アプリケーション保守マスタセットアップ住所マスタなどのマスタ情報の最新化、システム反映定型ASP
アプリケーション保守操作手順書作成アプリケーションの操作手順書の作成、更新非定型ASP

STEP2 コスト削減計画を検討する

STEP2では、STEP1で特定したコスト構造の問題点や削減余地を分析し、コスト削減計画を立てる。

クラウド利用料・運用保守作業費それぞれについてとり得るアプローチ例も参考にしながら検討すること。

クラウド利用料コスト削減レコメンデーションサービス

国の行政機関や単独利用方式を採用する地方公共団体など、管理コンソールへのアクセスが可能である場合、各CSPのレコメンデーションサービスの利用が有効である。

各サービスはクラウドリソースの利用状況を分析し、ベストプラクティスに照らしてリソース最適化のための推奨事項を提案する。

共同利用方式の地方公共団体で利用する場合は、職員の求めに応じてガバメントクラウド運用管理補助者にて推奨事項の情報提供が必要となるため、留意されたい。

CSP*レコメンデーションサービスサービスの概要
Amazon Web ServiceAWS Trusted AdvisorAWSのベストプラクティスに沿ったコスト削減の推奨事項を提案する
AWS Compute Optimizer仮想マシンのサイズ適正化やDB最適化等の推奨事項をダッシュボードで集約する推奨事項とコスト削減額の推定を比較してアクションを検討する
Google CloudRecommender
Cloud Billing		RecommenderはリソースのHOUSE状況に応じてコスト削減の推奨事項を提案する
収集した情報に基づき、Cloud BillingのFinOpsハブ機能でダッシュボードが生成される
Cloud Monitoring仮想マシンのサイズ適正化の推奨事項を提案する
Microsoft AzureAzure Advisor
Microsoft Cost Management		Azure Advisorは過剰なリソースの特定などコストに関する推奨事項を提示する
Microsoft Cost Managementに情報をとりこんで表示することが可能である
Oracle Cloud InfrastructureOCI Cloud Advisor使用率の低いリソース等を特定し、最適なサイズ・設定を提案する
さくらのクラウド最適化サジェストリソース使用状況を分析し、それに基づいた最適な利用方法を提案する

*Google Cloud、Microsoft Azure、さくらのクラウドにおけるクラウド利用料削減アプローチは今後追記予定

クラウド利用料の削減計画

利用職員と事業者は協働してコスト削減可能なリソースを特定し、即効性のある変更から実施する。

最終的には、アーキテクチャのモダン化を目指す（マネージドサービスの活用やAPIベースのシステム構成の実現等）ことが抜本的なクラウド利用方法の改善として有効だが、以下ではモダン化までの過渡期を想定し、即効性が高いアプローチ例を中心に示す。

コスト削減アプローチについては地方公共団体向けに発出している「ガバメントクラウドの適切な利用によるコスト最適化のアプローチガイド 」も参照すること*。

*「ガバメントクラウドの適切な利用によるコスト最適化のアプローチガイド 」は見積時点での利用を想定した記載内容であるため、現行システムの情報を移行後システムの利用状況に適宜読み替えられたい。

#アプローチアプローチ概要
①インスタンス最適化• CPU・メモリ使用率をモニタリングし、過剰リソースを検知した場合はダウンサイズや削除、適切なインスタンスファミリー(例最適化型など)への変更を検討する。
• 新世代のインスタンスファミリーに変更することで、同等性能でコスト削減が見込める場合は移行を検討する。
②稼働時間の最適化• 常時稼働が不要な開発・検証環境や夜間利用のない業務環境は、スケジュール停止を設定し、稼働時間の圧縮を図る。
• 稼働ログを分析し、アクセスのない時間帯や休日に稼働しているリソースを特定し、停止または運用の見直しを実施する。
• バッチ処理や一時利用のジョブは、イベント駆動・スケジュール実行型の構成へ移行することを検討する。
③インスタンスストレージ最適化• ブロックストレージのIO性能や使用量をモニタリングし、過剰リソースを検知した場合はダウンサイズや適切なクラスへの変更を検討する。
④不要なリソースの削除• 本番環境、非本番環境問わず、構築時に一時的に作成されたリソースが残存していないか棚卸し、利用実績のないものは停止・削除・統合を検討する。
• 長期間デタッチ状態のブロックストレージや未使用のIPアドレス、停止しているインスタンス等、非アクティブなリソースを定期的に特定し、削除を検討する。
• ライフサイクルルールや自動削除スクリプトを設定することで、放置リソースの発生を抑止する。
⑤不要なログの削除• 保存されているログの種別・用途・保存期間を棚卸し、業務上不要なログは削除または出力停止する。
• 保存が必要なログについても、保存期間短縮や階層ストレージ移行によるコスト削減を検討する。
⑥補助的ストレージサービスの見直し• ログ保存、ファイル共有、エクスポートデータ保管などに利用されているストレージサービスを対象に、アクセス頻度・保存目的に応じたクラス選定やライフサイクルルール設定を行う。
• 不要なデータやアクセスのないファイルが蓄積している場合は、削除またはアーカイブへの移行を検討する。

なお、共同利用方式を採用する地方公共団体では、同一の環境内に複数の団体のシステムが存在するため、環境ごとの管理コンソールを利用職員が閲覧することは想定しない。

利用職員とガバメントクラウド運用管理補助者が連携してシステムの状況を把握する必要があるため、「共同利用方式における検討のポイント」を参照すること。

アプローチの検討手順（AWS）

アプローチの検討手順（AWS）

アプローチの検討にあたっては、レコメンデーションサービスによる推奨事項の提案や、監視サービスによる利用状況の情報を参考にする。

AWSにおいてはCompute Optimizerが示す推奨改善事項や、CloudWatchが示すリソース利用状況等を参考にすることができる。

  • ＜共通＞Compute Optimizerによる推奨改善事項確認
  • ＜共通＞CloudWatchによるリソース利用状況確認方法

これらのサービスを参考にしながら、以下①～⑥のコスト削減策のうち、とり得るアプローチと対応内容を検討する。

  • ①インスタンスの最適化（AWS）
  • ②稼働時間の最適化（AWS）
  • ③インスタンスストレージ最適化（AWS）
  • ④不要なリソースの削除（AWS）
  • ⑤不要なログの削除（AWS）
  • ⑥補助的ストレージサービスの見直し（AWS）

＜共通＞Compute Optimizerによる推奨改善事項確認

＜共通＞Compute Optimizerによる推奨改善事項確認

国の行政機関においては以下ガイドも参照すること。

本手順では、EC2インスタンスにおける推奨改善事項の確認方法を例示する。

他のサービスにおける推奨事項の確認方法の詳細は以下のAWS公式ドキュメントを参照すること。

1-1.AWSマネジメントコンソールへのログイン

対象システムが稼動するAWSアカウントにログインする。

なお、Switchロールから、後述の操作に必要な権限を持ったユーザー（ロール）にスイッチして作業すること。

必要な権限は以下のAWS公式ドキュメントを参照すること。

1-2.Compute Optimizerの有効化

サービス一覧から「AWS Compute Optimizer」を選択する。

Compute Optimizer画面への遷移後、Compute Optimizerの利用開始画面が表示される場合は本手順を実施すること。

表示されない場合は、本手順は実施不要とし次の手順1-3.推奨事項の確認を実施する。

図 13 AWS Compute Optimizer有効化
図 13 AWS Compute Optimizer有効化

「ご利用開始」を押下後、「オプトイン」を押下する。

なお、オプトインの実施後、Compute Optimizerにて推奨事項が表示されるまでに最大24時間かかる点に留意すること。

図 14 AWS Compute Optimizerオプトイン
図 14 AWS Compute Optimizerオプトイン

1-3.推奨事項の確認

EC2リソース最適化に向けた推奨事項を確認する。

EC2のメモリ使用率を用いた過剰なプロビジョニング状態の確認が必要な場合は、EC2CloudWatchエージェントをインストールし、定義ファイルの設定を行うこと。

必要に応じて、AWS公式ドキュメントを参照し、CloudWatchエージェントのインストールおよび設定を行うこと。

実施後、推奨事項の分析が完了するまでに最大24時間かかる点に留意すること。

Compute Optimizer画面のダッシュボードのリージョン欄にて、「すべてクリア」を押下し、全てのリージョンを対象にする。

図 15 AWS Compute Optimizerダッシュボード

Compute Optimizer画面のダッシュボードの「リソースの最適化オプション」欄にてAmazon EC2の「最適化されていない」インスタンスまたは「アイドル」インスタンスが存在するかどうかを確認する。

Amazon EC2に「最適化されていない」インスタンスと「アイドル」インスタンスが共に存在しない場合は、手順1-6.推奨事項一覧のエクスポートから実施すること。

「最適化されていない」インスタンスが存在する場合は、「リソースタイプ」列の「EC2 インスタンス」を押下し、手順1-4.コスト削減内容の確認（「最適化されていない」インスタンス）を実施すること。

「アイドル」インスタンスが存在する場合は、「アイドル」列を押下し、手順1-5.コスト削減内容の確認（「アイドル」インスタンス）を実施すること。

1-4.コスト削減内容の確認（「最適化されていない」インスタンス）

Compute OptimizerのEC2インスタンスに関するレコメンデーション画面にて、「CPU アーキテクチャの詳細設定」を押下し、「現在」のみにチェックを入れる。

図 16 AWS Compute Optimizer CPUアーキテクチャの詳細設定

「結果=過剰なプロビジョニング」でフィルタする。

図 17 AWS Compute Optimizer 「過剰なプロビジョニング」によるフィルタ
図 17 AWS Compute Optimizer 「過剰なプロビジョニング」によるフィルタ

「推定月間節約額 (オンデマンド)」列記載のコスト削減額、および「推奨インスタンスタイプ」列記載のインスタンスタイプを確認する。

各推奨事項に対する詳細なアクションは「インスタンスID」を押下することで確認できる。

図 18 AWS Compute Optimizer 推定月間節約額と推奨インスタンスタイプ

本確認を、表示されているインスタンス分実施する。

なお、本確認は手順1-6-1.推奨事項のエクスポートにてエクスポートしたEC2推奨事項一覧を用いて実施することもできる。

1-5.コスト削減内容の確認（「アイドル」インスタンス）

「リソースタイプ=EC2 インスタンス」でフィルタする。

「推定月間節約額 (オンデマンド)」列記載のコスト削減額を確認する。

各推奨事項に対する詳細なアクションは「リソースID」を押下することで確認できる。

図 19 AWS Compute Optimizer アイドル状態のリソースの推定月間節約額
図 19 AWS Compute Optimizer アイドル状態のリソースの推定月間節約額

1-6.推奨事項一覧のエクスポート

1-6-1.推奨事項のエクスポート

以下のAWS公式ドキュメントを参照し、エクスポート先のS3バケットを作成する。

左ペインの「レコメンデーション」欄記載の「ライツサイジング」内にある「EC2 インスタンス」を押下し、フィルターが設定されていないことを確認の上、「エクスポート」を押下する。

図 20 AWS Compute Optimizer 推奨事項のエクスポートの留意点
図 20 AWS Compute Optimizer 推奨事項のエクスポートの留意点

  • 「レコメンデーションをエクスポート」画面にて以下の設定し、推奨事項一覧をエクスポートする。
    • 「エクスポート先と名前付け」欄にて、S3バケットを指定する。「オブジェクトプレフィックス」の指定は任意とする。
    • 「フィルタをエクスポート」欄にて、「CPU アーキテクチャの詳細設定」の項目が「現在」のみとなっていることを確認する。
    • 「含める列」欄にて、「すべて選択」を押下し、全ての項目にチェックが入っていることを確認する。
    • 画面下部の「エクスポート」を押下し、推奨事項一覧をエクスポートする。

図 21 AWS Compute Optimizer 推奨事項のエクスポート
図 21 AWS Compute Optimizer 推奨事項のエクスポート

S3バケットにエクスポートした推奨事項一覧をダウンロードする。

＜共通＞CloudWatchによるリソース利用状況確認方法

＜共通＞CloudWatchによるリソース利用状況確認方法

Compute Optimizerにてエクスポートした推奨事項一覧をもとに、CloudWatchを用いて各リソースが稼働していない時間帯を過去のメトリクスから確認する。

※Compute Optimizerを用いてCPU使用率、ネットワークI/O等のメトリクスを参照することは可能だが、最大14日分のメトリクスしか確認できないため、CloudWatchにて1か月程度のメトリクスを確認すること。

本手順では、EC2インスタンスにおけるリソースの利用状況を確認する手順を例示する。

他のサービスにおけるリソース利用状況の確認方法の詳細は以下のAWS公式ドキュメントを参照すること。

なお、後述の操作に必要な権限を持ったユーザー（ロール）でコンソールにログインして作業すること。

必要な権限は以下のAWS公式ドキュメントを参照すること。

1.利用時間帯の特定

対象インスタンスのリソース状況を確認する。

サービス一覧から「CloudWatch」を選択する。

「すべてのメトリクス」画面の「参照」タブにて、対象インスタンスの「リソースID」で検索を実施し、任意のメトリクスにチェックボックスを入れる。

  • 確認メトリクス例：
    • CPUUtilization（CPU使用率）
    • NetworkIn/NetworkOut（ネットワークI/O）
    • メモリ使用率　※対象インスタンスへCloudWatch Agentの導入が必要

メトリクスを過去４週間以上で表示し、曜日・時間帯ごとのパターンを確認する。

※「グラフ化したメトリクス」タブにて、集計の粒度を変更できる。曜日単位の確認では1時間、時間帯の確認では5分とする等、パターンごとに集計粒度を変更すること。

①インスタンス最適化（AWS）

①インスタンス最適化（AWS）

1.コスト削減可否の検討

「＜共通＞Compute Optimizerによる推奨改善事項確認」、「＜共通＞CloudWatchによるリソース利用状況確認方法」で確認した推奨事項、リソース状況をもとにコスト削減の可否を検討する。

2.インスタンスタイプの変更

「＜共通＞Compute Optimizerによる推奨改善事項確認」で確認した推奨事項をもとに、対象のEC2インスタンスに対して推奨のインスタンスタイプへの変更を検討する。

検討にあたって、「＜共通＞CloudWatchによるリソース利用状況確認方法」で確認したリソース状況を鑑みること。

変更手順の詳細は以下のAWS公式ドキュメントを参照すること。

3.リソースの削除

「＜共通＞Compute Optimizerによる推奨改善事項確認」で確認した推奨事項をもとに、対象のEC2インスタンスに対してリソースの停止・削除を検討する。

検討にあたって、「＜共通＞CloudWatchによるリソース利用状況確認方法」で確認したリソース状況を鑑みること。

稼働時間をスケジューリングすることで過剰リソースが解消される場合もあるため、適宜「②稼働時間の最適化」を参照し、併せて検討する。

②稼働時間の最適化（AWS）

②稼働時間の最適化（AWS）

1.コスト削減可否の検討

「＜共通＞Compute Optimizerによる推奨改善事項確認」「＜共通＞CloudWatchによるリソース利用状況確認方法」で確認した推奨事項、リソース状況をもとにコスト削減の可否を検討する。

2.スケジュール停止の実装

「＜共通＞Compute Optimizerによる推奨改善事項確認」で確認したリソース状況をもとに、該当するリソースの稼働時間や要件を見直し、曜日・時間帯でのスケジュール停止の運用や必要に応じて停止・起動の自動化を検討する。

スケジュール停止・起動の実装にあたっては、EventBridge Scheduler等のスケジューリングサービスの利用を検討すること。

EventBridge Schedulerのサービス詳細は以下のAWS公式ドキュメントを参照すること。

なお、インスタンス起動時に、稀に一時的なキャパシティ不足のエラーによりインスタンス起動が失敗する可能性があるため、起動のリトライの処理を含めた自動化を行う等の対応をあわせて検討すること。また、スケジュールによる停止起動の対象とするインスタンスについては、コスト削減効果と上記エラー等による起動失敗時の業務影響度を総合的に勘案の上、決定すること。

キャパシティ不足のエラーを踏まえた停止・起動の運用の考え方については、今後GCASガイド上で提供予定のため、そちらを参照されたい。

③ブロックストレージ最適化（AWS）

③ブロックストレージ最適化（AWS）

1.コスト削減可否の検討

「＜共通＞Compute Optimizerによる推奨改善事項確認」「＜共通＞CloudWatchによるリソース利用状況確認方法」で確認した推奨事項、リソース状況をもとにコスト削減の可否を検討する。

2. ボリュームの最適化

2-1. タイプ/IOPSの変更

「最適化されていない」ボリュームで確認した推奨内容をもとに、ボリュームタイプやIOPSが最適化の候補となる場合は動的なボリュームの変更を検討する。

検討にあたって、「＜共通＞CloudWatchによるリソース利用状況確認方法」で確認したリソース状況を鑑みること。

2-2. サイズダウン

「最適化されていない」ボリュームで確認した推奨内容をもとに、EBS容量が過剰な場合は小容量ボリュームへの付け替えを検討する。

検討にあたって、「＜共通＞CloudWatchによるリソース利用状況確認方法」で確認したリソース状況を鑑みること。

EBSは直接の容量縮小が不可能なため、対象ボリュームのスナップショット作成→リソースダウン済みの新ボリューム作成→旧ボリュームからの切り替え→不要となったボリュームとスナップショットの削除の手順で対応すること。

各手順は、以下のAWS公式ドキュメントを参照すること。

2-3. リソースの削除

「アイドル」ボリュームで確認した推奨内容をもとに、孤立したスナップショットや未使用EBSが確認された場合は、削除を検討する。

検討にあたって、「＜共通＞CloudWatchによるリソース利用状況確認方法」で確認したリソース状況を鑑みること。

EBSボリュームの削除においては、スナップショットの作成を事前に実施することが推奨されている。削除手順に関しては、AWS公式ドキュメントを参照すること。

④不要なリソースの削除（AWS）

④不要なリソースの削除（AWS）

1.コスト削減可否の検討

「＜共通＞Compute Optimizerによる推奨改善事項確認」「＜共通＞CloudWatchによるリソース利用状況確認方法」で確認した推奨事項、リソース状況をもとにコスト削減の可否を検討する。

2.リソースの削除

確認したリソース状況をもとに、定常的に利用が確認できないインスタンスは削除候補として検討する。

削除前に一定期間インスタンスを停止し、業務影響を確認することを推奨する。インスタンスを停止している間、インスタンス使用料は課金されない。

稼働時間をスケジューリングすることで不要なリソースを最適化可能な場合もあるため、適宜「②稼働時間の最適化」を参照し、併せて検討する。

⑤不要なログの削除

⑤不要なログの削除

1.ログ情報の収集

1-1.ログサービスの設定情報の確認

取得しているログサービスの保存場所や保持期間等の現状を確認する。

※基本的にログの保存場所はS3かCloudWatch Logs、またはその両方となっている。

  • 主要なログサービス
    • Cloud Watch Logs
    • S3サーバーアクセスログ
    • ELBサーバーアクセスログ
    • Cloud Trail
    • VPC Flow Logs
    • AWS Config　等

保存場所がCloudWatch Logsの場合は、保持期間設定を確認し、S3の場合はライフサイクルルール設定を確認する。

確認場所は以下のAWS公式ドキュメントを参照すること。

1-2.ログの利用要件の確認

各ログに関して、業務における利用状況や規定等の要件を確認する。

  • 確認事項の例
    • 規制や法令に基づくセキュリティ要件や保持義務の有無
    • アラートや可視化等の運用・監視用途での利用有無
    • セキュリティ監査やコンプライアンスチェックでの利用有無

2.コスト削減可否の検討

手順1.ログ情報の収集（AWS）の確認情報をもとに、各ログに対して利用期間、保持すべき期間、アーカイブへの移行タイミング等ルールの見直しを検討する。

見直した要件を元として以下の設定を検討する。

3.ログの保管方法の変更

3-1.保持期間設定の変更 - CloudWatch Logs

手順1.ログ情報の収集（AWS）の確認情報をもとに、各ログに対する保持期間設定の要件を検討し、以下の手順に従って設定の変更を実施する。

CloudWatch Logsの場合、ログの保持期間はデフォルトで「無制限」となっているため、保持期間設定の変更実施を推奨する。

なお、後述の操作に必要な権限を持ったユーザー（ロール）でコンソールにログインして作業すること。

必要な権限は以下のAWS公式ドキュメントを参照すること。

サービス一覧から「CloudWatch」を選択する。 「ロググループ」画面にて、対象のロググループにチェックを入れ、「アクション」＞「保持設定を編集」を押下する。

要件に定めた保持期間を設定し、「保存」することで、設定期間を超過したログを保持しないことととする。

※長期保持する場合、CloudWatch LogsはS3よりコストがかかるため、リアルタイム監視を実施していない、もしくはリアルタイム監視を実施する期間を超えたログをS3へ転送する運用も検討すること。

検討にあたっては以下のAWS公式ドキュメントを参照すること。

3-2.ライフサイクルルール設定の変更 - S3

手順1.ログ情報の収集（AWS）の確認情報をもとに、各ログに対するライフサイクルルール設定の要件を検討し、以下の手順に従って設定の変更を実施する。

サービス一覧から「Amazon S3」を選択する。「バケット」画面にて対象のバケットを選択し、「管理」タブにて「ライフサイクルルールを作成する」を押下する。

ライフサイクルルール名を入力し、ライフサイクルルールを適用する範囲であるルールスコープを設定する。

  • 特定のプレフィックスやタグを持つオブジェクトにライフサイクルルールを適用するには「1つ以上のフィルターを使用してこのルールのスコープを制限する」を選択し、「プレフィックス」もしくは「タグの追加」を設定する。
  • バケット内のすべてのオブジェクトにライフサイクルルールを適応するには「バケット内のすべてのオブジェクトに適用」を選択する。

要件に定めたライフサイクルルールを選択し、「ルールの作成」をすることで、設定期間を超過したログを他のストレージクラスに移行、もしくは削除すること。

オブジェクトを他のストレージクラスに移行するルール設定を実施する場合は、以下のAWS公式ドキュメントを参考にし、適切なクラスへの移行を検討すること。

⑥補助的ストレージサービスの見直し（AWS）

⑥補助的ストレージサービスの見直し（AWS）

補助的ストレージサービス（S3、EFS等）に対して、利用容量、アクセス頻度、リクエスト数等を可視化し、最適化余地を特定する。

以下は、最も利用が多いと推測されるS3での見直し手順を記載しているが、他のストレージサービスにおいても本手順を汎化して見直しを実施すること。

1.ストレージ利用情報の収集

1-1.バケットの利用状況の確認 ‐ S3 Storage Lens

S3 Storage Lensを用いて、S3バケットがベストプラクティスに基づいて設定されているかを確認する。

サービス一覧から「Amazon S3」を選択する。「Storage Lens」の「ダッシュボード」画面から「ダッシュボードを作成」を押下する。

以下を設定し、「ダッシュボードを作成」する。

※ダッシュボードは作成後48時間後に表示される。

ダッシュボードが有効化されたら、対象のダッシュボードを選択し、以下を確認する。

  • 7 日以上経過した未完了のマルチパートアップロードを含むバケット
  • 多数の旧バージョンが蓄積されているバケット
  • 未完了のマルチパートアップロードを中止するためのライフサイクルルールが設定されていないバケット
  • 旧バージョンのオブジェクトを期限切れにするライフサイクルルールがないバケット
  • オブジェクトを別のストレージクラスに移行するためのライフサイクルルールがないバケット

確認にあたっての詳細は、以下のAWS公式ドキュメントを参照すること。

1-2.バケット内オブジェクトの利用要件の確認

各バケット、オブジェクトに関して、業務における利用状況や規定等の要件を確認する。

  • 確認事項の例
    • 規制や法令に基づくセキュリティ要件や保持義務の有無
    • アラートや可視化等の運用・監視用途での利用有無
    • セキュリティ監査やコンプライアンスチェックでの利用有無

2.コスト削減可否の検討

手順1.ストレージ利用情報の収集の確認情報をもとに、各バケットに対しての設定、要件の見直しを検討する。

3.バケットの設定変更

3-1.ストレージクラスの変更

手順1.ストレージ利用情報の収集の確認情報をもとに、各オブジェクトに対するストレージクラスの要件を検討し、以下の手順に従ってストレージクラス設定の変更を実施する。

サービス一覧から「Amazon S3」を選択する。「バケット」画面にて対象のバケットを選択し、「アクション」＞「ストレージクラスを変更」を押下する。

見直した要件に沿って、選択肢から変更先を指定する。ストレージクラスの検討においては、以下のAWS公式ドキュメントを参照すること。

※上述の方法では、オブジェクト単位でのクラス変更しか対応していないため、必要に応じて手順3-2.ライフサイクルルールの設定にて「オブジェクトの作成から1日後にクラスの移行」等のルールを適用して対応すること。

3-2.ライフサイクルルールの設定

手順1.ストレージ利用情報の収集の確認情報をもとに、各バケット、オブジェクトに対するライフサイクルルールの要件を検討し、ストレージクラス設定の変更を実施する。

手順は「⑤不要なログの削除」の手順3-2.ライフサイクルルール設定の変更 - S3を参照すること。

アプローチの検討手順（OCI）

アプローチの検討手順（OCI）

アプローチの検討にあたっては、レコメンデーションサービスによる推奨事項の提案や、監視サービスによる利用状況の情報を参考にする。

OCIにおいてはCloud Advisorが示す推奨改善事項や、Monitoringが示すリソース利用状況等を参考にすることができる。

  • ＜共通＞Cloud Advisorによる推奨事項確認
  • ＜共通＞Monitoringによるリソース利用状況確認

これらのサービスを参考にしながら、以下①～⑥のコスト削減策のうち、とり得るアプローチと対応内容を検討する。

  • ①インスタンスの最適化
  • ②稼働時間の最適化
  • ③インスタンスストレージ最適化
  • ④不要なリソースの削除
  • ⑤不要なログの削除
  • ⑥補助的ストレージサービスの見直し

＜共通＞Cloud Advisorによる推奨事項確認

＜共通＞Cloud Advisorによる推奨事項確認

1-1.Oracle Cloudコンソールへのログイン

対象システムが稼動するOCIテナンシにAdminユーザーでログインする。

ガバメントクラウドのAdminユーザーはCloud Advisorを操作する権限を有している。

1-2.Cloud Advisorの有効化

ナビゲーション・メニューを開き、「ガバナンスと管理」を選択し、「クラウド・アドバイザ」を選択する。

クラウド・アドバイザが有効な場合、以下のようなコスト管理の推奨事項が表示される。

クラウド・アドバイザが無効の場合は、アクティブ化し有効にする。

なお、クラウド・アドバイザは対象となるリソースが作成されるか、テナンシーにログインすることで自動的に有効化され、7日後から推奨事項を提供する。

図 22 Oracle Cloud Advisorの有効化

1-3.推奨事項の確認

「クラウド・アドバイザ」で、「推奨事項」を選択する。

デフォルト設定では、「すべてのカテゴリ」、「すべてのサービス」および「アクティブ」ステータスの推奨事項が表示される。

推奨のリストをフィルタするには、「カテゴリ」、「サービス」および「ステータス」ボックスを選択して、表示する推奨を表示する。

コスト最適化のための推奨事項を確認するには、「カテゴリ」で「コスト管理」を選択する。

図 23 Oracle Cloud Advisor 推奨事項の確認
図 23 Oracle Cloud Advisor 推奨事項の確認

1-4.コスト削減内容の確認

「推奨事項のタイプ」から確認したい推奨事項の名前を選択し、推奨事項の詳細ページを開く。

対象のコンパートメントを選択し、必要に応じて「タグ」や「リージョン」でフィルタする。

表示される「Resource recommendations」から、リソース名、推定節約額や推奨構成等を確認することができる。

図 24 Oracle Cloud Advisor 推奨事項のフィルタ

1-5.推奨事項一覧のエクスポート

「CSVをダウンロード」を選択し、ページに表示される推奨事項情報の表をダウンロードする。

なお、手順1-3「推奨事項の確認」にてフィルターを設定している場合は、フィルターされた推奨事項のみがダウンロードされる。

ファイルは指定したダウンロード・フォルダに格納される。

図 25 Oracle Cloud Advisor 推奨事項のエクスポート
図 25 Oracle Cloud Advisor 推奨事項のエクスポート

＜共通＞Monitoringによるリソース利用状況確認

＜共通＞Monitoringによるリソース利用状況確認

1-1.Monitoringの確認

ナビゲーション・メニューを開き、「監視および管理」を選択する。「モニタリング」で、「サービス・メトリック」を選択する。

なお、ガバメントクラウドのAdminユーザーはリソースをモニターするための権限を有している。

権限の詳細は以下のOCI公式ドキュメントを参照すること。

1-2.メトリック・チャートの表示

「サービス・メトリック」ページでサービスごとやリソースごとのメトリック・チャートを確認することができる。

  • 「コンパートメント」から、メトリック・データを必要とするリソースを含むコンパートメントを選択する。
  • 「メトリック・ネームスペース」リストから、対象のリソース・タイプのメトリック・ネームスペースを選択する。
    たとえば、oci_computeagentを選択して、コンピュート・インスタンスのメトリックを表示する。
  • 「ディメンション」から、resourceDisplayNameなどリソース固有のディメンションによるフィルタを追加して、リソースごとのメトリックを表示する。

図 26 メトリック・チャートの表示

  • コンピュート・インスタンスに関するメトリック例：
    • CPU使用率
    • メモリー使用率
    • ディスク読取り/書き込みI/O

※「開始時間」「終了時間」を選択して、5分単位で表示期間を変更できる。曜日単位の確認、時間帯ごとの確認等、パターンごとに期間を変更して利用状況を確認すること。

①インスタンスの最適化（OCI）

①インスタンスの最適化（OCI）

1.コンピュート・インスタンスの変更

1-1.コスト削減可否の検討

「＜共通＞Cloud Advisorによる推奨事項確認」「＜共通＞Monitoringによるリソース利用状況確認」で確認した推奨事項、リソース状況を基にコスト削減の可否を検討する。
CPU利用率やメモリー使用率が定常的に低いコンピュート・インスタンスはスペックが過剰となっている可能性がある。

1-2.インスタンスの縮小

必要以上に大きいコンピュート・インスタンスのOCPU、メモリを縮小することでコストを節約する。

シェイプの変更手順は以下のOCI公式ドキュメントを参照すること。

また、Cloud Advisorで「利用率の低いコンピュート・インスタンスの縮小」が推奨されている場合は、推奨事項の詳細から「実装」を選択することで、推奨事項に沿った修正を行うことができる。

推奨事項の実装手順は以下のOCI公式ドキュメントを参照すること。

1-3.バースト可能なインスタンスに変更

コンピュート・インスタンスをバースト可能なインスタンスに変更することで、不定期に使用量が増加するインスタンスにおいてワークロードの増加時にパフォーマンスを低下させることなく、ワークロードが低い通常時にコストを節約する。

バースト可能なインスタンスへの変更手順は以下のOCI公式ドキュメントを参照すること。

また、Cloud Advisorで「コンピュート・インスタンスをバースト可能に変更」が推奨されている場合は、推奨事項の詳細から「実装」を選択することで、推奨事項に沿った修正を行うことができる。

推奨事項の実装手順は以下のOCI公式ドキュメントを参照すること。

図 27 Cloud Advisor レコメンデーションの確認
図 27 Cloud Advisor レコメンデーションの確認

図 28 Cloud Advisor バースト可能への変更
図 28 Cloud Advisor バースト可能への変更

2.Oracle Databaseの変更

2-1.コスト削減可否の検討

「＜共通＞Cloud Advisorによる推奨事項確認」「＜共通＞Monitoringによるリソース利用状況確認」で確認したリソース状況を基にコスト削減の可否を検討する。

  • データベースに関するメトリック例：
    • AverageActiveSessions（平均アクティブセッション数）
    • ConnectionLatency（接続レイテンシ）
    • CpuUtilization（CPU使用率）

2-2.データベースの最適化

データベースに必要以上に割り当てられたOCPUを減らすことでコストを削減する。
サービスごとの最適化手順はOCI公式ドキュメントを参照すること。

また、Cloud Advisorで「利用率の低いADWおよびATPデータベースの縮小」が推奨されている場合は、推奨事項の詳細から「実装」を選択することで、推奨事項に沿った修正を行うことができる。

推奨事項の実装手順は以下のOCI公式ドキュメントを参照すること。

3.リソースの削除

「＜共通＞Cloud Advisorによる推奨事項確認」で確認した推奨事項をもとに、対象のインスタンスの停止・削除を検討する。

検討にあたって、「＜共通＞Monitoringによるリソース利用状況確認」で確認したリソース状況を鑑みること。

稼働時間をスケジューリングすることで過剰リソースが解消される場合もあるため、適宜「②稼働時間の最適化」を参照し、併せて検討する。

②稼働時間の最適化（OCI）

②稼働時間の最適化（OCI）

1.コスト削減可否の検討

「＜共通＞Monitoringによるリソース利用状況確認」で確認したリソース状況を基にコスト削減の可否を検討する。
特定の曜日や時間帯に処理が発生していないリソースは、リソースが不要なときに自動的に停止し必要なときに再起動するよう設定することで、稼働時間を最適化する余地がある。

2.スケジュール停止・起動の実装

該当するリソースの稼働時間や要件を見直し、曜日・時間帯でのスケジュール停止の実装を検討する。

スケジュール停止の実装にあたっては、リソース・スケジューラ等による自動化を検討すること。

リソース・スケジューラでは、次のリソース・タイプに対しスケジュールを作成することができる。

  • コンピュート・インスタンス
  • コンピュート・インスタンス・プール
  • Autonomous Databases
  • ファンクション・リソース

リソース・スケジューラのサービス詳細は以下のOCI公式ドキュメントを参照すること。

なお、インスタンス起動時に、稀に一時的なキャパシティ不足のエラーによりインスタンス起動が失敗する可能性があるため、起動のリトライの処理を含めた自動化を行う等の対応をあわせて検討すること。また、スケジュールによる停止起動の対象とするインスタンスについては、コスト削減効果と上記エラー等による起動失敗時の業務影響度を総合的に勘案の上、決定すること。

キャパシティ不足のエラーを踏まえた停止・起動の運用の考え方については、今後GCASガイド上で提供予定のため、そちらを参照されたい。

③ブロックストレージ最適化（OCI）

③ブロックストレージ最適化（OCI）

1.コスト削減可否の検討

「＜共通＞Monitoringによるリソース利用状況確認」で確認したリソース状況を基にコスト削減の可否を検討する。
必要以上にスループットの高いストレージではスペックが過剰となっている可能性がある。操作数に対するスペックの妥当性を鑑みて対象リソースを判断する。

  • ボリュームに関するメトリック例：
    • ボリューム読取り/書込みスループット
    • ボリューム読取り/書込み操作

2. ブロックボリュームの最適化

2-1. パフォーマンス・レベルの変更

「1.コスト削減可否の検討」の検討結果に基づき、ボリュームのパフォーマンス・レベルを変更する。

パフォーマンス・レベルの変更手順は以下のOCI公式ドキュメントを参照すること。

図 29 ボリューム・パフォーマンスの確認
図 29 ボリューム・パフォーマンスの確認

また、ブロック・ボリュームでは動的パフォーマンス・スケーリング（自動チューニング）を有効化することでパフォーマンス・レベルを自動的に調整してパフォーマンスを最適化することができる。

動的スケーリングの詳細は以下のOCI公式ドキュメントを参照すること。

なお、Cloud Advisorのパフォーマンスに関する推奨事項で「デタッチ済ブロック・ボリュームのパフォーマンス自動チューニングの有効化」「デタッチ済ブート・ボリュームのパフォーマンス自動チューニングの有効化」が推奨されている場合は、推奨事項の詳細から「実装」を選択することで、推奨事項に沿った修正を行うことができる。

推奨事項の実装手順は以下のOCI公式ドキュメントを参照すること。

2-2. アタッチされていないリソースの削除

ブロック・ボリュームは使用していなくてもリソースを確保しており、常にコストが発生し続ける。

アタッチされていないボリュームを削除することでコストを削減する。

手順は以下のOCI公式ドキュメントを参照すること。

また、Cloud Advisorで「アタッチされていないブロック・ボリュームの削除」「アタッチされていないブート・ボリュームの削除」が推奨されている場合は、推奨事項の詳細からリソースを修正することができる。

推奨事項の実装手順は以下のOCI公式ドキュメントを参照すること。

④不要なリソースの削除（OCI）

④不要なリソースの削除（OCI）

1.コスト削減可否の検討

「＜共通＞Cloud Advisorによる推奨事項確認」「＜共通＞Monitoringによるリソース利用状況確認」で確認した推奨事項、リソース状況を基にコスト削減の可否を検討する。

特に、Cloud Advisorにおける「アイドル・コンピュート・インスタンスの削除」の推奨事項は、一部のコンピュート・インスタンスが使用されていないことを示す。

2.リソースの削除

確認したリソース状況をもとに、定常的に利用が確認できないインスタンスは削除候補として検討する。

削除前に一定期間インスタンスを停止し、業務影響を確認することを推奨する。インスタンスを停止している間、OCPU,、メモリに対しては課金されない。

稼働時間をスケジューリングすることで不要なリソースを最適化可能な場合もあるため、適宜「②稼働時間の最適化」を参照し、併せて検討する。

また、Cloud Advisorで「アイドル・コンピュート・インスタンスの削除」が推奨されている場合は、推奨事項の詳細からリソースを修正することができる。

推奨事項の実装手順は以下のOCI公式ドキュメントを参照すること。

⑤不要なログの削除（OCI）

⑤不要なログの削除（OCI）

1.ログの利用要件の確認

各ログに関して、業務における利用状況や規定等の要件を確認する。

  • 確認事項の例
    • 規制や法令に基づくセキュリティ要件や保持義務の有無
    • アラートや可視化等の運用・監視用途での利用有無
    • セキュリティ監査やコンプライアンスチェックでの利用有無

2.Loggingの最適化

2-1.サービス・ログの保持期間の設定

サービス・ログは対応しているサービスごとに有効にすることで取得される。

保持期間は1か月（デフォルト）から6か月まで30日刻みで設定することが可能である。

ナビゲーション・メニューを開き、「監視および管理」を選択する。「ロギング」で、「ログ」を選択する。

各カスタムログの「編集」を選択し、ログの保持期間を変更する。

その他のログ管理操作については以下のOCI公式ドキュメントを参照すること。

なお、コネクタを利用してLoggingからObject Storageにログを転送することでより安価にログを保存できる。

参照する機会が少ないが永続的に保存する必要があるログはObject Storageへの保存も検討する。

コネクタの作成方法は以下のOCI公式ドキュメントを参照すること。

図 30 ログ保持期間の変更

⑥補助的ストレージサービスの見直し（OCI）

⑥補助的ストレージサービスの見直し（OCI）

1.オブジェクトストレージの見直し

1-1.コスト削減可否の検討

「＜共通＞Monitoringによるリソース利用状況確認」で確認したリソース状況を基にコスト削減の可否を検討する。

オブジェクト数やバケット・サイズが大きい場合は不要なオブジェクトやバージョンが保存されていないか確認する。

また、リクエスト数の少ないバケットではライフサイクル・ポリシーを設定してオブジェクトのストレージ階層を変更できないか検討する。

  • オブジェクトストレージに関するメトリック例：

    • ObjectCount（オブジェクト数）

    • StoredBytes（バケット・サイズ）

    • AllRequests（すべてのリクエスト）*

      *カスタムメトリックであるため、チャートに表示するためにはメトリック・エクスプローラを使用する。

手順は以下のOCI公式ドキュメントを参照すること。

1-2.バケット内オブジェクトの利用要件の確認

各バケット、オブジェクトに関して、業務における利用状況や規定等の要件を確認する。

  • 確認事項の例
    • 規制や法令に基づくセキュリティ要件や保持義務の有無
    • アラートや可視化等の運用・監視用途での利用有無
    • セキュリティ監査やコンプライアンスチェックでの利用有無

1-3.オブジェクト・ライフサイクル・ポリシーの設定

オブジェクト・ライフサイクル管理を使用して、オブジェクト・ストレージおよびアーカイブ・ストレージのデータを管理することでコストを削減する。

ライフサイクル管理の手順は以下のOCI公式ドキュメントを参照すること。

また、Cloud Advisorで「オブジェクト・ライフサイクル管理の有効化」が推奨されている場合は、推奨事項の詳細から「実装」を選択することで、推奨事項に沿った修正を行うことができる。

推奨事項の実装手順は以下のOCI公式ドキュメントを参照すること。

アプローチの検討手順（Google Cloud）

今後掲載を予定している

アプローチの検討手順（Azure）

今後掲載を予定している

アプローチの検討手順（さくらのクラウド）

今後掲載を予定している

長期継続割引の利用

稼働時間の削減や調整が難しく、月間稼働率が高い（目安：70％以上）リソースについては、長期契約割引（リザーブドインスタンスやSaving Plans等）の購入を検討する。

長期継続割引の利用は以下のステップで検討する。詳細は国の行政機関・地方公共団体に向けたGCASガイドを参照すること。

  1. インスタンスサイズや稼働時間の最適化、不要リソースの削除等、他のコスト削減手法を適用する
  2. 稼働実績を分析し、長期使用（1~3年単位）が見込まれるリソースを選定する。その際、システム構成の変更や停止予定がないことも確認する
  3. 構成固定型の割引（リザーブドインスタンス等）、または一定利用料に基づく柔軟な割引（Saving Plans等）など、リソース特性に応じた契約方式を選定する

なお、OCIでは長期継続割引が提供されていないため上記ガイドを掲載していない。

【地方公共団体向け】共同利用方式におけるポイント

クラウド利用料の削減アプローチを検討するにあたり、共同利用方式を採用する団体の利用職員は管理コンソールを参照できない。

必要に応じてガバメントクラウド運用管理補助者に情報提供を依頼し、連携してコスト削減計画を検討すること。

図 31 共同利用方式における推奨事項提供依頼のフロー
図 31 共同利用方式における推奨事項提供依頼のフロー

運用保守作業費の削減計画

「単純移行で想定される運用作業項目と削減アプローチ例」を参考に、以下観点で削減可能な作業を検討する。

なお、利用職員と事業者による検討が難しい場合は、運用保守作業の改善活動を第3者の外部事業者に調達することを検討する。

削減対象作業の検討ポイント

  • 件数ベースの見積もり（N回/月）を実績値（N時間/月）に調整して、各作業の工数を把握する
  • 各作業の工数から運用保守作業費の内訳を把握し、削減対象とする作業を検討する
    • コストが特に高い作業に着目し、工数を削減可能か検討する
    • 作業項目別の工数とコストを直接紐づけることが難しい場合は、「単純移行で想定される運用作業項目と削減アプローチ例」を参考に、とり得るアプローチから削減対象とする作業を特定する
    • 複数の事業者でいずれも工数を計上している作業があれば、作業範囲に重複がないか検討する
  • 削減対象とする作業について、「単純移行で想定される運用作業項目例」等を参考にアプローチ実施後の作業有無や実施頻度の変化を反映した明細を作成する。STEP1で作成した現状の明細と比較し、費用対効果を検討する。
  • 各作業に対し、以下いずれかのアプローチをとることが可能か検討する。
    作業項目ごとに考えられる主なアプローチを「単純移行で想定される運用作業項目と削減アプローチ例」の表に示しているため、検討の際の参考にされたい。
    1. 見積りの妥当性確認
    2. 要求仕様の見直し
    3. 不要な業務の特定・廃止
    4. 運用フロー、運用プロセスの改善
    5. 作業の内製化
    6. 業務の自動化/マネージドサービスへの置き換え

運用保守作業の削減アプローチ例

1. 見積りの妥当性確認

  • 見積り時点において、以下の観点に従って見積りの妥当性を確認する。
    • 作業工数の明細と単価、その要員レベルを明確にする
    • 作業工数の根拠を問い、妥当性を確認する
    • 工数根拠が過年度の実績を踏まえた係数となっていることを確認する（問い合わせ件数、障害対応件数、定例会議頻度 等）
      • 障害対応工数が固定的である場合、実績に基づいた工数へ見直す
    • 作業に対する要員単価の妥当性を確認する
    • 作業に重複がないことを確認する
    • 削除済み、緩和済みの作業が残っていないことを確認する

2. 要求仕様の見直し

  • 見積り時点において、見積金額算出に係る要件の見直しを検討する。
    • システム稼働報告をダッシュボードや管理コンソールで実施することで資料作成工数を削減する
    • システム利用状況は職員がダッシュボード等を用いてモニタリングするとし、事業者の定期報告頻度を削減する
    • サポートデスクや問合せ対応工数について固定的な件数で計上している場合、実態に即した件数に見直す、または対応時間を限定することで対応工数を削減する
    • 障害対応に関して、実績ベースの後払い請求方式を導入する
  • 【地方公共団体向け】アプローチの検討時は以下に留意する。
    • サービスレベルの見直し（定例報告会実施頻度等）を検討する場合は、「地方公共団体情報システム 非機能要件の標準について」を参照し、求められる条件を満たす範囲での削減を検討する

3. 不要な業務の特定・廃止

  • ガバメントクラウド移行により不要となったハードウェア関連作業を洗い出し、廃止する。
    • ハードウェア保守や定期点検などハードウェア起因作業を廃止する
    • データセンターの法定点検、停電対応などの拠点起因作業を廃止する
    • リモート保守を導入することにより、端末、プリンタのキッティングや管理作業を廃止する
    • 可搬媒体、バックアップ媒体の廃止により、その管理運用を廃止する
  • 冗長となった手動監視、現地作業などを見直す。
    • オンサイトでの常駐運用を、リモート運用やマネージドサービスへ移行する
    • 夜間作業を把握し、日中実施や自動実施へ移行する
    • 利用状況や業務状況確認のためのヒアリング訪問を削減する
  • アプローチの検討時は以下に留意する。
    • 庁舎拠点やデータセンター拠点に残置するシステムがあり、作業の廃止ができない場合も削減余地がないかを確認されたい

4. 運用フロー、運用プロセスの改善

  • 運用保守契約に基づき実施される各運用プロセスやフローを継続的に把握し、非効率や重複が見られる場合に事業者へ改善を要求する。
    • 報告書や資料の様式を簡素化し、必要最低限の記載とする
    • 障害対応フローが煩雑である場合、フローを見直し工数を削減する
      • オートヒーリングなどを活用し一次復旧にかかる工数を削減する
      • 障害発生時の連絡経路を簡素化し、窓口を一本化する
      • 軽微な障害や問合せについては、エスカレーション基準を見直し、必要以上の報告や二重対応を避ける
    • 軽微な設定変更や定例作業については、大規模変更と同一の承認フローとせず、簡易な手続きを設ける
  • アプローチの検討時は以下に留意する。
    • 運用プロセスやフローの非効率は事業者だけでなく利用者側の要件（例：夜間作業の現地立ち合い必須 等）に起因する場合もあるため、改善要求にあたっては要件緩和も併せて検討する

5. 作業の内製化

  • 運用保守契約において委託している作業項目や運用フローの中で、利用職員で対応可能な定型的な作業を内製化することを検討する。
    • 業務アプリケーション上で定期的に実施される、パラメータ変更や帳票テンプレートの入替等の定型的作業を職員が実施する
    • ログ監視や死活監視等の一次確認を職員が実施し、詳細確認の必要がある場合にのみ事業者へ確認する運用とする
    • EUC機能などのサービス起動停止を職員が実施する。
    • 【地方公共団体向け】閉庁日利用時などのサービス起動停止処理を職員が実施する。
    • 【地方公共団体向け】国や広域自治体より依頼されるデータ取得・提供業務において、データ調査・補正作業を職員が実施する

6. 業務の自動化/マネージドサービスへの置き換え

  • コード化や自動化により事業者の省力化を通じて工数を削減する
    • 監視製品をマネージドサービスに移行し、製品ライセンスや保守費用を削減、常駐監視を廃止する
    • バックアップをマネージドサービスに移行し、夜間バックアップから日中バックアップに切り替え夜間対応工数を削減する
      • ライフサイクル管理機能を利用したバックアップ管理運用の自動化による工数を削減する
    • ログ取得など事業者が対応している定型作業をコード化し自動化することで、工数を削減する
    • アプリケーションリリース作業をCI/CDパイプライン化し、対応工数を削減する
    • IaCを導入しインフラ作業を自動化することで対応工数を削減する
  • アプローチの検討時は以下に留意する。
    • システム変更を伴うアプローチであるため、複数年での取組が前提となる
    • 初年度には費用対効果や具体的な作業内容を検討し、次年度以降の開発～実装を契約内で取り決める
    • 改善作業を実施する年度では一時的に作業量やクラウド利用料が増加する可能性がある

単純移行で想定される運用作業項目と削減アプローチ例

単純移行で想定される運用作業項目と削減アプローチ例
作業分類作業項目説明見積りの妥当性確認要求仕様の見直し不要な業務の特定・廃止フロー・プロセスの改善作業の内製化自動化／マネージドサービス化コスト削減対策の例地方公共団体における作業者
インフラ保守環境変更作業インフラ環境変更、OS,PPのバージョンアップ、作業手順書の作成⚫︎IaC導入による省力化ガバメントクラウド運用管理補助者
インフラ保守インフラ監視リソース監視、ログ監視、ジョブ監視、セキュリティ監視⚫︎運用管理製品からダッシュボードへの移行　外形監視への移行ガバメントクラウド運用管理補助者
インフラ保守バックアップ定期バックアップ、スポットバックアップの取得⚫︎⚫︎マネージドサービスへの移行、夜間から日中バックアップへの変更ガバメントクラウド運用管理補助者
インフラ保守ジョブ運用定期ジョブ運用、不定期ジョブのカレンダー投入⚫︎⚫︎マネージドサービスへの移行、夜間から日中バックアップへの変更ガバメントクラウド運用管理補助者
インフラ保守クラウドリソース管理ハイパーバイザクラスタリソースの管理運用⚫︎クラウド環境では考慮しないガバメントクラウド運用管理補助者
インフラ保守ウイルス対策エンドポイントセキュリティの管理、パターンファイル管理コンテナ化、サーバレス化により削減可能ガバメントクラウド運用管理補助者
インフラ保守端末運用運用端末、業務端末、プリンタの運用管理、キッティング等⚫︎リモートアクセス、DssSへの移行ガバメントクラウド運用管理補助者
インフラ保守ユーザーメンテナンスアカウント管理、ユーザ追加削除、PW変更、ユーザ棚卸対応などガバメントクラウド運用管理補助者
インフラ保守NW管理NW構成管理、NW機器管理、LAN構成管理、CIDR管理回線運用管理補助者
運用補助業務データ運用補助データ調査、データ補正、オペレーションミス対応⚫︎⚫︎ガバメントクラウド運用管理補助者
運用補助業務ヘルプデスク・研修QA受付、回答。問い合わせ状況管理、研修の実施⚫︎⚫︎ガバメントクラウド運用管理補助者
運用補助業務ユーザー運用補助大量帳票印刷、外字作成、配布対応⚫︎⚫︎ガバメントクラウド運用管理補助者
運用補助業務閉庁日オンライン対応閉庁日利用に際するシステム起動停止対応⚫︎⚫︎インスタンスやサービスの自動起動停止機能の活用　職員のセルフサービスガバメントクラウド運用管理補助者
管理業務課題管理課題管理管理資料の共有ツール選定などで効率化可能ガバメントクラウド運用管理補助者/ASP
管理業務ドキュメント管理仕様書、設計書類、操作マニュアル等の管理管理資料の共有ツール選定などで効率化可能ガバメントクラウド運用管理補助者/ASP
管理業務システム構成管理アプリケーションのバージョン、インフラ構成、OS,PPバージョン,ライセンス、証明書ほか構成情報の管理⚫︎IaC導入による省力化ガバメントクラウド運用管理補助者/ASP
管理業務リリース管理インフラ構成変更作業計画と作業管理、アプリケーションのリリース計画と作業管理管理資料の共有ツール選定などで効率化可能ガバメントクラウド運用管理補助者/ASP
管理業務セキュリティ管理内部/外部セキュリティ監査の対応、監査ログの取得、情報提供ガバメントクラウド運用管理補助者
管理業務物理的セキュリティ対策運用環境の物理的点検⚫︎物理環境に対する対応は削減。ガバメントクラウド運用管理補助者
管理業務セキュリティインシデント対応セキュリティインシデント対応、インシデント管理ガバメントクラウド運用管理補助者/ASP
管理業務月次稼働報告システム稼働状況、障害発生状況の定期報告⚫︎⚫︎⚫︎⚫︎⚫︎ダッシュボードによる稼働状況の常時モニタリング　ライセンス製品からマネージドサービスへの移行　実施頻度の見直しガバメントクラウド運用管理補助者/ASP
障害対応障害管理障害履歴、是正対応の管理、障害管理DB管理資料の共有ツール選定などで効率化可能ガバメントクラウド運用管理補助者/ASP
障害対応障害受付オンコール対応ガバメントクラウド運用管理補助者/ASP
障害対応一時対応障害の一時復旧⚫︎⚫︎オートヒーリングの実装による自動復旧、効率化、リモート化に伴う全体的な障害対策フローの省力化（オンサイト駆けつけの廃止、など）ガバメントクラウド運用管理補助者/ASP
障害対応障害解析障害原因の特定⚫︎⚫︎統合モニタリングの実装による障害原因特定の効率化、効率化、リモート化に伴う全体的な障害対策フローの省力化（オンサイト駆けつけの廃止、など）ガバメントクラウド運用管理補助者/ASP
障害対応障害是正障害是正対応、ポストモーテムガバメントクラウド運用管理補助者/ASP
アプリケーション保守アプリケーションリリースアプリケーションの検証、本番環境へのリリース⚫︎CI/CDパイプラインの導入による省力化ASP
アプリケーション保守アプリケーション監視アプリケーションログ監視、アプリジョブ監視⚫︎運用管理製品からダッシュボードへの移行　サービス監視への移行ASP
アプリケーション保守マスタセットアップ住所マスタなどのマスタ情報の最新化、システム反映⚫︎⚫︎ASP
アプリケーション保守操作手順書作成アプリケーションの操作手順書の作成、更新⚫︎CI/CDパイプラインの導入による省力化ASP

STEP3 コスト削減計画を実行する

STEP2で検討したコスト削減計画に基づき、各種アプローチを実行する。

クラウド構成や運用保守計画の大幅な見直しを伴う場合は、一時的に作業負荷が増大する可能性があることに注意すること。

アプローチ実施後はその効果を可視化・計測し、継続的なコスト削減へつなげていく。

クラウド利用料の削減

採用するコスト削減アプローチについて、以下のポイントに留意しつつ本番適用までのスケジュールを立てて改善作業を実施する。

  • 改善作業の実施や、発生する作業工数の扱いについては調達仕様書や運用保守契約書に盛り込んで予め取り決めておくことが望ましい
    • 改善策を実施することや、作業量の増大と事前に合意できていない場合、追加費用が発生したり、スケジュール通りに最適化を実施できないおそれがある
  • 検証のために過度な工数が積まれないように注意する
    • インスタンスのサイズ変更など、アーキテクチャそのものに影響しない変更は、検証環境での事前適用や手順確認にとどめる
  • 最適化の実施後、一定期間の運用を経てコスト削減結果を計測する

運用保守作業費の削減

運用変更によって削減可能な作業から削減し、次年度以降の契約金額に反映する。

STEP2に示したアプローチのうち「5.作業の内製化」や「6. 業務の自動化/マネージドサービスへの置き換え」は、運用の大幅な見直しやシステム変更作業を伴うため、複数年にわたって最適化に取り組む必要があることに留意されたい。

なお、年度ごとの活動内容は参考例でありスケジュールを規定するものではない。事業者と協議の上、合理的な改善活動を検討されたい。

1年目

  • 年度初めに年間の運用保守計画書を提出し、作業項目一覧による可視化を行う。
  • 自動化、マネージドサービスへの置き換えを検討する作業を選別し、事業者に対象作業における実績の計測を依頼する。事業者は頻度、工数などから定量的に計測を行う。
    • 過年度実績など信頼に足る情報があれば、これを根拠とすることを妨げない。
  • 3ヶ月もしくは半年に1回、事業者に作業実績を振り返り改善に向けた分析を図る。
    • 運用保守作業、プロセスのモデルを提示し、突き合わせて改善点を洗い出す。
  • 作業実績から、自動化、マネージドサービスへの置き換えによって費用対効果が見込めるものを2年目以降の保守契約に運用改善を要件として取り込む。
    • 運用保守契約の調達仕様に改善に向けた作業内容を要件として明記する
    • 課題管理、引き継ぎ内容に改善に向けた実行した内容を明記する
    • 別調達として第3者の外部事業者に委託することを妨げない

2年目

  • 運用改善のためのシステム変更を実施する。
    • 自動化、マネージドサービスへの置き換えた運用保守作業の実績の計測を依頼する。事業者は定量的な改善効果を計測する。
    • 改善効果が見られる場合、経済的に合理的な範囲で運用保守作業費の見直しを行い、次年度以降の契約に反映する。

3年目

  • 継続的に運用改善が見込める運用保守作業がないか検討、継続改善する。

STEP4 調達仕様書・契約に反映する

STEP1からSTEP3までの取組を通じたコスト削減の結果は、運用保守契約の更新や新規調達を行う際に仕様書に反映する必要がある。

コスト削減計画に則って改善を行った後のシステム構成や運用保守作業を前提とした調達仕様書とすることで、契約金額の削減に繋げていく。

事業者と複数年度にわたる運用保守契約を締結する場合も、年度ごとに契約内容や金額の見直しを行う。

また、FinOpsの取組を開始するにあたっても、事業者が実施すべき作業事項を調達仕様書・契約条件に適切に盛り込む必要がある。

運用保守契約調達仕様書の記載

運用保守契約において、コスト削減の取組が継続的に実践される仕組みを構築する。

以下に調達仕様書への要件を例示する。内容・ポイントを踏まえ当該年度で実施する活動内容を選択し、適宜要件として提示されたい。

全体（FinOpsの実施）

事業者によるFinOpsの活動を成立させるための全般的な要件例を以下に記載する。

項目内容・ポイント要件例
FinOpsの実施・システム利用経費の削減に向けて、継続的にFinOpsを実施する。
・事業者はコスト削減策の立案と費用効果の説明責任を負う。		受託者は、FinOpsの原則に基づき、クラウド利用状況の可視化及び分析を通じて、システム利用経費の削減に向けた継続的な改善活動を実施すること。具体的には、不要なリソースの削除・適正化、タグ管理の最適化等のコスト削減策を立案し、担当課と調整・合意の上で実施すること。また、提案にあたっては費用対効果を定量的に示すこと。
契約内容の見直し検討・FinOpsの実施結果を踏まえて、必要に応じて運用保守委託経費を含む契約内容の見直しを行う。
・コスト改善活動に係る契約は、別途契約を締結するのではなく、運用保守契約の一部として位置付ける。		受託者は、FinOpsの実施結果を踏まえ、契約期間中のいかなる時点においても、担当課の求めに応じて運用保守委託経費を含む契約内容の見直しに協議・対応すること。見直しに資する情報の提供に加え、合理的な範囲で契約内容の変更を受容し、担当課と合意の上で実施すること。

クラウド利用料の継続的な削減

事業者がクラウド利用料の削減に取り組めるための要件例を以下に記載する。

項目内容・ポイント要件例
クラウド利用実績の可視化・コスト推移やシステム利用状況を可視化するためダッシュボードを活用する。
・必要に応じて、より詳細な可視化・分析を行うためのコスト最適化ダッシュボードを構築する。
・予算を超過する場合のアラートなどを設定し、クラウド利用料の予実管理を行う。		受託者は、クラウド利用状況及びコスト遷移を可視化するため、担当課の求めに応じ、クラウドリソースの利用状況やコスト推移の詳細情報をコンソール等から取得し提供すること。必要に応じて、より詳細な分析を可能とするコスト最適化ダッシュボードを構築し、担当課との調整の上で運用すること。また、予算超過の兆候を早期に把握するため、アラート機能等を設定し、クラウド利用料の予実管理を支援すること。
クラウド利用料の削減提案・CSPのレコメンデーションサービスも利用し、クラウド利用料削減のための改善提案を行う。
・提案や対応の件数・頻度をKPIとして定めることも検討する。		受託者は、各CSPが提供するレコメンデーションサービス(例 Trusted Advisor、Azure Adviser 等)を活用し、クラウド利用料の削減に向けた改善提案を定期的に行うこと。提案内容は担当課と共有し、必要に応じて対応を実施すること。
契約年度のクラウド利用料削減目標・契約年度における削減目標値を盛り込むことも検討する。受託者は、クラウド利用料の最適化に向けた改善活動の一環として、契約年度における削減目標の設定を担当課と協議の上で検討すること。目標値は、CSPのレコメンデーションサービスの活用結果や過去の利用実績等を踏まえて合理的に算定し、提案・実施内容のKPIとして活用すること。
【地方公共団体向け】団体ごとのクラウド利用料可視化・特に共同利用方式において、リソースへのタグ付けなどを実施し地方公共団体ごとのクラウド利用料を把握できるようにする。受託者は、共同利用方式において、利用期間ごとのクラウド利用料について担当課の求めに応じ、クラウドリソースの利用状況や費用按分等を含め、クラウド利用料の説明責任を負う。

運用保守作業費の継続的な削減

事業者が運用保守作業費の削減に取り組めるための要件例を以下にに記載する。

項目内容・ポイント要件例
運用保守作業の可視化運用保守作業の明細を作成し、作業ごとに掛かるコストや削減余地を可視化する。受託者は、運用保守に係る各作業の内容を明細化し、運用作業の対応工数を可視化すること。受託者は担当課の求めに応じ、運用作業の要否や費用について協議し、運用作業の削減を検討すること。継続的な見直しと改善提案を行うこと。
運用保守作業の自動化対応明細化された作業のうち、定型作業の自動化に取り組む。受託者は、契約年度において自動化等を通じた運用改善に取り組み、運用保守作業費の削減に取り組むものとする。担当課と改善対象の運用作業を協議し改善策を提案すること。改善対象の作業については実績の記録・管理に取り組み、定量的な削減効果の評価に活用すること。
運用保守作業の削減実績報告契約年度末において、運用保守作業の削減実績を対応件数や対応工数をベースとして報告する。KPIを定めている場合は、KPI達成率をベースとする。受託者は、契約年度末において、運用保守作業の削減実績を対応件数や対応工数を基に担当課へ報告すること。KPIを定めている場合は、KPI達成率を評価指標として用い、削減効果の定量的な把握と次年度以降の改善活動に資する情報提供を行うこと。

運用保守契約の見直し

運用保守契約においては、契約更新のタイミングにかかわらず、委託金額や委託内容を毎年度見直すことが重要である。

必要に応じて契約内容を柔軟に更新することで、継続的なコスト削減を図るとともに、FinOpsの成果を支出の削減として反映する仕組みを維持・強化する。

運用保守契約見直しの観点

以下観点に沿って運用保守契約を定期的に見直すこと。

  • 委託内容
    • FinOpsを活用した継続的なコスト削減に向けた改善活動は、別途契約を締結するのではなく、運用保守契約の一部として位置づけること。
    • 定型的な運用作業（常時監視や障害発生時の一次対応等）はMSP（マネージドサービスプロバイダー）を調達して委託することでコストを削減できる可能性がある。
  • 契約期間
    • 長期継続契約の場合、継続的な改善の実施を前提とし、年度ごとに契約内容や契約金額の見直しを行う。
    • 契約期間の設定にあたっては、事前にRFI等により応札可能性のある事業者の技術力やクラウド対応状況を把握し、適切な契約期間を判断する。
  • クラウド利用料
    • 毎年度、コスト削減目標値について事業者と協議・検討を行い、その結果を踏まえて契約内容を更新する。
  • 運用保守作業費用
    • 作業内容は契約書において明細化し、各作業に対する工数を明示する。
    • IaCやマネージドサービスの活用によって自動化が可能な作業については、契約書において自動化の協議・検討を要件として明記する。
    • 最適化の対象とした作業項目については、事業者に作業量の可視化による費用対効果の測定・説明を求める。
改訂年月日改訂理由
2025年10月29日新規作成
2026年2月2日用語の揺らぎを修正
共同利用方式に関する記載を修正
← モダン化ガイド に戻る