# エリアデータ連携基盤の共同利用ガイドブック第3.0版
日付: 2026年9月4日
発行元: デジタル庁
## まえがき
旧来は「データ連携基盤」という名称を使っておりましたが、類似の用語が登場・普及している背景から、役割や扱うデータをより具体的にイメージできるよう、昨年度から「エリアデータ連携基盤」という名称に統一しています。
本ガイドブックは、タイトルにあるとおり、元々はエリアデータ連携基盤の共同利用を目的とした、共同利用ビジョンを作成するためのものでした。現在は、エリアデータ連携基盤の共同利用に向けた方針や検討内容だけでなく、その背景、活用事例、エリアデータの利活用について、デジタル庁として考えを網羅した内容に改版しています。
**更新履歴**
|版 |公開日 |目的・概要 |
|---|---|---|
|第1.0版 |2024年10月10日 |エリアデータ連携基盤の「共同利用」 |
|第2.0版 |2025年9月1日 |エリアデータ連携基盤を活用した「データ利活用の推進」 |
|第3.0版 |2026年9月4日 | エリアデータ連携基盤の「より一層の活用」 |
- 【追加内容】 共同利用に至るプロセス、エリアデータ活用や接続サービスの拡充方法、サービス利用者の拡大施策など
**資料構成**
提供形式を以下の2種類となります。
|提供ドキュメント|形式|
| --- | --- |
|本編|構造化された文書|
|Appendix|関連する図表等を用いたスライド|
Github上には、ビジュアルを整え見やすく読みやすいドキュメントとしてHTMLファイルを提供しています。 また、AI等の活用を想定した機械判読可能な、構造化されたドキュメントとしてMarkdownファイルを提供しています。
[エリアデータ連携基盤 共同利用ガイドブック（GitHub）](https://github.com/digital-go-jp/area-data-coordination/tree/main/guidebook)
[TOC]
## 1. 本ガイドブックでの用語の定義
エリアデータ連携基盤に関する、根底となる共通の理念と領域の定義は以下の通りです。
| 用語 | 定義 |
| --- | --- |
| **分野** | 地域が直面する社会的課題の解決および将来的なサービスニーズを見据え、それらの取組において頻繁に連携・共有されるデータの内容や属性の共通性に基づいて設定されるもの。 |
| **パーソナルデータ** | 個人情報に加え、個人情報との境界が曖昧なものを含み、個人の属性情報、移動・行動・購買履歴、ウェアラブル機器等から収集されたデータあるいは加工された情報等、個人と関係性が見出される広範囲のデータ。 |
| **非パーソナルデータ** | オープンデータに代表される、個人情報が含まれないデータ（パーソナルデータ以外のデータ）。 |
| **データアセット** | 地域に存在するデータを、複数の主体やサービスから利用・再利用できるよう、価値ある資産として管理したデータのまとまり。 |
| **エリアデータ** | 行政手続、健康、交通、防災、観光などの暮らしを支える様々なサービスのデータや、地理データ、公共データ等の様々なデータアセット。 |
| **協調領域** | 各事業者が協調・協力して、機能を共有していくことで、産業の成長を見込む領域。 |
| **競争領域** | 各事業者が競争して、全体として産業の成長を見込む領域。 |
| **サイロ化** | 各システムが独立し、データ連携がされていない「縦割り」の状態。 |
| **バックキャスト（逆算）思考** | 予測可能な未来の延長線上で考えるのではなく、まず「あるべき理想の未来像」を最初に設定し、そのゴールから現在に遡って、今、何をすべきか、どのような課題を解決すべきかを導き出す思考・計画策定の手法。 |
| **AIネイティブ** | システムの開発や運用の初期段階から大規模言語モデル（LLM）をはじめとする人工知能の活用を前提とし、その全プロセスにおいて安全性、透明性、権利保護などのガバナンスやリスク管理の仕組みが一体として組み込まれている設計思想。 |
| **データモデル** | 異なるシステムや地域間でデータを円滑に相互連携（相互運用）させるために、データの意味、項目及び相互の関係性を構造化して定義したもの。 |
▲[目次に戻る](#00)
## 2. エリアデータ連携基盤とは
### 2.1. 目指すべき姿
日本の多くの地域が人口減少局面を迎える中、「限られたリソースでの住民サービスの維持」が喫緊の課題です。
地域に関わる全ての人々の満足度を向上させるため、以下の3つの軸で取組の推進が必要だと考えます。
* **地域の生活を守る**：住民サービスや生活インフラの維持・確保
* **より良い生活をつくる**：暮らしの利便性向上や新たな価値の創出
* **地域で稼ぐ力をつける**：地場産業の活性化や地域経済の循環
これらのまちづくりを机上の空論で終わらせず、具体的に実現するためには「協業」と「利活用」の両輪が不可欠です。
* **多様な主体との「協業」**
行政単独の枠組みを超え、民間企業、NPO、住民などが一体となった推進体制。
* **エリアデータの「利活用」**
既存サービスの付加価値向上や新サービス創出に向け、地域に眠る様々なデータを分野横断でつなぐ。
これら「協業」と「利活用」を掛け合わせ、経験や勘に頼るのではなく、客観的なデータを根拠に施策を決定・実行する「データドリブン」な取組への転換を行い、供給側の都合ではなく、需要側（住民一人ひとり）の事情やニーズに合わせた「個人に最適化されたサービス」の実現を目指すことが必要です。
### 2.2. データ利活用に向けた現状
デジタルサービスの導入は進みつつあるものの、住民サービスの多くはバラバラに提供されているのが現実であり、データ利活用が困難な状況です。
* **サービスごとのID分離とシステムのサイロ化**：
各システムが独立しサイロ化されていて、住民はサービスごとに何度も同じ情報の入力を求められます。
* **データ利活用の限界**：
行政側が利用者の全体像を把握できず、データの紐付けが困難なため、データ利活用が進まない要因となっています。
* **データアセットの紐付け作業の重複**：
同じデータアセットをサービス毎に個別に紐付けるといった非効率な作業が必要となっています。
### 2.3. データ利活用に必要な要素
この分断を解消するためには、サービスやデータアセットをつなげることが重要です。 その際、繋ぎ合わせるサービスやデータアセットが少ない場合は、一つ一つを繋ぎ合わせる形でも問題ないかもしれないですが、その数が多くなっていくと、サービスやデータアセットが複雑に絡み合い、いわゆる「スパゲティ化」の状態となってしまいます。そのため、サービスやデータアセットを繋ぐハブのようなものを置く必要があり、住民サービスを中心とした地域のデータを活用するためのエリアデータ連携基盤が必要になります。
そして、エリアデータ連携基盤は、多くのサービスやデータアセットが繋がることにより、その真価が発揮されるものです。
>🍝スパゲティ化とは
>システムやプログラムの構造が複雑に絡み合い、どこを変更すると、どこに影響するのかが分からない状態になることです。スパゲティの麺が絡まって、1本だけ取り出せない様子を例えて「スパゲティ化」と呼ばれます。一般には、プログラム内部を指す「スパゲティコード」だけでなく、システム間連携やデータ連携が複雑化した状態にも使われます。
>理論上、全てのシステムを相互接続する場合の接続数は、「接続数 ＝ システム数 ×（システム数－1）÷ 2」といわれていて、システム数が5つであれば接続数は10。システム数が10であれば接続数は45。システム数が20であれば接続数は190と大幅に増えていきます。
>こうなると問題は、「改修の影響範囲が分からなくなる」、「保守費用が増える」、「障害の原因が特定しにくい」、「新しいサービスを追加しにくい」などの問題が生じてしまいます。
▲[目次に戻る](#00)
## 3. エリアデータ連携基盤の構成
エリアデータ連携基盤は、内閣府 科学技術・イノベーション推進事務局が定める「スマートシティリファレンスアーキテクチャ」を共通の指針として設計されています。これは、全国の地域で共通的に活用可能な「データ利活用の設計図」に相当するものです。
### 3.1. 基盤を支える「3つの要素」
この基盤は、まち全体のデータをスムーズに動かすために、以下の3つの要素を技術的に実現しています。
* **① 相互運用（つながる）：**
異なるサービスや他のエリアデータ連携基盤同士が、安全かつ効率的に連携・接続し合えるようにします。
* **② データ流通（ながれる）：**
スマートフォンアプリやまちのIoTセンサーなど、異なる形式で流れるデータを扱いやすい形式に変換し、効率的に仲介します。
* **③ 拡張容易（ひろげられる）：**
必要に応じて機能を追加し、システムを段階的に拡張することが可能です。
**主要な機能構成**
目的に合わせて必要な部品を組み合わせる「ビルディングブロック方式」を採用し、以下の機能（モジュール群）を柔軟に組み合わせて、目指す姿を実現させます。
* **データ仲介機能**： オープンデータ等の資産の有効的な活用や、各サービス間の効率的なデータ連携を推進。
* **共通モジュール群**： ユーザー管理、認証管理（本人確認など）、認可管理（権限付与）、センサー等のデバイス管理など。
### 3.2. エリアデータ連携基盤の4つの管理層
エリアデータ連携基盤は、大きく分けて「サービスマネジメント」「データマネジメント」「アセットマネジメント」「外部連携」の4つのブロックを管理する機能群で構成されています。
**① 主なサービスマネジメント機能群**
利用者やアプリが基盤にアクセスする際の「玄関口」となり、セキュリティの確保や利便性の向上を図る機能となります。
| 機能名 | 役割 |
| --- | --- |
| **APIゲートウェイ** | 様々なアプリからのリクエストを一括で受け付け、交通整理を行う「総合受付」です。 |
| **ユーザー管理・認証・認可** | 誰が（ID）、本当に本人か（認証）を確認し、その人が「どのデータを見てよいか（認可）」の権限を厳密にチェックします。 |
| **サービスライフサイクル管理** | 基盤に接続する新しいアプリやサービスの登録・変更・削除を管理します。 |
| **サービス利用履歴管理** | どのアプリがどの程度基盤を使ったかの履歴を記録し、レポートにします。 |
| **サブスクリプション管理** | サービスの利用権限や、利用の開始・終了状態を管理します。 |
| **開発ポータルサービス** | 開発者が「どのようなデータやAPIがあるか」を検索し、テストできる専用のウェブサイトです。 |
コアとなるAPIゲートウェイについて、デジタル庁は推奨モジュールとして[「Kong Gateway」](https://digital-service-catalog.digital.go.jp/service/a0PQ800000QvvxBMAR/a001075)を提供。
**② 主なデータマネジメント機能群**
収集されたデータを、適切に整理し必要に応じて即時に利用できる環境を提供する「心臓部」となる機能です。
| 機能名 | 役割 |
| --- | --- |
|**データ仲介機能（非パーソナルブローカー）**| 非パーソナルデータを蓄積、または分散管理し、サービス間のデータ流通を制御するAPIを提供するブローカーモジュール。|
|**データ仲介機能（パーソナルブローカー）**|サービス事業者が保有しているパーソナルデータを、目的別の個人同意に基づき組織をまたがって共有できるAPIを提供するブローカーモジュール。|
コアとなるデータブローカーについて、デジタル庁は2つの推奨モジュールを提供。
非パーソナルブローカー[「NGSI v2 FIWARE Orion」](https://digital-service-catalog.digital.go.jp/service/a0PQ800000QwsHBMAZ/a001077)
パーソナルブローカー[「パーソナルデータ連携モジュール」](https://digital-service-catalog.digital.go.jp/service/a0PQ800000QwrL7MAJ/a001072)
**③主なアセットマネジメント機能群**
まちに設置されたIoTセンサーや、既に動いている他のシステムを管理・監視する機能です。
| 機能名 | 役割 |
| --- | --- |
|**デバイス管理ブロック（IoTセンサーなどの管理）**|まちのカメラや温度センサーなどの「登録（ライフサイクル）」から、「稼働しているかどうかの監視（死活監視）」、さらに遠隔での再起動などの「制御（アクチュエーション）」、安全な接続のための「デバイス認証」までを包括的に担います。|
|**システム管理ブロック（他システムとの連携管理）**|既に自治体や民間企業が保有している外部システムとつなぐための連携情報（鍵やパスワードなど）や、その接続状態を管理します。|
**④主な外部データ連携機能群**
外部システムと連携する際に、データの変換・補完およびデータ交換を行う機能です。
| 機能名 | 役割 |
| --- | --- |
|**データ処理**|データアセットから取得したデータの差異を吸収し、標準データモデル等へ変換する機能を提供。取得したデータを 様々な用途で汎用的に利用することが可能となり、多様な基盤間でのデータ利活用が促進されます。|
|**データ転送**|異なる都市・地域、他分野のシステムといった、共通のガバナンスを持たない外部システムとの間で、安全（セキュア）かつ円滑にデータの送受信やアクセスを行う役割を担います。|
### 3.3.エリアデータ連携基盤の全体像
これら全ての機能を最初から全て作る必要はありません。自治体や地域の予算、「まずは観光から始めたい」「次は防災を強化したい」といった目的に合わせ、必要な部品だけを組み合わせる「ビルディングブロック方式」で構築することが可能です。これにより、コストを抑えながら賢く成長させることができます。
ビルディングブロック方式の考え方やシステムの構成などは、内閣府が公開するスマートシティリファレンスアーキテクチャに、推奨される設計図として、自治体や企業なども含めた全体の枠組みや関係性が示されています。このリファレンスアーキテクチャを活用することで、相互運用性が確保され、スムーズなデータの利活用が実現できますので、エリアデータ連携基盤の構築、活用の際には必ず押さえておく必要があります。
また、デジタル庁の推奨モジュールに関する導入・活用方法や、推奨モジュールの更新情報は以下のリンクから確認できます。
[エリアデータ連携基盤に関する取り組み（一般社団法人データ社会推進協議会）](https://data-society-alliance.org/data-ex/area-data/)
[基礎からわかるデータ連携基盤ガイド（一般社団法人データ社会推進協議会）](https://data-society-alliance.org/data-ex/area-data/article/)
▲[目次に戻る](#00)
## 4. エリアデータ連携基盤の属性整理の解説
共同利用の検討に向けて、現状のエリアデータ連携基盤の把握やエリアデータ連携基盤の設計を行う際に、**域内の基盤の状況を把握し、共同利用に向けた基盤設計に必要な項目（パラメータ）を整理したもの**が以下となります。これを参考にしながら整理し、協議の際に活用をしてみてください。
### 4.1. スキームおよび利用範囲
サービスや基盤を「誰が提供し、どこまで届けるか」という運営の枠組みを整理します。
* **サービス提供スキーム：**
基盤に接続するサービスを提供する組織の体制を示します。
* *【選択肢】* なし ／ 自治体のみ ／ 民間のみ ／ 自治体と民間 ／ 運営組織
* **基盤提供スキーム：**
エリアデータ連携基盤そのものを運営・提供する組織の体制を示します。
* *【選択肢】* なし ／ 自治体のみ ／ 民間のみ ／ 自治体と民間 ／ 運営組織
* **サービス利用者の範囲：**
提供されるサービスが利用可能な地理的範囲を示します。
* *【選択肢】* 特定の「基礎自治体内（市町村など）」限定 ／ 「都道府県内」全域
### 4.2. 基盤の数量（データ・認証の受け皿）
域内に存在する、認証やデータ連携のための基盤の「数」を整理します。
* **個人認証サービスの数：** 域内に存在する個人認証サービスの数（0 ／ 1 ／ 2つ以上）
* **非パーソナルエリアデータ連携基盤の数：** 天気や交通量など、個人情報を含まないデータを扱う基盤の数（0 ／ 1 ／ 2つ以上）
* **パーソナルエリアデータ連携基盤の数：** 健康や行政手続など、個人に紐づくデータを扱う基盤の数（0 ／ 1 ／ 2つ以上）
### 4.3. ブローカーのデータ管理方式
データの生成・蓄積・利用・管理（認可）の責任を明確にし、最適なデータベースの所有方法を整理します。
| 管理方式 | 概要 | メリットと注意点 |
| --- | --- | --- |
| **なし** | ブローカー（データ仲介者）が存在しない状態。 | - |
| **外部** | 基盤の内部にはデータを溜めず、外部のサービスごとのデータベースを**仲介（パス）するだけ**の方式。 | 内部にデータを持たないため安全です。 |
| **内部（データベース分離なし）** | 接続する全てのサービスのデータを、**1つの巨大なデータベース**に丸ごと蓄積する方式。 | まとめて扱いやすい反面、組織ごとのデータ状態の把握が難しくなる場合があります。 |
| **内部（データベース分離あり）** | データを1つの基盤に入れつつも、**組織・サービスごとにコンテナ（データベース）を分離**して蓄積する方式。 | セキュリティが高く、組織ごとのデータ状態の把握が容易になります。 |
### 4.4. 個人認証の要素と基盤間連携
安全にデータをやり取りするための「本人確認のルール」と「基盤同士のつなぎ方」を整理します。
**個人認証サービスの3要素**
個人認証は、以下の3つの属性（ステップ）で構成されます。
1. **身元確認：** 書類等で「その人が本当に実在するか」を確認するレベル。
2. **当人認証：** パスワードや生体認証等で「今操作しているのは本人か」を確認するレベル。
3. **認証連携：** 認証を行うシステム（IdP）とサービスを安全につなぐ処理。
**基盤同士の連携（あり／なし）**
* **基盤間連携（認証連携）：**
複数の基盤が統合する際、お互いの「身元確認」や「当人認証」のレベルが一致（整合）しているかを示します。
> ⚠️ **注意：** レベルがズレていると、厳しいセキュリティを求めるサービスが利用できず、住民の利便性が損なわれます。そのため、連携相手のレベルを引き上げるなどの調整が必要です。
* **基盤間連携（データ連携）：**
基盤同士でデータを融通し合えるかを示します。特に個人データ（パーソナル）をやり取りする場合は、お互いの基盤で「このデータはAさん自身のものだ」と正しく一致させるため、上記の**認証連携が必須**となります。
### 4.5. 規約の記載状態（ルールの見える化）
住民向けの利用規約に、必要な項目（「あり」「なし」「区別しているか」等）が網羅されているかを確認し整理します。
* **責任範囲の明確化：** 部品（モジュール）ごとの責任や、基盤側とサービス側の責任の境界が記載されているか。
* **信頼性の担保：** サービスを提供する組織の認定要件や、サービス開始後の定期的な監査に関するルールが記載されているか。
これらを整理しておくことで、共同利用の検討やエリアデータ連携基盤の設計がスムーズに行えます。
🔖詳細については[Appendix](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/84c08375-e8c4-440f-8ef4-521a4a36ed9f/e9c28525/20260904_policies_digital-garden-city-nation_guideline-of-area-data-coordination-platform_appendix.pdf) P.3「エリアデータ連携基盤の検討に向けた属性整理」をご確認ください。
▲[目次に戻る](#00)
## 5. エリアデータ連携基盤のコスト構造
エリアデータ連携基盤の導入および継続的な運営に当たっては、「費用の内訳が不透明」「継続的に発生するコストの全体像が把握しづらい」「適正価格を判断する基準が示されていない」といった課題が多くの自治体から挙げられています。 コストの全体像を正しく把握し、どのプロセスで費用をコントロールできるかを見極めることが重要です。
基盤に関わる費用は、実務上、初期費用と運用費用に大別されます。
初期費用と運用費用それぞれに対して、3つの費用区分から構造を整理しました。
### 5.1. 初期費用と運用費用の構造
| 費用区分 | 初期費用（新規導入・構築） | 運用費用（ランニングコスト） | 費用発生個所の実務的解説 |
| --- | --- | --- | --- |
| **クラウドサービス利用料**
（インフラ費用） | ✕
*(原則発生しない)* | ◯
*(毎月発生)* | クラウドを前提とするため、初期に仮想マシン（VM：Virtual Machine）等のサーバー開設費が単独で発生することは通常ない。運用期に、流通するデータ量やアクセス数に応じた「従量課金」として発生する。 |
| **運用保守費用**
（役務費・SI費） | ◯
*(初期構築・設定)* | ◯
*(毎年の監視・保守)* | 24時間365日の死活監視、アップデート、ヘルプデスク窓口対応の対価。 |
| **アプリライセンス料**
（サービス費用） | ◯
*(初期環境設定等)* | ◯
*(月額・年額サブスク)* | 防災、交通、医療といった個々のデジタルアプリ（フロントサービス）の利用料。自治体ごとに個別契約するか、基盤事業者が一括して窓口を一本化するかを選択する。 |
### 5.2. 運用保守コスト構造の明確化と対策
クラウドサービス利用料やアプリライセンス料については、必要経費として見込まざるを得ず、運用保守費用については役務となります。運用保守作業を人件費ベースで4つの区分に構造化して「適正コスト」を可視化し、共同利用を検討する際に活用できる共通言語を整備することを目的としています。
|区分|内容|必須/任意|難易度|主作業者|コストの集中ポイント|
|---|---|---|---|---|---|
|a：運用| アカウント管理／問合せ／障害対応／基盤管理|必須|低～高|運用保守者| 問合せ＋障害対応に40〜70% 集中|
|b：データ整備|静的データ登録・更新／オープンデータ公開|必須|低～中| データ提供者・自治体職員|モデル設計＋登録に60〜100% 集中|
|c：データ連携|外部システム／センサーとのAPI連携|任意|高|委託事業者中心|外部連携設計＋テストに70〜90% 集中 ←最大膨張要因|
|d：外部サービス連携| 外部サービスへの提供・接続設定|任意|中～高|基盤管理者・委託事業者| 接続設計＋テストに55〜75% 集中|
**コスト適正化のポイント**
上記のコスト構造を踏まえ、コストを抑え共同利用を推進するためには以下の観点が重要です。
1. **内製化による抑制（区分a・b）** アカウント管理や静的データの登録といった「定常×標準化」が可能な作業は、自治体職員による内製化の余地があります。この作業を内製化することで、共同利用におけるスケールメリットが効きやすくなります。
2. **仕様共通化による削減（区分c・d）** 外部システムやサービスとの連携といった「連携×外部依存」の高コスト・高難度領域については、仕様の共通化や標準化を行うことが有効です。これにより、委託費の構造的な削減が見込めます。
3. **指標化とガイドラインへの組み込み** 本コスト構造を適正調達の指標として組み込むことで、調達時の検討を促し、自治体間の価格妥当性評価や他地域への横展開の判断材料として活用することが推奨されます。
🔖詳細については[Appendix](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/84c08375-e8c4-440f-8ef4-521a4a36ed9f/e9c28525/20260904_policies_digital-garden-city-nation_guideline-of-area-data-coordination-platform_appendix.pdf) P.16「エリアデータ連携基盤 運営保守コスト構造の明確化」をご確認ください。
### 5.3. 財政負担を賢く抑えるための「費用軽減アプローチ」
限られた財政リソースの中で、基盤のコストを最小限に抑え込むための具体的な戦略を解説します。5.1.初期費用と運用費用の構造で示した費用区分ごとに適切な対策を講じます。
**初期構築時・運用時の「運用保守費用（役務費・SI費）」を抑える**
* **デジタル庁の推奨モジュールを活用することによる仕様検討工数の削減：**
推奨モジュールを採用することで、システム要件や基本仕様をゼロから検討・個別設計する「設計工数（人件費）」を徹底的に排除します。仕様を1から作らないことが最大の抑制につながります。
* **標準データモデルの採用によるデータ設計工数の削減：**
デジタル庁が公開する「標準データモデル」のルールを仕様に指定することで、異なるシステム間でデータを受け渡す際、名寄せやデータ変換のための「個別マッピング開発・設計工数」を劇的に削減します。
* **個別要件の徹底的な排除：**
「自地域だけの特別なオリジナル機能」を安易に追加しないことがポイントです。運用のフェーズにおいても、メニューが標準化されていることで、ベンダー側の保守作業がシンプルになり、毎年のランニングコストを低く抑えられます。
* **自身で対応できる範囲（内製化）の見極め：**
サポートや保守内容のメニューを事前に可視化し、「単純なアカウント追加」や「簡易なデータマッピング」など、共同利用の運営組織の内部で対応できる作業を切り分けることで、事業者に支払う委託料を削減します。
**運用（ランニング）時の「クラウドサービス利用料」を抑える**
* **過剰サイジング（オーバープロビジョニング）の防止：**
将来のデータ流通量の増加を恐れて、最初から巨大なサーバーパワーを確保するような過剰な初期サイジングを避ける必要があります。クラウドの最大のメリットである「必要に応じて柔軟に拡張できる特性」を活かし、最初はスモールスタートで実流動量に見合った適切なサイズ（ジャストサイズ）に設定することが基本となります。
**「アプリライセンス料」について**
* アプリライセンス料については、利用ユーザー数や導入サービス数に応じたパッケージが多く、調達時のボリュームディスカウント交渉や、国・関係団体が提供するマッチング事業等の枠組みを有効活用するほかに独自の削減余地は小さいため、固定費として予め予算枠を固めておく必要があります。
**構築における推奨モジュールの活用による経費抑制**
* エリアデータ連携基盤の新規構築に当たっては、独自仕様での個別SIではなく、推奨モジュールやオープンソースソフトウェア（以下、OSSという。）を利用して構築することで費用の抑制が行えます。
🔖詳細については[Appendix](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/84c08375-e8c4-440f-8ef4-521a4a36ed9f/e9c28525/20260904_policies_digital-garden-city-nation_guideline-of-area-data-coordination-platform_appendix.pdf) P.25「推奨モジュールの活用による経費抑制効果」をご確認ください。
### 5.4. OSSの正しい捉え方と活用
**デジタルインフラとしてのOSSと「無意識のバイアス」**
現代のデジタル社会において、OSSは、目に見えない巨大な「デジタルインフラ」の役割を果たしています。
* **圧倒的な普及率：** 世界の企業向け（エンタープライズ）製品やクラウドサービスの **90%以上** で何らかのOSSが稼働していると言われています。
* **開発のベース：** 現在、新しく構築されるシステムのソフトウェアコード（プログラム）のうち、実質 **70%〜90%** は既存のOSSコンポーネント（部品）を組み合わせて作られていると言われています。
>💡 **OSSの成り立ち**
>元々は、ソフトウェアを誰もが自由に「実行」「学習」「改変」「再配布」できるようにするという、技術者の純粋な倫理・コミュニティ運動から始まったもの。
現在では、ソースコードが広く公開されていることで、世界中の何万人もの優秀なエンジニアたちが日々バグを修正し、機能のアップデートを重ねています。そのため、一企業の独占製品よりもむしろ **高品質で安全なソフトウェアへと進化を遂げる仕組み** が確立されています。
一方で、私たちの周りには依然としてOSSに対する「無意識のバイアス（思い込み）」が存在しています。
1. **「タダで使えるものは、品質もセキュリティも低いに違いない」**
2. **「ネットにあるコードはフリー素材と同じで、どう使ってもいいはずだ」**
3. **「OSS活動は、業務時間外に個人の趣味でやるものだ」**
これらの知識不足が招いたバイアスを見過ごすことは、有用な技術の採用を遅らせる「機会損失」や、安易な利用による「ライセンス違反・セキュリティ事故」という重大なリスクをもたらす原因となり得るため、簡単にOSSについて解説します。
**「フリー＝何でも自由」ではない：ライセンスの罠と「配布」の定義**
「OSSはフリー（無償公開）だから、どのような使い方をしても制約はない」と誤解されることがありますが、実際には作者の権利や利用ルールを定めた「OSSライセンス」を厳格に遵守する必要があります。これは、開発者の権利と利用者の自由を守るための「取り決め」です。
ライセンスは大きく以下の2つのタイプに分類されます。
| ライセンスの類型 | 主な特徴とルール（利用時の条件） | 代表的なライセンス例 |
| :---- | :---- | :---- |
| **① パーミッシブ型** （寛容型ルール） | 利用条件が非常に緩く、「著作権の表示」さえ残せば、OSSを組み込んだ自作のプログラムを**有料の秘密製品（非公開）として販売・配布してもよい**とするライセンスです。企業が独自のビジネスに最も取り入れやすい形といえます。 | MITライセンス、Apache 2.0、BSDライセンスなど |
| **② コピーレフト型** （恩返し型ルール） | 自由の連鎖を守るための強いルールです。このOSSを改変したりシステムに組み込んだりして新しいソフトウェアを作った場合、**その新しいプログラムの設計図（ソースコード）も、同じようにオープンソースとして無償公開しなければならない**という義務（伝播）が生じます。 | GPL（General Public License）など |
エリアデータ連携基盤の中核としてデジタル庁の推奨モジュールは、ライセンス条件（改変部分の公開義務等）を確認のうえで利用できます。
**品質を見極める「目利き力」と3段階の評価プロセス**
なぜ、有償の商用ソフトウェアよりも、無償のOSSの方が高品質であるケースが存在するのか。その根拠は、OSS特有の検証メカニズムにあります。
**リーナスの法則（Linus's Law）**
**「十分な数の目があれば、全てのバグは洗い出される（Given enough eyeballs, all bugs are shallow）」**。
閉ざされた商用開発と異なり、人気のあるOSSプロジェクトでは、世界中の何千、何万人というエンジニアがソースコードを日々チェックし、自らのプロジェクトで酷使しています。この圧倒的な「検証量の違い」と、中身がブラックボックスではない「透明性」こそが、堅牢性を生み出す源泉です。
しかし、公開されている全てのOSSが高品質なわけではありません。組織が利用する上で最も重要なのは、無条件に信じることではなく、「正しく疑い、品質を評価する目（目利き力）」を持つことです。以下に、失敗しないための実践的な3段階のチェックプロセスを提案します。
**【第1段階】基本チェック**
* **ライセンス適合性：** 自組織の提供モデル（社内利用、配布、SaaS）に合致するか確認します。
* **プロジェクトの活発性：** OSSコミュニティの「休眠中」を避けるため、過去数ヶ月以内にコミット（更新）やIssueへの返信があるか確認します。
* **機能要件：** ドキュメントを読み、必要最低限の機能が備わっているか確認します。
**【第2段階】技術的評価**
* **動作の容易さ：** ドキュメント通りにスムーズに動くか（導入コストに直結）確認します。
* **パフォーマンスと安定性：** 実環境に近いユースケースで負荷やメモリリークを測定します。
* **統合性と依存関係：** 既存システムとスムーズに連携できるか、依存している他ライブラリの品質に問題はないか確認します。
**【第3段階】セキュリティとリスク評価**
* **脆弱性履歴と対応の透明性：** 単に脆弱性がゼロかを見るのではなく、発見された際に「どれほどのスピードで修正され、情報公開されたか」という対応の迅速さを見ます。
* **持続可能性：** 特定の1社や個人だけに依存せず、複数のスポンサー企業や多様なコミュニティが存在しているか確認します。
* **リスクの受容可能性：** 完璧な安全性を求めるあまりに導入を諦めるのではなく、インターネット未接続の社内ツールなら受容するなど、ビジネス価値とのトレードオフで判断します。
デジタル庁の推奨モジュールについては、一般社団法人データ社会推進協議会（DSA）において、バグ情報やコミュニティ内での対応を定期的に確認し、[国内への情報提供](https://data-society-alliance.org/data-ex/area-data/module/update/)などを実施しています。
▲[目次に戻る](#00)
## 6. 共同利用の必要性と効果
### 6.1. 協調領域と競争領域
人口減少下において、地域の住民サービスの維持等が課題となっています。このような状況下で、各事業者が独自の基準でバラバラにシステムを乱立させれば、社会全体の投資効率は著しく低下し、コストの回収も困難になります。
そこで、お互いに共通化できる基盤やデータの標準ルールを「協調領域」とし、無駄な重複投資を排除し、競争領域へ集中することが必要です。これは、地域サービスを維持するというマクロ（国・自治体）の視点と、生存戦略というミクロ（事業者）の視点の双方から極めて重要なアプローチです。
### 6.2. デジタル公共インフラ（DPI）とデジタル公共財（DPG）
デジタル庁として協調領域における標準化/共通化については、以下のように捉えています。
* **デジタル公共インフラ（DPI：Digital Public Infrastructure）**
国が中心となって整備し、社会全体の共通基盤とするもの。（例：マイナポータル、ベース・レジストリなど ）
* **デジタル公共財（DPG：Digital Public Goods）**
誰もが標準的に使えるように公開されたシステム、ソフトウェア、データモデルなどの知的な資産。
> 💡 **エリアデータ連携基盤の位置付け**
> 「エリアデータ連携基盤」は、その中核（コア）にデジタル庁が示す推奨モジュールを含んでおり、特定の事業者に縛られないオープンな仕様を前提としています。そのため、デジタル庁は本基盤を標準的に扱うツール＝「デジタル公共財（DPG）」に該当するものと考えています。
> したがって、本基盤は各自治体でバラバラに抱え込むのではなく、「協調領域として、共同利用すること」が極めて合理的であると言えます。
### 6.3. エリアデータ連携基盤を共同利用する「3つの目的と効果」
2025年5月の自治体向け調査結果から、エリアデータ連携基盤を複数自治体や広域で共同利用することには、主に以下の3つの大きな効果があることが分かっています。
| 期待される効果 | 具体的なメリット（解説） |
| --- | --- |
| **①負担の軽減（割り勘効果）** | 共通の基盤をシェアし、重複投資を回避することで、1自治体当たりの初期構築費や毎年の運用経費の負担が軽減します。 |
| **②広域でのDX推進** | 近隣の自治体が同じエリアデータ連携基盤を活用することで、住民が居住地（自治体の境界）を意識することなく、どこでも等しく高度なデジタルサービスを享受できる環境に繋がります。 |
| **③サービスの共同利用促進** | データ連携の土台（ハブ）が共通化されるため、その上で動く民間企業や自治体のデジタルサービス自体も、他の地域へ横展開しやすく（相互に共同利用しやすく）なります。|
### 6.4. 利用モデル（テナント方式）による費用感と「割り勘効果」の本質
クラウドサーバーの利用形態が「シングルテナント（一戸建て型）」か、「マルチテナント（アパート型）」かによって、費用構造、特に **運用委託料（役務費）** の面で大きな差が生じます。
* **シングルテナント（自組織専用にインフラ環境を構築）：**
セキュリティの分離レベルやカスタマイズ性は極めて高いものの、インフラの維持だけでなく、**保守・監視体制やパッチ適用などの「役務」を単独で維持・負担する**ため、全体の料金は高額になります。
* **マルチテナント（複数自治体・広域でシステム環境を共同利用）：**
1つの強固な基盤環境をシェア（共同利用）することで、コストを大幅に抑えることができます。
> 🪄 **マルチテナントにおける「割り勘効果」の本質**
> マルチテナントによって費用負担の軽減（割り勘効果）が見込めるのは、主に **「運用委託料（役務費）」** です。基盤全体のセキュリティ監視、システムの保守・更新作業、不具合対応などの役務は、1つの環境に集約されているマルチテナントの方が事業者の作業効率が圧倒的に高くなるため、1自治体当たりの負担額を軽減できます。
> 一方で、**「クラウドサービス利用料」** や **「アプリライセンス料」** は、参加自治体（利用者）や流通するデータ量が増えればそれに応じたキャパシティ（サーバーパワーやアカウント数）が必要となるため、割り勘による単価の低下は限定的であり、流通量に応じたスケールアップによるランニングコストの変更を考慮しておく必要があります。
### 6.5. 近隣自治体で連携するメリット
エリアデータ連携基盤の共同利用を進めるに当たっては、遠く離れた地域と組むよりも、**「近隣の自治体同士」で共同利用する方が、地域課題や住民のニーズが近く、円滑にプロジェクトを進めやすい**という特徴があります。
また、実際のデータ利活用の効果という観点からも、生活圏や経済圏が重なる「隣のまちのデータ」を掛け合わせる方が、遠いまちのデータを使うよりも、はるかに地域活性化や利便性向上に対して効果的です。
デジタル庁では以下の「都道府県ごとに1つ」というコンセプトを掲げ、2025年3月末までに各都道府県に対して「共同利用ビジョン」の策定を要請しました。
> 📌 **共同利用の基本概念**
> * **分野別のデータ連携基盤：** 医療、交通、防災など、特定の「専門分野ごと」の基盤は、原則として各都道府県に**1つ**。
> * **分野間のデータ連携基盤：** それら異なる分野のデータをさらに横断的につなぐ「全体のまとめ役」としての基盤も、各都道府県に**1つ**。
> * **推奨モジュール：** これらは原則、デジタル庁が公開するサービス／システムのカタログが推奨するエリアデータ連携基盤技術から採用する
**都道府県単位としている理由**
デジタル庁は、地域の実情を細かく把握した上で、それぞれの市町村とスムーズに協議・調整を行うための司令塔（コーディネーター）としての役割を考えた際に、**「都道府県」という単位でまとまることが妥当である**と考えています。
### 6.6. 全国における共同利用の現状
47都道府県のうち、過半数の地域で基盤の導入が進んでいるものの、「都道府県間の広域での共同利用」という観点では、**まだまだ多くの自治体において協議や調整が続いている発展途上の状況** です。
だからこそ、先行している13団体や5団体の「共同利用ビジョン」を横展開し、残りの地域がスムーズに合流できるようなサポート体制の強化が、今後の日本全体のDX（デジタルトランスフォーメーション）の成否を分ける鍵と考えています。
47都道府県におけるエリアデータ連携基盤の共同利用のステータスは、以下の通りです。(2026年9月4日現在)
| 共同利用のステータス | 団体数 | 現在の状況と評価 |
| --- | --- | --- |
| **都道府県基盤を共同利用している** | **13** | 都道府県がリーダーシップを取り、域内の市町村が共通の基盤を効果的に共同利用できている先行地域です。 |
| **域内市町村基盤を市町村同士で共同利用している** | **5** | 都道府県単位ではないものの、近隣の市町村同士が自発的に共同し、広域で共同利用を進めている地域です。 |
| **域内に基盤はあるが、共同利用は行っていない** | **19** | 既にデータ連携の土台は立ち上がっているものの、まだ特定の自治体内での利用にとどまっており、周辺への横展開を模索している地域です。 |
| **基盤を保有していない** | **10** | 基盤を有していないものの、これからデータ連携の検討を本格化させる地域です。 |
各都道府県が策定した「共同利用ビジョン」の具体的な内容やリンクは、デジタル庁の公式ウェブサイトにて公開しています。
🔗 [デジタル庁：エリアデータ連携基盤 共同利用ビジョン一覧](https://app.powerbi.com/view?r=eyJrIjoiNTMyOTA0OGYtMzQyZS00MTMxLWI5ZTItMDFmNzEyMDE4MTdlIiwidCI6IjA2ZTRhMGZmLTQ5NzItNGE4Yi1hZjMwLTQ1NzEzNjFkMTM0NCJ9&pageName=c8a4c7eb46e700641073)
▲[目次に戻る](#00)
## 7. 共同利用前後の型の定義
### 7.1. 型の概要
共同利用の「型」は、共同利用ビジョンの策定に当たり、各都道府県や各市区町村が「現在どのような状態にあり（前の型）」、「共同利用によってどのような状態を目指すのか（後の型）」を客観的に把握・選択できるよう、エリアデータ連携基盤の運営・提供ステータスを類型化（パターン化）したものです。
**【共同利用前の型】現状のパターン（型1.1〜1.5）**
共同利用を始める前に、自治体が単独で基盤を抱えている、あるいは全く導入していない状態を分類したものです。
| 型番号 | 基盤の種類 | 基盤・サービスの提供スキーム | 特徴・詳細 |
| --- | --- | --- | --- |
| **型1.1** | なし | なし | 都道府県内にエリアデータ連携基盤を運営している自治体が1つもない状態。 |
| **型1.2** | フル機能
（非パーソナル＋パーソナル） | **自治体(C1)** が双方を提供 | 基礎自治体が自前で1つの個人認証サービスと両基盤を運営し、閉じた環境で提供している状態。 |
| **型1.3** | フル機能
（非パーソナル＋パーソナル） | 基盤：**自治体**
サービス：**自治体と民間が混在** | 基盤自体は自治体が提供しているが、その上で動くサービスには民間企業も参入している状態。 |
| **型1.4** | 機能限定
（**非パーソナルのみ**） | **自治体(C1)** が双方を提供 | 天気や交通量などのオープンなデータ基盤のみを1つ運営。個人認証やパーソナル基盤は「なし」。 |
| **型1.5** | 機能限定
（**パーソナルのみ**） | **自治体(C1)** が双方を提供 | 住民手続きや医療など個人に紐づく基盤と個人認証（各1つ）を運営。非パーソナル基盤は「なし」。 |
**【共同利用後の型】目指すべきパターン（型2.1〜2.8）**
共同利用に移行した後の状態を分類したものです。「サービスの提供主体」「利用者の範囲」「元々の基盤の数や個人認証レベルの統合度」によって8パターンに分かれます。
第1.0版から、共同利用の検討に当たっては、都道府県下の基盤を単一の共同利用基盤として集約し、官民混在サービスを広域展開する【型2.4】を、共同利用の目標として位置付けています。
また、検討結果によって無理な共同利用が弊害を生む場合については、基盤間をつなぐなどの複数基盤の活用が考えられます。
>💡 後の型を見分ける「3つのチェックポイント」
>1. サービスの提供主体は？ ➔「自治体のみ」か、「自治体と民間が混在」か
>2. 利用者の範囲は？ ➔単独自治体内に閉じるか、都道府県内の他の自治体に広げるか
>3. 元になった基盤の数は？ ➔「単一（1つの基盤を後からシェア）」か、「複数（別々の基盤を1つに統合）」か
**型2.xの比較表**
| 分類 | 元の基盤数 | サービス提供スキーム | サービス利用者の範囲 | 個人認証整合 | 主な狙い |
| --- | --- | --- | --- | --- | --- |
| 型2.1 | 単一 | 自治体 | 自治体内 | 原則不要 | 既存基盤を共同運営に移管し、個別自治体向けに継続利用する |
| 型2.2 | 単一 | 自治体 | 都道府県内 | 必要に応じて整合 | 既存サービスを広域に展開する |
| 型2.3 | 単一 | 自治体＋民間 | 自治体内 | 原則不要 | 民間サービスを含めて個別自治体内で利用する |
| 型2.4 | 単一 | 自治体＋民間 | 都道府県内 | 必要に応じて整合 | 単一基盤上で民間サービスを含めて広域展開する**共同利用の目標** |
| 型2.5 | 複数 | 自治体 | 自治体内 | 整合なし | 複数基盤を共同運営下で管理するが、利用範囲は各自治体内にとどめる |
| 型2.6 | 複数 | 自治体 | 都道府県内 | 整合あり | 複数基盤を統合し、自治体主導サービスを広域展開する |
| 型2.7 | 複数 | 自治体＋民間 | 自治体内 | 整合なし | 官民混在サービスを含め、拠点ごとの利用を維持する |
| 型2.8 | 複数 | 自治体＋民間 | 都道府県内 | 整合あり | 認証連携とデータ連携を両立する複数基盤系の高度統合形。将来的な基盤統合による型2.4への収斂を視野に入れる |
### 7.2. 目標（型2.4）への2つの経路
型2.1〜2.8は並列の選択肢ではなく、地域の現状に応じた**2つの発展経路**として捉えられます。単一基盤から出発する地域は理想経路をそのまま進み、複数基盤が既に稼働している地域は現実経路（統合・整合）を経て、いずれも最終的に単一基盤上の官民混在・広域サービス（型2.4）へ収斂していきます。
**パートA：【単一の基盤】をみんなでシェアする形（型2.1〜2.4）**
1つの自治体（C1）が使っていた基盤を共通基盤とし、後から他の自治体（C2、C3）が相乗りしていくパターンです。
* **サービス利用範囲：自治体内にとどまる**
* **型2.1：自治体主導サービス**
* 運営組織が基盤を提供し、基礎自治体（C1）が住民ポータルや行政サービスを「自分の自治体内向け」に提供します。
* **型2.3：官民混在サービス**
* 型2.1の構成に加え、サービスを届ける組織に民間企業も混在している状態です。利用範囲は変わらず「自分の自治体内」です。
* **サービス利用範囲：都道府県内へ拡大**
* **型2.2：自治体主導・広域サービス**
* C1が使っていた地域社会サービスを、後から参加したC2の住民も含めた「都道府県内全域」で広く利用可能にします。
* **型2.4：官民混在・広域サービス【目標】**
* 共同利用の目標です。運営組織の共通基盤（個人認証・非パーソナル・パーソナル各1つの単一構成）を使い、後からC2やC3が利用に加わります。C1で民間が提供していた医療サービスなどの利用範囲を「都道府県全域」へ一気に拡大します。
* 単一基盤への集約により、基盤間の認証連携・データ連携の仕組みや複数基盤の重複維持コストが不要となるため、運営のシンプルさと財政面の持続可能性を最も高く両立できる姿です。
**パートB：【複数の基盤】を1つにまとめて共同運営する形（型2.5〜2.8）**
既に複数の自治体（C1、C2）がバラバラに運営していた基盤を、運営組織が「一元管理（統合）」し、後からC3などが合流する高度なパターンです。既に複数基盤が稼働している地域が現実的に選択する経路であり、ここでは「個人認証レベルのすり合わせ（整合）」が重要になります。
* **サービス利用範囲：自治体内にとどまる**
* **型2.5：自治体主導（個人認証レベル：整合なし）**
* C1とC2の基盤を1つにまとめ、C3が後から加わります。ただし、それぞれの身元確認や当人認証の厳しさ（個人認証レベル）はバラバラで、すり合わせ（整合）がされていない状態です。
* **型2.7：官民混在（個人認証レベル：整合なし）**
* 型2.5と同様に複数基盤を統合しますが、サービス提供に民間が混在します。こちらも個人認証レベルのすり合わせはされておらず、利用範囲は各自治体内に閉じます。
* **サービス利用範囲：都道府県内へ拡大**
* **型2.6：自治体主導・広域（個人認証レベル：整合あり）**
* C1とC2の基盤を統合し、C1の地域社会サービスを「都道府県全域」へ拡大します。安全に広域連携するため、お互いの個人認証レベルのズレを解消（整合）させています。
* **型2.8：官民混在・広域（個人認証レベル：整合あり・データ連携）**
* 複数基盤系における到達点です。統合した基盤の上で、民間が提供する高度な医療サービス（レベル3）等を都道府県全域に拡大します。C2の住民がC1のサービスを安全に利用できるよう、基盤間で強固な「認証連携」と「データ連携」を両立させています。
* ただし、複数基盤を維持し続ける限り、連携の仕組みの運用負荷や重複コストは残ります。そのため、将来的には基盤の統合による単一基盤化（型2.4への収斂）を視野に入れます。
> 💡 **型の選定に当たっての留意点**
> 全ての地域が直ちに型2.4を目指せるわけではありません。域内に基盤がない地域は型2.1等から段階的に、複数基盤が乱立している地域は無理な統合が弊害を生んでしまう場合は型2.6/2.8（基盤間連携）を経由するなど、現状に応じた現実的な到達型を選定したうえで、長期的な目標として型2.4への収斂を見据えることが重要です。具体的な検討プロセスと移行パターンは8章を参照してください。
🔖詳細については[Appendix](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/84c08375-e8c4-440f-8ef4-521a4a36ed9f/e9c28525/20260904_policies_digital-garden-city-nation_guideline-of-area-data-coordination-platform_appendix.pdf) P.31「共同利用前後の型整理」をご確認ください。
▲[目次に戻る](#00)
## 8. 共同利用に向けた検討プロセス
### 8.1. バックキャストによる「5つのステップ」
エリアデータ連携基盤の導入や共同利用を検討するに当たっては、現在からの延長線上で考えるのではなく、まず地域の「目指す姿（Vision）」をゴールとして定め、そこから逆算して、何をすべきかを導き出す**バックキャスト（逆算）思考**での検討が必要です。
> 💡 **検討の進め方における注意点**
> ビジョンやアウトカム（期待される成果）の策定には、行政単独ではなく民間の事業者や地域住民などの関係者を交え、継続的に協議・共有しながら納得感を持って進める必要があります。
> また、STEP 3〜5の事業・サービス・要件の検討は、一方通行の順序に囚われる必要はありません。現場の実情に合わせて「行きつ戻りつ」しながら、具体的な要素へと細かく分解していくプロセスが不可欠です。
> さらに、検討時に課題を軸に検討すると、「課題」という言葉は非常に多義的であり、文脈によって解釈のブレが生じる可能性があります。また「現状の不満や不足」にのみ焦点が当たりやすく、マイナスをゼロに戻すという対症療法的な改善に偏重しやすくなります。そのため、「ニーズ」すなわち「理想のゴール」に焦点をあてて検討することで、未来志向の問いが生まれるため、期待や効果、変化の洗い出しが行いやすくなります。
### 8.2. 移行パターン別の重要な取組事項
共同利用前の現状（型1.x）から、目指すべき共同利用後の姿（型2.x）へ安全にシステムを移行させるための、事業・制度面および技術面における具体的な取組事項です。
**移行パターンと到達型の対応**
| 移行パターン | 現状 | 主な到達型 | 重点論点 |
| --- | --- | --- | --- |
| パターンA: 新規構築 | 域内に基盤がない | 型2.1、将来的に型2.2/2.4 | サービス企画、共同運営組織、費用負担、規約整備 |
| パターンB: 広域展開 | 単一市区町村基盤がある | 型2.2、型2.4 | 利用範囲拡大、参加自治体の認可制御、規約共通化 |
| パターンC: 複数基盤の高度統合 | 複数基盤が存在 | 型2.6、型2.8| ID突合、認証レベル整合、マルチテナント、データ分離 |
| パターンD: 広域基盤への統合 | 市区町村基盤から都道府県基盤へ参加 | 型2.4、型2.8 | 既存資産の移行、個人IDマッピング、責任分界 |
**📌 都道府県下の状況に応じた「型の選定指針」**
* 域内にエリアデータ連携基盤を運営している自治体が【ない】**場合 ➔ 基盤をゼロから立ち上げる**「パターンA」
* 域内にエリアデータ連携基盤を運営している自治体が【1つだけある】**場合 ➔ その資産を広域へ広げる**「パターンB」「パターンD」
* 域内にエリアデータ連携基盤が【複数乱立している】**場合 ➔ 無理に1つに統合して破綻させるのを避け、お互いのシステムを安全なハブで結ぶ**「パターンC」
いずれのパターンも、長期的には単一の共同利用基盤上で官民混在サービスを広域展開する **型2.4** への収斂を見据えて検討を進めます。
**🟩 パターンA：基盤ナシのパターン（新規構築）**
* **対象：** 【型 1.1】（基盤運営自治体なし）/【型 1.2】（単一市区町村基盤） ➔ 【型 2.1】（共同運営組織による新設・個別利用）への移行
| 検討領域 | 分類 | 必須となる取組事項（要取組） |
| --- | --- | --- |
| **魅力的なサービスづくり** | 事業・制度 | ・地域課題の緻密な分析と、課題解決手段となるサービスの企画・検討
・提供開始後のサービスの定期的な評価・見直しサイクルの確立
・住民が特定のサービスだけに縛られない（ロックインされない）ための工夫 |
| **共同利用する基盤の設計** | 技術 | ・基礎自治体（市区町村）に特化した固有サービスを提供できる仕組みの確保
・個人データを扱う層（パーソナルデータ管理層）を、サービス提供組織単位で確実に論理分離すること |
| **責任範囲の明確化とコスト負担** | 事業・制度 | ・「サービスの提供責任」と「基盤の運営責任」を負う組織・境界の明確化
・基盤の年間維持コストについて、参加自治体間での公平な負担割合の決定
・ 民間等からも広く回収するための利用料徴収の仕組みづくり |
| **住民の理解・セキュリティ** | 事業・制度 | ・基盤に参加するサービス提供組織の厳格な審査・認定要件の策定
・データの流通状況が適正かを外部からチェックする監査ルールの確立 |
|**住民の理解・セキュリティ**| 技術 | ・パーソナルデータの連携に対する同意状態を、サービス単位できめ細かく管理・制御する手段の提供
・各サービスが求める最も高い身元確認・当人認証レベル（例：マイナンバーカード等）を自動で適用・判定する認証機能の実装 |
**🟨 パターンB：共同利用していない市区町村基盤ありのパターン（広域展開）**
* **対象：** 【型 1.2～1.5】（単一市区町村基盤） ➔ 【型 2.2】（都道府県内へ利用範囲を拡大）への移行
既に1つの市区町村が自前で基盤とサービス（住民向け地域社会サービス等）を動かしている状態から、その基盤を「共同運営組織」へ移管し、周辺の市区町村（C2など）へと利用者を広げていくパターンです。起点となるサービスが存在するため、サービスづくりは大枠の「見直し」が中心となり、「利用者を広げたときのエコシステム設計」に注力します。さらに民間サービスの参画を進めることで、目標ある【型 2.4】へと発展していきます。
| 検討領域 | 分類 | 必須となる取組事項（要取組） |
| --- | --- | --- |
| **魅力的なサービスづくり** | 事業・制度 | ・既存サービスがあるため、事業・制度の新規構築は「必要に応じ見直し」で可。 |
| **共同利用する基盤の設計** | 技術 | ・サービス利用者の範囲を「都道府県下」全域に拡大するためのシステム拡張
・新旧の参加組織が混在するため、パーソナルデータ管理層をサービス提供組織単位で強固に部屋分け（分離）すること |
| **責任範囲・コスト・住民の理解** | 共通 | ・新しく相乗りする自治体（C2等）との間での、維持コストの再割り勘（負担割合）の契約締結
・自治体をまたいだ広域利用となるため、住民向け利用規約の都道府県レベルでの共通化・改定 |
| **責任範囲・コスト・住民の理解**| 技術 | ・異なる市区町村の住民が同じサービスにアクセスする際、システム側で安全にユーザー属性（所属自治体など）を判別する認可機能の追加 |
**🟥 パターンC：市区町村間で共同利用している基盤ありのパターン（複数基盤の高度統合）**
* **対象：** 【型 1.2～1.5】＋【型 1.2～1.5】（別々に動く複数基盤） ➔ 【型 2.8】（官民混在・広域・データ＆認証連携の高度連携形）への移行
**複数基盤の統合を伴う、最も難易度が高いパターンです。** 既に別々の市区町村や地域で個別に動いていた複数のフル機能基盤を「共同運営組織」のガバナンス下で1つにまとめ、さらに民間提供の高度なサービス（医療、決済など）を都道府県全域に拡大します。なお、型2.8は複数基盤を維持したままの到達点であり、基盤間連携の運用負荷と重複コストが残るため、将来的には基盤の統合による単一基盤化（目標である型2.4への収斂）を視野に入れます。
| 検討領域 | 分類 | 必須となる取組事項（要取組） |
| --- | --- | --- |
| **魅力的なサービスづくり** | 事業・制度 | ・既存サービスがあるため、事業・制度の新規構築は「必要に応じ見直し」で可。 |
| **共同利用する基盤の設計** | 技術 | ・住民情報（パーソナル）だけでなく、気象や交通センサーなどの **「非パーソナルデータ管理層」についても、サービス提供組織・地域ごとに安全に部屋分け（分離）して管理できるマルチテナント構造**を構築すること |
| **責任範囲・コスト・住民の理解** | 共通 | ➔ パターンA〜Cの全てのガバナンス項目・規約改定が「要取組」となります。 |
| **責任範囲・コスト・住民の理解** | 技術 | **【このパターン固有の最重要項目（認証・認可の完全整合）】**
・異なる基盤に登録されている個人IDをシステム間で正確に結びつける「個人IDの突合（マッピング）」の自動化
・サービス間やコンポーネント（システム部品）間でパーソナルデータを連携させる際、データ提供元と提供先の「身元確認レベル」および「当人認証レベル」のズレをシステムが自動で検知し、整合確認（レベルが満たない場合はアクセスを拒否する等）を行う認可処理（セキュリティチェック）を確実に実装すること。 |
**🟦 パターンD：都道府県基盤へ参加するパターン（広域基盤への合流）**
* **対象：** 【型 1.2～1.5】（単一市区町村基盤） ➔ 【型 2.4】（都道府県基盤をハブとした官民広域連携・**共同利用の目標**）への移行
既に基礎自治体によるサービス提供実績がある状態から、都道府県が用意した、あるいは広域で運営されている巨大な共通データハブへと合流・移行するパターンです。単一の共同利用基盤へ直接合流するため、目標である型2.4へ最短で到達できる経路となります。
| 検討領域 | 分類 | 必須となる取組事項（要取組） |
| --- | --- | --- |
| **魅力的なサービスづくり** | 事業・制度 | ・既存サービスがあるため、事業・制度の新規構築は「必要に応じ見直し」で可。 |
| **共同利用する基盤の設計** | 技術 | ・サービス利用者の範囲を「都道府県下」全域とする共通サービスの提供
・民間企業や多組織が交じるため、パーソナルデータ管理層をサービス提供組織単位で確実に分離すること |
| **責任範囲・コスト・住民の理解** | 共通 | ➔ 基本的には「パターンA（新規構築）」と同様のガバナンスルール・コスト負担の取り決めが要取組となります。|
|**責任範囲・コスト・住民の理解** | 技術 | **【このパターン固有の最重要項目】**
・各自治体のエリアデータ連携基盤間でパーソナルデータを安全にやり取り（融通）する際、それぞれの基盤が独自に発行した個人ID同士をシステム的に結びつける「個人IDの突合（名寄せ・マッピング）」の処理を確実に実装すること |
🔖詳細については[Appendix](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/84c08375-e8c4-440f-8ef4-521a4a36ed9f/e9c28525/20260904_policies_digital-garden-city-nation_guideline-of-area-data-coordination-platform_appendix.pdf) P.71「取組事項の整理」をご確認ください。
### 8.3. 事業の健全性を測る「成果指標（KPI）」の設定
**曖昧な目標が招く「エリアデータ連携基盤の形骸化」**
エリアデータ連携基盤を継続的に運用するための考え方や体制をどれほど立派に整えても、目指すべきゴールが曖昧なままでは、プロジェクトの持続や発展にはつながりません。
全国の様々な自治体のデジタル活動を俯瞰して見ると、エリアデータ連携基盤を導入したものの、何をもって「成功」とするかの基準が無いために、費用対効果を何年も示せず継続困難な状態に陥ることがあります。持続可能な事業運営には、目標達成度を客観的に測る「成果指標」の確立が絶対に必要です。運営組織内でしっかりと地域で目指す姿に対しての成果指標を設定し、合意のもと事業推進を行う必要があります。
**バックキャストから導く「2つの評価指標（ロジックモデル）」**
成果指標を設定する際は、「バックキャスト（逆算）思考」を用います。「まちをどう変えたいか」という未来のビジョンから逆算し、日々の活動をシステム的に測定できる **「アウトプット」** と **「アウトカム」** の2つの階層に落とし込んで管理します。
* **アウトプット指標（提供したモノ・量）：**
システムや行政側がどれだけ動いたかを示す数値です。（例：基盤に接続された総サービス数、データアセットの連携数など）
* **アウトカム指標（住民やまちの変化・質）：**
それによって住民の暮らしがどう豊かになったか、生活がどう向上したかを示す数値です。（例：サービス毎の月間アクティブ利用者数、サービス毎の住民満足度など）
**KPI例**
| 区分 | KPI例 | 見るべき意味 | 注意点 |
| --- | --- | --- | --- |
| アウトプット | 接続サービス数 | 基盤の利用面が広がっているか | 数だけでなく、実利用の有無も確認する |
| アウトプット | 連携データアセット数 | 利用可能なデータ資産が増えているか | 重複データや低品質データを含めない |
| アウトプット | API利用回数 | システム間連携が実際に発生しているか | バッチ処理等で数が過大にならないよう定義する |
| アウトカム | 月間アクティブ利用者数 | 住民・事業者が継続利用しているか | サービス別・属性別に分けて見る |
| アウトカム | 手続き時間の短縮 | 住民体験・行政効率が改善しているか | 導入前後の比較条件を揃える |
| アウトカム | 住民満足度 | Well-beingや利便性向上につながっているか | アンケート設計を固定し、経年比較できるようにする |
| アウトカム | 民間サービス・実証件数 | 官民共創が進んでいるか | 実証止まりではなく、本番化率も追う |
**成果の見える化による「データ駆動型PDCAサイクル」の確立**
これら「アウトプット」と「アウトカム」の目標値（ターゲット）とリアルな実績値を常にダッシュボードなどで意識・比較することが、客観的でブレのない「事業評価」へと直結します。
地域課題の解決度合いをデータで可視化し、エビデンス（根拠）に基づいて、施策を毎年アップデートしていく、官民協働のPDCAサイクルを確立することこそが、エリアデータ連携基盤を何年にもわたって健全に下支えする必須条件となります。
▲[目次に戻る](#00)
## 9. エリアデータ連携基盤の継続的な運用
### 9.1. 共同利用・データ利活用における「3つの主体」の役割分担
エリアデータ連携基盤の共同利用とデータ利活用を円滑に進めるためには、**「都道府県」「市区町村」「民間事業者」の3者が協力し、それぞれの強みを活かした役割を果たすこと**が必要です。
それぞれの主体が担うべき主な役割は、以下のように整理されます。
**① 都道府県：広域連携の「司令塔（コーディネーター）」**
市区町村や民間事業者を有機的につなぎ、都道府県全体の方向性をハンドリングして地域でのデータ利活用を強力に推進します。
* **全体方針（共同利用ビジョン）の策定：**
都道府県内だけでなく、必要に応じて他の都道府県との連携も見据えた、広域的な基盤の共同利用方針を定めます。
* **マッチングの場づくり：**
市町村間や事業者間の橋渡し（マッチング）を担い、新しいデジタルサービスが生まれる機会を積極的に創出します。
* **市区町村へのリソース支援：**
人材やノウハウなどのリソースが不足している市区町村に対し、人的・情報の両面から伴走型の支援を行います。
* **広域データ利活用の検討：**
複数の自治体をまたぐような、広域でのデータ利活用施策や、具体的な利活用方法の検討を主導します。
**② 市区町村：地域課題と向き合う「推進役（プレイヤー）」**
エリアデータ連携基盤をフルに活用し、目の前の地域課題を解決するためのデジタルサービス創出を主導します。
* **住民ニーズの的確な把握：**
最も住民に近い基礎自治体として、現場のニーズを捉え、都道府県や民間事業者と連携しながら、具体的な解決策を検討します。
* **ローカルなステークホルダーの巻き込み：**
地元の企業、NPO、地域住民などを積極的に巻き込み、地域のリアルな課題発掘とサービス創出の起点となります。
* **官民連携によるサービス設計：**
都道府県の支援を受けながら、民間事業者と二人三脚でデータ利活用および具体的なサービス開発を進めます。
**③ 民間事業者：技術をカタチにする「実装役（パートナー）」**
プロフェッショナルとしての技術的な知見やノウハウを基に、具体的なサービスを生み出し、エリアデータ連携基盤と接続して地域のスマート化を支えます。
* **最適なサービス設計への知見提供：**
最先端のIT技術を基に、その地域にとって本当に使いやすいサービス設計に向けて、市区町村と深く連携して検討を進めます。
* **円滑な導入と持続的な運用の支援：**
他地域での導入実績やビジネスのノウハウを活かし、市区町村へのスムーズなシステム導入と、サステナブル（継続的）なサービス運用をサポートします。
* **有用なデータ活用方法の提案：**
民間ならではのデータ分析ノウハウを基に、都道府県・市区町村と連携し、ただデータを蓄えるだけで終わらない効果的な活用方法を提案します。
### 9.2. まちづくり全体をデザインする「アーキテクト」の重要性
これら3つの主体（都道府県・市区町村・民間事業者）がバラバラに動くのを防ぎ、まちづくり全体のグランドデザイン（全体設計）を描きながら、最適なサービス創出やデータ利活用に関してプロの視点から助言・事業推進を行うのが「アーキテクト」という存在です。
**📌 アーキテクトが担う主な役割**
* **まちづくりのグランドデザイン（全体設計）：**
都道府県・市区町村・民間事業者のそれぞれの動きやニーズを踏まえ、特定のシステムに偏らない「まちづくり全体のビジョン」をデザインします。
> 💡 **ポイント**
> アーキテクトは行政の内側の人間ではなく、民間人材など、全てのステークホルダーを中立的な立場で巻き込みやすい独立したセクター（外部の専門組織や有識者など）が担うことが想定されます。
* **サービス間の関係性整理と助言：**
バラバラに立ち上がりそうな各サービスの関係性を綺麗に整理し、「まちづくり全体」の視点から、新規サービス創出に向けたアドバイスや推進体制の構築を行います。
* **最適なデータ利活用のエコシステム構築：**
他の先進団体や他地域の優れた取組をベンチマークしながら、自分たちの地域に最も適したデータ活用の実施に向けた技術的・組織的な助言を行い、持続可能な体制を作ります。
### 9.3. 目的と課題：エリアデータ連携基盤を「デジタルハコモノ」にしないために
エリアデータ連携基盤を巨額の予算で整備し、共同利用を開始したとしても、継続して運営（維持・発展）ができなければ、自治体にとっては、「毎年、ランニングコストが垂れ流しになるだけのハコモノ」と化してしまいます。
基盤を構築すること自体が目的なのではなく、あくまでも「地域におけるデータ利活用を進め、住民生活を豊かにするためのツール」であることを忘れてはなりません。
**【放置すると陥る「データ利活用の負のスパイラル」】**
>**📑 運営における4つの代表的課題**
>1. **タッチポイントの不足：** 接続サービスを増やし、住民や企業との接点をいかに確保するか。
>2. **データの孤立：** 既存サービスから生み出されるデータを、いかに分野横断で次の価値へつなげるか。
>3. **人材の枯渇：** サービスを次々と創出し、基盤を安定運用できるデジタル人材をどう確保・育成するか。
>4. **財政の持続性：** 毎年の基盤運営コストをいかに官民で負担し、あるいはビジネスとして回収（マネタイズ）するか。
これらの山積する課題をクリアするためには、基盤のシステム運用だけを見つめるのではなく、**「データ利活用を通じた地域課題の解決」、ひいては「自分たちのまちの未来像」から逆算して考えるアプローチ**が効果的です。(バックキャスト思考)
### 9.4. 継続的な組織運営を支える「3つのコア要素」
サステナブルな運営組織を確立するためには、「サービス創出の仕掛け」「柔軟な組織形態」「自立的な人材確保」の3つの要素を同時並行で検討・実行していく必要があります。
**サービス創出・既存サービス接続の仕掛け**
エリアデータ連携基盤の価値は「つながるデータの量とサービス数」で決まります。「新しいサービスを作る」「既存のシステムを基盤につなぐ」「データの利活用を試す」の3つを、現状に合わせて着手しやすいところから並行してすすめていくため、以下のような取組を参考にしてください。
* **官民協働によるサービス創出の具体策・事例**
* **ステークホルダーとの常設の議論（コンソーシアムの結成）：**
行政・民間企業・地域住民が定期的に地域課題を議論し、机上の空論で終わらせず実際の政策形成やサービス開発へ直結させます。
* **行政課題の提示と民間からの解決策公募（コンペティション）：**
行政が困っている課題を開示し、民間企業からデータを使った解決アイデアを募る手法です。
* *事例（静岡県浜松市）：「Hamamatsu ORI-Project」* … 市の地域課題に対し、データを活用して解決を図るプロジェクトを民間から公募。
* *事例（大阪府）：「OSAKAイノベーションデータラボ」* … 府のデータプラットフォーム「ODPO」のデータ等を活用した課題解決ユースケースを広く公募。
* **民間企業の実証実験の強力なバックアップ（テストベッド化）：**
地域の課題解決をテーマにした民間企業の実証実験を、行政がデータやフィールドの提供で支援します。企業側は、そのまちでの成功モデルを「他地域へ横展開」することで自社のビジネスにできるため、民間からの自発的な投資を呼び込むことができます。
**運営組織形態の選択**
「誰が基盤を動かすのか」という組織のカタチは、事業の継続性や将来の拡張性を左右する極めて重要な決断です。
* **多様な組織の選択肢：**
都道府県が直接運営する形、官民共同の株式会社、機動性の高い一般社団法人など、地域の特性に合わせた最適な組織体制を選択します。
9.7.サステナブルな３つの運営組織の事例で具体的に紹介していますので、ご参照ください。
**人材確保と「中核キーマン」を中心としたチーム作り**
デジタル人材の確保には、外部からの「登用（連れてくる）」と、内部での「育成（育てる）」の2つのルートを適切に組み合わせます。
* **外部人材・制度の有効活用：**
「地域情報化アドバイザー」といった外部専門家を招き入れ、プロの知識や経験を現場に注入します。単に作業を丸投げするのではなく、そのノウハウを地域に蓄積し、地元の職員の「人材育成」に活用します。
* **「キーマン」の存在とチームビルディング：**
先進的なデータ連携で全国のモデルとなっている地域には、いずれも全体の強力な推進力となる「中核のキーマン」が存在し、さらにそのキーマンを孤立させずに組織の壁を越えて支える「多才なチーム作り」が行われています。
### 9.5. 3つのコスト負担・役割スキームの事例
自治体がエリアデータ連携基盤を広域で安定的かつ迅速に普及させるためには、都道府県と市区町村の間における導入・維持管理費用の分担ルールが重要なポイントとなります。実際の導入実態からは、取り扱うデータの性質（非パーソナルかパーソナルか）や自治体の財政規模に基づき、大きく3つのパターンに分類されます。
| コスト負担スキーム | 事例 | スキームの特徴 | 展開されるサービスの特徴 |
| --- | --- | --- | --- |
|**都道府県先行負担型**|**栃木県** |基盤の初期構築から、毎年の運用保守にかかる費用を含め、先行して県が負担。市町のニーズに応じたサービス追加や基盤の直接利用が生じた際には、予め定めた負担金ルールが適用される。| 次世代GIS、空き家対策総合プラットフォーム等。防災データ（リアルタイム雨量・河川水位、道路ライブカメラ画像データ等）を地図上に重ね合わせて展開。 |
| **都道府県・市町村共同負担型**|**福島県** |県が構築するエリアデータ連携基盤の運用保守費用に対し、県が2分の1を負担し、残り2分の1を利用する市町村が負担金として分担して支払う。また市町村は、利用したいサービスに対し、応分の負担金を支払う。| オンライン行政手続き、防災アプリ、健康アプリ、ポイントサービス等、生活直結分野のサービスパッケージ。|
| **協調・競争領域別負担型**|**鳥取県** |協調領域であるエリアデータ連携基盤やキャッシュレス基盤を県が整備し、エリアデータ連携基盤の運用保守は県が負担する。また、競争領域である個々のアプリやフロントサービスの費用は市町村等が自己負担する。| 県は「データ連携の土台（ハブ）」となる「エリアデータ連携基盤」を市町村等に提供。市町村等は、エリアデータ連携基盤を活用した住民サービスを自由に選定。|
**①都道府県先行負担（事例：栃木県）**
県が、インフラとなるエリアデータ連携基盤の構築経費を先行して全額負担し、管内市町の財政負担を抑えながら基盤整備とサービス展開を主導するコスト負担スキームです。単なる県の全額負担ではなく、市町が基盤を共同利用する際の運用保守経費について、負担金等の費用負担ルールを予め確立しておき、市町のニーズが顕在化した段階で応分負担へ移行する二段階の設計である点に特徴があります。
栃木県では、2026年3月にエリアデータ連携基盤の運用を開始しました。県が構築した「とちぎまるっとマップ（次世代GIS）」と「とちぎ空き家サイト（空き家対策総合プラットフォーム）」を基盤と一体的に運用し、県内全25市町のデータを集約・一元化した上で、防災・インフラ・空き家情報を県サービスとして実装しています。
本スキームの最大のメリットは、各市町が個別に基盤をスクラッチ構築する重複投資を回避しつつ、市町の財政状況やIT専門人材の有無にかかわらず、信頼性の高い広域防災・空き家対策の仕組みを迅速に普及できる点にあります。
**②県・市町村共同負担（事例：福島県）**
エリアデータ連携基盤の構築費用は県が負担し、運用保守費用のうち、県が2分の1を負担し、残り2分の1をサービスを導入・利用する市町村が負担金として分担して支払うコスト負担スキームです。また、市町村は利用したいサービスを選択できるようになっており、利用するサービスに応じた負担金を支払うこととなっています。
福島県は2024年3月にエリアデータ連携基盤を構築し、2025年度より市町村負担金による本格的な共同利用運用へ移行しています。
本モデルの最大の特徴は、オンライン行政手続き、防災アプリ、健康アプリ、ポイントサービスなど、住民生活に直結するパーソナルな複数分野のサービスを最初から共通のパッケージとして市町村へ一括展開する点にあります。市町村が独自でシステムを個別構築する場合、それぞれ数千万円の初期構築費用が発生しますが、県が一括調達・分配し、費用を案分することで、自治体個別の財政調達コストを抑制することができています。
**③協調・競争領域別負担（事例：鳥取県）**
「協調領域」と「競争領域」の定義を最も忠実に再現した、論理的かつ合理的なコスト負担スキームです。
鳥取県が県内市町村と協議の上、2025年3月に策定した「鳥取県データ連携基盤共同利用ビジョン」において、県内自治体がエリアデータ連携基盤、キャッシュレス基盤の必要性が生じた場合は、原則として鳥取県が提供する共同利用システムを利用することと規定されています。
この共同利用ビジョンに基づき、「協調領域」であるエリアデータ連携基盤の整備・運用費用は「県が全額を負担」します。また、キャッシュレス基盤については、地域通貨や地域クーポン、地域ポイントなどの行政サービスを共同利用できるプラットフォームとして鳥取県が選定し、市町村等に提供しています（キャッシュレス基盤は利用する市町村等の負担（サービス利用型）） 。一方で、これらの基盤を活用した住民向けの具体的なアプリケーションや、住民の購買履歴等のパーソナルデータ（購入・利用履歴など）を利活用して各地域で展開する個別サービスについては、各市町村等が負担し、自律的にサービスを選定・提供します。これにより、自治体間における重複投資の最小化と各市町村等の地域課題に適合した行政サービス選択の自由が高度に両立されています。
### 9.6. サステナブルな3つの運営組織の事例
エリアデータ連携基盤を一過性の実証プロジェクトで終わらせず、中長期にわたってアップデートし、活用を推進し続けるためには、地域の特性に最適化された運営組織の選択と、住民・民間企業を巻き込むデータ利活用の仕掛けが必要となります。
| 運営組織モデル | 事例 | 主な運営主体・推進体制 | データ利活用を活性化する具体的な仕掛け | 拡張性と将来の方向性 |
| --- | --- | --- | --- | --- |
| **都道府県主導**：順次使用許諾型（直列型） | 鳥取県 | 県デジタル局| 地域DXを推進する3つの会議体を設置。
①「鳥取県地域DX推進会議」：県及び県内全ての市町村が連携し、自治体の枠を越えた自治体連携による高度な地域DXを協議。
②「鳥取県自治体ICT共同化推進協議会」：県及び県内全ての市町村等が連携し、情報システムの標準化、共同化などを推進。
③「鳥取県デジタルイノベーションセンター」：県及び県内全ての市町村、全ての大学、全ての商工団体が連携し、データ連携基盤を核としたデジタルイノベーションの地域実装など4つのプロジェクトを協議。| 県内で生み出される官民データの県内流通、データの高度利用を推進。 |
| **コンソーシアム**：外部組織型 | 福島県会津若松市 | 一般社団法人「AiCTコンソーシアム」、会津大学、民間事業者、市部局。 | 13分野の専門ワーキンググループを設置し、市民参画プラットフォーム等と連動してスマートシティのダッシュボード化を推進。 | 会津若松市の取組が展開され、福島県が構築する全県エリアデータ連携基盤や周辺町村（矢吹町、石川町等）とのID・サービス接続へ拡張。 |
| **民間企業主導**：外部組織型 | 群馬県前橋市 | めぶくグラウンド株式会社（前橋市と民間事業者の共同出資）。 | マイナンバーカードをトラストアンカーとし、自己主権に基づく「ダイナミックオプトイン方式」を用いて安全にパーソナルデータを連携。 | 定額制のサービス形態をとり、北海道江別市や長崎県大村市、大阪府門真市などへシームレスに横展開。 |
**①都道府県主導（事例：鳥取県）**
広域自治体である県が強力なリーダーシップを発揮し、行政責任のもとで一元的に共通のエリアデータ連携基盤等を整備し、県内の地域DXを先導するモデルです。
県は、共通基盤として「エリアデータ連携基盤（非パーソナル・パーソナル）」を整備、運営しています。さらに、エリアデータ連携基盤と連携する「キャッシュレス基盤」、「自治体ポータルアプリ」を整備、運営しています。その他、県と多くの市町村が連携し「地理空間情報（GIS）基盤」を整備し、エリアデータ連携基盤と連携させるなど、データ流通するためのコンテンツ（アセット）充実を図っています。
推進体制として、いつまでも安心して暮らすことの出来る地域社会の実現を目指し、これらの基盤等を活用しながら地域DXを推進する３つの会議体を設置しています。
「鳥取県地域DX推進会議」では、県と県内全市町村で構成し、部局を越えた議論となることから市町村からは副首長等が参加し、団体の枠を越えた自治体連携による高度な地域DXを協議しています。「鳥取県自治体ICT共同化推進協議会」では、県と県内全市町村等で構成し、情報システムの標準化、共同化などを推進しています。「鳥取県デジタルイノベーションセンター」では、県デジタル局長をセンター長として、県、県内市町村、県内大学、商工団体が連携し、データ連携基盤をコアテクノロジーとした４つのプロジェクト（①デジタルイノベーションの地域実装、②地域データの高度解析、③イノベーション人材育成、④県内産業の活性化）を協議しています。
これらの会議体は、県デジタル局主導のもと運営しています。各会議体は相互に連携しながら一体となった取組みを推進しています。
**②コンソーシアム（事例：福島県会津若松市）**
一般社団法人等がプラットフォームの運営主体として機能し、行政、大学、国内外の事業者、地元企業、及び市民を対等に巻き込む官民共創エコシステムのモデルです。
会津若松市では、一般社団法人「AiCTコンソーシアム」が運営の中核を担っています。分野ごとにシステムを縦割りに導入する従来の行政調達ではなく、大学、コンソーシアム、市による基本協定により産学官連携の枠組みを形成しつつ（共助モデル）、コンソーシアム主導でエリアデータ連携基盤の運用や連携データ・サービスの調整をしています。
データ利活用の仕掛けとして、コンソーシアム内に「ヘルスケア」「防災」「教育」「食・農業」「決済」「行政」「モビリティ」など13分野に及ぶ専門ワーキンググループを設置し、市の担当部局と民間事業者が定常的に議論を重ねる体制があるため、データの流通速度が極めて早く、高度なデータ利活用の具現化に寄与しています。
**③民間企業主導（事例：群馬県前橋市）**
自治体と民間の出資によって「株式会社（官民共創会社）」を立ち上げ、民間の俊敏性、及び迅速な意思決定力を最大限に活かしながら、ガバナンス体制を強化したモデルです。
前橋市では、市と複数の事業者等の出資によって設立された「めぶくグラウンド株式会社」が基盤の運営とビジネス展開を牽引しています。民間企業のガバナンスを活かすことで、先行投資を伴う先駆的な技術開発や他自治体への迅速なシステム提供を可能にしています。
データ利活用の仕掛けとして、マイナンバーカードをトラストアンカーとして発行された秘密鍵・電子証明書を「めぶくID」として利用することにより、利用者が自らの意志でデータ提供先をコントロールできる「ダイナミックオプトイン方式」を採用している。これにより、利用者のプライバシー保護と権利保証を最優先しながら、個人属性に応じたパーソナライズされたサービスを安全に創出しています。この優れた基盤モデルは、県境を超えて横展開されています。
🔖詳細については[Appendix](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/84c08375-e8c4-440f-8ef4-521a4a36ed9f/e9c28525/20260904_policies_digital-garden-city-nation_guideline-of-area-data-coordination-platform_appendix.pdf) P.94「運営組織の整理」をご確認ください。
▲[目次に戻る](#00)
## 10. エリアデータ連携基盤における相互運用性
### 10.1. 相互運用性（インターオペラビリティ）とは何か
前章では、エリアデータ連携基盤を継続的に運営するための体制や役割分担について解説しています。共同利用が進み、自治体や民間事業者の参加が拡大すると、接続するサービスやデータの種類も増加していきます。そのため、持続的なデータ利活用や広域連携を実現するには、組織面でのガバナンスに加え、異なるシステム同士が円滑に連携できる「相互運用性（インターオペラビリティ）」を確保することが重要となります。
エリアデータ連携基盤は、防災、交通、観光、医療などの分野を越えてデータを相互に活用することを目的としています。しかし、共通のルールがないままシステムが乱立すると、参加組織の増加に伴い接続や運用に必要なコストが増大し、データ利活用の拡大を阻害する要因となります。
エリアデータ連携基盤における相互運用性とは、異なるシステム同士が個別の改修や特別な変換処理を最小限に抑えながら、円滑にデータをやり取りできる状態を指します。
**相互運用性を確保する3つの層**
相互運用性は、APIや通信方式を合わせるだけでは成立しません。データ項目の意味や単位を揃えること、さらに利用規約・責任分界・本人同意・監査ルールを組織間で揃えることによって、はじめて広域で安全にデータを流通できます。
**デジタル庁の方針・準拠するガイドライン**
デジタル庁は、以下のガイドライン及び推奨仕様において、エリアデータ連携基盤の接続ルール（標準化）を定めています。
1. **スマートシティ リファレンス アーキテクチャへの準拠：**
データ接続や都市のデジタル化に必要なコア機能（認証・認可、API仲介、コンテキスト管理など）の設計思想を共通化し、インターフェースを標準仕様とすることを強く求めています。
2. **推奨モジュールの選定：**
デジタル庁では、3.2.エリアデータ連携基盤の4つの管理層に示したとおり、APIゲートウェイとデータブローカーを推奨モジュールとして提供しています。実証済みのOSSや、汎用的なパッケージをビルディングブロック方式として組み合わせる構成を推奨しています。これは、特定のIT事業者にシステムが依存し、将来的なコストが高止まりする「ベンダーロックイン」を徹底的に回避します。現在は非パーソナルブローカーについては、FIWARE OrionのNGSI V2を推奨としていますが、昨今ではNGSI-LD形式なども世界的には使われているため、柔軟に推奨モジュールなどの追加も検討していきます。
🔖詳細については[Appendix](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/84c08375-e8c4-440f-8ef4-521a4a36ed9f/e9c28525/20260904_policies_digital-garden-city-nation_guideline-of-area-data-coordination-platform_appendix.pdf) P.114「FIWAREのNGSI規格」をご確認ください。
### 10.2. データモデルの共通化
APIの接続方法（言語）を揃えるだけでなく、送受信するデータそのものの項目名や型（単語）も共通の標準ルールとして統一する必要があります。データモデルが地域ごとにバラバラのまま乱立した場合、以下の2つの深刻な弊害が生じます。
* **弊害 ①：サービスアプリケーションの普及・横展開の阻害**
データモデルが異なることにより、他地域で成功した優れたサービス（防災アプリ等）を自地域へ導入する際、自治体ごとに高額な「カスタマイズ開発費（名寄せ改修）」が発生し、迅速な横展開が困難になります。
* **弊害 ②：地域をまたいだ広域データ相互運用性の破綻**
県単位でデータを集約して広域分析を行う際、あるいは隣接する自治体間で災害時の避難所データを相互融通する際に、システム間でのデータ結合が自動で行えなくなります。
### 10.3. デジタル庁による「エリアデータ活用のためのデータモデル」の公開
これらの弊害を排除し、高い次元での相互運用性を担保するため、デジタル庁ではエリアデータ連携基盤の活用において、利用頻度が高い主要な分野のデータについて、推奨する標準データモデルを示していきます。
* **設計思想：** 政府相互運用性フレームワーク（GIF）をベースとし、各府省庁が示している最新の標準定義（語彙集）を完全にリファレンス（参照）して定義を一本化します。
**標準データモデルが規定する「9つの定義項目（属性パラメータ）」**
デジタル庁が公開する標準データモデルは、ただデータの名前を決めるだけでなく、システム開発やデータ連携時の手戻りを防ぐため、以下の9つの属性パラメータ（ルール）に基づいて厳格に各データ項目（例：避難所、河川水位など）の仕様を定義しています。
基盤にデータを接続する事業者や自治体は、この定義に沿ってデータを準備・出力する必要があります。
1. **項目名**
データの意味を人間が直感的に理解するための、標準化された日本語の名称です。
2. **英字名**
エリアデータ連携基盤やAPI、プログラム内で実際に使用する、「システム変数名（コード）」です。
3. **入力例**
実際にシステム間でやり取りされるデータの具体的なイメージを記述したサンプル値です。
4. **型**
そのデータが「文字列」なのか「数字」なのか、あるいは予め決められた選択肢から選ぶ「文字列（選択）」なのかという、データの属性を定義します。
5. **項目必須**
システムの構造（スキーマ）として、その項目自体を必ず存在させなければならないか（必須／任意）を定義します。
6. **値必須**
項目が存在した上で、その中身（値）を空っぽ（空文字やNull）にすることを許すか、必ず具体的な値を入れなければならないか（必須／任意）を定義します。
7. **全半角**
日本の行政データや地域システムで最もトラブルになりやすい、テキストデータの「全角」と「半角」の指定ルールを明確にします。
8. **取り得る値**
データ型が選択式の場合に、システムが受け付けることができる具体的な選択肢のキーワード（許容値のリスト）を限定します。
9. **単位**
数値データ（収容人数、水位、面積など）を扱う際、システム間で解釈がズレないよう、「人」や「m（メートル）」といった標準的な計量単位を規定します。
**各分野で作成・公開される「標準データモデル」の一覧**
上記の9項目で定義されたデータモデルの最新スキーマ及び仕様書は、2026年9月から順次デジタル庁のGitHubからダウンロード・活用が可能となります。
🔗 [エリアデータ連携基盤における標準データモデル](https://github.com/digital-go-jp/area-data-coordination/tree/main/datamodels)
| 分野 | モデル |
|---|---|
| 🚨 防災 | 避難所、避難場所、一時滞在場所、避難指示等（発令履歴）、警戒区域（発令履歴）、固定系カメラ画像、河川水位及び危険度情報、ダム水位及び危険度情報、ため池水位及び危険度情報 |
| 🏛️ 行政サービス | 公共施設、人口統計・年齢別人口、消防水利施設 |
| 👥 住民サービス | ユーザー、地域ポイント・地域通貨、公衆無線LANアクセスポイント、公衆トイレ、空き家バンク、子育て支援施設 |
| 🗺️ 観光・地域活性化 | イベント、人流データ、観光施設、文化財 |
| 🏥 健康・医療 | AED設置場所、医療機関、介護サービス事業所 |
| 🚌 交通・モビリティ | 公共交通運行情報、乗降実績データ（鉄道、バス）、駐車場、駐輪場、シェアサイクルポート |
| 🏫 教育 | 学校 |
### 10.4. 相互運用性を保つために技術以外で必要なこと
エリアデータ連携基盤の相互運用性を名実ともに確保するためには、単にFIWARE等のツールを導入する技術的なアプローチにとどまらず、以下の3つのガバナンス（制度・組織）対策を自治体・県主導で強力に進めることが強く求められます。
1. **「意味論的相互運用性 (Semantic Interoperability)」の事前設計**
自治体、地域のサービス提供事業者、ベンダーの間で、予め標準データモデル（オントロジー・コンテキスト）の適用範囲を合意・契約化すること。これにより、人間が手作業で「名寄せ」のパッチを当てなくても、AIやシステム自体が自動でデータの意味を正しく解釈し、分野間で即座につなぎ合える環境を整えます。
2. **「制度的・組織的相互運用性 (Organizational Interoperability)」の整備**
官民や異なる行政分野をまたいでパーソナルデータや機微な情報をやり取りする際の、セキュリティ監査基準、プライバシー保護の枠組み（オプトイン／同意管理のルール）、及び共同利用に関わる「利用規約（責任分界点）の統一テンプレート」を予め準備し、ガバナンスの足並みを揃えること。
3. **「段階的な移行ロードマップ（ハイブリッド運用）」の策定**
既存の`NGSI v2`や独自APIで稼働しているサービス資産を一度に置き換えるのではなく、データ形式やAPI仕様の差異を吸収する変換コネクターを活用しながら、段階的に標準仕様へ移行するロードマップを策定すること。 移行期間中は新旧のハイブリッド運用を許容し、既存システムの継続利用と新規サービスの標準化を図ること。 また、新規に調達・導入するサービスについては、`NGSI-LD`及び標準データモデルの採用を推奨し、中長期的には地域全体の相互運用性向上と保守コスト削減を目指すこと。
▲[目次に戻る](#00)
## 11. データ利活用に向けて
デジタル技術を駆使したデータ利活用は、地域の持続可能性を高め、住民の満足度を最大化するための極めて重要なアプローチです。これまでのスマートシティ施策における課題は、特定の分野や個別事業にとどまる **「点での成功」** に終始しがちであった点にあります。今後は、複数の分野やシステムが密接に連携する **「面での成功（エリア全体としての成功）」** へと転換させることが求められています。
この「面での成功」を支えるデジタル公共財が、エリアデータ連携基盤です。エリアデータ連携基盤は、社会的に共有される **協調領域** に分類され、市区町村や事業者間での共有・共同利用を進めることで、開発・運用の重複投資や非効率な接続プロセスの発生を抑制できます。**協調領域** の活用によって得られた投資余力や蓄積されたビッグデータを、AI技術等も駆使した **競争領域** へ集中投資することで、より個別最適化された地域サービスの創出と、持続可能な地域エコシステムの構築が可能となります。
本章では、エリアデータ連携基盤を起点とした高度なデータ利活用を実現するための実践的アプローチとして、**「データマップの作成」** 及び **「オープンデータの戦略的推進」** の具体的な方法論と留意事項について解説します。
### 11.1. データマップ作成の目的・意義・効果
**データマップ作成の背景と目的**
エリアデータ連携基盤の導入や共同利用を進める初期段階において、自治体や地域内の事業者が「どのようなデータを保有し、それをどのように活用できるか」という現状を把握できていないケースが多く見られます。データマップは、データの所在、内容、属性、接続方法、更新頻度、連携状況等を体系的に整理・台帳化するための標準の枠組みです。
データマップを作成する主な目的は、サービス側（データの需要）とデータアセット側（データの供給）の両面からデータ項目を統一的に整理することにあります。これにより、行政の縦割り構造や事業者間の壁を越えた情報共有や比較検討の共通材料が提供され、エリアデータ連携基盤の共同利用が促進されることを期待します。また、データの接続方式やAPI仕様といった技術的条件を初期段階で明確化することは、将来的なデータ連携設計における信頼性の高い「基礎資料」としての役割を果たします。
**データマップ作成に伴う4つの意義と具体的効果**
データマップの導入によってもたらされる価値は、単なるデータの台帳整理にとどまらず、地域の意思決定や投資判断にまで影響を与えます。その意義と具体的効果は以下の通りです。
| | 意義 | 期待される具体的効果・付加価値 |
| --- | --- | --- |
| **1** | **可視化による全体像把握** | 地域や行政が保有する多種多様なデータアセットの種類、属性、所在、接続方法を一元的に把握し、活用可能なデータの把握、重複・非効率な連携の是正、行政内のEBPMの推進を支援します。|
| **2** | **分野横断的な連携促進** | 防災、観光、ヘルスケア、モビリティなど複数分野のデータの組合せを容易に発見し、これまでにない新規サービスの創出や複雑な社会課題解決への検討材料を提供します。 |
| **3** | **整備・投資判断の効率化** | 更新頻度や接続方式を把握することで、同一地域内や隣接自治体間での重複投資や非効率な個別での連携開発を回避し、限られたリソースの最適化を図ります。 |
| **4** | **戦略的な優先度付け** | 地域にとって社会的価値の高い重要なデータや、現在不足しているデータ領域を明確化し、API化、データ標準化、データクレンジング等の実施におけるロードマップの優先順位を合理的に設定します。 |
### 11.2. 2つの視点によるデータマップの構成
データマップを実効性のあるものとするためには、フロントの「サービス」の視点と、バックエンドの「データアセット」の視点の双方からマッピングを行うことが求められます。
* **サービス側データマップ**
サービス側データマップは、エリアデータ連携基盤を通じてサービスに提供されたデータのうち、利活用可能なデータが「他サービスへどのように広がるか」をマッピングするものです。
サービス内で完結するデータだけでなく、外部へ提供可能なデータを明確に定義することにより、サービスを起点とした新たな連携シナリオの創出を促す効果があります。
| 主な整理項目 | 記載すべき具体的な要件と内容 | 記入例（防災分野） |
| --- | --- | --- |
| **サービス名** | 具体的なサービス又はシステムの固有名詞。 |避難所混雑度通知アプリ|
| **取込データ** | サービス実現のために基盤から接続・利用するデータ。特に「サービス内利用データ」と「外部提供可能データ」を識別して整理します。 | 避難所情報、混雑度、水位情報、気象警報 |
| **取得データ：外部提供可能データ** | 提供サービスで取得しているデータの内、他のサービスで利用ができるデータを整理します。|アプリ利用状況、避難所閲覧数、通知開封率 |
| **提供先サービス** | 外部提供可能データが、別のどのようなサービスやシステムで利活用されるかの展開先。 |防災ダッシュボード、地域ポータル |
| **提供頻度** | データの送信・同期サイクル。|リアルタイム、または5分間隔 |
| **提供方式** | 外部とデータ連携を行うための具体的な技術仕様。 | REST API、Webhook |
* **データアセット側データマップ**
データアセット側データマップは、データの所管元から基盤を介して提供されるデータが、「複数のサービスへどのように広がるか」をマッピングするものです。
これにより、地域内の埋もれたデータ（オープンデータ、地理空間情報、センサーデータなど）が、どのサービスで活用されているかを見極め、データ価値の可視化を支援します。
| 主な整理項目 | 記載すべき具体的な要件と内容 | 記入例（防災分野） |
| --- | --- | --- |
| **データセット名** | データの具体的な名称。 |指定避難所一覧 |
| **データ所管元** | 該当データを管理・管轄している正式な部署・組織名。 | 防災危機管理課 |
| **データの所在** | データが生成・収集される大元の具体的なシステム名。 | 防災情報管理システム |
| **提供先サービス** | 該当データアセットが実際に活用・連携されている全てのサービスやシステムの一覧。 | 防災アプリ、観光アプリ、地域ポータル |
| **提供頻度** | データの更新サイクル。 | 日次、随時更新 |
| **提供方式** | データの取得や連携のための通信手段やプロトコル。 |CSV、REST API、NGSI-LD |
データマップのフォーマットファイルについては、GitHub上の[「template」](https://github.com/digital-go-jp/area-data-coordination/tree/main/template)フォルダで公開しています。
### 11.3. オープンデータへの取組
データ利活用の最初の一歩として、行政が自ら保有する情報を標準的な仕様で公開する「オープンデータ」の取組は、推進しやすい取組です。
>📕**官民データ活用推進基本法に基づく自治体におけるオープンデータの取組義務化等**
>2016年に施行された官民データ活用推進基本法第11条により、国及び地方公共団体は、保有する官民データについて、個人や法人の権利利益や安全保障等を害さない範囲において、国民がインターネットを通じて容易に利用できるよう、必要な措置を講ずることが「義務」付けられました。また、一般事業者に対しても、公益の増進に資するデータについては同様の措置を講じるよう「努力義務」が規定されています。
さらに、同法第9条の規定に基づき、各都道府県は「都道府県官民データ活用推進計画」を策定し、市区町村においては同計画の策定に努める（努力義務）とともに、オープンデータの取組を組織的に加速させることが求められています。
**オープンデータの定義と3要素**
データが「オープンデータ」として認められるためには、以下の3つの要件を満たすライセンス及び形式で公開されていなければなりません。
* **営利目的、非営利目的を問わず二次利用可能なルールが適用されたもの**:
営利目的・非営利目的を問わず、誰でも自由に加工、編集、再配布ができること。原則として「公共データ利用規約（第1.0版）」や「クリエイティブ・コモンズ・ライセンス」といった著作権を保持したまま自由な二次利用を事前許諾するルールを適用。
* **機械判読に適したもの**:
人間が目で読むためのPDF等の画像フォーマットではなく、コンピュータプログラムが自動的に解析・直接処理できる構造化形式（CSV、XML、JSON等）であること 。
* **無償で利用できること**:
誰もが費用負担なく自由にアクセスし、データの恩恵を享受できること。
**オープンデータの具体的な多目的利活用案（自治体標準オープンデータの組合せマトリクス）：**
基盤に集まった共通のオープンデータを、複数の異なる分野のアプリ（サービス）で「利活用」します。
| 提供するサービス分野 | 基盤から呼び出して活用するオープンデータ |
| --- | --- |
| **観光・まち歩き** | 観光施設一覧、観光ポイント、イベント一覧、文化財一覧、子育て施設一覧、公衆トイレ一覧、公営駐車場一覧、公営駐輪場一覧、公衆無線LANアクセスポイント一覧、食品等営業許可・届出一覧 |
| **子育て支援** | 子育て施設一覧、赤ちゃんの駅、学校給食献立情報、小中学校通学区域情報、教育機関一覧、公共施設一覧、イベント一覧、公衆トイレ一覧、公営駐車場一覧、公営駐輪場一覧 |
| **地域交通（MaaS）** | 標準的なバス情報フォーマット、観光施設一覧、文化財一覧、子育て施設一覧、公共施設一覧、イベント一覧、公営駐車場一覧、公営駐輪場一覧 |
| **健康・医療** | 医療機関一覧、介護サービス事業所一覧、AED設置箇所一覧 |
| **地域防災** | 指定緊急避難場所一覧、消防水利施設一覧、防災行政無線設置一覧、医療機関一覧、AED設置箇所一覧、公衆トイレ一覧、公衆無線LANアクセスポイント一覧 |
### 11.4. オープンデータの活用事例
本章では、公益財団法人九州先端科学技術研究所とTISI株式会社が行った、複数自治体による「共同利用型データ連携基盤（BODIK CityOS）」を用いた実証事業の成果が報告されていますので、その報告書から一部を抜粋し紹介します。
----
**「FIWARE共同利用による広域データ連携基盤実証実験」**
**背景と課題**
近年、自治体のオープンデータ取組率は90.4%に達したものの、「公開データの具体的な利活用事例の不足」「データモデル標準化の遅れ」、そして単独導入における 「コストの高騰」 が、広域連携を阻む深刻な課題となっていました。これらの課題に対し、コストを分散しつつ相互運用性を担保できる共同利用モデルの可能性を検証しました。
**プロジェクト1：公共施設情報の広域横断検索（福岡市、久留米市、静岡市、大分県）**
* **目的：**
自治体ごとに分断された施設予約システムを、既存システムを一切改修することなく横断的に検索可能とし、自治体の垣根を越えたシームレスな施設探索を実現できるかを検証すること。
* **実証内容：**
独自開発のデータ収集エンジン「BODIK ODGWR（リアルタイム版）」を導入し、設定ファイルベースで4自治体（福岡市、久留米市、静岡市、大分県）の施設予約データを自動収集。収集したデータは国際標準NGSI V2に準拠した「統一データモデル」に整え、自治体ごとに異なる予約状況の表現を9種類の統一ステータスへ正規化しました。さらに生成AI（LLM）を用いて21種類の活動種目を自動タグ付けし、正確な緯度経度を付与することで地図上へのマッピングを実現。Webビューア「FIWARE Facility Viewer」を通じて広域横断検索を提供しました。
* **結果：**
約3ヶ月の構築期間で、4自治体・213施設・未来30日分の約45万件以上の予約枠データの一元管理を達成。毎朝7時に自動収集を開始し、約24分で変換・統合・AI処理を経てFIWAREへのアップロードを完了する自動運用サイクルを確立しました。これまで自治体ごとに分断されていた動的データ（予約状況）が国際標準モデルで統合されたことにより、住民が自治体の枠を越えてシームレスに施設を探索できる「広域住民体験」を創出しました。また、既存システムに手を加えない手法（ベンダーフリー）によるデータ連携が可能であるため、将来的な参加自治体の拡大や、観光・防災など他分野のオープンデータ利活用へ容易に展開できるモデルを確立できた点も大きな成果です。
* **今後の課題と展望：**
社会実装に向けては、日次バッチから高頻度なリアルタイム同期への最適化、参加自治体増加時の負荷分散、及び相手先システムの仕様変更に柔軟に対応できる保守体制の構築が課題です。また久留米市からは、スポーツ施設等は隣接自治体からの利用者も多いことから、実際の生活圏を共にする「近隣自治体単位」での統合需要が高いとの指摘があり、生活圏に即した広域展開が今後の方向性となります。
**プロジェクト2：AIカメラによるリアルタイム混雑状況管理（久留米市）**
* **目的：**
AIカメラで取得したリアルタイムの混雑状況（動的データ）を基盤経由で住民へ可視化し、住民の「空振り」防止と職員の目視確認業務の自動化、さらに蓄積データによるEBPMへの活用可能性を検証することです。
* **実証内容：**
自習室にはRaspberry Pi 5とAIカメラを配置して1分ごとに人数をカウントし、駐車場にはJetson Orin Nanoを採用して車両のIN/OUTトラッキングから駐車台数を推定しました。映像データはエッジデバイス内で数値化直後に即座に削除する「Privacy by Design」を徹底し、個人を特定できない数値データのみをサーバーへ送信する安全な構成としています。
* **結果：**
リアルタイムの混雑度をWebアプリで公開し、住民の空振り防止と職員の目視確認業務の自動化を達成。久留米市からは「現場が楽になった」との具体的な成果が確認されています。さらに、蓄積された時系列データを用いた「カレンダー分析」により、土日祝日や金曜日の満車傾向、開館直後の午前中への利用集中といった利用特性をデータで裏付け、EBPMに資する政策判断の材料を提示しました。
* **今後の課題と展望：**
駐車場の満空情報自動検知は、将来的に警備員の配置最適化や人件費削減につながる可能性が示唆されています。エッジ側で数値化する低コスト・プライバシー保護型の構成は、他の公共施設や他自治体への横展開が容易であり、混雑緩和・施設運営効率化の標準的なユースケースとしての普及が期待されます。
**プロジェクト3：生成AIによるデータモデルの共通化「AIデータブリッジ」（2県、1市、BODIK）**
* **目的：**
複数団体の基盤に分散するデータを手動で突合することなく、生成AI（LLM）とMCPを活用して自動的にモデルの差異を吸収する「AIデータブリッジ」の実現可能性と、それによるデータ統合の準備コスト削減効果を検証すること。
* **実証内容：**
①複数基盤（2県、1市、BODIK）からのデータ構造情報の収集、②生成AIによる共通項目の解析と「共通データモデル」の自動生成、③各自治体モデルとの差異を埋める「結合変換辞書」の自動作成、の3ステップで実施。生成AIの活用を「準備段階」に限定し、実際の検索時には事前生成した「結合変換辞書」による変換処理を行うことで、生成AIの推論コストや回答の不安定さを回避する実用的な設計としました。
* **結果：**
生成AIによって作成された共通データモデルを用いることで、異なる基盤にある人口データを同時に検索し、同一フォーマットで取得することに成功。また、公共施設データを地図上に一括表示できることを確認し、データ統合における設計・開発などの準備コストを削減できる道筋を示しました。
* **今後の課題と展望：**
基盤を新設せずとも既存基盤同士を生成AIによりつなぐ本方式は、基盤整備の予算確保が困難な団体を含めた広域連携の現実的な選択肢となり得ます。今後は対象データ分野の拡大と、辞書生成の精度・運用プロセスの確立を通じて、都道府県域を越えたデータ利活用への適用拡大が展望されます。
---
出典：[「FIWARE共同利用による広域データ連携基盤実証実験」](https://www.bodik.jp/research/field_trials_2025)
▲[目次に戻る](#00)
## 12. エリアデータ連携基盤の活用事例
エリアデータ連携基盤を活用するにあたり、パーソナルデータと非パーソナルデータの両方を活用することを考えています。
初めからフル機能を目指しても、決して間違いではありません。分かりやすい非パーソナデータの活用から始め、パーソナルデータの活用に拡張していく道筋もあります。また、ID連携からパーソナルデータを活用するサービスの提供から始め、非パーソナルデータの活用に拡張していく道筋もあります。
### 12.1. 非パーソナルデータの活用
**①非パーソナル（静的）データとGISでの地図表示**
* **取組内容：**
まずはパーソナルデータを含まず、更新頻度の低い「静的なオープンデータ」を最初のデータアセットとして基盤へ登録します。もともと担当部署ごとに紙の台帳や個別のExcelファイルで管理されていた地域の資産情報をデジタル化（構造化）し、GIS（地理空間情報システム）を使って地図上へ統合マッピングします。
* **解決できる地域課題：**
**防災情報の一元化**
各自治体のハザードマップ（土砂災害危険度、浸水想定区域など）を重ね合わせ、指定緊急避難場所や避難所、付近のAED設置箇所を一元的に可視化した「総合防災マップ」の提供。
**デジタルインフラ管理**
バラバラに管理されていた「道路台帳」「消防水利施設（消火栓・防火水槽など）の位置データ」「公共施設情報」をデジタル地図上で重ね合わせ、行政内の管理業務や市民への情報公開を効率化。
**空き家対策**
域内の空き家バンク情報や関連する災害リスクの情報を地図上で一元発信し、移住・定住促進と空き家対策を低コストで開始。
* **事例：**
**栃木県：次世代GIS及び空き家対策総合プラットフォームによる全25市町共同利用モデル**
* **概要：** 県内全25市町が連携し、県が保有する防災・インフラ情報や国のオープンデータを集約・可視化する「次世代GIS（とちぎまるっとマップ）」及び「空き家対策総合プラットフォーム（とちぎ空き家サイト）」を構築。
* **特徴：** これまで行政内で一覧表（Excel等）のまま管理・公開されていた各種インフラや地域資産のデータをデジタル地図上に重ね合わせ、河川水位や道路・河川ライブカメラ映像などと一体的に平時から確認できる環境を整備。さらに、25市町間でばらつきのあった空き家情報を一元的に集約し、地図上の周囲の住環境と合わせて可視化するなど、静的データのオープン化とサイロ化の解消を県・市町共同で実現しています。
**②リアルタイム（動的）データのつなぎ込み**
* **取組内容：**
STEP1の静的な地図情報の上に、IoTセンサーや外部システムから出力される「リアルタイム（動的）な非パーソナルデータ」を接続し、まちの「今の文脈（コンテキスト）」をエリアデータ連携基盤に流通させます。
* **解決できる地域課題・具体例：**
**スマートモビリティ（交通）**
コミュニティバスやオンデマンドタクシーにGPS端末を搭載し、運行状態や遅延状況を知らせる「バスロケーション情報（GTFS-JP規格等）」をリアルタイムに地図上へ表示。
**水防・減災（防災）**
街頭や中小河川、ため池等に低価格なIoT水位センサーや雨量計、定点観測用の固定カメラを設置。基盤経由で最新の気象・水位データを取り込み、水位が警戒ラインを超えた瞬間にアラートを発出する自動減災パトロール環境を構築。
**混雑緩和（環境・観光）**
公共駐車場の満空状況や、観光施設のリアルタイムな人流・混雑度データを基盤に集約し、混雑を避けた行動を促す環境を整備。
* **事例：
香川県高松市：センサーデータをリアルタイムに活用するエリアデータ連携基盤**
* **概要：** 行政が保有する各種台帳データ（インフラ台帳）を基軸とする地理空間データ連携基盤を「自治体版ベースレジストリ」としてエリアデータ連携基盤の中核に構築。この土台に、IoTセンサー等から得られるリアルタイムな防災・交通データを接続し、地域の状況を時間単位で可視化・活用できる動的なデータ連携の環境を実現。
* **特徴：** 基盤に集約された防災情報（河川・水路18地点の水位センサー、海岸部5地点の潮位センサー、アンダーパス18カ所の冠水センサー等）や駐車場の満空データを、時間単位で取得。これらのリアルタイムデータは、公開型GIS「高松スマートマップ」で一般に公開されるとともに、防災アプリ「たかまつマイセーフティマップ」や駐車場情報アプリ「どこ駐車ナビ高松」など複数のサービスで活用されています。
### 12.2. パーソナルデータの活用
**①複数サービスでの「共通ID」の活用**
* **取組内容：**
OIDC（OpenID Connect）を活用したID・属性連携のシステム設計に基づき、これまで住民向けにバラバラに提供されていた既存サービス（地域ポイントアプリ、健康ウォーキングアプリ、施設予約システムなど）を、OIDCを用いた「地域共通ID基盤」へと接続します。
* **実務上のポイント：**
まずは、住民が1つのID/パスワードで全てのアプリにシングルサインオン（SSO）できる環境を整えます。同時に、サービス側（アプリ側）の設定やインターフェースを見直し、基盤側のデータを各アプリ内へセキュアに取り込めるよう、システム的な接続（API連携）を完了させます。
* **事例：**
**福島県：会津若松市の知見を全県へ横展開する「オールふくしま共同利用モデル」**
* **概要：** 「オールふくしまスマートシティ推進事業」において、会津若松市がスマートシティの取組で培った複数都市でのデータ連携や共通IDに関する実績・知見をベースに、福島県が全県共通のエリアデータ連携基盤を整備。
* **特徴：** 総合窓口アプリ「ふくしまポータル」を起点として、行政手続オンライン申請や防災アプリ、ポイント管理アプリ等へシームレスに遷移するシステムを構築。公式文書での明記はないものの、実態として外部アカウントを用いたフェデレーションID連携によるシングルサインオン（SSO）が組み込まれており、県内全域での共同利用を見据えた環境を整備しています。
**②複数サービス間でのパーソナルデータの相互利活用**
* **取組内容：**
エリアデータ連携基盤を介して、あるアプリが持つパーソナルデータを、別の分野のアプリへと安全に橋渡し・連動させます。
* **ユースケース（具体例）：**
住民がスマートフォンの「検診予約システム」で病院の予約を確定させると、エリアデータ連携基盤がその予約日時・場所を検知。住民の事前同意（オプトイン）及び同意管理に基づき、その情報を「オンデマンドバスの配車予約システム」へ自動連携させます。これにより、住民が自分で操作しなくても、検診の時間に合わせた最適な往復バスの座席が自動的に予約されるといった、ライフステージや個人の状況に高度に最適化された先進サービスの提供が可能となります。
* **事例：**
**群馬県前橋市：「めぶくID」とダイナミックオプトインによるパーソナルデータ相互融通**
* **概要：** マイナンバーカードをトラストアンカーとするデジタルID「めぶくID」を活用し、行政サービス・地域通貨・コミュニティ・教育など複数サービス間でパーソナルデータを本人同意のもとで相互連携。
* **特徴：** 利用者自身がデータの提供先をいつでもオン・オフできる「ダイナミックオプトイン」機能を通じて同意管理を実施し、認可・解除の履歴はめぶくIDによる電子署名付きのエビデンスとして保管されます。実装例として、行政の審査結果と電子地域通貨「めぶくPay」を連携させた自治体給付金（子育て関連給付金等）のオンライン申請・給付や、興味・関心や活動エリアに応じてパーソナライズされた情報を受け取れるダッシュボード「グッドグロウまえばし」など、個人の状況に最適化された連携サービスを実装しました。
### 12.3. 非パーソナルデータとパーソナルデータの活用
* **取組内容：**
エリアデータ連携基盤を介して、パーソナルデータを活用したサービスと地図等を活用したサービスを複合的に提供します。
* **ユースケース（具体例）：
** 地図等を活用したサービスとパーソナルデータを活用したサービスの相乗効果により、より良い地域を作ることが可能となります。
* **事例：**
**北海道更別村：分野を横断したパーソナルデータ・非パーソナルデータ連携による生活支援サービス**
* **概要：** 「更別スーパービレッジ構想」のもと、健康・医療、交通・モビリティ、産業振興、農林水産、行政サービスの5分野を基軸に展開されており、ほとんどのデータアセットがAPI連携により、リアルタイムで提供されている。ウェアラブル端末等から取得されるパーソナルデータと、デマンド交通の運行情報や農業自動化サービス、それらを表現するGISなど非パーソナルデータが相互に補完し合い、複数分野にまたがる連携が実現している。これにより、地域住民の生活の質向上と地域経済の活性化を同時に推進するパーソナルデータと非パーソナルデータの分野横断型のデータ利活用モデルが形成されている。
* **特徴：** スマートメーターが検知する個人の電力使用データを、独居高齢者等を対象とした見守りサービス「あんしん見守り」（防災・防犯分野）に連携し、そこで得られた見守りデータをさらに「健康データ管理」「チャットコーチング」といった健康・医療分野のサービスへ提供するなど、防災・防犯分野から健康・医療分野へとまたがるパーソナルデータの連鎖的な活用を実現。あわせて、デマンド交通の位置情報を地図上に表示することで、「すいすい村内移動」に活用し交通サービスの利用者の向上を図っている。さらに、受診予約ができる「AIかんたん病院予約」で受診予約をした際に、「らくらくサービス移動」ともデータ連携していることから、受診予約から通院のための移動手段の確保までを一気通貫で支援する、健康・医療と交通・モビリティの分野横断的な連携を実現している。 また、地域ポイント「どんぐりスタンプ」の利用データもエリアデータ連携基盤に集約され、複数のパーソナル・非パーソナルサービスが分野を越えて活用されています。
その他のエリアデータ連携基盤の活用状況については、[デジタル庁エリアデータ連携基盤のホームページ](https://www.digital.go.jp/policies/digital_garden_city_nation/area-data-coordination-platform#status-nationwide)にダッシュボードとして公開しています。
### 12.4. 分野横断サービスの実現に向けた「3つの基本フロー」
これらのステップを着実に進め、高度な「分野横断サービス」を社会実装するための具体的な推進プロセスです。
* **①分野ごとの基本データ項目の整備：**
既存サービスが保有する連携対象データから、分野（医療、防災、交通等）ごとに最低限必要となる基本データ項目を選定します。共同利用に向けた取組において、予めサービス種別ごとの「共通データモデル」が定義されている場合は、それらを最優先の候補としてマッピングを行います。
* **②分野横断サービスの検討：**
既存のサービスが、他の分野の基本データ項目を掛け合わせることで、より効果的に地域課題を解決できるか（例：防災アプリに医療データを混ぜるなど）を企画・検討します。住民の満足度の向上という観点からは、他分野のパーソナルデータを本人同意のもとで安全に活用し、徹底的に「パーソナライズされた価値」を提供できるサービス像を目標に据えることが極めて有効です。
* **③分野間相互接続の実現：**
企画した分野横断サービスが必要とする広域なデータ利活用を実現するために、隣接する自治体や県全体のエリアデータ連携基盤同士を相互に接続します。前章までの「基盤間連携（認証連携・データ連携など）」で定めたガバナンスルールに準拠し、異なる運営組織が管理する複数の共同型エリアデータ連携基盤をセキュアに相互接続します。
🔖詳細については[Appendix](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/84c08375-e8c4-440f-8ef4-521a4a36ed9f/e9c28525/20260904_policies_digital-garden-city-nation_guideline-of-area-data-coordination-platform_appendix.pdf)P.119「分野横断サービスの実現」をご確認ください。
▲[目次に戻る](#00)
## 13. エリアデータ連携基盤の真の価値
### 13.1. 地域の「バイタルサイン」を捉える：「リアクションデータ」という新しい視点
エリアデータ連携基盤には、防災・交通・健康・子育て・観光といった複数の分野のデータアセット（オープンデータやIoTセンサー等のリアルタイムデータ）と、住民が実際に利用する各サービスの利用データが、分野の垣根を越えて集まってきます。
ここで参考になるのが、医療や介護の現場で日常的に行われている「**バイタルサイン**」です。バイタルサインとは、体温・血圧・脈拍・呼吸といった、生命の状態を示す複数の基本的な指標のことを指します。医療の現場では、このうちどれか1つだけを見て患者の状態を判断することはありません。複数の指標を組み合わせ、さらにその数値の経過（変化）を継続的に追うことで、初めて身体に起きている変化を客観的に捉えることができるからです。
地域も同様に、防災、交通、健康、子育てといったデータを個別に眺めているだけでは、地域に今何が起きているのかは見えてきません。エリアデータ連携基盤に集まった全てのデータを分野横断的に俯瞰したとき、それは単なる個々の情報（パーソナルデータ）の無機質な集合体ではなく、エリア内における住民の活動、選択、そして地域に対する反応の総体＝「**リアクションデータ**」として浮かび上がってくるものと考えています。すなわちリアクションデータとは、特定の分野のデータ単体からは決して見えてこない、分野を掛け合わせて初めて把握できる「地域の姿」です。
これこそが、地域の「今」をリアルタイムに映し出す「生きたデータ」です。このリアクションデータを、地域の状態を示すサインとして捉え、その変化を継続的に観測しながらまちづくりに活かしていくことが重要と考えています。
### 13.2. 「きっかけ」と「反応」を繋ぐことで、データは「洞察」に変わる
リアクションデータの真価は、行政の施策（きっかけ）と、それに対する住民・都市の行動変容（反応）をシステム的に結び付けることで初めて発揮されます。
ここで重要なのは、「きっかけ」と「反応」が同じ分野の中で完結するとは限らない、という点です。例えば、オンデマンド交通を導入したという施策（交通分野）の効果は、その利用者数だけを見ていても十分には分かりません。効果は、高齢者の外出頻度の増加や健診受診率の向上、通いの場への参加者数の変化といった、健康・福祉分野のデータに現れます。所管課ごとにデータを抱えたままでは、この因果関係は見えないままです。施策の効果を正しく捉えるには、分野をまたいでデータを突き合わせる必要があり、その突合を可能にすることこそが、エリアデータ連携基盤の果たす役割です。
これにより、従来の「勘と経験」に頼らざるを得なかったところから、客観的なデータを根拠に次の施策をアップデートしていく、持続可能で再現性のある「**データドリブンなまちづくり**」への進化を成し遂げることができます。
### 13.3. エリアデータ連携基盤を通じた「データ利活用」の3つの方向性
以上のとおり、リアクションデータの価値は、分野をまたいでデータを結び付けたときに最大化されます。単一のサービスや縦割りの分野だけでデータを抱え込むのではなく、分野の壁を越えてデータを掛け合わせることにこそ、本当の価値があります。これらを段階的に発展させることで、個人に最適化されたインクルーシブなデジタル社会の実現につながると考えています。
### 13.4. 「産官学連携」による、まちづくりの新しいエコシステム
エリアデータ連携基盤から生み出される価値ある「リアクションデータ」は、決して行政だけのものではありません。地域の共有資産として活用できるようになれば、産官学の新たなイノベーションを生み出す源泉となります。
これにより、これまで行政が交付金や税金等で負担していた「まちづくりのコスト」を、民間企業や大学、研究機関がビジネスや研究の対象として共に投資し、共に価値を回収し合う「持続可能な地域エコシステム」へと転換します。
### 13.5. AIネイティブ時代だからこその真価
AIの急激な進化により、多くの方がAIを日常的に活用するようになってきています。主な使い方は、チャットで質問や指示をすれば答えを返してくれるというものです。最近では「エージェント」と呼ばれる使い方も広がっています。これは、与えられた目的やゴールに向けて、AIが自ら手順を考え、必要に応じて検索やコード実行などのツールを使いながら作業を進めてくれるというものです。
このAIネイティブな時代において、AIの性能や安全性は、AIモデルの規模や性能そのもの以上に、「どのデータを、どの権限で、どのような品質管理のもとに収集・更新したか」に強く左右されると言っても過言ではありません。
そこで考えていただきたいのが、「エリアデータ連携基盤で扱っているデータとは何か」ということです。
データアセットについては、出所がはっきりとしているデータだといえます。また、サービスが持つデータについては、利用者本人に関連するデータだといえます。
ここには、信頼のおけるエリアデータやパーソナルデータがあります。これらをAIがうまく活用できれば、利用者本人にとって「自身と地域をよく知ったエージェント」が誕生し、ハイパーパーソナライズされたデジタル活用が実現します。
AIの進化により、エリアデータ連携基盤の価値が、ようやく明確になってきたともいえるでしょう。
デジタル庁としては、今後もエリアデータ連携基盤とAIについて、様々な情報提供を行ってまいります。
▲[目次に戻る](#00)
## 14. サービス利用者を増やすための戦略
### 14.1. 「利用者」がいなければ基盤は価値を生まない
エリアデータ連携基盤の価値を高めるのは、システムに接続されたサービス数やデータアセットの量だけではありません。実際にそれらを使う「利用者数」こそが、基盤の成否を分ける最大の要素となります。
* 本質的な事実（The Fundamental Truth）：
データの価値は、その「量と質」に大きく依存します。前章で述べた「リアクションデータ（まちのバイタルサイン）」を意味ある統計データにするためには、土台となる連携サービスの利用者を増やすことが絶対条件です。
* 視点の転換（A Shift in Focus）：
どれほど優れたデータアーキテクチャを裏側（バックエンド）で構築しても、住民に使われなければ意味がありません。私たちはシステム設計と同時に、「どうすれば住民が毎日使いたくなるか」を徹底的にデザインする**UI/UX（ユーザーインターフェース／ユーザー体験）の視点**を併せ持つ必要があります。
### 14.2. 普及を加速させる「タッチポイント戦略」
デジタルサービスを効果的に届けるためには、「誰に」「いつ」「どこで」届けるべきかという「タッチポイント（住民と行政・サービスが実際に接点を持つ機会や場所）」を戦略的に設計することが重要です。
> 💡 **リアル（アナログ）な接点からデジタルへ誘う**
> オンライン広告だけで完結させるのではなく、住民が必ず訪れる「リアルな行政窓口」やライフイベントの瞬間（アナログな接点）を捉えて対面でサポートする。このハイブリッドなアプローチが、利用者を伸ばす鍵となります。
**📌 接点（タッチポイント）と入口（ポータル）の整理**
① **ライフステージの起点（トリガー）を狙う：**
マイナンバーカードの交付時、母子手帳の申請時、引越し時の転入・転出届の手続きなど、新しくサービスを利用し始める必然性があるタイミングを「起点」として捉え、その場で登録や利用案内を行います。
>🤱**子育て世代のユーザージャーニー（具体例）**
住民の生活にどのようにデジタルアプローチを組み込むか、最もタッチポイントを活用しやすい「子育て世帯」を例にした具体的なジャーニー（行動の流れ）です。
出生届の提出や乳幼児健診といった「必ず発生するリアルな対面イベント」の瞬間に、自治体データと連携した子育て支援アプリなどの登録・操作サポートを組み合わせることで、確実な利用者の定着を促します。
**タッチポイント施策の評価観点**
| タッチポイント | 主な対象者 | 施策例 | 評価指標 |
| --- | --- | --- | --- |
| マイナンバーカード交付 | 全住民 | 地域ポータル・共通IDの登録支援 | 登録率、初回ログイン率 |
| 母子手帳交付 | 妊産婦・子育て世帯 | 子育て支援アプリの登録案内 | 登録率、健診予約利用率 |
| 転入届 | 転入者 | 防災・交通・ごみ出し等の生活サービス案内 | 転入者登録率、30日以内利用率 |
| 乳幼児健診 | 子育て世帯 | 健康データ連携・通知設定支援 | 通知開封率、継続利用率 |
| 高齢者窓口 | 高齢者・家族 | 見守り・交通・医療サービスの対面登録支援 | 代理登録率、問合せ削減率 |
**②ターゲット層と媒体の最適化：**
高齢者、学生、子育て世帯など、届けたい対象者ごとに「広報誌（アナログ媒体）」や「自治体公式LINE（デジタル媒体）」のリーチ層を正確に見極め、最も響くアプローチを選択します。
**③スーパーアプリやポータルへの集約：**
バラバラになりがちな複数のサービスや行政手続を、1つの「スーパーアプリ」や「地域ポータルサイト」の入口に集約し、利用者が迷わずアクセスできる環境をワンストップで提供します。
全てのサービスをまとめるのは難しいかもしれませんが、まとめた方がわかりやすいものは、まとめてポータル化させた方が普及コストも最小化できます。
▲[目次に戻る](#00)
## 15. （参考）既存サービスを接続し追加する方法
地方公共団体が既に導入・運用している既存の住民向けサービス（地域ポイントアプリ、健康ウォーキングアプリなど）を、新設される「エリアデータ連携基盤」へセキュアかつ低コストで連結し、データの相互利活用による「クロスドメイン（分野横断）での地域価値創出」を実現するためのシステム要件と実装アプローチをまとめました。
* **技術的アプローチ**
既存システムのコアロジックに対する大規模改修を回避するため、データの変換処理を中継する「変換用の中継プログラム」の配置を推奨します。データ交換の通信規格には国際標準の `NGSI` を、ID連携の認証基盤には `OIDC（OpenID Connect 1.0）` を採用することで、安全なシングルサインオン（SSO）と本人同意に基づく属性連携を最小限の工数で実現します。
* **法務・セキュリティ対策**
個人情報保護法におけるデータの4分類（個人情報・仮名加工情報・匿名加工情報・個人関連情報）に応じた厳格なアクセス認可制御（特に仮名加工情報の第三者提供禁止ルールの遵守）を行います。また、住民が自らの意思でデータ開示範囲を制御できる「同意管理」の実装及び総務省のスマートシティセキュリティガイドラインへの完全準拠が不可欠です。本章を通じて、これらを段階的に構築するステップと、実務上の主要課題への Tips（解決策）を定義しました。
### 15.1. 既存サービスを連結する技術要件
既存のサービスシステムをエリアデータ連携基盤に安全かつ論理的に接続するための主要な技術要件です。
**① APIの標準化と通信プロトコル（NGSI仕様）**
コンテキスト情報管理モジュール（FIWAREのコンテキストブローカー等）と双方向通信を行うため、リアルタイムな情報流通を可能とする国際標準プロトコル **`NGSI-LD`**（または `NGSI v2`）を採用します。
既存アプリ側が直接NGSIを実装できない場合は、中間に「変換用の中継プログラム」を配置し、既存APIのレスポンスやデータベースの出力を、基盤が扱えるNGSI形式に双方向変換してシームレスに転送する構成を基本とします。
**② データモデルの共通化（セマンティックな相互運用性）**
異なる分野のデータを組み合わせて使えるようにするため、項目名や値の表現を揃えます（意味的相互運用性の確保）。
具体的には、デジタル庁が公開する「エリアデータ活用のためのデータモデル」（避難所、施設情報等の項目定義）や、グローバルな標準語彙集である「Smart Data Models」に準拠したデータフォーマット（JSON-LD等）等を適用します。
**③ 既存システムの接続手法（3つのデータ連携パターン）**
扱うデータの特性や更新頻度、システムの負荷特性に合わせて、適切な接続方式を選択・設計します。
* **リアルタイムAPI連携（随時接続方式）：**
民間駐車場の満空状況や、観光店舗のリアルタイム混雑情報など、瞬時に変化する動的データをAPI経由で即時につなぎ込みます。
* **ETL／バッチ連携（定期接続方式）：**
前日の健康ウォーキング歩数実績や、地域ポイントの月間利用実績の集計など、リアルタイム性を求められないデータについて、深夜帯等にバッチ処理（抽出・変換・格納）を回すことで、低コストかつ安全に連携します。
* **ストリーミング連携（連続ストリーム方式）：**
街頭のIoT環境センサー（気温・雨量等）や、公共交通（バス・オンデマンドタクシー）のGPS位置情報など、絶え間なく発生する時系列データを連続ストリームとして基盤へ高頻度送信します。
### 15.2. OpenID Connect (OIDC)を活用したID連携の設計
多くの住民向けアプリは、サービスごとに異なるIDとパスワードの個別管理による「ログインの煩雑さ（住民の利用離脱）」が課題となっています。これを解決するため、OIDCを用いた共通ID基盤との統合設計を行います。
**① 認証・同意・属性連携の流れ（イメージ図）**
住民がウォーキングアプリ等に「地域共通ID」でログインし、開示にオプトイン（同意）した上で、安全にデータを基盤と共有する流れの全体像です。
```mermaid
sequenceDiagram
autonumber
actor User as 住民
participant App as 既存アプリ
participant IdP as 共通ID基盤
participant Base as エリアデータ連携基盤
User->>App: 「地域共通IDでログイン」を選択
App->>IdP: 認証と同意取得を依頼 (画面遷移)
IdP->>User: ログイン画面／連携内容の同意画面を表示
User->>IdP: ログイン ＆ 同意 (オプトイン)
IdP->>App: 一時的な引換コードを返却 (画面遷移)
App->>IdP: 引換コードを提示
IdP->>App: 認証結果・同意範囲の情報を返却
App->>Base: 返却された情報を添えてデータを送信
Base->>Base: 内容を検証し、同意された範囲のみ処理
```
**② 既存認証システムと共通IDの紐付け（IDリンク）**
すでに独自の会員IDで稼働している既存アプリを共通ID化する場合、既存のアカウントデータベースに、共通ID基盤が発行する識別子を保持する列を追加し、既存IDと対応づける「アカウントリンク」方式を導入します。識別子の発行方式は基盤によって異なるため、事前に仕様を確認してください。既存IDと共通IDを関連付けることで、既存の活動データを引き継いだまま共通ID認証へ移行できます。なお、移行期に従来のID／パスワード認証を併存させる場合は、認証経路が二重に残ることになります。移行期間を予め定め、期間経過後は従来認証を停止する運用設計も必要です。
### 15.3. データガバナンスとセキュリティ要件
**① 個人情報保護法への適合（データの4分類と認可制御）**
流通・連携させるデータは、個人情報保護法に基づいて厳格にアクセス制御（ACL）を設計する必要があります。
| 法律上のデータ分類 | 特徴とデータ連携時の必須要件 | スマートシティにおける具体的な用途 |
| --- | --- | --- |
| **① 個人情報** | 氏名やマイナンバーなど、特定の個人を識別できる情報。第三者（別サービス等）へ提供するには、**本人の事前確認と明示的な同意（オプトイン）** が必須。 | パーソナライズされた交通MaaSの予約、個人の状態に合わせた行政通知・医療サポート。 |
| **② 仮名加工情報** | 他のデータと照合しない限り個人を特定できないよう加工した情報。法律上、**「第三者への提供は原則禁止」**。 | エリアデータ連携基盤内部に閉じ、AI分析モデルの機械学習や、統計アルゴリズムの検証用データ。 |
| **③ 匿名加工情報** | 特定の個人を識別できないよう、かつ復元不可能なレベルまで高度な減算加工を施した情報。**本人同意なしで第三者提供が可能**。 | 民間企業へも開放する、特定駐車場の時間帯別混雑統計値や、観光地エリアの1時間ごとの人流変化データ。 |
| **④ 個人関連情報** | クッキー（Cookie）や単体のGPS位置情報など。**「提供先（別アプリ等）で個人データ化される」ことが予見される場合、提供先が本人から同意を取得していることの確認義務**が発生。 | 既存の民間ポイントサービスで収集した位置履歴を、基盤側の個人IDと結合・マッチングさせて活用する際の手続き。 |
>💡匿名加工情報の扱いについて
>民間の「匿名加工情報」は義務を履行すれば第三者提供できますが、「行政機関等匿名加工情報」では「保有個人情報を第三者提供できる」ことが条件に加わります。
>また、匿名加工情報は受領者の判断で他の第三者へ再提供できますが、行政機関等匿名加工情報は行政機関等と受領者との提供契約に基づいて取り扱うことになります。
**② 同意管理の導入**
住民が「自分のどのデータを、どの分野のサービスに、どこまで開示するか」を自らのスマートフォンから自由に変更・コントロール（ダイナミックオプトイン方式の採用）できるよう、同意管理の機能と連携が必要となります。いつ同意・解除したかのタイムスタンプ付きログを確実に保存・管理し、ガバナンスを担保します。
**③ スマートシティセキュリティガイドライン**
基盤の構築の有無にかかわらず、サービス実装においても、総務省が発行している「スマートシティセキュリティガイドライン」（2026年9月時点 第3版）を参考にし、適切な対策を検討します。
▲[目次に戻る](#00)
以上
© 2026 Digital Agency, Government of Japan
This work is licensed under [PDL 1.0](https://www.digital.go.jp/resources/open_data/public_data_license_v1.0)
**参考文献**
* 内閣府 [「スマートシティリファレンスアーキテクチャ」](https://www8.cao.go.jp/cstp/society5_0/smartcity/index.html#architecture)
* 総務省 [「スマートシティセキュリティガイドライン」（2026年9月時点第3版）](https://www.soumu.go.jp/main_content/000955126.pdf)
**執筆協力者**
* 一般社団法人データ社会推進協議会
* TISI株式会社
* 公益財団法人九州先端科学技術研究所
**問合せ先**
デジタル庁 国民向けサービスグループ
[ご意見・ご要望](https://forms.cloud.microsoft/r/3BnjEn6Nuw)