デジタル認証サービスの認証をiPhoneとAndroidの実機で通してみた。テスト用マイナアプリの画面遷移、暗証番号を2回聞かれる理由、テストカードで戻ってくる4情報
TodoONada株式会社の土門です。J-LISに借用を申し込んでいたテスト用マイナンバーカードが届いたので、2026年10月2日に、デジタル庁の「デジタル認証サービス」(2026年8月25日にマイナアプリへ統合される前は「デジタル認証アプリ」)の認証を、iPhoneとテスト用マイナアプリで最初から最後まで通しました。同じ日に公開したあと、10月5日にAndroid端末でも通したので、違いを追記しています。
それまでの開発はテストカード代替機能で進めていました。代替機能はAPIの応答を返してくれますが、利用者がアプリで何を見て、何を入力し、どこで戻ってくるのかは見えません。この記事は、その「見えなかった部分」を実際の画面で記録したものです。デジタル庁の実装ガイドラインにはシーケンス図とエラー文言の例はありますが、利用者が見る画面の並びは載っていないため、これから申請する事業者や、発注前に利用者の操作量を知りたい方に向けて公開します。
画面はすべてテスト環境(Sandbox)のものです。アプリは「テスト」のバッジが付いたテスト用マイナアプリ、カードはJ-LISから借用した全AP搭載のテスト用ICカードで、RP(自社サービス側)は当社が検証用に用意した会員サービスのステージング環境です。テストカードに入っている氏名・住所・生年月日・性別は、架空の人物とはいえそのまま載せないほうがよいと判断し、黒塗りにしています。
この記事の要点
- 利用者が見る画面は、RPの開始画面を含めて9画面。カードをかざすのは1回、暗証番号の入力は2回だった
- 暗証番号が2回になるのは、認証に使う利用者証明用電子証明書(JPKI-AP)と、氏名・住所などの4情報が入っている券面事項入力補助APで暗証番号が別だから。4情報を要求しなければ1回で済む
- 基本4情報は認証APIのscopeで取得できる。 当社の過去記事で「4情報は署名APIの領域」と書いていたのは誤りで、本記事とあわせて訂正した
- RPに戻る住所は券面どおりの表記で、数字が全角だった。郵便番号・メールアドレス・電話番号は取得できないので、自社で入力してもらう
- 完了画面からRPへは、スマホ同一端末では利用者がボタンを押して戻る。PCのブラウザから二次元コードで連携した場合は、PC側が数秒後に自動で戻る
- Androidでも画面の並びは同じ。違いは、暗証番号が「パスワード」と表記されること、読み取りが「読み取り開始」ボタンで始まり端末ごとの読み取り位置を案内するリンクがあること、アプリに「ヘルプ」が常設されていること
試した条件
| 項目 | 内容 |
|---|---|
| 日付 | 2026年10月2日(iPhone)、2026年10月5日(Android) |
| 端末とブラウザ | iPhone(Safari)とAndroid(Chrome)。どちらもテスト用マイナアプリ(「テスト」バッジ付き) |
| カード | J-LISから借用した全AP搭載のテスト用ICカード(有効な電子証明書入り) |
| 環境 | デジタル認証サービスのテスト環境(Sandbox)。テストカード代替機能からテスト用マイナアプリへ切り替え済み |
| API | 認証API。scopeは openid に加えて name address birthdate gender |
| 構成 | スマホ同一端末(スマホのブラウザからアプリを起動して戻る)と、PCのブラウザから二次元コードでiPhoneのマイナアプリに連携する構成の2つ |
テストカード代替機能とテスト用マイナアプリは同時に使えないため、カードが届いた時点でデジタル庁へ設定書で切り替えを申し出ています。この手順は代替機能の解説記事に書きました。
全体の流れ
先に全体を1枚で示します。左上から右へ、RPの開始画面、アプリの起動、暗証番号2回、カード読み取り、同意、完了の順です。

| 順 | 画面 | 誰が作る画面か | 利用者の操作 |
|---|---|---|---|
| 1 | RPの開始画面 | 自社 | 「マイナンバーカードでログイン」を押す |
| 2 | マイナアプリの起動画面 | デジタル庁 | 「自分のマイナンバーカードで認証」を押す |
| 3 | 利用者証明用暗証番号の入力 | デジタル庁 | 4桁の数字を入力 |
| 4 | 券面事項入力補助用暗証番号の入力 | デジタル庁 | 4桁の数字を入力(4情報を要求した場合のみ) |
| 5 | カードの読み取り | デジタル庁 | スマホの背面上部をカードに当てて待つ(Androidは「読み取り開始」を押してから) |
| 6 | 読み取り完了 | デジタル庁 | 待つだけ |
| 7 | 情報提供の同意 | デジタル庁 | 提供する情報を見て「提供」を押す |
| 8 | 完了画面 | デジタル庁 | 「利用中のサービスに移動」を押す |
| 9 | RPの結果画面 | 自社 | 確認済みの情報を見て続きの入力へ |
自社で作るのは1と9だけで、間の7画面は国のアプリです。文言もボタンも変えられません。UXの記事で「開始前に必要なものを見せる」「戻り先を保証する」と書いたのは、自社が手を入れられるのがこの両端だけだからです。
画面ごとの記録
1. RPの開始画面(自社)
自社側の画面です。ボタンの下に、このあとマイナアプリが起動すること、券面情報の読み取りと暗証番号の入力を求められること、個人番号(マイナンバー)そのものは取得も保存もしないことを書いています。
個人番号を取らないと明記しているのは、民間事業者が本人確認の目的で個人番号を集めることは番号法で認められていないからです(民間企業がマイナンバーを集めてはいけない理由)。利用者から見ると「マイナンバーカードでログイン」は「マイナンバーを渡す」と誤解されやすいので、開始画面で打ち消しておきます。
2. マイナアプリの起動(デジタル庁)
ボタンを押すと、ブラウザからテスト用マイナアプリに切り替わります。画面上部の「◀ Chrome」はiOSの「戻る」表示で、ブラウザから起動されたことが分かります。
「自分のマイナンバーカードで認証」の下に「自分以外のマイナンバーカードで認証」というリンクがあります。本人以外のカードを使う導線がアプリ側に用意されていることは、利用申請の段階では意識していませんでした。自社サービスがこの経路をどう扱うかは、ここで初めて検討項目になりました。
3. 利用者証明用暗証番号(デジタル庁)
1回目の暗証番号です。見出しが「実物のマイナンバーカードの利用者証明用暗証番号の入力」となっているのは、マイナアプリがスマホ用電子証明書にも対応しているため、カードの証明書を使うことを明示しているからです。説明文には申請時に登録したサービス名(当社は「TodoONada認証」)が入ります。
「暗証番号がわからない」のリンクはアプリ側にあります。UXの記事で「忘れている人の出口を作る」と書きましたが、デジタル認証サービスを使う場合、この出口は国のアプリが持っています。自社で作るのは、アプリから戻ってこなかった人への後日の案内です。
4. 券面事項入力補助用暗証番号(デジタル庁)
2回目の暗証番号です。説明文が「認証するために」から「情報を連携するために」に変わっています。ここが、この記事でいちばん伝えたい画面です。
マイナンバーカードには複数のAP(アプリケーション)が入っていて、APごとに暗証番号が別です。認証に使う利用者証明用電子証明書はJPKI-APに、氏名・住所・生年月日・性別の4情報は券面事項入力補助APに入っています。デジタル庁の資料でも、認証APIは「マイナンバーカードの券面事項入力補助APを用いた4情報連携機能も利用可能」と説明されています。認可リクエストのscopeに name address birthdate gender を含めると、アプリは券面事項入力補助APを読むために、その暗証番号を別に求めます。
利用者にとっては、どちらも4桁の数字です。カード交付時に4桁の暗証番号を同じ番号に統一して設定できるため、同じ番号を2回入れる人が多いはずですが、別の暗証番号として設定している人もいます。ロックの条件も別々に数えられます。
設計への影響は単純で、4情報を要求すると暗証番号の入力が1回増えるということです。ログインや当人認証だけが目的なら、scopeを openid だけにして暗証番号1回で済ませられます。4情報を取るかどうかは「氏名と住所を自社に取り込む必要があるか」で決めるべきで、取れるから取るという判断は利用者の手間を1画面分増やします。当社も利用申請の審査で、4情報の用途を問い直されました。
5〜6. カードの読み取り(デジタル庁)
暗証番号を2回入れたあとで、カードをかざします。iPhoneの場合は背面上部をカードに当てる案内と、iOS標準のNFC読み取りシートが自動で出ます。Androidでは「読み取り開始」ボタンを押してから読み取りが始まります(後述)。暗証番号は2回でも、カードをかざすのは1回でした。利用者証明用電子証明書による認証と券面事項入力補助APからの4情報の読み出しは、1回の読み取りの中で行われます。
読み取りが終わるとチェックマークが出て、背後に次の同意画面が現れます。読み取りの裏側で何が起きているかはマイナカードをNFCで読む裏側に書いています。
7. 情報提供の同意(デジタル庁)
同意画面には、申請時に提出したアイコン(テスト環境なので「テスト」のバッジが付きます)、サービス名、提供する情報の一覧、利用規約とプライバシーポリシーへのリンクが並びます。提供する情報はscopeで要求したものだけが出ます。
利用規約とプライバシーポリシーのリンク先は、利用申請の設定書で指定したURLです。ここに古いURLや未公開のページを入れると、利用者が同意画面から飛んだ先で404になります。本番申請の前に、このリンクを実機で踏んで確認しておくことをおすすめします。
8. 完了画面(デジタル庁)
「提供」を押すと完了画面になり、「利用中のサービスに移動」のボタンでブラウザに戻ります。スマホ同一端末の構成では自動では戻らず、利用者がボタンを押します。PCから二次元コードで連携した場合はPC側が自動で戻ります(後述)。
UXの記事で「戻り先を保証する」と書いた離脱ポイントは、まさにこの画面です。ここでアプリを閉じてしまうと、認証は成功しているのにRPには誰も戻ってきません。対策として、戻ってきたときに入力途中の内容が保持されていることと、戻らなかった人にあとから再開してもらう導線を自社側で持つ必要があります。
9. RPの結果画面(自社)
ブラウザに戻ると、RPがトークンを受け取り、UserInfoから4情報を表示しています。黒塗りの部分にはテストカードに入っている架空の人物の氏名・住所・生年月日・性別が返ってきました。確認日時は当社側で記録した時刻です。
実装上の気づきが2つあります。
- 住所の数字は全角で返ってきました。 画面の注記に「氏名と住所はマイナンバーカードの記載どおりの表記で表示しています」と書いたのはこのためです。配送先や帳票に使うなら、全角と半角の正規化、丁目・番地の表記の扱いを自社側で決める必要があります。氏名も券面どおりで、外字や旧字体が返る可能性があります
- 郵便番号・メールアドレス・電話番号は取得できません。 4情報に郵便番号は含まれないので、住所が確認済みでも郵便番号は利用者に入力してもらいます。画面では「ご本人の申告による情報です(デジタル認証サービスでは取得できません)」と分けて見せています
確認済みの情報を利用者が編集できないようにしているのは、本人確認済みという状態の意味を保つためです。引っ越しや改姓で変わる可変データなので、同一人物の判定にはPPID(sub)を使い、4情報は入力補完と突合に使うという整理にしています。
番外. キャンセルしたとき
アプリで×を押したり「提供しない」を選んだりすると、RPにはエラーの認可レスポンスが返ります。当社は開始画面に戻して「認証がキャンセルされました」と表示し、同じボタンをもう一度押せるようにしました。キャンセルは利用者の意思なので、エラー画面に飛ばすより、同じ場所でやり直せるほうが自然だと考えています。
Androidで通したときの違い
10月5日に、同じテストカードと同じRPで、Android端末(Chrome)からも通しました。画面の並びはiPhoneと同じ9画面で、暗証番号は2回、カードをかざすのは1回でした。

違いは3つありました。
1. 「暗証番号」が「パスワード」と表記される。 iPhoneでは「利用者証明用暗証番号の入力」「暗証番号がわからない」だった画面が、Androidでは「利用者証明用電子証明書のパスワードの入力」「パスワードがわからない」になっています。券面事項入力補助用も同じく「パスワード」です。中身は同じ4桁の数字ですが、自社の開始画面で「暗証番号を求められます」と書いていると、Android利用者はアプリで「パスワード」と言われて戸惑う可能性があります。当社は開始画面の文言を「暗証番号(パスワード)」と併記する方向で見直します。

2. 読み取りは「読み取り開始」ボタンで始まり、端末ごとの読み取り位置を案内する。 iPhoneはOS標準の読み取りシートが自動で出ますが、Androidは読み取り画面に「読み取りかたを確認」のリンクと「読み取り開始」のボタンがあり、押すと「端末をカードにかざしてください」のシートが出ます。シートには「端末ごとの読み取り位置をみる」のリンクがあり、機種によってNFCアンテナの位置が違うことをアプリ側が前提にしています。UXの記事で「読み取りは機種差を前提にガイドする」と書いた部分は、デジタル認証サービスを使う場合、国のアプリが受け持ちます。

3. アプリの右上に「ヘルプ」が常設されている。 iPhoneでは「…」メニューだった位置に、Androidでは「ヘルプ ?」が各画面に出ています。
同意画面、完了画面、RPに戻ったあとの表示はiPhoneと同じでした。RPのマイページに戻ると、ヘッダーの氏名と確認済み情報(黒塗り)が表示され、住所の数字が全角で返る点も同じです。
PCのブラウザから二次元コードで連携したときの流れ
利用者がPCでサービスを使っている場合、マイナアプリはスマホにしかないので、PCのブラウザとスマホのアプリを二次元コードでつなぎます。10月5日に、PCのブラウザとiPhoneのマイナアプリで通しました。PC側の画面はデジタル庁が用意するもので、自社で作る部分はありません。
PCで「マイナンバーカードでログイン」を押すと、デジタル庁側の画面に切り替わり、二次元コードが表示されます。コードには残り秒数が出ていて、時間が来ると更新されます。右側には手順と、マイナアプリをまだ入れていない人向けのダウンロード用コードが並びます。

スマホ側では、マイナアプリのホームにある「二次元コードを読み取る」からカメラでコードを読みます。読み取ると、アプリに6桁の数字と残り秒数が表示されます。これをPCのブラウザに入力します。
PC側は「二次元コードを読み取った利用者本人が操作していることを確認します」と説明しています。PCに表示されたコードを別の人のスマホで読まれても、その人が6桁をPCに入力できなければ先に進めない、という設計です。
6桁を入力すると、PC側は「このブラウザは開いたままにしてください」の待機画面になります。ここから先はスマホの操作で、利用者証明用暗証番号、券面事項入力補助用暗証番号、カードの読み取り、情報提供の同意は、同一端末のときと同じ画面でした。

スマホ側の最後の画面は「二次元コードが表示されたもうひとつの端末に戻って利用を続けてください」で、ボタンは「閉じる」です。同一端末のときの「利用中のサービスに移動」とは違い、スマホからRPへは遷移しません。
PC側は、スマホの操作が終わると自動で完了画面に変わり、「あと◯秒で、もとのサービスに自動で戻ります」のカウントダウンのあとRPへ戻りました。「利用中のサービスに戻る」のボタンもありますが、押さなくても戻ります。同一端末では利用者がボタンを押して戻るのに対し、PC連携では自動で戻るので、「戻ってこない」離脱の性質が構成によって違います。PC連携では、むしろ利用者がPCのブラウザを閉じてしまったり、二次元コードや6桁の残り時間が切れたりする離脱を考える必要があります。
PC連携で分かったことをまとめます。
| 項目 | スマホ同一端末 | PCのブラウザと二次元コード |
|---|---|---|
| 二次元コードの読み取り | なし | あり。コードに残り秒数がある |
| 6桁の数字の入力 | なし | あり。スマホに表示された数字をPCに入力。残り秒数がある |
| 暗証番号、カード読み取り、同意 | スマホで操作 | スマホで操作(画面は同じ) |
| RPへの戻り方 | スマホの完了画面でボタンを押す | PC側が自動で戻る。スマホ側は「閉じる」で終わり |
| 自社で作る画面 | 開始画面と結果画面 | 開始画面と結果画面(二次元コードや6桁の画面はデジタル庁側) |
代替機能では見えなかったこと
テストカード代替機能で確認できるのはRP側のAPI連携までで、アプリの画面は見られません。今回の通し試験で初めて分かったことを並べます。
| 分かったこと | 代替機能 | 実機 |
|---|---|---|
| 暗証番号の入力が2回になる(4情報を要求した場合) | 分からない | 画面3と4で確認 |
| カードをかざすのは1回 | 分からない | 画面5で確認 |
| 同意画面にアイコン、サービス名、提供する情報、規約リンクが出る | 分からない | 画面7で確認 |
| 完了画面からRPへは利用者がボタンを押して戻る | 分からない | 画面8で確認 |
| 住所の数字が全角で返る | テストデータの値を見れば推測できる | 画面9で確認 |
| キャンセル時にRPへエラーが返る | エラーパターンで再現できる | 画面10で確認 |
代替機能の段階で異常系を終わらせ、実機では画面と戻りの確認に集中する、というテスト計画の分け方は、実際に通してみても妥当でした。
過去記事の訂正。4情報は認証APIで取れる
当社はデジタル認証アプリとは。民間サービスが使うための条件と連携開発の実務で、「氏名・住所などの基本4情報が必要なら署名APIの領域」と書いていました。これは誤りでした。
デジタル庁のAPIリファレンスでは、認証APIの認可リクエストのscopeに name address birthdate gender が定義されており、デジタル庁の資料にも「認証API:マイナンバーカードの券面事項入力補助APを用いた4情報連携機能も利用可能」とあります。今回の実機でも、認証APIで4情報が返ってきました。署名APIは署名用電子証明書で電子署名を行うためのもので、4情報を取るために署名APIが必要なわけではありません。当社の申請も認証APIで4情報を取得する内容で、プラットフォーム事業者との契約は求められていません。
両記事は2026年10月5日付で本文を訂正しました。認証APIと署名APIのどちらを使うかは「氏名・住所が要るか」ではなく、「電子署名が要るか」で決まります。
試せていないこと
今回の試験は、iPhoneとAndroidの同一端末、およびPCとiPhoneの二次元コード連携で、いずれも認証API、有効なカードという経路です。次は未試験で、別の機会に追記します。
- PCとAndroidの二次元コード連携
- 署名API、および顔写真を取得する
picturescope
発注前に決めておく項目
実機を通して、要件定義の段階で決めておくべきだと感じた項目です。
- 4情報を取得するか。取得しないなら暗証番号は1回で済む。取得するなら用途を説明できるか
- 開始画面に「マイナアプリが起動する」「暗証番号を求められる」「個人番号は取得しない」を書くか。Androidでは「パスワード」と表記されるので併記するか
- 完了画面から戻ってこなかった利用者を、あとから再開させる導線があるか
- 戻ってきたときに入力途中の内容が保持されるか
- 住所の全角数字、氏名の外字を、自社のデータ形式にどう正規化するか
- 郵便番号・メールアドレス・電話番号など、4情報に含まれない項目の入力画面があるか
- 同意画面に出る利用規約とプライバシーポリシーのURLが本番で正しく開くか
- キャンセル時にどの画面へ戻すか
- 「自分以外のマイナンバーカードで認証」の経路を自社サービスでどう扱うか
よくある質問
Q. デジタル認証サービスで暗証番号は何回入力しますか?
ログインや当人認証だけなら利用者証明用暗証番号の1回です。氏名・住所・生年月日・性別の4情報を要求すると、券面事項入力補助用暗証番号の入力が加わって2回になります。どちらも4桁の数字です。カードをかざす回数は1回でした。
Q. 基本4情報を取るには署名APIが必要ですか?
必要ありません。認証APIの認可リクエストのscopeに name address birthdate gender を指定すれば、券面事項入力補助APから4情報が返ります。署名APIは署名用電子証明書で電子署名を行うためのAPIです。
Q. 利用者が見る画面のうち、自社で作るのはどこですか?
開始画面と、認証後に戻ってくる結果画面の2つです。間のマイナアプリの7画面は国のアプリで、文言もボタンも変えられません。
Q. 認証が終わったら自動でサービスに戻りますか?
構成によります。スマホのブラウザからアプリを起動する同一端末の構成では、完了画面の「利用中のサービスに移動」を利用者が押して戻ります。PCのブラウザから二次元コードで連携した構成では、PC側が数秒のカウントダウンのあと自動でRPに戻り、スマホ側は「閉じる」で終わります。同一端末では戻らない利用者への再開導線を自社で用意しておく必要があります。
Q. テストカードでどんなデータが返りますか?
J-LISの全AP搭載テストカードには、架空の人物の氏名・住所・生年月日・性別と有効な電子証明書が入っています。認証APIで4情報を要求すると、その値がUserInfoで返ります。住所の数字は全角で返りました。
Q. PCのブラウザからでも使えますか?
使えます。PCの画面にデジタル庁側の二次元コードが表示され、スマホのマイナアプリで読み取り、アプリに出た6桁の数字をPCに入力してから、スマホで暗証番号の入力とカードの読み取りを行います。終わるとPC側が自動でRPに戻ります。二次元コードと6桁の数字には残り時間があります。
Q. iPhoneとAndroidで画面は違いますか?
並びは同じで、暗証番号2回、カードをかざすのは1回です。Androidでは暗証番号が「パスワード」と表記され、読み取りは「読み取り開始」ボタンで始まり、端末ごとの読み取り位置を案内するリンクがあります。アプリの右上に「ヘルプ」も常設されています。
まとめ
テストカードが届いて初めて、利用者が実際に何画面を操作するのかが分かりました。iPhoneとAndroidで画面の並びは同じで、違うのは表記(暗証番号とパスワード)と読み取りの始め方です。カードをかざすのは1回でも、4情報を要求すると暗証番号の入力は2回になります。自社で作れるのは両端の2画面だけで、間の7画面は国のアプリです。PCから使う場合は二次元コードと6桁の数字の手順が加わりますが、その画面もデジタル庁側のもので、終わるとPCが自動でRPに戻ります。
要件定義で効くのは、4情報を本当に取るのか、戻ってこなかった人をどう拾うのか、返ってきた住所をどう正規化するのか、の3点です。これらは代替機能では見えず、実機で通すまで気づきにくい項目でした。
当社では、デジタル認証サービスの利用申請、テストカード代替機能での先行実装、J-LISテストカードの手配、実機での通し試験、本番接続までをお手伝いしています。連携開発の実務とあわせて、マイナンバーシステム導入支援をご覧ください。ご相談はお問い合わせからどうぞ。
この記事に関連するサービス
TodoONada株式会社では、マイナンバーカード認証を組み込んだシステム開発を行っています。
- マイナンバーシステム導入支援 — JPKI・eKYC対応の本人確認をワンストップで
導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。
出典・参照
- デジタル庁 開発者サイト APIリファレンス(民間事業者向け) (2026年10月5日確認)
- デジタル庁 開発者サイト 行政機関等・民間事業者向け実装ガイドライン (2026年10月5日確認)
- デジタル庁「デジタル認証アプリを使ったマイナンバーカードの利活用推進について」(令和7年2月3日、東京都デジタルサービス局掲載) (2026年10月5日確認)
- デジタル庁 開発者サイト テストカード代替機能 (2026年10月5日確認)