マイナポータルAPI連携でできること
「マイナンバーカードで本人確認して、そのまま年収も取れるんですよね」という理解は、半分だけ正しく、実務では危険です。本人確認の仕組みと、行政が持つ情報を取得する仕組みは別物で、必要な手続きも、かかる期間も、社内で通すべき稟議の重さも違います。本記事は、審査書類の提出を減らしたい、証明書のアップロードをやめたいと考えている事業会社の企画・開発責任者に向けて、マイナポータルAPIで何ができて、使い始めるまでに何が必要かを整理します。確認日: 2026年7月18日。
この記事の要点
- マイナポータルAPIは「本人確認」の仕組みではありません。確認済みの本人について、行政が保有する情報を本人同意で取得する仕組みです
- 公開されているのは4用途13種のAPI。民間の主役は自己情報取得APIと医療保険情報取得APIで、この2つの管轄を取り違えると申請からやり直しになります
- 民間活用の主戦場は「証明書類の提出の置き換え」です。ローン審査・保険・年末調整で実績が積み上がっています
- 利用開始までは機密保持誓約・デジタル庁審査・EV証明書提出を含めて全体で半年〜1年が公式の目安です。事業計画にリードタイムを織り込む必要があります
混同されやすい3つの仕組みを分ける
まず、マイナンバーカードまわりで名前が似ている3つの仕組みを、役割で切り分けます。
| 仕組み | 役割 |
|---|---|
| JPKI(公的個人認証) | マイナンバーカードの電子証明書で「本人か」を確認する |
| デジタル認証アプリ | JPKIをOIDCで簡単に組み込むための国の公式アプリ |
| マイナポータルAPI | 行政機関が保有する「本人の情報」を本人同意で取得する |
前の2つは認証(この人は誰か)の話です。認証方式そのものの整理はマイナンバーとOIDCの関係に、国の公式アプリを民間サービスが使う条件はデジタル認証アプリを民間サービスで使うにまとめています。
マイナポータルAPIはその先にあります。確認した本人について、行政が持っているデータそのものを取りに行く仕組みです。所得証明書をユーザーにアップロードさせていた処理を、行政からの直接取得に置き換える、と言えばイメージしやすいと思います。
この違いは設計にそのまま効いてきます。マイナポータルAPIを使う画面には、必ずその前段に本人確認と同意の取得が入ります。「マイナポータルAPIを導入する」という要件は、実際には「本人確認基盤+情報取得APIの連携」という2つの構築を意味しており、片方だけの見積もりを見て投資判断をすると足りません。
公開されているAPIの全体像
デジタル庁のマイナポータルAPI仕様公開サイトには、4用途・13種のAPIが公開されています。民間サービスに関係が深いのは次の系統です。
- 自己情報取得API: 税・所得、公金受取口座、世帯、年金、児童手当、雇用保険など、行政保有の自己情報を取得します。民間活用の主役です
- 医療保険情報取得API: 薬剤情報、健診情報、医療費通知情報など。保険・ヘルスケア系はこちらの管轄になります
- お知らせ情報取得・民間送達サービス保有情報取得API: 行政からのお知らせや、民間送達サービス(e-私書箱等)が保有する控除証明書などを取得します
- 利用者登録等API: 自社サービスからマイナポータルの利用者登録を行う導線です
ここで最も注意すべき点をひとつ挙げます。「薬剤情報や医療費通知」は自己情報取得APIではなく、医療保険情報取得APIの管轄です。 名前の直感に反する切り分けで、要件定義の段階でどちらのAPIかを取り違えると、申請からやり直しになります。半年〜1年のリードタイムがかかるプロジェクトで最初からやり直すダメージは大きいので、企画段階で「取りたい情報の一つひとつが、どのAPIの仕様書に載っているか」を確認するプロセスを必ず挟んでください。
民間活用の主戦場は「書類提出の置き換え」
デジタル庁の活用事例一覧には、自己情報取得APIだけで55件の事例が掲載されています。パターンはほぼ共通しています。
- ローン・与信審査: 三井住友海上(収入情報の電子取得)、SMBCコンシューマーファイナンス(収入証明書類の代替)、セブン銀行(ATMから所得情報を提出)
- 保険: 日本生命(加入時の健診結果を電子提出)
- 税・年末調整: 国税庁の連携プラットフォーム(控除証明書の一括取得)。NRIのe-私書箱が民間送達のハブとして保険会社11社に使われています
- 属性証明: 婚活サービスの独身証明・年収証明、障害者手帳情報による割引適用(JR九州)
共通しているのは、「ユーザーに紙の証明書を取りに行かせない」ことが価値の源泉になっている点です。役所や勤務先に書類を取りに行く手間は、申込フローにおける最大級の離脱要因です。ここを消せる業務であれば投資が回収しやすく、逆に「あれば便利」程度の情報取得のためだけに半年〜1年のプロジェクトを立てるのは割に合いません。
自社の申込フローのどこに紙の証明書があるかを数え、その提出率・離脱率を測るところから検討を始めるのが現実的な進め方です。
方向性としては、書類アップロード型のeKYCがJPKI方式に置き換わっていくのと同じ流れの延長にあります。本人確認は電子証明書へ、証明書類の提出はAPI取得へ、という置き換えが並行して進んでいると捉えるとわかりやすいと思います。
使うためのハードル: 審査と期間
自己情報取得APIの利用手順は、公式ページに流れが明記されています。
- ガイドライン・利用規約の確認と機密保持誓約書の提出、仕様書の取得申請
- 利用申請とデジタル庁・運営主体との事前打合せ(約2か月)
- デジタル庁の審査(約1.5か月)
- 開発(約3か月)、接続試験、本番確認
全体で半年〜1年が公式の目安です。さらに実務上の制約が2つあります。詳細仕様書は申請しないと読めないため、契約前・稟議前に技術的な実現可能性を精査しきれません。また本番確認環境へのアクセスには、企業の実在性証明としてEV証明書の提出も求められます。なお、テスト用マイナンバーカードを使った接続試験環境は用意されているため、開発フェーズに入ってからの検証手段は確保されています。
つまり、これは「来月リリースの機能にちょっと組み込む」類のAPIではありません。審査と行政側との調整を含む1つのプロジェクトとして計画し、経営に対しても半年〜1年のリードタイムを前提に説明する必要があります。逆に言えば、この期間に耐えられる体力があることが参入障壁になっており、先行事例が金融・保険の大手に集中しているのはそのためでもあります。
発注・企画時のチェックリスト
構想段階で埋めておきたい項目です。ここが曖昧なまま開発ベンダーに見積もりを依頼しても、意味のある数字は出てきません。
- 取りたい情報の特定: 一つひとつの情報項目が、自己情報取得API・医療保険情報取得API・民間送達のどの管轄に載っているかを仕様公開サイトで確認したか
- 業務価値の確認: その情報取得が置き換えるのは、現行フローのどの書類提出か。提出率・離脱率を測っているか
- 本人確認との一体設計: 情報取得の前段に入る本人確認と同意取得を、どの方式で実現するか(デジタル認証アプリの連携開発などと組み合わせる設計になります)
- マイナンバー(12桁)を扱わない設計になっているか: この仕組みで扱うのは行政保有情報であって、個人番号そのものではありません。個人番号の取得は原則禁止であり、混同すると法令違反のリスクがあります
- リードタイムの織り込み: 申請から本番まで半年〜1年。事業計画・予算年度と整合しているか
- 体制の確保: 事前打合せ・審査対応にあたる担当者を確保できるか。機密保持誓約書やEV証明書の手配を誰が行うか
- 段階的な導入計画: 初回は取得する情報を絞り、後から拡張する計画になっているか
本人確認方式の全体像から整理したい場合はeKYC完全マップ2026を、関連記事をどの順で読むべきかはeKYC・本人確認記事の読み方ガイドを参照してください。
まとめ
- マイナポータルAPIは「本人確認」ではなく「行政保有の本人情報を本人同意で取得する」仕組みです。JPKIやデジタル認証アプリとは役割が異なり、導入時は両方の構築が必要になります
- 公開APIは4用途13種。民間の主役は自己情報取得APIと医療保険情報取得APIで、薬剤情報や医療費通知は後者の管轄です。取り違えると申請からやり直しになります
- 活用事例の主戦場は「証明書類の提出の置き換え」です。ローン審査・保険・年末調整で実績が積み上がっており、自己情報取得APIだけで55件の事例が公開されています
- 価値が出るのは、紙の証明書を取りに行く手間が申込フローの離脱要因になっている業務です。まず自社フローのどこに紙があるかを数えるところから始めてください
- 利用には機密保持誓約書・デジタル庁の審査・EV証明書の提出が必要で、全体で半年〜1年のプロジェクトになります。事業計画にリードタイムを織り込んでください
- この仕組みで扱うのは行政保有情報であり、マイナンバー(12桁)そのものではありません。個人番号の取得は原則禁止である点と混同しないことが重要です
よくある質問
Q. マイナポータルAPIで何ができるのですか?
行政機関が保有している本人の情報を、本人の同意にもとづいて自社サービスに取り込めます。税・所得、公金受取口座、世帯、年金、児童手当、雇用保険といった自己情報のほか、薬剤情報・健診情報・医療費通知などの医療保険情報、行政からのお知らせや民間送達サービスが保有する控除証明書なども対象です。所得証明書のアップロードを行政からの直接取得に置き換える、といった使い方が典型です。
Q. マイナポータルAPIは本人確認に使えますか?
本人確認の仕組みではありません。本人確認はJPKI(公的個人認証)やデジタル認証アプリが担い、マイナポータルAPIはその先で「確認済みの本人について行政が持つ情報を取得する」役割です。マイナポータルAPIを使う画面の前段には必ず本人確認と同意の取得が入るため、導入時は認証基盤と情報取得APIの両方を設計する必要があります。
Q. マイナポータルAPIにはどんな種類がありますか?
デジタル庁の仕様公開サイトで4用途13種が公開されています。民間に関係が深いのは、自己情報取得API(税・所得、公金受取口座、世帯、年金など)、医療保険情報取得API(薬剤情報、健診情報、医療費通知など)、お知らせ情報取得・民間送達サービス保有情報取得API、利用者登録等APIの4系統です。薬剤情報や医療費通知は自己情報取得APIではなく医療保険情報取得APIの管轄である点に注意してください。
Q. マイナポータルAPIの利用にはどのくらい期間がかかりますか?
公式の目安は全体で半年〜1年です。内訳は、ガイドライン・利用規約の確認と機密保持誓約書の提出および仕様書の取得申請、利用申請とデジタル庁・運営主体との事前打合せ(約2か月)、デジタル庁の審査(約1.5か月)、開発(約3か月)と接続試験・本番確認、という流れになります。来月リリースの機能に組み込む類のAPIではなく、プロジェクトとして計画する必要があります。
Q. マイナポータルAPIを使うには何が必要ですか?
機密保持誓約書の提出とガイドライン・利用規約の確認、利用申請とデジタル庁・運営主体との事前打合せ、デジタル庁の審査の通過が必要です。詳細仕様書は申請しないと読めず、本番確認環境へのアクセスには企業の実在性証明としてEV証明書の提出も求められます。開発段階では、テスト用マイナンバーカードを使った接続試験環境が用意されています。
Q. マイナポータルAPIでマイナンバー(12桁)は取得できますか?
この仕組みで扱うのは行政機関が保有する本人の情報であって、個人番号そのものではありません。マイナンバー(12桁)の取得は法令で用途が限定されており原則として禁止されています。「マイナンバーカードを使う」ことと「マイナンバーを取得する」ことはまったく別の話で、ここを混同したまま要件を書くと法令違反のリスクがあります。
Q. どんな業務ならマイナポータルAPIの投資が回収できますか?
ユーザーに紙の証明書を取りに行かせている業務です。公開されている活用事例も、ローン・与信審査での収入証明書類の代替、保険加入時の健診結果の電子提出、年末調整での控除証明書の一括取得、婚活サービスの独身証明・年収証明など、書類提出の置き換えに集中しています。役所や勤務先に書類を取りに行く手間が申込フローの離脱要因になっているなら効果が見込めますが、「あれば便利」程度の情報取得のために半年〜1年のプロジェクトを立てるのは割に合いません。
主な参考資料: デジタル庁 マイナポータルAPI、マイナポータルAPI仕様公開サイト、活用事例一覧
TodoONada株式会社では、マイナンバーカード認証(JPKI・eKYC)と行政API連携を含む本人確認システムの受託開発を行っています。方式選定から開発・運用までワンストップで支援しており、デジタル庁「デジタル認証アプリ」の利用申請・審査対応も書類作成から指摘対応まで伴走します。マイナポータルAPIについても、「取りたい情報がどのAPIの管轄か」「本人確認とどう組み合わせるか」といった構想段階の壁打ちからご相談いただけます。料金の目安は認証機能組込みプラン150万円〜、認証込みアプリ開発プラン400万円〜、大規模・個別要件は1,000万円〜です。マイナンバーシステム導入支援またはお問い合わせからお気軽にどうぞ。
この記事に関連するサービス
TodoONada株式会社では、マイナンバーカード認証を組み込んだシステム開発を行っています。
- マイナンバーシステム導入支援 — JPKI・eKYC対応の本人確認をワンストップで
導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。
出典・参照
- デジタル庁 マイナポータルAPI (2026年7月18日確認)
- マイナポータルAPI仕様公開サイト (2026年7月18日確認)
- マイナポータルAPI 活用事例一覧 (2026年7月18日確認)
- 自己情報取得API(利用の流れ・審査プロセス) (2026年7月18日確認)