アドレス・ベース・レジストリの方針と期待【備忘録】デジ庁のコメントをまとめてみた
アドレス・ベース・レジストリ??
ベースレジストリ（正式表記は「ベース・レジストリ」？）のトップバッター「アドレス・ベース・レジストリ」について国民の声に応えたデジタル庁のコメントを纏めた。いや、コピペした！？
ふと思ったが、デジタル庁が本物かどうかは保障しませんｗｗ
私の思い
アドレス・ベース・レジストリは、民間や自治体などのアドレスが「2-2-2」とか「2丁目２番２号」とか表記がバラバラ、コードIDもバラバラ、アドレス・ベース・レジストリで統一しましょという大工事をする認識です。アドレス・ベース・レジストリが完璧にしたとて、日本の全システムがアドレス・ベース・レジストリに対応します！って大変ですが。。
それはさておき、システム的には都道府県コードなどIDなどで出来るので、住所表示はアドレジを参照するので、常に同じ住所表記になる。
システム外では、住所を書くことがなくなるかも。一応、デジタル庁はワンスオンリー狙いです。ワンスオンリーは「一度提出した情報は、二度提出することを不要とする」もので、それがベースレジストリで、今回は住所系に挑戦です。
個人的には「個人（名前、生年月日、性別、住所、マイナンバーなど）」も期待しています。この「個人」の中の住所の基になる情報が今回のスコープです。ちなみに私が期待する「個人・ベース・レジストリ」はCIO時代から入っていますが、番号法の壁がありますよね。個人情報ヒステリック症候群（造語）がさらに日本のデジタル化を遅らせるのか・・。
アドレジ（勝手に略称）でどうなるの？をデジタル庁より説明いただきます。そのあとに、デジタル庁の「アドレスベースレジストリ担当者さん」が参加者へのコメントを張り付けて、私がポイント、大事だなと思ったところを太字にしています。
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。
アドレス・ベース・レジストリの取組の目的の一つとして、官民が活用可能な住所辞書を整備し、官民各システムの住所辞書として利活用することを想定しております。（略）
現状では、各府省における住所データは、申請者の申請通りの住所が入力されている場合が多いことが、各台帳間の住所表記揺れが生じている要因となっております。そのため、住所のテキスト情報を連携キーとして使用する場合において、アドレス・ベース・レジストリの住所辞書を共通的の用いることは一定程度有効であると考えております。
既存の住所データをどのようにアドレス・ベース・レジストリの住所辞書に合わせていくかについては、何らかのツールによる変換等も含め、その方法については今後検討して参ります。
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。
ベース・レジストリ自体は基盤となるデータであるため、それ自体が価値を生み出すと側面よりも、ベース・レジストリの取組で整備した基盤データが各種サービスに用いられることにより、利便性を実感いただく側面が大きいと考えております。
アドレス・ベース・レジストリにおいては、行政側で住所・所在地情報係る情報について、人間が可読な「文字情報」と、機械が認識可能な「ID」「位置情報」「形状情報」を組み合わせて整備することを念頭に置いております。その基盤データを官民の各サービスが利活用することで、ご意見いただいたユースケースの実現が可能になると考えているところです。ベース・レジストリで整備する協調領域と、それを活用して様々なサービスを提供する競争領域について、ご意見いただいた点も踏まえて検討して参ります。
アドレスベースレジストリ担当者さん
アドレス・ベース・レジストリの検討に際しては、人間が可読な「文字情報」と、機械が認識可能な「ID」「位置情報」「形状情報」を組み合わせて整備することを念頭に置いており、データ設計上は緯度経度等を保持可能な形にしておりますので、それらと他の情報をどう組み合わせて活用していくかについては、いただいたご意見も踏まえて取り組んで参ります。
アドレスベースレジストリ担当者さん
町字情報や住居表示情報は市区町村、地番は登記所でそれぞれ個別に管理されていることから、行政において、標準的な住所・所在地を一元的に管理できていません。さらに、一般に流通している住所・所在地の表記の階層構造は、地域により様々に異なり、特殊なケースも多々存在していることから、住所をキーとしたデータ連携が困難となる要因となっています。
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。
アドレス・ベース・レジストリの取組は、行政手続に係る住所入力のワンスオンリーに資すると考えておりますので、ご指摘いただいたペーパーレスへの課題の解決の一助となるよう、今後も取り組んで参ります。
▼アドレス・ベース・レジストリ
▽デジタル庁：アドレス・ベース・レジストリのページ
▽意見募集：アドレス・ベース・レジストリ
▽参加者に対してコメントしたデジタル庁の「アドレスベースレジストリ担当者」さんのコメント
▽「京都の通り名」「岐阜県多治見市にカナ未記載町字あり」などは鬼門？地域に特異あり
関係各所とも連携しないと使えない・・となるかも。って、レジストリじゃなくなりますが・・。やはり、大変ですね・・。
アドレスベースレジストリ担当者さん
この度はご意見をいただき、ありがとうございました。
ご指摘いただいた京都の通り名については、今回の試行公開版では対象外としております。その理由としては、参照元のデータに京都市の通り名が整理された形で保有しているものがなかったためです。
しかし、京都市では同一行政区内に同一名称の町が複数あるケースが少なからず存在し、通り名がなければ、各町字の場所の区別ができない状況も把握しているところです。（例：「京都市中京区亀屋町」は５箇所あります。全部別々の場所であり、通り名を付けることによって区別することができます。）
通り名の整備については、上記の状況も踏まえつつ、ベース・レジストリとして整備することの必要性も含め検討課題の一つであると認識しております。今後、京都市をはじめ地方自治体における業務内容や通り名による課題についても具体的に把握した上で、対応方法について検討して参ります。
アドレスベースレジストリ担当者さん
この度はご意見をいただき、ありがとうございました。
ご指摘いただいた点について、状況について確認いたしました。カナが記載されていない57件については、参照元のデータの状況を確認したうえで対応いたします。
▽課題と方針
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。
住居表示の住居番号として４桁以上ある事例について、今後検討を進めていく中で、その事象の発生状況について把握するとともに、必要に応じて当該地方公共団体に確認するなど、その対応について検討して参ります。
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。
ご指摘いただいた「丁目」の区分については、区分けする要否について両論あることは承知しておりますが、参照元データの構造、当該名称を番号・ハイフンで省略するかどうか、英語表記の再現性等を勘案し、試験公開版においては「丁目」を独立した項目として定義したところです。
今後、この区分の要否については、町字名を管理する主体である地方公共団体のご意見やみなさまからのご意見も踏まえながら、検討して参ります。
アドレスベースレジストリ担当者さん
この度はご意見をいただき、ありがとうございました。
ご指摘いただいた同じ住所の建物が存在することについては、住居表示実施地域においては袋小路にある建物は同じ住居番号となる場合があることや、住居表示未実施区域においては地番が住所として使用されるため、同じ筆の土地に複数の住宅が存在する場合は同じ地番の建物であることから、同じ住所の建物が生じることは承知しております。
試験公開版においては、まずは町字までの情報を整理した上で、それに紐付く地番または街区符号・住居番号を紐付けるデータ形式を整理したところです。今後、建物情報を整備する際に、建物情報と住所情報を文字情報と位置情報を含めて整備し紐付けることで、同様の住所で複数の住宅が存在する場合にも対応できるのではないかと考えております。住居を含めた建物情報の取扱いについては、いただいたご意見も含め、今後検討して参ります。
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。
ご意見いただきました住居表示実施については住居表示に関する法律にのっとり、各市町村住民説明や議会の議決を経て実施するものとなっており、地方自治体の業務の範疇であるため、アドレス・ベース・レジストリの取組においては、現状の状況を踏まえた取組となっております。また、地番は土地の筆単位に付される番号である一方、住居表示は住居番号のフロンテージの点情報を元に建物の玄関の位置により付される番号であることから、その特性上、地番と住居表示を全て対応させることは難しいところです。
これらの課題を乗り越えるため、いただいたご意見を踏まえ検討を行いデータを整備するよう努めて参ります。
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。
地番と住居表示の関係は重要な観点だと私たちも認識しております。
他方、地番は土地の筆単位に付される番号である一方、住居表示は住居番号のフロンテージの点情報を元に建物の玄関の位置により付される番号であることから、その特性上、地番と住居表示を全て対応させることは難しいところですが、住居表示と地番の関係性については、地方自治体においても苦労していると伺っているところです。
そのため、試験公開版で収録できなかった地番については、整備に向けた制度的整理が図られ次第整備していくとともに、地番と住居表示の関係性については、一定の解決策をお示しすべく、その整備方法や公開方法について検討して参ります。
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。
ドローンなどの自動運転も見据えた場合、２次元の情報に加え、地表面の高度の情報、地上の建物の形状・出入口情報、電柱・電線等の工作物に関する情報等、３次元に関する様々な情報が整備され、連携することが必要であると考えており、現在はその検討の緒に就いたところです。
整備にあたりまだまだ課題がありますが、みなさまからのご意見を伺いながら、いただいたご意見含め様々な利活用ができるように幅広い視野をもってデータ整備を進めて参ります。
アドレスベースレジストリ担当者さん
この度はご意見をいただき、ありがとうございました。
試験公開版においては「効力発生日」「廃止日」において時間軸を記録できるデータ定義となっておりますが、時間軸も含めたID体系は現状では採用しておりません。現在は試験公開版の現在の情報と今後の変更情報について注力しておりますが、過去の変更情報については「効力発生日」「廃止日」等の活用を含め、今後の課題として検討して参ります。
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。
市区町村統廃合等、アドレス・ベース・レジストリ整備後に全国地方公共団体コードの変更を伴う措置があった場合において、新旧が対応できる仕組みについては、各レコードに「効力発生日」「廃止日」を登録できる仕様となっています。今後、旧・新の紐付けが可能な仕組みについて、検討して参ります。
また、現在は試験公開版の現在の情報と今後の変更情報について注力しておりますが、過去の変更情報については「効力発生日」「廃止日」等を登録できるため、今後の課題として検討して参ります。
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。
アドレス・ベース・レジストリの試験公開版においては、「全国地方公共団体コード＋町字ID」がキー情報となり、地番や住居表示の街区符号・住居番号それぞれに紐付く形で整備しております。地番は「不動産登記法」に基づき地番区域単位で土地の筆単位に付される番号である一方、住居表示の街区符号・住居番号は一定のルールに則り設定された街区において付与される住居番号のフロンテージの点情報を元に建物の玄関の位置により付される番号であることから、両者が完全に紐付く関係にはなりません。そのため、住居表示実施地域においては、地番IDは住所の検索キーとなり得ないのはご指摘の通りです。
試験公開版の整備に際しては、その状況を理解したうえで、データ構造としては「町字」単位でIDを付与した上で、その下位階層として「地番」「住居表示（街区符号・住居番号）」をそれぞれ定義しているところです。
今後、ご指摘の点も踏まえながら、デジタル庁内全体で検討を進めて参ります。
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。ご指摘いただいた地下埋設物については、3次元データの取扱いについての文脈の中で、ドローンの自動運転等に資する地上の情報とともに地下埋設物についても重要であると認識しております。3次元情報どのように情報を収集・取得・管理していくかについて、検討の緒に就いたところですが、アドレス・ベース・レジストリの取組やその周辺で整備されていく2次元情報との連携が必要であると考えております。
２次元データ整備のみならず、整備したデータをどのように利活用していくのかも含め、広い視野をもって取り組んで参ります。
▽SE：CSV？XML？JSON？
アドレスベースレジストリ担当者さん
この度はご意見をいただき、ありがとうございました。
現時点では試験公開版として取組の背景や状況をサイト上で説明しつつ、CKANを通じたCSVファイル形式での提供を開始したところであり、私たちの取組内容について、全体像や詳細についてみなさまへのご説明が不足していることについて、今回のアイデアボックスでの意見募集において感じているところです。
今後、デジタル庁においてアドレス・ベース・レジストリの取組やその周辺領域での取組の全体像や可能な範囲で詳細をお示ししたうえで、みなさまと議論ができるよう、取り組んで参ります。
また、現状のアドレス・ベース・レジストリでは、市民参加型のアーキテクチャは採用しておりません。ガバナンスの重要性についても認識をしているところです。頂いたご指摘を参考に、今後のアーキテクチャ検討及びパイロットシステムの改善に取り組んでまいります。
アドレスベースレジストリ担当者さん
この度はご意見をいただき、ありがとうございました。
現在は住所・所在地データを整備しているところですが、次の段階として、官民の既存の住所データをベース・レジストリの形式と互換性を持たせる取組であると考えています。データの提供方法やフォーマットについては、今後WebAPI等を通じて検索条件により抽出されたJSON等のフォーマットで提供することも含め、検討しているところです。また、アドレス・ベース・レジストリのデータから既存の住所データを変換できるツールについても検討しているところです。
また、官民で保守していく方法も含め、どこまで行政側で提供し、また官民で協力し整備運用し、どこから民間側で取り組んでいくかについても、ご意見いただいた点も踏まえて検討して参ります。
アドレスベースレジストリ担当者さん
この度はご意見をいただき、ありがとうございました。
ご指摘いただいた文字化けについては、試験公開版においては、提供しているCSVの文字コードがUTF-８のため、エクセルで開くと文字化けが生じてしまいます。現在はCKANを通じたCSVのみの提供ですが、データの提供方法やフォーマットについては、今後WebAPI等を通じて検索条件により抽出されたJSON等のフォーマットで提供することも含め、検討しているところですが、現状これらの取組内容について、みなさまへのご説明が不足していることについて、今回のアイデアボックスでの意見募集において感じているところです。
今後、デジタル庁においてアドレス・ベース・レジストリの取組やその周辺領域での取組の全体像や可能な範囲で詳細をお示ししたうえで、みなさまと議論ができるよう、取り組んで参ります。
CSV、XML、JSONの3種類用意にしておきますか？
1つに絞る必要もなかろうかと。（たぶんXMLはそのうち保守停止かなと）
非SEがノンコード・ローコードで（簡単な）電子システムを作った記事を思い出しました。（私は経験がないので何ができるかなど知りませんが）たぶんCSVの方が良いのかなと。
あと、100名程度のEXCEL台帳なども世の中にはあるのかなと。そこでXMLやJSONって・・ﾍ(ﾟдﾟ)ﾉ ﾅﾆｺﾚ?と思う人もいるかと。
世の中のすべての電子システムが最新技術であるわけでもないので、CSVもあったも良かろうと思いました。
では、10年後JSONもう古くない？となるかもね！？
ただ、CSVだけというのは、「まさにそのレガシーが延々残ることで困った、ということを教訓にすべきであって（略）散々な状況がちらほら出ている（略）絶滅危惧種のCOBOLerに高額な費用を払って保守」になるというのはわかりますね。また、3種類用意するのは初期開発費と保守費がかかるという意見もわかります。ただ、CSV、XML、JSONの3種類を用意することに関しては、さほど費用（含、説明書など）は掛からないだろうかと。
ちょっと盛り上がったのでこのスレだけ貼っておきます。タイトルは釣られないでください。あくまで提案者さんは『データの配布はきちんと「そのデータにふさわしい」フォーマットと方法で配布されるべきであり、準備が整っていないにせよ「最終的にはこういった形での配信となる予定」という話を、具体性がある程度ないにしても目標とする地点をきちんと説明しておくべきかと思いまっす。』が本質です。
仮にCSVとしたら文字コードは？
アドレスベースレジストリ担当者さん
この度はご意見をいただき、ありがとうございました。
ご指摘いただいた文字化けについては、試験公開版においては、提供しているCSVの文字コードがUTF-８のため、エクセルで開くと文字化けが生じてしまいます。現在はCKANを通じたCSVのみの提供ですが、データの提供方法やフォーマットについては、今後WebAPI等を通じて検索条件により抽出されたJSON等のフォーマットで提供することも含め、検討しているところですが、現状これらの取組内容について、みなさまへのご説明が不足していることについて、今回のアイデアボックスでの意見募集において感じているところです。
今後、デジタル庁においてアドレス・ベース・レジストリの取組やその周辺領域での取組の全体像や可能な範囲で詳細をお示ししたうえで、みなさまと議論ができるよう、取り組んで参ります。
▽日本全システムがアドレジ移行できるのか？
全システムの日本語住所などを統一（データ変更）するの大変だな～と。。アドレジできても利用されなかったら意味なし！行政だけしても意味なし！と思っています。
アドレスベースレジストリ担当者さん
この度はご意見をいただき、ありがとうございました。
ご質問いただいた行政の各サイトにおけるデータベース等への適用ですが、現在は住所・所在地データを整備しているところですが、次の段階として、官民の既存の住所データをベース・レジストリの形式と互換性を持たせる取組であると考えています。今後、アドレス・ベース・レジストリのデータから既存の住所データを変換できるツールについて検討していきますが、行政側の各台帳における適用については、各台帳を調製する根拠法令との関係を整理した上で進めていくことが必要です。そのため、現在どのデータに適用するのかについては決定しておりませんが、行政側のどのデータについて提供していくかについて、検討して参ります。
現在の全国住所辞書をかき集めて変換表とツールを渡せば、ベースレジストリの移行を進めるところが多くなるのかなと思っています。完ぺきなものは難しいでしょうけど。。
番号法で個人番号（マイナンバー）を付番するのも、4情報などで突合し、目検だったようだ。DXすんぞ～手入力で目検とか、大手ベンダーと下請けマンパワーでやる、移行推進に向けて血税放出大サービスにならないようにデジタル庁が用意すべき。
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。
アドレス・ベース・レジストリに対し、期待をお示しいただき大変うれしく思います。お示しいただいた「名寄せ作業」については、官民の様々な方からその苦労・大変さについて伺っているところです。本アドレス・ベース・レジストリの取組が名寄せの苦労が減るための一助になるよう、取り組んでいます。
また、「住所マスタにするには精度が足らないように思います」というご指摘のとおり、現状は試験公開版のため、住所・所在地マスターとして利活用するにはまだまだ課題がございますが、本番公開に向けみなさまからのご意見を伺いながら進めてまいります。
▽アドレス・ベース・レジストリの更新タイミングについて
アドレスベースレジストリ担当者さん
この度はご意見をいただき、ありがとうございました。
住所・所在地データ更新のタイミングについては、町字の変更情報は地方自治法に基づき告示された後に変更されるため、告示で示された変更日後速やかに更新されることが望ましいと考えております。ただし、当面の間は国土地理院の電子国土基本図・居住地名の更新情報をもとに更新していくこととしております。
データ品質の担保においては、正確性・最新性・継続性は重要な観点であると認識しておりますので、運用方法についてはこれらの観点を踏まえ今後検討して参ります。
▽建物情報の整備と位置情報との連携と可視化
アドレスベースレジストリ担当者さん
この度はご意見をいただき、ありがとうございました。
アドレス・ベース・レジストリの取組は、2次元の土地に関する文字情報・機械可読情報を整備しているところですが、その次の段階として土地の上にある建物情報と連携していくことが必要であると考えております。
ベース・レジストリの文脈では、不動産登記情報の土地情報と建物情報を紐付けて整備していくアプローチですが、PLATEAUなど点群データなど、航空写真やMMS（移動計測車両による測量システム）などの測定データから生成される3次元情報画整備されつつあることから、これらの情報とアドレス・ベース・レジストリで整備するデータを連携させて利活用を図ることについても、検討の緒に就いたところです。今後、いただいたご意見も含め、検討して参ります。
▽法律の壁
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。
整備したデータについては、少なくとも町字までの情報は試験公開版と同様にオープンデータとして公開する前提です。地番については、現行の個人情報保護法を前提としたものではないですが、「地理空間情報の活用における個人情報の取扱いに関するガイドライン」(平成22年9月地理空間情報活用会議推進会議)では個人情報に該当する可能性が指摘されているところです。そのため、地番マスターの公開に際しては、個人情報保護法等の法令における整理を図った上で公開が必要となります。今後、どのような整理により、誰にどこまで公開できるかについては、法令を遵守した上で、できるだけ広く公開できる方策について、検討して参ります
（参考）地理空間情報の活用における個人情報の取扱いに関するガイドライン
https://www.gsi.go.jp/common/000055897.pdf
▽パイロットシステム：Docker、マイクロサービス、WebAPI
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。
ご指摘のとおり、現状のアドレス・ベース・レジストリでは、市民参加型のアーキテクチャは採用しておりません。ガバナンスの重要性についても認識をしているところです。頂いたご指摘を参考に、今後のアーキテクチャ検討及びパイロットシステムの改善に取り組んでまいります。
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。
ご教示いただいたURLに記載された内容については、私たちも以前から拝見しているところです。
また、今回整備したパイロットシステムにおいても、Dockerを用いるなど、マイクロサービスアーキテクチャーを指向しながらシステム構築しているところです。現在は試験公開版ですが、データの提供方法やフォーマットについては、今後WebAPI等を通じて検索条件により抽出されたJSON等のフォーマットで提供することも含め、検討しているところですが、現状これらの取組内容について、みなさまへのご説明が不足していることについて、今回のアイデアボックスでの意見募集において感じているところです。
今後、デジタル庁においてアドレス・ベース・レジストリの取組やその周辺領域での取組の全体像や可能な範囲で詳細をお示ししたうえで、みなさまと議論ができるよう、取り組んで参ります。
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。
ご指摘いただいたマイクロサービスアーキテクチャーについては、私たちとしても重要な観点であると認識しており、試験公開版やその後の機能拡張の実施に際しては、機能等に小単位でシステム・ツールを作成し、それらを疎結合で連携させるような設計を指向しているところです。また、より良いアーキテクチャの検討あたり、ご指摘のように具体性のあるユースケースの想定が重要と考えており、関係府省や自治体へのヒアリングを行っているところです。試験公開版で公開している部分については、CKANを通じたCSVファイル形式での提供にとどまっていることから、どのような設計になっているか等、デジタル庁においてアドレス・ベース・レジストリの取組やその周辺領域での取組の全体像をお示ししたうえで、みなさまと議論ができるよう、取り組んで参ります。
▽そのほか
アドレスベースレジストリ担当者さん
この度はご意見をいただき、ありがとうございました。
データ整備のみならずどのように活用していくか重要な課題であると認識しております。
また、３D空間情報については、国土交通省が進めているPLATEAUの取組等において実際のデータ提供を開始しているところです。また、3次元空間における情報連携のアーキテクチャについては、IPAのデジタルアーキテクチャデザインセンターにおいて検討しているところです。今後、アドレス・ベース・レジストリの取組と、PLATEAU等で整備されるデータをどう連携していくかについては、データフォーマットや連携方法などについて検討の緒に就いたところです。
アイデアボックスはじめみなさまから活用方法などご提案いただき厚く御礼申し上げます。データ整備に向けて課題がまだまだございますが、ご意見いただいた点も含め関係者等と広く意見交換しながら取り組んで参ります。
アドレスベースレジストリ担当者さん
この度はご意見をいただき、ありがとうございました。
ご意見の1点目及び2点目については、マイナポータルを活用するサービスや、マイナンバーカードの利用者証明書を使用して認証を行うサービスにおいては、マイナンバーカードのICチップに格納されている住所データを用いることで、各サービスにおいて住所入力や各サービス側での住所の保持は不要になることで、住所情報のワンスオンリーが実現すると考えております。また、マイナポータルやマイナンバーカードを利用しないサービスにおいては、アドレス・ベース・レジストリの情報を参照・活用することで、住所表記の揺れ等に一定程度対応できると考えております。
3点目については、例えば官民の各システムに組み込むことのできるツールや、WebAPIで使用できるツール等を提供できれば、申請者から見てシームレスになると考えておりますが、具体的なツール等の内容や提供方法等については、地方公共団体や事業者等のご意見を伺いつつ、みなさまからのご意見も踏まえ、今後検討して参ります。
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。
いただいたご意見については、「土地の情報はポリゴンなどの座標情報で管理されるが、時間と共に合筆・分筆等形状の変化が生じることから、ポリゴンに対してIDを振るような採番体系では、同一の意味に同一のIDを振るという形で、管理しきれない。そこで時間軸にもIDを振って、時間と空間にユニークなキーを振れば管理できるのではないか」という趣旨のご提案であると理解いたしました。試験公開版においては「効力発生日」「廃止日」において時間軸を記録できるデータ定義となっておりますが、土地の境界と時間軸の組み合わせでのID体系は現状では採用しておりません。また、当該ご意見については、他の投稿者から様々なご意見が出ていることからも、その要否や必要となった場合の、実装・運用の方法は検討が必要な論点があると考えております。
また、担当部門としてRFCについては認識しておりますが、試験公開版においては、現在はわかりやすさを優先してRFC準拠とせずに、既存の位置参照情報（国土交通省）に附番されているIDを準用し、町字単位でIDを付しているところです。
いただいたご意見を踏まえ、時間軸も含めたID体系の要否も含め、デジタル庁内の標準を担当している部門等とも連携して検討して参ります。
▽標準仕様との絡み
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。
ご指摘いただいた「住民記録システム標準仕様書【第2.0版】」における住所辞書の記載についてはアドレス・ベース・レジストリ担当も認識しているところであり、同じデジタル庁内で住民記録システムの標準化を担当している部門へも相談しながら、検討しているところです。現状は試験公開版であるため、本番公開に向け、いただいたご意見も踏まえて取り組んで参ります。
アドレスベースレジストリ担当者さん
この度は、ご意見をいただきありがとうございます。
ご意見いただいたAutocomplete属性については、デジタル庁内の標準化を担当している部門とも連携しながら、その対応について検討して参ります。
▽私の妄想
大事ですよね。
アドレジの住居に限っての私のイメージは
C（新規追加）・・・・自治体
R（参照）・・・・・・いろいろ
U（更新）・・・・・・自治体
D（論理削除）・・・・自治体
かな。というのが「https://www.digital.go.jp/policies/base_registry_address/」の図3かな。あまりいろいろなアクターが新規・更新すると嫌な予感がする。ひとまず国でも自治体でもよいけど、プッシュなりで即反映は大事なのかなと思う。
頻度は即時ですね。過去・未来も参照できないといけないので（履歴を積む感じ）、「変更は市区町村の統廃合、分割や地名変更など」はいつでもOKですかね。明日から変わるぞ！定時後に情報更新や～は勘弁を。改元もそうですが、５月１日から令和でも、4月20日に一時的に令和にしてデータ処理・印刷・封入封緘をして5月1日に郵送着をする業種もあるので、お気をつけて！
まっユースケース、シナリオなどを作って、それぞれCRUDで整理したらいいんじゃないかな。ではデジタル庁さんあとはお任せします。
---
＞即時ということは（略）
ごめんなさい。土地取引がイメージできないので、自治体合併でいうと次の通り。
①人口減でA市とB市が合併し８月１０日からC市になることが決定。
②C市になったときの住所系の各コード（ID）と名称など関係各所に合意し、７月１０日にアドレス・ベース・レジストリ更新
→②を即時と使ってしまっている。
土地取引になっているかわかりかねますが、Aさんの土地をBさんにそのまま渡す・売る場合は、土地管理系システムで「土地XXXXはAさんからBさんに変わった」となるので、アドレス・ベース・レジストリは更新されないかと。
>速やかに実用レベルのアドレス・ベース・レジストリを整備し、標準化後の住民記録システムに実装されることを期待
住民記録以外も住所は参照するだろうから、
・デジタル庁でガバメントクラウドに宛名基盤を用意しそこに
アドレス・ベース・レジストリも内包
・各自治体システムは国が用意した宛名基盤を参照
・各自治体システムは都道府県コードなどコードだけ持つ
（将来的には位置情報だけでもよいのでは）
までして欲しい。
・市町村合併も宛名基盤上で一括データ変換
・自治体のデータ量減＝CSPへの支払い減
（住所など履歴を持つと、結構膨らむ。除票150年でしたっけ？）
など自治体の運用コストもより減るのでは？
「住所辞書が統一されていない」ので住所辞書ごとの変換も宛名基盤へのアップロード後に国が一括ですれば、変換ツールもベンダーごとに作らなくてよくないのでは。
個人的には以下も期待する
・標準20業務以外もア・ベ・レを強制
・民間も続かせないといけない
・EXCEl台帳などシステム外業務も何らかの手立てを
人情報レジストリも必須です。まずは番号法改正ですかね♪