2026.08.04 DX

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

ガバメントクラウドは、国の機関と地方公共団体が共通で使うクラウドの利用環境です。デジタル庁はこれを「政府共通のクラウドサービスの利用環境」と位置づけ、迅速かつ柔軟でセキュアなシステムを構築できる基盤として整備してきました。ただし自治体の担当者から見ると、どこまでが国の役割で、どこからが自団体の負担になるのかが見えにくい仕組みでもあります。この記事では、定義と対象範囲、対象採択の技術要件、調達と契約の構造、費用の流れ、政令で定める20業務と経過措置、そして2026年時点の移行実績までを、デジタル庁と内閣府の公表資料の数値で順に整理し、自団体がどう構えるかの判断材料までをまとめました。標準化される20業務そのものの中身については自治体システムの標準化とは？20業務の移行と期限経過後の実務を解説で扱っています。

まとめ：ガバメントクラウドの定義と自治体が負う費用・期限の要点

ガバメントクラウドは、デジタル庁が整備する政府共通のクラウド利用環境です。特定の製品名ではなく、公募と審査を通過したクラウドサービス群の総称にあたります。
対象クラウドサービスは年度ごとの募集で決まります。令和4年度は2022年10月3日、令和5年度は2023年11月28日、令和8年度は2026年3月27日に結果が公表されました。令和8年度の選定はAmazon Web Services、Google Cloud、Microsoft Azure、Oracle Cloud Infrastructure、さくらのクラウドの5件です。
対象になる条件は、ISMAPクラウドサービスリストへの登録と、生成AI機能の6項目を除く技術要件305項目の充足です。未充足でも計画の提出で審査が続く猶予の仕組みがあります。
自治体はクラウド事業者と直接契約するのではなく、利用量に応じた費用をデジタル庁へ支払い、デジタル庁が事業者へまとめて支払う経路をとります。
標準化の対象は政令で指定された20業務です。一部の機能には経過措置があり、2028年度末までに機能標準化基準へ適合させることが条件になります。
原則の移行期限は令和7年度末でした。2026年6月30日公表の実績では、全34,366システムのうち24,353システム（70.9%）が移行を終え、10,013システム（29.1%）・1,015団体が期限に届いていません。
期限内の移行が難しいものは特定移行支援システムとして扱われ、主務省令で新たな期限が設定されたうえで、概ね5年以内の移行が目指されます。令和8年度末までに全体の約90%が移行を終える見込みです。
運用経費を2018年度比で少なくとも3割削減する目標は掲げられていますが、達成の見通しは2026年時点でも不透明との報道が続きます。移行そのものを目的化しない設計が求められます。

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

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

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

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

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

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

なお、行政のネットワーク側の仕組みであるLGWANとは層が異なります。都市空間のデータを扱う都市OSとも役割が別で、その線引きはスマートシティとは？政府定義と都市OSの成熟レベル1〜4で整理しました。LGWANは団体間を結ぶ閉域ネットワークで、ガバメントクラウドはシステムを載せる計算基盤です。両者の関係はLGWAN（総合行政ネットワーク）とは何か？その仕組み・機能、セキュリティや自治体における役割を徹底解説で詳しく整理しています。

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

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

募集年度	審査結果の公表時点	備考
令和4年度	2022年10月3日	2023年4月3日に改訂
令和5年度	2023年11月28日	305項目の技術要件を提示
令和8年度	2026年3月27日	5サービスを選定

デジタル庁が公表した令和8年度募集の審査結果に並ぶのは、Amazon Web Services、Google Cloud、Microsoft Azure、Oracle Cloud Infrastructureの海外系4サービスと、国内事業者であるさくらインターネットの「さくらのクラウド」です。さくらのクラウドは令和5年度の募集で条件付きの採択となり、令和8年度の募集でも選定されました。対象への採択は技術要件の充足を示すもので、データ主権が確保されていることとは別の論点です。運用主体と準拠法から見た切り分けはソブリンクラウドとガバメントクラウドの違いで整理しています。

ここで注意したいのが、対象に入っていることと自団体で使えることが同義ではない点です。標準準拠システムを提供するベンダーが、どのクラウドサービス上で製品を動かしているかによって、実際の選択肢は絞られます。団体側が先にクラウドを選び、後からベンダーを探す順序では行き詰まりがちでした。対象となる5サービスの公募年度別の適合状況と、選定で先に決めるべき順序はガバメントクラウドの対応ベンダー5社と選定基準で整理しています。

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

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

技術要件305項目とISMAP登録という対象採択の前提条件を確認する

「305項目」という数字だけが一人歩きしがちですが、令和8年度募集の調達仕様書を読むと、内訳と例外がはっきり書かれています。まず入口の条件が、政府情報システムのためのセキュリティ評価制度であるISMAPのクラウドサービスリストに登録されていることです。ISMAPという制度そのものの仕組みと登録の流れはISMAPとは？クラウドサービスリスト・管理基準・費用の解説で整理しました。ここに登録がなければ、機能面をどれだけ満たしても土俵に上がれません。

技術要件は別紙1「基本事項」、別紙2「サービス要件（基本）」、別紙3「サービス要件（データ連携や高度なセキュリティ等）」の3つに分かれます。このうち別紙3の生成AI機能に係る6項目（項番74から79）を除いた305項目が、対象採択の判定軸に置かれました。305という数は総項目数ではなく、生成AI分を差し引いた後の数だという点は押さえておきたいところです。

猶予の仕組みも用意されています。305項目を満たしていない事業者でも、令和8年9月末までに全要件を満たす計画を提出し、デジタル庁が対象に加われると判断すれば審査が続きます。1社単独ではなく複数社のクラウドサービスを組み合わせた共同提案も認められており、その場合は技術的ガバナンス、課金・決済、不具合発生時の最終責任を主幹事業者が引き受ける建て付けです。共同提案では全事業者がISMAPクラウドサービスリストに登録されていることが条件になります。

除外された生成AI機能6項目は、別枠で扱われました。国外のAI推論環境については、ガバメントクラウド本体と管理範囲を完全に分離し、環境・設定テンプレート・管理権限・管理画面・ログ管理・支払いを別に管理する設計が示されています。推論の実行はできるものの、情報資産の永続的な保管はできないと明記されました。行政側の生成AI基盤そのものの動きはガバメントAI「源内（げんない）」とは？使い方・何ができるかとデジタル庁の生成AI基盤を解説で扱っています。

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

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

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

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

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

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

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

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

契約期間と準拠法・撤退時のデータ返還を調達仕様書の条文で押さえる

団体が直接の契約当事者にならないぶん、デジタル庁と事業者の間でどんな条件が結ばれているかは見えにくくなります。調達仕様書に書かれた条件のうち、団体側の計画に直結するものを3つ挙げます。

1つ目は契約期間です。クラウドサービスを提供する事業者が電気通信事業法第9条の登録、または同法第16条第1項の届出を行っている場合、契約期間は契約締結日から最長で令和13年3月31日までとされました。これに該当しない事業者は令和9年3月31日までです。基盤の継続性を何年先まで前提にできるかが、この区分で変わります。

2つ目は準拠法と裁判管轄でした。原則として準拠法は日本法、国際裁判管轄は東京地方裁判所と定められています。海外資本のクラウドを使う場合でも、契約上の紛争解決は国内の枠組みに置かれる建て付けです。データの物理的な保管場所や運用主体の国籍とは別の話なので、両者を混ぜて説明しないよう気をつけてください。

3つ目が撤退時の扱いです。クラウドサービスの廃止やサービス内容の変更で契約を終了する場合、事業者は原則として1年以上の期間をもって事前にデジタル庁へ通知することとされました。1年に満たない場合は、稼働中システムの移行期間を考慮した対策方法を提示してデジタル庁と協議します。契約終了時のデータは、汎用性のあるデータ形式に変換して提供したうえで、クラウド上では復元できないよう抹消し、その結果を書面で報告する義務が置かれました。

団体側の実務としては、この3点を自団体の中期計画に写しておくと効きます。基盤側の契約期間の終期、撤退通知が来た場合に自団体へ伝わる経路、データ形式の受け取り方の3つを、標準準拠システムのベンダーとの契約書にも対応する条項として置いておくと、基盤側の変更が起きたときに動き出しが早くなります。

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

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

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

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

観点	単独利用	共同利用
構成の自由度	自団体で判断できる	参加団体と調整が要る
費用の負担	全額を自団体で負担	参加団体で分担する
必要な体制	専任の担当者が要る	幹事団体に依存しやすい
向く団体規模	中核市以上が中心	小規模団体が中心

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

標準化対象20業務と経過措置の適用範囲を移行計画の観点で仕分ける

ガバメントクラウドの話は、載せる中身である標準準拠システムの範囲と一体で考えないと計画が組めません。

政令で指定された20業務の内訳と自団体が先に着手すべき業務の順序

標準化の対象は、地方公共団体情報システムの標準化に関する法律（令和3年法律第40号）に基づき、政令で指定された事務です。デジタル庁の地方公共団体の基幹業務システムの統一・標準化のページには、現時点で20の事務が政令で指定されていると記載されています。

住民記録系：住民基本台帳、戸籍、戸籍の附票、印鑑登録、選挙人名簿管理、就学
地方税系：固定資産税、個人住民税、法人住民税、軽自動車税
福祉・医療系：児童手当、子ども・子育て支援、児童扶養手当、生活保護、障害者福祉、介護保険、国民健康保険、後期高齢者医療、国民年金、健康管理

着手の順序は、2026年6月30日にデジタル庁が公表した業務別の傾向が手がかりになります。同資料では、従前から標準化が進み他業務と独立して構築されている戸籍・戸籍の附票と、主要ベンダー数が少ない生活保護は、移行作業が進めやすく期限に届かなかったシステムが少なかったと分析されました。逆に、住民情報系と地方税系ではリソースの逼迫で400から500程度が期限に届かず、児童手当・子ども・子育て支援・介護保険といった福祉系は、住民情報系の影響に加えて福祉系だけを提供する主要ベンダーの事情が重なり、該当がより多くなっています。

この分布から導ける順序は明快です。福祉系と住民情報系を先に押さえ、戸籍系を後ろに回してください。混み合う領域ほどベンダーの着手が遅れるため、余裕がある業務を先に片付ける組み方は逆効果になります。20業務それぞれの中身と移行実務は自治体システムの標準化とは？20業務の移行と期限経過後の実務を解説にまとめました。

一部機能の経過措置が使える2つの要件と2028年度末という期限

期限の話には、システム単位の期限とは別に、機能単位の経過措置があります。2024年12月に改定された地方公共団体情報システム標準化基本方針の改定資料では、標準仕様に対応したシステムへの移行を完了させることを前提に、一部の機能について移行後の実装を可能にする経過措置が設けられました。

対象になる要件は2つです。1つは、データ要件・連携要件に関する標準化基準に適合し、標準化されたデータを他システムから扱える状態になっていること。もう1つは、制度所管省庁と地方公共団体の双方が当該機能の経過措置の必要性を認め、遅くとも令和10年度（2028年度）末までに機能標準化基準へ適合するものであることです。

この2要件は、団体が単独で判断できるものではありません。データ連携の側が先に基準を満たしていることが入口になるため、機能の作り込みを後回しにする代わりにデータ要件は前倒しで固める、という組み替えが必要になります。経過措置の対象となった機能を標準化基準上どう扱うかは、制度所管省庁が令和9年度（2027年度）末までに検討することとされました。取扱いが確定する前に自団体の独自機能を経過措置へ寄せると、後から判断が覆るおそれがあります。

経過措置を当てにしてよいのは、制度所管省庁との協議の場に自団体の要望が上がっている場合に限ります。庁内で「この機能は経過措置で残せるはず」と判断しているだけの状態は、根拠になりません。

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

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

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

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

この経路には、団体側にとって分かりにくい面があります。従量課金の内訳がデジタル庁を挟んだ先にあるため、どの資源がどれだけ費用を生んでいるかを団体が把握しづらいのです。請求額だけを見て「高い」と判断しても、削るべき対象が特定できません。なお調達仕様書では、事業者が毎月の利用量と利用料金の確定後に前月分の実績レポートをデジタル庁へ提出することが定められており、粒度の細かい実績は国側に集まる建て付けになっています。

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

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

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

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

標準化の基本方針では、標準準拠システムへの移行完了後に運用経費等を平成30年度（2018年度）比で少なくとも3割削減する目標が掲げられました。ところが2026年時点でも、この達成見込みは不透明との報道が続いています。目標と実感が離れる理由は、いくつかの構造にあります。

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

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

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

デジタル庁が内閣府の会議へ提出した地方公共団体の基幹業務システムの統一・標準化についての資料でも、増加要因は3層に整理されています。機能強化の要因（非機能要件の標準への適合、標準仕様書への対応に伴う機能増強）、構造的な要因（基盤とネットワークの二重化、パッケージがクラウド前提に作り替えられていないこと、接続回線費や運用管理補助委託費といった新たな経費）、そして外部要因（物価上昇、賃上げによる人件費増、為替）です。3層のうち団体側の努力で動かせるのは構造的な要因の一部だけだ、という前提で議会や住民への説明を組み立ててください。

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

デジタル庁の総合的な対策から自治体が今すぐ使える支援を選び出す

費用の増加に対しては、令和7年6月13日のデジタル行財政改革会議に報告され、同日にデジタル庁が決定した「自治体情報システムの標準化・ガバメントクラウド移行後の運用経費に係る総合的な対策」が置かれています。当面の対策と構造的な対策が並びますが、団体が今日から使える窓口はそう多くありません。実務で先に手を伸ばすべきものを2つに絞ります。

1つ目は、デジタル庁内に立ち上げられた見積精査の支援チームです。ガバメントクラウドの利用料だけでなく運用経費全体について団体からの相談に応じる体制とされており、庁内だけでは見積の妥当性を判定できない場面で使えます。予算措置も新規調達も要らないので、着手の障壁がいちばん低い手段になります。

2つ目は、事業者への説明要求です。総合的な対策では、事業者に対して「可能な限り精緻な見積書を提出すること」「増加理由をできるだけ分かりやすく説明すること」を国から働きかけると明記されました。この記載は、団体が見積書に増加理由の内訳を求める際の根拠として使えます。口頭で「高い」と伝えるより、国の対策文書を引いて書面で求めるほうが通りは良くなります。

このほか、令和7年度中にFinOpsのガイドを作成すること、クラウド利用料の大口割引等の拡充を交渉すること、利用料をダッシュボードで見える化して費用を抑える仕様・要件案をガイドすること、令和7年4月公開の「ガバメントクラウドにおけるSaaS（公共SaaS）について」を踏まえて基盤と業務の一体調達へ進むことが挙げられています。クラウド費用を継続的に見直す手法そのものはFinOpsとは？クラウドコスト管理の仕組み・3フェーズと導入判断を解説で扱いました。

逆に、当てにしないほうがよいものもあります。事業者間の競争進展や優良システムの長期継続利用は中期的なトレンドとして期待される項目に置かれており、いま組む予算の根拠には使えません。2026年度から2027年度の予算要求では、削減を織り込まず横ばいで積むほうが安全です。

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

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

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

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

結果として、デジタル庁が2026年6月30日に公表した移行支援期間における特定移行支援システムの数についての資料では、対象34,366システムのうち10,013システム、率にして29.1%が期限内に移行できませんでした。該当する団体は1,015で、全1,788団体の56.8%にあたります。差し引き24,353システム（70.9%）は移行を終えており、数字の出どころは総務省の標準化PMOツールです。

同資料が挙げた主因は、移行期限が迫るにつれて移行作業とその直後の運用に想定以上のシステムエンジニアが必要だと判明し、事業者が移行スケジュールを大幅に見直したことでした。工程そのものの見積もりが実態と合っていなかった、という説明です。今後の見通しとしては、令和8年度末までに全体の約90%が標準準拠システムへの移行を終える見込みが示されています。

約3割という規模は、例外的な遅れではありません。標準準拠システムの提供側と移行を担う技術者の供給が需要に追いついていない状態を示す数字です。自団体の計画を組むときは、ベンダーの見積もりに書かれた工期をそのまま信じるのではなく、着手の順番待ちが発生する前提で余裕を持たせてください。

事由別の内訳が示す遅延の正体と見込み値が実績で2.7倍になった経緯

10,013という数字は、4つの事由に分けて公表されています。内訳を見ると、遅延の性質が一目で分かります。

事由	システム数	該当団体数
メインフレームで運用	44	7
個別開発システム	190	26
現行事業者が開発せず	189	102
事業者のリソース逼迫	9,590	987
合計（重複排除）	10,013	1,015

技術的に移行が難しい事由1から事由3の合計は423システムで、全体の4.2%にすぎません。残る9,590システム、実に95.8%は事業者のリソース逼迫による遅延です。レガシー資産の重さが原因だという語られ方をしがちですが、数字が指しているのは人手の供給量でした。

もう一つ押さえたいのが、見込み値の動き方です。デジタル庁が令和7年9月30日に公表した令和7年7月末時点の調査では、対象34,592システムのうち3,770システム（10.9%）が特定移行支援システムに該当する見込みとされ、団体数は1,788団体中643団体（36.0%）でした。それが移行支援期間の終期には10,013システム・1,015団体になっています。約8か月でシステム数は2.7倍、団体数は1.6倍に膨らみました。対象システムの総数も、自治体への最終確認の結果、34,592から34,366へ改められています。

この動き方から引き出せる教訓は1つです。移行の半年前や8か月前に事業者から示される見込みは、そのまま計画の前提にできません。特に事由4に該当しうる案件、つまり大手ベンダーのパッケージに載っていて自団体固有の事情が少ない案件ほど、他団体との順番待ちの影響を後から受けます。順調だと報告されている案件こそ、四半期ごとに着手予定日を書面で確認しておくほうがよいでしょう。

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

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

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

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

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

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

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

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

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

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

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

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

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

現行システムの保守期限がまだ数年残っており、かつベンダーの撤退予定がない場合。この状況で無理に前倒しすると、二重の費用を長く払うことになります。周囲の団体が発注に殺到している時期を外すという意味でも、待つ判断には合理性がありました。移行そのものの進め方はクラウド移行の進め方｜計画から移行方式・費用・切り替えまでの手順を発注者視点で解説で発注者の目線から整理しています。

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

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

よくある質問

自治体の担当者から寄せられることの多い疑問を、公表資料の記載に沿って整理しました。

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

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

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

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

ガバメントクラウドの対象採択に必要な技術要件は何項目ありますか

令和8年度募集の調達仕様書では、生成AI機能に係る6項目（項番74から79）を除く技術要件305項目が判定軸に置かれました。前提としてISMAPクラウドサービスリストへの登録も条件です。305項目を満たしていない場合でも、令和8年9月末までに全要件を満たす計画を提出すれば審査が続く猶予の仕組みがあります。

標準化の対象となる20業務はどの法令で決められているのですか

地方公共団体情報システムの標準化に関する法律（令和3年法律第40号）に基づき、標準化対象事務が政令で指定されています。デジタル庁のページには現時点で20の事務が指定されていると記載され、住民基本台帳や戸籍などの住民記録系、固定資産税や個人住民税などの地方税系、介護保険や国民健康保険などの福祉・医療系が含まれます。