2025年9月16日、デジタル庁と総務省はわずか17ページの文書を静かに公開した。「地方公共団体情報システム非機能要件の標準【第1.2版】」である。プレスリリースはなく、大きく報道されることもなかった。しかし、ガバメントクラウド移行後のコスト高止まりに悩む自治体担当者にとって、この文書は見落とせない一次情報だ。

本記事では、なぜ非機能要件がコスト問題の核心にあったのか、第1.2版の改定で実際に何が変わったのか、そして次回調達や更改にどう活かすかを体系的に解説する。

---

1. コストが「2倍」「3倍」になった本当の原因

1-1. コスト増加の実態：数字が示す深刻さ

ガバメントクラウド移行後の運用経費増加は、既に複数の調査で数値化されている。

中核市市長会の調査によると、移行後の運用経費の平均倍率は2.3倍に達し、5割以上の自治体で2倍以上の増加が確認された（出典: 日本経済新聞 2025年1月）。東京都の調査では、ガバメントクラウドの利用割引を最大限適用しても、特別区で平均1.5倍、市で1.7倍、町村で2倍程度の経費増加が見込まれるとされた。個別事例では、福島市でシステム運用経費が3.7倍になったケースも報告されている。

政府内でもこの問題は深刻に受け止められており、2025年4月の石破総理の指示を受けて、デジタル行財政改革会議が地方三団体の代表も含むワーキングチームを設置。同年6月13日に「自治体情報システムの標準化・ガバメントクラウド移行後の運用経費に係る総合的な対策について」を取りまとめた（出典: デジタル庁 2025年6月13日）。

1-2. 「クラウドは安い」はずがなぜ逆転したか

コスト増加の原因は複合的だが、構造的な要因として以下が挙げられている。

第一の要因は、基盤費用の分離と従量課金化だ。 従来のオンプレミスや自治体クラウドでは、基盤費用とソフトウェア借料が一体化しており、人口規模や財政力に応じた柔軟な料金設定が行われていた。ガバメントクラウドへの移行により基盤費用が分離・従量課金化されたことで、小規模自治体ほど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による最適化ではコスト削減に限界がある。その根本原因が「制度設計の問題」にあることが、政府内でも公式に認識されたのだ。

---

2. 第1.2版の核心：「一律」から「選択制」へ

2-1. 改定の経緯と背景

第1.2版は、段階的な検討を経て策定された。

2025年2月、「地方公共団体情報システムにおける標準化にかかる共通基準に関する検討会」が設置された。ガバメントクラウド早期移行団体の検証事業で蓄積された実績データと、各自治体からの「要件が過大」という声を受け、同年夏を目途に必要な見直しを実施することとされた。

その約束は守られた。2025年9月16日、デジタル社会共通機能グループ 地方業務システム基盤チームから第1.2版が公開された（出典: デジタル庁 2025年9月16日）。

2-2. 旧版（1.1版）と新版（1.2版）の根本的な違い

1.1版の基本原則は、「国が示したレベルを原則遵守し、例外は個別申請」だった。セキュリティの根幹に関わる項目はもちろん、規模による差異が生じやすい運用・性能系の要件も、実質的に一律の水準が求められていた。

1.2版では、この設計を根本から見直した。改定の基本思想は次のとおりだ。

• セキュリティの根幹に関わる項目など、業務にかかわらず画一的な指標が必要な項目については引き続き国が示した「選択レベル」を維持
• 一方で、自治体の規模・業務の性質・リスク受容方針等に応じて幅を持たせ得る項目については、自治体が自らの裁量でレベルを選択可能とした

これが「ケース1」と「ケース2」の仕組みとして具体化された。

2-3. ケース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リスク方針で判断"]

---

3. 実際に「下げられる」要件はどこか

3-1. 変更点の全体像

第1.2版で変更された項目は、可用性（A領域）・性能拡張性（B領域）・運用保守性（C領域）・セキュリティ（E領域）にまたがる。以下に主な変更項目をまとめる。

領域	変更の種別	内容の要点	コスト効果の方向性
可用性（A領域）	[-]条件追加	外部データによる復旧が可能な場合、バックアップ水準を下げることができる	バックアップ設計・ストレージ費削減
性能拡張性（B領域）	ケース2化	同時アクセス数等、業務量に応じた自由選択が可能に	ライセンス・スペック見直しの余地
運用保守性（C領域）	[-]条件追加	外部非接続システムは緊急パッチ対応の頻度を下げられる	運用工数・保守費削減
セキュリティ（E領域）	[+]条件追加	リスクの高い環境では上位選択が可能（柔軟化は双方向）	リスク管理の適正化

3-2. 小規模自治体が注目すべきポイント

特に小規模自治体（人口10万人未満、特に町村）にとって実務的に重要なのは次の点だ。

まず、性能拡張性（B領域）のケース2化が大きい。同時アクセス数や処理量は、業務の実態に即して設定できるようになった。中核市規模を想定した仕様では、実際のアクセス数の数倍〜数十倍のスペックが義務付けられていたケースがある。自治体の業務量を計測し、それに見合ったスペックを選択できることは、ライセンスコストとインフラコストの両面で改善余地をもたらす。

次に、可用性のバックアップ要件に付いた[-]条件も見逃せない。住民基本台帳や各種証明書発行の業務において、住基ネット等の公的外部データで復旧が可能であれば、多重バックアップの水準を見直せる可能性がある。ただし、この判断は「本当に外部データで復旧できるか」の業務面の検証が前提であり、ベンダーと連携した確認作業が必要だ。

3-3. 重要な留意点

「下げられる」と「下げるべき」は別の話だ。以下の点は必ず理解した上で判断してほしい。

第一に、選択したレベルの要件は遵守義務がある。レベルを下げた場合でも、そのレベルが定める基準を守らなければならない。「下げたからどうにでもなる」という考えは誤りだ。

第二に、各業務の標準仕様書に独自の要件がある場合はそちらが優先される。非機能要件の標準で選択可能になっても、個別業務の標準仕様書がより厳しい水準を求めていれば、そちらに従う必要がある。20業務の標準仕様書を個別に確認することが前提だ（標準仕様書対応チェックリスト参考）。

第三に、共同利用の場合は合意形成が先になる。複数自治体が共同で利用するシステムでは、参加自治体が一律のレベルを採用する必要がある。単独利用より選択肢が狭まる可能性があり、構成自治体間での事前協議が不可欠だ。

---

4. 調達・更改で使う方法：実践ガイド

4-1. まずExcelシートを入手する

デジタル庁の公式ページでは、第1.2版の本体PDF（17ページ）と並んでExcelシート（活用シート）が提供されている。このExcelシートが実務上の核心だ。

Excelでは各要件項目について、「選択レベル」「レベルの幅」「選択時の条件」の列が設定されている。「選択時の条件」列を確認し、[+][-]の記号があればケース1、なければケース2と判別できる。また、網掛けになっている項目は自治体が選択できないため、見落とし注意だ。

入手先: デジタル庁 ガバメントクラウド政策ページ から「非機能要件の標準」セクションへ。

4-2. 自団体の規模・業務特性をマッピングする

Excelシートを入手したら、次は自団体の実態データを整理する。判断に必要な主な軸は以下だ。

• 人口規模・想定アクセス量: 性能拡張性（B領域）のケース2選択の根拠になる
• 外部接続の有無・接続先: セキュリティ（E領域）のリスクレベルに影響する
• 外部データによる復旧可否: 可用性（A領域）の[-]条件判定に必要
• 業務別の処理時間帯・ピーク特性: 可用性の稼働時間設定に関わる

特にB.1.1.1〜B.1.1.5の性能拡張性5項目は、実際の業務量データを計測・収集して埋めることが1.2版の想定している姿だ。推測ではなく実測値を使うことで、レベル選択の根拠が明確になり、後の説明責任にも対応できる。

4-3. ベンダーへの交渉に使う方法

次回更改や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・調達へ"]

---

5. 限界と残された課題

第1.2版の改定はGCInsightが課題として指摘してきた問題に対する公式の応答であり、一定の前進だ。しかし、全てが解決されたわけではない。フラットに評価する。

5-1. Excelが複雑になったという現実

1.2版のExcelシートは、[+][-]条件・ケース1/2の組み合わせ・網掛け項目の判別など、1.1版より確認すべき要素が増えた。担当者が「なんとなく選ぶ」のではなく、各項目の判断根拠を理解した上で選択することが求められる。IT専門職員が少ない小規模団体ほど、この「Excelを使いこなす難しさ」が壁になりうる。

5-2. 責任所在の問題が未解決

1.2版で自治体の裁量が拡大した反面、「レベルを下げた結果、障害が発生した場合の説明責任」が明確化されていない。国が「選択レベル」を示した1.1版の方が、「国の示した水準に従った」という説明が容易だった側面もある。

1.2版では「自治体が選択した」という事実が残る。リスク受容方針の文書化と、庁内の意思決定プロセスの記録が、担当者の身を守る意味でも重要だ。

5-3. 全ての問題が非機能要件の緩和で解決するわけではない

コスト高止まりの原因は非機能要件だけではない。前述した「基盤費用の従量課金化による小規模自治体の不利」や、「ベンダーの見積体系がガバメントクラウドに最適化されていない」という問題は、非機能要件の緩和では解決できない。1.2版の活用と並行して、FinOpsによる継続的なコスト管理（FinOps実践ガイド参照）や、調達・契約の見直しも必要だ。

---

まとめ：「下げられる」より「どこを下げるか」を問う

第1.2版は、非機能要件の過剰問題に対するデジタル庁・総務省の制度的な回答だ。中核市市長会調査で示された平均2.3倍のコスト増加という現実に対し、「一律から選択制へ」という方向転換は評価できる。

ただし、この改定が自動的にコストを下げるわけではない。

Excelシートを理解し、自団体の業務実態を計測し、リスク受容方針を文書化し、ベンダーとの要件定義に明示的に持ち込む——このプロセスを自治体側が能動的に行わない限り、ベンダーは従来通りの最大公約数スペックを提示し続ける。「どこを下げるか」を担当者が主体的に判断できるかどうかが、次回更改でのコスト結果を左右する。

「下げられる」かどうかより「どこを下げるか、なぜ下げるか」を整理することが、調達担当者・ベンダーSEの双方に求められている。

GCInsightでは、規模別・業務別の最適選択レベル試算ツールの提供を予定している。詳細はGCInsightダッシュボードでご確認いただきたい。

---

FAQ

Q. 第1.2版はすでに移行済みのシステムにも適用できますか？

A. 直接の「遡及適用」はありません。現在稼働中のシステムの仕様変更は、次回の更改・リプレースのタイミングが基本的な適用機会です。ただし、年度更新の保守契約の場面で「1.2版に基づく要件の見直し」を提案することは可能です。ベンダーと現行契約の範囲を確認した上で協議してください。

Q. どの項目を下げるかの判断は自治体が単独でできますか？

A. 法的には自治体の裁量ですが、実務上はベンダーの技術的確認と庁内の合意形成が必要です。特に業務継続性に関わる項目（可用性・バックアップ）は、「本当に[-]条件が自団体に当てはまるか」の業務分析が先決です。担当部局・情報部門・首長部局の三者で方針を決定することを推奨します。

Q. 非機能要件のExcelシートはどこで入手できますか？

A. デジタル庁の「地方公共団体情報システムの標準化及び非機能要件の標準」ページ（digital.go.jp/policies/local_governments/）から入手できます。「非機能要件の標準」セクションにExcel形式（約200KB）のシートが用意されています。

Q. 共同利用方式で参加している場合、単独で要件レベルを変更できますか？

A. できません。共同利用システムでは参加自治体が一律のレベルを採用することが原則です。レベル変更を希望する場合は、構成自治体全体での合意形成と、幹事自治体を通じた仕様変更の手続きが必要になります。他の参加自治体の状況によっては実現が難しいケースもあります。

---

参考文献・出典

• 地方公共団体情報システム非機能要件の標準【第1.2版】本体（デジタル庁・総務省、令和7年9月16日）
• 「地方公共団体情報システム非機能要件の標準【第1.2版】」の改定について（概要資料）（デジタル庁、令和7年9月）
• 自治体情報システムの標準化・ガバメントクラウド移行後の運用経費に係る総合的な対策について（デジタル庁、令和7年6月13日）
• 参考資料：運用経費高止まり問題への対応（内閣官房、デジタル行財政改革会議）
• 自治体システム標準化で運用経費2.3倍 中核市調査（日本経済新聞）