自治体システム標準化、期限後も終わらない移行——未移行と運用経費増にどう備えるか｜2026年最新動向

自治体システム（基幹20業務）標準化の移行原則期限である2026年3月末（令和7年度末）を過ぎても、すべての自治体・システムが移行を完了したわけではない。 期限内に間に合わず2026年度以降にずれ込む「特定移行支援システム」が一定数残り、その見込み件数は時点を追うごとに増えている（デジタル庁公表・日経xTECH報道）。標準化は「号令で一斉に切り替える」局面から、「未移行の積み残しを着実に消し込みつつ、移行後のクラウド運用経費をどう抑えるか」という地に足の着いた実務フェーズへ移った。自治体DX担当にとっても、公共向けベンダーにとっても、ここからが継続的な需要の本番である。

この記事の要点

• 自治体システム標準化の移行原則期限は2026年3月末（令和7年度末）。期限後も移行が終わらない「特定移行支援システム」が残る。
• 「特定移行支援システム」の見込み件数は時点を追って増加。デジタル庁公表（日経xTECH報道｜二次）によれば、2025年1月末時点見込み約2,989件（8.6%）→10月末時点見込み5,009件（14.5%）／743団体（41.6%）→12月末時点見込み約8,956件（25.9%）／自治体数は過半とされる。
• 実務課題は「未移行の解消」と「移行後の運用経費増」の二正面。どちらも自治体・ベンダー双方に継続需要を生む。
• 期限超過を「失敗」と捉えず、移行方式の再選定・クラウド運用最適化・データ移行の品質管理を計画的に進めることが鍵。

標準化は「期限を過ぎても終わらない」局面に入った

地方公共団体の情報システムの標準化は、住民記録・地方税・国民健康保険・介護保険など基幹20業務を対象に、国が定める標準仕様に準拠したシステムへ移行する取り組みである。移行の原則期限は2026年3月末（令和7年度末）とされてきた。

しかし2026年に入ってからの各種公表で明らかになったのは、すべての自治体・システムが期限内に移行を完了できたわけではない、という現実だ。期限内の移行が難しく、2026年度以降にずれ込むものは「特定移行支援システム」として整理されている。つまり標準化は終了したのではなく、「期限後フェーズ」に入ったと捉えるべきである。

これは民間のレガシー刷新で繰り返されてきた構図と重なる。期限という外圧で一斉に動き出しても、現場では「データ移行の難所」「業務の作り込み」「ベンダー・人材の逼迫」がボトルネックになり、最後の数%・数百システムが残る。民間の「2025年の崖」をめぐる議論でも同じことが起きており、2025年の崖を越えた今のレガシー刷新の進め方で整理したとおり、「期限を越えた＝完了」ではない点は公共・民間に共通する教訓だ。

未移行の見込みは「時点を追って増えている」——数値は時点とセットで読む

未移行（特定移行支援システム）の件数は、一つの固定値ではなく、集計時点ごとに公表される「見込み」であり、時点が新しくなるほど増加している点に注意が要る。デジタル庁の公表（日経xTECHが報道｜二次）をたどると、次のように推移している。

※いずれも各時点の「見込み」であり、確定値ではない。古い数値（2,989件）だけを見ると過小評価につながるため、新しい時点ほど件数・割合が増えていることを踏まえて読む必要がある。施策判断に使う場合は、必ず最新のデジタル庁・総務省の公式資料で原典を確認してほしい。

直近の見込みでは全システムの約4分の1（25.9%）・自治体数では過半が期限後の移行を抱える計算になる。標準化は「ごく一部の例外が残った」話ではなく、「片付いた話題」でもない。これから数年単位で継続する実務である。

期限後に残る二つの実務課題

期限後フェーズで自治体と関連ベンダーが向き合う実務課題は、大きく二つに整理できる。

課題1：未移行システムの解消

期限内に移行できなかったシステムは、限られた要員・予算・移行スロットの中で順次消し込んでいく必要がある。ここでの典型的なつまずきは、(1) 旧システムからのデータ移行の品質（文字コード・住所表記・履歴データの整合）、(2) 自治体独自の作り込み（条例・運用ルールに依存した機能）の標準仕様への寄せ込み、(3) 移行作業を担うベンダー・人材の逼迫である。民間の基幹刷新でも同じ難所が繰り返されており、移行方式の選定そのものを誤ると、期限後の遅延がさらに長引く。移行方式の選び方は基幹システム刷新の進め方とコストの観点で早めに固めておきたい。

課題2：移行後のクラウド運用経費の増加

標準準拠システムはガバメントクラウド上での運用が前提となる。移行が完了しても、そこで終わりではなく、クラウド運用経費（ランニングコスト）の増加という新たな課題が生じうる。リソースの過剰割り当て、利用実態に合わないプラン、複数システムの共通基盤化が進まないことによる重複コストなどは、放置すれば毎年の運用費を押し上げる。移行後はクラウドの構成最適化・コスト可視化を継続的に回す体制が要る。クラウド前提の運用設計はクラウド移行と運用最適化の進め方として、移行プロジェクトと一体で計画するのが望ましい。

期限後フェーズの進め方——自治体・ベンダー共通のチェックリスト

期限超過を「失敗」と捉えて動きを止めるのではなく、残作業と運用を計画的に管理することが重要だ。自治体DX担当・公共向けベンダーが期限後フェーズで確認すべき要点を整理する。

• 未移行システムの棚卸し：どの業務・どのシステムが「特定移行支援システム」に該当するかを、最新の公式資料・各団体の状況に照らして正確に把握しているか。
• 移行スケジュールの再設定：2026年度以降の移行時期・移行スロット・ベンダー稼働を現実的に組み直しているか。希望的観測の日程になっていないか。
• データ移行の品質管理：移行元データの整備（名寄せ・文字コード・履歴整合）と、移行後の突合検証の手順が決まっているか。
• 独自作り込みの寄せ込み方針：標準仕様に合わない既存運用を、業務側で見直すのか、標準の範囲で代替するのかを早期に判断しているか。
• ガバメントクラウド運用経費の可視化：移行後のランニングコストを毎年モニタリングし、リソース最適化・プラン見直しのサイクルを回す体制があるか。
• ベンダー・要員の確保計画：期限後も移行・運用を担う人員が確保できているか。逼迫を前提に複数年の調達計画を立てているか。
• リスクの早期エスカレーション：遅延・障害・コスト超過の兆候を、責任者・国の支援窓口へ早めに上げる経路が機能しているか。

このチェックリストは、民間の基幹刷新で繰り返されてきた失敗の裏返しでもある。たとえばメインフレームやオフコンからの脱却で生じる移行リスクは、IBM i（AS/400）刷新のコストとロードマップでも整理しており、「期限・データ移行・運用コスト」という難所は技術スタックを問わず共通している。標準準拠移行の全体計画づくりにはシステム開発の構想・計画づくりの進め方も参考になる。

この記事を読むべき人

• 標準化移行が期限内に終わらず、2026年度以降の残作業を抱える自治体のDX・情報システム担当。
• 自治体向けに標準準拠システムの移行・運用を提供する公共向けベンダー・SIer。
• ガバメントクラウド上の運用経費の増加に頭を悩ませる自治体・ベンダーの実務責任者。
• 期限超過を踏まえ、移行方式の再選定やクラウド運用最適化の外部知見を求めている方。

移行の進め方やコスト構造を客観的に点検したい場合は、DX成熟度の診断で現状を可視化し、基幹刷新・システム開発の相談、移行後のデータ活用基盤を見据えるならデータ基盤の構築へと検討を広げてほしい。

よくある質問（FAQ）

Q1. 自治体システム標準化の移行原則期限はいつですか？

基幹20業務を対象とする自治体システム標準化の移行原則期限は、2026年3月末（令和7年度末）とされています。ただし期限内に移行が難しいものは「特定移行支援システム」として2026年度以降にずれ込む扱いとなっており、期限を過ぎても移行作業は続いています。

Q2. 未移行のシステムはどれくらい残っているのですか？

時点ごとの「見込み」として公表されており、新しい時点ほど増えています。デジタル庁の公表（日経xTECH報道｜二次）によれば、2025年1月末時点見込みで約2,989件（8.6%）、2025年10月末時点見込みで5,009件（14.5%）／743団体（41.6%）、2025年12月末時点見込みでは約8,956件（25.9%）・自治体数では過半とされています。古い数値だけを見ると過小評価につながるため、最新は各公式資料で確認してください。

Q3. 移行が終われば運用コストは下がりますか？

必ずしもそうとは限りません。標準準拠システムはガバメントクラウド上での運用が前提となり、移行後はクラウド運用経費（ランニングコスト）の増加が新たな課題になりうると指摘されています。リソースの最適化やコスト可視化を継続的に行わないと、毎年の運用費が想定以上に膨らむ可能性があります。

Q4. 期限を過ぎてしまった場合、まず何から手を付けるべきですか？

まず未移行システムの正確な棚卸しと、現実的な移行スケジュールの再設定です。そのうえで、データ移行の品質管理、独自作り込みの寄せ込み方針、移行後のクラウド運用経費の可視化を計画に織り込みます。要員・ベンダーの逼迫を前提に複数年の調達計画を立てることも重要です。外部の知見が必要な場合は構想段階からの相談をおすすめします。

まとめ

自治体システム標準化は、2026年3月末の移行原則期限を過ぎてもなお「終わらない移行」を抱える局面に入った。特定移行支援システムの見込み件数は時点を追って増加しており、デジタル庁公表（日経xTECH報道｜二次）では2025年1月末見込み約2,989件（8.6%）→10月末見込み5,009件（14.5%）／743団体（41.6%）→12月末見込み約8,956件（25.9%）・自治体数では過半とされる。相当数の自治体・システムが期限後の移行と、移行後のクラウド運用経費増という二正面の課題を抱えている。

ここからは、号令ではなく実務管理の勝負だ。未移行の着実な消し込み、移行方式の適切な選定、そしてガバメントクラウド上の運用最適化を、計画的に回せるかどうかが分かれ目になる。自社・自団体の状況に合わせて進め方を点検したいなら、まずはレガシー・基幹システム刷新の相談やクラウド移行と運用最適化、現状把握にはDX成熟度の診断から検討してほしい。

参考情報

• デジタル庁公表を報じた日経xTECH「自治体システム標準化、遅延が全システムの25.9％ 自治体数では過半」（二次報道。2025年12月末時点見込み約8,956件／25.9%）： https://xtech.nikkei.com/atcl/nxt/news/24/03115/
• 総務省 地方財政審議会提出資料「地方公共団体情報システムの標準化・ガバメントクラウドについて」（2026年2月13日・一次情報／PDF。標準化と移行後の運用経費に関する資料）： https://www.soumu.go.jp/main_content/001063741.pdf
• ※2,989件（2025年1月末見込み）・5,009件／743団体（2025年10月末見込み）はデジタル庁公表として日経xTECH等が報じた数値（二次）。いずれも各時点の見込みであり、最新はデジタル庁・総務省の各公式資料で確認すること。

稟議・RFPに落とす90日アクションプラン

この記事の論点を実際の商談・稟議・RFPに落とす場合は、情報収集で止めず、30日・60日・90日の3段階で意思決定材料を作る。重要なのは、ベンダーに「何ができますか」と聞く前に、自社の現行業務、データ、権限、運用制約、セキュリティ要件を数字で出すことだ。生成AI、RAG、AIエージェント、業務システム、基幹システム、レガシー刷新、補助金活用のどれであっても、この順番を外すと見積り比較が崩れる。

一次情報も同じ表に残しておく。AIやセキュリティが絡む案件では、NIST AI Risk Management Framework、OWASP Top 10 for LLM Applications、IPA 情報セキュリティ、JPCERT/CC 注意喚起、個人情報保護委員会を参照し、製品固有の公式発表と並べて確認する。補助金や中小企業施策を使う場合は、中小企業庁の更新も確認する。

GXOに相談する場合は、現状資料が完全でなくてもよい。最低限、対象業務、利用中システム、月間件数、希望時期、予算レンジ、既存ベンダー、セキュリティ制約の7点があれば、要件定義・RFP・ベンダー比較・AI開発・セキュリティ・レガシー刷新の優先順位を整理できる。

実装後に追うKPIとベンダー比較軸

対策を始める前に、導入後の測定方法を決めておく。AI開発、業務システム、セキュリティ、補助金活用、レガシー刷新のいずれでも、成果が測れない投資は次の改善につながらない。特に経営説明では「導入したか」ではなく「どの数字がどう変わったか」が問われる。最低限、次の5項目を月次で追える状態にしたい。

ベンダー比較では、金額だけでなく、要件定義、RFP回答、PoC、保守、セキュリティ、データ移行、教育、運用改善を同じ表で見る。見積りが安くても、要件定義が薄い、ログが残らない、引き継ぎ資料がない、保守範囲が曖昧であれば、90日後に追加費用が発生しやすい。

問い合わせ前に整理する情報は7点でよい。対象業務、月間件数、担当人数、既存システム、希望時期、予算レンジ、制約条件。この7点があれば、GXO側で要件定義、RFP、ベンダー選定、AI開発、RAG、セキュリティ、補助金、レガシー刷新のどこから着手すべきかを切り分けられる。未整理のまま相談しても構わないが、1時間の初回相談でこの7点を埋めるだけでも、次のアクションはかなり明確になる。

失敗を早く見つけるレビュー運用

導入後のレビューは「最後に品質を見る場」ではなく、30日ごとに前提を直す運用にする。初月は対象を1業務に絞り、2ヶ月目に例外処理を増やし、3ヶ月目に本番運用の責任分界を確定する。AI開発やRAGであれば回答ログ、業務システムであれば操作ログ、セキュリティであれば検知ログ、補助金案件であれば効果測定の根拠を残す。ログがない案件は、効果も事故も説明できない。

GXOでは、このレビュー表を起点に、要件定義、RFP、ベンダー選定、AI開発、RAG、セキュリティ、レガシー刷新、補助金活用の優先順位を整理する。初回相談では、現状の課題を完璧にまとめる必要はない。業務フロー、画面、帳票、Excel、ログ、既存見積りのうち1つでもあれば、そこから不足情報を洗い出せる。

相談前にそろえる7つの材料

最後に、社内相談・外部相談の前にそろえる材料を明確にしておく。完璧な資料は不要だが、次の7点があると、初回の1時間で論点をかなり絞れる。1. 対象業務、2. 月間件数、3. 現在の担当人数、4. 利用中システム、5. 既存の課題、6. 希望時期、7. 予算レンジ。この7点がないまま製品比較に入ると、要件定義もRFPも曖昧になり、ベンダー選定が価格比較に寄りやすい。

この材料は、AI開発、RAG、AIエージェント、セキュリティ、業務システム、レガシー刷新、補助金のどの相談でも共通して使える。GXOに相談する場合も、この7点から始めれば、要件定義、RFP、ベンダー選定、開発費用、運用体制、セキュリティ要件を同じ土俵で整理できる。

関連記事

• 『2025年の崖』を越えた今、レガシーシステム刷新はどう進めるべきか
• IBM i（AS/400）刷新のコストとロードマップ 2026
• 日立メインフレーム（VOS3）2034年保守終了と脱却の進め方
• 富士通メインフレーム2030年撤退とCOBOL刷新
• レガシー刷新の特集ハブ：システム開発発注の失敗図鑑