eKYCが失敗する30パターンを層別に診断する
eKYCを導入した後、サポート窓口に必ず届くのが「本人確認ができない」という問い合わせです。しかしこの一言の中身は1つではありません。NFCが読めないのか、顔照合で弾かれたのか、証明書が失効していたのか。原因の層が違えば、対処する主体も打ち手もまったく変わります。
本記事は、eKYCを提供する事業者のサポートチーム・開発チーム・サービス責任者に向けて、「できない」の中身を6層30パターンに分解した診断表をお届けします。障害対応の切り分け表としてだけでなく、完了率をどの層で失っているかを計測し、改善投資の優先順位を数字で決めるための設計図として使えます。ユーザー向けの「できないときの対処法」記事ではない点にご留意ください。確認日: 2026年8月23日。
この記事の要点
- 「本人確認が通らない」は1つの症状ではなく、端末・撮影・書類・証明書・通信/API・運用の6層で起きる別々の事象の総称です
- どの層の失敗かによって対処する主体(ユーザー自身・サポート・開発・ベンダー)が変わるため、層の切り分けができれば解決は早くなります
- 失敗率は設計品質の指標でもあります。層別に計測すれば、どこに投資すべきかが数字で見えます
- エラーコードは「層が特定できる粒度」で設計しておくことが、サポート品質と改善速度の両方を左右します
第1層: 端末・NFC読み取りの失敗(パターン1〜6)
マイナンバーカードをスマートフォンで読み取る方式では、最初の関門が端末とNFCです。ここでの失敗はユーザーには「アプリが動かない」としか見えません。
| # | 症状 | 原因 | 対処の方向性 |
|---|---|---|---|
| 1 | カードがまったく検出されない | NFCが無効になっている・非対応端末 | 事前の対応端末判定と設定ガイドの提示 |
| 2 | 検出はされるが読み取りが不安定 | かざし位置のずれ(アンテナ位置は機種ごとに異なる) | 機種別のかざし位置ガイド表示 |
| 3 | 読み取りの途中で切断される | カードを動かした・スマホケースの干渉 | 「動かさない」の明示、進捗表示、途中再開の実装 |
| 4 | 特定機種だけ失敗率が突出して高い | 端末側のNFC実装差 | 機種別完了率の計測と既知問題端末の案内 |
| 5 | 読み取り画面でアプリが固まる | 読み取りセッションのタイムアウト処理漏れ | セッション時間制限を前提とした処理の分割設計 |
| 6 | 読み取りは成功したのにアプリが落ちる | 券面画像など大きなデータのメモリ処理 | 実機での長時間・低メモリ環境試験 |
この層の失敗は開発側の設計とガイダンスで大きく減らせます。裏を返せば、ベンダー選定時にSDKの機種対応状況や読み取りUXの作り込みを確認しておくべき領域です。確認観点は『eKYCサービスの選び方20項目』にまとめています。
第2層: 撮影・顔照合の失敗(パターン7〜12)
セルフィー撮影と顔照合を伴う方式では、正当なユーザーが弾かれる「本人拒否」が離脱の主要因になります。
| # | 症状 | 原因 | 対処の方向性 |
|---|---|---|---|
| 7 | 本人なのに顔照合で弾かれる | 閾値が厳しすぎる・照明条件・書類写真との経年変化 | 閾値と手動審査に回す帯域の見直し |
| 8 | 撮影自体が完了しない | 暗所・逆光・カメラ権限の拒否 | 撮影ガイダンスと権限取得導線の改善 |
| 9 | ライブネス検知で正当ユーザーが落ちる | アクティブ検知の指示が伝わらない(高齢者・眼鏡着用者など) | 指示UXの改善、パッシブ方式の併用 |
| 10 | 特定の属性層だけ否認率が高い | 照合エンジンの評価データと自社ユーザー層のずれ | 属性別否認率の計測とベンダーとの協議 |
| 11 | 書類の顔写真と照合できない | 券面写真の反射・かすれ | 券面撮影の品質チェック、ICチップ内写真の利用 |
| 12 | 再撮影ループに陥って離脱する | 失敗理由を伝えないUI | 失敗理由別のガイダンス出し分け |
顔照合の閾値は「厳しくすればなりすましを防げるが本人拒否が増える」というトレードオフの上にあります。閾値そのものと、閾値付近を手動審査へ回す帯域設計をセットで見直すのが定石です。
第3層: 本人確認書類の失敗(パターン13〜16)
書類そのものに起因する失敗は、入口の案内と例外処理の設計で決まります。
| # | 症状 | 原因 | 対処の方向性 |
|---|---|---|---|
| 13 | OCRが氏名・住所を読み間違える | 券面の汚れ・特殊な氏名表記 | 確認画面での訂正導線(ただし訂正はログに残す) |
| 14 | 対応していない書類で申し込まれる | 書類要件の案内不足 | 入口での書類選択と要件表示 |
| 15 | 真贋判定で正当な書類が弾かれる | 旧様式・地域差・経年劣化 | 判定根拠の確認と手動審査への迂回路 |
| 16 | 券面の記載とICチップの内容が一致しない | 記載事項変更(裏面追記)・読み取り不良 | 券面更新の案内、ICチップ側を正とする設計 |
なおOCRで文字を読み取ること自体は本人確認ではなく、書類確認は「読み取り・真贋判定・記載内容の検証・本人との紐付け」という複数の工程で構成されます。パターン13の「訂正をログに残す」は、後から確認記録の正当性を説明するために欠かせない設計です。
第4層: 電子証明書・暗証番号の失敗(パターン17〜21)
JPKI(公的個人認証サービス)を使う方式に特有の層です。2027年4月の犯収法改正で非対面本人確認がJPKI方式へ一本化されていく流れを踏まえると(背景は『eKYCとJPKIの違い』を参照)、今後最も問い合わせが増える層と言えます。
| # | 症状 | 原因 | 対処の方向性 |
|---|---|---|---|
| 17 | 暗証番号エラーが出る | 4桁(利用者証明用)と6〜16桁(署名用)の取り違え | どちらのPINを求めているかを画面で明示 |
| 18 | PINがロックされる | 試行回数の超過(署名用5回・利用者証明用3回) | 残り回数の表示、ロック時の初期化手続き案内 |
| 19 | 証明書の有効期限が切れている | カード有効期限(10年)と証明書有効期限(5年)の差 | 「カードは有効でも証明書は切れる」の事前案内 |
| 20 | 証明書が失効している | 引っ越し・婚姻による署名用電子証明書の自動失効 | 失効検知時の再発行案内フロー |
| 21 | スマホ搭載の証明書で読めない・使えない | カードの証明書とスマホ搭載証明書の混同 | どちらの証明書で確認するかの導線分離 |
マイナンバーカードには署名用と利用者証明用の2種類の電子証明書があり、暗証番号の桁数もロックまでの試行回数も異なります。ユーザーはこの区別を知らない前提で、画面側が「いまどちらの暗証番号を求めているか」を明示する設計が必要です。PINロック時の初期化はコンビニ等での手続きになるため、案内文面まで用意しておくとサポート負荷が下がります(手続きはJPKIの暗証番号初期化・再設定ページを参照)。
第5層: 通信・API・Webhookの失敗(パターン22〜26)
eKYCベンダーのAPIと自社システムの連携部分で起きる失敗です。ユーザーからは「いつまで待っても終わらない」と見えます。
| # | 症状 | 原因 | 対処の方向性 |
|---|---|---|---|
| 22 | 結果がいつまでも「処理中」のまま | Webhookの欠落・受信側の障害 | 照会APIでの回収、再送仕様の確認 |
| 23 | 同じ確認が二重に課金される | リトライ時の冪等性キー未実装 | Idempotency-Keyの導入 |
| 24 | ステータスが巻き戻る | Webhookの順序逆転をそのまま状態に反映 | イベント順序と現在状態の突き合わせ |
| 25 | 完了通知が偽造されうる | Webhook署名検証の未実装 | 署名検証(タイムスタンプ+生ボディ) |
| 26 | 突然すべての確認が失敗し始める | ベンダー側障害・証明書更新・API仕様変更 | 死活監視、障害時に受付を止めるか後回しにするかの判断フロー |
この層は本人確認の状態遷移を状態機械として設計し、Webhookを唯一の情報源にしないことが土台になります。ベンダー選定時には、Webhookの再送仕様・署名検証・照会APIの有無を必ず確認してください。比較の観点は『eKYCベンダー比較』で扱っています。
第6層: 運用・審査の失敗(パターン27〜30)
システムが正常でも、運用側で完了が滞るパターンです。
| # | 症状 | 原因 | 対処の方向性 |
|---|---|---|---|
| 27 | 手動審査が詰まって完了が遅い | 審査に回す帯域が広すぎる・人員不足 | 審査率とp95審査時間の計測、閾値調整 |
| 28 | 審査結果が担当者によってぶれる | 審査基準の文書化不足 | 判定基準書の整備と定期的な突き合わせ |
| 29 | 完了メールが届かず問い合わせが増える | 通知経路の不達(迷惑メール判定など) | 複数経路での通知、ステータス確認画面 |
| 30 | 「できない」問い合わせが解決しない | サポートが層の切り分け情報を持てない | 層別のエラーコード設計と管理画面での可視化 |
パターン30は、この記事全体の要でもあります。エラーコードが「エラーが発生しました」の粒度しかないと、サポートはどの層の失敗かを特定できず、30パターンのどれにも辿り着けません。エラーコードは設計段階で「層が分かる粒度」に決めておく必要があります。
診断表を計測の設計図として使う
この30パターンは、サポートの切り分け表であると同時に、完了率改善の計測設計図です。申し込みから完了までのファネルを層に対応させ、次の指標を分けて取得します。
- NFC読み取り開始率・完了率(第1層)
- 撮影完了率・照合通過率・再撮影率(第2〜3層)
- PIN・証明書エラー率(第4層)
- API/Webhookのエラー率・回収率(第5層)
- 手動審査率・p95審査時間・審査の覆り率(第6層)
「eKYC完了率80%」という1つの数字を眺めていても何も直せません。層別に分解して初めて、「第1層で12%落ちている。かざし位置ガイドに投資する」という意思決定ができます。逆に、この計測ができる管理画面・ログ設計になっているかどうかは、内製・外注いずれの場合も発注時に要件へ含めるべき項目です。
導入前・改善前チェックリスト
eKYCの新規導入や完了率改善に着手する前に、次を確認してください。
- エラーコードが6層のどこで失敗したか特定できる粒度で設計されている
- 機種別・属性別の完了率を計測できるログが取得されている
- PINロック・証明書失効・期限切れの案内文面と導線が用意されている
- Webhookの再送仕様・署名検証・照会APIを確認済みである
- 手動審査の審査率とp95審査時間を定期的に見ている
- サポート窓口が層別の切り分けフローを持っている
本人確認の方式選定から運用までの全体像は『eKYC完全マップ』を、規制動向を踏まえた導入判断はマイナンバーシステム導入支援のページもあわせて参照してください。
まとめ
- 「eKYCができない」は、端末・撮影・書類・証明書・通信/API・運用の6層30パターンに分解できます
- 層が特定できれば、対処する主体(ユーザー・サポート・開発・ベンダー)と手段が決まります
- エラーコードは層が分かる粒度で設計することが、サポート品質と改善速度の分岐点です
- 完了率は層別に計測して初めて、改善投資の優先順位を数字で決められます
- JPKI方式への移行が進むほど第4層(証明書・PIN)の問い合わせが増えるため、失効・ロック時の導線設計は先回りして用意する価値があります
よくある質問
Q. eKYCで本人確認ができない原因には何がありますか?
原因は大きく6つの層に分かれます。端末・NFC読み取りの問題、撮影・顔照合の問題、本人確認書類の問題、電子証明書・暗証番号の問題、通信・APIの問題、運用・審査の問題です。同じ「できない」でも層によって対処する主体と手段が異なるため、まずどの層で失敗しているかを切り分けることが解決の近道です。
Q. マイナンバーカードがスマホで読み取れないのはなぜですか?
代表的な原因は、NFCが無効または非対応の端末であること、かざし位置のずれ(アンテナ位置は機種ごとに異なります)、読み取り中にカードを動かしたこと、スマホケースの干渉です。事業者側では、対応端末の事前判定、機種別のかざし位置ガイド、進捗表示と途中再開の実装で失敗率を下げられます。
Q. 顔照合で本人なのに弾かれるのはなぜですか?
照合閾値が厳しすぎる、撮影時の照明条件が悪い、書類の写真からの経年変化などが主な原因です。またライブネス検知の指示が伝わりにくい高齢者や眼鏡着用者で失敗が集中することもあります。閾値の調整と手動審査に回す帯域の設計、失敗理由別のガイダンス表示が対処の中心になります。
Q. マイナンバーカードの暗証番号がロックされるまでの回数は何回ですか?
署名用電子証明書の暗証番号(6〜16桁)は連続5回、利用者証明用電子証明書の暗証番号(4桁)は連続3回の誤りでロックされます。ロック後は初期化・再設定の手続きが必要です。事業者側では残り試行回数の表示と、どちらの暗証番号を求めているかの明示が失敗防止に有効です。
Q. カードは有効期限内なのに電子証明書が使えないことがありますか?
あります。マイナンバーカード本体の有効期限は発行から10年ですが、電子証明書の有効期限は5年で、カードが有効でも証明書だけ期限切れになるケースがあります。また引っ越しや婚姻などで署名用電子証明書は自動的に失効します。失効・期限切れを検知した際の再発行案内フローを用意しておくことが重要です。
Q. eKYCの完了率を改善するにはどこから手を付けるべきですか?
まず完了率を層別に計測することから始めてください。NFC読み取り完了率、撮影・照合通過率、PIN・証明書エラー率、APIエラー率、手動審査率をそれぞれ分けて取得すると、どの層で最もユーザーを失っているかが数字で分かります。全体の完了率という1つの数字では改善の投資先を決められません。
主な参考資料: J-LIS 公的個人認証サービス(利用者向け情報)、JPKI 暗証番号の初期化・再設定、デジタル庁 マイナンバーカード関連情報
TodoONada株式会社では、マイナンバーカード認証(JPKI・eKYC)を組み込んだWebサービス・スマホアプリの受託開発を行っています。本記事のような層別のエラーコード設計・完了率計測を織り込んだ確認基盤の構築から、既存eKYCの完了率の層別分析と改善設計まで対応可能です。料金の目安は認証機能組込みプラン150万円〜、認証込みアプリ開発プラン400万円〜、大規模・個別要件は1,000万円〜です。「完了率がどの層で落ちているのか分からない」という段階からのご相談も、マイナンバーシステム導入支援よりお寄せください。
この記事に関連するサービス
TodoONada株式会社では、マイナンバーカード認証を組み込んだシステム開発を行っています。
- マイナンバーシステム導入支援 — JPKI・eKYC対応の本人確認をワンストップで
導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。
出典・参照
- 公的個人認証サービス ポータルサイト(利用者向け情報) (2026年8月23日確認)
- JPKI 暗証番号の初期化・再設定の手続き (2026年8月23日確認)
- デジタル庁 マイナンバーカード関連情報 (2026年8月23日確認)