【第2回】 「JPKI一本化」の課題
――担当者が直視すべき機会損失と隠れたリスク

サイバートラスト株式会社　山田 拓輝 氏（プロダクトマネージャー）

【CTJ 山田氏】
確かにJPKIは機能として非常に優れています。住所変更の検知や、電子証明書の一意性にもとづく二重登録防止など、事業者にとってメリットが大きいのは間違いありません。

ただ、冷静に数字を見る必要があります。
現在、マイナンバーカードの普及率は人口の約8割（※2026年1月時点）と言われていますが、裏を返せば「5人に1人はそもそもカードを持っていない」ということになります。
ビジネスにおいて、最初から「2割のお客さま」を門前払いしてしまうリスクは、決して小さくありません。

【DNP 児島】
おっしゃる通りですね。
さらに現場の感覚で言うと、カードを持っている方の中にも「JPKIが使えない」ケースが一定数存在します。

【CTJ 山田氏】
はい。例えば「署名用電子証明書」の発行を受けていなかったり、有効期限（5年）が切れていたり、そもそも長い暗証番号を忘れてしまっていたりするケースです。
「カード未所持」と「証明書利用不可」を合わせると、JPKI一本化によって離脱してしまうユーザー層は、無視できない規模になります。
その離脱層を「利用不可」として切り捨てるのか、それとも別の手段で救うのか。ここで重要になるのが、運転免許証などのICチップを読み取って顔写真と照合する、いわゆる「へ方式（※2）」による「救済措置」です。

【DNP 児島】
へ方式であれば、マイナンバーカード・運転免許証・在留カード等で検証が可能ですからね。
さらに最近は、「顔写真を撮影しておきたい」というニーズも増えています。
JPKIの場合、顔画像は必須ではありませんが、業務上の観点や、心理的な「けん制（なりすまし防止）」のために、あえて顔写真を撮影するフローを残したいというご相談です。
その点、DNPのソフトウエア開発キット（SDK）であれば柔軟な設計が可能です。
「基本はJPKIだが、顔写真撮影も追加する」といった組合せや、「JPKIでエラーが出たら即座に免許証の読み取りへ誘導する」といったハイブリッドな動線を、一つのアプリ内でシームレスに実装できます。

【DNP 児島】
また、最近増えている「外国人対応」においても、JPKI一本化はまだ難しいのではとの話も伺っています。

【CTJ 金子氏】
そこは非常に重要なポイントです。
日本に住む在留外国人の方々は、入管法によって「在留カードの常時携帯義務」が課されています。マイナンバーカードは持っていないかもしれませんが、在留カードだけは法的に必ず肌身離さず持っているのです。
つまり、外国人対応をするビジネスにおいて、在留カードのICチップを読み取る「へ方式」を用意しておくことは、機会損失を防ぐための重要な手段になるわけです。

【DNP 児島】
在留カードといえば、2026年頃から「第2世代在留カード」への切り替えも予定されていますよね。 現場では「仕様がまだ完全には見えない中で、どう対応すればいいのか」という困惑の声も聞きます。こうした新しい券面やICチップの仕様変更に、自社開発ですべて追従していくのは相当な負荷がかかります。

【CTJ 金子氏】
そうですね。仕様が公開されてから開発・検証を行っていたのでは、運用開始に間に合わないリスクもあります。 特に在留カードのような公的な本人確認書類は、今後も規格変更が起こり得ます。そうした「将来の規格変更」への対応も含めて、専門のベンダーに任せてしまうのが、結果的に最もコストを抑え、ビジネスを止めないための賢い選択肢だと思います。

サイバートラスト株式会社　金子 大輔 氏（PKIプロダクト統括部 統括部長）

【CTJ 金子氏】
最も重要なのは、ICチップから取り出したデータを「どこで真正性を検証しているか」です。
実は、ICチップの偽造自体は技術的に不可能ではありません。
仕様さえわかれば、本物のように振る舞うチップを作ることは理論上可能です。
そのような場合には、「電子署名」を検証することで偽造を見抜くのですが、問題はその検証を「スマホアプリ（クライアント側）」だけで完結させる場合にはリスクがあるということです。

【DNP 児島】
スマホアプリ側で「検証OK」と出れば、それで安全というわけではないのですか？

【CTJ 金子氏】
はい。アプリ側で読み取ったデータは、悪意のある攻撃者によって改ざんされたり、通信の途中で書き換えられたりするリスクがゼロではありません。
実際、銀行などセキュリティ意識の高いお客さまは、「クライアントから送られてくるデータをそのまま信用することはできない」とはっきりおっしゃいます。

【DNP 児島】
現場の厳しい声ですね。「送られてきたデータが、本当に読み取ったそのものなのか証明しろ」と。

【CTJ 金子氏】
そうです。アプリがいくら堅固でも、最終的な署名検証を「サーバー側」で行わない限り、そこにはリスクが存在します。
私たちのサービスがサーバー側での検証を必須としているのは、それが多層防御における「最後の”とりで”」となり、万が一アプリ側が突破されても不正を検知できる唯一の手段だからです。

【DNP 児島】
なるほど。本人確認業務のリスクを考えると、「ICチップを読み取れます」という機能だけでなく、「サーバー側で署名検証しているか」までを確認した上での検討が必要になりますね。

【CTJ 金子氏】
はい。ただ、実はもう一つ、事業者にとって重要なポイントがあります。
それは、検証結果のデータを受け取ったあとの「業務連携」です。
多くのツールは「検証しました、結果はOKです」というデータをAPIで返して終わりです。
しかし、事業者からすれば、「そのデータをどうやって自社の業務に生かすのか」、「目視確認といった後続業務は誰がどうやって行うのか」といった後続の業務フローとの連携が残っています。

大日本印刷株式会社　児島 勇介（企画開発第1部 部長）

【DNP 児島】
そこはわれわれDNPが最も得意とする領域ですね。
私たちのアプローチは、「認証」を単独の機能として提供するのではなく、業務プロセス全体の一部としてとらえています。
CTJさまの基盤で厳格に検証されたデータを、DNPの「BPO基盤」や「データ連携基盤」を通じて、お客さまの業務に合わせて加工して連携する、そこまで一気通貫で提供できるからこそ、お客さまは「認証ツールの導入」ではなく「業務プロセスの最適化」として、安心して任せていただけるのだと思います。

• オンライン本人確認（eKYC）総合サービスに関するお問合わせ(別ウィンドウで開く)