スマートシティの課題を4つの構造で分解｜実証で止まる原因と計画段階の対処

スマートシティが実証で止まるかどうかは、センサーやAIの精度ではなく、事業計画の書き方でほぼ決まります。国の第2世代交付金はソフト事業で補助率1/2・原則3か年度以内（最長5か年度）と定められており、6年目以降の運営費は自治体の自前負担になる設計です。この記事では、自治体と発注担当が直面する課題を資金・データ標準・合意形成・人材の4類型に分け、内閣府のスマートシティリファレンスアーキテクチャ第5版（令和8年3月11日公表）と総務省のセキュリティガイドライン第3.0版を根拠に整理しました。計画段階で潰す条件、調達仕様書に入れる条項、着手を見送るべき状態まで、判断に使える形で示します。

まとめ：計画段階で決着する4つの分岐点と課題への対処順序

課題の本体は技術ではありません。実証から実装へ進めなかった事業に共通するのは、補助が切れた後の運営費の出どころ、データを引き継ぐための記述ルール、住民から同意を得る範囲、そして毎年の運用を担う人の4点が、計画書に書かれていないことです。逆に言えば、この4点を事業計画の段階で決めきれば、技術選定は後から差し替えられます。

資金は制度の数値で読めます。第2世代交付金のソフト事業は事業計画期間が原則3か年度以内、最長でも5か年度、補助率は1/2です。3年目から5年目のどこかで国費が止まる前提で、単年度の運営費と負担主体を先に決めておく必要があります。

データ標準は、内閣府が令和8年3月11日に公表したSCRA5.0の第6章が、分野横断統合・意味仲介・信頼及びガバナンス・非ロックインの4要件として規定しました。ただし共通語彙の別冊仕様書は同時点で未策定です。だからこそ、仕様が確定するまでの間は、語彙の定義とその改版方針を自治体側が調達要件として明文化する形で埋めます。

合意形成は、扱うデータをオープンデータ・限定公開データ・クローズドデータの3種別に分けたうえで、どの種別に住民のパーソナルデータが混じるかを先に切り分けます。人材は、企画・データ管理・調達の3機能のうち、外部へ出せないものを見極める話に落ちる論点です。以下の各章で、それぞれの機序と対処を順に見ていきます。

実証止まりを生む構造｜技術ではなく制度と体制に原因がある4類型

「実証実験は成功したのに実装に進まない」という現象は、個別の自治体の事情ではなく、補助制度と調達の組み立て方から繰り返し生まれます。原因を分解すると、資金・データ標準・合意形成・人材の4つに収まります。

実証と実装を分ける境目｜運営費と責任主体が決まっているかの差

実証は、期間が区切られた補助金と、企業側の持ち出しで成立します。実装はそうはいきません。毎年の通信費・クラウド利用料・データ更新・保守の支払い元と、障害時に誰が判断するかという責任主体が要ります。SCRA5.0の第6章は、信頼及びガバナンス要件として「都市状態の管理は、責任主体を特定可能でなければならない」と規定しました。責任主体が事業者側に置かれたまま実証が終われば、実装に移す相手がいなくなります。スマートシティの定義や都市OSの成熟レベルの整理はスマートシティとは？政府定義と都市OSの成熟レベルで扱っているため、本記事は障壁と回避策に絞ります。

課題が技術側に見える理由｜調達単位と所管部署の分断が生む誤診

交通は土木、見守りは福祉、防災は危機管理と、所管部署ごとに別々の調達をかけると、データ形式も認証方式も事業者ごとにばらばらになります。この状態で「システム同士がつながらない」という症状が出るため、技術的な難しさに見えてしまいます。実際は調達単位の設計が原因です。SCRA5.0の分野横断統合要件は、この点を「分野間の統合は、特定の業務体系又は組織構造に依存してはならない」と明記しました。庁内の組織図をそのままシステム境界に写した時点で、後から統合するコストが発生します。

4類型の優先順位｜資金・データ標準・合意形成・人材のうち先に潰す順

4つを同時に解こうとすると計画が進みません。順序を付けるなら、資金と人材が先、データ標準と合意形成が後です。理由は復旧コストの差にあります。データ標準と同意範囲は、後から仕様変更や再同意で取り戻せる余地がありますが、運営費の手当てと担当者の配置は、年度予算と人事の周期に縛られるため後追いが効きません。国の資料一式は内閣府のスマートシティ関連ページに集約されており、ガイドブックは第2版（令和5年8月10日）、リファレンスアーキテクチャは第5版が最新です。

交付金の年限と補助率が生む資金の課題｜6年目以降の全額自己負担

資金の課題を「コストが高い」で終わらせると手が打てません。制度の数値に落とすと、いつ・いくら・誰が負担するかが確定します。

第2世代交付金の年限と補助率｜ソフト事業は原則3か年度・最長5か年度

令和6年度補正予算で創設された新しい地方経済・生活環境創生交付金のうち、第2世代交付金のソフト事業と拠点整備事業は、事業計画期間が原則3か年度以内（最長5か年度）、補助率1/2です。1自治体当たりの国費上限は都道府県と中枢中核都市が15億円/年度、市区町村が10億円/年度。インフラ整備事業だけは原則5か年度以内（最長7か年度）で、都道府県は事業計画期間中の総国費50億円（単年度目安10億円）という別枠になります。金額と年限は内閣官房・内閣府の交付金概要資料（令和7年9月）に記載されたものです。補助率1/2という条件は、初年度から半額は自治体が払う構造を意味します。

6年目に現れる負担｜補助対象外になる運用費の内訳と見積りの単位

計画期間が終わった翌年度、いきなり現れるのが運用費です。内訳は、データ連携基盤のクラウド利用料、センサーやゲートウェイの通信回線費、機器の故障交換、データ更新の委託費、アプリの改修費に分かれます。見積りは「システム一式」ではなく、この5費目で単年度あたりの金額を出しておくと、財政部局との協議が具体になります。分野別の事例で運用費をどう賄っているかはスマートシティ事例を分野別に整理した記事にまとめたので、財源の型はそちらを参照してください。

単年度予算の制約を外す方法｜債務負担行為と複数年契約の使い分け

単年度予算のままだと、毎年3月に契約が切れ、事業者側も人を張り付けられません。対処は2つです。1つは債務負担行為を設定して複数年度にまたがる契約を可能にすること。もう1つは、基盤の保守と個別サービスの運用を別契約に分け、基盤側だけ長期契約にすることです。全部を長期契約にすると、使われなかったサービスの費用まで固定されます。判断の境目は、そのサービスの利用実績が読めるかどうか。利用者数の見通しが立たない新規サービスは、単年度で切って評価するほうが撤退しやすくなります。

データ標準の不統一という課題｜SCRA5.0の要件で防ぐ移行不能

データ標準は、つながるかどうかの問題であると同時に、事業者を乗り換えられるかどうかの問題です。ここを外すと、10年単位で選択肢を失います。

SCRA5.0が定める4つの論理要件｜分野横断統合から非ロックインまで

内閣府が令和8年3月11日に公表したスマートシティリファレンスアーキテクチャ第5版は、第6章で都市状態を統合するための論理要件を4つ規定しました。分野横断統合要件、意味仲介要件、信頼及びガバナンス要件、そして非ロックイン要件です。非ロックイン要件は「都市状態モデル及びそれを統合する論理基盤は、特定の技術、製品又は事業者に依存してはならない」「論理構造は、複数の実装方式を許容しなければならない」「都市状態の記述及び参照は、移行可能でなければならない」と3文で定義されています。第5版は、第4版までが約300ページに膨らんで核心が伝わりにくくなったことを踏まえ、構成そのものを整理し直した版です。

共通語彙の仕様が未策定である現在地｜令和8年3月時点で残る空白

注意すべき点がひとつあります。SCRA5.0が参照する「SCRA共通語彙・メタデータ相互運用仕様書」は、公表時点の令和8年3月では未策定で、同年の夏から秋頃の公表を目指すと本文に明記されています。つまり現時点では、語彙の細部は国の仕様書で埋まりません。空白を埋めるのは調達仕様書の側です。具体的には、使用する語彙の定義元、@contextの公開場所とバージョニング方針、旧版データの解釈可能性を維持する期間の3つを、契約条件として書いておきます。仕様書が出た後に整合させる前提で書けば、書き直しは差分で済みます。

最低限そろえる7つのコアエンティティ｜PersonやBuildingなどの扱い

SCRA5.0の第12章は、必須参照のコアエンティティとして7つの概念を挙げています。分野が違っても、この7つの識別子と属性がそろっていれば、後からの突き合わせが利きます。

属性例は表示の都合で絞った一部で、原典にはstatusやparentLocationなどの属性も併記されています。表の「備考」に書かれたPersonの扱いに注目してください。個人識別情報を含まない匿名・集約を前提とする設計が、データモデルの段階で組み込まれています。なお、住民記録や税といった基幹20業務の標準化は所管も期限も別の枠組みで進むため、自治体システムの標準化とは？20業務の移行と期限経過後の実務で扱う論点と混同しないでください。都市OS側のデータモデルと基幹業務システムの標準仕様は、別々に管理します。

個人情報とプライバシー合意形成の課題｜データ種別で分ける同意設計

住民の反対で事業が止まるケースは、同意の取り方そのものより、何のデータを誰に渡すのかが説明できていないことに起因します。先に種別を切り分ければ、説明の範囲が確定します。

データを3種別に分ける判断｜オープン・限定公開・クローズドの線引き

総務省のスマートシティセキュリティガイドライン（第3.0版・2024年6月）は、スマートシティで扱うデータを3種別に整理しました。オープンデータは営利・非営利を問わず無償で二次利用できるルールが適用されたもの、限定公開データはステークホルダ間の契約等に基づいて限定的に共有するもの、クローズドデータは住民記録のように外部へ公開しないものです。事業計画の段階で、収集する項目を1つずつこの3つに割り振ります。割り振れない項目が残ったら、それは収集目的が定まっていない項目なので、収集対象から外します。

住民合意を取り付ける順序｜パーソナルデータの範囲と公表の手順

同ガイドラインは、パーソナルデータを「個人情報に加え、個人情報との境界が曖昧なものを含む、個人の属性情報、移動・行動・購買履歴データなど個人と関連性が見出される情報」と定義し、加工した情報も含むとしています。人流データやカメラ映像から得た滞留人数のように、個人情報に当たらないと整理されがちなデータも、この定義では説明対象に入ります。合意形成の順序は、収集項目と種別の一覧を先に公表し、次に取得方法と保存期間、最後に第三者提供の有無を示す形が扱いやすい順序です。逆順にすると、住民説明会で「何を取っているのか」という最初の問いに戻り、議論が前に進みません。

運用人材が不在という課題｜庁内に残す機能と外部委託の責任分界

人材不足は、人数の問題として語られがちですが、実際には「どの機能を庁内に残すか」が決まっていないことの言い換えであることが多い論点です。

庁内に残す3機能｜企画・データ管理・調達のうち外へ出せないもの

庁内に必要な機能は、事業企画、データ管理、調達の3つに整理できます。このうち調達は制度上、外部へ丸ごと出せません。事業企画も、住民サービスの優先順位を決める行為である以上、庁内の判断が要ります。外へ出しやすいのはデータ管理の実務、つまり基盤の運用監視やデータ更新の作業部分です。庁内体制の作り方そのものは自治体DX推進計画の枠組みと重なるため、自治体DXとは？推進計画第5.1版の重点8項目と進め方と併せて読むと、庁内業務側の体制との役割分担が見えます。

外部委託でも残る責任｜再委託先まで把握する体制と契約書の条件

委託すれば責任まで移るわけではありません。セキュリティガイドライン第3.0版は、横断的な対策の筆頭にサプライチェーン管理を置き、推進主体が委託先・再委託先・提携先を含めて全体を把握すること、セキュリティに関するチェックシートへの回答や第三者認証の取得有無で確認することを挙げています。加えて、インシデント対応で必要になるのは、責任範囲の明確化と、連絡先・対応手順の整備です。契約書に再委託の届出義務と、インシデント時の連絡先・連絡期限を書いておくと、事故のときに探し回る時間が減ります。

事業計画段階で課題を潰すチェック条件｜着手を見送るべき3つの状態

ここまでの4類型を、計画書のチェック項目に変換します。判断は言い切ります。次の条件を満たせない事業は、着手のタイミングをずらしたほうが結果として早い。

着手を見送るべき3つの状態｜運営費・責任主体・データ提供元の欠落

次の3つのいずれかに当てはまるなら、実証にも入らないほうが安全です。第一に、補助期間終了後の単年度運営費の負担部署が決まっていない状態。第二に、データの管理責任者が事業者側にしかいない状態。第三に、収集するデータの提供元が他部署や民間事業者で、提供の継続について書面の合意がない状態です。この3つはいずれも、実証中は表面化せず、実装の直前に露見します。逆に、規模が小さいことや、専任職員がいないことは見送り理由になりません。基盤を共同利用にする、対象分野を1つに絞るといった縮小で対処できるためです。

調達仕様書に入れる4つの条項｜移行可能性と脆弱性情報の提供義務

仕様書に入れておくと後年に効く条項は4つあります。データの記述に用いる語彙の定義元と@contextの公開、契約終了時に全データを機械可読な形式で引き渡す義務、基盤の機能をAPI経由で第三者事業者にも開放する条件、そして新たに発見された脆弱性について委託先から情報提供と対応を受ける義務です。最後の1つはセキュリティガイドライン第3.0版が調達時の仕様書に含めるよう挙げている項目、前の3つはSCRA5.0の非ロックイン要件を契約の言葉に置き換えたものです。「移行可能でなければならない」という要件は、引き渡し形式を書いて初めて実効性を持ちます。

外部の開発会社に任せる範囲｜内製で持つ判断と委託に出す判断の境目

役割分担の基準は、変更の頻度で決まります。毎年見直すもの、たとえばサービスの優先順位づけやデータ公開範囲の判断は庁内に残す。一方、データ連携基盤の構築、既存の業務システムとの接続、アプリの開発と保守は、仕様と引き渡し条件を明確にしたうえで委託したほうが、人件費と技術の陳腐化の両方を抑えられます。委託先を選ぶときに見るのは、実装経験の多さより、契約終了時のデータ引き渡し方法を仕様書の段階で提示できるかどうかです。当社も公共システム開発として自治体の業務システムやデータ連携の実装を請け負っており、調達仕様の検討段階からの相談にも対応しています。

よくある質問

自治体の担当者や発注検討中の方から実際に寄せられる質問のうち、判断に直結するものを5つ取り上げます。

スマートシティの課題として最初に検討すべきものは何ですか？

補助期間が終わった後の運営費と、その負担部署です。第2世代交付金のソフト事業は原則3か年度以内（最長5か年度）・補助率1/2なので、遅くとも6年目には国費が入らなくなります。データ標準や住民同意の範囲は後から修正できますが、予算の手当てと人の配置は年度予算と人事の周期に縛られるため、後追いが効きません。計画書に単年度の運営費の金額と負担部署を書けないうちは、調達に進まない判断が妥当です。

スマートシティの実証実験が実装に進まないのはなぜですか？

実証は期間限定の補助と事業者の持ち出しで成立しますが、実装には毎年の運営費と、障害時に判断する責任主体が必要になるためです。SCRA5.0は信頼及びガバナンス要件として責任主体を特定可能にすることを規定していますが、実証段階では管理責任が事業者側に置かれたままになりがちです。実証の終了時点で引き継ぐ相手がいなければ、技術的に成功していても止まります。

スマートシティに使える交付金の上限額と期間を教えてください。

新しい地方経済・生活環境創生交付金の第2世代交付金では、ソフト事業と拠点整備事業が原則3か年度以内（最長5か年度）、1自治体当たり国費は都道府県・中枢中核都市が15億円/年度、市区町村が10億円/年度、補助率1/2です。インフラ整備事業は原則5か年度以内（最長7か年度）で、都道府県は事業計画期間中の総国費50億円が目安となります。金額は令和7年9月時点の概要資料に基づく数値のため、申請前に最新の公募要領で確認してください。

都市OSは最初から導入する必要がありますか？

対象分野が1つだけなら、先に導入する必要はありません。都市OSの意味は、複数分野のデータを共通の識別体系で結び付ける点にあるため、連携する分野が1つの段階では費用に見合いません。ただし、後から乗せ替える前提で個別システムを作る場合は、SCRA5.0のコアエンティティに沿った識別子と属性を最初から持たせておきます。これを省くと、統合時にデータの作り直しが発生します。

住民の個人情報を扱わなければ同意は不要ですか？

不要とは言い切れません。総務省のガイドライン第3.0版は、パーソナルデータを個人情報より広く定義し、移動・行動履歴など個人と関連性が見出される情報や、それを加工した情報も含めています。人流の集計値やカメラ映像から得た滞留人数も、住民から見れば説明を求める対象です。法令上の同意義務の有無とは別に、収集項目・取得方法・保存期間・第三者提供の有無を公表する手順を、計画段階で組み込んでおくほうが後戻りを避けられます。

関連記事

• スーパーシティとスマートシティの違い：特区指定と規制緩和の有無で枠組みが分かれるため、どちらの制度で進めるかを決める段階で読む記事です。
• デジタルツインとは：本記事で触れた都市状態の記述モデルについて、仕組みと導入の判断基準を実装目線で解説しています。