自治体システムの標準化とは？20業務の移行と期限経過後の実務を解説

自治体システムの標準化とは、全国1,788の地方公共団体がそれぞれ独自に構築してきた基幹業務システムを、国が定めた標準仕様に適合したシステムへ移行させる制度です。対象は住民基本台帳や地方税など20業務。原則の移行期限だった2025年度末は2026年3月に過ぎ、いまは「間に合わなかったシステムをどう扱うか」が実務の中心になりました。本記事では標準化法と20業務の定義、2026年3月末時点の到達数、特定移行支援システムの位置づけ、Fit to Standardと独自施策システムの切り分け、そして運用経費の削減目標に届く条件までを一次情報で整理します。

まとめ｜期限経過後の自治体システム標準化で発注側が決める論点

デジタル庁が2026年6月30日に更新した公表値では、移行対象の全34,366システムのうち10,013システム、割合にして29.1%が「特定移行支援システム」に区分されています（2026年3月末時点）。3件に1件近くが原則期限内に収まらなかった計算になります。

ここで混同しやすいのが、特定移行支援システムと単なる期限遅延の違いです。前者は事業者の撤退やリソース逼迫といった要件に当てはまり、主務省令で個別に移行完了期限が設定されたうえで国の支援対象となるもの。放置されている遅延とは扱いが異なります。

結論を先に置きます。すでに移行を終えた団体が次に手を付けるべきは、標準準拠システムそのものではなく、その外側に残った独自施策システムと連携部分の整理です。特定移行支援システムを抱える団体は、概ね5年という猶予を「延期」ではなく現行システムの停止時期を確定させる期間として使うべきで、この判断を先送りすると次の期限でも同じ理由が繰り返されます。運用経費の削減目標についても、移行しただけでは届きません。共同利用の形へ踏み込むか、契約を単年度の保守から見直すか、どちらかを選ばない限り数字は動かない、というのが本記事の立場です。

自治体システム標準化の定義と標準化法が定めた対象20業務の範囲

制度の骨格は法律と主務省令の二層構造になっています。まず何が決められているのかを押さえます。

1,788団体が別々に持っていた基幹業務を共通仕様へ寄せる制度設計

根拠法は「地方公共団体情報システムの標準化に関する法律」、いわゆる標準化法で、2021年（令和3年）に成立し同年9月に施行されました。それまでは同じ住民記録の処理でも、団体ごとに帳票のレイアウトやデータ項目、画面の遷移が異なっていました。ベンダーを乗り換えようとすればデータ移行の見積もりだけで数千万円規模になる構造だったわけです。

標準化はこの状態を解きにいく制度です。国が業務ごとに標準仕様書を作り、各団体はその仕様に適合したシステム、すなわち標準準拠システムへ移行します。制度の運用方針は「地方公共団体情報システム標準化基本方針」にまとめられ、直近では令和6年（2024年）12月に改定されました。

住民基本台帳から国民年金まで20業務の内訳と主務省令による基準

デジタル庁が公開している対象業務は次の20です（2026年7月28日時点のページ記載）。分野ごとに整理すると全体像がつかみやすくなります。

それぞれの業務について、機能要件を定める標準仕様書が制度所管省庁から示されます。仕様書は改定を重ねるため、調達仕様に引用する際はバージョンと公表時点を必ず控えてください。「最新版」と書いただけの契約書は、改定のたびに解釈が割れます。

ガバメントクラウドの利用が努力義務にとどまる法律上の位置づけ

標準化とガバメントクラウドは、しばしば同じものとして語られますが法的な強さが違います。標準準拠システムへの移行は義務、国が整備するクラウド環境の利用は努力義務です。この差は調達の設計に直結します。

努力義務であるため、地域のデータセンターに置いたまま標準準拠システムへ移行する選択も制度上は残ります。ただし国の財政支援や共同利用の枠組みはクラウド前提で組まれているものが多く、独自の基盤を選ぶと補助の対象範囲が狭まる点には注意が必要です。クラウド基盤側の要件や移行期限の詳細はデジタル庁が求めるガバメントクラウドの全体像で個別に整理しています。

2025年度末の期限到達点と特定移行支援システム10,013件の実像

数字を見ないと現在地が分かりません。公表値を時点付きで並べます。

2026年3月末時点で全34,366システム中29.1%という到達水準

デジタル庁が2026年6月30日に更新した値では、移行対象の全34,366システムのうち10,013システム（29.1%）が特定移行支援システムに区分されました。その前段、2026年2月27日の公表（2025年12月末時点）では期限より遅れているシステムが全体の25.9%で、遅延を1つ以上抱える団体は935団体。全1,788団体の半数を超えていました。

移行を完了した側の数字も出ています。令和8年1月末時点で完了は13,283システム、割合では38.4%。母数の取り方が資料により34,366と34,592で揺れるため、比較するときは同じ公表資料の中で数字を突き合わせてください。異なる時点の値を並べると、進捗が実態より良くも悪くも見えます。

特定移行支援システムと単なる期限遅延を切り分ける4つの該当類型

特定移行支援システムは、期限に間に合わなかったものすべてを指す言葉ではありません。デジタル庁が示した定義に照らすと、次の類型に当てはまるものです。

• 現行システムがメインフレームで運用されている
• パッケージではなく個別開発されたシステムである
• 現行事業者が標準準拠システムの開発から撤退し、公募しても代替事業者が見つからない
• 事業者側のリソース逼迫により、令和8年度以降の移行とならざるを得ないことが具体化している

共通するのは「団体の努力だけでは動かせない外部要因」という点です。庁内の合意形成が遅れただけ、要件定義が固まらないだけ、という理由は該当しません。自団体のシステムがどちらに当たるかを取り違えると、支援の申請段階で差し戻されます。

主務省令が個別に定める移行完了期限と概ね5年以内という支援枠

特定移行支援システムに区分されると、標準化基準を定める主務省令のなかで、そのシステム固有の移行完了期限が設定されます。国は概ね5年以内に標準準拠システムへ移行できるよう支援する方針を示しました。

誤読しやすいのは、この5年が全団体に一律で与えられた猶予ではないことです。期限はシステム単位で個別に決まります。同じ団体のなかでも、税務系は令和9年度、福祉系は令和11年度というように期日が分かれる可能性がある。移行計画は団体単位ではなくシステム単位で引き直す必要があります。

ガバメントクラウド認定5事業者の採用実態と基盤選定の判断材料

基盤の選択肢は増えましたが、実際の採用は一極に寄っています。

AWS1,564団体・OCI461団体という2026年3月末の採用分布

2026年6月時点で認定されているのは、Amazon Web Services、Microsoft Azure、Oracle Cloud Infrastructure、Google Cloud、さくらのクラウドの5サービスです。ところが2026年3月31日時点の採用状況を見ると、分布は次のように偏っています。

この偏りは団体が自分で選んだ結果とは限りません。標準準拠システムを提供するベンダー側が対応基盤を絞っているため、パッケージを選んだ時点で基盤も決まる構図になっています。基盤を先に決めてからベンダーを探す進め方は、実務ではほぼ成立しません。

さくらのクラウドが305項目に適合して国産唯一となった選択肢

さくらインターネットが提供するさくらのクラウドは、305項目の技術要件への適合を経て2026年3月に正式認定されました。国内事業者としては唯一の認定です。

国産であることを調達要件に掲げたい団体には選択肢が生まれた一方、標準準拠システム側の対応が追いついているかは業務ごとに確認が要ります。認定は基盤の要件充足を示すもので、20業務すべてのパッケージがそこで動く保証ではありません。この確認を飛ばすと、基盤を決めた後にベンダーが見つからない事態になります。

LGWAN接続系とインターネット接続系をまたぐ通信経路の設計

基盤をクラウドへ移しても、自治体のネットワークは三層分離の構造を保ったままです。基幹業務はLGWAN接続系に置かれ、インターネット接続系とは通信を分離する。標準準拠システムをクラウドで動かすとなれば、この境界をどう越えるかの設計が必須になります。

専用線やクラウドへの専用接続回線の帯域、ファイル受け渡しの無害化処理、認証基盤の置き場所。ここを曖昧にしたまま調達すると、稼働後に窓口業務の応答が遅くなるという形で表面化します。ネットワーク側の前提はLGWAN（総合行政ネットワーク）の仕組みとセキュリティで整理しています。

Fit to Standardの運用と独自施策システムへ切り出す判断基準

標準化でもっとも摩擦が起きるのが、既存の運用を捨てる判断です。

標準仕様書へ業務を合わせる原則とカスタマイズ禁止がもたらす影響

標準準拠システムは、標準仕様書に定められた機能へ業務のほうを合わせる前提で作られています。パッケージに手を入れて庁内の運用を再現する従来のやり方は取れません。この考え方がFit to Standardで、民間のERP導入と同じ発想です。

影響は帳票と業務フローに強く出ます。長年使ってきた通知書のレイアウトが変わる、確認画面の順序が変わる、という変更が現場に降りてくる。ここで「元に戻せないか」という要望を吸い上げて仕様変更に走ると、標準準拠でなくなり移行そのものが成立しなくなります。現場説明は移行作業の付随ではなく、独立した工程として計画に載せてください。

自治体独自の給付や減免を独自施策システムへ逃がす切り分けの型

とはいえ、団体独自の給付金や減免制度をすべて捨てられるわけではありません。標準仕様に含まれない施策は、標準準拠システムの外側に「独自施策システム」として別建てし、データ連携で成立させる形が基本の型になります。

切り分けの判断はこう置くと崩れません。住民の権利義務に直結し条例で定めている施策は独自施策システムへ切り出す、庁内の慣行にすぎない処理は標準機能に寄せて廃止する。この線引きを首長部局と情報政策部門の合議で先に決めておかないと、業務所管課ごとに例外要求が積み上がります。切り出す数が増えるほど連携インターフェースの保守費が増える点も、判断材料に入れてください。

経過措置で令和10年度末まで猶予される機能と先送りできない範囲

標準化基準のうち一部の機能には経過措置が置かれ、遅くとも令和10年度末までに基準へ適合すればよいとされています。すべてを初回移行で作り込む必要はありません。

ただし経過措置の対象は限定的で、住民記録や税の基幹処理そのものは対象外です。猶予があるのは主に付随的な機能で、そこを理由に全体の移行を待つ判断は取れない。実務としては、経過措置対象の機能をリスト化して次期改修の計画へ移し、初回移行のスコープから外す使い方が現実的です。

運用経費3割削減という目標に届く条件と届かないままになる条件

ここからは本記事の立場を明確にします。削減目標は自動的には達成されません。

移行しただけでは費用が下がらない仕組みと基金7,000億円の限界

政府は標準化の効果として、2018年度時点の水準と比べて運用経費を3割削減する目標を掲げてきました。しかし移行そのものは費用を生む工程です。データ移行、並行稼働、職員研修、連携改修。これらは基金で賄えても、稼働後に残るのはクラウド利用料とベンダー保守費です。

移行費用として自治体へ配分されているデジタル基盤改革支援基金は約7,000億円規模で、設置年限は5年をめどに延長する方向で検討が進んでいます。ただし基金はあくまで移行のための原資であり、恒常的な運用費を補填し続けるものではありません。基金が切れた後の年度予算で何が残るかを、移行の設計段階で試算しておく必要があります。

共同利用と単独調達とで分かれる1団体あたり運用コストの実際の水準

削減が効く条件ははっきりしています。同一の標準準拠システムを複数団体で共同利用し、基盤とライセンスを割り勘にする構成です。人口規模の小さい団体ほど、単独調達では固定費の比率が高くなり、クラウドへ移しても総額が下がりません。

逆に、単独で調達しつつ独自施策システムを多く抱える団体は、連携部分の保守費が上乗せされるため移行前より総額が増えることがあります。ここは玉虫色にせず言い切ります。人口10万人未満で独自施策システムを複数抱える構成なら、単独調達での3割削減は届きません。都道府県単位の共同利用へ参加するか、独自施策そのものを制度として整理するか、どちらかを選ぶ必要があります。

削減が届かないと判断した時点で見直すべき契約と運用の3つの論点

試算の結果、削減目標に届かないと分かった場合に手を入れる順序を示します。

1. 契約形態。単年度の保守契約を複数年へ切り替え、更新のたびに発生する調達事務と価格上昇の余地を圧縮する
2. 基盤の構成。開発・検証環境を常時稼働させたままにせず、使用時のみ起動する運用へ変える
3. 独自施策システムの棚卸し。利用実績の乏しい施策を制度側から廃止し、連携インターフェースの本数を減らす

この3つのうち効き幅が大きいのは3番目です。技術的な調整でひねり出せる額には限りがあり、制度そのものを減らすほうが恒常費に効きます。情報政策部門だけでは決められない論点なので、削減が届かないと判明した時点で政策部門を巻き込む場を作ってください。

外部委託する範囲と自治体側が手放してはいけない業務知識の線引き

最後に、発注側の体制の話をします。委託の範囲設計を誤ると、次の更改で身動きが取れなくなります。

データ移行とテスト工程を委託する場合に発注側へ残る4つの責任

移行作業の大半はベンダーが担いますが、委託しても発注側から消えない責任があります。現行データの品質に関する説明責任、移行後データの正しさを判定する基準の決定、業務停止を伴う切替日程の決裁、そして住民への周知。この4つは外部に渡せません。

とくに移行後データの検証基準は、曖昧なまま進むと稼働直後に混乱を招きます。「件数が一致すれば合格」では不十分で、課税額や資格期間といった業務上意味のある値を、どの範囲でどう突き合わせるかを発注側が定義する必要がある。公共分野の調達で起きやすい失敗の型は公共システム開発に立ちはだかる課題とその解決策にまとめています。

標準化の対象外に残る業務システムと連携要件の棚卸しという宿題

20業務の移行が終わっても、庁内のシステムはそれで全部ではありません。財務会計、文書管理、公共施設予約、内部情報系。これらは標準化の対象外で、従来どおり各団体の判断で調達します。

問題は、対象外システムの多くが基幹業務とデータ連携している点です。住民基本台帳から宛名情報を受け取る、税の賦課情報を参照する。標準準拠システムへ移った側はインターフェース仕様が変わるため、対象外システム側の改修が必ず発生します。この改修費は標準化の予算に含まれないことがあり、見落とすと年度途中で財源不足になります。移行計画の初期に、連携先の一覧と改修見込みを棚卸ししてください。

特定移行支援システムを抱える団体が次の5年で決めるべき推進体制

特定移行支援システムに区分された団体が最初にやるべきは、現行システムの停止時期を先に決めることです。移行先が決まっていなくても、停止日を置いて逆算する。事業者の撤退が理由なら、代替候補の探索と並行して自団体のデータを取り出せる状態にしておく作業が先に来ます。

体制面では、情報政策部門に業務所管課の職員を兼務で入れる形が機能しやすい構成です。標準仕様書の解釈は業務知識がないと判断できず、逆に連携やデータ移行は所管課だけでは決められません。外部の支援を入れる場合も、要件の判断を丸投げせず助言に留める切り分けが要ります。移行の設計や独自施策システムの構築を外部と進める段階では、公共システム開発の受託のように、自治体特有の制度要件とデータ連携を前提に設計できる相手を選んでください。

よくある質問

自治体システムの標準化について、検索で多く寄せられる質問に答えます。

自治体システムの標準化とは、わかりやすく言うと何ですか？

全国1,788の地方公共団体がバラバラに作ってきた住民記録や税などの基幹業務システムを、国が定めた共通の仕様に合わせたシステムへ入れ替える取り組みです。根拠は2021年施行の標準化法。狙いは、団体ごとの個別開発をやめることで運用費と改修負担を下げ、制度改正への対応を全国一斉に行える状態を作ることにあります。読者の立場で言えば、システムを団体ごとに作る時代が終わり、標準仕様に業務を合わせる時代に変わったということです。

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

原則の期限は2025年度末（令和7年度末）で、2026年3月に到達済みです。間に合わなかったもののうち、事業者の撤退やリソース逼迫など一定の要件に当てはまるものは特定移行支援システムに区分され、主務省令で個別に移行完了期限が設定されます。国は概ね5年以内の移行を支援する方針です。この期限はシステム単位で決まるため、同じ団体でも業務によって期日が異なります。

標準化の対象20業務に入らないシステムはどうなりますか？

財務会計や文書管理、公共施設予約といった業務は標準化の対象外で、従来どおり各団体が独自に調達します。ただし基幹業務とデータ連携している場合、標準準拠システム側でインターフェース仕様が変わるため、対象外システムの改修が発生します。この改修費は標準化向けの財政支援に含まれないことがあるので、移行計画の段階で連携先を洗い出し、費用を別枠で見積もっておく進め方が安全です。

ガバメントクラウドは必ず使わなければいけませんか？

標準準拠システムへの移行は義務ですが、ガバメントクラウドの利用は努力義務です。地域のデータセンターに置いたまま標準準拠システムへ移る選択も制度上は残ります。ただし国の財政支援や共同利用の枠組みはクラウド前提で設計されているものが多く、独自基盤を選ぶと支援の対象範囲が狭まる場合があります。2026年6月時点の認定はAWS、Azure、Oracle Cloud、Google Cloud、さくらのクラウドの5サービスです。

標準化基本方針や手順書はどこで確認できますか？

制度全体の方針は「地方公共団体情報システム標準化基本方針」にまとめられており、直近の改定は令和6年（2024年）12月です。実務手順は総務省が公表する手順書、業務ごとの機能要件は制度所管省庁が示す標準仕様書に記載されます。いずれも改定を重ねるため、調達仕様書へ引用する際はバージョン番号と公表年月を併記してください。版を特定しない引用は、改定後に解釈の食い違いを生みます。

関連記事

• デジタル庁が求めるガバメントクラウドの全体像と自治体が直面する移行期限：本記事が扱う標準準拠システムに対し、その土台となるクラウド基盤側の要件と期限を詳しく解説しています。
• 金融・公共・流通系のシステム開発とは？業界特化の要件と外注先の選び方：公共分野の調達で押さえるべき要件と、外注先を見極める観点を業界横断で整理しています。
• モダナイゼーションとは？レガシー刷新の手法と実装アプローチ・進め方：メインフレームや個別開発システムを刷新する際の技術的な選択肢をまとめています。
• レガシーシステムとは何か、その意味・定義や歴史的背景：特定移行支援システムの背景にある、古い基盤が残り続ける構造を理解できます。