デジタル庁は2026年8月、マイキープラットフォームの詳細仕様を公開した。公的個人認証サービス（JPKI）を活用する行政システム向けに、対面特化型の類型①APIと汎用性の高い類型②APIが用意され、自治体や開発事業者はサービス要件に応じた認証基盤を選択できるようになる。これにより、窓口端末から非対面のオンラインサービスまで、マイナンバーカードを用いた本人確認の導入ハードルが変化する。

二つのAPI類型が分ける開発責任と利用シーン

マイキープラットフォーム（PPID方式）は、自治体システムと連携してサービスごとに異なる仮名識別子（PPID）を払い出す中核機能を担う。ここで提供される類型①APIは、主に窓口などの対面サービスを対象とし、カード読取画面や読取機能をデジタル庁側が提供する。暗証番号不要の「かざし利用」にも対応し、Windows端末上での動作が前提だ。一方、類型②APIは認証機能のみを提供し、読取画面の開発や端末環境の整備は自治体側の責任となるが、OSを問わず非対面環境でも利用できる。開発工数と柔軟性のトレードオフを、各自治体が自らの行政サービス特性に応じて判断する構造である。

スマートフォン認証とデジタル認証アプリの接続点

類型①APIには、デジタル庁が別途提供する「デジタル認証アプリ」との連携オプションが存在する。この連携により、窓口端末だけでなく利用者のスマートフォン上でも同一のPPIDを払い出すことが可能になり、行政サービスへのログインや本人確認の場面がモバイル端末に拡張される。デジタル認証アプリはiOSおよびAndroidに対応しており、民間事業者は利用不可だが、行政機関にとっては対面と非対面を横断する認証体験を単一のAPI体系で設計できる点が実装上の意味を持つ。

電子証明書の有効性確認がもたらす実務負荷の分岐

両類型とも利用者証明用電子証明書の有効性確認をOCSPレスポンダ方式で実行できるが、CRL提供方式による一括確認は類型②のみが対応する。OCSPレスポンダ方式ではリアルタイムの失効確認が可能である一方、システムの応答設計やネットワーク依存を考慮する必要がある。また、署名用電子証明書の有効性確認はデジタル認証アプリ連携時に限られ、基本4情報（氏名・住所・生年月日・性別）の提供機能も類型①に集約されている。導入する行政サービスがどのレベルの本人確認を求めるかによって、採用すべきAPI類型とシステム設計は大きく変わる。

導入手続きの非対称性が示す開発着手までの時間差

類型①APIを利用する場合、自治体や行政機関は所定の申請書類を提出し、技術情報の開示手続きを経て仕様書の提供を受けるまで約3週間を要する。これに対し、類型②APIは申請手続きが省略され、仕様書の入手から直接開発に着手できる。この導入手続きの非対称性は、迅速なプロトタイピングを求める開発案件や、調達スケジュールに制約のある自治体にとって、類型②を先行して検討する動機になりうる。ただし、申請後のデジタル庁による技術開示プロセスには変更の可能性があり、現時点で具体的な審査基準は明らかにされていない。