
中核市市長会調査で平均2.3倍に膨らんだ運用経費の根本原因は非機能要件の過剰設定にあった。2025年9月にデジタル庁・総務省が公開した第1.2版の「選択制」改定で、自治体は次回調達から要件レベルを適正化できる。具体的な変更点と実践ガイドを解説する。
2025年9月16日、デジタル庁と総務省はわずか17ページの文書を静かに公開した。「地方公共団体情報システム非機能要件の標準【第1.2版】」である。プレスリリースはなく、大きく報道されることもなかった。しかし、ガバメントクラウド移行後のコスト高止まりに悩む自治体担当者にとって、この文書は見落とせない一次情報だ。
本記事では、なぜ非機能要件がコスト問題の核心にあったのか、第1.2版の改定で実際に何が変わったのか、そして次回調達や更改にどう活かすかを体系的に解説する。
ガバメントクラウド移行後の運用経費増加は、既に複数の調査で数値化されている。
中核市市長会の調査によると、移行後の運用経費の平均倍率は2.3倍に達し、5割以上の自治体で2倍以上の増加が確認された(出典: 日本経済新聞 2025年1月)。東京都の調査では、ガバメントクラウドの利用割引を最大限適用しても、特別区で平均1.5倍、市で1.7倍、町村で2倍程度の経費増加が見込まれるとされた。個別事例では、福島市でシステム運用経費が3.7倍になったケースも報告されている。
政府内でもこの問題は深刻に受け止められており、2025年4月の石破総理の指示を受けて、デジタル行財政改革会議が地方三団体の代表も含むワーキングチームを設置。同年6月13日に「自治体情報システムの標準化・ガバメントクラウド移行後の運用経費に係る総合的な対策について」を取りまとめた(出典: デジタル庁 2025年6月13日)。
コスト増加の原因は複合的だが、構造的な要因として以下が挙げられている。
第一の要因は、基盤費用の分離と従量課金化だ。 従来のオンプレミスや自治体クラウドでは、基盤費用とソフトウェア借料が一体化しており、人口規模や財政力に応じた柔軟な料金設定が行われていた。ガバメントクラウドへの移行により基盤費用が分離・従量課金化されたことで、小規模自治体ほど1団体あたりのコストが割高になる構造が露わになった。
第二の要因が、非機能要件の標準による「過剰設定」だ。 標準仕様書は「中核市規模」を想定して策定されており、人口5,000人の町村と政令指定都市が、実質的に同水準の可用性・バックアップ・セキュリティ要件を求められる設計になっていた。デジタル庁・総務省も2025年6月の対策文書でこの点を明示し、「令和2年9月に策定された非機能要件の標準は、個別業務の態様や自治体の規模等に比べて過大であり、運用経費の高止まりに繋がっているとの意見がある」と公式に認めた。
以下のフローは、コスト高止まりの構造を整理したものだ。
flowchart TD
A["標準仕様書\n中核市規模想定"] --> B["非機能要件\n一律適用"]
B --> C["可用性・バックアップ・\nセキュリティが過大"]
C --> D["小規模自治体\nコスト負担増"]
D --> E["運用経費\n平均2.3倍"]
F["基盤費用\n従量課金化"] --> E
GCInsightが2026年4月の分析(ガバメントクラウド移行 全実態レポート 2026 FinOps完全版)で指摘した通り、FinOpsによる最適化ではコスト削減に限界がある。その根本原因が「制度設計の問題」にあることが、政府内でも公式に認識されたのだ。
第1.2版は、段階的な検討を経て策定された。
2025年2月、「地方公共団体情報システムにおける標準化にかかる共通基準に関する検討会」が設置された。ガバメントクラウド早期移行団体の検証事業で蓄積された実績データと、各自治体からの「要件が過大」という声を受け、同年夏を目途に必要な見直しを実施することとされた。
その約束は守られた。2025年9月16日、デジタル社会共通機能グループ 地方業務システム基盤チームから第1.2版が公開された(出典: デジタル庁 2025年9月16日)。
1.1版の基本原則は、「国が示したレベルを原則遵守し、例外は個別申請」だった。セキュリティの根幹に関わる項目はもちろん、規模による差異が生じやすい運用・性能系の要件も、実質的に一律の水準が求められていた。
1.2版では、この設計を根本から見直した。改定の基本思想は次のとおりだ。
これが「ケース1」と「ケース2」の仕組みとして具体化された。
ケース1:[+][-]条件付き項目
ケース1は、Excelの「選択時の条件」列に[+]条件または[-]条件が明記されている項目だ。
例えば、可用性に関する項目で「外部データによって復旧可能」という[-]条件が設定されていれば、住基ネット等の外部データで復旧できる環境の自治体は、バックアップ多重化水準を下げることができる。
ケース2:条件なし自由選択項目
ケース2は、[+][-]条件の記載がない項目だ。これが1.2版最大の変更点といえる。
「選択時の条件」欄にプラス条件もマイナス条件も記載がない場合、自治体の規模・業務の性質・リスク受容方針等に応じて、幅の中から自由にレベルを選択できる。
「小規模団体だからレベルを下げていい」が公式に認められた。これは1.1版では実質的に存在しなかった選択肢だ。
flowchart TD
A["非機能要件の各項目"] --> B{"条件の記載は?"}
B -->|"[+][-]条件あり"| C["ケース1\n条件充足時のみ変更可"]
B -->|"条件なし"| D["ケース2\n自治体の裁量で自由選択"]
C --> E["[-]条件を満たす\n→下位レベルへ変更"]
C --> F["[+]条件を満たす\n→上位レベルへ変更"]
D --> G["規模・業務・\nリスク方針で判断"]
第1.2版で変更された項目は、可用性(A領域)・性能拡張性(B領域)・運用保守性(C領域)・セキュリティ(E領域)にまたがる。以下に主な変更項目をまとめる。
| 領域 | 変更の種別 | 内容の要点 | コスト効果の方向性 |
|---|---|---|---|
| 可用性(A領域) | [-]条件追加 | 外部データによる復旧が可能な場合、バックアップ水準を下げることができる | バックアップ設計・ストレージ費削減 |
| 性能拡張性(B領域) | ケース2化 | 同時アクセス数等、業務量に応じた自由選択が可能に | ライセンス・スペック見直しの余地 |
| 運用保守性(C領域) | [-]条件追加 | 外部非接続システムは緊急パッチ対応の頻度を下げられる | 運用工数・保守費削減 |
| セキュリティ(E領域) | [+]条件追加 | リスクの高い環境では上位選択が可能(柔軟化は双方向) | リスク管理の適正化 |
特に小規模自治体(人口10万人未満、特に町村)にとって実務的に重要なのは次の点だ。
まず、性能拡張性(B領域)のケース2化が大きい。同時アクセス数や処理量は、業務の実態に即して設定できるようになった。中核市規模を想定した仕様では、実際のアクセス数の数倍〜数十倍のスペックが義務付けられていたケースがある。自治体の業務量を計測し、それに見合ったスペックを選択できることは、ライセンスコストとインフラコストの両面で改善余地をもたらす。
次に、可用性のバックアップ要件に付いた[-]条件も見逃せない。住民基本台帳や各種証明書発行の業務において、住基ネット等の公的外部データで復旧が可能であれば、多重バックアップの水準を見直せる可能性がある。ただし、この判断は「本当に外部データで復旧できるか」の業務面の検証が前提であり、ベンダーと連携した確認作業が必要だ。
「下げられる」と「下げるべき」は別の話だ。以下の点は必ず理解した上で判断してほしい。
第一に、選択したレベルの要件は遵守義務がある。レベルを下げた場合でも、そのレベルが定める基準を守らなければならない。「下げたからどうにでもなる」という考えは誤りだ。
第二に、各業務の標準仕様書に独自の要件がある場合はそちらが優先される。非機能要件の標準で選択可能になっても、個別業務の標準仕様書がより厳しい水準を求めていれば、そちらに従う必要がある。20業務の標準仕様書を個別に確認することが前提だ(標準仕様書対応チェックリスト参考)。
第三に、共同利用の場合は合意形成が先になる。複数自治体が共同で利用するシステムでは、参加自治体が一律のレベルを採用する必要がある。単独利用より選択肢が狭まる可能性があり、構成自治体間での事前協議が不可欠だ。
デジタル庁の公式ページでは、第1.2版の本体PDF(17ページ)と並んでExcelシート(活用シート)が提供されている。このExcelシートが実務上の核心だ。
Excelでは各要件項目について、「選択レベル」「レベルの幅」「選択時の条件」の列が設定されている。「選択時の条件」列を確認し、[+][-]の記号があればケース1、なければケース2と判別できる。また、網掛けになっている項目は自治体が選択できないため、見落とし注意だ。
入手先: デジタル庁 ガバメントクラウド政策ページ から「非機能要件の標準」セクションへ。
Excelシートを入手したら、次は自団体の実態データを整理する。判断に必要な主な軸は以下だ。
特にB.1.1.1〜B.1.1.5の性能拡張性5項目は、実際の業務量データを計測・収集して埋めることが1.2版の想定している姿だ。推測ではなく実測値を使うことで、レベル選択の根拠が明確になり、後の説明責任にも対応できる。
次回更改やRFIの段階では、「第1.2版に基づきレベルをXに変更する」と明示することで、ベンダーとの要件定義を能動的に再設計できる。
具体的には、仕様書の非機能要件欄に「地方公共団体情報システム非機能要件の標準【第1.2版】ケース2に基づき、当団体の業務規模・リスク受容方針に応じてレベルXを選択する」と明記することを推奨する。これにより、ベンダーが従来の「最大公約数」スペックを提示してくる慣行に対して、交渉の根拠を持つことができる。
ただし、「レベルを下げろ」と言うだけでは通らない。下げる理由(自団体の業務実態データ)と、下げた場合のリスクへの対応方針を文書化した上で交渉するのが現実的なアプローチだ。
flowchart TD
A["デジタル庁Excelシート入手"] --> B["各項目がケース1/2か判別"]
B --> C["自団体の実態データを収集\n(業務量・接続先・ピーク等)"]
C --> D["適用可能な[-]条件・ケース2を特定"]
D --> E["リスク受容方針を文書化"]
E --> F["仕様書に明記してRFI・調達へ"]
第1.2版の改定はGCInsightが課題として指摘してきた問題に対する公式の応答であり、一定の前進だ。しかし、全てが解決されたわけではない。フラットに評価する。
1.2版のExcelシートは、[+][-]条件・ケース1/2の組み合わせ・網掛け項目の判別など、1.1版より確認すべき要素が増えた。担当者が「なんとなく選ぶ」のではなく、各項目の判断根拠を理解した上で選択することが求められる。IT専門職員が少ない小規模団体ほど、この「Excelを使いこなす難しさ」が壁になりうる。
1.2版で自治体の裁量が拡大した反面、「レベルを下げた結果、障害が発生した場合の説明責任」が明確化されていない。国が「選択レベル」を示した1.1版の方が、「国の示した水準に従った」という説明が容易だった側面もある。
1.2版では「自治体が選択した」という事実が残る。リスク受容方針の文書化と、庁内の意思決定プロセスの記録が、担当者の身を守る意味でも重要だ。
コスト高止まりの原因は非機能要件だけではない。前述した「基盤費用の従量課金化による小規模自治体の不利」や、「ベンダーの見積体系がガバメントクラウドに最適化されていない」という問題は、非機能要件の緩和では解決できない。1.2版の活用と並行して、FinOpsによる継続的なコスト管理(FinOps実践ガイド参照)や、調達・契約の見直しも必要だ。
第1.2版は、非機能要件の過剰問題に対するデジタル庁・総務省の制度的な回答だ。中核市市長会調査で示された平均2.3倍のコスト増加という現実に対し、「一律から選択制へ」という方向転換は評価できる。
ただし、この改定が自動的にコストを下げるわけではない。
Excelシートを理解し、自団体の業務実態を計測し、リスク受容方針を文書化し、ベンダーとの要件定義に明示的に持ち込む——このプロセスを自治体側が能動的に行わない限り、ベンダーは従来通りの最大公約数スペックを提示し続ける。「どこを下げるか」を担当者が主体的に判断できるかどうかが、次回更改でのコスト結果を左右する。
「下げられる」かどうかより「どこを下げるか、なぜ下げるか」を整理することが、調達担当者・ベンダーSEの双方に求められている。
GCInsightでは、規模別・業務別の最適選択レベル試算ツールの提供を予定している。詳細はGCInsightダッシュボードでご確認いただきたい。
Q. 第1.2版はすでに移行済みのシステムにも適用できますか?
A. 直接の「遡及適用」はありません。現在稼働中のシステムの仕様変更は、次回の更改・リプレースのタイミングが基本的な適用機会です。ただし、年度更新の保守契約の場面で「1.2版に基づく要件の見直し」を提案することは可能です。ベンダーと現行契約の範囲を確認した上で協議してください。
Q. どの項目を下げるかの判断は自治体が単独でできますか?
A. 法的には自治体の裁量ですが、実務上はベンダーの技術的確認と庁内の合意形成が必要です。特に業務継続性に関わる項目(可用性・バックアップ)は、「本当に[-]条件が自団体に当てはまるか」の業務分析が先決です。担当部局・情報部門・首長部局の三者で方針を決定することを推奨します。
Q. 非機能要件のExcelシートはどこで入手できますか?
A. デジタル庁の「地方公共団体情報システムの標準化及び非機能要件の標準」ページ(digital.go.jp/policies/local_governments/)から入手できます。「非機能要件の標準」セクションにExcel形式(約200KB)のシートが用意されています。
Q. 共同利用方式で参加している場合、単独で要件レベルを変更できますか?
A. できません。共同利用システムでは参加自治体が一律のレベルを採用することが原則です。レベル変更を希望する場合は、構成自治体全体での合意形成と、幹事自治体を通じた仕様変更の手続きが必要になります。他の参加自治体の状況によっては実現が難しいケースもあります。
GCInsight編集部
ガバメントクラウド・自治体標準化を専門に調査するリサーチチーム。デジタル庁・総務省公表データを一次資料として継続的に分析し、自治体DX担当者・ITベンダー向けに実務情報を提供しています。
無料ニュースレター — 毎週金曜
この記事の続報・関連データを見逃さない。週1・5分のガバクラ週報。
935自治体・8,956システムがガバメントクラウド移行に遅延し、運用費が最大5.7倍に増加した事例をデジタル庁・総務省の公式データで解説。移行失敗の3大原因と自治体が今すぐ取れる対策を紹介します。
2026-04-26ガバクラ(ガバメントクラウド)とは何かを公式資料に基づいて徹底解説。AWS・OCI・さくらのクラウドなど選定5クラウドの特徴、935自治体が移行に遅延した構造的原因、2026年度以降の対応策まで自治体IT担当者が知るべき情報をまとめました。
2026-04-24ガバメントクラウド移行後に運用費が平均2.3倍に膨らんだ実態を中核市市長会データで解説。8,956システムが遅延した原因・Replatform手順・GCASアカウント申請から移行完了までの全ステップを2026年最新のデジタル庁手順書(第3.0版)をもとに整理します。
2026-04-21