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

2025/05/02

2025年3月25日（火）、第12回「地理空間情報に関するベースレジストリ利活用研究会」をオンラインにて開催し、委員とオブザーバーあわせて約40名の委員が参加しました。今回はAIGIDの取り組みとして「総合的な WebAPIサービスのプロタイプ」および「オープンデータを用いた道路ID等のベースレジストリの研究開発」「河川系ベースレジストリ データ作成のための検討」について報告するとともに、3人の識者による話題提供が行われました。

情報試作室開発室の相良氏が、オープンデータを用いた道路や河川、道路関連施設などインフラ関連の総合的なベースレジストリのプロトタイプを開発する取り組みについて発表しました。

この取り組みは、もともとは道路のベースレジストリの一つとなるように開発していたシステムにを基礎に、AIGIDで取り組んできた河川や道路関連施設などの基礎データも取り込んで、「インフラベースレジストリ」として1つのシステムに統合を目指したものです。これらのデータをさまざまな分野で広く共有できるようにすることを目的に、研究開発を行っています。

インフラのベースレジストリが必要な理由は、複数のデータを連携させる上で同一性を保証するためです。例えば名称だけで「春日通りの一部で交通規制」という情報があったとしても、果たしてそれがどの場所を指すのかを特定することは難しく、画像だけを渡されても本当に同じものを指しているのかわからないので、何らかの識別子を使って同じものであることを保証する必要があります。

道路のベースレジストリは、全国を網羅する公開可能な道路基盤データを研究用に構築することを目的としており、都道府県道以上を「骨格道路」として全国整備、市区町村道およびその他の道路を「詳細道路」として地域別に整備するとともに、時系列を持つ道路データの管理手法の開発も目指しています。今年度はOSM（OpenStreetMap）のデータをもとにノードおよびリンクのIDと、その時系列管理方式を確立し、定期的に骨格道路データを更新し、配信するサービスを開発しました。

公開予定のシステムは認証設定をかけて対象を限定して公開しており、道路・河川の流路・道路関連施設を検索可能で、道路（リンク・ノード）は日付を指定して検索可能することもできます。提供予定データのフォーマットはGeoJSONLおよびgzipで、道路ノードの容量は約28.3MB（2025年3月時点）、道路リンクは約906.5MB（2025年3月時点）、道路関連施設は約31.4MB（全国道路施設点検データベースの基礎データベース）、流路は約5.7MB（国土数値情報「河道中心線」四国のみ）です。

同システムの機能としては、道路については近傍検索やノード名による検索、名称および座標での検索、識別子による詳細取得、流路の空間範囲検索や河川名による検索、道路関連施設については空間範囲検索や種別および属性（市区町村）検索、種別・属性（施設）による検索、データダウンロードなどの機能を備えています。WebAPIとしても提供予定で、WebAPIではContent-Typeを指定することで検索および情報取得をGeoJSONで返します。

アジア航測の徳田氏が、河川のベースレジストリ整備に関する取り組みを報告しました。この取り組みは、全国を網羅する公開可能な河川系の基盤データを構築することを目的としたもので、今年度は利用可能な元データの選定や加工上の課題の検討を行った上で試作データを作成するとともに、河川ベースレジストリのユースケースおよびそれらを想定したデータ仕様やデータ配信方法を検討しました。

具体的には、国土数値情報（河川）をもとに四国全域を対象に試作データを作成し、ユースケースを想定して属性項目を付加しました。さらに、前述したインフラベースレジストリの配信サービスのシステムに試作データを掲載し、属性に基づく検索および抽出データのダウンロードを行えるようにしました。

試作データに使用したのは国土数値情報（河川）の河道中心線リンク（ライン）および河川流路端点ノード（合流点、分岐点ポイント）で、流路（リンク）の基本属性項目には6桁の水系域コードや10桁の河川コード、河川名、区間種別、原典資料、流下方向判定、河川始点／終点、流路始点／端点などが含まれます。河川流路端点（ノード）には6桁の水系域コード、標高、河川端点IDが含まれます。

ユースケースを想定した追加属性としては、流路始点／終点の標高（流路始点／終点ノードから取得）、始点と終点の標高差、下流リンク名（当該流路リンクの流路終点が流路始点となる流路リンクのリンクID）などの属性項目を付加しました。

ユースケースについては、「データ公開用のウェブサイトから河川名や水系名等をキーに必要な河川の流路データを検索してGIS上で確認する」、「水系単位でデータをダウンロードしてGISソフトウェアで読み込んで『落差、下流側リンク情報』を用いて主題図を作成する」といった使い方のほか、他データと組み合わせることで流況分析や水力発電賦存料の算定、河川施設の管理などにも活用できます。

今後の課題としては、国土数値情報において「不明」とされているデータを修正する必要があることや、一部流下方向が逆向きになっている場合があることなど不具合を解消する必要があることが挙げられます。また、今後も国土数値情報をベースとする場合に、データ更新の方法やコストについて、それを管轄する国土交通省地理空間情報課と連携する必要があることも挙げられます。さらに、今回はデータをダウンロードして汎用GISソフトウェアで活用することを提案しましたが、今後はユースケースを考慮してSaaS化することも検討する方針です。

国立情報学研究所の北本氏が、時間軸を延伸した基盤データとして「歴史的ベースレジストリ」を構築する取り組みについて紹介しました。

北本氏は、現代の地理情報は多くの産業における基盤技術として整備されている一方で、過去の地理情報についてはデータの整備が不十分で既存のツールが使えないという点に課題を感じており、歴史研究においては地理情報の整理（マッピング）に多大な労力が費やされているとためDXを推進するべきだと考えています。

そこで北本氏が取り組んでいるのが、歴史ビッグデータの統合解析です。これは歴史的資料に含まれる気候・地震・噴火・疫病などの自然科学的データや、経済・人口・政治・文化などの人文社会的データを構造化して「歴史的ベースレジストリ」として機械可読データにすることにより、現代のビッグデータと同じように過去も解析できるようにする取り組みです。

歴史的ベースレジストリは、現代のベースレジストリから時間軸を過去の方向へ延伸させることにより、ベースレジストリに時間軸を持たせることを目指しています。方法としては、過去の地理情報に永続的なIDを付与し、IDに紐付くデータをオープン化した上で、関連データをリンクして利便性を向上させます。また、基盤データを活用したソフトウェアも開発することでデータの活用を促進します。

このような試みのひとつとして、国土数値情報と複数のオープンデータを統合した「歴史的行政区域データセットβ版」を提供しています。このデータセットには全国地方公共団体コードが付与されていますが、1968年以降しか付与されていないため、このIDを過去に延伸させてユニークなIDを付けることを目指しています。国土数値情報にも市区町村の境界データがありますが、これも1920年までしか存在せず、しかも1920年から1950年までの30年間が抜けており、その間に生まれて消えた市区町村などの要素がありません。これらのデータを補って明治まで遡りたいと考えています。

例えば東京都の場合は東京都特別区部（23区）から東京東京市（35区）、東京府東京市（15区）へと遡っていくところにIDを付与する場合、現状において1920年までのデータを整備した結果としては、市区町村コードがあるものが4,159件、国土数値情報から拾えるものが12,273件、行政界変遷DBから取得できるものが424件で、合計16,856件が登録されています。しかし1919年から1889年（市制及町村制）までは遡ることができず、明治時代（1888年以前）から江戸時代への遡及も困難です。

このような状況において、平凡社地図出版とのコラボレーションにより「日本歴史地名体系」をオープン化することができました。これには江戸時代の村まで遡れる80,502件の地名データが収録されており、位置情報を加えてCC-BYライセンスで公開しました。この取り組みは、出版社が保有するデータを学術的な利用も含めてオープンにできる部分とクローズドにする部分を分けて、オープンにできるものを公開したということで大きな反響がありました。有料サービス「ジャパンナレッジ」のIDや基本的な地名、読み方、位置情報などの書き手に依存しない情報はオープンデータとして公開し、書き手に依存するデータはクローズドデータとしてジャパンナレッジで提供しています。

江戸時代の村に関するデータとしては、このほかに「日本歴史地名体系」のPOIデータや幕末期近世村領域データ、天保郷帳翻刻データなどのデータも今後の公開を予定しており、このようなデータをもとに現代から江戸につながる基盤データを整備する取り組みを進めています。

ほかにも平凡社地図出版と連携して江戸時代の海岸線データなどの地理データも作成中であり、近日公開を予定しています（注：4月4日に公開しました）。

このほか、人間文化研究機構・H-GIS研究会が公開する「歴史地名データ」を活用した「歴史地名マップ」や、29枚の古地図「江戸切絵図」から8,739カ所の地名を抽出してデータベース化した「江戸マップβ版」などの整備も進めています。これらの地図はジオリファレンスして現在の地図と位置合わせを行っています。

また、株式会社MIERUNEが公開している現代風デザインの歴史マップ「れきちず」と連携して、江戸切絵図の町家領域を抽出して人口密集地域を可視化する取り組みも進めました。このデータはポリゴンをGIS形式でダウンロードできます。また、「れきちず」を背景地図として、江戸の商店の分布を可視化したマップや、旅日記をもとにした旅ルートなども公開しています。

このように整備したデータを活用するためのソフトウェアとして、テキストから地名を抽出して地図化するOSS「GeoNLP」や、住所を緯度・経度に変換する「jageocoder」、地名に統一的な識別子を付与して検索できるウェブサイト「GeoLOD」などがあり、これらのソフトウェアも活用しながらIDを用いたデータ統合の取り組みを進めています。

また、このようなプロジェクトに関連する新しい動きとして、DiHuCo（DHコンソーシアム）という事業が始まりました。ROIS-DS人文学オープンデータ共同利用センター（CODH）はこのコンソーシアムに連携機関として参加し、「地図・地誌類領域」を担当することになっており、過去の地理情報の知識基盤化や人文学分野におけるAIユースケース創出などに取り組みます。

国土交通省の片田氏が、同省が整備に向けた検討を進めている「不動産ID」について紹介しました。不動産IDとは、不動産関連の情報連携を進める際に住所などの表記ゆれが支障となるため、不動産それぞれにIDを付与して連携キーとして用いることにより、各不動産情報の名寄せや連携をスムーズに行えるようにする取り組みです。不動産IDを活用することにより、不動産取引における物件調査だけでなく、空き家調査や災害時の被害状況把握など不動産以外の分野でも効率化が期待できます。

2022年3月に行われた「不動産IDルール検討会」中間取りまとめの時点では、不動産IDは不動産登記簿の不動産番号（13桁）を基本として、これだけでは対象不動産を特定できない場合にも対応できるように「特定番号」（4桁）を加えた17桁の番号とすることを検討していました。特定番号の4桁は集合住宅の部屋番号だけでなく、商業施設の階数を表すのにも使うことができます。

2023年度に、以上のルールに基づいて不動産IDを建物・土地に付番し、業務の効率化を図れるかどうか実証事業を実施したところ、いくつかの課題が明らかになりました。課題の1つは、建物の不動産IDを付ける際に、正確に建物を特定できない場合があることです。例えば一筆の土地に複数の建物が存在する場合は、対象の建物と登記を正確に結びつけることができず、建物IDの正確性を担保できません。登記所に登録されている建物の敷地図面を見れば正確に建物を特定することはできますが、紙で管理されているためデータの入手は困難です。

このほか、「公営住宅など未登記物件も建物IDの対象にしてほしい」「新築・除却など日々変動する不動産の状況をリアルタイムで反映してほしい」「不動産IDの検索時に入力する住所に揺れを含んでいても検索できるようにしてほしい」といった要望も寄せられました。

このような課題に対応するため、現在は登記所のデータを使うことから方向転換して、日本郵便株式会社が保有する住所・建物のデータをもとにIDを作ることを検討しています。日本郵便は日々の配達業務を通じて新築や除却の情報を収集しているために情報のリアルタイム性が高く、前述した課題にも対応できると考えています。ただし、住所をもとに不動産IDを作る場合、1つの住所に複数の建物があるケースがあり、その場合の区別をすることが課題となります。

今後の方針としては、まずは1つの住所に1つの建物がある場合はシンプルに住所とIDを提供すれば建物の特定が可能となるので、これをしっかりと整備していく予定で、2027年度の試験運用開始を目指しています。1住所に複数の建物がある場合は、建物IDおよび住所に加えて、位置情報などの複数建物を区別するための情報の付加が必要となります。なお、日本郵便からデータを受領するのにあたっての法令上の整理については、個人情報保護法および郵便法いずれも問題がないことを確認しています。

現在、国土交通省は日本郵便から提供を受けた配達データを使って、19都市を対象として「不動産ID提供システム（試作版）」を開発し、2025年1月末から年度末まで不動産ID官民連携協議会員に提供しており、住所の網羅性の検証を行っています。この結果、約9割は正しい住所が返ってくることが確認できています。この精度は今後もう少し向上する見込みで、登記データを使った場合よりも網羅性が上がることが期待できます。

国土交通省の内山氏が、同省が取り組む「ProjectLINKS」および開発中のデータ構築基盤「LINKS Veda」について紹介しました。ProjectLINKSとは、国土交通省の分野横断的なDX推進プロジェクトで、さまざまな行政情報をデータとして再構築し、活用できるようにすることでEBPM（データに基づく政策立案の推進）や新たなビジネスの創出（オープン・イノベーション）を目指す取り組みです。

行政文書は支局によって様式が統一されておらず、手書きで補完されている部分や押印もあり、単純なOCRやRPAでは規格化されたデータ抽出ができません。そこでProjectLINKSでは、データ構築基盤「LINKS Veda」を開発しました。LINKS Vedaは、LLM（大規模言語モデル）を使って自然言語を解析し、非構造データから意味情報を抽出して指定されたカラムに格納することにより、テーブルなどに構造化されたデータを自動生成するシステムです。同システムにより、国土交通省が保有する膨大な行政情報を低コストでデータ化して、誰もが探索可能なデータアクセス基盤を実現できます。

LINKS Vedaでは、データ入力や抽出、クレンジング、名寄せなどの正規化処理、他データとの結合やジオコーディングなどの加工処理、CSV出力など、データ活用に必要な処理を一元的かつノーコードで提供できます。厳格なアクセス制御や監査ログ、リアルタイムログ収集によるシステムの安全性を確保し、セキュアな基盤を提供しています。

AI技術はAWS Bedrock APIのClaude3.5 Sonnetを非構造データの構造データ化やチャット機能における回答生成処理に活用しているほか、Amazon Titan Text Embedding v1をチャット機能における文章の数値ベクトル表現変換に活用しています。また、Azure AI Vision APIのAzure AI Document Intelligenceを、データ構造化処理においてOCR処理に活用しています。データ構造化プロセスでは自動処理と手動処理を組み合わせたバリデーションを行い、ハルシネーションなどの不正を検知した場合は再生成してデータを修正する仕組みになっています。

データの構造化は、事前にスキーマ構成を定義したテンプレートを活用することで、ユーザーは何度でも同じ構成で簡単にデータ構造化を実行できます。結合前処理についても、対象のカラムと条件を指定するだけで、クレンジングやジオコーディングなどの正規化処理をワンクリックで実行できます。テキストマッチングについても、結合するデータのそれぞれの結合キーと結合後に残すカラムを指定することにより、結合テーブルを作成できます。

クロス集計についても、集計単位と集計対象を指定するだけで、指定した値が数値型の場合は合計・平均、テキスト型の場合はカウントで集計が可能で、地図データでも同様に空間集計を行えます。また、空間結合のGISツールを使わずに結合方式（交差／最近傍）や条件を指定するだけで地図データの結合処理が可能です。

LINKS Vedaでは、BIツールや分析ツール、可視化ツール、シミュレーションツールといったアプリケーションを「LINKS EBPM Tools」として提供しています。生成したデータを政策立案に活用するアプリケーション層を含めた一気通貫のソリューションを提供しており、例えばモーダルシフトの政策担当部局と連携した政策立案業務の効率化システム「LINKS EFTR」や、無人航空機の安全運航に関する施策立案業務の効率化システム「LINKS FLIP」などを開発しています。ほかにも今年度は観光やドローン、旅客船、空き家、倉庫、公共交通などさまざまな部局と連携して開発を行っています。

同システムはオープンソースとしてGitHubにて公開予定で、庁内での業務システムとして運用開始することを目指して、来年度も継続して開発していく予定です。

以上のような話題提供に対して、以下のような意見交換や質疑応答がありました。

【歴史的ベースレジストリについて】
質問：「国土数値情報をもとにした過去の市区町村IDコードは、どのような形で付けられているのでしょうか？」
回答：「IDの種類はいくつかあります。全国地方公共団体コードをソースとした場合は、それを示す“A”というコードと当該の市区町村が始まった年を示す4桁の番号をつけています。。国土数値情報の場合は“B”を付けて、その後に郡などを意味するコードを付けてユニークなIDを作っています。そして行政界変遷DBをソースとするものは“C”を付けて全体にユニークなIDにしています。データソースが増えたら“D”“E”と付与していきますが、最終的にはもう1回振り直してきれいなIDにしたいと思っています」（北本氏）

質問：「日本歴史地名体系のPOIデータ約8万件をオープンデータ化に向けて作業中とありますが、どのようなものを想定していますか？」
回答：「地名以外の城や遺跡、寺院など歴史的な史跡や建造物を公開予定です。すでにジャパンナレッジに掲載する段階でIDを付与しているので、これを流用しようと考えています。一方、日本歴史地名体系には位置情報が入っていないため、独自に位置情報を付与する必要がありますが、遺跡については奈良文化財研究所のデータを使うなど、既存の情報を活用することも検討しています」（北本氏）

【不動産IDについて】
質問：「デジタル庁ではアドレス・ベースレジストリの検討・実装が進んでいますが、住所表記が正規化できた場合は住所表記テキストが一意になるので、これに緯度・経度を加えれば不動産IDが無くても運用できるのではないでしょうか？」
回答：「確かに住所と位置情報があればIDの代わりに使えるとは思いますが、例えば『部屋番号をどのように拾うのか』『住所が変わってしまう場合はどうすればいいか』という問題があります。また、1つの建物に複数の住所がある場合も考えられるので、IDがあるともっと便利になると思いますし、アドレス・ベースレジストリと連携することで住所の課題も解決できると考えています」（片田氏）

質問：「不動産IDを付与する対象として、空き家や納屋などは対象となりますか？」
回答：「郵便のデータを使うということで、基本的には配達をしているかどうかがポイントになります。人が住んでいない家でも、以前は配っていたという記録があれば対象になると思いますが、納屋などは配達していない可能性が高いので、ローンチの段階では含まれないことになると思います」（片田氏）

【Project LINKSについて】
意見：「LINKS EBPM Toolsのようなサービスが実用化すると、個別に文書を発行していた業務の集約DB化が進むのでDX進行上のエポックになりそうですね」

質問：「過去の行政データについて、どこまで遡って構造化して再デジタル化するのでしょうか？」
回答：「書類が残ってさえいればデジタル化は進めていく方針で、技術的には無限に過去へ遡れるようには作っていますが、手書き文書をデジタル化するのには限界があるし、様式の変更も多いので難しい面もあります」（内山氏）

意見：「林野庁では令和7年度事業において、平野部も含め日本全国に平面直角座標系を由来とする20mメッシュを生成し、森林地域である場合にはその情報を付与するという取り組みを始めます。森林地域でないメッシュについても固有IDを入れる予定で、全て来年度中にオープンデータにする予定なので、他の政策地域でも使い途があれば使ってください」