Photo by
soeji
データ戦略へのご意見をお寄せください(期間：2021/10/26 ~ 2021/11/09)
■ベース・レジストリの「個人」にDV・ストーカなどの「警告情報」も入れるべき
ベース・レジストリの「個人」にDV・ストーカなどの「警告情報」も入れるべきではと思います。
キーワードに「官民連携」「ワンスオンリー」「エンドツーエンド」「即時性」という効率化があるので、安全性を担保しないといけないかと。
自治体で管理する警告情報をベース・レジストリで管理し、民も必要に応じて参照させることで、業者によりワンストップの業者ポータル（*1）、民間電子サービスにおいても被害者保護になるのではと思います。
事例）発行事務において加害者に被害者の情報を渡す
事例）情報提供NWS・中間サーバを介しての情報連携警告情報設定漏れなどにより、情報照会側で加害者への被害者情報提供してしまう。現在、自治体システムでは住登外者の最新警告情報がないことが多いと認識しており、このリスクがある認識（含、マイナポータル）
最後に、警告情報は自治体はCRUD、民間はR、DV指定できる裁判所（？）などもCRUDと警告情報の取扱者の整理、自治体が設定したものは裁判所で上書きできるかなどユースケースを漏れなく行い、横串で検討いただければと存じます。
つまりのところ、
現在）自治体にDV申請すると、以降、発行禁止などになり、加害者に被害者の情報が渡らない。ただし、住民票を置かない自治体、省庁、民間サービスから漏れる可能性がある。
今後）DV認定、自治体、マイナポータルから加害者側設定すると、あらゆるサービスから発行・データ照会されない被害者保護が完璧である。
ということです。
最後に、非電子システム部分の教育も必要になるかと思います。制度的な面も必要に応じて検討いただきたく。
最後に、中の人ではないので誤りがあれば申し訳ないです。
効率化により被害者への2次災害が出ないことを願います。
*1:https://cio.go.jp/onestop-hikkoshi、https://www.soumu.go.jp/main_content/000759085.pdf
＜参考文献＞
標準仕様、デジガバ計画、重点計画
旧アイデアボックス
https://ideabox.cio.go.jp/ja/idea/07318/
データ戦略タスクフォース（第７回）のベースレジストリ
https://www.kantei.go.jp/jp/singi/it2/dgov/data_strategy_tf/dai7/siryou3-1.pdf
ベース・レジストリの指定について
https://cio.go.jp/node/2764
ベース・レジストリとしての住所・所在地マスターデータ整備について
https://cio.go.jp/dp2021_03
■日本全システム「IPAmj明朝」対応！移行計画
自治体システムは文字情報基盤の「IPAmj明朝」になるようだ。ただ、民間も追随してもらわないと意味がない認識のため、字形を渡せば文字コードを返すAPIなどを官民問わず使えるように国が用意してください。
＜理由＞
○自治体目線
・文字の同定は自治体によっては大変な作業である。
・JIS2004対応ではベンダーに依頼して切り抜けたところも多いとすると、自治体1700以上の移行を1年でするという計画なので、ベンダーは移行で手がいっぱいだろう。自治体は自力で頑張るしかないかと。。でも出来るのか？？「私の名前が違う！」と窓口クレームは起こりそう・・。
○民間：2025年以降2030年ターゲット？
・民間もベースレジストリからデータ参照すると、外字問題が勃発し、結局、シームレスを邪魔する認識である。
・いつまでたっても外字問題が壁でDXが促進しない。
・促進すべく”外字は他機関では内字にして連携！”と仮にしても、また文字同定発生。
＜手抜きイメージ＞
・外字字形ごとの文字コードを日本で一意に！
・字形などを渡せばAI-OCRが文字コードを渡してくれて全機関で文字コードと字形は一意にしましょ！移行も楽ちん！
・結果が既存にない（外字）場合、ベースレジストリの文字基盤に字形・文字コードが登録され、外字ファイル（EUDC.TTE）が配信され、各機関システムは取り込む
・ベースレジストリの「法人」などに登録されている機関にプッシュ機能で各機関に通知する（法人設立申請でベースレジストリ「法人」に登録され、サービスメッシュでプッシュ）
・定期的にDB内で誤り字形・文字コードがないかチェックできるツールを提供して、私の漢字が違う！とクレームがないようにしましょう！！
・政策企画・検証のための匿名加工情報等のデータも綺麗綺麗。
＜これが大変なら＞
・各システムで氏名・住所は持たずにベースレジストリあたりで、常に参照させましょうか？ベースレジストリ内は分散台帳技術を使いましょう。要は、日本のシステムでの4情報、マイナンバーなどはブラックボックス化で隠してしまいましょう！（別途、起票しました）
・個人情報アレルギーが強い国民性があるので、しっかりと安全性を説明しないといけないですね。
＜ざっくりアクションプラン＞
・2022年→VRSで外字問題解決しましょう！
・2023年→住基ネット、中間サーバなどの国側システムでデータ移行（文字コード変換）をしましょう！既存システムにはそのまま渡したら駄目駄目ですよ。
・2025年→自治体の移行作業でAI-OCRの精度を99.9%に高めましょう！国側システムで教育して賢い子を育てる理由はここで手修正不要にするためです。
・以降→→省庁のシステム更改、民間も含めて日本は全システム「IPAmj明朝」で行きましょう！シームレス文字変換！！！
以上、民間からデジタル庁に入った人のNOTEを読むと、MVP、アジェイル、DevSecOpsだそうですね。日本のIT業界に見本を見せるべく本年度中にリリース期待しています！余裕ですよね！ね♪（除、AIを育てる）。デジタル庁の民間出身者が挨拶がてらに自作でGO！
■情報漏えいしても大丈ブイ(^^)v
攻撃された！設定ミスした！情報漏えい。一層のことベース・レジストリ以外にマイナンバー、住民票コード、４情報などは保存駄目！ベース・レジストリ参照にすればよいのでは。情報漏えいしても大丈夫という発想です。
例えば、中間サーバーって機関別符号で個人情報を持っているので「誰や！このデータ」になる認識です。これを民間システムに強制するということ。
これで住所の「１丁目１番」「１－１」「1-1」とかベース・レジストリ上でデジタル庁のツールで一括変換ですね！区画変更、市町村合併などによる住所、郵便番号、行政の住所などの変更も全国のシステムで変更！とかなくなりますかね。
人口減！働き手減！補助金激減！でも、一括で対応完了！にならないですかね。
本物のインフラ・セキュリティエンジニアを確保しないといけないのでしょうけど。。。
ということで分散型台帳技術は何使います？これで「IPAmj明朝」移行も楽になりそう。
中間サーバ、情報提供NWSだけでなく、住基ネット、団体内統合宛名システム捨てて「エンドツーエンド」「即時性重視」しましょう。頑張って法改正♪
この記事が気に入ったらサポートをしてみませんか？