マイナンバー(12桁)は取得してはいけない。カード認証と個人番号の誤解を整理する

マイナンバーカードでの本人確認を検討する打ち合わせで、かなりの確率で出てくる質問があります。「うちがユーザーのマイナンバーを預かることになるんですか。漏えいしたら大変では」。情報システム部門やセキュリティ担当から出ると、これだけでプロジェクトが止まることもあります。

答えはノーです。むしろ逆で、本人確認の目的でマイナンバー（12桁の個人番号）を集めることは法律で禁止されています。そしてマイナンバーカードによる本人確認は、個人番号を一切使いません。この2つが世間的にほとんど区別されていないため、正しい理解が社内に共有されないまま、セキュリティ懸念だけが独り歩きしがちです。

本記事は、発注者・事業会社の意思決定者が、社内説明とベンダーへの要件提示にそのまま使える形で、制度の建て付けと実装上の注意点を整理します。

この記事の要点

• マイナンバー（12桁の個人番号）とマイナンバーカード認証（電子証明書）は別物です。認証は番号を一切使いません
• 個人番号の収集・保管は番号法20条で「何人も」禁止されています。本人の同意があっても、法定事務でなければ収集できません
• 民間企業が適法に個人番号を扱うのは、従業員等の税・社会保険手続きといった法定事務がほぼすべてです
• カード認証で取得できるのは、電子証明書による本人性の確認結果と、署名用を使う場合の基本4情報までです
• 実装では、裏面撮影の排除・読み出しスコープの確認・ログへの混入防止で「うっかり取得」を設計段階から塞ぎます

混同の正体 — 「カード」と「ナンバー」は別のもの

言葉を分解すると、誤解の構造がはっきり見えます。

• マイナンバー（個人番号）: カードの裏面に記載された12桁の番号。行政が個人を識別するための番号です
• マイナンバーカード認証（JPKI）: カードのICチップに格納された電子証明書を使う本人確認の仕組み。個人番号は使いません

つまり「マイナンバーカードで本人確認」とは、カードを使うが、ナンバーは使わないということです。同じ物理カードの中に、まったく別の制度で規律された2つのものが同居しているために混乱が起きています。

事業者が取得できるのは、電子証明書による本人性の確認結果と、署名用電子証明書を使う場合の基本4情報（氏名・住所・生年月日・性別）までです。利用者証明用電子証明書を使う場合は、基本4情報すら取得できません。証明書ごとの違いは署名用と利用者証明用の違いで整理しています。

この理解が揃うと、「マイナンバーカード認証を入れる=マイナンバーを預かる」という前提そのものが誤りだと分かります。

番号法の建て付け — 使える場面が法律で限定されている

個人番号の扱いは、番号法（行政手続における特定の個人を識別するための番号の利用等に関する法律）で厳格に定められています。押さえるべき条文は3つです。

規律	内容
利用範囲の限定	個人番号を使えるのは、社会保障・税・災害対策の法定事務に限られます
収集・保管の制限（番号法20条）	法律に定めのある場合を除き、何人も個人番号を含む情報を収集・保管してはなりません
提供の制限（番号法19条）	法定の場合を除き、個人番号を含む情報の提供は禁止されています

決定的に重要なのは、20条の主語が「何人も」であることです。事業者だけでなく、誰であっても、法定の場面以外で個人番号を集めること自体が違法になります。

ここで一般の個人情報の感覚を持ち込むと間違えます。「本人の同意を取れば集めてよい」という発想は、個人番号には通用しません。同意があっても、目的が法定事務でなければ収集できないのです。個人情報保護法の世界では同意が万能鍵のように機能する場面がありますが、番号法ではそうではない。この違いを法務・セキュリティ部門と共有しておくと、後の議論が速くなります。

民間企業が個人番号を扱う場面は実質1つ

一般の事業会社が適法に個人番号を扱う場面は、自社の従業員等の源泉徴収票・社会保険手続きなど、雇用に伴う法定事務がほぼすべてです。顧客の本人確認は、この法定事務に含まれません。

適法・違法の切り分けを並べると次のようになります。

場面	適法性
従業員のマイナンバーを収集する	適法（むしろ義務）
顧客の本人確認のためにマイナンバーを収集する	違法
顧客の本人確認のためにマイナンバーカードの電子証明書を使う	適法（公的個人認証法の枠組み）

この表は社内説明の場でそのまま使えます。ポイントは、3行目が2行目の代替ではなく、そもそも別の制度に基づく別の行為だという点です。「番号を集められないから、代わりに電子証明書で我慢する」のではなく、「本人確認には最初から電子証明書を使うのが正規の設計」なのです。

なお、本人確認記録として何を残すべきか、どこまで保存するかは番号法とは別の論点になります。犯収法上の記録保存要件は本人確認記録の保存要件で扱っています。

実装面の注意 — 「うっかり取得」を設計で塞ぐ

制度上は個人番号に触れない設計になっていても、実装の隙間から意図せず番号が入り込む経路があります。設計段階で塞いでおくべきポイントは4つです。

第一に、券面撮影のフローで裏面を撮影させないことです。 カードの表面には個人番号は書かれていませんが、ユーザーが誤って裏面を送信してくる可能性は現実にあります。「撮影させない」だけでなく、誤って送られた場合に検知して破棄するところまでを設計に含めてください。ユーザーの操作ミスは仕様の想定内に入れておく必要があります。

第二に、ICチップから読み出す情報のスコープを確認することです。 券面事項入力補助APIには個人番号を含む領域があり、読み出し権限と用途が法律で限定されています。本人確認用途では、基本4情報と電子証明書のみを扱う構成にします。ベンダーやSDKが何を読み出しているかは、要件定義の段階で明示的に確認すべき項目です。

第三に、電子証明書のシリアル番号を個人番号と混同しないことです。 シリアル番号は個人番号ではなく、アカウントとの紐付け管理に使ってよい識別子です。ここを取り違えて「番号は一切保存できない」と過剰に萎縮すると、必要な設計まで止まってしまいます。禁止されているのは個人番号の収集・保管であって、証明書のシリアル番号の保持ではありません。

第四に、番号が紛れ込みやすい周辺経路を洗い出すことです。 本体のフローを正しく設計しても、次のような経路から番号が入ってくることがあります。

• アプリケーションログやデバッグログ
• 障害調査時のスクリーンショット
• 問い合わせフォームへの添付ファイル（ユーザーがカード裏面の写真を添付してくる）
• カスタマーサポートのチャット履歴やメール本文

特に問い合わせ経路は見落とされがちです。ユーザーが善意で「カードの写真を送りますね」と裏面画像を添付してくるケースは想定しておくべきです。受け取ってしまった場合の対応手順（検知・削除・記録）を運用側で決めておいてください。

なお、デジタル認証アプリ経由の場合は、そもそもAPIから個人番号を取得できない設計になっています（デジタル認証アプリの利用条件）。eKYCベンダーのSDKも同様で、正規の経路を使っているかぎり個人番号に触れることはありません。

設計レビュー用チェックリスト

要件定義や設計レビューの場で、次の項目を確認してください。

• 券面撮影のフローで裏面を撮影させない導線になっているか
• 誤って裏面画像が送信された場合の検知・破棄の手順が定義されているか
• ICチップから読み出す情報のスコープをベンダーに確認したか（券面事項入力補助APIの利用有無を含む）
• 保存する識別子が電子証明書のシリアル番号であり、個人番号でないことを明文化したか
• ログ・スクリーンショット・問い合わせ添付に番号が混入する経路を洗い出したか
• 問い合わせ経路で個人番号を受け取ってしまった場合の運用手順を決めたか
• 社内の法務・セキュリティ部門に「番号は取得しない」設計であることを説明済みか
• プライバシーポリシーや利用規約の記載が実装と整合しているか

社内説明にそのまま使える一言

会議の場で使える要約を2つ挙げておきます。

• 「マイナンバーカード認証を入れても、マイナンバーは1桁も預かりません。預かることは法律で禁止されており、預からないことが正規の設計です」
• 「取得するのは電子証明書の検証結果と、必要な場合の氏名・住所・生年月日・性別までです。個人情報としての管理は必要ですが、特定個人情報（マイナンバー）の管理義務は発生しません」

2つ目の言い回しは、法務・情報システム部門に対して特に効きます。特定個人情報として扱う場合は、安全管理措置の要求水準が一段上がるためです。「その義務は発生しない」と明示できること自体が、プロジェクトのコストとリスクを下げます。

この整理を共有するだけで、セキュリティ懸念を理由にした社内の反対はかなり解消できます。制度上の位置づけを一段深く確認したい場合はeKYCとJPKIの違いを、導入方式の比較はマイナンバーカード本人確認の4つの組み込み方法を参照してください。本人確認方式全体の地図はeKYC完全マップ2026に、記事の読み進め方はeKYC記事の読み方ガイドにまとめてあります。

まとめ

• マイナンバー（12桁の個人番号）とマイナンバーカード認証（電子証明書）は別物です。認証は番号を使いません
• 個人番号の収集は番号法20条で「何人も」禁止されています。本人確認目的での取得は、同意があっても違法です
• 個人番号を使えるのは社会保障・税・災害対策の法定事務に限られ、民間企業では従業員の税・社会保険手続きがほぼすべてです
• カード認証で取得できるのは、電子証明書による本人性の確認結果と、署名用を使う場合の基本4情報までです
• 実装では、裏面撮影の排除・ICチップの読み出しスコープ確認・ログや問い合わせ添付への混入防止で「うっかり取得」を塞ぎます
• 電子証明書のシリアル番号は個人番号ではありません。紐付け管理に使える識別子であり、過剰に萎縮する必要はありません

よくある質問

Q. マイナンバーカードで本人確認すると、事業者はマイナンバーを預かることになりますか？

なりません。マイナンバーカード認証（JPKI）は、カードのICチップに格納された電子証明書を使う仕組みで、12桁の個人番号は一切使いません。事業者が取得できるのは、電子証明書による本人性の確認結果と、署名用電子証明書を使う場合の基本4情報（氏名・住所・生年月日・性別）までです。

Q. 本人確認のためにマイナンバー（12桁）を集めてもよいですか？

集めてはいけません。番号法20条により、法律に定めのある場合を除き、何人も個人番号を含む情報を収集・保管してはならないとされています。顧客の本人確認は法定事務に含まれないため、本人確認目的での個人番号の収集は違法になります。

Q. 本人の同意があればマイナンバーを取得できますか？

できません。一般の個人情報であれば同意が根拠になり得ますが、個人番号にはその考え方が通用しません。番号法では利用できる場面が社会保障・税・災害対策の法定事務に限定されており、同意があっても目的が法定事務でなければ収集できません。

Q. 民間企業がマイナンバーを扱ってよい場面はありますか？

あります。自社の従業員等の源泉徴収票や社会保険手続きなど、雇用に伴う法定事務がほぼすべてです。この場合はむしろ収集が義務になります。一方、顧客の本人確認はこの法定事務に含まれないため、同じ会社の中でも扱ってよい場面と違法になる場面が分かれます。

Q. 電子証明書のシリアル番号を保存してもよいですか？

問題ありません。電子証明書のシリアル番号は個人番号ではなく、アカウントとの紐付け管理に使ってよい識別子です。禁止されているのは個人番号の収集・保管であり、シリアル番号の保持ではありません。ここを混同して「番号は一切保存できない」と過剰に萎縮する必要はありません。

Q. 実装で個人番号を「うっかり取得」しないためには何をすべきですか？

4点です。券面撮影のフローで裏面を撮影させず、誤送信された場合の検知・破棄を設計すること。ICチップから読み出す情報のスコープを確認すること（券面事項入力補助APIには個人番号を含む領域があります）。シリアル番号と個人番号を混同しないこと。ログ・スクリーンショット・問い合わせ添付など番号が紛れ込みやすい経路を洗い出すことです。

Q. デジタル認証アプリやeKYCベンダーのSDKを使う場合も注意が必要ですか？

デジタル認証アプリは、そもそもAPIから個人番号を取得できない設計になっています。eKYCベンダーのSDKも同様で、正規の経路を使っているかぎり個人番号に触れることはありません。ただし、問い合わせフォームへの添付やサポート対応など、システム外の経路からの混入は自社で塞ぐ必要があります。

主な参考資料: 個人情報保護委員会 特定個人情報の適正な取扱いに関するガイドライン（事業者編）、国税庁 番号制度概要FAQ、e-Gov 番号利用法

TodoONada株式会社では、マイナンバーカード認証（JPKI・eKYC・デジタル認証アプリ連携）を組み込んだWebサービス・スマホアプリの受託開発を行っています。「個人番号に触れない設計になっているか」の設計レビューや、法務・セキュリティ部門への説明資料づくりからのご相談にも対応しています。方式選定から開発・運用まで一貫してご支援し、デジタル庁「デジタル認証アプリ」の利用申請・審査対応も書類作成から指摘対応まで伴走します。料金の目安は認証機能組込みプラン150万円〜、認証込みアプリ開発プラン400万円〜、大規模・個別要件は1,000万円〜です。検討段階のご相談も、マイナンバーシステム導入支援またはお問い合わせからお気軽にどうぞ。

---

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

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

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

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