WorXUPでは、2026年7月に株式会社ポケモンがマイナンバーカードを使った本人認証の導入を予定していることをお伝えしました。
その仕組みが、8月3日から実際に動き始めています。
今回、デジタル認証が開始となってから初となるポケモン30周年記念商品の抽選に検証も兼ねて応募してみました。
結論から書くと、認証そのものは短時間で終わります。手が止まるのは、認証の前後でした。
※今回の記事はポケモンカードの抽選の手順解説や、当たる確率を上げる方法、などでは一切ありません。
本人確認をサービスへ組み込んだとき利用者が実際にどこで詰まるのかを体験の立場から整理するものです。
今後、自社サービスへ本人確認を導入することを検討している企業や担当者の方に向けた内容になります。
優先抽選に参加するための事前認証
30周年記念商品の優先的な抽選販売に参加するためには、8月14日16時59分までに本人認証を完了していることが条件とされています。
認証にあたって必要なものは、次の3点です。
・有効期限内のマイナンバーカード（アカウント所有者本人のもの）
・利用者証明用電子証明書の暗証番号（数字4桁）
・NFC対応のスマートフォン（iOS 16.0以降、またはAndroid 11以降）
デジタル庁が提供する「デジタル認証アプリ」をダウンロードし、利用登録を済ませたうえで、プレイヤーズクラブ上の「マイナンバーカードで本人認証」から手続きを進める流れになります。
「本人認証済み枠」という設計が上手い
実際に申し込む前にまず設計として触れておきたい点があります。
今回の抽選販売には、「本人認証済み枠」と「本人未認証枠」という2つの応募枠が用意されています。
マイナンバーカードで認証を済ませた人は前者に、そうでない人は後者に応募する形です。
つまり、認証していなくても応募自体はできます。ただし、優先枠には入れません。
前回の記事では、本人確認を厳格にするほど、マイナンバーカードを持っていない人、対応端末を持っていない人、暗証番号を忘れた人がサービスから取り残される、という課題を挙げました。
今回の2枠構成は、その課題に対する事業者側の現実的な回答になっています。
禁止ではなく、インセンティブで移行させる。
認証率を引き上げながら、認証できない既存の利用者を切り捨てない設計です。
企業のサービスやプロダクトに置き換えると
この考え方は、ポケモンカードに限った話ではありません。
すでに会員基盤を持っているサービスが、途中から本人確認を導入しようとすると、「全会員に一斉に認証を求める」という方法は現実的に取りづらくなります。
認証を完了できない層が一定数残り、その分だけ利用者が減るためです。
一方で、認証済みの利用者にだけ便益を寄せる方法であれば、既存の導線を壊さずに移行を進められます。
・限定商品の先行販売や優先枠への参加権
・購入上限や取引上限の緩和
・手数料や審査プロセスの優遇
・本人確認済みであることのプロフィール表示
いずれも、認証を「義務」ではなく「使うと得をするもの」として位置づけるアプローチです。段階的に移行させたい場合の選択肢として、押さえておく価値があります。
申込みにあたり実際に詰まった箇所
ここからが本題です。実際に手を動かして、どこで止まったかを時系列で記録しました。
デジタル認証アプリの利用登録
まずアプリのダウンロードと利用登録から始まります。
最初の関門は暗証番号でした。
ここで必要になるのは、マイナンバーカードの受け取り時に自分で設定した「利用者証明用電子証明書」の4桁の暗証番号です。
マイナンバーカードを日常的に使っていない人にとっては、思い出せるかどうかが最初のハードルになります。
なお、公式の案内には注記として、デジタル認証アプリはデジタル庁がリリース予定の「マイナアプリ」に統合される予定であることが記載されています。
統合後に本人認証を行う場合は、マイナアプリを使うことになるとのことです。
これは導入する企業側にとっては地味に重い話で、利用者向けの案内文、FAQ、スクリーンショット、サポートスクリプトを、統合のタイミングで一斉に差し替える必要が出てきます。
認証基盤を外部に依存する以上、こうした更新コストが継続的に発生することは、導入前に見込んでおくべき部分です。
メールアドレスの一致条件
個人的に今回もっとも実務的な示唆があると感じたのがこの点です。
「ポケモンセンターオンライン」と「プレイヤーズクラブ」は、それぞれ別のアカウントです。
そして優先抽選の条件には、抽選に申し込んだポケモンセンターオンラインのアカウントと、プレイヤーズクラブのアカウントで、登録メールアドレスが一致していることが含まれています。
認証を済ませても、アドレスが一致していなければ優先枠の条件を満たしません。
長く使っているサービスほど、登録当時のアドレスが今と違っている可能性は高くなります。
そして利用者側からすると、「認証したのに条件を満たしていなかった」という失敗は、原因が分かりにくく、不満につながりやすい類のものです。
ここから読み取れる教訓は、次のように考えます。
認証APIを実装することよりも、既存のID体系をどう突き合わせるかのほうが、実務上のコストは高い。
複数のサービスやブランドを別々の会員基盤で運用してきた企業ほど、この問題は深刻になります。
本人確認を入れる前に、そもそも自社の中で「同じ人」をどう判定しているのかを棚卸しする必要があります。
iOSのポップアップブロック
認証ボタンの下には、iOSで手続きを進める場合はポップアップブロックを解除または許可する必要がある、という注意書きが添えられています。
公式がわざわざ案内するということは、それだけ発生しやすいということでもあります。
外部アプリへ遷移する形式の認証では、ブラウザ設定に起因する失敗が必ず一定数発生します。
シークレットモードやプライベートブラウズでの不具合も同様です。
問題は、この種の失敗が利用者側からは原因を特定しづらいことです。
画面には「認証できませんでした」としか出ないのに、実際の原因はブラウザの設定にある、という状況が起きます。
自社に導入する場合は、エラーメッセージの文面と、そこから辿れるFAQを、認証機能そのものと同じ優先度で設計しておく必要があります。
NFCでの読み取り
暗証番号の入力まで進むと、いよいよカードをスマートフォンにかざす工程に入ります。
実際の流れは次のようになります。
1．「マイナンバーカードで本人認証」からデジタル認証アプリが起動する
2．利用者証明用電子証明書の暗証番号（4桁）を入力する
3．アプリの案内に従って、マイナンバーカードをスマートフォンの背面にかざす
4．読み取り完了後、自動的にブラウザへ戻り、認証結果が表示される
作業としては単純ですが、実際にやってみると意外と何度もやり直しが発生しました。
大体想定どおりではありますが、ありがちなやり直しとなる要因は下記となります。
・読み取り位置が端末によって違う
— iPhoneは背面上部、Androidは機種によって背面中央付近など、位置がまちまちです。「かざす」という指示だけでは、どこに当てればいいのか分かりません
・ケースやカード類の干渉
— 厚みのあるケース、金属を含むケース、背面に定期券やICカードを入れている場合は読み取りに失敗しやすくなります
・完了前に離してしまう
— 読み取りには数秒かかります。反応した感触がないため、途中で動かしてしまいがちです
自社サービスやプロダクトに組み込む場合、認証アプリ側の画面はこちらで作り込めません。
だからこそその手前と後ろで補う必要があります。
・事前案内のページに主要機種の読み取り位置を図で示しておく
・ケースを外す、背面のカード類を抜く、といった前提条件を先に伝えておく
・失敗した場合に「もう一度試す」へすぐ戻れる導線を用意しておく
外部の認証基盤を使うということは、もっとも失敗が起きやすい工程のUIを、自社でコントロールできないということでもあります。
その分を前後の案内で埋める設計が必要になります。
混雑と仮想待合室
認証が完了して、いざ該当の抽選に応募しようとしたところ、アクセス集中時の仮想待合室に遷移しました。
順番待ちは20分となり、20分を超えると待合室に並び直しになる仕組みです。
引き続き、大変な人気具合がうかがえますね。
他の作業をしながら待っているとちょうど20分後にアクセスできるようになりました。
一度認証すると、やり直せない
認証画面には、警告として明確に書かれている条件があります。
同一人物のマイナンバーカードで本人認証できるプレイヤーズアカウントは1つに限られること。
そして、一度認証を行うと、誤ったマイナンバーカードで認証してしまった場合でも変更はできないということです。
不正防止の仕組みとしてはこれは正しい設計です。変更を認めてしまえば1人1アカウントという前提そのものが崩れます。
ただし裏を返せば、取り違えや家族間の誤操作が起きたとき、サポート側に救済手段が存在しないということでもあります。
子どものアカウントに保護者のカードで認証してしまった、といったケースは十分に起こり得ます。
自社サービスに同様の仕組みを入れるのであれば、事前に決めておくべきことがあります。
・認証を実行する直前の確認画面を、どこまで固くするか
・誤操作が起きた場合、例外対応を認めるのか、認めないのか
・認めない場合、その方針を利用者にどう事前告知するか
不可逆な操作は、実装よりも運用ルールを先に決めておかないと、後からサポート現場が引き受けることになります。
申し込んでみて分かったこと
一通り体験した総括として、あらためて書きます。
認証そのものにかかる時間は短いものでした。詰まるのは認証の前後です。暗証番号を思い出せるか、アカウント同士が突き合っているか、ブラウザの設定が邪魔をしていないか。技術的に難しい部分ではなく、事前の準備と案内でカバーすべき領域に、失敗の大半が集中しています。
これは、導入する企業がコストを見積もる際の配分にも影響します。
認証APIの実装よりも、事前案内・ID名寄せ・エラー対応のほうが重い。
本人確認の導入は認証機能の追加ではなく、既存の会員運用そのものの見直しに近い作業だと捉えたほうが、見積もりとしては実態に合います。
なお、この仕組みが転売対策として実際に機能するかどうかは、抽選結果が出てみないと分かりません。
当選発表後、結果とあわせて追記または続編としてお伝えする予定です。
最後に
前回の記事では、デジタル認証について「企業と利用者の信頼関係をどう設計するかを問う仕組み」だと書きました。
実際に自分で申し込んでみるとその手前にもう一段、具体的な階層があることが分かります。
信頼設計の前にまず導線設計の問題として立ち上がってくるのです。
どれだけ理念として正しい仕組みでも、暗証番号を思い出せなければ、メールアドレスが一致していなければ、ポップアップがブロックされていれば、利用者はそこで離脱します。
そして離脱した利用者には、その仕組みが何を守ろうとしていたのかは伝わりません。
本人確認をサービスに組み込むということは、認証基盤を選ぶことではなく、利用者が確実に辿り着ける道を、どこまで丁寧に敷けるかという作業なのだと思います。
