全4824文字
PR

突合作業にマイナンバーは使えなかったのか

 では氏名・住所が呼び出せないとして、個人を特定できるマイナンバーを合わせて送信すれば、少なくとも世帯主の突合作業を省力化できたのではないか。

 だがこれも、少なくとも行政の判断では実行できない。2015年に施行されたマイナンバー法は、マイナンバーを利用できる事務(法定事務)を法律の別表で厳格に定めているためだ。この表にない事務にマイナンバーを使う場合、新たな法改正が必要になる。

 実は今回のオンライン申請では、マイナンバーは使えない一方、別のIDが世帯主の突合に使われた。マイナンバーカードで本人認証に使われる「利用者証明用電子証明書」のシリアル番号である。

 マイナンバーカードのICチップは2種類の電子証明書を格納している。電子契約や電子申請で署名・押印の代わりに使える「電子署名用電子証明書」と、マイナポータルへのログインや住民票のコンビニ発行などの本人認証に使う「利用者証明用電子証明書」だ。

 今回のオンライン申請は、ログイン不要のWebフォームに情報を入力し、マイナンバーカードで電子署名を施す方式である。この「電子署名用電子証明書」のシリアル番号を、証明書の発行主体である地方公共団体情報システム機構(J-LIS)のシステムを使って「利用者証明用電子証明書」のシリアル番号に変換し、申請者のIDとして自治体に通知しているのだ。

申請者がマイナンバーカードによる電子署名に必要なパスワードを忘れた結果、パスワードロックがかかってしまい、ロック解除のため役所で列をなす光景もみられた
申請者がマイナンバーカードによる電子署名に必要なパスワードを忘れた結果、パスワードロックがかかってしまい、ロック解除のため役所で列をなす光景もみられた
[画像のクリックで拡大表示]

 わざわざ電子署名用から利用者証明用にシリアル番号を変換したのは、多くの自治体が住民票のコンビニ発行などを実施しており、利用者証明用のシリアル番号から住民をひも付けるのは容易とみたからだ。二重申請をはじいたり、オンライン申請を受理した住民を郵送の対象から外したりする処理にも使える。

 だが、こうした行政の思惑は半分当たり、半分外れた。

 コンビニ発行などでシリアル番号を使い慣れた大規模な自治体は、職員がExcelやAccessを使い、シリアル番号を検索キーとして迅速に照合処理ができた。

 一方、コンビニ発行を実施していない自治体や、コンビニ発行システムを住民情報と切り離して運用している自治体などは、J-LISからシリアル番号の対応表を受け取ったり、コンビニ発行システムからデータを取り出したりして、住民情報とひも付けるなどの対処が必要だった。対処といっても数日~数週間あれば実行できるものだが、その間は目視など手作業での照合を強いられた。「自治体システムのパッケージベンダーによって、対応が容易な自治体、対応できない自治体に分かれたようだ」と楠正憲政府CIO補佐官は語る。

 照合システムをExcelの手製でなくITベンダーに発注し、結果として実装が遅れた自治体も多かったとみられる。J-LISは2020年5月18日に、CSVファイル形式の申請受付データと住民情報データをシリアル番号で照合して給付金台帳データを出力するWindows用ソフトの配布を始めた。だが、その頃には郵送処理の準備を整えた自治体も多く、遅きに失したと言わざるを得ない。

 そもそも、こうしたシリアル番号による照合という手法自体、マイナンバー制度の設計において予定された業務とは言えず、「盗人を見て縄をなう」式の運用という側面があった。

 電子証明書のシリアル番号は発行から5年で変更されるほか、番号の正しさを確認するチェックデジットの仕組みもない。マイナンバーや住基コードのように本人を確実に識別できるキーとしての利用は想定していなかった。

 ぴったりサービスを運用する行政機関も、慣れないシリアル番号の扱いでミスを犯した。オンライン申請を開始した5月1日当初、自治体に証明書のシリアル番号を送るつもりが、受託したITベンダーのプログラムミスで別のデータを上書きして送信してしまったのだ。

 同月3日に自治体からの指摘でデータの不整合に気づき、4日夜に修正した。この間、自治体はシリアル番号を使った突合ができなかった。「テストは実施したが、結果的には発見できなかった」と内閣府の担当者は語る。

リーマンや震災の教訓、生かされず

 今回、オンライン申請で一部自治体に混乱が見られた根本的な要因は、「全国民向けの現金給付申請をオンラインで受け付ける」という業務について、法律面、運用面の双方で事前の想定を怠ったことだろう。

 2020年4月20日に給付金が閣議決定してから、5月1日にぴったりサービスによるオンライン給付の受け付けを始めるまで、実質的な開発期間は2週間弱。5月8日には自治体向けQ&A集を公開し、「氏名の一致は同一性が確認できればよく、厳密な一致を求める必要はない」「世帯員の合計数が一致すれば氏名の一致を推定して事務を進めてよい」などと通知した。さらにぴったりサービスの仕様について自治体の要望を聞き取り、6月1日までに口座情報の入力補助など46件の改修を施した。

 だが、現場の努力による不眠不休の突貫工事で実現できることには限界がある。

 リーマン・ショックや東日本大震災の経験を踏まえれば、「全住民を対象とした給付申請」について、事前に行政機関と自治体でデータ処理や業務フローを標準化することもできたはずだ。その中で、給付用口座の事前登録、児童手当向け口座の活用などのアイデアも出てきただろう。

 現在のぴったりサービスは「紙での申請業務をそのまま電子化したシステム」にとどまっている。行政や自治体向け申請手続きの多くは「白紙の申請用紙に氏名・住所、申請内容を記載し、本人確認書類を添付して送る」方式であり、ぴったりサービスもこの申請方式を踏襲している。

 Webフォームは基本的に紙の申請用紙の項目と同じで、氏名や住所なども手入力させる。入力結果は、CSVファイルのほか紙の申請書に近い様式のPDFファイルとして自治体に届く。紙の申請と同じ業務フローで電子申請を処理できるようにするためだ。今回のオンライン申請でもExcelなどを使わず、PDFを紙に印刷して手作業で住民情報と照合した自治体もあった。

 ただ、こうした方式は民間のITサービスの使い勝手とはかけ離れている。これがデジタルファースト時代の電子政府のユーザーインターフェース(UI)として適切なのか。セキュリティーやプライバシー保護とUIの向上をどう両立させるか。過去の経緯にとらわれて思考停止することなく、民間を巻き込み、ゼロベースで検討すべきだろう。