「AWSの費用を下げてほしい」と言われた瞬間、多くの人がまず思い浮かべるのは構成の作り替えです。サーバーの数を見直す、アーキテクチャを変える——大掛かりな刷新をまず覚悟した経験を持つ人は多いはずです。ところが政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針を読むと、真っ先に置かれているのは作りの話ではなく運用の話でした。刷新に進む前に、確認し、削り、終わらせる手が11項目も具体的に並んでいます。

1. 刷新しても運用が同じなら減らない

刷新への期待と、方針文書が示す順番

費用の相談を受けると、まず頭に浮かぶのは構成の刷新です。新しいサービスへの載せ替えや、アーキテクチャの見直しを提案の中心に置いた経験を持つ人は多いはずです。大きな絵を描くほうが、依頼に応えている実感を持ちやすいという事情もあります。

ところがこの基本方針では、刷新だけでは届かない現実が先に置かれています。システム運用が従前のままではコスト削減効果は十分に発現しないと記されているのです¹。作りを変える話の前に、運用の話が置かれている順番そのものに意味があります。

作りを変える前に、運用の中に置き去りにされた手があるかもしれません。目を向ける先は構成そのものではなく、日々の運用の進め方です。次に見るのは、その運用側にどんな原則が置かれているかという点です。

原則として置かれている運用側の削減

この方針は、運用に係る費用の削減を行うことを原則として置いています²。刷新は選べる手の一つであって、唯一の道ではありません。原則という言葉が使われている以上、まず当たるべき場所は運用のほうだと読み取れます。

構成を作り替えるよりも、運用の手順を整えるほうが早く着手できます。AWS環境の構築や運用に携わってきた経験があれば、すでに手元にある知識で応じられる範囲であることも少なくありません。

依頼を受けた側がまず見せられるのは、大掛かりな提案ではなく、これから確認していく11の視点です。次の項目から、運用側でどこを見ていくのかを順に整理していきます。

つまりこの方針は、費用の相談を「作りの問題」ではなく「運用の問題」として先に扱っています。刷新は選べる手の一つであり、最初に当たる場所ではありません。

図の作成：Remogu編集部。方針文書に挙げられた項目を整理したもので、統計データではありません

2. まず見る——利用料を定期的に確認する

見ていないと、直しようがない

費用を削るという依頼を受けても、現在の使用状況を把握していなければ、どこに手を付ければよいのかの判断がつきません。まず必要なのは派手な提案ではなく、現状を映す地味な数字です。

この方針の最初の項目に置かれているのは、クラウド利用料を定期的に確認することです³。数ある項目の中で一番手前に置かれている点が、実務の感覚と重なります。

華やかな改善策よりも先に、地味な確認作業があります。ここを飛ばして刷新に進んでしまうと、何が効いたのかも分からないまま作業だけが終わってしまいます。

確認を仕組みにする

思い付いたときに見るのではなく、決まった頻度で見る仕組みにしておくと、増加の兆しに早く気づけます。属人的な確認は、担当が変わった瞬間に途切れやすいという弱さを持っています。

確認して終わりにするのではなく、確認した結果をどこに書き残すかまで決めておくと、次に見る人が同じ場所から続きを見られます。仕組みとして残すことが、確認そのものよりも効いてきます。

Remoguに参画するエンジニアの中には、この確認の仕組みづくりから任される案件もあります。運用の中で積み重ねてきた経験がどこで生きるかは、まず登録して案件の中身を見て確かめるところから始められます。

確認を仕組みにすると、担当が変わっても同じ場所から続きを見られます。逆に思い付いたときだけ見る運用だと、増加の兆しに気づくのが遅れます。

3. 止まっているものと、常時の余裕

止まっているのに、課金は止まらない

確認を続けていくと、動いていないのに課金され続けているリソースが見つかることがあります。稼働していないリソースへの課金を抑制することが、この方針でも挙げられています⁴。

止まっている理由の多くは、派手な原因ではなく単純な消し忘れです。派手さがない分だけ、定期的な確認がなければ見つからないまま残り続けます。

止める対象を後から探すことよりも、止め忘れが起きにくい仕組みを作っておくほうが、効果は長続きします。次に確認するのは、動いてはいるものの余っている分です。

ピーク用の大きさを、普段も抱えていないか

ピーク時を想定した大きなリソースを通常時にも使用しないことが、同じ方針で挙げられています⁵。混雑する時間帯に耐えられる大きさを、静かな時間帯にもそのまま維持していないかという視点です。

この余裕は、障害が起きていない限り気づかれにくく、請求書の合計だけを見ていても見つかりません。稼働していない分と同じで、細かく見て初めて分かる部分です。

次の表は、この2つの状態がどちらも見つかりにくい理由と、運用側で何を確認できるかを整理したものです。

止まっている分と、常時の余裕の見つけ方

稼働していないリソースは消し忘れが典型で、ピーク時想定の余裕は障害が起きていないぶん気づかれにくいという違いがあります。どちらも原因は別々ですが、見つけ方の性質は似ています。

共通しているのは、どちらも請求書の合計だけを見ていては見つからず、動きを細かく確認して初めて分かる点です。次の表に、見つかりにくさと運用側で確認できることを整理しました。

観点	起きやすい状態	運用側で確認できること
稼働していないリソース	使われていない時間も課金が続いている	稼働状況を定期的に確認し、不要なら停止・削除する
ピーク時想定の大きさ	通常時に使わない容量を保持し続けている	通常時の必要量に合わせて縮小する

この2つはどちらも構成を変えずに着手できます。止まっている分は消し忘れ、常時の余裕はピーク時の想定——原因が違うので、確認の仕方も分けて持っておくと見落としが減ります。

出典：政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針（デジタル庁、2026年）をもとに作成

4. 人の時間を削る——IaCと自動化

手作業そのものが費用になっている

クラウドの費用というと請求書の金額を思い浮かべますが、確認や設定にかかる人の時間も費用の一部です。IaCによるインフラ作業の効率化が、この方針で挙げられています⁶。

手順書を見ながら同じ設定を繰り返す作業は、時間がかかるだけでなく、担当者によって手順が微妙にずれる原因にもなります。一度ずれた手順は、次の作業でも同じずれを生みやすくなります。

設定を人の記憶に頼るよりも、コードに残しておくほうが、次に触る人にとっても確認が早くなります。作業の速さだけでなく、引き継ぎのしやすさにも関わってきます。

自動化を徹底する範囲

運用作業の自動化を徹底することも、同じ方針で挙げられています⁷。手を動かす回数を減らすことが、確認漏れそのものを減らすことにも直結します。

自動化は一度作って終わりではなく、対象を広げ続けて初めて効果が積み上がっていきます。範囲を決めて満足するのではなく、次に自動化できる作業を探し続ける姿勢が求められます。

この領域は、AWS環境の運用に携わってきた経験がそのまま活きる部分です。参画先で自動化の設計から任されるケースも、案件によっては見られます。まずは自分の経験に近い案件があるかを見てみることから始められます。

人の時間を削る手は、請求書の金額だけを見ていると見つかりません。次に見るのは、増えたまま外す判断がされていないものです。

5. 増えたまま放置されるもの——監視・報告・体制

増えるが、外れることは少ない

システムが育つにつれて、監視の対象は自然に増えていきます。しかし外す判断は誰も下さないまま積み上がりやすいものです。監視対象を見直すことが、この方針でも挙げられています⁸。

常駐運用からリモート運用へ移すことも、挙げられている項目の一つです⁹。体制の置き方そのものが、費用に関わる要素として扱われている点が目を引きます。

監視も体制も、一度決めた形を疑う機会がないまま続きがちです。増やすときには理由があっても、減らすときには誰も声を上げないという非対称があります。

監視や体制を外側から見直す視点は、日々の運用に慣れているからこそ持てるものです。慣れが生む見落としに、あらためて気づく力とも言えます。長く同じシステムに関わってきた人ほど、当たり前になった部分を疑いにくいという難しさもあります。

過去の前提を疑う

夜間バッチの必要性を見直すことも挙げられています¹⁰。かつての事情で組まれた時間帯が、今も同じ理由で必要かどうかは、あらためて確かめないと分かりません。

マネージドサービスのアップデート時などにおける確認テストの最適化も、同じ方針の項目です¹¹。更新のたびに同じ範囲を全部確認していないか、範囲そのものを見直す余地があります。

過去に決めた運用のやり方よりも、今のシステムの姿に合わせて組み直すほうが、無駄な確認を減らせます。次の表は、この4つの観点を整理したものです。

監視・体制・バッチ・確認テストの見直し方

監視の対象、運用体制、夜間バッチ、確認テストの4つは、増える理由がはっきりしている一方で、減らす判断を下す機会がないまま積み上がりやすいという共通点があります。

次の表に、それぞれがなぜ増えやすいのか、どちらの向きで見直せるのかを整理しました。

観点	増えやすい理由	見直しの方向
監視対象	追加のたびに広げ、外すタイミングがない	対象を定期的に棚卸しする
運用体制	常駐前提のまま続いている	リモート運用へ移す
夜間バッチ	過去の必要性のまま残っている	必要性をあらためて見直す
確認テスト	更新のたびに同じ範囲を回している	対象と範囲を最適化する

並べてみると、どれも「増える理由ははっきりしているのに、減らす理由は誰も探していない」という共通点が見えてきます。

6. 終わり方を設計する——削除と契約の確認

使い終わったら、消す

検証環境や一時的に立てた構成は、役目を終えた後もそのまま残りやすいものです。サーバーやデータベースなどのリソースを削除することが、この方針で挙げられています¹²。

削除は最後に置かれる地味な作業ですが、これを飛ばすと、それまでの確認や自動化の効果が請求書の上では見えなくなってしまいます。始め方だけでなく、終わり方も設計に含める必要があります。

作るときの手順書はそろっていても、消すときの手順書は用意されていないことがあります。両方をそろえて初めて、費用の話が一巡したと言えます。

消し忘れと同じで、削除の判断も後回しにされがちです。終わり方まで含めて設計できるかどうかは、運用に慣れた人ほど差が出る部分です。作ることには慣れていても、片づけることまで意識してきたかどうかが問われます。

契約の形も確認する

一定期間の契約で使っている場合は、利用終了後の料金発生の有無を確認することも挙げられています¹³。削除したつもりでも、契約の形によっては費用が続くことがあります。

技術的な削除と、契約上の終了は別の手続きです。どちらか一方だけを済ませて安心してしまうと、見落としに気づくのは次の請求のときになってしまいます。

次の表に、確認する場面と内容を整理しました。

削除と契約確認の場面

リソースの削除と契約の確認は、どちらも作業の最後に置かれる地味な手順です。技術的な削除と契約上の終了は別の手続きであり、片方だけでは費用が続くことがあります。

次の表に、確認しておきたい場面とその内容を整理しました。

場面	確認すること
使い終わったリソース	削除する
一定期間の契約で使っている場合	利用終了後の料金発生の有無を確認する

出典：政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針（デジタル庁、2026年）をもとに作成

7. 作らない選択と、続ける前提の計画

作らない選択肢

マネージドサービスの活用によるコスト削減も、この方針で挙げられています¹⁴。自分で組み上げる部分を減らし、すでに用意された仕組みに任せる選択です。

サーバーを構築しないシステムでは、セキュリティ対策コストの削減も、この方針で挙げられています¹⁵。作らない選択は、守る対象そのものを減らす効果も持っています。

当初からピーク時を想定する構成よりも、オートスケールで無駄のない構成のほうが、綿密な当初見積りを要さずに済みます¹⁶。読み切れない需要を、あらかじめ読み切ろうとしなくてよくなります。

作らない選択は、楽をするための選択ではありません。守る範囲を絞り込み、限られた時間を運用の質に振り向けるための選択です。何を作らないかを決められることも、経験の厚みとして見られる部分です。

一度で終わらない計画にする

本番稼働の後も改善を続ける前提で、予算・体制・日程を計画する必要があると、この方針は位置づけています¹⁷。費用の見直しは、公開した瞬間に完了する作業ではありません。

サービスの更新への対応も、特別な出来事としてではなく、日常的に対応していく必要があると、この方針は位置づけています¹⁸。まとめて手を付けるのではなく、少しずつ続ける前提に置き換える発想です。

作らない選択と、続ける前提の計画。この2つを合わせて持てるかどうかが、依頼された側の実力として見られる部分です。Remoguでは、案件の90%以上がフルリモート可能です。運用の中で積み重ねてきた経験を、まず登録して自分に合う条件と照らし合わせてみることが、次の一歩になります。

出典：政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針（デジタル庁、2026年）をもとに作成

構成を作り替えないと、費用は下がりませんか

この方針が示すとおり、運用側だけでも複数の手があります。システム運用が従前のままではコスト削減効果は十分に発現しないと記されたうえで¹、利用料の確認、止まっている分の整理、自動化、監視と体制の見直し、削除と契約確認という、構成を変えずに着手できる手が並んでいます。

どこから手を付ければよいか迷います

この方針の並び順どおり、まず利用料を定期的に確認することから始めると³、次に見る場所が自然に見えてきます。全部を同時に進めようとしないことが、続けやすさにつながります。

この経験は、どんな案件で活きますか

運用の確認や自動化、体制の見直しに携わってきた経験は、費用の相談を受ける立場の案件で活きる範囲です。自分の経験がどの案件に近いかは、実際の案件情報を見て確かめるのが早い方法です。まず登録して、条件を照らし合わせてみましょう。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」出発点（2026年）
＊2 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」方針の位置づけ（2026年）
＊3 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」1つ目（2026年）
＊4 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」2つ目（2026年）
＊5 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」3つ目（2026年）
＊6 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」4つ目（2026年）
＊7 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」5つ目（2026年）
＊8 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」6つ目（2026年）
＊9 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」8つ目（2026年）
＊10 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」9つ目（2026年）
＊11 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」10番目（2026年）
＊12 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」片付け（2026年）
＊13 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」契約の確認（2026年）
＊14 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」作らない選択（2026年）
＊15 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」波及する削減（2026年）
＊16 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」見積りの前提（2026年）
＊17 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」計画の作り方（2026年）
＊18 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」更新の捉え方（2026年）