デジタル認証アプリとは。民間サービスが使うための条件・料金・できないことを整理する
「マイナンバーカードの本人確認を自社サービスに入れたい」という検討を始めると、必ず候補に挙がるのがデジタル庁のデジタル認証アプリです。ところが調べても出てくるのは利用者向けの使い方か公式の仕様書ばかりで、発注者・事業会社の意思決定者が本当に知りたい「自社で使えるのか、いくらかかるのか、何ができて何ができないのか」がまとまっていません。本記事は、要件定義やベンダー選定に入る前の段階で、その3点を判断できる材料を揃えることを目的にしています。確認日: 2026年7月4日。
更新（2026年8月23日）: 「デジタル認証アプリ」はサービス名称が「デジタル認証サービス」へ変わり、利用者が使うスマホアプリは2026年8月25日に新アプリ「マイナアプリ」へ統合される予定です。変更点と事業者への影響はデジタル認証サービスへ名称変更。顔写真提供も始まるにまとめています。以下の本文の名称・仕様は執筆時点（2026年7月）のものです。
この記事の要点
- デジタル認証アプリはデジタル庁が2024年6月に提供を始めた公式スマホアプリで、行政専用ではなく民間事業者もAPI連携で利用できます
- APIは認証と署名の2系統です。ログイン用の認証APIは手数料無料ですが、氏名・住所などの基本4情報や電子署名が必要なら署名APIの領域で、プラットフォーム事業者との有償契約と署名検証者としての届出が発生します
- 実装はOAuth 2.0 / OpenID Connectの認可コードフローという標準仕様で、既存のID基盤に1つのIdPを足す形で設計できます
- 利用は申請制です。マイナンバー（12桁の個人番号）は取得できず、アプリのインストール導線と非対応ユーザーの代替フローは自社の設計範囲として残ります
全体像。利用者はアプリ、事業者はAPIという役割分担
構図そのものは単純です。関与する2者の持ち分をはっきりさせておくと、以降の判断がぶれません。
- 利用者側: デジタル認証アプリをスマートフォンに入れ、マイナンバーカードを読み取って使う
- 事業者側: 自社のWebサービス・スマホアプリから、デジタル認証アプリサービスのAPIに連携する
利用者がICカードリーダーや専用機器を用意する必要はありません。NFC対応スマートフォンとマイナンバーカード（またはスマートフォンに搭載した電子証明書）だけで完結します。東京都の公式アプリのログインなどで実際に目にしたことがある方も多いはずです。
発注者の視点で意味があるのは、マイナンバーカードの読み取りという最も厄介な部分を、国の公式アプリに任せられるという一点です。カード読み取りを自前で実装するとNFCの挙動差、端末ごとの読み取り精度、暗証番号入力のUXといった検証項目が一気に増えます。そこをデジタル庁側に寄せられるため、自社の開発範囲は「認証結果を受け取って会員基盤とつなぐ部分」に集中できます。
出典: デジタル認証アプリ（デジタル庁）（2026年7月時点の画面）
認証APIと署名API。無料なのは前半だけ
デジタル認証アプリサービスのAPIは、大きく認証と署名に分かれます。これはマイナンバーカードのICチップに2種類の電子証明書が入っている構造にそのまま対応しています。2種類の証明書の使い分けは署名用電子証明書と利用者証明用電子証明書の違いで詳しく扱っています。
| 認証API | 署名API | |
|---|---|---|
| 使う電子証明書 | 利用者証明用 | 署名用 |
| できること | ログイン・当人認証（本人であることの確認） | 電子署名、基本4情報（氏名・住所・生年月日・性別）の取得 |
| 手数料 | 無料 | プラットフォーム事業者との有償契約が必要 |
| 主な用途 | 会員サービスのログイン強化、アカウント登録時の当人認証 | 契約・申込手続き、犯収法対応の本人確認 |
検討の初期でつまずきやすいのが料金の構造です。「認証APIは手数料無料」という部分だけが独り歩きしがちですが、氏名や住所を取得したい、あるいは電子署名が欲しいのであれば、それは署名APIの領域です。署名APIを使うには、公的個人認証サービスのプラットフォーム事業者（主務大臣の認定を受けた民間事業者）との有償契約と、署名検証者としての届出が必要になります。「無料でマイナンバーカード本人確認が入れられる」と読んで要件定義を進めると、後から当てが外れます。
ここは社内稟議の書き方にも直結します。「国のAPIだから費用ゼロ」と説明してしまうと、署名APIが必要だと判明した時点で予算の組み直しになります。稟議の段階で「認証で足りるのか、署名まで要るのか」を先に確定させておくことを強くおすすめします。判断の起点は「氏名・住所を自社に取り込む必要があるか」です。
技術仕様。標準的なOpenID Connectの組み合わせ
実装面はOAuth 2.0 / OpenID Connectの認可コードフローで、署名処理ではClient Credentialsフローも併用します。IDトークンの署名アルゴリズムはES256です。
利用者から見た流れは次のようになります。
- 利用者が自社サービス上で認証を開始し、デジタル認証アプリへ遷移する
- 利用者がマイナンバーカードを読み取り、暗証番号を入力する
- 認可コードが自社サービスへ返り、トークンと交換する
- UserInfoエンドポイントでスコープの範囲の属性を取得する
OIDCに対応した認証基盤（Amazon Cognito等）との接続構成例も公開されており、既存のID基盤に「マイナンバーカード認証」を1つのIdPとして足す形で設計できます。この「PKIをOIDCへ橋渡しする」という構造の意味はOpenID Connectとマイナンバーカード認証の関係で整理しています。
実装要件としては、リダイレクトURI（iOSはUniversal Links、AndroidはApp Links）の登録、IDトークンの検証、バックチャネルログアウトへの対応などがあり、デジタル庁の開発者サイトにガイドラインが公開されています。特別な独自プロトコルではないため、OIDCのRP実装経験があるチームならコア部分の技術的ハードルは高くありません。 発注時に「マイナンバーカード対応の特殊案件だから割高」と言われた場合は、どの部分が特殊なのかを具体的に説明してもらうべきです。
利用開始までの手順。申請制であることの意味
利用は申請制です。おおまかな流れは次のとおりです。
- デジタル庁の問い合わせフォームから利用相談
- 利用申請・審査（サービス内容・利用目的の確認）
- 接続情報の発行、テスト環境での接続テスト
- 本番接続・サービス開始
署名APIを使う場合は、これと並行してプラットフォーム事業者との契約・届出の手続きが走ります。
ここで発注者が理解しておくべきなのは、「アカウントを作れば今日から触れる」類のAPIではないという点です。一般的なSaaSのAPIと同じ感覚でスケジュールを引くと、サービスイン目標に間に合いません。リリース時期が決まっているなら、申請を工程の最初に置くのが鉄則です。申請から本番接続までの実務、契約の段階構成、費用と期間の考え方はデジタル認証アプリ連携の開発実務で具体的に扱っています。
できないこと。要件定義の前に共有しておく4点
期待値のズレが起きやすいポイントを、あらかじめ社内とベンダーの双方で共有しておくべきです。
1. マイナンバー（12桁の個人番号）は取得できません。 そもそも民間事業者が本人確認目的で個人番号を収集することは番号法で認められていません。取得できるのは電子証明書に紐づく本人性と、署名APIの範囲での基本4情報です。この線引きを誤ると設計そのものが法令違反になりますので、民間企業がマイナンバーを集めてはいけない理由もあわせて確認してください。
2. 利用者にアプリのインストールを求める導線が必要です。 「デジタル認証アプリを入れてください」という一手間は、ユーザー層によっては明確な離脱要因になります。既にアプリを持っている層が厚いサービスかどうかで、実効的なコンバージョンは大きく変わります。
3. NFC対応スマートフォンが前提です。 対応機種外の利用者、そもそもマイナンバーカードを持たない利用者に対する代替フローは、別途自社で設計する必要があります。ここを「後で考える」にすると、リリース直前に仕様追加が発生します。
4. 画面遷移はデジタル認証アプリのUIを経由します。 本人確認フローのUXを細かく作り込みたい場合は、eKYCベンダーのSDKやプラットフォーム事業者との直接連携のほうが自由度は高くなります。
これらを踏まえた選択肢全体の比較はマイナンバーカード本人確認を自社サービスに組み込む方法は4つに整理しています。本人確認方式の地図全体を俯瞰したい場合はeKYC完全マップ2026から読むのが早道です。
向いているサービス・向いていないサービス
同じマイナンバーカード認証でも、目的によって適不適がはっきり分かれます。
向いているケース
- 会員サービスのログイン強化・アカウント乗っ取り対策が目的（認証APIが無料で使えるため費用対効果が出やすい）
- 自治体・行政と接点のあるサービス（利用者が既にアプリを持っている可能性が高く、インストール導線の摩擦が小さい）
- なりすまし対策が急務のCtoCサービス・マッチングサービス
慎重に比較すべきケース
- 犯収法対応の本人確認が主目的で、かつ確認件数が多い場合。この場合は署名APIの契約構造まで含めた総コストで、eKYCベンダーと比較したうえで選ぶのが安全です
- 本人確認フローのUXを自社ブランドで完全に統制したい場合
発注前チェックリスト
ベンダーとの初回打ち合わせまでに、社内で次を埋めておくと議論が一気に進みます。
- 目的は**ログイン強化（当人認証）**か、**身元確認（犯収法等の本人確認）**か。両方なら優先順位はどちらか
- 氏名・住所・生年月日・性別を自社システムに取り込む必要があるか（あるなら署名API＝有償契約が前提）
- 電子署名そのもの（契約書への署名）が必要か
- マイナンバーカードを持たない・NFC非対応端末の利用者にどう対応するか。代替フローの要否と、その方式
- 既存の会員基盤（ID基盤）は何か。OIDCのIdPを追加できる構成か
- サービスイン目標日はいつか。そこから逆算した申請開始日を決めているか
- 署名APIを使う場合、どのプラットフォーム事業者と契約するか。候補と料金体系を比較したか
- 認証結果と既存アカウントの突合ルール（初回連携、複数アカウント、退会時の扱い）を決めたか
まとめ
- デジタル認証アプリはデジタル庁公式の「マイナンバーカード読み取りを任せられる」アプリで、民間事業者もAPI連携で利用できます
- 認証API（ログイン・当人認証）は手数料無料、署名API（基本4情報の取得・電子署名）はプラットフォーム事業者との有償契約と署名検証者の届出が必要です
- 実装は標準的なOpenID Connect（認可コードフロー、ES256）で、既存のID基盤にIdPとして追加する設計ができます
- 利用は申請制で審査があります。サービスイン時期から逆算して申請を工程の先頭に置いてください
- マイナンバー（12桁）は取得できません。アプリのインストール導線と非対応ユーザーの受け皿は自社の設計範囲として残ります
- 犯収法対応が主目的で件数が多い場合は、署名APIの契約構造まで含めた総額でeKYCベンダーと比較したうえで判断すべきです
よくある質問
Q. デジタル認証アプリは民間企業でも使えますか？
使えます。デジタル庁が2024年6月に提供を始めた公式スマホアプリで、行政サービス専用ではありません。民間事業者も自社のWebサービス・スマホアプリからAPI連携して利用できます。ただし利用は申請制で、サービス内容・利用目的の確認を含む審査があります。
Q. デジタル認証アプリの利用料金はいくらですか？
ログイン・当人認証に使う認証APIは手数料無料です。一方、基本4情報（氏名・住所・生年月日・性別）の取得や電子署名を行う署名APIを使う場合は、公的個人認証サービスのプラットフォーム事業者との有償契約と、署名検証者としての届出が必要になります。「マイナンバーカード本人確認が完全に無料で入る」わけではない点に注意してください。
Q. 認証APIと署名APIはどちらを使えばよいですか？
目的で決まります。会員サービスのログイン強化やアカウント登録時の当人認証が目的なら認証APIで足ります。契約・申込手続きや犯収法対応の本人確認のように、氏名・住所などの基本4情報を取得したい、あるいは電子署名が必要な場合は署名APIの領域です。使う電子証明書も、前者は利用者証明用、後者は署名用と異なります。
Q. デジタル認証アプリでマイナンバー（12桁の個人番号）は取得できますか？
取得できません。そもそも民間事業者が本人確認目的で個人番号を収集することは番号法で認められていないためです。取得できるのは電子証明書に紐づく本人性と、署名APIの範囲での基本4情報（氏名・住所・生年月日・性別）です。
Q. デジタル認証アプリの技術仕様は特殊ですか？
特殊ではありません。OAuth 2.0 / OpenID Connectの認可コードフローで、署名処理ではClient Credentialsフローを併用します。IDトークンの署名アルゴリズムはES256です。OIDCに対応した認証基盤（Amazon Cognito等）との接続構成例も公開されており、既存のID基盤にIdPを1つ追加する形で設計できます。実装要件としてリダイレクトURI（iOSはUniversal Links、AndroidはApp Links）の登録、IDトークン検証、バックチャネルログアウト対応などがあります。
Q. 利用開始までにどんな手続きが必要ですか？
デジタル庁の問い合わせフォームからの利用相談、利用申請・審査（サービス内容・利用目的の確認）、接続情報の発行とテスト環境での接続テスト、本番接続・サービス開始という流れです。署名APIを使う場合はプラットフォーム事業者との契約・届出が並行して進みます。アカウントを作ればすぐ使えるAPIではないため、サービスイン目標から逆算して早めに動く必要があります。
Q. デジタル認証アプリはどんなサービスに向いていますか？
会員サービスのログイン強化・アカウント乗っ取り対策（認証APIが無料）、自治体・行政と接点があり利用者が既にアプリを持っている可能性が高いサービス、なりすまし対策が急務のCtoC・マッチングサービスに向いています。逆に犯収法対応の本人確認が主目的で件数も多い場合は、署名APIの契約構造まで含めてeKYCベンダーと比較したうえで選ぶのが安全です。
主な参考資料: デジタル庁 デジタル認証アプリ（民間事業者向け）、実装ガイドライン（開発者サイト）、導入事例
TodoONada株式会社では、マイナンバーカード認証（JPKI・eKYC）を組み込んだWebサービス・スマホアプリの受託開発を行っています。「認証APIで足りるのか、署名APIまで必要か」という要件整理の段階からご相談いただけますし、デジタル庁「デジタル認証アプリ（デジタル認証サービス）」の利用申請・審査対応は書類作成から指摘対応まで伴走します。方式選定（JPKI・IC読取り・画像方式）から開発・運用までワンストップで対応し、料金の目安は認証機能組込みプラン150万円〜、認証込みアプリ開発プラン400万円〜、大規模・個別要件は1,000万円〜です。マイナンバー関連記事の読み進め方はeKYC記事ガイドにまとめていますので、あわせてご覧ください。ご相談はマイナンバーシステム導入支援またはお問い合わせからお気軽にどうぞ。
この記事に関連するサービス
TodoONada株式会社では、マイナンバーカード認証を組み込んだシステム開発を行っています。
- マイナンバーシステム導入支援 — JPKI・eKYC対応の本人確認をワンストップで
導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。
出典・参照
- デジタル庁 デジタル認証アプリ（民間事業者向け） （2026年7月4日確認）
- デジタル庁 開発者サイト 実装ガイドライン （2026年7月4日確認）
- デジタル庁 デジタル認証アプリ 導入事例 （2026年7月4日確認）
- デジタル認証アプリ（デジタル庁）公式サイト （2026年7月4日確認）
