自治体窓口DX公募で“応募ゼロ”が示したもの──現場と市場のミスマッチを解く処方箋

• 自治体窓口DXのSaaS公募で、令和8年度準備事業者募集に応募がなかった（デジタル庁発表）。これ、すごくないですか？
• 背景には仕様の硬直化、採算性の不透明さ、ガバメントクラウド運用の事務負担があると考えられます
• 解決は「段階的調達」「オープン実装」「運用支援パッケージ」の組合せで可能です。要するに現場と市場をつなげ直す話です

結論

自治体の“書かないワンストップ窓口”という良い目標はあるけれど、公募に応募が集まらなかった事実は、設計側（行政）と供給側（ベンダー・スタートアップ）の期待・リスク認識が乖離していることを示しています。これを放置すると実装遅延や独自閉鎖系の乱立につながり、住民利便性とコスト効率の両立が遠のきます。だから、仕様を「実装可能なモジュール化」に変え、初期支援と標準化をセットで用意することが近道です。

レポート本文

公募の状況と意味

デジタル庁の自治体窓口DXSaaS関連ページによれば、令和7年（2025年）10月24日〜11月25日で公募を実施し、ガバメントクラウドにおける準備事業者の募集には応募がありませんでした（デジタル庁）。真面目な話をすると、これは単なる一回の失敗ではなく市場シグナルです。

なぜ応募が集まらなかったのか、考えられる要因を整理します：

• 仕様のハードルが高い（安全性・インターフェース・地方差対応）
• 単価と運用コストのバランスが取れない（採算見通しが立ちにくい）
• 調達・契約条件の不確実性（責任範囲、データ保持、法令対応）
• 地方固有要件の多さで“汎用SaaS”になりにくい

要するに、ベンダーは「投資対効果が見えない」「リスクが高すぎる」と判断した可能性が高いです。総務省の自治体DX推進計画（第5版）も示すように、人口減少をにらんだ持続可能なサービス提供が求められる中で、自治体側も効率化と住民利便の両立を急いでいます。だが現場と市場の接点が弱いと前に進めません。

技術的観点──ここを直せば動き出す

エンジニア視点で見ると、次の設計改善がキーです：

• API-first設計と明確なデータスキーマ（My Numberやマイナポータル連携の前提を共有）
• 標準認証・権限モデル（OAuth/OpenID Connect等）を前提にする
• 最低限のオンプレ要件とクラウド要求の切り分け
• 参考実装（OSS）とテストデータセットの提供

要するに、仕様は「やるべきこと」を示しつつ「どう作るか」のショートカットを用意することが重要です。

調達・制度面の工夫案

政策的には次の組合せが現実解になります：

• 段階的調達：PoC→限定自治体でのパイロット→本稼働を段階化
• リスク分担：初期インセンティブ（クラウド利用クレジット、補助金）と運用支援のセット
• 共通プラットフォームの提供：APIゲートウェイ＋共通認証を国が提供してベンダー負担を低減
• 標準化と認証：準拠証明を作り、市場参入の障壁を下げる

これらはコストがかかりますが、長期的に見ると地方の分散した需要をまとめてスケールできるため、結果的に自治体の運用コストを下げられます。

まとめ

• 自治体窓口DXの公募で応募がなかった事実は、仕様・採算・制度の三点で市場とのズレがあることを示すシグナルです
• 技術的にはAPI-first、認証・データ仕様の明文化、参考実装の提供で解決可能です
• 制度側は段階的調達と初期支援、国による共通基盤提供で市場参加を促すべきです

おかむーから一言

ぶっちゃけ、技術的な解はあるんですよ。あとは政治・調達設計の勇気だけ。やるなら一気にじゃなく段階で作って、成功事例を増やしていきましょう！