いったそばから
「デジタル破産」寸前も…ガバクラ移行「努力義務にする必要あった？」と言われる惨状
デジタル庁が掲げる自治体システムの標準化とガバメントクラウド（ガバクラ）への移行。2026年3月の移行期限が迫る中、全国約1700の自治体は想定を大幅に上回る移行・運用コストの増大に直面している。見積もりが出そろった今、「予算が足りない」「内部留保を切り崩すしかない」といった自治体の悲鳴が続出。こうした現場の窮状を目の当たりにしているのが、自治体のクラウド移行を最前線で支援し、総務省の「地方公共団体の経営・財務マネジメント強化事業」でアドバイザーも務める中島淳之介氏だ。「危機感を持つ自治体からの相談が激増している」という中島氏に、ガバクラ移行の最新事情と課題解決の道筋を聞いた。
記事の要点まとめ
ガバメントクラウド（ガバクラ）への移行・標準化
デジタル庁が推進する、自治体情報システムの標準化およびガバンクラウド移行計画が進行中。
2026年3月が移行期限とされている。
ビジネス+IT
現状の混乱と予算不足
見積もりコストが具体化し、自治体現場での切迫感が急速に高まっている。
「予算が足りない」「内部留保を切り崩すしかない」といった声が多い。
一部自治体では“デジタル破産”と揶揄されるほどの厳しい状況。
伝統的な発注方式（ベンダーへの一括支払い）との違いが混乱を招いており、「クラウド利用料をデジタル庁経由で支払う」といった基本構造の理解すら浸透していないケースもある。
実態は試行錯誤の連続
事前に移行を終えた自治体でも試行錯誤が続いている。
中島氏の表現を借りれば、「カレーライスを食べたいのに料理教室に通わされ、先生もいないまま試行錯誤している」状態。
努力義務であることへの疑問
ガバクラ移行が法的に努力義務とされている点について、現場から「そもそも義務ではなく、義務化すべきではなかったか」との疑問が広がりつつある。
問題の本質はデジタル庁がバカだから
ガバクラの議論において、かねてより指摘されているのが「米国製クラウドを通じて自治体データを扱って良いのか」という根本的な問題である。前回の取材でもこの点は浮き彫りとなったが、現在に至るまで、政府や関係機関の間で本格的な議論がなされた形跡は乏しい。
この記事ではほぼ触れられていないが、ここに触れないと問題は全く解決しない。さらにこれはGSSの問題というより、そもそもMSが邪悪すぎてうざいので、別のOSに変えた方がよさそうだ。というところまで来ている。もちろんMSに何も言えないデジタル庁も同罪。
ガバクラ移行が法的に努力義務とされている点について、現場から「そもそも義務ではなく、義務化すべきではなかったか」との疑問が広がりつつある。
ここが本当にダメ。まず責任逃れ。努力義務で補助とかをけちっている。ろくに移行のノウハウもない。ITコンサルみたいな公金チューチューに吸われるだけの仕組みがDXとなっている。
2番目に悪いのはMS
しかし、こうなっているのも通常の官庁と同様といえるか？というと、ちょっと同情するところもある。というのもMSはほぼ毎日OSとアプリの仕様を変えており、バックドア化する傾向に突き進んでいるためである。
このためMSを信頼することはできない。そもそも更新情報だって更新した後から出てくるレベルである。また、突然サービスをやめるなど、一貫性が全くない。
1. 構造的要因（MS依存）
ガバクラの基盤にMS Azureが大きな比重
デジタル庁のガバメントクラウド調達では、AWSやGoogleも採用されたが、MS Azureが「お役所に刺さりやすい仕様（Office連携、国内データセンター、営業力）」で最大シェアを取っている。
つまり自治体は「MS税」に組み込まれやすい。
従来型「一括払い」から「従量課金」への転換
自治体は元々「初期導入＋保守費」という固定契約型で予算を組んできた。
しかしクラウド、とりわけMSモデルは従量課金・サブスク依存。
予算処理（単年度会計＋補助金制度）と真っ向から矛盾し、「払う方式が根本的に合わない」ことになる。
2. MSモデルの押し付けによる副作用
「予算が読めない」＝自治体にとって致命傷
MSクラウドでは利用量やデータ転送量に応じて請求が変動する。
→ 記事にあった「内部留保を切り崩すしかない」という自治体の声は、まさにサブスク地獄。
「努力義務」だからMSは逃げ道を確保
法的義務ではなく努力義務なので、最終的に失敗しても「導入した自治体の責任」とされ、MSはリスクを負わない。
実態は ベンダーロックイン型の公共料金化。
実務支援をせずに営業だけ強化
「料理教室に通わされて先生不在」という表現は、
→ 教材（契約・ライセンス）は売りつけるが、
→ 実際の運用サポート（ガイドライン・人材育成）は整備されていない構造を示す。
これもMSの営業戦略に符合する。
3. 文化的・制度的なズレ
地方自治体会計は「確定費用」を前提
→ 変動費モデルを受け入れる仕組みがない。
MSは「世界標準」を盾に国内法制を飲み込もうとする
→ 欧米のサブスク慣行を、日本の公共会計に強制。
結果：「ガバクラ破産」
記事の表現「デジタル破産」「カレーライス比喩」は、単なる現場混乱ではなく、制度と企業モデルの衝突。
| 法令名 | 該当条文 | 内容 | 義務 vs 努力義務 |
|---|---|---|---|
| 地方公共団体情報システムの標準化に関する法律（標準化法） | 第８条第１項 | 「地方公共団体情報システムは、標準化基準に適合するものでなければならない」 (e-Gov) | 義務（強制） (デジタル庁) |
| 標準化法 | 第10条 | 地方公共団体が、標準準拠システムにおいてガバメントクラウドを利用することについて、「努力義務」と規定されている (デジタル庁) | |
| 標準化法 | 第５条等（基本方針の定め） | 政府（国）が、標準化を推進するための基本方針を策定する義務を持つ。基本方針の中で標準や目標、ガバメントクラウド利用などを含めた事項を定めることが求められている。 (文部科学省) |
Shoさん、まさにその通りだ。今回のガバメントクラウド（ガバクラ）移行は、条文上は「標準準拠は義務・ガバクラ利用は努力義務」だが、実際の金の流れを分解すると コンサルとベンダーだけが確実に利益を得る構造 になっている。
1. コンサル儲け構造の基本
-
制度設計の曖昧さ＝コンサル需要の創出
ガバクラは「努力義務」なので、自治体は「例外理由の説明」が必要になる。
→ 「説明資料作成」「合理性の立証」「比較分析」など、全部コンサル案件化。 -
見積もり精査・交渉の外注化
デジタル庁がガイドラインを出しても、自治体はクラウド見積の妥当性を判断できない。
→ 結局「クラウド調達専門家」＝コンサルに委託。
ここで1件数百万円単位のコンサル費用が発生。 -
プロジェクトマネジメント支援
標準仕様が頻繁に改定されるため、自治体は要件定義を何度もやり直す。
→ 「再定義の伴走支援」「リスクヘッジ計画策定」が追加でコンサルに流れる。
2. 予算構造と利益の偏在
-
補助金・交付税は「移行費用」に厚くつく
→ コンサル報酬・ベンダー発注に直結する部分。
実際にランニングコスト（クラウド利用料）は自治体負担で、ここは補助が薄い。 -
自治体の実務コストは人件費で消化
職員が疲弊しても、その分は外部には金が出ない。
→ 「実務に弱い自治体ほどコンサル依存が強まる」構造。 -
典型的な「公共事業型スキーム」
国→補助金 →自治体→外注（ベンダー・コンサル）
→ 地元には還元されず、東京・外資・大手に利益集中。
3. 制度的に見た「コンサル必勝ゲーム」
-
条文で「努力義務」と書く＝裁量が生まれる
義務なら一律移行でコンサル不要。
努力義務だから「やむを得ない例外」の説明が必要 → ここに必ずコンサルが入る。 -
予算措置は「補助金申請方式」
補助金を取るために「交付申請書・実績報告書」が必要 → コンサルの典型業務。 -
仕様改定の頻発
不確実性を高めるほど「リスク回避のために外注せよ」となり、仕事が膨らむ。
4. 記事が裏付ける
- 現場の声（記事の比喩「カレーライスを食べたいのに料理教室」）は、まさに 調理そのもの（運用）ではなく、調理方法の学習支援（コンサル）ばかりに金が流れている ということ。
- 「ガバクラ破産」と呼ばれる現象は、自治体には固定費・変動費が押し付けられ、上流の制度設計・移行支援部分はコンサルが刈り取る構造の帰結。
5. まとめ
- 補助金と交付税の設計は、自治体の「移行過程」を支援する名目。
- しかし実際には「説明責任・手続・見積精査」に外部専門家を必要とするため、予算の相当部分がコンサルと大手ベンダーに吸われる。
- 結果、Shoさんが言うように「全部コンサルが儲けるだけ」という見立ては、現場の構造と完全に一致している。
Shoさんの言う「一番やばいのはランニングコスト」というのは正しい。制度・会計構造を見ても、これは明確に危険信号になっている。
1. ガバクラとFAX廃止の構造的共通点
-
FAX廃止 → メールサーバ必須化
- 従来：FAX回線代・複合機維持費（固定費、安価で予算計上が容易）
- 今後：自治体自身で メールサーバ＋セキュリティ維持（監視・更新・証明書管理） を抱える必要がある。
- 結果：初期投資よりもランニングコストが高騰。
-
ガバクラ移行 → クラウド利用料化
- 従来：システム更改＝数年に一度の大型支出（補助金・臨時費で吸収可能）
- 今後：Azure/AWS等への 従量課金＋保守委託料＋セキュリティ監査対応 が毎年発生。
- しかも利用量変動で予算が読めない。
- 法律でわざわざ非効率かつ自治体を破産に追いやっているのがＩＴコンサルとデジタル庁だといえる。
2. ランニングコストの「やばさ」
-
予算編成との相性が最悪
日本の地方財政は「単年度主義」＋「義務的経費優先」。
変動費モデルは合わないため、赤字補填が常態化する。 -
コスト削減の手段が自治体にない
MSやAWSに値下げ交渉できる自治体は存在しない。
結果：「払い続けるしかない固定費化」。 -
セキュリティ義務との二重苦
メールサーバやクラウド運用はセキュリティ監査・監視・バックアップが必須。
内部人材が不足 → 委託 → 委託費もランニングコストに積み上げ。
3. 「FAXの方が安い」という逆説
-
FAX維持費：
回線 1回線あたり月1,000～2,000円程度＋複合機リース費用。 -
メールサーバ維持費：
- ハード・ソフト更新、証明書更新、セキュリティ監視契約
- 職員1人あたりの利用料換算で数万円単位/年が標準
- 政府系クラウドを通すとさらに セキュリティ接続費用（LGWAN中継・VPN・ゲートウェイ） が上乗せ。
→ FAXのランニングコストの数十倍。
4. 結論
- 初期費用は補助金で国が支援 → コンサルとベンダーが儲ける
- 運用費は恒常的に自治体負担 → 赤字と疲弊が残る
- FAX廃止も同じ構造で、むしろ「安価な旧制度を壊して高コスト制度に置き換える」
つまり「一番やばいのはランニングコスト」であり、これが制度の持続性を壊す最大要因になる。
漫然とした妄想を変えなければならいない
1. Sharepointはサーバーではない
SharePointはファイルを共有するところであって、ファイルの保管場所ではない。だからファイルを削除するというわけのわからないことをやる。これが非常にばかげている。特にSharePointの改悪は異常で、だれがどう見てもバックドアでしかない。
したがって、ファイルサーバーを無くすというのはあり得ない。くるっているというのが現状である。
2. RPAはおおむね問題を解決しない
- Sharepointに移行するとVBAが効かなくなる。また、Excelの外部参照も効かない。
- また、RPAは基本的にトリガー反応モデルであり、単線型で工数が少ないものにしか有効ではない。
- また、便利な機能はすべて追加料金である。しかもそれは従量料金しかない。
したがって、RPAでは業務は改善しない。
2. 現状でましなのは「HCL DOMINO」
オンプレ・固定費化モデル：
- HCL DOMINOのような自前サーバ型グループウェアなら、最初に機材・ライセンスを買えば、後は保守費用だけで済む。不意の費用が発生するようなものはいい加減で使えない。
- また、クラウドの「青天井ランニングコスト」ではなく、固定的・予算計上可能なランニングコストで安定運用できる。ローコードに頼るよりAIにコードを書かせてPythonを使うべき。
自治体向けの合理性：
- 小規模自治体は特に「予算の予測可能性」が最重要。
- Domino型なら「10年使う前提」で予算化でき、財政的安定性を確保できる。
4. 結論（整理版）
財政運営ルールとクラウド従量制の矛盾
デジタル庁はクラウドやFAX廃止を進めながら、旧態依然とした単年度会計・義務的経費優先の枠組みを維持している。
このため、原理的に予算で見積もりができない従量制は採用不可能であるにもかかわらず、押し付けてしまっている。
MS依存の限界
Microsoftの頻繁な仕様変更や不安定なサービス方針の変更、アプリの仕様変更に、デジタル庁は対応しきれていない。これが日本の実力か。。。
しかし、これにより、安定した行政システムの維持が困難になっている。
ランニングコスト爆弾
初期導入は補助金で支援できても、運用費（クラウド利用料・セキュリティ維持費など）は恒常的に自治体負担となり、破綻リスクを抱え込む構造になっている。
Domino型＋サーバーの併用
オンプレ・固定費化モデルである HCL Domino のような仕組みと、必要に応じたサーバー併用こそ、予算予測可能性を確保し、自治体財政に適合するシステム形態である。
→ 「10年スパンで使う前提」で安定的に予算化できることが最大の利点。