小規模自治体における標準データモデルでのオープンデータ公開

和歌山県すさみ町 NGSIv2対応の記録
~ ODS・GIF・NGSI をつなぐデータモデリングの実際 ~

OPEN DATA WITH STANDARD DATA MODELSCASE STUDY : SUSAMI TOWN, WAKAYAMA × NGSIv2

01 / Executive Summaryエグゼクティブサマリー

株式会社ウフルは、和歌山県西牟婁郡すさみ町におけるオープンデータ推進の取り組みを支援し、AED設置箇所・医療機関・公衆無線LAN・観光施設のデータを、データ連携基盤CUCONを通じて、NGSIv2形式で公開する仕組みを構築した。すさみ町は従来からこれらのデータをCSVで公開しており、本件は、システム間連携を想定した機械可読な提供手段を新たに追加する取り組みである。公開までは、次の4つのステップで進めた。

  1. STEP1仕様の選定ODS・GIF・NGSIそれぞれの役割を確認し、どの標準に沿って何を提供するかを定めた
  2. STEP2データモデリングウフルによる支援のもと、一般社団法人データ社会推進協議会(DSA)の専門家の協力を得て、ODSデータをNGSIv2で表現するモデルを設計した
  3. STEP3実装CUCON上に組み込まれたFIWARE上に、CSVをアップロードするだけでNGSIv2形式に変換・公開できる仕組みを構築した
  4. STEP4公開約2か月のプロジェクト期間を経て、2025年1月末に本番リリースした

このうち最も検討を要したのが、データモデリングである。ODSの項目をNGSIのEntityとAttributeにどう対応させるかを示す参照可能なモデルが見当たらなかったため、本プロジェクトでは共通エンティティの設計から取り組んだ。専門家の知見を得ながら進めたことで、単なる形式変換ではなく、相互運用性を意識した構造として整理することができた。

この経験は、オープンデータの流通という観点で一つの論点を示している。同じODSに準拠したデータであっても、NGSI化の際のモデルが自治体ごとに異なれば、機械的に統合することはできない。たとえば、近隣の複数自治体のAED情報を一つの地図アプリでまとめて表示しようとすると、自治体の数だけ項目の対応付けを人手で行う必要が生じる。防災アプリや観光アプリのように広域で使われるサービスほど、この負担は大きくなる。

データが標準形式で公開されていても、
モデルが揃っていなければ広域での利活用は進みにくい。

本稿は、すさみ町での取り組みの過程を記録するとともに、この論点を踏まえた提言をまとめたものである。

02 / Project Overviewプロジェクトの概要

すさみ町は和歌山県南部、太平洋に面した西牟婁郡に位置する町である。人口は3,450人(男性1,661人、女性1,789人、世帯数1,984、2025年4月調査時点)。町では、「すさみ町まち・ひと・しごと創生総合戦略」にて掲げている目標を加速実現すべく、スマートシティを推進しており、その過程でデータ連携基盤の整備を進めた。

推進体制としては、すさみスマートシティ推進コンソーシアムに参加する事業者と連携し、技術的な検討・実装は事業者側が主体となって担う形をとった。小規模自治体が専門性の高い領域に取り組むうえで、外部の専門機関・事業者と役割を分担する進め方である。

TABLE 1プロジェクトの概要

対象データ AED設置箇所、医療機関、公衆無線LANアクセスポイント、観光施設
提供形式 NGSIv2(FIWARE Orion準拠)APIとCSV形式での公開
プロジェクト期間 2024年12月〜2025年1月末
体制 すさみ町/株式会社ウフル

03 / Key Termsオープンデータにおける用語の整理

本事例を理解するうえで、3つの用語の関係を整理しておく。ODSは何を公開するか、GIFは他システムとも通じる形にどう整理するか、NGSIはそれをどう配信するかを、それぞれ定めている。

TABLE 2ODS・GIF・NGSIの階層関係

名称 役割 AEDを例にすると
ODS自治体標準オープンデータセット 自治体が公開すべきデータの種類と、CSVの項目・書式を定めた実務ルール 「名称」「所在地_都道府県」「緯度」「経度」などのCSV列構成
GIF政府相互運用性フレームワーク 府省庁・自治体・民間を横断してデータをやり取りするためのデータモデルのひな型 施設・場所・法人といった共通エンティティの型定義。ODSはGIFを参照したデータモデルという位置づけ
NGSIv2 / LD モデル化されたデータをEntityとAttributeとして表現し、APIで流通させる技術仕様 AEDを1件のEntityとして表し、位置情報や属性をAttributeとして持たせ、APIで取得できるようにする

04 / Path to Publicationオープンデータ公開までの道のり

標準データモデルでオープンデータを公開するには、いくつかのステップを順に踏む必要がある。本章では、ウフルがすさみ町のオープンデータ公開支援において実施したプロセスを、仕様の選定・データモデリング・実装・公開の順に記す。

4.1仕様の選定

本件では、NGSI形式でのデータ提供と、自治体標準オープンデータセットへの準拠が前提となっていた。NGSIにはNGSIv2とNGSI-LDという世代の異なる2つの仕様があるため、まずどちらを採用するかを定める必要があった。デジタル庁・DSAが示す推奨モジュールにおいて、非パーソナルデータ用のブローカーとしてNGSI v2 FIWARE Orionが指定されていることから、NGSIv2を採用する判断を行った。

4.2データモデリング

国は、データの相互運用性を確保するための枠組みとして、政府相互運用性フレームワーク(GIF)を整備している。GIFは、語彙(IMIコア語彙)、コアデータモデル、分野別の実装データモデルという階層構造を持ち、ODSもGIFを参照したデータモデルという位置づけにある。一方、実務で参照できるのは実装データモデルが項目一覧として整理された資料であり、ODSの項目をNGSIのEntity・Attributeにどう対応させるかを直接示すものは、本プロジェクトの時点では見当たらなかった。

そこでウフルは、一般社団法人データ社会推進協議会(DSA)理事であり、ウフルのCDTO(Chief Data Trading Officer)でもある杉山恒司氏をはじめとする専門家の協力を得て、項目の対応付けにとどまらないデータモデリングに取り組んだ。その結果として整理したのが、法人(Organization)・施設(Facility)・建物(Building)・土地(Land)という共通エンティティである。AEDや医療機関といった個別のデータは、これらの共通エンティティをRelationshipで参照する構造とした。位置情報や連絡先のように複数のデータ種別に共通して現れる情報を、一箇所にまとめて表現できる。AEDを例に、この変換の内容を図1に示す。

FIGURE 1ODSのCSV 1行が、5種類のEntityに分解される(AEDの例)

ODS(自治体標準オープンデータセット) AED設置箇所一覧 — CSVの1行

全国地方公共団体コード 名称 所在地_連結表記 緯度 / 経度 電話番号 法人番号 ほか
304069 特別養護老人ホーム はまゆう園 すさみ町周参見2362 33.5555798 / 135.4959463 0739-55-3484 …

1つの行に、設備・施設・建物・住所・管理主体の情報がすべて並んでいる(項目は抜粋)

NGSIv2形式へ変換

NGSIv2 Entityの構造

Devicetype: Device / category: AED
id: urn:ngsi-ld:Device:AED-1location(緯度・経度)設置位置・利用可能曜日 など
refFacility
Facility施設
contactPoint(連絡先)floor / 高度
refBuilding
Building建物
name(はまゆう園)nameKana / nameEn
refLand
Land土地
address(住所一式)都道府県・市区町村 ほか

Device から、管理主体を参照

refOwner
Organization設置主体
name / 法人番号
refInformationCustodian
Organization情報の管理主体
全国地方公共団体コード

Facility・Building・Land・Organization は、医療機関や観光施設など他のデータ種別からも同じ実体を参照できる共通エンティティ。住所や連絡先を、データ種別ごとに重複して持つ必要がなくなる。

図1:ODSのCSV 1行が、5種類のEntityに分解される(AEDの例)

ODSのCSVでは、AEDそのものの情報(設置位置、利用可能曜日)、設置先の施設の連絡先、建物の名称、住所、情報の管理主体が、すべて1つの行に並んでいる。NGSIv2では、これらをDevice・Facility・Building・Land・Organizationという5種類のEntityに分け、Relationship(refFacility、refBuilding、refLand、refOwner、refInformationCustodian)で相互に参照する構造とした。この分け方により、同じ建物に複数のAEDが設置されている場合でも、建物や住所の情報は1つのEntityとして表現され、それぞれのAEDから参照される。表記ゆれや更新漏れが生じにくくなるほか、他のデータ種別からも同じ実体を参照できる。

本プロジェクトで最も時間を要したのがこの工程である。専門家の知見を得ながら進めたことで、GIFのコアデータモデルに相当する抽象化を、本件のデータに即した形で整理することができた。

4.3実装

CUCONにはオープンソースのFIWARE(Orionコンテキストブローカー)を組み込み、NGSIv2サーバを構築した。すさみ町の担当者は、CUCON管理画面からODSデータ(CSV)をアップロードするだけで、システムが自動的にNGSIv2形式へ変換し、サーバに登録・公開する。

  • ODSデータ(CSV)の形式チェック:必須項目の有無や文字コードを確認し、画面上に結果を表示
  • NGSIv2形式への変換・登録:チェック済みのCSVを変換し、サーバへ登録
  • データの参照・削除:設備・施設単位の削除のほか、選択削除・一括削除にも対応

NGSIv2サーバのAPIは https://api.cucon.io/v1/fiware/v2/ で公開しており、FIWARE Orion NGSIv2仕様に準拠している。代表的なエンドポイントは表3のとおりである。API利用にはCUCONが払い出すAPIキーが必要で、リクエストヘッダに Authorization: Bearer <APIキー> を付与する方式とした。EntityのIDは urn:ngsi-ld:Device:AED-<ID> のようなURN形式を採用し、共通エンティティについては内容から生成するハッシュ値を用いた。この命名やRelationshipによる参照構造は、NGSI-LDの考え方を踏まえたものである。

TABLE 3主なAPIエンドポイント

概要 API名 HTTPメソッド
データリストの参照 entities GET
バッチクエリの実行 op/query POST
データの参照(ID指定) entities/{entityId} GET
属性情報の参照(ID・属性指定) entities/{entityId}/attrs GET
タイプリストの参照 types GET

4.4公開

約2か月のプロジェクト期間を経て、NGSIv2形式でのオープンデータ公開を本番リリースした。公開対象は、AED設置箇所、医療機関、公衆無線LANアクセスポイント、観光施設の4種類である。

すさみ町の公式サイトでは、CC0ライセンス(クリエイティブ・コモンズ・ゼロ)に基づくCSVによる公開に加え、NGSIv2 APIはシステム間連携を意図した提供手段として追加された形になる。

EXTERNAL LINKすさみ町 スマートシティのオープンデータhttps://www.town.susami.lg.jp/tyousei/03/2025-0228-0917-1.html

05 / Insights & Recommendations得られた知見と提言

本事例を通じて得られた知見をもとに、自治体のオープンデータ標準化・データ連携基盤整備を推進する立場の方々に向けて、3点を提言する。

5.1ODS・GIF・NGSIをつなぐリファレンスモデルを整備する

本プロジェクトで最も検討を要したのは、ODSの各データ種別をNGSIでどうモデル化するかであった。データ種別ごとに、ODS項目・GIFコアデータモデル・NGSIのEntity構造までを一貫して示すリファレンスモデルが整備・公開されれば、各自治体・各事業者が同じ検討を重ねる必要がなくなる。あわせて、GIFの実装データモデルを項目一覧としてだけでなく、施設・場所といった共通エンティティの構造として示せると、本プロジェクトで行ったような共通エンティティの設計を、各案件で繰り返さずに済むと考えられる。本プロジェクトで整理した構造を図2に示す。

FIGURE 24種類のデータ種別に共通するエンティティ構造

パターンA:設備・機器として表現(Device型)

AED設置箇所type: Devicecategory: AED公衆無線LANtype: Devicecategory: PublicWirelessLAN
refFacility
Facility施設
contactPointfloor / 高度
refBuilding
Building建物
namenameKananameEn
refLand
Land土地
address(住所一式)

パターンB:施設そのものとして表現(Facility型)

医療機関type: Facilitycategory: Hospital観光施設type: Facilitycategory: Tourism
refBuilding
Building建物
namenameKananameEn
refLand
Land土地
address(住所一式)

共通:4種類すべてのデータが参照

4種類すべてAED・公衆無線LAN・医療機関・観光施設
refOwner / refInformationCustodian
Organization法人・団体
name法人番号団体コード

施設・建物・土地・法人を共通エンティティとして切り出すことで、複数のデータ種別に共通して現れる情報を一箇所にまとめて表現できる。

図2:4種類のデータ種別に共通するエンティティ構造

4種類のデータは、大きく2つのパターンに分かれる。AEDと公衆無線LANは、施設に設置された設備・機器であるためDevice型で表現し、refFacilityで施設を参照する。医療機関と観光施設は、施設そのものであるためFacility型として表現し、建物を直接参照する。いずれの場合も、建物・土地・法人という共通エンティティにつながる。このような型の選択や参照関係は、項目一覧からは読み取れない。データ種別ごとに、どの型を用い、どの共通エンティティを参照するかが示されていれば、各案件で同じ設計判断を繰り返す必要がなくなる。

5.2語彙を機械可読な形で公開する

将来的にNGSI-LDを活用する場合、その相互運用性はJSON-LDのコンテキスト(@context)に依存する。各項目名が、共同で管理された語彙の識別子に紐づけられることで、異なる自治体のデータを機械的に統合できるようになる。本件でも、項目の対応関係は変換仕様書として定義しているが、その内容はExcel形式にとどまっている。同様の対応関係を、URLで機械可読に公開できる形にすることが、広域での利活用を進める前提条件となると考えられる。

5.3専門機関・事業者との協業モデルを広げる

すさみ町の取り組みは、自治体・業界団体・事業者がそれぞれの役割を分担することで実現した。標準データモデルの設計には専門的な知見が必要であり、それを自治体単独で確保することは規模を問わず容易ではない。すさみ町がコンソーシアムを通じて外部の専門性を取り込んだ進め方は、同様の課題を抱える他の自治体にとっても参考になる。この協業を広げるうえでは、共通で使える参照モデルやテンプレートが提供されることが有効である。事業者が個別に設計を組み立てる部分が減れば、より多くの自治体が短い期間で標準対応に着手できる。

06 / Outlook今後の展望

すさみ町とウフルの取り組みは、小規模自治体でも、外部の専門機関・事業者と連携することで標準データモデルへの対応が可能であることを示した。一方、整理したモデルは相互運用性を意識して設計しているものの、国として標準化されたものではないため、現時点ではすさみ町向けのモデルである。同じODSデータを他の自治体が公開する際にそのまま再利用できる状態にするには、モデルが国レベルで標準化され、機械可読な語彙として公開されることが望ましい。

FROM UHURU

ウフルとしては、CUCONがNGSI-LDとNGSIv2の双方に対応している強みを活かし、標準化に向けた知見の提供を継続していきたい。標準データモデルの普及を後押しする立場の方々にとって、本稿が現場の実際を伝える一例となれば幸いである。

Share

CONTACT

ご依頼・ご相談など、お問い合せはこちら