デジタル認証アプリ連携の開発実務。申請から本番接続までの流れ・費用・開発範囲

デジタル認証アプリを使うと決めたあと、プロジェクトの成否を分けるのは技術ではなく段取りです。API仕様そのものは標準的なOpenID Connectで、経験のあるチームなら実装で詰まる部分はさほど多くありません。にもかかわらずスケジュールが崩れるのは、契約手続きの重さと、OIDC接続の外側に積まれる開発範囲を初期見積もりに入れ忘れるからです。本記事は、発注者・開発責任者が申請開始前にプロジェクト計画を固められるよう、手続き・開発範囲・費用・期間を実務ベースで整理します。確認日: 2026年7月6日。

サービスの概要と料金の構造（何ができるか、どこから有償か）を先に押さえたい方はデジタル認証アプリとは。民間サービスが使うための条件・料金・できないことからお読みください。本記事はその続きにあたります。

更新（2026年8月23日）: 「デジタル認証アプリ」はサービス名称が「デジタル認証サービス」へ変わり、利用者が使うスマホアプリは2026年8月25日に新アプリ「マイナアプリ」へ統合される予定です。変更点と事業者への影響はデジタル認証サービスへ名称変更。顔写真提供も始まるにまとめています。以下の本文の名称・仕様は執筆時点（2026年7月）のものです。

この記事の要点

• 利用手続きは「申込 → 事前準備契約 → テスト環境で接続テスト → 本契約 → 本番」という2段階契約です。テスト環境に触るだけでも契約が必要です
• 申込書は業務委託契約に関わる書類として契約締結権限者（代表取締役等）の名義が必要で、開発者が個人でサンドボックスを試す類のAPIとは手続きの重さが違います
• 技術はOIDC認可コードフロー（ES256）で標準的です。工数が積まれるのは非対応ユーザーの代替フロー設計と既存会員基盤との突合です
• 認証APIは手数料無料、署名APIはJPKIプラットフォーム事業者との有償契約（固定＋従量）と届出が並走します
• 公式の標準処理期間は示されていませんが、全体では月単位で見るのが安全です。サービスイン時期が決まっているなら申込を工程の先頭に置いてください

手続きの全体像。契約が2段階であることの意味

デジタル庁の案内によると、デジタル認証アプリサービスAPIの利用は次の順で進みます。

段階	内容	主な担い手
1. 利用の申込	公式サイトのフォームから申込	自社（契約締結権限者名義）
2. 事前準備契約の締結	テスト環境を使うための契約	自社×デジタル庁
3. 接続テスト	テスト環境の提供を受けて実装・検証	開発チーム
4. 本契約の締結	本番利用のための契約	自社×デジタル庁
5. 本番テスト・サービス開始	本番環境の提供を受けて最終確認	開発チーム

計画上いちばん効いてくるのは、契約が事前準備契約と本契約の2段階に分かれていることです。テスト環境に触るだけでもまず契約が必要になります。さらに申込書は業務委託契約に関わる書類として契約締結権限者（代表取締役等）の名義が求められるため、社内の法務・稟議・押印のプロセスが工程に入ってきます。「開発者が個人でサンドボックスを触ってみる」ことから始められるAPIとは、手続きの重さが根本的に違います。

デジタル庁自身が「手続きや審査の期間を踏まえ、余裕を持ったスケジュールで」と案内している点も見逃せません。これは形式的な注意書きではなく、サービスイン目標から逆算して早めに申込むことが実務上の最重要ポイントであることの公式な示唆と読むべきです。

発注者側の実務としては、次の3点を最初の1週間で片付けるのが理想です。第一に、申込の名義者と社内承認ルートを確定させること。第二に、申込フォームに記載するサービス内容・利用目的の説明文を用意すること。第三に、署名APIを使うかどうかを決めること（使うならプラットフォーム事業者との契約手続きが並走します）。

開発すべき範囲。標準OIDCだが「周辺」が本体

API仕様はOAuth 2.0 / OpenID Connectの認可コードフローで、IDトークンの署名はES256です。OIDCのRP（Relying Party）実装の経験があるチームなら、コア部分の技術的な新規性は高くありません。実際の工数は、その周辺に積まれます。OIDCとマイナンバーカード認証の関係そのものを整理したい場合はOpenID Connectとマイナンバーカード認証の関係を参照してください。

リダイレクト設計。 スマホアプリ連携ではiOSはUniversal Links、AndroidはApp Linksの登録が必要です。Web導線とネイティブ導線の両方があるサービスでは、それぞれ別に設計・検証する必要があります。

IDトークン検証。 ES256の署名検証に加え、nonceやaudなどの検証を確実に行います。既存のID基盤（Amazon Cognito等）にIdPとして追加する構成であれば、基盤側の設定で済む部分も多くなります。ここは既存構成の調査結果で工数が大きく振れる箇所です。

バックチャネルログアウト。 実装ガイドラインで対応が求められています。セッション管理を自前実装しているサービスは、対応箇所の洗い出しから始める必要があります。既製の認証基盤に乗っている場合と、独自実装のセッション管理を持っている場合とで、作業量が大きく変わります。

非対応ユーザーの受け皿。 マイナンバーカードを持っていない、NFC非対応端末を使っている、アプリを入れたくない、といった利用者向けの代替フローです。ここはデジタル庁の提供範囲ではなく、完全に自社の設計範囲です。

業務側の統合。 認証結果と会員基盤の紐付けです。初回連携時のアカウント突合をどうするか、同一人物が複数アカウントを持っていた場合にどう扱うか、退会時に連携情報をどうするか。仕様として決めるべき論点が並びます。

体感としては、OIDC接続そのものよりも「非対応ユーザーの代替フロー」と「既存会員基盤との紐付け」が要件定義の主戦場になります。RFPやベンダー見積もりを読むときも、この2項目がどれだけ具体的に書かれているかが、そのベンダーの理解度を測る指標になります。見積書の読み解き方は本人確認システムの見積もりチェックリストにまとめています。

費用の構造。無料なのはどこまでか

費用は3つの層に分けて考えると整理できます。

層	内容	費用
デジタル庁側	認証API（ログイン・当人認証）	手数料無料
デジタル庁側	署名API（基本4情報取得・電子署名）	JPKIプラットフォーム事業者との有償契約が別途必要
プラットフォーム事業者	署名検証・有効性確認	契約（固定＋従量）と届出の手続きが発生
自社	開発費（OIDC接続＋代替フロー＋会員基盤統合）	既存基盤の状態により小規模改修〜数百万円規模まで幅がある

署名APIを使う場合、プラットフォーム事業者経由で署名検証・有効性確認を行う構造になるため、その契約と届出の手続きが発生します。この構造がなぜそうなっているのかという背景は公的個人認証（JPKI）の民間利用。自社で認定を取るか、プラットフォーム事業者を使うかで解説しています。

まとめると、**「認証だけなら国のAPIは無料。お金がかかるのは自社側の開発と、署名を使う場合のプラットフォーム事業者契約」**という整理になります。予算計画を作るときは、この3層を分けて記載しておくと社内での説明が通りやすくなります。「マイナンバーカード認証の費用」と一括りにすると、無料の部分と有償の部分が混ざって議論が噛み合いません。

自社側の開発費が「小規模改修〜数百万円規模」と幅を持つのは、既存基盤の状態に依存するためです。見積もりのブレを縮めたいなら、ベンダーに渡す前に既存のID基盤の構成、セッション管理の実装方式、会員データの持ち方を棚卸ししておくことが最も効きます。

期間の考え方。月単位で見る

公式に標準処理期間は示されていませんが、構造上、期間は次の要素の合計になります。

• 申込〜事前準備契約: デジタル庁側の確認・契約手続き
• テスト環境での接続テスト: OIDC接続の実装・検証（実装自体は数週間規模が目安）
• 本契約〜本番接続: 契約手続き＋本番テスト

合計では月単位で見ておくのが安全です。三菱UFJ銀行、DMM.com、東京都公式アプリなど導入事例は既に多数あり、手続き自体は枯れてきていますが、それでも「来月リリースの機能に入れたい」という時間軸では動きません。

さらに、認証APIか署名APIかで手続きの重さが大きく変わります。署名APIを使う場合はプラットフォーム事業者側の契約・接続も並走するため、クリティカルパスが増えます。ここを見誤ると、自社の開発が完了しているのに契約手続き待ちでリリースできない、という事態になります。

計画を立てるときのコツは、開発工程とは別に契約工程のガントを引くことです。開発チームの進捗だけを追っていると、契約側の遅れが見えません。申込日、事前準備契約の締結見込み日、テスト環境の払い出し予定日、本契約の締結見込み日を、開発マイルストーンと同じボードに並べてください。

判断の分かれ目。そもそもこの経路でいいのか

連携作業を始める前に、デジタル認証アプリが自社にとって最適解なのかは確認しておくべきです。手続きを進めてから方式を変えると、投じた時間がそのまま損失になります。

目的	推奨される検討の方向
ログイン・当人認証の強化	デジタル認証アプリ（認証API・無料）が第一候補
犯収法対応の本人確認	署名APIの契約構造まで含めるとeKYCベンダーとの比較が必要。アプリインストール導線を含むUXも判断材料
本人確認フローのUXを細かく作り込みたい	プラットフォーム事業者との直接契約も選択肢

選択肢全体の比較はマイナンバーカード本人確認を自社サービスに組み込む方法は4つに、本人確認方式の全体像はeKYC完全マップ2026にまとめています。

着手前チェックリスト

申込ボタンを押す前に、次を確認してください。

• 申込書の名義者（契約締結権限者）と社内の承認ルート・所要日数を確定した
• 申込フォームに書くサービス内容・利用目的の説明文を用意した
• 認証APIのみか、署名APIも使うかを決めた（署名APIならプラットフォーム事業者の選定・契約を並走させる）
• サービスイン目標日から逆算した申込期限を決め、契約工程を独立したガントに引いた
• 既存ID基盤の構成（Cognito等の利用有無、セッション管理の実装方式）を棚卸しした
• Web導線・ネイティブ導線のどちらを対象にするか決め、Universal Links / App Linksの登録要否を整理した
• 非対応ユーザー（カード未取得・NFC非対応端末・アプリ非導入）の代替フローを仕様として決めた
• 初回連携時のアカウント突合ルール、複数アカウントの扱い、退会時の連携解除を仕様化した
• バックチャネルログアウトの対応箇所を洗い出した

まとめ

• 利用は「申込 → 事前準備契約 → テスト → 本契約 → 本番」の2段階契約です。テスト環境に触るだけでも契約が要り、申込書は契約締結権限者名義が必要です
• デジタル庁自身が余裕を持ったスケジュールを推奨しており、全体は月単位で見るのが安全です
• 技術はOIDC認可コードフロー（ES256）で標準的です。工数は非対応ユーザーの代替フロー設計と既存会員基盤との突合に積まれます
• 認証APIは無料、署名APIはプラットフォーム事業者との有償契約（固定＋従量）と届出が並走します。自社の開発費は既存基盤の状態により小規模改修〜数百万円規模まで幅があります
• サービスイン時期が決まっているなら、申込を最初に出すのが鉄則です。開発工程とは別に契約工程のガントを引いてください

よくある質問

Q. デジタル認証アプリの利用申請にはどんな手続きが必要ですか？

公式サイトのフォームからの利用の申込、事前準備契約の締結、テスト環境の提供を受けての接続テスト、本契約の締結、本番環境での本番テスト・サービス開始という流れです。契約が事前準備契約と本契約の2段階に分かれている点が特徴で、テスト環境に触るだけでもまず契約が必要になります。

Q. 申込書は誰の名義で出す必要がありますか？

申込書は業務委託契約に関わる書類として、契約締結権限者（代表取締役等）の名義が必要です。開発者が個人でサンドボックスを試す類のAPIとは手続きの重さが違うため、社内の法務・稟議・押印にかかる日数もスケジュールに織り込んでおく必要があります。

Q. デジタル認証アプリ連携の開発期間はどのくらいですか？

公式に標準処理期間は示されていませんが、申込〜事前準備契約、テスト環境での接続テスト（実装自体は数週間規模が目安）、本契約〜本番接続の合計となり、全体では月単位で見ておくのが安全です。署名APIを使う場合はプラットフォーム事業者側の契約・接続も並走するため、さらに余裕が必要です。

Q. デジタル認証アプリ連携でいちばん工数がかかるのはどこですか？

OIDC接続そのものではなく、その周辺です。具体的には、マイナンバーカード未取得・NFC非対応端末・アプリ非導入といった非対応ユーザーの代替フロー設計と、認証結果と既存会員基盤の紐付け（初回連携時のアカウント突合、複数アカウント問題の扱い）が要件定義の主戦場になります。ほかにリダイレクト設計（Universal Links / App Links）、IDトークン検証、バックチャネルログアウト対応があります。

Q. デジタル認証アプリ連携の費用はどう構成されますか？

3層に分かれます。デジタル庁側の認証APIは手数料無料です。署名API（基本4情報取得・電子署名）を使う場合はJPKIプラットフォーム事業者との有償契約（固定＋従量）と届出が別途必要です。自社側の開発費はOIDC接続＋代替フロー＋会員基盤統合で、既存基盤の状態により小規模改修〜数百万円規模まで幅があります。

Q. 認証APIと署名APIで手続きの重さは変わりますか？

大きく変わります。認証APIのみであればデジタル庁との手続きで完結しますが、署名APIを使う場合はプラットフォーム事業者との契約・接続が並走します。クリティカルパスが増えるため、スケジュールへの影響も大きくなります。どちらを使うかは申込前に確定させておくべきです。

Q. デジタル認証アプリ以外の選択肢も検討すべきですか？

目的次第です。ログイン・当人認証の強化が目的なら認証APIが無料で使えるデジタル認証アプリが第一候補です。犯収法対応の本人確認が目的なら、署名APIの契約構造まで含めた総額でeKYCベンダーと比較すべきです。本人確認フローのUXを細かく作り込みたい場合は、プラットフォーム事業者との直接契約も選択肢になります。手続きを進めてから方式を変えると時間の損失が大きいため、着手前に確認してください。

主な参考資料: デジタル庁 デジタル認証アプリ（民間事業者向け）、デジタル庁 民間事業者向けよくある質問、実装ガイドライン（開発者サイト）、導入サービス一覧

TodoONada株式会社では、デジタル認証アプリ連携（OpenID Connect）を含むマイナンバーカード認証・電子署名まわりのシステム開発を受託しています。デジタル庁「デジタル認証アプリ（デジタル認証サービス）」の利用申請・審査対応は書類作成から指摘対応まで伴走し、申請準備と並行した接続設計・会員基盤統合の設計からご相談いただけます。方式選定（JPKI・IC読取り・画像方式）から開発・運用までワンストップで対応し、料金の目安は認証機能組込みプラン150万円〜、認証込みアプリ開発プラン400万円〜、大規模・個別要件は1,000万円〜です。ご相談はマイナンバーシステム導入支援またはお問い合わせからお気軽にどうぞ。

---

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

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

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

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