第15回「地理空間情報に関するベースレジストリ利活用研究会」レポート

2026/02/02

2025年12月22日（月）、第15回「地理空間情報に関するベースレジストリ利活用研究会」をオンラインにて開催し、委員とオブザーバーあわせて38名の委員が参加しました。今回はAIGIDと東京大学による研究開発の取り組みとして「オープンデータを用いたインフラベースレジストリの研究開発」および「河川系ベースレジストリ データ作成のための検討」、「変化検出に基づく建物IDを維持した建物フットプリント更新」について報告するとともに、2人の識者による話題提供が行われました。

情報試作室開発室の相良氏が、OpenStreetMap（OSM）のデータを用いて全国を網羅する公開可能な道路基盤データを構築する取り組みの進捗状況を報告しました。同プロジェクトでは2025年3月に試行版を公開しましたが、このバージョンにはいくつか課題があり、現在は道路リンクIDとその時系列管理方式の改良に取り組んでいます。また、ラインで与えられた道路に最も近い道路リンク列を検索する手法についても開発する予定です。

道路リンクIDの管理方法の改良については、これまでIDの算出方法にUUID4を使っていましたが、UUID4はランダム値のために作り直すたびにIDが変わってしまうという課題があります。そこで、いつどの環境で作り直しても同じリンクIDを生成できるように、ハッシュ値をベースとしたUUID5に変更することにしました。

また、道路属性については、従来は道路リンクの空間属性に対して道路の名前や路線番号などの情報をすべて与えていましたが、1つの道路区間に対して複数の名称が付いている場合があるため、名称や路線番号などは道路形状の外側に1対多で関連するテーブルとして持つように変更しました。例えば国道と県道が重複している場合は、1つの道路リンクIDに国道の属性データと県道の属性データの2つのレコードを作って紐付けるという方法にしています。そのためにOSMデータの“Way”と“Relation”のそれぞれから属性を抽出して統合する必要があり、現在この点が課題となっています。

UUID5の入力パラメータは、「始点ノードのID」「終点ノードのID」「リンクの長さ（10cm単位で丸めたもの）」「始点方位（0.1度単位で丸めたもの）」「スナップショットの時刻」の5つで、スナップショットが変わると同じデータでも異なるIDが生成されます。これにより、属性が変わっていない場合に同じIDを持つデータが重複してしまう問題を回避しました。ただし、リンクの変化のチェックは属性の比較で行うようにしました。

同じリンクかどうかの判定基準については、「始点ノードのIDが一致」「終点ノードのIDが一致」「長さの差が10cm以内」の3点で、前回までは基準に入れていた「路線種別が一致」「路線番号が一致」「道路名が一致」の3点については除外しました。これは道路形状が変わっていないままで県道の指定が外れた場合などに、今までは属性として道路名を持っていたために異なる地物と判定していましたが、道路名などは外のテーブルに出すことで関連している属性だけが変わる形になるので、「名称が変わっても地物としては変わらない」という判定ができるようになったためです。

このような基準に沿って2014年から毎年1月のスナップショットをもとに10年分のリンクIDのデータを生成したところ、毎年少しずつリンク数が増えていることが確認され、近年は大きく数が変化することが少ないという傾向が見られました。

このほか、複数の道路リンクIDを束ねる「道路空間ID」の検討も行っています。現状は道路形状などを少し変更するだけで道路リンクIDが変更されてしまい、以前のIDがわからなくなってしまうという課題があるため、多少の変化があっても同じ道路区間を表しているのであればIDが変更されないように、概念的な道路区間を示す道路区間IDを導入することを検討しています。

道路リンクの変化パターンには、始終点ノードの座標の変化やIDの変化、ノードの追加・削除など「空間属性（トポロジーを含む）の変化」と、路線種別や路線番号、道路名の変化など「非空間属性の変化」の2種類があります。道路区間IDは、空間属性や非空間属性が多少変化しても変わることがなく、リンクが分割されて交差点ノードが追加されたり、交差点ノードが削除されて隣接するリンクと結合したりするような大きな変更の場合には新たにIDが生成される形にする予定です。また、始終点ノードの座標の変更やリンク長が変化する場合などについても、条件によっては変更されるようにすることを検討しています。

今後はUUID5を利用した道路リンクIDを持つデータに差し替えることに加えて、リンクに関連する道路属性についてはWayの属性とrelationの属性をマージして時系列データを整備する予定です。また、道路区間IDについては始点終点座標やリンク長などの属性から同一区間を判定するルールを決定し、道路リンクに区間IDとして付与する予定です。

アジア航測の徳田氏が、河川のベースレジストリ整備に関する取り組みを報告しました。この取り組みは、全国を網羅する公開可能な河川系の基盤データの構築を目的としたもので、国土数値情報の河川リンクとノードをもとに全国版の試作データを作成しています。

前回の研究会では、河川の始点と終点の位置が逆になっているリンクがいくつか見つかったため、リンクとノードのつながり具合から不具合を推定する方法を説明しましたが、この方法に基づいて全国版の試作データの修正を完了しました。修正したデータは公開用ウェブサイトに掲載し、インターネットを介して閲覧できる状態になっています。同サイトでは、河川名や河川コードから河川を検索できるほか、地図上で流路や河川端点を選択して属性情報を調べることもできます。

また、流下方向の不具合を修正する過程において、ある地点で分流が起こり、分かれた先の下流でまた合流することで囲われた領域を作るような特異な流路構成となった場合に、正しい評価ができないという新たな課題も見つかりました。解決策としては、上流側と下流側の両方がNGと判定されたものだけを抽出して修正作業を行って、その上でもう一度評価を行うことにしました。

もうひとつの課題として、ノードとリンクでデータの表記方法に不整合があり、ノード番号をキーにして双方を検索することができないという問題が見つかったため、今回は手作業で修正を行いました。

データの表記方法に不整合がある問題についてオリジナルの国土数値情報を調べてみたところ、ノード番号は河川の属性情報として定義されておらず、国土数値情報ダウンロードサイトでは地物の属性ではなく別項目の属性情報として説明されていることがわかりました。これは国土数値情報をShapeファイルとして公開する際に、利用者の利便性を考慮して付加された項目であると推測されます。ノード番号については製品仕様書や作業手順書に規定がなく、特段の附番ルールが存在しないために不整合が生じていると思われます。

河川ベースレジストリは水が上流から下流に流れるモデルの基盤となるデータであり、流下方向の取得は非常に重要ですが、流路リンクの位置正確度の問題からDEM（数値地形モデル）と国土数値情報の重ね合わせによる流下方向取得は難しいという課題があります。現在の国土数値情報の流下方向に関するデータは修正や更新が必須であり、これをどのように進めていくかは要検討となります。

東京大学 空間情報科学研究センターの趙氏が、航空画像をもとに建物フットプリントを取得し、その変化を検出して建物に付与したIDを維持しながら建物フットプリントを更新する技術の開発について発表しました。同プロジェクトは2025年度第3四半期には熊本県益城町において自動変化検出モデルの学習および精度検証に取り組み、第4四半期では益城町の広域において建物フットプリントの更新の実装に取り組む予定です。

前回は益城町における変化検出ラベリングの精査を行う上で、2016年と2023年の航空写真の位置のズレが大きいため、2020年と2023年のデータを用いてアノテーションを精査しました。現時点で全2401組の画像の精査が完了しています。

さらに、ピクセルレベルにおける変化検出精度を向上させる手法の検証も行いました。リモートセンシング画像を深層学習ネットワークに入力する際に、入力範囲の違いによって受容野が変化します。例えば1つの街全体を入力する場合は空間解像度が低くなり変化を判定しにくくなり、一棟の建物周辺のみを入力した場合は受容野が小さすぎて周辺文脈が見えず精度が下がってしまいます。そこで本研究では、512ピクセル（約200×200m）、 256ピクセル（約100×100m）、128ピクセル（約50×50m）の3種類の入力範囲における結果を比較しました。

続いて、データ拡張および超解像技術を用いることにより、現状は0.4mの空間解像度を、オープンソースの標準データセット（WHUデータセット）に近い0.15mのレベルまで向上させることも検討しました。具体的には、2時点の2401組の空中写真に対してATD、ESRGAN、SwinIR、SinIRの4種類の超解像技術を適用して、Change3Dアルゴリズムにおける変化検出精度を比較しました。この超解像処理により、元の解像度は4倍以上に向上し、画像の細部表現も改善されて、その結果、変化検出アルゴリズムの精度も向上しました。

これらの結果、ラベル品質および受容野の変化、超解像処理はいずれも変化検出の精度向上に寄与することが確認できました。その中でもラベル品質の向上は変化検出精度の改善に最も大きな効果をもたらします。変化検出のアノテーションを精査して超解像を適用した結果、検証精度は47％から84％に向上しました。また、可視化の結果においても、精査後のデータは精査前より良好な結果を示しています。

このほか、建物IDの維持を目的としたオブジェクトレベル変化検出と精度改善にも取り組みました。以前の実験では、ピクセルレベルで最も高い性能を示したデータを用いて大きな精度向上を達成したので、今回は最終的な実装を見据えてオブジェクトレベルでのアルゴリズムの学習を行いました。アルゴリズムにはYOLOv12を利用し、2時点の画像を6チャンネルデータとして連結して学習を行いました。

ピクセルレベルの評価ではピクセル単位で正誤を判定し、形状のつながりや個数を区別しないのに対して、オブジェクトレベルの評価では物体（インスタンス）ごとに検出の成否を評価し、1つ1つの建物を正しく分離できているかを重視するため、誤検出・未検出を厳密に評価できます。

現状の課題として、建物の変化検出は学習後に実現できたものの、依然として多くの誤検出や未検出が発生しているため、現在抽出された結果を基盤として、目視による誤検出や未検出の指摘を加えるPoint orientation技術を導入することにより、建物自動抽出の精度向上を図ることを検討しています。RGB画像だけでなく元の建物フットプリント検出結果と誤検出、未検出のポイント提示などにより検出効果を改善します。

ピクセルレベルではラベルの精査や受容野の影響分析、超解像技術などにより精度が46％から83％まで向上しました。一方、オブジェクトレベルでは精度が大きく低下しますが、Point orientation技術を導入することによりオブジェクトレベルの精度を大幅に向上させることができます。

今後は益城町および箕面市を対象として、既存の建物IDを維持した更新の実装実験および精度評価を行う予定です。現時点では箕面市の正射画像データおよび変化検出用のアノテーションが未整備のため、箕面市に関するデータ整備には一定の時間を要する見込みです。また、Point orientation技術を基盤としてデータアノテーション支援ツールも開発する予定です。

IPA DADCの田嶋氏が　空間IDを時空間情報に活用する取り組みについて発表しました。空間IDとは、3次元空間を直方格子状に分割した「空間ボクセル」に割り当てられる一意の識別子です。建物や樹木、気象などの情報は個別に各領域の標準となる方法で整備されていますが、それらを置き換えるのではなく空間IDを付与することで連携し、統一的に扱うことでシステムやロボットが利用しやすい形となり、さまざまな時空間情報の統合や検索を容易にするとともにデータ量を削減してエッジでの効率的な処理が可能となります。

3次元空間を分割する基準については、高さの基準面はジオイド、測地系はWGS84（JGD2024対応）を採用し、水平分割はウェブメルカトルと同様にズームレベルが1つ増えるごとに4分割にして、垂直分割はズームレベルが1つ増えるごとに2分割します。地球全体をズームレベル0として1つ増えるごとに8分割することを繰り返し、IDはズームレベルと標高、経度、緯度の各要素をスラッシュで連結します。

空間IDはあらゆる空間に付与されており、ユースケースに合わせて空間ボクセルのサイズ（ズームレベル）を設定します。例えば霞ヶ関ビルディングの建物全体は「18/1/232832/103235」「18/1/232833/103235」「18/0/232832/103235」「18/0/232833/103235」 の4つに収まります。この場合のズームレベルは18（ボクセルサイズは約124m）ですが、ズームレベル20（ボクセルサイズは約32m）と小さいサイズのボクセルを使ってドローンなどで利用する場合は、例えばビルの36階の会議室周辺を「20/4/931331/412940」というIDで表現できます。

空間IDの普及に向けた取り組みとしては、4次元時空間情報の利活用のためのガイドラインを公開しているほか、空間IDに関連した情報の集約サイトを公開しています。また、GitHubにて関連するライブラリやAPI仕様も公開しており、ドローン向けAPIやPython・JavaScript用ライブラリ、実証成果も公開しています。

実装に関わる検討として、実装する際にどのように使用するかいくつか例を公開しています。データの紐付けの例としては、以下の4パターンが考えられます。
（1）空間ボクセルと地物や事象が1:1で紐付けられる場合（例：空間ボクセルごとに集計された統計メッシュデータ）
（2）空間ボクセルと地物や事象が1:多で紐付けられる場合（例：IoTセンサー情報のポイントデータ）
（3）空間ボクセルと地物や事象が多:1で紐付けられる場合（例：河川のラインデータ）
（4）空間ボクセルと地物や事象が多:多で紐付けられる場合（例：地物のポリゴンデータ）

空間IDを活用することにより、上記のような様々な組み合わせを地物や事象に応じて活用できます。

空間IDは、2次元的にはウェブメルカトルやSlippy map tilenamesと同じ仕様なので2次元の高さ方向の情報を省略することで2次元のID形式と互換で使うことができます。また、空間IDを時間に応じて変化・移動する情報にも適用できるようにすることも検討しており、空間IDの後ろにアンダースコアで時間IDを結合した形式となっています。

また、建物など任意のローカル座標空間において空間ボクセルに付与された空間IDを「ローカル空間ID」と定義しています。ローカル空間IDは細かいズームレベルを使いたい場合に適しており、地球上の位置に基づく座標系ではない任意の原点や距離単位が定義された座標空間となります。

このほか、共通性の高い機能として想定される「ジオメトリと空間IDの変換」をライブラリとして整備しており、さまざまなユースケースでの実装を想定してオープンソースソフトウェア（OSS）として提供しています。

2022年度～2023年度にかけて行われた空間IDの実証では、防災領域において空間IDを用いて空間情報の統合や災害情報の3次元可視化を行ったほか、地下埋設物情報を空間IDに紐付けて紹介業務やマシンガイダンスに活用する実証や、空間IDに紐付けて整備したデータを配送ロボットやARナビサービスで共有する実証などを行いました。また、国立研究開発法人 新エネルギー・産業技術総合開発機構（NEDO）による産業DXのためのデジタルインフラ整備事業「3次元空間情報基盤に係る研究開発」では、各実証において空間IDを活用したシステムや基盤を構築し、各ユースケースでの有効性を評価しました。

さらに「デジタルライフライン全国総合計画」のアーリーハーベストプロジェクト「ドローン航路」および「自動運転サービス支援道」「インフラ管理DX」では、空間情報を扱う場合の標準識別子として空間IDの適用を検討しています。

空間IDは、3D都市モデルの可視化ツール「PLATEAU VIEW 4.0」においてGUI上で空間IDを選択・可視化する機能が追加されたり、高松市の地理空間データ連携基盤において空間IDが利用されたりと、様々な分野において活用が広がっており、内閣府が公開するスマートシティ・リファレンスアーキテクチャ別冊「地理空間データ連携基盤」にも連携技術として空間IDが記載されています。

IPA DADCとしては、空間IDを共通識別子として位置付けることにより、さまざまな情報の結合を容易に行える仕組みを作ることで多種多様な情報の流通やビジネスの拡大につなげていきたいと考えています。空間IDを色々なベースレジストリと連携するするための識別子として活用することを目指しており、空間IDとの連携に向けたツールの整備に取り組んでいます。

AIGIDの理事を務める建設技術研究所の藤津氏が、AIGIDが開発したインフラベースレジストリのツールをオンライン電子納品システム「My City Construction（MCC）」に実装したことについて発表しました。MCCは自治体向けのオンライン電子納品サービスで、工事の施工者などが工事情報と成果品を登録した上で発注者に承認申請を通知し、問題がなければ承認が行われます。登録後は保管管理サービスとして成果品を閲覧することもできます。2025年12月現在、約6,800件の案件がMCCに登録されており、試行利用中の自治体を含めるとこれまで21自治体がMCCを利用しています。

MCCではこれまで登録された成果品について工事名などで検索する仕組みがありましたが、対象とする工事名などがわからないとピンポイントに必要な成果品を見つけられないという課題がありました。この原因としては、工事や設計の成果品データは必ずしも施設データベース（台帳）と紐付いていないため、施設に紐付けて検索することができなかったことが挙げられます。

そこで、施設に関連する成果品を網羅的に抽出できるようにするために、インフラベースレジストリのツールを利用して施設と工事・業務の成果を紐付けることにしました。手順としては、MCCの成果品の登録情報から施設の種類や名称、管理者（発注者）、施設の位置などの情報を抽出した上で、全国道路施設点検データベース（Xroad）の施設一覧に対して管理者・位置・名称の一致度合いから関連する施設を抽出しました。抽出する際は、管理者が合致する施設のうち名称の一致や位置精度などにより関連度を「大」「中」「小」「参考」の4つで評価し、成果品と施設を紐付けて検索できるようにしました。

これにより、工事の基本情報を登録すると同時に場所情報や概要などの記載内容から自動的に施設名が付与されるようになり、施設情報を検索する際には数十年前の設計業務や工事の案件を関連度とともに簡単に検索できるようになりました。さらに、施設名をクリックするとxroadの施設DBとAPI連携により取得した諸元などの情報を掲載することもできます。

今回の取り組みでは、インフラベースレジストリとのAPI連携により、とくに問題なくMCC側に施設情報を自動で付与することができました。2025年12月8日時点で11,314件の案件に施設名が自動付与されています。

インフラベースレジストリとのAPI連携に関する要望としては、施設名の完全一致オプションが欲しい点と、現状では検索結果がどの順番で表示されているか不明なため、名前順や距離順などソートに関する条件も設定できるようにして欲しいと考えています。

話題提供に続いて、副座長を務める駒澤大学文学部地理学科・准教授（東京大学CSIS特任准教授）の瀬戸寿一氏が進行役となり、質疑応答および議論が行われました。このときの議論では、参加者からは以下のような質問や意見が寄せられました。

・「（インフラベースレジストリにおいて道路の位置が全体的にずれて道路リンクが変化した場合の対応について）DRM（日本デジタル道路地図協会）のデータベースではノードを削らないようにしてデータの変更を最小限に抑制しています」
→（相良氏による回答）「ノードを残す方法があれば残したいのですが、DRMの場合は人の手で処理しているのに対して、OSMの場合はデータを編集する人がそれぞれ異なり、データ生成も自動で行っているので、何らかのルールを決めて一括で行うしかないと考えています」

・「河川ベースレジストリの資料において、河川名が地元の呼び方と不整合がある場合は表記の仕方が難しい」
→（徳田氏による回答）「河川名には課題が多く、日本語の表記を標準化するのは極めて難しいので、河川を特定する用途では河川構造や流路のIDを標準仕様として使っていく方法にしないと難しいと思っています」

・「ISO 24108-1（メッシュ統計の基本原則）において、メッシュコードは標準地域メッシュを統計目的として世界レベルで整備する動きがありますが、国際標準についての考えをお聞かせください」
→（田嶋氏による回答）「標準地域メッシュの拡張については識者と意見交換していて、統計や分析は標準地域メッシュを利用し、3Dの識別子で時間も含む場合は空間IDを使う方向で考えています。標準地域メッシュは色々なパターンで分割することがありますが、空間IDはウェブメルカトルと同様に完全に整合された親子関係があり、グローバルに一意です。現在、極地をどうするかということも含めてグローバルな検討を進めており、意見交換しながらバッティングしないように守備範囲やお互いのメリットを整理しながら検討しています」

・「空間IDを割り振るインセンティブをどのように考えますか？　検索が速くなる可能性があるとか、色々あるとは思いますが、今後どのように啓蒙活動を行っていくか戦略をお聞かせください」
→（田嶋氏による回答）「まさにそこが一番の課題と考えており、色々な情報を空間IDで検索できれば皆さんが使うようになるし、逆にすごいユースケースがあれば皆さんが付与するようになるので、どちらが先かというのはまだ明確な解がないという状況です。当面は活用しやすくしたり、導入を迷っている人に情報発信したり、ツールを提供したりすることを進めていきたいと思います」