マイナンバーカード読み取りの本番実装ではどの資料を参照すべきですか？

J-LISが署名検証者・アプリ開発者向けに提供する技術資料が一次資料です。各APの正確なAID値やコマンド仕様はここで確認します。オープンソースの実装は学習の参考にとどめ、本番実装は必ず一次資料を正としてください。

マイナカードをNFCで読む裏側。AP・AID・APDU

Q: マイナンバーカードのNFC読み取りはどういう仕組みですか？

ISO/IEC 14443 Type Bの無線通信でカードに接続し、ISO-DEPの伝送層の上でAPDU（ISO/IEC 7816-4）というコマンド形式でICチップと対話します。SELECTコマンドでAIDを指定してカード内のアプリケーション（AP）を選び、証明書読み出し・PIN照合・署名演算などの機能を実行する多層構造です。

Q: マイナンバーカードの読み取りエラーの原因は何ですか？

層によって異なります。カードが検出されないのは位置ずれや金属ケースなど無線層の問題、途中で切れるのはカードを動かしたことによる伝送層の切断が典型です。かざし直しても直らない場合は、暗証番号の誤り・PINロック・電子証明書の期限切れや失効といった機能層の問題を疑います。

Q: マイナンバーカードのICチップには何が入っていますか？

役割の異なる複数のアプリケーション（AP）が搭載されています。電子証明書の読み出しや署名演算を行うJPKI-AP、氏名・住所・生年月日・性別のテキストデータを持つ券面事項入力補助AP、券面のイメージ情報を持つ券面APが主なもので、どのAPを読むかで必要な暗証番号も取得できる情報も変わります。

Q: AndroidとiPhoneでマイナンバーカードの読み取り実装は違いますか？

違います。AndroidはIsoDepのtransceive()でAPDUを送受信し、フォアグラウンドディスパッチでセッションを制御します。iPhoneはCore NFCのNFCTagReaderSessionを使い、AIDを事前にInfo.plistへ宣言する必要があり、セッションに時間制限があります。両OSともセッションが切れる前提で途中再開できる設計が重要です。

Q: カードは有効なのに認証が通らないのはなぜですか？

カードの有効期限と電子証明書の有効性は別物だからです。引っ越しなどを契機に署名用電子証明書が失効している場合、カードが有効でも認証は通りません。PINの試行回数超過によるロックも同様に、かざし直しでは解決しません。

スマホにマイナンバーカードをかざす。ユーザーから見れば一瞬のこの動作の裏側では、無線の接続からカード内アプリケーションの選択、証明書の読み出しまで、複数の技術レイヤーが順番に積み上がっています。本記事は、この「かざした瞬間に何が起きているのか」をレイヤーごとに分解して解説します。自社でNFC読み取りを実装する開発者だけでなく、SDKやeKYCベンダーに任せる発注者・事業会社の開発責任者にとっても、この一段下の知識は「読み取りエラーの原因をベンダーと切り分ける」「見積もりや技術提案の妥当性を評価する」場面で直接役立ちます。確認日: 2026年8月23日。

この記事の要点

カード読み取りは「無線（ISO/IEC 14443 Type B）→ 伝送（ISO-DEP）→ コマンド（APDU）→ アプリケーション（AP）選択 → 機能実行」の5層の積み重ねで、層ごとに失敗の原因と対処が異なります

カード内には役割の異なる複数のAP（JPKI-AP・券面事項入力補助AP・券面AP等）が搭載されており、どのAPを選ぶかで読める情報・必要な暗証番号・法的な意味が変わります

「読み取りエラー」を電波の問題・PINの問題・証明書の問題に切り分けられると、UX改善もサポート対応も一段速くなります

個人番号（12桁）は券面事項入力補助APから技術的には読めてしまうため、読み取り範囲の設計を誤ると法令違反につながります

本番実装のコマンド仕様は、J-LISが提供する一次資料を正とします

読み取りは5階建て。どの層で失敗したかで対処が決まる

「かざしてください」という画面の裏側を、下から順に5つの層として整理します。

層	規格・概念	役割	失敗するとどう見えるか
1. 無線	ISO/IEC 14443 Type B	電磁誘導での給電と搬送波	そもそもカードが検出されない。位置ずれ・金属ケース
2. 伝送	ISO-DEP（14443-4）	パケットの分割・再送を担う伝送プロトコル	読み取り途中で切断。「カードを動かさないでください」の世界
3. コマンド	APDU（ISO/IEC 7816-4）	カードへの命令と応答の形式	ステータスワードでエラーが返却される
4. 選択	SELECT（AID指定）	カード内のどのAPと対話するかを選ぶ	AP選択ミス。読みたい情報が読めない
5. 機能	各APのコマンド	証明書読み出し・PIN照合・署名演算	PINロック、証明書の期限切れ・失効

この5層モデルが実務で効く理由は明快です。ユーザーに見える現象は同じ「読み取り失敗」でも、どの層で起きた失敗かによって対処がまったく違うからです。

第1〜2層（無線・伝送）は物理と電波の問題です。かざし直せば直ります。カードの位置ガイドやケースを外す案内といったUI側の工夫が効く領域です
第4〜5層（選択・機能）は論理の問題です。何度かざし直しても直りません。暗証番号の誤り、証明書の失効といった、案内すべき内容そのものが変わる領域です

サポート窓口に「読み取れない」という問い合わせが来たとき、この区別ができているかどうかで一次対応の質が変わります。ベンダーに読み取りモジュールを任せている場合でも、「エラーログからどの層の失敗か判別できる作りになっているか」は発注時に確認しておきたいポイントです。

APDU。カードとの会話の最小単位

第3層のAPDUは、カードへ送る命令（Command APDU）とカードからの応答（Response APDU）のペアで構成されます。

命令側は、CLA・INS・P1・P2（命令の種類とパラメータ）とデータ部からなります
応答側は、末尾2バイトのステータスワードで結果を表します。成功なら 90 00、それ以外はエラー理由を示す値が返ります。たとえばPIN関連のエラーでは、残り試行回数が読み取れる形式になっています

SDKやライブラリを使う開発では、APDUのやり取りは通常隠蔽されます。それでもこの層を知っておく価値があるのは、障害調査の一次情報がここにあるからです。ログに残ったステータスワードを読めるだけで、「電波が切れたのか、PINを間違えたのか、そもそも対応していない操作を投げたのか」を区別できます。ベンダーのサポートに問い合わせる際も、ステータスワード付きで報告できれば解決までの往復が減ります。

AP。カードの中は複数のアプリケーションに分かれている

マイナンバーカードのICチップは1つの塊ではなく、独立した複数のアプリケーション（AP）が同居する構造になっています。読み取り側は、AID（アプリケーション識別子）を指定したSELECTコマンドで「どのAPと話すか」をまず選びます。これが第4層です。

AP	読める・できること	必要な暗証番号
JPKI-AP	利用者証明用・署名用の電子証明書の読み出し、PIN照合、秘密鍵での署名演算	利用者証明用: 数字4桁 / 署名用: 英数字6〜16桁
券面事項入力補助AP	氏名・住所・生年月日・性別（+個人番号）のテキストデータ	数字4桁（項目により異なる）
券面AP	券面のイメージ情報	照合番号等

この表から、発注・設計の実務に直結するポイントが2つ導けます。

第一に、「カードを読む」の中身はAPによって別物です。 JPKI-APから証明書を読んで署名演算まで行うのか、券面事項入力補助APから氏名・住所のテキストを取り出すだけなのかで、技術的な処理も法的な意味も異なります。犯罪収益移転防止法のJPKI方式（公的個人認証）に該当するのは、JPKI-APの署名用証明書と署名演算を使う処理です。方式ごとの法的位置づけの全体像はeKYC完全マップ2026で整理しています。

第二に、読み取り範囲の設計を誤ると法令違反になります。 個人番号（12桁）は券面事項入力補助APから技術的には読めてしまいます。しかし、マイナンバーを取得してよいのは法令で定められた事務に限られるため、本人確認目的のシステムが個人番号まで読み取る設計にしてはいけません。「技術的に読める」と「読んでよい」は別問題であり、要件定義の段階で読み取り項目を明示的に絞り込む必要があります。ベンダーのSDKを使う場合も、どの項目を取得する構成になっているかを確認してください。

なお、各APの正確なAID値やコマンド仕様は、J-LISが署名検証者・アプリ開発者向けに提供する技術資料で確認します。オープンソースの読み取り実装はレイヤー構造の学習には有用ですが、本番実装は必ず一次資料を正とすべきです。

OSごとの実装。AndroidとiPhoneで何が違うか

第2〜3層をアプリからどう扱うかは、OSによってAPIが異なります。

Android: android.nfc.tech.IsoDep がISO-DEP層をそのまま公開しており、transceive() でAPDUを直接送受信できます。読み取りセッションの制御にはフォアグラウンドディスパッチを使います
iPhone: Core NFCの NFCTagReaderSession でISO 7816対応タグとして接続します。読み取るAIDを事前にInfo.plistへ宣言する必要があり、セッションには時間制限があるため、長い処理は分割して設計します

両OSに共通する設計原則は、セッションは切れるものとして作ることです。ユーザーはカードを動かしますし、OSはセッションを打ち切ります。したがって、

「どこまで読めたか」を保持し、途中から再開できる実装にする
進捗をユーザーに見せるUIを用意し、「動かさないで待つ」行動を引き出す

この2点が読み取り完了率に直結します。読み取り完了率は、eKYCフロー全体の離脱率を左右する最重要指標の1つです。スマホ搭載の電子証明書（スマホ用電子証明書)を使えば物理カードのかざし操作自体を減らせるため、対象ユーザーによってはスマホ搭載マイナンバーカードでのeKYCとの併用も検討に値します。

エラー切り分け表。サポートと開発の共通言語にする

運用フェーズで効いてくるのが、エラーを層で分類した切り分け表です。サポート窓口と開発チームが同じ表を参照できるようにしておくと、エスカレーションの精度が上がります。

症状	層	主な原因	対処
カードが検出されない	無線	位置ずれ、金属ケース、NFC無効	かざし位置ガイド、ケースを外す案内
途中で切れる	伝送	カードを動かした、電波不安定	「動かさない」案内、リトライ
PINエラー	機能	暗証番号の誤り	残り試行回数の表示、ロック前の警告
PINロック	機能	試行回数超過	初期化手続きの案内（署名用はコンビニで初期化可）
証明書エラー	機能	期限切れ・失効（引っ越し等）	「カードは有効でも証明書が失効している場合がある」案内

最後の行は見落とされがちです。カード自体は有効期限内でも、引っ越しなどを契機に署名用電子証明書が失効していることがあります。この場合、ユーザーが何度かざし直しても認証は通りません。失効がサービスのアカウント継続にどう影響するか、どう検知して案内すべきかは電子証明書の失効とアカウント継続性で詳しく扱っています。また、サーバー側で署名と証明書をどの順序で検証するかは署名検証の正しい順序を参照してください。

発注者向けチェックリスト。ベンダー・SDK選定で確認すること

読み取り部分を外部のSDK・ベンダーに任せる場合でも、次の項目を確認しておくと後の運用トラブルを減らせます。

読み取り対象のAPと取得項目の一覧が明示されているか（個人番号を読まない構成になっているか）
エラーが層ごとに区別できるログ・エラーコードとして返ってくるか（ステータスワード相当の情報が追えるか）
読み取り途中からの再開に対応しているか（セッション切断のたびに最初からやり直しになっていないか）
PINの残り試行回数の表示とロック前の警告がUIに組み込まれているか
証明書の失効・期限切れをエラーとして区別し、ユーザーへの案内文まで用意されているか
AndroidとiPhoneの両OSでの読み取り完了率の実績値を提示できるか

これらは、JPKIの実装経路（プラットフォーム事業者経由か、署名検証者として直接かなど)を選ぶ議論とも密接に関わります。経路ごとの契約・開発負担の違いはJPKIのプラットフォーム事業者とサービスプロバイダで整理しています。

まとめ

マイナンバーカードのNFC読み取りは、無線・伝送・APDU・AP選択・機能の5層構造です。失敗した層が特定できれば対処は決まります
第1〜2層は物理・電波の問題でかざし直しが効き、第4〜5層は論理の問題でかざし直しでは直りません。この区別がサポート対応の質を左右します
カード内はJPKI-AP・券面事項入力補助AP・券面APに分かれ、どれを読むかで取得情報・必要な暗証番号・法的意味が変わります
個人番号は技術的に読めても読んではいけません。読み取り項目の絞り込みは要件定義段階の必須作業です
AndroidはIsoDep、iPhoneはCore NFC。どちらも「セッションは切れるもの」として再開可能に設計することが読み取り完了率に直結します
本番実装のAID・コマンド仕様はJ-LISの技術資料を正とします

よくある質問

Q. マイナンバーカードのNFC読み取りはどういう仕組みですか？

ISO/IEC 14443 Type Bの無線通信でカードに給電・接続し、ISO-DEP（14443-4）の伝送層の上でAPDU（ISO/IEC 7816-4）というコマンド形式を使ってカード内のICチップと対話します。まずSELECTコマンドでAID（アプリケーション識別子）を指定してカード内のアプリケーション（AP）を選び、そのAPが提供する証明書読み出し・PIN照合・署名演算などの機能を実行する、という多層構造です。

Q. マイナンバーカードの読み取りエラーの原因は何ですか？

原因は層によって異なります。カードが検出されない場合は位置ずれや金属ケースなど無線層の問題、途中で切れる場合はカードを動かしたことによる伝送層の切断が典型です。かざし直しても直らない場合は、暗証番号の誤り・PINロック・電子証明書の期限切れや失効といった機能層の問題を疑います。どの層の失敗かを切り分けることが対処の第一歩です。

Q. マイナンバーカードのICチップには何が入っていますか？

役割の異なる複数のアプリケーション（AP）が搭載されています。主なものは、電子証明書の読み出しや署名演算を行うJPKI-AP、氏名・住所・生年月日・性別（および個人番号）のテキストデータを持つ券面事項入力補助AP、券面のイメージ情報を持つ券面APです。どのAPを読むかによって、必要な暗証番号も取得できる情報も変わります。

Q. マイナンバーカードを読み取ると個人番号（12桁）も取得されますか？

券面事項入力補助APから技術的には読み取れますが、マイナンバーを取得してよいのは法令で定められた事務に限られます。本人確認目的のシステムでは個人番号を読み取らない設計にする必要があり、読み取り範囲を誤ると法令違反になります。ベンダーのSDKを使う場合も、取得項目の構成を必ず確認してください。

Q. AndroidとiPhoneでマイナンバーカードの読み取り実装は違いますか？

違います。Androidは android.nfc.tech.IsoDep の transceive() でAPDUを送受信し、フォアグラウンドディスパッチでセッションを制御します。iPhoneはCore NFCの NFCTagReaderSession を使い、読み取るAIDを事前にInfo.plistへ宣言する必要があり、セッションに時間制限があります。両OSとも、セッションが切れる前提で途中再開できる設計にすることが重要です。

Q. カードは有効なのに認証が通らないのはなぜですか？

カードの有効期限と電子証明書の有効性は別物だからです。引っ越しなどを契機に署名用電子証明書が失効している場合、カード自体が有効でも認証は通りません。またPINの試行回数超過によるロックも同様に、かざし直しでは解決しません。エラー案内では「カードが有効でも証明書が失効している場合がある」ことをユーザーに伝える設計が必要です。

Q. 本番実装ではどの資料を参照すべきですか？

J-LISが署名検証者・アプリ開発者向けに提供する技術資料が一次資料です。各APの正確なAID値やコマンド仕様はここで確認します。オープンソースの読み取り実装は学習の参考になりますが、本番実装の根拠にはせず、必ず一次資料に当たってください。

主な参考資料: J-LIS 公的個人認証サービス署名検証者等向けの手続・技術資料、Android Developers: IsoDep、Apple Developer: Core NFC、総務省公的個人認証サービスによる電子証明書

TodoONada株式会社では、マイナンバーカード認証（JPKI・eKYC）を組み込んだWebサービス・スマホアプリの受託開発を行っています。方式選定（JPKI・IC読取り・画像方式）から開発・運用までワンストップで支援し、NFC読み取りの完了率改善やSDK選定の技術評価、デジタル庁「デジタル認証アプリ」利用申請の伴走支援（書類作成から指摘対応まで）にも対応します。料金の目安は認証機能組込みプラン150万円〜、認証込みアプリ開発プラン400万円〜、大規模・個別要件は1,000万円〜です。「読み取りエラーの原因がベンダーと切り分けられない」といった技術相談も、マイナンバーシステム導入支援またはお問い合わせからお気軽にどうぞ。

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

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

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

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