2026.10.26 アーキテクチャ

スマートシティの技術：都市OSをFIWAREとNGSI-LDで組む参照構成と実装手順

Q: スマートシティの実装事例はどこで確認できますか？

国内の分野別の事例は スマートシティ事例を分野別に整理した記事 でまとめています。技術構成まで知りたい場合は、内閣府のスマートシティのページから辿れる各地域の資料と、SCRA5.0の第11章にある交通や地理空間の連携例を見ると、どの層にどの技術を置いたかが分かります。

スマートシティの技術：都市OSをFIWAREとNGSI-LDで組む参照構成と実装手順

スマートシティの技術と聞いて、IoT・AI・5Gといった単語の一覧を思い浮かべる方は多いはずです。ただ、実装する側が最初に決めなければならないのは、分野ごとに集めたデータをどの形式で、どの基盤に、誰の権限で置くかという一点です。この記事では、内閣府のスマートシティリファレンスアーキテクチャ第5版（SCRA5.0）が前提に置くNGSI-LDと、そのオープンソース実装であるFIWAREのOrion-LDを使い、検証環境の起動からセンサー値の登録・照会・購読、履歴の保存、アクセス制御、調達の切り方までを順に扱います。スマートシティの定義や自治体の着手順序はスマートシティの政府定義と都市OSの成熟レベルを解説した記事に譲り、ここは都市OSを動かす技術に絞りました。

まとめ｜スマートシティの技術は都市OSのデータモデルと権限設計で決まる

結論から書きます。スマートシティの技術選定で中心に来るのは、センサーやAIの性能ではなく、分野をまたいでデータを渡す都市OSの作り方です。SCRA5.0は都市OSの共通方針をNGSI-LD前提で整理しており、新規に組むならNGSI-LDのAPIとSmart Data Modelsのデータモデルを起点にするのが素直な選択になります。

実装の順序は、ブローカを立てる、エンティティIDと@contextの規則を決める、IoTゲートウェイからの変換を通す、履歴の保存先を選ぶ、認可とテナントを前段で切る、の5段階です。このうち後から直しにくいのはIDと@contextの規則で、ここだけは最初の検証環境で固めてください。

判断も先に示します。動的データが少なく静的な地図データが中心の自治体なら、ブローカを自前で抱えず既存の地理空間基盤との並立で始めて構いません。逆に複数分野のリアルタイムデータを単一APIで出す要件があるなら、NGSI-LDブローカ中心の構成を選び、運用はマネージドに寄せる。この線引きを最後の章で条件ごとに整理しました。

スマートシティを支える技術の層構造｜センサーから都市OSまでの役割分担

スマートシティの技術を個別製品の名前で並べると、選定の議論が散らばります。層に分けて、それぞれが何を受け取り何を渡すかで整理すると、どこに標準を入れるべきかが見えてきます。

収集層・連携層・サービス層に分けたときの責務と採用する代表的な技術

収集層はセンサー、カメラ、既存の業務システムから値を取り出す部分で、MQTTやHTTP、各分野の業界仕様が混在します。連携層が都市OSにあたり、収集した値を共通のデータモデルへ揃え、APIで外へ出す役割を持つ。サービス層は防災ダッシュボードや交通案内アプリなど、連携層のAPIを読む側です。

層	主な責務	代表的な技術
収集層	値の取得とプロトコル変換	MQTT、IoT Agent、GTFS-RT
連携層（都市OS）	データモデルの統一とAPI公開	NGSI-LD、Orion-LD、Scorpio
サービス層	分野別アプリと分析	地図表示、BI、予測モデル

標準を強く効かせるべきなのは連携層の出口だけです。収集層の多様さを連携層の入口で吸収し、出口は1つのAPI仕様に揃える。この形にしておけば、サービス層のアプリを入れ替えても連携層は残ります。

SCRA5.0が都市OSに置く共通機能と分野別システムに残す業務機能

SCRA5.0（2026年3月11日付・内閣府）の9.5節は、都市OS側が担う共通機能をデータ管理・認証と認可・API公開の3つとし、業務固有の機能は分野別システム側に置くよう求めています。特定ベンダーの独自拡張を基盤レイヤへ持ち込むと、再利用や他主体との連携を妨げるという理由です。

実装に落とすと、都市OSにビジネスロジックを書かないという規律になります。たとえば「PM2.5が閾値を超えたら学校へ通知する」という判定は防災や教育の分野システム側に置き、都市OSは値の保持と変化の通知だけを受け持つ。なお、SCRA5.0本体は特定製品の実装方法を規定しないと明記しており、語彙とメタデータの別冊仕様書は公表時点で未策定でした（2026年10月時点で確認）。

FIWAREの都市OS検証環境｜Orion-LDのDocker Compose起動手順

NGSI-LDの感触をつかむには、ブローカを手元で1つ立てるのが近道です。ここではFIWAREのOrion-LDを使います。

Orion-LD 1.12.0とMongoDBを1ファイルで起動する最小構成と確認手順

Orion-LDのREADMEは、MongoDB 4.2以上を必須とし、安定版イメージとして quay.io/fiware/orion-ld:1.12.0 を示しています。latestタグは非推奨と明記されているため、版は必ず固定してください。以下は公式のdocker-composeを、版固定と現行のCompose書式に直した最小構成です。

# docker-compose.yml
services:
  mongo:
    image: mongo:4.4
    command: --nojournal
  orion-ld:
    image: quay.io/fiware/orion-ld:1.12.0
    depends_on:
      - mongo
    ports:
      - "1026:1026"
    command: -dbhost mongo

docker compose up -d
curl -s localhost:1026/version

応答のJSONに "Orion-LD version" のキーが返れば起動は完了です。--nojournal は検証用の設定で、本番ではMongoDBのジャーナルを有効にし、レプリカセットで冗長化します。最新版はOrion-LD 1.12.0のリリースページで確認できます（2026年1月公開、2026年10月時点の最新）。

ブローカの選び分け｜NGSIv2のOrion 4.7とNGSI-LD対応の2系統

FIWAREのブローカは系統が2つあります。NGSIv2を実装する従来のOrionは4.7.0が2026年6月に公開されており、国内の実証事例の多くはこちらで組まれてきました。NGSI-LDを使うならOrion-LDかScorpio Brokerが候補です。

注意したいのは仕様の追随状況です。NGSI-LD APIの正本はETSI GS CIM 009 V1.9.1（2025年7月）が最新ですが、Orion-LDのREADMEは準拠対象をv1.6.1付近とし、v1.8.1への対応を作業中と書いています。仕様書の新しい機能を前提に設計するなら、採用前にブローカ側の実装有無を1つずつ確かめてください。SCRA5.0は、同じブローカがv2とLDの両APIを出す方式で既存クライアントを残しつつ移行する道も示しています。

NGSI-LDでセンサー値を登録して取り出す｜作成・照会・購読のリクエスト例

ブローカが立ったら、大気質センサー1台分のデータを流してみます。データモデルは独自に作らず、Smart Data Modelsの既存定義を借りるのが基本です。

AirQualityObserved登録｜Smart Data Models準拠

大気質の観測値にはAirQualityObservedモデルが用意されています。公式の正規化例に合わせ、観測日時は dateObserved、位置は location（GeoProperty）、二酸化窒素は no2 に単位コードを添え、設置地点への参照は refPointOfInterest（Relationship）で持たせます。

curl -s -X POST localhost:1026/ngsi-ld/v1/entities \
  -H 'Content-Type: application/ld+json' \
  -d '{
  "id": "urn:ngsi-ld:AirQualityObserved:jp:131010:station:001",
  "type": "AirQualityObserved",
  "dateObserved": { "type": "Property", "value": "2026-10-26T09:00:00Z" },
  "location": { "type": "GeoProperty",
    "value": { "type": "Point", "coordinates": [139.7671, 35.6812] } },
  "no2": { "type": "Property", "value": 21, "unitCode": "GQ" },
  "refPointOfInterest": { "type": "Relationship",
    "object": "urn:ngsi-ld:PointOfInterest:jp:131010:poi:012" },
  "@context": "https://smart-data-models.github.io/dataModel.Environment/context.jsonld"
}'

本文に @context を含めるときは、Orion-LDのクイックスタートにあるとおりContent-Typeを application/ld+json にします。application/json のまま送ると、@contextを本文に置けません。

位置で絞る照会と値の変化を外部システムへ通知する購読条件の書き方

照会では、登録時と同じ@contextをLinkヘッダで渡します。渡し忘れると AirQualityObserved という短い型名が既定の語彙で展開され、登録したエンティティが1件も返りません。以下は東京駅から半径2km以内の観測値を引く例です。

curl -s -G localhost:1026/ngsi-ld/v1/entities \
  -H 'Link: <https://smart-data-models.github.io/dataModel.Environment/context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
  --data-urlencode 'type=AirQualityObserved' \
  --data-urlencode 'georel=near;maxDistance==2000' \
  --data-urlencode 'geometry=Point' \
  --data-urlencode 'coordinates=[139.7671,35.6812]'

値の変化を分野システムへ届けるには購読を使います。q に条件を書けば、閾値を超えたときだけ通知させられます。通知先には、受け手のシステム側で用意するエンドポイントを指定してください。

curl -s -X POST localhost:1026/ngsi-ld/v1/subscriptions \
  -H 'Content-Type: application/ld+json' \
  -d '{
  "type": "Subscription",
  "entities": [ { "type": "AirQualityObserved" } ],
  "watchedAttributes": [ "no2" ],
  "q": "no2>40",
  "notification": { "endpoint": {
    "uri": "http://alert-service:8080/notify", "accept": "application/json" } },
  "@context": "https://smart-data-models.github.io/dataModel.Environment/context.jsonld"
}'

先ほどのPM2.5の例と同じで、閾値の判定を都市OSの中に作り込まず、購読の条件で分野システムへ渡すのが前章の責務分割に沿った作り方です。

エンティティIDの命名規則｜URN形式と自治体コードで衝突を防ぐ

SCRA5.0の8.5.1節は、エンティティIDに urn:ngsi-ld 形式を推奨し、urn:ngsi-ld:Building:jp:131010:facility:12345 のように型・国・全国地方公共団体コード・施設識別子を階層で並べる例を挙げています。避けるべき例として示されているのは facility_12345 や systemA_facility_01 で、管理主体が分からず特定システムの内部番号に依存する点が問題だとされています。

上の登録例のIDもこの規則に合わせました。都市間連携や広域化を見込むなら、自治体コードの位置は最初の検証環境から固定してください。後から変えると、購読や他エンティティからのRelationshipがすべて張り替えになります。@contextも同様で、自治体側に管理権限を残す配置にしておかないと、項目を1つ足すたびにベンダーへの発注が発生します。

IoTゲートウェイから履歴保存までの収集設計｜IoT AgentとTRoEの使い分け

センサーが直接NGSI-LDを話すことは、まずありません。現場の機器が送る値をエンティティの形へ変換する層と、時系列の履歴を残す層を別に用意します。

IoT Agent for JSONでMQTTのデバイス値をエンティティへ変換する

FIWAREには機器側プロトコルとブローカの間を取り持つIoT Agentがあり、IoT Agent for JSONはHTTPとMQTTで届くJSONのペイロードをエンティティの属性へ写します。版は3.14.0が2026年4月に公開されています。役割は、ゲートウェイが受けた値に意味を与えてブローカへ書き込む変換点です。

どこでプロトコルを変換するかの設計論はIoTゲートウェイの役割とクラウド直結との使い分けを解説した記事に、MQTT自体の仕組みとQoSはMQTTの仕組みとQoSを実装者向けに整理した記事にまとめています。都市OS側で押さえるのは、機器IDとエンティティIDの対応表をIoT Agentの設定として管理し、前章の命名規則に合わせることです。

履歴データの保存先｜TRoEとQuantumLeapを成熟度で選ぶ

ブローカが持つのは基本的に最新値だけで、履歴は別の仕組みに残します。選択肢は2つです。Orion-LD内蔵のTRoE（Temporal Representation of Entities）は -troe で有効化し、PostgreSQLにPostGISとTimescaleDBを組み合わせて保存、/ngsi-ld/v1/temporal/entities で履歴を返します。ただし公式文書自身が、最小限の試験しかしておらず本番向けではないと書いています。

もう一方のQuantumLeapは、購読の通知を受けてCrateDBやTimescaleDBへ書く方式で、NGSIv2では実績があります。NGSI-LDは実験的サポートにとどまり、取り出しはv2形式になる。最新リリースも1.0.0（2023年12月）で止まっています。

本番の判断を言い切ると、履歴を業務の根拠に使う段階では、どちらにも全面依存しないほうが安全です。購読の通知を自前の受け口で受けてTimescaleDB等へ直接書き、分析系はそこを読む構成にすると、ブローカの版上げに履歴が巻き込まれません。TimescaleDBの採否はTimescaleDBの仕組みと採用可否の判断基準を扱った記事を参照してください。

匿名加工とアクセス制御の設計｜個人に紐づく都市データを公開する前の線引き

環境センサーの値だけなら公開は容易です。ところが人流、カメラ、交通系ICの乗降のように個人に紐づきうるデータが入った時点で、APIの設計は権限と加工の設計に変わります。

テナント分離とロール別の認可をブローカ前段のAPI管理で実装する

SCRA5.0の9.5節は、複数の自治体や事業者が同じ基盤を使う場合にテナント単位でデータを分けること、ロールベースまたはポリシーベースでアクセスを制御すること、APIキー等で接続主体を識別することを挙げています。NGSI-LDではテナントを NGSILD-Tenant ヘッダで指定する方式が仕様にあり、Scorpio Brokerのマルチテナント文書にも同じヘッダでの指定例があります。

ブローカ単体には利用者ごとの認可を持たせず、前段にAPIゲートウェイを置いて認証と認可をそこで終わらせる構成を勧めます。FIWAREにもIDM（Keyrock）がありますが、最新リリースはFIWARE_8.4（2023年6月）です。汎用のゲートウェイとOpenID Connectの基盤で組むほうが保守の選択肢は広くなります。構成の考え方はAPIゲートウェイの役割と導入判断を解説した記事、IDプロバイダ側はKeycloakの使い方と権限モデルを扱った記事が参考になります。

人流やカメラ由来のデータを出す前に匿名加工の範囲を確定する手順

個人データを含む値をオープンデータや民間サービスへ渡すなら、ブローカに入れる前の段階で加工しておくのが原則です。個人情報保護委員会の匿名加工情報制度のページは、加工基準に沿った作成、安全管理、作成時の公表、識別行為の禁止を事業者の義務として示しています。

収集項目ごとに、個人情報か、個人関連情報か、どちらにも当たらないかを台帳にする
公開範囲（庁内のみ、協定先、一般公開）を項目ごとに決める
一般公開する項目は、集計単位（メッシュ、時間帯）と加工方法を決めてからエンティティ化する
生データを持つテナントと公開用テナントを分け、公開用だけをAPIゲートウェイの外へ出す

手順4のテナント分離が、前のh3で決めた権限設計とここでつながります。制度上の義務と加工基準の詳細は匿名加工情報の加工基準と第三者提供の義務を設計要件に翻訳した記事で扱いました。

都市OSの調達単位と採用判断｜自前構築とマネージドを分ける条件

技術が分かっても、どの単位で発注するかを誤ると、実証が終わった時点で基盤が宙に浮きます。最後に構成と調達の判断を条件で整理します。

二系統並立とNGSI-LD統合の2構成から自治体規模に合う方を選ぶ

SCRA5.0の11.3.2.1節は、FIWAREと地理空間データ連携基盤の組み合わせ方として2つの構成を示しています。静的な地図データは地理空間基盤から、動的データはFIWAREから取る「二系統並立構成」と、静的データもNGSI-LDに変換してブローカで一元管理する「NGSI-LD Broker中心の統合構成」です。

構成	向く条件	引き受ける負担
二系統並立	小規模、既存APIを残したい	アプリが2種のAPIを使い分ける
NGSI-LD統合	複数分野の動的データを1つのAPIで出す	静的データの変換と統合

判断の目安は、リアルタイムに扱う分野が2つ以上あるかどうかです。1分野だけなら並立で十分で、ブローカを抱えるだけ運用費が増えます。2分野以上を横断させるなら統合構成を選び、IDと@contextの規則を全分野で共有してください。

FIWAREの自前運用を見送る場面と仕様書に残す相互運用の要件

自前運用を見送るべきなのは、庁内にコンテナとデータベースの運用担当を置けない場合です。SCRA5.0も、ブローカの運用に専門的なインフラ知識が要ること、データモデルの変更がベンダー発注になること、@contextの管理権限が自治体にないことを運用コストが膨らむ理由に挙げ、SaaS型のマネージドブローカを選択肢として示しています。実証の単年度予算で自前サーバーを立て、翌年に保守費が付かずに止まるという実証で止まるスマートシティの典型的な課題は、この判断を先送りした結果として起きます。

調達の単位は、基盤（ブローカと認可）と分野アプリを別契約に分けるのが基本です。仕様書には、NGSI-LDの準拠版と未実装機能の一覧、エンティティIDの命名規則、@contextの所有者、APIの版管理と非推奨化の事前通知期間、データの書き出し方法を明記してください。SCRA5.0の9.4.2節もAPIの版管理と後方互換の方針を求めています。基盤側の設計から相談したい場合は、データ分析基盤構築・MLOps構築支援でお受けしています。

よくある質問

スマートシティの技術選定と都市OSの実装で、検討段階によく出る質問をまとめました。

スマートシティの都市OSはFIWAREでなければいけませんか？

いいえ。SCRA5.0は特定製品の実装方法を規定しておらず、求めているのは標準的なAPIとデータモデルによる相互運用です。NGSI-LDを実装していればScorpio Brokerや商用のマネージドブローカでも条件を満たせます。FIWAREは国内実績が多く、検証環境を無償で立てられる点で出発点として選ばれやすい、という位置づけです。

NGSIv2で作った既存の都市OSはNGSI-LDへ作り直す必要がありますか？

すぐに作り直す必要はありません。SCRA5.0はNGSIv2の既存実装を否定せず、同じブローカがv2とLDの両方のAPIを出す方式で既存クライアントを残す移行も示しています。ただしIDが短い文字列から urn:ngsi-ld 形式へ変わるため、新規分野をLD側で作り始め、既存分野は更改時に移すのが現実的な順序です。

スマートシティのデータモデルは自分で設計するものですか？

まずSmart Data Modelsに既存の定義がないかを確認してください。大気質、駐車場、交通流、街路灯など都市でよく使う型は既に定義があり、そのまま使えば他都市のアプリとも型がそろいます。不足する属性だけを自前の@contextで追加し、その@contextの管理権限を自治体側に残す運用が基本です。

都市OSの履歴データはどこに保存すればよいですか？

検証段階ならOrion-LDのTRoEで十分な構成です。本番で業務判断の根拠に使うなら、TRoEは公式に本番向けではないとされているため、購読の通知を受けて自前の時系列データベースに書く構成を勧めます。保存先にはPostgreSQL系のTimescaleDBが扱いやすく、地理情報もPostGISでまとめて持てます。