次期マイナンバーカードの券面デザイン変更に備えて何かすべきですか？

券面の目視やOCRに依存した本人確認フローを持っている場合は、IC読み取り・JPKI軸の設計へ移行する計画が必要です。すでにICチップから情報を取得する設計であれば券面がどう変わっても影響はほぼなく、券面デザインそのものへの対応準備は不要です。

次期マイナンバーカード、開発者は何を備えるか

Q: 2027年の犯収法対応と次期カード対応は別々に進めるべきですか？

別々に構える必要はありません。どちらも券面ではなくICチップ（JPKI）を読むという同じ方向を向いています。2027年4月に向けてJPKI軸で設計しておけば、次期カード対応で残る作業は主に暗号方式まわりの確認に絞られるため、新規開発ではこの2つをひとつの設計判断として扱うのが効率的です。

「次期マイナンバーカード」というと券面デザインの話題が先に出てきますが、システムを作る側にとって本当に効くのはそこではありません。電子証明書の有効期間と、署名に使われる暗号方式が変わることです。本記事は、これから本人確認システムを新規開発する発注者と、既存の署名検証基盤を抱える開発責任者に向けて、次期カードの変更点のうち設計判断に影響するものだけを抜き出して整理します。2026年7月時点の情報にもとづきます。

この記事の要点

次期個人番号カードは、導入時期を2028年度へ後ろ倒しする方針が報じられています。ただし「まだ考えなくていい」わけではありません

開発者に効く変更は4つ。電子証明書の10年化、暗号方式の強化、券面記載事項の見直し、スマホ搭載側の更新です

最大の実装影響は暗号方式です。公開鍵をECDSA（P-384）、ハッシュをSHA-384へ移行する検討が示されており、現行のRSA 2048ビット／SHA-256と併存する移行期間を処理できる必要があります

2027年4月の犯収法改正に向けて今からシステムを作る事業者は、その設計が次期カードでも生き残るかを同時に確認すべきです

券面OCRに依存しない、IC読み取り・JPKI軸の設計にしておけば、券面変更の影響はほぼ受けません

まず時期の話。「2026年」ではなくなった

次期個人番号カード（次期マイナンバーカード）は、当初2026年中の導入が視野に入っているとされてきました。しかしその後、導入時期を2028年度へ後ろ倒しする方針が報じられています。来月から切り替わる、という性質の話ではありません。

では先送りしてよいかというと、そうではありません。理由は、いま作っているシステムの寿命のほうが長いからです。2026年から2027年にかけて本人確認システムを新規構築する事業者は、そのシステムを2028年度以降も使い続けます。次期カードの変更点のうち、設計時点で織り込んでおかないと後から作り直しになるものがあるなら、それは「今の判断」に含まれます。

特に、2027年4月の犯収法改正でマイナンバーカード方式への移行が進むことに対応するシステムを今から作る事業者は、次の2つを同時に満たす設計をしなければなりません。

2027年4月時点の要件を満たしていること
2028年度以降のカード世代でも、局所的な改修で動き続けること

この2つは矛盾しません。むしろ、後述するとおり「券面ではなくICチップを読む」という同じ方向を向いています。本人確認方式の全体像から確認したい場合はeKYC完全マップ2026を先にご覧ください。

開発者に効く変更点は4つ

デジタル庁のタスクフォースのとりまとめをもとに、システム側に影響する変更を整理します。影響度の順に並べると次のようになります。

変更点	実装への影響	対応の主体
暗号方式の強化（ECDSA-384／SHA-384検討）	大。署名検証・証明書チェーン検証の実装に直撃	検証を自前実装している側／ライブラリのバージョン管理
電子証明書の有効期間10年化	中。失効確認の設計の重要度が上がる	失効確認・アカウント継続の設計
券面記載事項の見直し（性別非表示など）	券面依存なら大、IC依存ならほぼゼロ	券面OCR・目視に依存したフロー
スマホ搭載側の更新	中。対応OS・APIの追随運用が必要	スマホ搭載での本人確認を使うシステム

以下、それぞれ詳しく見ていきます。

1. 電子証明書の有効期間が10年になる

現行の電子証明書は5年で更新が必要ですが、次期カードではカード本体と同じ10年に延長される方向です。

ユーザー側から見れば、更新切れによる認証失敗が減るという素直な改善です。5年ごとに市区町村の窓口へ行く必要があったものが10年に1度になれば、「久しぶりにログインしようとしたら証明書が切れていた」というトラブルは確実に減ります。

一方、システム側の含意はもう少し込み入っています。証明書が長寿命化するということは、発行から失効までの間に起こりうる出来事が増えるということです。10年のあいだに、氏名の変更、住所の異動、カードの紛失・再発行が起これば証明書は失効します。「有効期限が長いから安心」ではなく、「有効期限だけを見ていては不十分で、失効確認の重みが増す」と読むのが正しい理解です。

失効した証明書に紐づくアカウントをどう扱うか、再登録の導線をどう設計するかは、有効期間が長くなるほど発生頻度としては効いてきます。この論点は証明書失効とアカウント継続の設計で詳しく扱っています。また、そもそも署名用電子証明書と利用者証明用電子証明書のどちらを使うべきかという前提整理は2つの電子証明書の使い分けにまとめています。

2. 暗号方式の強化。ここが最大の実装影響

10年という長い有効期間に耐えるため、公開鍵暗号をECDSA（P-384）、ハッシュをSHA-384へ移行する検討が示されています。現行はRSA 2048ビット／SHA-256です。

項目	現行カード	次期カード（検討）
公開鍵暗号	RSA 2048ビット	ECDSA（P-384）
ハッシュ関数	SHA-256	SHA-384

これは検証側の実装に直撃します。RSAとECDSAは鍵の形式も署名の構造も異なるため、「鍵長を変えるだけ」では済みません。署名検証や証明書チェーン検証を自前で実装しているシステム、あるいは暗号ライブラリを古いバージョンに固定しているシステムは、対応可否をいま棚卸ししておく必要があります。

さらに厄介なのは、切り替えが一斉には起きないという点です。次期カードが発行され始めても、既存のカードは有効期限まで使われ続けます。つまり新旧両方式が混在する移行期間が必然的に発生するということです。検証処理は、提示された証明書のアルゴリズムを見て適切な検証経路を選べなければなりません。

実務的にやるべきことは次の3点です。

暗号アルゴリズムをコードにハードコードしていないか確認する。「RSAで検証する」と決め打ちした分岐がないか、ハッシュアルゴリズムがSHA-256固定になっていないかを探します
利用している暗号ライブラリがECDSA P-384とSHA-384を扱えるか確認する。扱えないバージョンに固定しているなら、更新計画を立てます
アルゴリズムを設定で切り替えられる構造にする（暗号アジリティ）。将来また方式が変わったときに、コード改修ではなく設定変更で追随できる形にしておくのが理想です

なお、署名検証は「署名を検証する」だけでは完結せず、証明書チェーンの検証と失効確認を正しい順序で行う必要があります。この実装レベルの論点は署名検証の正しい順序で扱っています。

3. 券面の変更。性別の非表示など

券面から性別の記載がなくなり（ICチップには記録されます）、記載事項やデザインが見直されます。

システム的な含意は明快です。券面の目視やOCRに依存した本人確認フローは影響を受けます。券面のレイアウトが変われば、座標や罫線を前提としたOCRの読み取り精度は当然落ちますし、性別を券面から取得している処理は取得元がなくなります。

もっとも、写真つきの券面を目視して確認するという発想自体が、犯収法改正によって縮小していく方向にあります。つまり券面変更への対応は、単独の課題として構えるより「券面ではなくICチップ（JPKI）を読む設計へ寄せる」という大きな流れの一部として処理するのが合理的です。

マイナンバーカードを使った本人確認の組み込み方式のうち、IC読み取り・JPKI系を軸にしておけば、券面がどう変わっても影響はほぼ受けません。そもそもICチップから取得するのは構造化されたデータであり、印字レイアウトとは独立しているからです。ICチップを読む処理が内部で何をしているかはマイナンバーカードをNFCで読む裏側を参照してください。

4. スマホ搭載側も動いている

カード本体とは別に、スマートフォンへの電子証明書搭載も更新が続いています。Android向けは2026年秋頃に刷新が予告されており、スマホ搭載での本人確認を利用するシステムは、対応OS・APIの変更告知を継続的に追う運用が必要です。

ここで意識しておきたいのは、これがカードの世代交代とは独立した別の変化軸だという点です。「次期カードは2028年度だから当面何も起きない」と考えていると、スマホ搭載側の更新を見落とします。カード世代とスマホ搭載サービスの更新は別々に進むので、追いかける情報源も分けて管理してください。

今やるべきことの結論

立場別に、いま手を動かすべきことを整理します。

新規開発の場合

券面OCRへの依存を避け、JPKI（IC読み取り、またはデジタル認証アプリ）を軸に設計します。これで犯収法2027年対応と次期カード対応の両方に耐えます
署名検証部分は、アルゴリズムを設定で差し替えられる構造にしておきます
ベンダーに実装を任せる場合は、RFPまたは要件定義の段階で「次期カードの暗号方式（ECDSA P-384／SHA-384）への対応方針」を確認事項に入れます

既存システムの場合

署名検証まわりの暗号方式が固定実装になっていないかを棚卸しします
利用している暗号ライブラリがECDSA-384／SHA-384を扱えるか、対応状況を確認します
券面OCRや券面目視に依存している処理を洗い出し、IC読み取りへ寄せる移行計画を立てます

やらなくてよいこと

券面デザイン変更そのものへの対応準備。券面に依存しない設計なら、見た目が変わっても影響はありません
2028年度を前提とした具体的な移行スケジュールの確定。時期は方針として報じられている段階であり、いま固定すべきは「変更に耐える構造」であってスケジュールではありません

棚卸しチェックリスト

既存システムを持っている場合、次の項目に答えを出しておくと移行時の慌てが減ります。

署名検証の実装箇所を特定したか（自前実装か、ライブラリか、ベンダーのSDKか）
暗号アルゴリズム・ハッシュアルゴリズムがコード内に固定値として埋め込まれていないか
利用中の暗号ライブラリのバージョンと、ECDSA P-384／SHA-384のサポート状況を確認したか
新旧の暗号方式が混在する期間に、提示された証明書のアルゴリズムを見て検証経路を切り替えられるか
失効確認の実装が、証明書の有効期限チェックとは別に存在するか
券面のOCR・目視結果に依存している処理を洗い出したか（性別の取得を含む）
スマホ搭載を利用している場合、対応OS・APIの変更告知を追う担当と手順が決まっているか
ベンダーに委託している場合、次期カード対応の責任範囲と費用負担が契約上明確か

本人確認まわりの記事をどの順で読むと全体像がつかめるかはeKYC記事の読み方ガイドにまとめています。

まとめ

次期個人番号カードは2028年度へ後ろ倒しする方針が報じられていますが、いま作るシステムの設計判断には既に効いています
最大の実装影響は暗号方式の強化です。ECDSA（P-384）／SHA-384への移行検討が示されており、現行のRSA 2048ビット／SHA-256と併存する移行期間を処理できる必要があります
電子証明書は10年化の方向です。有効期限だけに頼れなくなる分、失効確認とアカウント継続の設計の重要度が上がります
券面は変わりますが、IC読み取り・JPKI軸の設計なら影響はほぼありません。券面OCR依存からの脱却は犯収法対応と同じ方向を向いています
スマホ搭載側はカードとは別軸で更新が続きます。Android向けは2026年秋頃の刷新が予告されており、告知を追う運用が必要です

よくある質問

Q. 次期マイナンバーカードはいつ導入されますか？

当初は2026年中の導入が視野とされていましたが、その後、導入時期を2028年度へ後ろ倒しする方針が報じられています。ただし、いま構築する本人確認システムは2028年度以降も使い続けることになるため、設計段階で次期カードの変更点を織り込んでおく必要があります。

Q. 次期マイナンバーカードで開発者に影響する変更は何ですか？

4つあります。電子証明書の有効期間が10年に延長されること、公開鍵暗号がECDSA（P-384）・ハッシュがSHA-384へ移行する検討が示されていること、券面の記載事項が見直され性別の記載がなくなること（ICチップには記録）、そしてスマートフォンへの電子証明書搭載サービスの更新が続いていることです。実装への影響が最も大きいのは暗号方式の変更です。

Q. 次期マイナンバーカードの暗号方式はどう変わりますか？

現行はRSA 2048ビット／SHA-256ですが、次期カードでは10年の有効期間に耐えるため、公開鍵暗号をECDSA（P-384）、ハッシュをSHA-384へ移行する検討が示されています。署名検証や証明書チェーン検証を自前実装している、あるいは暗号ライブラリを古いバージョンに固定しているシステムは対応可否の確認が必要です。

Q. 新旧の暗号方式が混在する期間はありますか？

あります。次期カードの発行が始まっても既存のカードは有効期限まで使われ続けるため、新旧両方式が混在する移行期間が発生します。検証処理は、提示された証明書のアルゴリズムを見て適切な検証経路を選べる構造にしておく必要があります。アルゴリズムを設定で切り替えられるようにする暗号アジリティの確保が有効です。

Q. 電子証明書が10年有効になると何が変わりますか？

ユーザーの更新切れによる認証失敗は減ります。一方で有効期間が長い分、その間に氏名変更・住所異動・カードの紛失再発行などで証明書が失効する可能性が相対的に高まります。有効期限のチェックだけでは足りず、失効確認の設計と、失効したアカウントの継続・再登録の導線設計の重要度が上がります。

Q. 券面デザインの変更に備えて何かすべきですか？

券面の目視やOCRに依存した本人確認フローを持っている場合は、IC読み取り・JPKI軸の設計へ移行する計画が必要です。逆に、すでにICチップから情報を取得する設計であれば、券面がどう変わっても影響はほぼありません。券面デザインそのものへの対応準備は不要です。

Q. 2027年の犯収法対応と次期カード対応は別々に進めるべきですか？

別々に構える必要はありません。どちらも「券面ではなくICチップ（JPKI）を読む」という同じ方向を向いています。2027年4月に向けてJPKI軸で設計しておけば、次期カード対応で残る作業は主に暗号方式まわりの確認に絞られます。新規開発ではこの2つをひとつの設計判断として扱うのが効率的です。

主な参考資料: デジタル庁次期個人番号カードタスクフォース最終とりまとめ（案）概要、日経クロステック「デザインだけじゃない、記載事項や暗号方式も変わる『次期個人番号カード』」、デジタル庁 Androidスマホ用電子証明書搭載サービスのお知らせ

TodoONada株式会社では、マイナンバーカード認証（JPKI・eKYC）を組み込んだWebサービス・スマホアプリの受託開発を行っています。方式選定（JPKI・IC読取り・画像方式）から開発・運用までワンストップで支援し、既存システムの署名検証まわりの棚卸しや、犯収法2027年対応と次期カード対応をまとめて設計する上流の相談にも対応します。デジタル庁「デジタル認証アプリ」の利用申請・審査対応も、書類作成から指摘対応まで伴走します。料金の目安は認証機能組込みプラン150万円〜、認証込みアプリ開発プラン400万円〜、大規模・個別要件は1,000万円〜です。ご相談はマイナンバーシステム導入支援またはお問い合わせからどうぞ。

この記事に関連するサービス

TodoONada株式会社では、マイナンバーカード認証を組み込んだシステム開発を行っています。

マイナンバーシステム導入支援 — JPKI・eKYC対応の本人確認をワンストップで

導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。