アドレスってなんだ。どうしたいんだ。
日本の住所の話が盛り上がっています。誰もが、この住所なんて読むんだろうと思ったり、不思議な住所に出会ったことがあると思います。また、誰もが指摘するのが京都の住所の難解さです。
住所の専門家ではないのですが、なんだかんだ長い間関わってきたので、これまでの流れを整理してみました。
住所ってなんだ、アドレスってなんだ
そもそも住所という言葉からつまずいてしまいます。
住所とは正確に言うと「読んで字のごとく”人の住む所”であり、それ以外の土地の位置は所在、所在地という言葉を使うべきである」という人がいます。
「でも、汎用的に住所って会社や施設でも使っていますよね」といっても、それは違うと言い張ったりします。
会社法に以下の条項があるから、会社の住所ってありだと思うんですよね。
会社法
（住所）
第四条 会社の住所は、その本店の所在地にあるものとする。
何とも味わい深い一文ですが、ともかく「会社の住所」というのは法的に間違いないですね。
でも、こんなところで躓いていても時間の無駄ですので、他の言い方を考えてみました。しかし、「住所・所在地」や「住所・地番」といちいち使うのがめんどくさいですよね。そこで、アドレスとまとめて呼んだりしています。
カタカナを容易に使うなという人は多いですが、そんなこと言っても日本語で合意できないなら仕方がないです。
とはいえ話すときには、ひっくるめて住所ということが多いです。
ちなみに住居表示に関する法律という法律がありますが、「住所」の定義はされていません。
日本の住所や、関連した土地管理の問題
土地に関してはデジタル化以前に様々な課題があります。詳しくは専門家に聞いてほしいのですが、ここでも様々な課題を簡単に説明します。
住居表示と地番の存在
住居表示とは、市町村が定めた住所で、配送や各種手続きなどで普段の生活でよく使われています。一方、地番とは、土地一筆ごとにユニークにつけられた番号で法務省が管理しているもので、主に不動産取引に使われています。（筆とは土地の区画のことで、土地取引をするときに使われます）
この住居表示の区画と筆の区画が1対１対応していないことが管理を複雑にしています。1つの住居表示に複数の筆があったり、複数の住居表示が1つの筆の中にあったりします。
1つの住居表示に複数の筆というのは、複数の土地をまとめてビルを建てたときなどに起こります。また、複数の住居表示が1つの筆というのは、大地主が自分の土地に複数の貸家を作った時などに起こります。
また、枝番を振るケースがあるなどの課題も指摘されている。
飛び地の存在
市などの行政の区切りを飛び越して、島のように他の行政区域内に住所がつながっている問題です。
行政サービスをどのように提供するかなどの問題が発生したりします。
境界未確定の土地の存在
隣地との境界が未確定な土地があります。境界を確定させるために地籍調査が行われています。
しかし、土地の境界といっても地面に線がひかれているわけではなく、双方の合意が必要なことから、長年、地道に時間をかけて取り組まれてきています。
住所表記ゆれの存在
今回問題になっている課題です。
住所は、１丁目を漢数字で一丁目と書いたりハイフンでつないだり、同じ住所を表記するのに複数の表記方法がとられています。曖昧処理が得意な人間の場合は一目で理解できますが、厳密に照合を行うコンピュータには処理しにくい問題です。
そもそも、町字といわれる町名などの書き方自体が揺らいでいる場合があります。「霞が関」のような「が」なのか「ヶ」なのか「ケ」なのか、省略可能な地名もあり、接続の文字で揺れる場合があります。
さらに、難しい地名だと、簡易表記した文字により揺らぐ場合もあります。
ヨミガナ、ローマ字、英字表記の揺れの存在
地名のヨミの揺れも各地に存在します。「いばらき」なのか「いばらぎ」なのかという濁音の問題が代表的な揺れです。また、太田が「OTA」なのか「OOTA」なのかといった長音つづりの揺れの問題があります。日本橋の表記にNiho”mb"ashiと書くかNiho”nb"ashiのように発音しやすさによる表記ゆれもありますし、Nihon-bashiと言葉区切による揺らぎもあります。
また、地名表記でGakkou-maeとローマ字で書いてあったり、Schoolと英語で書いてあるといったローマ字表記と英語表記の揺れもあります。
東京駅では、Tokyoの書き方がJR東日本とJR東海で異なるという表記ルールによる揺れもあります。
なぜ今、問題になっているのか
そんなに課題があるのに対策は考えられてこなかったのかという指摘はよく言われます。土地の本質的な観点もありますが、ここではデジタルという視点での取り組みを説明をします。本質的な観点は土地の専門家の論議に任せましょう。
デジタル化の観点からは、２つの大きな論点があります。テキストデータと土地の形状データの問題です。
まず、これらの問題が解決に進んでこなかった理由は、人間が扱うことが多かったので問題が発生しにくかったし、曖昧処理できたことが大きいです。
手書きであれば、住所の「ヶ」「ケ」の大きさの違いも気にしないし「が」であっても問題なく処理してしまいます。
ワープロで作成する時代になっても、それを受け取った人が目視で処理しているうちは多少の揺らぎは人が吸収できます。
デジタル処理の進展
それが、デジタルデータで自動処理しようとすると大きな問題が発生します。1丁目、１丁目、一丁目、壱丁目、１、1は、全て違うデータであり自動照合できません。
また、住所の付番ルールが全国一律ではなく、「１，２，３，・・・」の代わりに「イロハ・・・」を使っていたりするところも存在します。
全国に特殊なケースがあるために、多くの情報処理関係者がデータの整理に苦労してきたわけです。
形状データも同様です。紙で管理されていた時代は、縮尺の違う図面が混在する中でその形状を目視で確認していたので曖昧処理できましたが、デジタル処理の場合にはその形状をデータ間で照合するので、図面の精度も含めて確認しないと一致しているかの判断が難しいのです。
解決に向けた2つのアプローチ
課題の解決に向けては段階的なアプローチがとられてきました。第一にデータの構造化をしっかり行い、次のステップで、そこで使う正確なデータの管理を行います。
データ構造化
データ構造化とは、住所を、「都道府県」「市区町村」「町字」等、バラバラな部品に分けて管理する方法です。部品に分けることで、各部品ごとに検証したりすることができます。（※町字とは、市区町村の下の地域区分）
わかりやすいのはショッピングサイトです。行政機関の各種手続きでは、郵便番号、住所、建物名を1つの記入欄に書くことが多いですが、ネットサービスは、ほぼすべてのサイトで、郵便番号、住所（都道府県や市区町村が独立項目）、建物名で分離した記述欄が用意されています。
こうすることで、住所の書き間違いを防いだり、処理をしやすくしています。
特に建物名を住所から切り離すことは重要です。そうすることで、住所が単独で検証や処理できるようになります。
（建物名は行政データではよく「方書」といわれます。昔、下宿していて「○○様方」と書いていたころの名残です。）
しかし、集合住宅に住んでいる場合、建物記入欄ではなく、住所欄に「-101」のようにつなげて書くこともあります。「-A101」など様々なバラエティが存在する場合もあり、こう記述すると何処までが住所なのか切り分けるのが非常に難しくなります。
さらに、ショッピングモールの場合、２Fとまで書けますが、部屋番号がない場合もあります。
このような、住所を正確に表す方法として住所データ構造化の取り組みが行われています。
このデータ構造化の取り組みは、住所にだけ必要なものではなく社会活動に必要な様々なものに必要なことから、政府相互運用性フレームワークとして政府全体で推進が行われています。
オーサライズされた正確なデータの管理
住所データを構造化すると様々な検証ができるようになります。都道府県等は記述しないで選択式にして入力間違いを防止したり、市や町字の名前が実在するか検証したりすることもできます。
今までは、郵送による送達することで実在確認をすることができましたが、ネット取引が増える中で住所データだけで実在の検証する仕組みが必要になってきます。
この検証可能なデータというものは、最新性と最新性が保証されるとともに、きちんと管理、検証されたものでなければいけません。世界では、公的機関により検証され、オーサライズされたデータをベース・レジストリと呼んで管理しています。
個人、法人、土地と様々なものがベースレジストリとして整備されますが、最も最初に整備し、投資対効果の高いものが住所を管理するアドレス・ベース・レジストリといわれています。
このベース・レジストリは、多様な目的に使えるように設計されており、構造化したデータモデルを使って整備されます。
住所って国全体で管理されていたのではないのですか？
日頃から住所や地図で地名を見ているので、誰かがきちんと管理しているのではないかと思っていたのではないでしょうか。
確かに、国土地理院は地図とともに住所だけではなく、山や沢の名前まで広く収集・管理しています。また総務省統計局でも国勢調査などの統計のために町字情報を持っています。また、郵便番号を使ったらよいのではないか、民間情報を使えばよいのではないかという意見もあります。
しかし、正確で最新の住所、形状、緯度経度、ヨミガナ、英字表記を一元的に管理しているところがありませんでした。また、これらの情報には変更履歴データも必要になります。
では誰がそれらの情報を持っているかというと市区町村です。区画整理や埋め立てを行うときでも、必ず市区町村で初期データの作成、若しくは、届け出が行われます。そして住居表示台帳が整備されていて、必要に応じてヨミガナなども整理されます。
このような住所データを一元的に集める仕組みがありませんでした。
よく、国で集めるとか仕事を増やさないでほしいという自治体の意見はあります。しかし、住所に関しては、一元的なデータベースがあれば転出先の住所の確認もできるし自治体にもメリットがあります。今までそうしたデータを購入している自治体もありましたが、そのコストを低減できるかもしれません。
アドレス・ベース・レジストリ
前述しましたが、先進国では社会の基礎データを国が提供するベース・レジストリの整備が進められています。ベース・レジストリでは、レジスター（公的機関への登録）されたデータを、個人情報とかに配慮したうえで、社会の共通資産として共有することが行われています。
その要件は以下になります。
・正確であること
・最新であること
・網羅性があること
・様々な用途に使えるデータであること
・作成、収集・管理コストが適正で、持続可能なこと
こうした視点で見たときに、最も適合しているのが自治体のデータです。従来の民間が提供していた町字情報を活用したいとか郵便番号情報で整理できないかという議論ももちろんしました。しかし、知的財産の話や、様々な用途に使える基礎データという点からいくつか課題があり、また、自治体が住居表示をするときには告示や関係機関への報告をすることとなっていますし、これらの発生源に存在するデータをオープンデータ化することでベース・レジストリ化できないかと考えました。
ただし、自治体のオープンデータということでは全国一斉にスタートするのが困難になると考えられたため、国の保有するデータを初期データにアドレス・ベース・レジストリの試験版を公開しています。
今後、自治体からのメンテナンスができるようになれば、より正確性と最新性の確保されたデータが使えるようになります。
デンマークでは、このようなアドレスベースレジストリを整備したことにより、投資の数倍のコスト削減や経済効果を上げています。特にアクセスの70%は民間であり、経済的効果が大きいと指摘されています。
ここまで石垣を積んできた
さて、こんな仕組みを作ってきたわけですが、ここまで来るには長い道のりがありました。
どうしても社会の関心は、サービスとか先進技術に目が行きがちです。でも、その裏では、まるで石垣を積むような作業を10年以上かけて取り組んできた歴史があります。
2013年8月 共通語彙基盤（IMI）v1公開
1994年12月の行政情報化推進基本計画（閣議決定）で、「データコード、データ項目等基本的事項の標準化」をすることが閣議決定されていますが、難しい課題であり、長い間誰も取り組みませんでした。
2011年の東日本大震災でデータの重要性が再認識され、2011年度後半からデータの構造化プロジェクトが開始し、2013年にやっと成果物ができました。
そこでは、個人、法人等の行政で使用する主要なデータモデルが定義されました。その中に住所のデータモデルも定義しています。
それを2014年、2015年とバージョンアップを図り、展開可能なレベルにしていきました。
2016年6月 世界最先端IT国家創造宣言（閣議決定）
ついに、日本のIT戦略である世界最先端IT国家創造宣言への住所データの話題の登場です。本文中に共通語彙基盤の整備が明記され、脚注の解説の中に住所等の語彙のデータ構造の話が入っています。でも、ここでは脚注ですので解説レベルです。
［本文］
文字情報基盤(注4)と共通語彙基盤(注5)を整備。国・地方公共団体がこれらの 基盤を活用することで、組織や業務分野を超えた行政情報システム間の連携 が可能となり、円滑な公共サービスの提供を期待。
［脚注］
(注5) 氏名や住所等語彙の表記・意味・データ構造を共通化してデータの交換・活用を容易にする基盤。
2017年1月 法人インフォ（gBizInfo）サービス開始
2017年1月からマイナンバーと同時に法人番号が開始されました。実はここで、住所がクローズアップされています。
法人番号を使用して政府が保有する情報を紐づけて活用することを目指したポータルサイトである法人インフォを作ることになっていました。
これを実現するには、各省が保有する既存の法人関連情報に法人番号を付加する必要がありました。
しかし、法人名だけで正確に法人番号を付加することは困難です。そこで、国税庁が公開する法人番号、法人名称、所在地を各省の持っている公開可能なデータと照合することとしました。
ここで課題になったのが、法人名称と所在地の揺れです。法人名も「株式会社」「（株）」や株式会社と法人名の間にスペースで区切りを入れるデータがあり、所在地の住所データも自由に記述がされています。
そこで、法人番号付与ツールを作成しました。このツールでは、法人名をクレンジングするとともに、住所データをクレンジングしてマッチングする方法をとっています。
住所のクレンジングでは、都道府県などが抜けているものを付与し、丁目以下の漢数字や全角数字を半角数字にして照合しています。
一方、商業登記の原データが1行の住所データであったため、市区町村までのタグ付けはしていますが、データの構造化までは踏み込みませんでした。
法人インフォでは、共通語彙基盤を参照してデータを整備していので、将来のデータ構造化に備え、2020年にIMI 情報共有基盤 コンポーネントツールとして住所変換コンポーネントを提供しています。住所データを入力することで、記載漏れ部分の補完、共通語彙基盤の項目にデータ項目の分解をしてくれます。しかし、現段階で、gBizInfo自体が住所データ構造化をしていないので、サイト内で公開だけしています。
2017年12月 行政データ連携標準α版
共通語彙基盤は専門的過ぎてわかりにくいということもあり、ここで、行政で簡易に活用できる行政データ連携標準を整備しています。日付、住所、電話番号等の基本情報の表記方法が異なるのを防止するために作ったものです。社会的に影響範囲が大きいため、α版という形で公開しています。
住所に関しては、1行で記述する場合、2行で記述する方法などのルールを解説しています。
2018年1月 デジタルガバメント実行計画
デジタルガバメント実行計画（eガバメント閣僚会議決定）で住所データの標準化と町字コードの推進を明記しています。
1)行政データ標準の確立
ア．行政データ連携標準（仮称）の策定（◎内閣官房、全府省）
官民を通じた分野横断のデータ連携を行うためには、日付、公共施設・観光施設等の住所等の基本的なデータ形式の標準化が必要となるが、行政機関におけるデータ実装レベルでは、いまだこうした基本的なデータやコードの記法に揺らぎが存在している。これまでは人が目視で確認する等によりその揺らぎを吸収してきたが、データ連携が前提となる現在においては、揺らぎを抑える仕組みが必要である。
このため、内閣官房は、引き続き、日本工業規格（JIS)や関連する国際標準等とも整合性をとりつつ、上記の標準について、利用者からの意見を踏まえ、2018年度（平成30年度）末までに整備するとともに、必要に応じて改定、拡充を実施する。
各府省は、今後データ連携に使うデータを整備する際は、この標準を適用することとする。また、内閣官房は関係府省と協力して町字識別子及び町字情報の標準化を推進する。
ここでの注目点は町字識別子に踏み込んでいることです。単に町字情報を整理するだけでなく町字識別子を検討することにしています。
ここまでの検討の中で、既存の識別子を使うのではなくオープンデータを活用する方針にしたことで方針の整理が進みました。
2018年6月 世界最先端IT国家創造宣言（閣議決定）
2017年の戦略では、共通語彙基盤の推進を行うことが簡単に書かれているだけですが、2018年についに戦略本文で行政データ標準を作ることが明記されました。
(３) デジタル改革の基盤整備
① 行政データ標準等の確立 官民を通じた分野横断のデータ連携を行うためには、データ形式の標準化が必要となるが、行政機関におけるデータ実装レベルでは、いまだ基本的なデータやコードの記法に揺らぎが存在している。これまでは人が目視で確認するなどによりその揺らぎを吸収する、膨大なデータクレンジング作業が発生してきたが、データ連携が前提となる現在においては、揺らぎを抑える仕組みが必要である。 内閣官房において、行政分野におけるサービスやデータの標準化に向け、行政データ標準（日付、住所等の基本情報）を策定するとともに、政府の文字情報基盤を整備するため、漢字、代替文字、フリガナ、ローマ字等を含む文字情報の現状や導入方法に関するガイドラインの整備を行う。
2019年3月 行政データ連携標準正式版
IT戦略である世界最先端IT国家創造宣言で策定されたことを受け、α版で公開していた行政データ連携標準を正式版として公開しています。
2019年3月 文字環境導入実践ガイドライン
行政データ連携標準とともに公開されたのが文字のガイドラインです。文字情報基盤により日本の漢字の国際標準化が2017年12月に終わり、その普及が求められていました。そこで、ヨミガナやローマ字も含んだガイドを策定することがIT戦略に明記されました。
このガイドでは地名の漢字、ヨミガナ、ローマ字についてガイドをしています。しかし、氏名の表記を主目的に作成したガイドなので、地名に関しては詳細に定義されていません。
2.2.3. 地名における文字の取扱い
2.2.3.1. 文字の範囲に関する標準的な取扱い
JIS X 0213の使用が前提ですが、歴史的地名等、特殊な要因のため、外字を使用せざるを得ない場合には、外字とJIS X 0213の関連付け（マッピング表の作成）を行います。データ連携の際にマッピング表から外字をJIS X 0213の文字にデータ提供者が変換してデータを提供します。
2.2.3.2. 文字コード及び文字の符号化形式に関する標準的な取扱い
総論で記載したとおり、文字コードはJIS X 0221、文字の符号化形式はUTF-8を指定することを推奨します。
2.2.3.3. ヨミガナに関する留意事項
訪日外国人旅行者向けた観光情報の提供等、地名のヨミガナの取扱いが必要な場合には、都道府県名及び市区町村名については、総務省が作成している「全国地方公共団体コード」に記載されている「カナ」を使用します。
2.2.3.4. ローマ字表記に関する標準的な取扱い
地図で用いる地名のローマ字については、国土交通省が作成している「地名等の英語表記規程」のローマ字表記に基づき、決定します。 住所表記で用いる地名のローマ字については、行政機関が住所表記する場合には、「市」を「shi」のようにローマ字表記をすることが多いことから、一般的な行政文書では、地方公共団体のローマ字名であるshi等のローマ字表記を使用します。
2020年3月 デジタル・ガバメントの実現のためのグランドデザイン
戦略を毎年改定している中でエポックメイキングなのがこのグランドデザインです。これまでの戦略が行政官中心に書かれたものに対して、このグランドデザインは、「統一的な政府情報システムの将来的な在り方」を示すものとして民間出身の政府CIO補佐官が世界や技術の動向を踏まえ提言としてまとめたものです。サブタイトルは「国民一人一人に寄り添った2030年の行政サービス実現に向けて」であり、サービスデザインやデザインシステム、データファースト等、現在のデジタル戦略の骨格をなすものを提言しています。
データファーストの取り組みのでは、トップ項目としてベースレジストリを記述しており、住所を例に説明をしています。
2020年6月 世界最先端デジタル国家創造宣言
本文でデータ整備の取り組みは書かないものの、グランドデザインを受けて施策集にベースレジストリの推進が記載されました。
2020年度中に土地情報のベースレジストリを整備すると記載しています。
[No.１－１] ベース・レジストリの整備
・ 行政機関の窓口における人と人との接触の削減に向けて、国民・企業等が窓口を訪問する回数を減らすことができるよう、一度提出した情報は、二度提出することを不要とするワンスオンリーの原則に基づき、個人・法人に係る基礎的な情報、地理空間情報、免許や許認可等を証明するための情報など、社会の基本データについて、最新かつ正確なベース・レジストリを整備することが重要。
・ このため、令和２年度中に、国民・企業等にとって、特に必要性の高い法人や土地情報等のデータをベース・レジストリの先行事例として整備するとともに、政府において管理すべきベース・レジストリの一覧を作成。
・ これにより、感染症の拡大防止に寄与するだけでなく、窓口での待ち時間が減少することから、国民・企業の利便性の向上等にも寄与。
この計画はタイトな目標設定ですが、法人については法人番号公表システムとgBizInfoがあるのでベースレジストリといえますし、土地情報等は国土地理院の地図や国土数値情報をベースレジストリとしてまとめられないかと前向に検討をしています。
2020年12月 ベース・レジストリ・ロードマップ
世界各国でデータ戦略整備が進む中でわが国でもデータ戦略整備が重要な課題となり、2020年10月に内閣官房のIT総合戦略室にデータ戦略ワーキンググループが設置され、12月に第一次取りまとめを行いました。この取りまとめの中でベース・レジストリ等のデータ整備が重要視され、別冊としてベース・レジストリ・ロードマップを作成しています。
ここでは以下のデータをベース・レジストリの候補に挙げています。
そして住所は、重点候補のデータとして、以下のように整理されています。
e)住所
各自治体が公表しており、国全体を集約した住所データはないが、ワンスオンリーという視点から、あらゆるサービスで必要となることから、最重要データとして整備が求められている。
●課題
一部の給付金申請時に、正確な住所が記載されていない申請があり、事務処理に手間がかかる。
架空の住所を記載されても正否を確認する方法がない。
●現在共有されているデータと共有範囲
共有されているデータはない
●データ項目例
町字識別子 都道府県・市区町村コード 都道府県・市区町村名、ヨミガナ、英字 町字名、ヨミガナ、英字 地番等 ポリゴン
2021年5月 ベース・レジストリの指定について
ベース・レジストリ・ロードマップは、考え方や方針の整理であり、候補データの洗い出しでした。その後詳細な検討を行い、内閣官房IT総合戦略室がベース・レジストリ対象データの指定を行いました。
アドレス（町字、所在・地番）、不動産番号、地図データ（不動産登記情報）
現在行政が保有する様々な土地台帳については、共通のキーが存在しない、各台帳間の表記揺れなどのため、台帳の更新などの際には、不動産登記簿等からデータを入手しても手作業で再入力するなど膨大な作業時間が発生しているのが実態である。
このため、町字、所在・地番、不動産番号をベース・レジストリとして指定し、これらを共通キーとして各台帳の紐付けを可能とする。この点については、地番は個人情報に該当する場合があるとされており、少なくとも行政機関間での扱いをどのように整理するかが課題となる。
また、町字、所在・地番表記の揺れに対するクレンジングや情報提供のあり方（APIや地図データ（不動産登記情報）のXML形式での提供）も課題となる。更に、台帳の保有する地図データそのものの連携を可能とする必要があるが、地図データ（不動産登記情報）の4割程度は地籍調査等を経ていない古い公図のままである。そのため、当該4割程度は正確な緯度経度が確定できない任意座標系に基づくものであり、他の地図データとの連携の際に適切に重ね合わせられないなどの課題がある。これらの地図データについては、まずは地籍調査等を進め測量法第11条で定められた基準に準拠した座標系（以下「公共座標系」という。）を付した地図を整備するとともに、任意座標系が付与されているものについては公共座標を付与する必要がある。
このため、まずは地番における個人情報との関係を整理しつつ、情報提供の技術的な課題や地図データの活用における公共座標系の付与方策等の課題を整理し、2025年までに、公共座標系の付与された地図データを含む台帳間連携を可能とするよう検討を進め、その実現を目指す。
2022年6月 包括的データ戦略（閣議決定）
データ戦略ワーキンググループの第一次取りまとめを受けて、包括的データ戦略が策定されました。半年しか間が空いていないことから、「データ戦略ワーキンググループの第一次取りまとめ」と「包括的データ戦略」の両方読むと理念や実施事項が分かるという珍しい構成になっています。
そしてアドレスベースレジストリは2022年度中に基本設計とプロト運用を行い、次年度以降本格運用に向けて検討を進めることと記載されています。
2022年3月 政府相互運用性フレームワーク
政府相互運用性フレームワーク（GIF）は、これまで内閣官房IT総合戦略室で推進してきたデータ標準や関連ガイドラインを体系的に整理したものです。
データモデルが中核にありますが、これまでの共通語彙基盤の欠点だった「わかりにくさ」を改善するため、拡張とサブセット化が行われています。
このように整理したことで、教育、防災、行政の通知、自治体サービスなど様々なところで活用され始めています。
特に住所についてもデータモデルの見直しが行われ、コアデータパーツとして整備されました。そして、アドレス・ベース・レジストリのデータ構造に採用されています。
このように共通的なデータモデルを使うことで、アドレス・ベース・レジストリのデータは、GIFに対応した各アプリケーションから使いやすくなります。
今後、GIFでは、データモデルやルールだけでなく、データ変換や確認、ジオコーディングする各種ツールが提供される予定です。
2022年3月 不動産ID
住所と切っても切り離せないのが、土地や建物などの不動産です。国土交通省が検討を行い、不動産IDのルールを整備しました。
2023年度には実際に不動産ID確認システムのプロトタイプを使って不動産IDを使った実証を進めていく計画です。
2022年4月 アドレス・ベース・レジストリ試験版公開
2021年に構築したアドレス・ベース・レジストリ試験版が整備されており、試験運用されています。
利用者の意見などを聞くとともに、地番情報の登録、更新のルーチン化、安定した運用基盤の整備等の検討を進めているところです。変更履歴情報を管理する方法も今後検討していく必要があります。
2023年1月 登記所備付地図データ公開
登記所で供覧のできる地番が記載された登記所備付地図データが公開されました。これにより、全国の不動産登記に関する地番ごとの地図データが活用可能になりました。これも住所データの一環として大きな一歩です。
このデータを使いやすくするために登記所備付地図データ（地図XML形式）変換コンバータも公開されています。
今後に向けて
ここまで、10年以上かけて、一歩一歩、住所のデータの整備をしてきています。当初は、検討しなければいけないことが多いうえ、必要性を理解してくれない人もいましたが、やっとゴールへの道が見えてきたと思います。
地番の問題や建物管理の問題などまだまだ大きな課題は残っていますし、今後は３Dデータの整理なども必要になりますが、何とかなるのかなと楽観的に見ています。
今後も関係者の方と一緒に取り組んでいけたらなと思います。
この記事が気に入ったらサポートをしてみませんか？