次期個人番号カードタスクフォース（第1回）

概要

日時：令和5年9月7日（木）13時00分から15時00分まで
場所：オンライン会議
議事次第：

開会
議事
1. 次期個人番号カードタスクフォースについて
2. 次期個人番号カード仕様に係る検討事項について
3. 意見交換
閉会

資料

議事録等

日時

令和5年9月7日（木）13時00分から15時00分

場所

オンライン

出席者

座長

手塚悟　慶応義塾大学環境情報学部教授

構成員

有識者（敬称略・五十音順）

上原哲太郎　立命館大学情報理工学部教授
小尾高史　東京工業大学科学技術創成研究院准教授
宍戸常寿　東京大学法学部教授

地方公共団体

堀雅史　横浜市市民局窓口サービス課個人番号カード交付促進担当課長
坂田直也　神戸市企画調整局デジタル戦略部係長（代理出席）
佐藤泰格　都城市デジタル統括課主幹

関係省庁等

太刀川浩一　警察庁交通局長
村上敬亮　デジタル庁国民向けサービスグループ統括官
山野謙　総務省自治行政局長
福原申子　出入国在留管理庁在留管理支援部長（代理出席）
安藤俊英　外務省領事局長
大柳久幸　国税庁デジタル化・業務改革室長（代理出席）
日原知己　厚生労働省大臣官房審議官（代理出席）
菅原泰治　地方公共団体情報システム機構副理事長

概要

（1）次期個人番号カードタスクフォースについて

「次期個人番号カードタスクフォース」はデジタル庁が主催し、資料 1 の開催要綱に基づき開催される会議である。構成員については、資料1別紙に記載の通りとなる。
技術面については、「技術検討ワーキンググループ」を別途設置することとする。
本会議の運営はデジタル庁が行い、庶務は、デジタル庁国民向けサービスグループおよび、デジタル庁デジタル社会共通機能グループが共同で実施する。
座長については、慶応義塾大学環境情報学部、手塚悟教授にお願いしたいと考えている。
（異議なしの声）
手塚座長よりご挨拶を頂いた。

（2）次期個人番号カード仕様に係る検討事項について

デジタル庁より、資料3をもとに今後のスケジュールおよび今後の進め方の説明、資料4をもとに本タスクフォースにおける主な論点の説明がされた後、構成員から意見が述べられた。主な意見は、以下のとおり。

【1.（1）カードの券面記載事項全体について】

カードの使われ方が券面記載事項に引っ張られている。券面記載事項はできるだけ縮小し、最小限とする方が良い。
券面に印刷しないとなると、それを読み取るデバイスをどうするかという議論になる。政府であればマイナンバー専用デバイス、一般の方であればスマートフォンを活用する考え方がある。これらとマイナンバーカードとの組み合わせを考えながら、券面記載事項を考えることが必要である。
在留カードと一体化した場合、外国人の方は一体化したカードを身分証明書として利用することになるため、基本的身分事項である生年月日、性別、住所といった事項の確認方法がどのようになるのか関心がある。
イベント参加時の年齢確認や、先般の旅行支援での住所確認など、通常業務以外の臨時的な確認でも必要となるので、読み取り機のみで対応していくことには不安を感じる。
住民票の提出が求められているものをマイナンバーカードの確認で代替するように関係機関にお願いしているが、券面に表示されなくなった場合、住民票の提出をお願いすることになり、住民に費用負担が発生する運用になることを懸念している。
オンライン資格確認について、停電やシステム障害でカードリーダーが使えない場合にも、マイナンバーカードの券面事項を目視で確認し、被保険者資格申立書に券面事項を書いていただいて、保険給付を受けていただいている。このため、現行の制度では、住所を含め券面記載事項は大事なものであり、券面記載事項の検討は重要な論点である。
実際に身分証としてどのくらい使われているのか、コピーを提出させられているのか等を把握した上で、券面記載事項を削っていくかどうかを検討してはどうか。券面記載事項を削るのはよいが、その場合にマイナンバーと自分を証明するものを別途提出するということになると、マイナンバーやマイナンバーカード制度への批判につながりかねない。
券面に記載する情報量と見やすさはトレードオフの側面もあるので、記載事項、追記欄、デザイン等の検討に際して、十分に留意してほしい。
デジタル促進のために券面記載事項を思い切って削るべきという意見があったが、一挙に無くしてしまうかどうかについては、小さな自治体も含めた現場での使われ方や券面のコピーを提出させている民間利用の実態も踏まえて、しっかりと考える必要があるのではないか。
券面をなくす・なくさないの2択ではなく、その間があるのではないか。デジタル化を推進するために削った方がよいが、国からアプリやライブラリを無償配布するといったサポートがあるとよいのではないか。また、QRコードに氏名、住所、生年月日を含めることで安価にシステム化が可能であり、デジタルで読み込む、コストを下げるような仕組みを券面にどこまで乗せるのかという点も考えた方がよい。

【1.（1）①カードの券面記載事項（氏名、生年月日、住所の3情報及び顔写真）について】

カードを作って亡くなった方が今後増えた場合、顔写真がないと悪用される恐れがある。身分証として使うことがあるのであれば、顔写真は残すことになるのではないか。
住所等を券面に記載するか否かは、運転免許証とマイナンバーカードの一体化のメリットの1つである住所変更のワンストップサービス等に影響があり得る。
ICチップに格納される情報について、フリガナなどの情報が拡大されることによって、利用者の入力ミス防止につながる等、より正確かつ利便性も高く、システムで情報の取得ができることになると考える。
なくす、なくさないのように極端に振れなくてよい。身分証明書として使うことを考えると、顔写真、氏名、生年月日は必須である。変更の頻度が多い住所が最大の議論になるかと思う。住所を書くと変更する場合に追記欄が必要といった議論に発展するため、自治体の負担も踏まえて、住所の記載有無を検討する必要がある。
電子的にどう読み取るかについては、ベーシックアクセスコード、生年月日、有効期限、セキュリティコードがOCRでも読み取れないことがある。海外では太字で券面印刷して読み取りやすくしている。券面事項の確認手続きの電子化にあたり、スマホで券面のデータを読み取ることができ、J-LISの電子署名の検証ができるのであれば、それで十分である。このように使い勝手の良い仕組みに変え、券面には必要最低限の情報を記載すれば、もっと使いやすくできるのではないか。

【1.（1）②カードの券面記載事項（性別）について】

マイナンバーやマイナンバーカードそのものの問題というより、政府全体のジェンダーやセクシャリティに関する考え方と合わせるべきである。
市民から意見をいただくところがあり、性の多様性の観点、性の表明に関する様々な考え方がある状況のため、氏名等と同列での性別の記載には課題感を持っている。

【1.（1）③カードの券面記載事項（マイナンバー）について】

海外の銀行において、口座開設や送金の際にマイナンバーの提示を求められる事例が発生している。今後マイナンバーカードの国外利用が開始されることで、マイナンバーカードの提示を求められる機会も増えるため、引き続き券面にマイナンバーを記載した上で、その他記載事項については、英語の併記、和暦は西暦にすることが必要である。
税務署の窓口では、券面情報を見てマイナンバーの確認を行っている。マイナンバーカードから電子的に本人の情報を読み取れればいいが、暗証番号を忘れた場合に備え、券面にマイナンバーの記載があった方がよいという考え方もある。こうした点も含め、券面記載事項や、券面記載事項からマイナンバーを無くした場合の確認の代替方法の検討を行ってほしい。
マイナンバーは見える番号ではあるが、今般の紐づけ誤りの事例から、4情報ではなくマイナンバーで届け出ることが重要である。使い勝手を良くしないと、マイナンバーを出しづらくなって困るのではないか。また、マイナンバーカードには、外国の社会保障番号(SSN)でなりすましが多いという事態を踏まえて、なりすまし防止のためにマイナンバーと本人確認情報が一体的に載っている。そうした経緯も踏まえて、ICチップにマイナンバーを入れるとした場合には、どのように使い勝手を良くするのか、結果的になりすましが多くならないように検討する必要がある。

【1.（1）⑤カードの券面記載事項（その他記載事項）について】

氏名のローマ字表記については、日本で唯一ローマ字表記が公証された旅券と一致させる必要があるのではないか。旅券の交付を受けていない者についてローマ字表記をする場合には、今後旅券を申請する可能性があることを踏まえれば、旅券のローマ字表記記載ルールを適用する必要があるのではないか。

【1.（1）⑥カードの券面記載事項（追記欄）について】

追記欄に書かれた住所が正しいかわからないため、追記欄が偽造の温床になってしまう可能性がある。電子的な本人確認を主として考えるのであれば、追記欄は廃止がよいのではないか。紙で提出するから入力ミスが発生するということを考えると、券面をコピーして提出することはやめるのがよい。また、何か変更になったからと言って追記欄に記載することもやめた方がよいのではないか。
海外利用を踏まえた生年月日の西暦併記やローマ字氏名の記載が追記欄で対応することが予定されているところ、追記欄での対応となると自治体の窓口での手作業前提での記載になるため、なるべく避けてほしい。また、都市部だとよくあるが、複数回引っ越しをして、追記欄が無くなって再発行が必要となるケースも多くあり、追記欄の面積について課題を感じている。
転入手続きはオンライン化が検討される一方で、追記欄への記載は自治体窓口に持ってこなくてはいけないという状況も課題である。

【1.（1）⑦カードの券面記載事項（券面デザイン）について】

臓器提供意思欄は利用率が高くないと思う。マイナポータル上で意思表示が行える、検証機能の中で医療機関に伝わるような検討ができないか。

【1.（2）①暗号方式の在り方について】

現状のカードのハードウェア仕様の中で、ソフトウェアでできる限界を見極めておかないと、移行プランも含めた全体の設計がしにくいと思う。現状出回っているカードの仕様やその枚数の情報も検討の俎上に載せてもらいたい。
個人的には、暗号の要件で厄介なところは、現実的に事務が回るように緩めざるを得ないのではないか。
窓口で説明する立場からすると、電子証明書の有効期限とカード自体の有効期限の違いを理解いただけない状況があるので、わかりやすさの観点、手続き忘れの防止の観点から、有効期限を合わせる方向で検討できないか。

【1.（2）②暗証番号の入力のユーザー利便性向上について】

一枚のカードに責任主体が違うAPが載っていて、それぞれで認証しているのはよくない。AP毎に認証するのではなくカードで認証する等、方式の見直しが必要ではないか。また、ロングとショートの二つにした場合、ショートでアクセスできるところとできないところができてしまうと、話がややこしくなる。
APの構造自体を考えてもよいと思う。EUでは、基本的にはパスポートに相当するAPと、日本におけるJPKIに相当するAPが入っている。必要に応じて、今あるAPを統合、または一部の機能をJPKIに寄せる等、機能変更やAPがどうあるべきか考える必要があるのではないか。
旅券のオンライン申請では、4回のカードの読み込み、暗証番号の入力が求められるため、利用者から不満が寄せられている。これが1回で済むように検討すべきである。
暗証番号をロングとショートの2つにすることについては、現状3つある4桁の暗証番号を1本化する方が利用者も管理しやすくなり、自治体も説明や問い合わせ対応の負担が減ると考えられるため、方針としては賛成である。現状は、利用者に何度もカードの読み込みや、暗証番号の入力をしていただく場面があるが、最低限の入力で済むような仕組みにしてほしい。

【1.（2）③J-LISマイナンバー関係システムの刷新について】

カードAPやアルゴリズムを変更すると、周辺システムに大きな影響を与えるため、2026年の導入にこだわらずに政府の他のシステムの更新のタイミングも踏まえて、いつリリースするか慎重に考える必要がある。
運転免許証や在留カードの機能がマイナンバーカードに入ってくると、個人によって入っているAPが変わってくるという状況が出てくる。予めAPを全部入れておくか、それとも個人ごとに違うAPを入れるのか、J-LISの発行プロセスだけではなく、他の周辺APとの最適化や、どのようにこれらの機能を入れていくのか考える必要がある。
暗号方式の変更は、カード管理システムだけなく、JPKI、住基などマイナンバー関係の様々なシステムに影響する。システム改修規模の大きさを踏まえ、改修期間についても十分ご配慮いただきたい。

【1.（3）①カードの速やかな発行体制について】

カードの利用範囲を広げるほど、カード利用のニーズによっては、特急発行により1週間で交付しても長いと言われる可能性がある。
交付事務の円滑な運用の観点で、特急発行・交付の拡大における市町村やJ-LISの事務への影響について整理する必要がある。
外国人の方の利便性の観点から、速やかに発行させる仕組みにしてほしい。
カードの普及が進んで今後は更新が中心となる。更新の受付は3か月前から行っており、特急発行の必要性も含め議論が必要である。
バッチ処理システムを含めた抜本的な改善には、十分な検討、開発期間、財源の確保が必要となるため、費用対効果も含めた検討が必要である。
カードの交付前の準備事務についても見直しをお願いしたい。カードの検品、交付前設定がされた状態で自治体に納品され交付する仕組みの場合、セキュリティ面で課題があることは承知しているが、各種暗証番号を事前に設定しておくことで、窓口での手続き時間を短縮できるのではないか。体制強化、費用面に課題があるとは思うが、検討されている特急発行・交付の仕組みを応用して、通常のカード交付、カード発行体制にも生かせるような形で検討をお願いしたい。

【1.（3）②オンライン更新の在り方について】

今のまま行くと、去年今年発行した人の大量更新が一挙に来るので、希望される方に対しては、3か月単位ではなく年単位で前倒ししてもよいのではないか。
切り替えのタイミングや切り替え体制の平準化は非常に大事なテーマである。運転免許証は自分の生年月日前後で更新するのでわかりやすい。
市町村窓口に行くことなく更新を行うことを可能とするニーズは高いが、政府のガイドラインやNISTの身元確認保証レベルの基準に照らして、役所に赴かずとも、身元確認保証レベルを維持するためにはどういう方法があるのか。現状は顔写真が記載されているので、申請者の本人確認ができ、それがマイナンバーカードの信用性の基礎にもなっているため、よく検討が必要である。
今後、更新期限のラッシュが来ることも予想される中で、必ず役所への来所を求めることは関係者への負担が大きいと考えられる。
カードの更新時期が集中することが予想される。職員の手作業や手入力の部分はミスにつながることもあり、オンライン化についてはぜひ検討してほしい。
オンライン更新、PUK、電子証明書の10年更新、いずれも非常に助かる。カードの新規取得時にアナログで市民を相当支援したフェーズがあり、更新においても必要になってくるのではないか。
カードの再発行手数料も一つの論点にならないか。運転免許証の再発行は2000円を超えるくらいのコストで再発行するところ、カード再発行時のコストが上がっていくようなら、国民に早めに情報提供することが重要である。カードの更新を無償で続けていくのかという点も検討が必要ではないか。
身元保証レベルを担保するとすれば、カード更新の際に対面が前提となることはやむを得ないのではないか。ただし、自治体職員以外による本人確認として、例えば本人限定受取郵便による本人確認だと、事業者に代替する形で郵便局員が本人確認書類の提示を受けて対応しているかと思う。このような仕組みを活用して、特急でない交付の場合でも、自治体の介在無く、J-LISから直接カードを届けることを検討できないか。

【2.（1）次期カード発行直前に発行されるカードの電子証明書の扱いについて】

電子証明書の見直しに伴い、現行の電子証明書を前提としたシステムも改修する必要が生じ得ることも踏まえて検討する必要があるのではないか。

【2.（2）新旧カードの切り替えに伴うカード利用機関等への影響について】

現行カードから次期カードへ簡易に移行できる手続きを検討してはどうか。
次期カードにおいて新旧の暗号を扱うとする場合、カードに新旧の証明書を入れておくだけで読み取れるものなのか、読み取りが適切に行われるようにカードの仕様を変更する必要があるのか、処理性能に影響がないか、慎重な検証が必要である。
医療機関・薬局の100%近くで現行の顔認証付きカードリーダーが導入されており、9割近くで実際に運用が開始されている。券面記載事項の見直し等次期カードの検討に際しては、医療現場等において、現行同様あるいはそれ以上に円滑な運用が可能な形で次期カードへの移行が進められることが必要である。

【2.（3）ICチップの空き容量について】

費用の問題があるが、顔写真や他の利用シーンの拡大を考えると、容量だけではなくチップの性能、特に非接触の通信速度の部分について、どういうカードがあるのかは調べてみないとわからないが、そういった話も今後検討していく必要がある。

【2.（4）ISO認証（現在、ISO15408のCC認証を取得）について】

券面セキュリティについては、ISO22388の話が動いていると聞いているが、リリースまで時間がかかると思うので、それに合わせた検討になると思う。

【2.（7）PUK（PIN UNLOCK KEY）の発行（海外で採用例が多い）について】

市町村窓口の負担軽減につながるものである一方で、利用者で管理しきれるか、紛失した場合に自治体の問合せ対応が増えるのではないかといった管理の面で懸念があり、なるべく自治体に負担が生じないように配慮してほしい。

【2.（11）個人番号カードの呼称の変更について】

マイナンバーカードには個人番号カードと書いてある。法律上の名称は個人番号カードであり、マイナンバーカードは通称であるので、念頭に置いておいた方がよい。

【2.（12）インターフェイス仕様の公開について】

仕様がクローズ過ぎるがために、APが広がらないという問題意識は持っている。インターフェイス仕様の公開を含め、どんどん広げていっていただきたい。
インターフェイス仕様公開については、セキュリティに関わる内容でもあるため、慎重に議論いただきたい。

【2.（14）その他重要論点について】

マイナンバーカードの使い勝手は、カードそのものに加えてマイナポータルと連動させて、カードの魅力を引き出せるよう検討するとよいと思う。
今後、政府、自治体、医療分野で今まで親展郵便で送っていたものを電子的に送ることを考えると、JPKIの機能の一つとして、暗号化機能を入れてはどうか。

以上