ガバメントクラウドとは？自治体が使う仕組み・対象サービス・費用負担を解説【2026年版】

ガバメントクラウドは、国の機関と地方公共団体が共通で使うクラウドの利用環境です。デジタル庁はこれを「政府共通のクラウドサービスの利用環境」と位置づけ、迅速かつ柔軟でセキュアなシステムを構築できる基盤として整備してきました。

ただし自治体の担当者から見ると、どこまでが国の役割で、どこからが自団体の負担になるのかが見えにくい仕組みでもあります。この記事では、定義と対象範囲、調達の構造、費用の流れ、そして2026年時点の移行状況までを順に整理し、自団体がどう構えるかの判断材料までをまとめました。標準化される20業務そのものの中身については自治体システムの標準化とは？20業務の移行と期限経過後の実務を解説で扱っています。

まとめ

• ガバメントクラウドは、デジタル庁が整備する政府共通のクラウド利用環境です。特定の製品名ではなく、公募と審査を通過したクラウドサービス群の総称にあたります。
• 対象クラウドサービスは年度ごとの募集で決まります。令和4年度は2022年10月3日、令和5年度は2023年11月28日、令和8年度は2026年3月27日に結果が公表されました。
• 自治体はクラウド事業者と直接契約するのではなく、利用量に応じた費用をデジタル庁へ支払い、デジタル庁が事業者へまとめて支払う経路をとります。
• 標準化の対象は政令で指定された20業務です。原則の移行期限は令和7年度末でしたが、2026年3月末時点で10,013システムが期限内に移行できていません。
• 期限内の移行が難しいものは特定移行支援システムとして扱われ、省令で新たな期限が設定されたうえで、概ね5年以内の移行が目指されています。
• 運用経費を2018年度比で3割削減する目標は掲げられていますが、達成の見通しは2026年時点でも不透明との報道が続きます。移行そのものを目的化しない設計が求められます。

ガバメントクラウドとは何かを制度上の位置づけと対象範囲から整理する

言葉の輪郭が曖昧なまま議論が進みやすい領域なので、まず定義と範囲を確定させます。

政府共通のクラウド利用環境という定義が置かれた背景を押さえる

ガバメントクラウドは、デジタル庁の資料で「政府共通のクラウドサービスの利用環境」と説明されています。ここで押さえておきたいのは、これが特定のクラウド製品を指す固有名詞ではないという点です。国が定めた要件を満たすと認められたクラウドサービス群と、それを政府・自治体が使うための調達・契約・技術の枠組み全体を合わせた呼び名にあたります。

背景にあるのは、府省や自治体がそれぞれ個別にサーバーを調達し、個別に運用してきた構造への反省でした。同じような住民情報システムを1,700を超える団体が別々に発注すれば、費用も人手も分散します。加えて、機器の更新期が来るたびに調達手続きが発生し、そのたびに仕様の差が積み上がっていきました。

そこで、共通の基盤を国がまとめて用意し、各団体はその上にシステムを載せる形へ切り替える方針が採られます。デジタル庁は令和5年度の調達で305項目の技術要件を提示しており、情報セキュリティとデータ保存の安全性が必須の基準として置かれました。個々の団体が自力で審査しきれない水準の要件を、国側で一度に検証する構造だと捉えると分かりやすいでしょう。

なお、行政のネットワーク側の仕組みであるLGWANとは層が異なります。LGWANは団体間を結ぶ閉域ネットワークで、ガバメントクラウドはシステムを載せる計算基盤です。両者の関係はLGWAN（総合行政ネットワーク）とは何か？その仕組み・機能、セキュリティや自治体における役割を徹底解説で詳しく整理しています。

対象クラウドサービスの顔ぶれと決定時点を公式の一次情報で確認する

対象クラウドサービスは、デジタル庁が募集をかけ、技術要件への適合を審査したうえで決定されます。年度ごとに募集が行われるため、顔ぶれは固定ではありません。

2026年時点で名前が挙がるのは、Amazon Web Services、Microsoft Azure、Google Cloud、Oracle Cloud Infrastructureの海外系4サービスと、国内事業者であるさくらインターネットの「さくらのクラウド」です。さくらインターネットは2026年3月27日、自社サービスが令和5年度および令和8年度の募集双方で対象クラウドサービスとして採択されたと公表しました。

ここで注意したいのが、対象に入っていることと自団体で使えることが同義ではない点です。標準準拠システムを提供するベンダーが、どのクラウドサービス上で製品を動かしているかによって、実際の選択肢は絞られます。団体側が先にクラウドを選び、後からベンダーを探す順序では行き詰まりがちでした。

また、対象サービスの一覧は年度をまたいで更新されます。調達仕様書を作る段階では、その時点でのデジタル庁の公表資料を必ず確認してください。数年前の資料を引き写したまま進めると、条件が変わっていた場合に手戻りが生じます。

国内事業者が加わった意味も押さえておきたいところです。ガバメントクラウドの議論では、行政データを海外資本の基盤に置くことへの懸念が繰り返し提起されてきました。技術要件を満たす国内サービスが対象に入ったことで、団体側は要件と事業者の所在という2つの軸で検討できるようになります。ただし、標準準拠システムの製品が対応しているクラウドは限られるため、この軸だけで決められる場面はまだ多くありません。

自治体がガバメントクラウドを使う仕組みを調達と契約の流れで捉える

定義よりも実務に効くのが、誰が何を調達し、誰と契約するのかという構造です。

デジタル庁が一括して整備し地方公共団体が利用する構造を分解する

従来の自治体クラウドでは、団体または団体の共同グループが、事業者と直接契約してクラウド環境を確保していました。ガバメントクラウドではこの部分が変わります。クラウドサービスの調達はデジタル庁が担い、各団体はデジタル庁が整備した環境上に自団体の領域を割り当てられる形になりました。

この構造には利点と制約が同居します。利点は、価格交渉と技術審査を国がまとめて担うため、団体単位では取りにくい条件を引き出せる点です。305項目の技術要件を各団体が個別に評価する必要はなくなりました。

一方の制約は、クラウド側の仕様に対して団体が独自の要求を差し込みにくくなることでしょう。共通基盤である以上、個別の団体の都合で構成を変える余地は限られます。これまで自前のデータセンターで柔軟に対応してきた運用が、そのままでは通らない場面が出てきます。

契約の相手方も整理が要ります。クラウド基盤そのものはデジタル庁経由ですが、その上で動く標準準拠システムは、団体がベンダーと個別に契約します。つまり団体は、基盤側とアプリケーション側で異なる相手と向き合うことになりました。障害が起きたときの切り分けと責任分界を、契約段階で文書化しておく必要があります。

この分界は、住民サービスが止まったときに効いてきます。窓口で証明書が発行できない状況で、原因が基盤側にあるのかアプリケーション側にあるのかを判定できなければ、復旧の指示先すら決まりません。契約書に「一次窓口をどこに置くか」「切り分けの結果が出るまでの暫定対応を誰が担うか」を書き込んでおくと、初動の迷いが減ります。障害時の連絡経路を年に一度は机上で確認しておく運用も、あわせて用意しておきたいところです。

単独利用と共同利用の使い分けを団体規模と運用体制の条件から考える

ガバメントクラウド上の利用形態は、団体が単独で領域を持つ形と、複数団体で共同利用する形の両方が想定されています。どちらを選ぶかで、費用と自由度のバランスが変わりました。

単独利用は、自団体だけで環境を持つため、更新のタイミングや構成の判断を自分たちで握れます。反面、基盤の運用にかかる費用と人手を自団体で負担しなければなりません。クラウド上の資源は使った分だけ課金されるので、設計が甘いと想定を超える請求につながります。

共同利用は、複数団体で環境と費用を分け合う形です。規模が小さく、情報部門に専任者を置けない団体では現実的な選択になります。ただし、更新の時期や仕様の決め方を他団体と揃える調整が発生し、自団体の都合だけでは動かせません。

判断の分かれ目は、団体の人口規模よりも情報部門に技術判断ができる人がいるかどうかにあります。クラウドの構成を読める人材が庁内にいない状態で単独利用に踏み込むと、ベンダーの提案をそのまま受け入れる運用に陥りがちです。

費用負担の仕組みと運用経費の見通しを自治体実務の数字から読み解く

制度の理解でつまずきやすいのが、お金がどの経路で動くのかという点でした。

利用料がデジタル庁を経由して事業者へ支払われる経路を整理する

自治体がガバメントクラウドを使ったときの費用は、団体がクラウド事業者へ直接振り込む形ではありません。団体は利用量に応じた額をデジタル庁へ支払い、デジタル庁が事業者へまとめて支払います。国が窓口となって取引を集約する構造です。

この経路には、団体側にとって分かりにくい面があります。従量課金の内訳がデジタル庁を挟んだ先にあるため、どの資源がどれだけ費用を生んでいるかを団体が把握しづらいのです。請求額だけを見て「高い」と判断しても、削るべき対象が特定できません。

対処としては、システムを載せる段階でベンダーに資源構成の内訳を出させ、それを団体側の資料として残しておく方法があります。仮想サーバーの台数と規模、ストレージ容量、通信量の見込みを分けて記録しておけば、増減の原因を後から追えます。移行時の実務手順はデジタル庁が求めるガバメントクラウドの全体像と自治体が直面する移行期限でより詳しく解説しました。

もう一点、費用は移行の初期に跳ねやすい構造にあります。旧環境と新環境を並行して動かす期間が生じるためです。単年度の予算だけで判断せず、並行稼働の月数を含めた複数年の見込みを立ててください。

見落とされがちなのが、通信量に対する課金でした。クラウドから外部へデータを送り出す量に応じて費用が発生する料金体系が一般的で、帳票の一括出力やバックアップの外部保管といった処理を毎月大量に回すと、想定外の額が積み上がります。移行前に、月次でどれだけのデータが庁外へ出るのかを概算しておくと、設計段階で手を打てました。

運用経費を3割削減するという政府目標と自治体現場の実感が離れる理由

標準化の基本方針では、運用経費を2018年度比で3割削減する目標が掲げられました。ところが2026年時点でも、この達成見込みは不透明との報道が続いています。目標と実感が離れる理由は、いくつかの構造にあります。

第一に、クラウドの費用は使った分だけ増えます。オンプレミスの機器は買い切りで、償却が進めば帳簿上の負担は下がっていきました。従量課金ではその効果が働かず、利用が続く限り支払いも続きます。

第二に、移行の作業費が別途かかりました。データの移し替え、帳票の再設計、職員の再教育といった費用は運用経費の削減分を先に食う性質のものです。削減効果が現れるのは、これらが一巡した後になります。

第三に、標準準拠システムに寄せた結果として、これまで独自に作り込んでいた機能を外部の仕組みで補う必要が出るケースがありました。補完のための追加調達が発生すれば、総額は思ったほど下がりません。

したがって、3割削減という数字を単年度の指標として追うのは実態に合わないでしょう。移行完了後に運用が定常化してからの年額で比較し、初期費用は別枠で見る立て付けにしておくと、議会や住民への説明も筋が通ります。

移行期限と特定移行支援システムの扱いを2026年の実績値で確認する

期限をめぐる状況は、2025年度末を境に大きく変わりました。数字で押さえます。

令和7年度末という原則の移行期限が自治体でどこまで機能したかを見る

地方公共団体情報システム標準化法に基づき、標準化対象の20業務は原則として令和7年度末までに標準準拠システムへ移行することとされていました。この期限は基本方針で示され、各団体が計画を立てる基準になっています。

結果として、デジタル庁が2026年6月30日に公表した状況では、対象34,366システムのうち10,013システム、率にして29.1%が期限内に移行できませんでした。該当する団体は1,015に上ります。主な要因として挙げられたのは、システムエンジニアの不足でした。

つまり全体の約3割が期限を越えた計算になります。この規模は例外的な遅れというより、当初の計画自体が人的な供給量を織り込みきれていなかったことを示す数字だと読めます。特定の団体の努力不足に帰す話ではありません。

なお、一部の機能については2028年度末までに基準へ適合させることを条件とする経過措置も設けられました。期限が一律に切られているわけではない点は、計画を立て直すうえで押さえておきたいところです。

この数字は、これから計画を立てる団体にとっても材料になります。3割が期限を越えたという事実は、標準準拠システムの提供側と移行を担う技術者の供給が、需要に追いついていない状態を示すものだからです。自団体の計画を組むときは、ベンダーの見積もりに書かれた工期をそのまま信じるのではなく、着手の順番待ちが発生する前提で余裕を持たせるほうが安全でしょう。

特定移行支援システムに指定された団体が次の計画に置く実務論点

令和8年度以降の移行が避けられないものは、特定移行支援システムとして整理されます。該当するのは、メインフレームで動いているもの、個別開発の度合いが高いもの、事業者が撤退したものなどです。

この区分に入った場合、デジタル庁・総務省・制度所管省庁が団体から把握したスケジュールを踏まえ、省令で新たな移行完了の期限を設定します。目安として示されているのは概ね5年以内の移行でした。放置が許されるわけではなく、期限が引き直されると理解するのが正確です。

団体側が次に置くべき論点は3つあります。1つ目は、遅れの原因が技術なのか人手なのかの切り分けです。人手が理由なら、期限を延ばしても同じ制約に再びぶつかります。

2つ目は、現行システムを維持する費用の見積もりでした。移行が5年先になるなら、その間の保守契約と機器更新の費用が積み上がります。3つ目は、移行先のベンダーを確保できる時期の見通しです。同じ時期に多数の団体が発注へ動くため、順番待ちが起こります。この3点を並べたうえで、新しい期限の設定に臨むのが現実的な進め方になるでしょう。

自治体がガバメントクラウドへ踏み込む条件と急がない判断を切り分ける

ここからは、制度の説明ではなく判断の話をします。全団体が同じ速度で動く必要はありません。

自治体が単独利用へ踏み込む条件を庁内体制と業務量の観点で定める

単独利用を選んでよいのは、次の条件が揃った場合だと考えています。第一に、情報部門にクラウドの構成図を読み、ベンダーの提案に対して「なぜこの構成か」を問い返せる職員が最低1人いること。第二に、その職員が3年程度は異動しない見通しがあること。第三に、住民情報系以外にも独自のシステムを抱えており、共通仕様に合わせると業務が回らない領域が実在すること。

逆に、これらが揃わないまま単独利用へ進むと、構成の判断が事実上ベンダー任せになります。従量課金の環境でこれをやると、費用の妥当性を検証できない状態が固定化されました。共同利用のほうが、幹事団体と協議する過程で判断の材料が共有される分だけ健全に働く場面もあります。

体制面で不安が残る場合は、外部の設計支援を先に入れる方法も選択肢の一つです。一創では公共システム開発として、自治体向けの要件整理から標準準拠システムとの接続、移行後の運用体制づくりまでを請け負っています。単独利用と共同利用のどちらを選ぶかの段階から相談いただけます。

自治体が移行を急がない判断が成り立つ場面を契約条件付きで示す

期限が示されている以上、移行しない選択はありません。ただし、いつ動くかについては団体ごとの判断の余地があります。急がない判断が成り立つのは、次のような場面でした。

現行システムの保守期限がまだ数年残っており、かつベンダーの撤退予定がない場合。この状況で無理に前倒しすると、二重の費用を長く払うことになります。周囲の団体が発注に殺到している時期を外すという意味でも、待つ判断には合理性がありました。

また、標準準拠システムの製品側が、自団体の業務量に対する検証を終えていない場合も同様です。人口規模の大きい団体では、処理件数の想定が製品の検証範囲を超えることがあります。先行団体の稼働実績が出るのを待ってから動くほうが、結果的に手戻りは少なくなるでしょう。

反対に、待つ判断が通らないのは、現行機器の保守が切れている場合と、担当ベンダーが撤退を表明している場合です。この2つに該当するなら、他の条件が整っていなくても着手を優先してください。基盤が止まったときの復旧手段がない状態は、費用の議論以前の問題になります。

よくある質問

ガバメントクラウドと自治体クラウドは調達主体がどう違うのですか

調達の主体が違います。自治体クラウドは団体または共同グループが事業者と直接契約する形でした。ガバメントクラウドではデジタル庁がクラウドサービスを整備し、各団体はその環境を利用する構造になっています。費用も団体からデジタル庁へ支払う経路に変わりました。

ガバメントクラウドで使えるクラウドサービスは決まっているのですか

デジタル庁の募集と審査を通過したサービスに限られます。2026年時点ではAmazon Web Services、Microsoft Azure、Google Cloud、Oracle Cloud Infrastructure、さくらのクラウドの名前が挙がっています。募集は年度ごとに行われるため、調達の前にその時点の公表資料を確認してください。

移行が令和7年度末に間に合わなかった地方公共団体はどうなりますか

特定移行支援システムとして整理され、省令で新たな移行完了の期限が設定されます。概ね5年以内の移行を目指す方針が示されました。2026年3月末時点で1,015団体・10,013システムが該当しており、例外的な扱いではありません。

ガバメントクラウドへ移れば自治体の運用経費は本当に下がるのですか

2018年度比で3割の削減が目標に掲げられていますが、2026年時点でも達成の見通しは不透明とされています。移行期間中は旧環境との並行稼働で費用が増えるため、効果を測るなら移行完了後の定常運用の年額で比較するのが妥当です。

小規模な自治体でも庁内の運用体制を整えれば単独利用を選べますか

制度上は選べます。ただし基盤の運用費と人手を自団体で負担するため、情報部門に技術判断ができる職員がいない場合は共同利用のほうが現実的でしょう。判断の分かれ目は人口規模よりも庁内の体制にあります。

関連記事

• 自治体システムの標準化とは？20業務の移行と期限経過後の実務を解説
• デジタル庁が求めるガバメントクラウドの全体像と自治体が直面する移行期限
• LGWAN（総合行政ネットワーク）とは何か？その仕組み・機能、セキュリティや自治体における役割を徹底解説