ベース・レジストリのメニューがそろった！
将来の社会基盤であるベース・レジストリの指定が2021年5月26日に行われました。これまで多くの期待が寄せられてきましたが、実際に何が指定され、何が指定されなかったのか、何が課題なのか、実際にどのように使えるようになるのか。何をしなければいけないのかを整理していきます。
どのような基準で何が選ばれたのでしょうか
昨年12月に公表したベース・レジストリのロードマップでは、①多くの手続きで利用されるデータ、②災害等の緊急時に必要なデータ、③社会的・経済的効果が大きいデータ、の観点からベース・レジストリの重点整備候補を選定しましたが、今回のベース・レジストリの指定は、①社会的ニーズ、②経済効果、③即効性、の観点から整理をしました。また、この中でも実現が容易なものと時間がかかるものがあり、そこでも区分をすることとしました。
まず、できるものからスモールセクセスでいこうというのが区分①です。そして、調整事項が多いものなどを区分②にしています。
どちらの区分にしても、将来の社会の基盤として必須のものをあげており、これからの整備に向けた意気込みを示したものになっています。
今回の指定は、コア中のコアのベース・レジストリと、容易に実現が可能でショーケースになりえるところを重点的に選定しています。
ベース・レジストリで個人に関する情報は重要ですが、マイナンバー等の議論が別途行われているので、その進展を見て進めていく必要があり区分②にしています。また、不動産や法人の登記も見直し範囲が広範なことから区分②にしています。
もっと広く推進すると期待していたのに・・・
もっと広くベースレジストリの対象を指定して一気にデータ基盤を作っていくことを期待した人も多いと思います。でも基礎から固めていくことが重要なのです。いきなり避難所のベース・レジストリを作るというよりも、学校などの公共施設のベース・レジストリを作ってから、情報をアドオンしていったほうが基礎情報の一元化はできるし、メンテナンスも楽になります。
これまでにない取り組みなので、小さく始めて経験を蓄積してから展開していくことを考えています。
これまでの政府のプロジェクトは、ノウハウもないのに全部同時に導入し失敗したものが数多くありますし、スモールスタートといいながらそのあとがつながらない実証実験も数多くありました。ベースレジストリの推進では、これまでの失敗を繰り返さないように、実践的な実証をしながら経験を積み、その中で人材を育成しながら対象を広げていこうとしています。
では、指定されなかったものはどうすればいいんだよという疑問もあると思います。ベース・レジストリに指定されなくても、各分野でデータを標準化して整備していけばよいものもあります。ベース・レジストリの基盤になるのはデータ標準です。データを効率的に維持管理し連携させていくにはデータ標準が欠かせません。そうした点から、ベース・レジストリになっていない情報も含めデータ標準化を強力に進めていく予定です。
課題１：指定にあたって顕在化した「ベース・レジストリはどれだ」という問題
法人データは、登記で登録され、国税庁に送られます。国税庁では文字の範囲を縮退したり住所表記を修正するなどのデータのクレンジングがされ、法人番号や英語法人名が付加されて公開されます。さらに、経済産業省が法人情報の提供サイトであるgBizInfoで、代表者名や決算情報なども追加して公開しています。このように複数機関で情報が連鎖して公開されています。
レジストリという点では法人が法律に従い届けるのは法務省の商業登記です。他機関から使えるかという観点からみると、法人番号付与のため国税庁にデータを提供しています。しかし、各国がベース・レジストリとして一般に公開するデータであるのに対して、提供範囲が極めて限定的です。管理しているデータは、一般のシステムでは表示できない外字があり、住所表記変更や本社移転が更新されていないデータも含まれています。こうしたことから、ワンスオンリーサービスの申請で既登録データを自動入力することや自動審査で使うのは難しいと考えられます。
2段階目の国税庁は、文字データをJIS第4水準に縮退して、さらに実務で必要な英語名も付加してAPIでオープンにデータを公開しています。登記情報に外字を含んでいるときには画像で確認できるようにする等、原本性も確保しています。ワンスオンリーという面で見ると、実質的にこのデータがベース・レジストリではないかとみることができます。
3段階目の経済産業省の提供する法人情報サイトのgBizInfoはどうでしょう。国税庁のデータをはじめ各府省の保有する法人関連データを集めてAPIで情報提供しています。申請をワンスオンリー化するという点では、このデータが項目数が多く最も利便性が高いです。一部の法人は、申請フォームに法人番号を入れれば、法人名、代表者名、決算データ、証明データ（政府調達の統一資格等）などを一括して入力したり審査することができます。今後、ここに集積する情報を充実させることで、ワンスオンリーサービスを通じて法人手続きの大幅な利便性向上が実現できると考えられます。実務上は全く問題ないというより便利になっていますが、厳密にみると、法人の外字は代替した文字で示されるし、法人の住所もクレンジング済みのものであり、法的な登記情報と表記が100%一致しているわけではありません。
このように3重管理になっている場合、どれがベース・レジストリなのでしょうか。ベース・レジストリ先進国であれば、最初に登録するときにデータをクレンジングして、そのデータをAPI連携させて重複させずに管理しているのでこのような問題がありませんが、既存のデータや制度をもとに作ってきた日本の場合はこのようなことが起こります。（海外もコピーデータを中間の他機関のサーバで保持してサービス提供する場合はあります。）
そのため、当面の対策として登記情報、法人番号公表サイト、gBizInfoを3重に指定しています。
戸籍と住民基本台帳も同じ問題があります。基本的に戸籍の文字を住民基本台帳で継承しているのですが、いくつか戸籍統一文字にない文字を住民基本台帳ネットワーク統一文字で追加したものがあります。またデータ項目も戸籍には相続情報があり、住民基本台帳には世帯情報があるなど、違いがあるため、両方のデータを検討する必要があります。
課題２：ベースレジストリ以前の「データ共有」という基本思想の問題
日本のデータ管理の基本的考え方は「データを目的外に利用しません」というものです。業務のサービスはもちろんのことアンケートでも必ず「このデータを目的以外に利用しません」と定型句が書かれています。これは、オープンデータ推進時から課題でした。複数のデータを重ね合わせようとしても「データを目的外に利用しません」の一言でできなくなってしまいます。また、メディアも世論もこの言葉が大好きで、少しでも目的から外れているのではないかというサービスが始まると、一斉に大炎上させます。そのため、多くの企業がデータ利用に委縮してしまっています。匿名データの話でも相当安全サイドに振った議論が行われています。
一方、ベース・レジストリは、公益性を鑑み社会全体でデータを使っていこうという思想のもとで推進されています。もちろん何でもオープンデータにしようといっているわけではありません。ベース・レジストリの先進国では、「データの公益性を考え、適切な公開範囲に対して、適切なアクセス管理の下で、データを共有する」という考えで取り組みを進めています。
これは、本来はデジタル手続法でワンスオンリーやワンストップサービスを定義したときに議論するべき内容でした。一度提出した情報を再利用したり他機関に提供することを前提とした法律ですので、データの目的外利用と共有の考え方はその段階で整理される必要がありました。
もう一つの考え方として、データは誰のものかという視点もあります。自分が提出した情報を自分が再利用するのに目的外利用も何もないだろとか、自分の許可した範囲なら使えるようにしてほしいという意見があります。要するにオプトイン、オプトアウトの活用なのですが、既存の申請を受け付けている部門にデータ再利用の仕組みを追加するのは、その部門に直接メリットがある話ではないので進めるのが難しいテーマです。
そうなると、今度はパーソナル・データ・ストア（ＰＤＳ）的な視点が出てきます。自分の基本データを民間サービスに預けているから、そこから基本データを入力するという考え方です。既にＳＮＳサービスでログインすると各種データが引き継がれるサービスがありますし、会計サービスでもそのようなサービスがあります。昔から、税理士が税務申告書類を記入してくれるサービスの現代版のようなイメージです。
ベース・レジストリ推進では、このような根本のところまで検討する必要があるのです。
課題３：「ありそうでない」データをどう整備するのか
行政機関にはありそうでないデータというものがたくさんあります。日本中の住所が一元化された一覧はありません。そんな馬鹿なと思うかもしれませんが、市区町村が保有していて統合されていません。郵便番号やカーナビで出てくるではないかとか、地図の住所はどうなっているのかと思うかもしれませんが、町字名、緯度経度、形状等やヨミガナや英字名など、日本の正式で最新のデータであると定義されたものがないのです。そもそも氏名に正式なヨミガナはないですし、日本中の店舗や事業所の一覧も正確なものがないなど、かなりあいまいに運用されてきています。「ほぼあります」、「ほぼ正確です」というデータはたくさんあるのですが、最新で正確なデータというとないもの多いのです。
当該情報の巨大なデータを持っている部門に行っても「目的外利用できません」から始まり「うちのデータの対象範囲はすべてを網羅していない」「最新化はしていない」「既存システムが対応できない」「制度外である」「他のサービスが便利になる機能は必要ない」等で協力を得られないことが多いです。
文字情報（漢字）は、ベースレジストリの前からこの問題に直面し、戸籍統一文字、住民基本台帳ネットワーク統一文字、登記統一文字の3つの文字セットがありましたが、戸籍統一文字、住民基本台帳ネットワーク統一文字を包含する文字セットを作り、それに登記統一文字を縮退するという方法をとることで、今回ベースレジストリと指定した文字情報基盤という一つの文字セットにすることに成功しましたが調整に10年以上かかっています。
「ありそうでない」データを整備するのは、担当部門も明確でない新しい仕組みなので検討するのが大変なのです。
課題４：そもそも「用語定義」からスタートする分野さえある
住所と書いてきましたが、ベースレジストリに指定したものは「アドレス」としています。多くの人は住所と考えているかもしれませんが、「「住所」とは住むところであり、住所という言葉は使うべきではない」という指摘があります。法務省では「所在」という言葉を使っています。また「所在地」や「地番」「地籍」等の近い概念の言葉があるのですが、皆さんに伝わりません。その結果、それらを包含的に含む「アドレス」という用語を使うこととなりました。「カタカナを使うな」という意見もあるかもしれませんが、日本語で新語を作ってもわかりにくいし、世界各国が持っている住所DBはAddressDBという名前のことが多いので「アドレス」にしました。住所に関連して、町名などを示す「町字」もわかりにくいし、建物名を示す「方書（かたがき）」なんて、すでにPCでの文字変換に出てこないし、下宿している人はそんなにいないし、このようなところから見直していく必要があります。
課題５：正確で最新のデータでないものをベース・レジストリにしてよいのか
ベース・レジストリの指定に向け、「正確性や最新性が保証されていないデータをベースレジストリに指定してよいのか」という指摘もありました。しかし、世の中には完璧なものはありません。20年前から整備しているエストニアさえ、時々エラーが出るといっているのに、これから始める日本のベース・レジストリに完璧性、無謬性を求めるのは無理があります。むしろ改善プロセスを作っていくことが重要です。
課題６：運用に向けた役割や責任の分担が必要
ベース・レジストリからワンスオンリーで読み込んだデータが違っていたり、修正が必要な場合にどうするのか、また、ベース・レジストリが障害などで停止しているときにどうするのかという課題があります。
法人情報を提供するｇBizInfoには社長名が違う等の修正依頼がきたりします。これらの依頼は、レジストリである元のデータを提供している部門に修正を依頼してもらうように案内をしています。ワンスオンリーサービスを提供する部門に来る意見をどのようにベース・レジストリを担当する部門に伝えるのか、その時に利用者に不便をかけさせないようにするための共通ルールを検討する必要があります。ワンスオンリーサービスを提供するフロント部門にベース・レジストリの問い合わせが多くなるようでは、ベース・レジストリを活用する部門のモチベーションが下がってしまいますので、データの流れに従った検討が必要になります。
具体的には、法人のワンスオンリーサービスを考えると、本社の登記住所が異なっていた場合に、登記のデータから直す必要があります。登記変更には取締役会の議事録や登記変更手数料の印紙3万円をもとに法務局で手続きする必要がありますが、こうした手続きもワンストップでできないかと利用者は考えますので対応策の検討が必要になります。
ベース・レジストリの障害対策も各国で取り組みが違います。スロバキアではメッセージ管理のフロントシステムを作ることで責任をそこで切り分けています。日本でこのような共通システムでは、注意書きで「十分時間的余裕をもって申請してください」としていますが、ベースレジストリの運用時にはAPIによる自動連携が増えることから、もう少し検討が必要かもしれません。
このように運用でも多くの課題が出てきます。
課題７：簡易表記というあいまいデータ
ベース・レジストリではなくデジタル手続き全体の問題として文字の簡易表記の問題があります。登記や戸籍では７万文字近くの文字を使っていますが、一般の行政システムではJIS第4水準の1万文字しか使えません。申請によっては2136文字しかない常用漢字で申請をするものもあります。そうすると渡邊さんが渡辺で申請することになります。（この邊はPCで表示可能ですが、辺は30文字以上の異体字があります）
多くの法律では「氏名を記載」と定義する場合が多いのですが、氏名とは何かということをベース・レジストリでは考える必要があります。簡易表記した氏名は、法律でいう氏名とみなしてよいのかが明確ではありません。これまで、手書きの時には多くの人が普通に簡易表記を使い、申請を受け付けていましたが、データというか文字コードになると明確に違う文字になります。こうしたものをデジタル社会でどのように受け止めていくかデジタル技術の話ではなく制度設計の話として議論していく必要があります。
マイナンバーに合わせて代替文字が導入されていますのでこの文字を活用していくのも一案ではないでしょうか。
課題８：決算情報とは、税務会計か財務会計か
申請書に決算情報として税務申告の情報の複写を添付する場合が多くありますが、それは税務会計の情報で、審査目的として十分なデータなのかという意見があります。また、これは税務署に申告したデータであり、納税証明書の納税額と合わせて確認しないと確定値かどうかわからないのではないかという意見もあります。一方で、財務会計データを使うべきといっても、会社法で義務化されているにもかかわらず決算公告をしていない企業が多いのが実態です。
ベース・レジストリの指定では、活用目的を考えれば企業の経営状況を表す財務会計で行くべきであるとの議論となり、決算公告をベース・レジストリに指定しています。今後は、決算公告の推進も必要になるし、審査書類も変わるなど大きな変更を伴うので、時間をかけて取り組んでいくことが必要です。
何がいつできるようになるのか
こんなに本質的な課題があって進めていけるのかと思うかも知れません。でもこれはベース・レジストリの問題だけでなく、デジタル・ガバメント全体の問題です。ベース・レジストリを作ろうとして、これまで先送りにしてきた問題や気が付かなかった問題が次々と掘り起こされています。各担当部門が解決していくべきものもありますが、だれが検討すればよいのかという制度的な課題もあります。政府一丸となって検討を進めていく必要があります。
そうはいっても着手できるところもたくさんあるので、まずは、オープンデータ系のところを重点的に進めていくことになります。公共施設情報、制度情報、イベント情報を対象として、データ収集や活用できる環境を作っていきます。また、ニーズが大きいこととデータや仕組みの体系化が進んできていることから法人関連データも集中的に進めていくこととなります。ここで得られるノウハウは様々な分野で活かせると思います。
困難な領域にも積極的に取り組む必要があるので、事業所、アドレスなどで実証が行われます。そこができると、ワンスオンリーも行いやすくなるはずです。
何を意識しなければならないのか
申請システムを作っている部門では、デジタル手続法に従いワンスオンリーを検討しなければならなくなります。
設計では、法人番号を入力して本社住所を呼び出すなど、ベース・レジストリを活用してワンスオンリーにできないかの検討を行います。ベース・レジストリがサービス提供がまだできていなくても、申請データの形式を標準を意識して作ることで将来のベース・レジストリ活用への移行性を高めることができます。
資格などの証明書を提供する府省では、証明書を利用する府省が自動審査できるように資格データにデータ標準を使いAPIを提供することが重要になります。自システムを持つのではなくｇBizInfo等の情報のハブに資格情報を提供する方法もあります。
これらの取り組みを支援するために、IT室では行政サービス・データ連携モデル（β版）を提供しているので、参照すると検討が進めやすいと思います。
ベースレジストリに指定されると何がうれしいのか
ベース・レジストリに指定されたけど、何がうれしいのよと思う部門もあるかと思います。まず言われるのが、予算が優先的につくのかと聞かれます。それは保証されませんが、ベース・レジストリとして幅広く社会に役に立ち効率性を高められることから、経済効果を整理することで予算は確保しやすくなると考えられます。各省や自治体で重複していた予算を集約してベース・レジストリを高度化することで、各国は1.2倍とかの小さな効果ではなく4倍とか10倍とかの大きな投資対効果を出しています。このようなモデルを考えることで予算は要求しやすくなると考えられます。
また、指定されたベース・レジストリは技術的支援が受けられます。上述の経済性分析や標準の適用、データ設計などの支援を受けて効率的なデータ運営ができるようになります。特に品質管理は今後のデータサービス運営で重要であり、診断などを行うことで自データの品質が向上でき、運用経費の低減やサービスレベル向上が期待できます。
さらに、先進各国で行われているのがワンスオンリーの推進が政府全体で推進されることが重要です。様々なサービスから参照すべきデータとして位置づけられることでアクセスが増大し、データの利用が拡大することで経済効果が大きくなります。そしてまた投資をして、より高度なサービスを検討していくことができるようになります。
ベースレジストリは、デジタル社会における投資と位置付けることが重要です。
頑張ろう
2025年までに仕組みを整備して2030年までにデータを整備することとなっています。でも課題は山積です。今回指定されなかったデータも、追加で指定するかもしれませんし、各分野のベース・レジストリを整備していく方法もあります。また、ベース・レジストリだけでなく、社会全体で多くのデータがあります。米国ではプライオリティデータとして主要なデータを幅広に指定して推進をしています。
身近なできるところから頑張っていくことが重要ではないでしょうか。
この記事が気に入ったらサポートをしてみませんか？