eKYCのAPI・SDK実装を比較｜自社アプリ・Webへの組み込み方式と選び方

自社のアプリやWebサービスに本人確認（eKYC）を組み込むとき、最初にぶつかるのが「どのサービスがAPIやSDKを提供していて、それぞれ何を使えば組み込めるのか」という壁です。

SaaSの画面に利用者を飛ばす方式なら迷いませんが、自社プロダクトの中で完結させたい場合は、提供形態（REST API／モバイルSDK／Web組み込み／App Clip／NFCによるICチップ読取など）がサービスごとに違い、公式サイトの営業文だけでは見分けがつきません。

この記事では、eKYCの実装方式を「API提供型・SDK提供型・Webブラウザ組み込み（タグ）型・SaaS画面完結型・App Clip／NFCネイティブ型」の5系統に整理し、主要なeKYCサービスがどの形態に対応するかを一覧で示します。

そのうえで、各方式で自社が負う開発工数・保守範囲の違い、本人確認方式（犯収法の各方式）との関係、2027年の法改正が実装選定に与える影響、そして自社のプロダクト形態と開発リソースに合わせた選び方までを解説します。

まずは実装方式の全体像と、サービスごとの提供形態の一覧から確認していきます。本記事はeKYCの基礎解説ではなく、実装方式をどう選ぶかに焦点を当てます。

eKYCの実装方式は大きく5系統に分かれる

eKYC（オンラインで本人確認を完結させる仕組み）を自社プロダクトに組み込む方法は、提供形態で見ると大きく5系統に分かれます。どの系統を選ぶかで、自社が書くコードの量、UI（利用者に見える画面）をどこまで自由に作れるか、対応できる本人確認の方式が変わります。まずは判断の軸として、この5系統を押さえておきます。

• API提供型：本人確認の処理をサーバー間のREST APIなどで呼び出す形態。画面や撮影フローは自社で作り込み、照合や審査の機能をAPIで利用します。
• SDK提供型：iOS・Androidのモバイルアプリに組み込む開発キット（SDK）を利用する形態。撮影・ICチップ読取・ライブネス（なりすまし検知）などの画面と処理をSDKが持ちます。
• Webブラウザ組み込み（タグ）型：自社サイトにJavaScriptタグを設置し、Webブラウザ上で本人確認を動かす形態。アプリを持たないWebサービスでも導入できます。
• SaaS画面完結型：ベンダーが用意した本人確認用の画面へ利用者を遷移させ、そこで完結させる形態。自社側の実装が最も軽い代わりに、画面のカスタマイズ範囲は狭くなります。
• App Clip／NFCネイティブ型：iOSのApp Clipや、スマートフォンのNFC（近距離無線通信）でマイナンバーカードのICチップを読み取る、ネイティブアプリ寄りの形態。ICチップ読取や公的個人認証を使う場合に関わります。

「本人確認をアプリで行うか、Webブラウザで行うか」というよく語られる二分も、この5系統の中の違いとして捉えられます。ネイティブアプリ向けはSDK提供型やApp Clip／NFCネイティブ型、Webサービス向けはタグ型やSaaS画面完結型が対応し、API提供型はサーバー側から両方に接続できます。次のセクションで、実際のサービスがどの形態を提供しているかを一覧で見ていきます。

【一覧】主要eKYCサービスのAPI/SDK・タグ・App Clip・NFC対応

実装方式を検討するうえで最初に知りたいのは、「どのサービスが、どの提供形態に対応しているか」です。ここでは主要なeKYCサービスを、REST API／モバイルSDK／Webブラウザ組み込み（タグ）／App Clip／NFCによるICチップ読取／公的個人認証（JPKI）対応の観点で横並びに整理しました。

組み込める形が提供されていないサービスは、実装の選択肢から外れるため、まずこの一覧で自社が使える形態を持つサービスに当たりを付けてください。

※2026年7月時点の各社公式情報にもとづく一般的な傾向です。実際の対応状況は各社の公式情報をご確認ください。

ここからは、各実装方式で自社が具体的に何を作り、何をベンダーに任せられるのかを見ていきます。

各実装方式の違い ── 何を自前で実装し、何をベンダーが担うか

同じ「本人確認を組み込む」でも、選ぶ実装方式によって自社が書くコードの範囲は大きく変わります。ここでは5系統それぞれについて、自社が担う部分とベンダーが肩代わりする部分、そして工数・保守の面での向き不向きを整理します。自社の開発リソースと照らし合わせながら読んでみてください。

自社が作り込む範囲の大小で並べると、各方式の位置づけは次のように整理できます。

API提供型（REST API）

API提供型は、本人確認の照合や審査、書類のOCR（文字認識）といった処理を、サーバー間のREST APIで呼び出す形態です。利用者に見える撮影画面や案内フロー、エラー時の再撮影の導線などは自社で設計・実装します。自由度が高く、自社サービスのUIやブランドに完全に合わせ込める一方で、その分だけ作り込む範囲は広くなります。

注意したいのは、APIだけで組む場合、撮影のガイド表示やライブネス、法令が求める確認プロセスの維持まで自社の責任範囲に入りやすい点です。実装の自由度と引き換えに、画面の作り込みと運用後の保守（法改正への追随を含む）を自社で抱えることになります。エンジニアリソースが厚く、UXを細部までコントロールしたいプロダクトに向く形態です。

SDK提供型（iOS／AndroidモバイルSDK）

SDK提供型は、iOSやAndroidのアプリに組み込む開発キットを利用する形態です。撮影のガイド表示、ライブネス、ICチップの読取、送信処理といった本人確認に必要な画面と機能をSDKがまとめて持つため、自社は自社アプリからSDKを呼び出し、結果を受け取る実装に集中できます。API提供型に比べて撮影まわりの作り込みを任せられる分、実装工数を抑えやすいのが特徴です。

撮影UIの細かなカスタマイズはSDKが提供する範囲に依存しますが、多くのSDKは自社アプリのデザインになじむ調整に対応しています。ネイティブアプリを持っていて、NFCによるICチップ読取まで含めて安定して動かしたい場合に有力な選択肢です。

Webブラウザ組み込み（タグ）型

Webブラウザ組み込み型は、自社サイトにJavaScriptのタグを設置し、ブラウザ上で本人確認を動かす形態です。ネイティブアプリを持たないWebサービスでも導入でき、タグの設置が中心のため短期間で組み込めるのが利点です。撮影や案内の画面はベンダー側が用意するものを使うため、実装は比較的軽くなります。

一方で、スマートフォンのブラウザからはNFCによるICチップ読取が使えないなど、ブラウザの制約を受ける方式があります。ICチップ読取や公的個人認証まで必要な場合は、タグ型で完結するか、アプリ側の実装が要るかを、対応方式とあわせて確認する必要があります。Webで手早く本人確認を導入したいケースに向いています。

SaaS画面完結型

SaaS画面完結型は、ベンダーが用意した本人確認用の画面へ利用者を遷移させ、そこで手続きを完結させる形態です。自社側はリンクやリダイレクトの設定が中心で、実装の負担が最も軽く済みます。開発リソースが限られていても短期間で導入でき、運用後の保守もベンダー側に寄せられます。

その反面、利用者が自社サービスから一度離れて外部画面へ移るため、画面のデザインや導線を自社で細かく制御することはできません。UXの一貫性より、まず確実・手早く本人確認を用意したい段階のサービスに適しています。

App Clip／NFCネイティブ型

App Clip／NFCネイティブ型は、iOSのApp Clip（アプリをフルインストールせずに一部機能を即座に起動できる仕組み）や、スマートフォンのNFCでマイナンバーカードのICチップを読み取る、ネイティブ寄りの実装です。ICチップ読取や公的個人認証（JPKI）を用いる本人確認では、この形態が関わってきます。

マイナンバーカードのICチップ読取や公的個人認証を使う場合、NFC読取は本体アプリ側の実装が前提になります。この形態の技術的な前提と実装イメージは、後述の「本人確認方式と実装方式の関係」で詳しく扱います。

eKYC実装の具体像 ── 導入ステップとSDK組み込みの流れ

実装方式の当たりが付いたら、次に気になるのが「実際にどう組み込み、稼働までにどれくらいかかるか」です。ここでは、SDK提供型を例に、組み込みの流れと導入ステップの標準的なイメージを示します。サービスや方式によって差はありますが、大きな流れは共通します。

SDKを使った本人確認の処理は、おおむね次の順に進みます。利用者の操作からサーバーでの照合、結果の受け取りまでが一連のコールバックでつながる形です。

1. 自社アプリからSDKを呼び出し、本人確認フローを起動する
2. SDKが撮影・ICチップ読取・ライブネスの画面を表示し、利用者が操作する
3. 取得したデータをベンダーのサーバーへ送信し、照合・審査を行う
4. 結果（承認・要確認・否認など）をコールバックで自社アプリが受け取り、後続の処理へつなぐ

導入の準備としては、サービスの申し込みからアカウント発行、審査、テスト環境での検証を経て本番稼働へ進むのが一般的です。この審査やアカウント発行には一定の期間がかかるため、実装工数だけでなく、事前の準備期間も見込んでスケジュールを組むことをおすすめします。実際に要する期間はサービスや自社の要件によって幅があるため、要件定義の段階で各社に確認しておくとよいでしょう。

本人確認方式（ホ・ヘ・ト・公的個人認証）と実装方式の関係

eKYCの実装方式を選ぶうえで避けて通れないのが、犯罪収益移転防止法（以下、犯収法）が定める本人確認の「方式」との関係です。どの方式を採用するかで、必要になる実装（撮影だけで足りるのか、NFCによるICチップ読取まで要るのか）が決まります。ここでは非対面の主な方式を、実装への影響とあわせて整理します。

各方式そのものの種類や、方式ごとのセキュリティ・なりすましのリスクを基礎から整理したい場合は、以下の記事で詳しく解説しています。実装方式との違いを押さえたうえで読み進めると理解が進みます。

犯収法施行規則は、非対面の本人確認方法を第6条第1項第1号でいくつかの方式に分けています。代表的なのが、容貌と写真付き本人確認書類の画像を送信する方式（いわゆる「ホ方式」）です。原文は次のとおりです。

当該顧客等又はその代表者等から、特定事業者が提供するソフトウェアを使用して、本人確認用画像情報（当該顧客等又はその代表者等に当該ソフトウェアを使用して撮影をさせた当該顧客等の容貌及び写真付き本人確認書類の画像情報であって、当該写真付き本人確認書類に係る画像情報が、当該写真付き本人確認書類に記載されている氏名、住居及び生年月日、当該写真付き本人確認書類に貼り付けられた写真並びに当該写真付き本人確認書類の厚みその他の特徴を確認することができるものをいう。）の送信を受ける方法

出典：犯罪による収益の移転防止に関する法律施行規則 第6条第1項第1号ホ｜e-Gov 法令データ

このホ方式は、撮影した画像を送るだけで完結するため、撮影画面さえ用意できればWebブラウザ組み込み型でも実装しやすい方式です。一方で、より確実性の高い方式として、容貌の画像に加えて写真付き本人確認書類のICチップ情報を送信する方式（ヘ方式）や、書類画像の送信とICチップ読取のいずれかを用いる方式（ト方式）があります。

これらICチップを読み取る方式は、書類やマイナンバーカードの半導体集積回路（ICチップ）をNFCで読む必要があるため、実装としてはNFCを扱えるネイティブアプリ側の作り込みが前提になります。

もう一つ重要なのが、マイナンバーカードの電子証明書を使う公的個人認証（JPKI）です。これは犯収法施行規則の同じ第6条第1項第1号のうち、地方公共団体情報システム機構（J-LIS）が発行する署名用電子証明書を用いる「カ号」にあたります。

業界では慣用的に「ワ方式」と呼ばれることもありますが、現行の施行規則上、公的個人認証を根拠づける号は「カ号」で、「ワ号」は電子署名法の認定を受けた民間の認証事業者による電子証明書を指す別の方式です。号の呼称に触れる際は、この違いに注意が必要です。

当該顧客等から、電子署名等に係る地方公共団体情報システム機構の認証業務に関する法律（平成十四年法律第百五十三号。以下この号において「公的個人認証法」という。）第三条第六項又は第十六条の二第六項の規定に基づき地方公共団体情報システム機構が発行した署名用電子証明書及び当該署名用電子証明書により確認される公的個人認証法第二条第一項に規定する電子署名が行われた特定取引等に関する情報の送信を受ける方法（特定事業者が公的個人認証法第十七条第四項に規定する署名検証者である場合に限る。）

出典：犯罪による収益の移転防止に関する法律施行規則 第6条第1項第1号カ｜e-Gov 法令データ

公的個人認証で使う署名用電子証明書は、J-LISが発行します。マイナンバーカードのICチップに記録された電子証明書をスマートフォンのNFCで読み取るため、この方式もICチップ読取と同様に、NFCを扱えるネイティブアプリ側の実装が前提になります。このように、撮影だけで足りるホ方式を除き、ICチップ読取・公的個人認証を使う方式では、NFCネイティブ型の実装が関わってきます。

• 参考資料：電子証明書のご用意｜公的個人認証サービス ポータルサイト（J-LIS）

実装方式の選定と並行して、公的個人認証（JPKI）そのものの仕組みや、署名用電子証明書・利用者証明用電子証明書の違い、認証局が担う役割を基礎から押さえておきたい場合は、以下の記事にまとめています。

App Clip／NFC（ICチップ読取）を使った本人確認の実装イメージ

ICチップ読取や公的個人認証をアプリに組み込む場合、鍵になるのがNFCの扱いです。マイナンバーカードのICチップはISO 7816系の非接触ICで、iOSではCore NFCという仕組みでこうしたタグを読み取れます。ただしこの機能はアプリ本体でしか使えず、拡張機能（App Extension）側からは呼び出せません。

そのため、NFC読取を実装するには本体アプリでの作り込みが必要になり、SDKがこの部分を提供しているかどうかが工数を大きく左右します。

• 参考資料：App Clips｜Apple Developer Documentation
• 参考資料：Core NFC｜Apple Developer Documentation

ネイティブアプリを持っていない、あるいは開発リソースが限られている場合の選択肢として、iOSのApp Clipがあります。App Clipはアプリをフルインストールせずに一部機能を即座に起動できる軽量な仕組みで、本人確認だけを切り出して提供する使い方が考えられます。

ただしApp Clipは機能やサイズに制約があり、一定期間使われないとシステムが自動的に削除する特性もあるため、本人確認のどこまでをApp Clipで賄えるかは、対応するサービスの実装仕様とあわせて確認する必要があります。

また、マイナンバーカードの機能をスマートフォンに搭載して本人確認を行う「ル方式」は、物理カードのICチップをNFCで読み取る方式とは別の実装経路として整理されています。仕組みや対応時期、対応するeKYCサービスは以下の記事で扱っており、NFC読取型の実装と並行して検討材料に加えられます。

2027年の犯収法改正が実装方式選定に与える影響

今から実装方式を選ぶうえで見落とせないのが、2027年に施行される犯収法施行規則の改正です。改正命令（令和7年内閣府・総務省・法務省・財務省・厚生労働省・農林水産省・経済産業省・国土交通省令第3号、公布は2025年6月24日）の附則で、施行日が定められています。

附則　この命令は、令和九年四月一日から施行する。

出典：犯罪による収益の移転防止に関する法律施行規則の一部を改正する命令（令和7年内閣府等令第3号）｜警察庁 犯罪収益移転防止対策室（JAFIC）

この改正で削除されるのが、先に見た「容貌及び写真付き本人確認書類の画像情報の送信を受ける方法」、すなわち画像送信型のホ方式です。改正命令の本文では、この号を削る旨が現行のホ号の条文とあわせて示されています。一方で、ICチップ読取を含む方式（ヘ・ト）や公的個人認証（カ）などは存置されます。

条文の構造としては、画像送信だけで完結する方式がなくなり、ICチップ読取・公的個人認証を用いる方式が残る形へと変わります。

実装の観点で言えば、撮影画像を送るだけのホ方式に依存した設計は、2027年4月以降は使えなくなります。今後を見据えるなら、NFCによるICチップ読取や公的個人認証に対応できる実装（SDK提供型やApp Clip／NFCネイティブ型）を選択肢に含めておくことが、将来の作り直しを避ける現実的な備えになります。

新規に実装方式を選ぶ段階であれば、この条文構造の変化を前提に、ICチップ読取まで見据えたサービス・方式を検討しておくと、将来の負担を抑えられます。

• 参考資料：犯罪収益移転防止法 同施行令 同施行規則など（新規制定・改正法令・告示）｜警察庁 犯罪収益移転防止対策室（JAFIC）

ここで触れた2027年4月施行の改正については、廃止される画像送信型（ホ方式）と、ICチップ読取や公的個人認証（JPKI）を用いる方式への移行の要点を、先行する2025年施行分もあわせて詳しく整理した記事があります。改正の全体像から自社の対応を確認したい場合は、こちらもご覧ください。

実装方式と料金の考え方

実装方式は料金にも影響します。eKYCの料金は、初期費用・月額費用・本人確認1件あたりの従量課金を組み合わせた体系が一般的で、これに最低利用料が加わることもあります。API・SDKの提供が基本料金に含まれるのか、別途費用がかかるのかはサービスによって異なるため、実装形態とあわせて確認するのが確実です。

また、実装方式の違いは初期の開発コストにも表れます。API提供型は自社で画面を作り込む分だけ開発工数がかかり、SaaS画面完結型やタグ型は導入の手間を抑えやすい傾向があります。多くのサービスは料金を公開しておらず「要お問い合わせ」としているため、正確な費用は要件を伝えたうえで見積もりを取り、導入・運用の総コストで比較することをおすすめします。

自社に合う実装方式の選び方（プロダクト形態×開発リソース）

ここまでの内容を踏まえ、自社に合う実装方式の絞り込み方を整理します。判断の軸になるのは、「自社プロダクトがネイティブアプリか、Webサービスか、両対応か」と、「本人確認の開発に割ける社内リソースがどれだけあるか」の2つです。この2軸で、現実的な選択肢が見えてきます。

• ネイティブアプリ中心＋開発リソースあり：SDK提供型が基本。ICチップ読取・公的個人認証まで見据えるなら、NFC対応のSDKが有力です。
• Webサービス中心＋短期導入を優先：タグ型やSaaS画面完結型。ただしICチップ読取が必要なら、ブラウザの制約を確認します。
• UXを細部までコントロールしたい：API提供型で画面を自社実装。工数と保守を自社で担える体制が前提です。
• 開発リソースが限られる：SaaS画面完結型で実装負担を最小化。将来のICチップ読取対応は乗り換え余地とあわせて検討します。

いずれの場合も、2027年の改正でICチップ読取・公的個人認証が実装の前提として重みを増す点は共通の判断材料になります。目先の導入スピードだけでなく、ICチップ読取まで無理なく対応できるかを、選定の段階で見ておくとよいでしょう。次のセクションでは、各実装方式に対応する具体的なサービスを紹介します。

実装方式に対応した主要eKYCサービス

ここからは、実装方式の観点で特徴のある主要なeKYCサービスを紹介します。API・SDKを提供して自社プロダクトへの組み込みに対応するサービスを中心に、提供形態の違いがわかるように取り上げました。自社の実装方針に合う候補として、資料請求や問い合わせの起点にしてください。

実装方式の当たりが付いたら、次は導入費用・本人確認方式・不正対策まで含めて各サービスを横並びで比較したい段階です。eKYCサービス全体を比較し、失敗しない選び方まで解説した以下の記事もあわせてご覧ください。

ネクスウェイの本人確認（eKYC）ソリューション（株式会社ネクスウェイ）

ネクスウェイの本人確認（eKYC）ソリューションは、API連携により自社の業務システムやアプリに本人確認を組み込めるサービスです。加えて、eKYCのシステム提供だけでなく、目視確認や郵送対応などの周辺業務までを一気通貫で任せられるのが特徴で、自社に審査体制を持たない企業でも導入しやすい体制が整っています。

本人確認の実装と運用の両面を支えられる点が、他のシステム提供中心のサービスとの違いです。実装工数だけでなく、稼働後の目視審査や例外対応まで含めて負担を軽くしたい企業にとって、有力な選択肢となります。

TRUSTDOCK（株式会社TRUSTDOCK）

TRUSTDOCKは、本人確認に特化した専業ベンダーとして、API・SDKでの提供と、目視確認を含む運用代行（BPO）を組み合わせられるサービスです。行政から金融まで幅広い業種のユースケースに対応し、犯収法だけでなく古物営業法や割賦販売法など複数の法令に沿った本人確認を実装できます。開発者向けのドキュメントが整っており、自社プロダクトへの組み込みを前提に検討しやすいのが強みです。

API・SDKによる柔軟な組み込みと、審査を含む運用の委託を両立できるため、実装だけでなく本人確認業務そのものの外部化まで視野に入れる企業に適しています。

xID（xID株式会社）

マイナンバーカードの公的個人認証（JPKI）に軸足を置くデジタルIDサービスが、xIDです。事業者はxIDのAPI・SDKを通じて、公的個人認証を用いた本人確認を自社プロダクトに組み込めます。マイナンバーカードのICチップを使う方式に軸足を置いているため、2027年以降にICチップ読取・公的個人認証の比重が高まる流れを見据えた実装と相性がよいのが特徴です。

公的個人認証を用いた本人確認を自社プロダクトに実装したい企業や、マイナンバーカードのICチップを使う方式を軸に据えたい企業に向いた構成です。

ProTech ID Checker（株式会社ショーケース）

Webサイトへの埋め込み型で本人確認を導入できるのが、ProTech ID Checkerです。自社サイトに組み込む形で本人確認を設置でき、最短での導入を掲げている点が特徴です。マイナンバーカードのICチップを使う公的個人認証にも対応しており、ネイティブアプリを前提とせず、Webサービス側で本人確認を手早く用意したい場合に導入しやすい形態を提供しています。

アプリ開発を伴わずにWebで本人確認を始めたい、導入までの期間を短くしたいという要件に向いています。対応する本人確認方式と、自社サイトの構成との相性を確認したうえで検討するとよいでしょう。

LIQUID eKYC（株式会社Liquid）

AIによる顔認証を軸に据えるeKYCサービスが、LIQUID eKYCです。JavaScriptによる埋め込みで導入でき、モバイルでの本人確認にも対応するため、Webとアプリのどちらのプロダクトにもなじみやすい構成です。

WebでもアプリでもeKYCを組み込みたい、まずは埋め込み型で手早く始めたいという場合に有力な選択肢です。自社の実装方式と、必要な本人確認方式への対応状況を確認しながら検討してください。

まとめ

eKYCを自社プロダクトに組み込む実装方式は、API提供型・SDK提供型・Webブラウザ組み込み（タグ）型・SaaS画面完結型・App Clip／NFCネイティブ型の5系統に整理できます。どれを選ぶかは、自社プロダクトがアプリかWebか、開発リソースがどれだけあるか、そしてICチップ読取・公的個人認証まで必要かで決まります。

2027年4月の犯収法改正で画像送信型のホ方式が使えなくなることを踏まえ、ICチップ読取に対応できる実装を選択肢に含めておくことが、将来の作り直しを避ける備えになります。実装方式の当たりが付いたら、対応するサービスの資料を取り寄せ、要件定義と見積もりに進んでください。

よくある質問（FAQ）

Q. eKYCの実装方式にはどのような種類がありますか？

A. eKYCの実装方式は、API提供型・SDK提供型・Webブラウザ組み込み（タグ）型・SaaS画面完結型・App Clip／NFCネイティブ型の5系統に大きく分かれます。どの系統を選ぶかで、自社が書くコードの量、利用者に見える画面をどこまで作り込めるか、対応できる本人確認の方式が変わります。

自社プロダクトがネイティブアプリかWebサービスか、そして本人確認の開発にどれだけリソースを割けるかが、方式選びの起点になります。

Q. eKYCのAPI提供とSDK提供はどう違うのですか？

A. API提供型は本人確認の照合・審査などの処理をサーバー間のREST APIで呼び出す形態で撮影画面やフローは自社で作り込み、SDK提供型は撮影・ICチップ読取・ライブネスなどの画面と処理を持つ開発キットをアプリに組み込む形態です。API提供型は自由度が高くUIを自社ブランドに合わせ込める反面、画面の作り込みと運用後の保守を自社で抱えます。

SDK提供型は撮影まわりをベンダーに任せられるため、ネイティブアプリへの組み込み工数を抑えやすいのが特徴です。

Q. eKYCはWebサイトにタグを設置すれば、ブラウザだけで本人確認まで完結できますか？

A. Webブラウザ組み込み（タグ）型ならJavaScriptタグの設置でブラウザ上の本人確認を導入できますが、NFCによるICチップ読取が必要な方式まではブラウザだけで完結しないことがあります。

スマートフォンのブラウザからはNFCでのICチップ読取が使えないなどの制約があるため、撮影した画像を送る方式（ホ方式）は手早く組める一方、ICチップ読取や公的個人認証まで必要な場合は、タグ型で完結するかアプリ側の実装が要るかを、対応方式とあわせて確認する必要があります。

Q. eKYCのApp ClipやNFC（ICチップ読取）は、自社アプリがなくても使えますか？

A. iOSのApp Clipを使えばアプリをフルインストールせずに本人確認だけを切り出して起動でき、ネイティブアプリを持たない場合の選択肢になりますが、NFCによるICチップ読取自体は本体アプリ側の実装が前提です。

iOSのCore NFCはアプリの拡張機能では使えず本体アプリでしか呼び出せないため、ICチップ読取まで対応するにはSDKがこの部分を担うか、自前で実装するかが工数を左右します。App Clipは機能・サイズに制約があり、一定期間使われないと自動削除される特性もあるため、どこまでApp Clipで賄えるかは対応サービスの仕様とあわせて確認してください。

Q. 2027年の犯収法改正で、eKYCの実装方式はどう変わりますか？

A. 2027年（令和9年）4月1日に施行される改正で、容貌と本人確認書類の画像を送信するだけで完結する画像送信型（ホ方式）が廃止され、ICチップ読取を用いる方式（ヘ・ト）や公的個人認証（カ号＝JPKI）を用いる方式が残る形になります。そのため、撮影画像を送るだけの設計は2027年4月以降は使えなくなります。

これから実装方式を選ぶなら、NFCによるICチップ読取や公的個人認証に対応できるSDK提供型・App Clip／NFCネイティブ型を選択肢に含めておくと、改正後も無理なく対応できます。

• 参考資料：犯罪による収益の移転防止に関する法律施行規則 第6条第1項第1号｜e-Gov 法令データ
• 参考資料：犯罪による収益の移転防止に関する法律施行規則の一部を改正する命令（令和7年内閣府等令第3号）｜警察庁 犯罪収益移転防止対策室（JAFIC）

Q. eKYCサービスは申し込みからどのくらいで使えるようになりますか？

A. eKYCの導入は、申し込み・アカウント発行・審査・テスト環境での検証を経て本番稼働に至るのが一般的で、実装工数に加えてこの準備期間も見込んでスケジュールを組む必要があります。審査やアカウント発行には一定の期間がかかり、実際に要する期間はサービスや自社の要件によって幅があります。要件定義の段階で各社に確認し、スケジュールに余裕を持たせておくと安全です。

Q. 開発リソースが限られている場合、eKYCはどの実装方式を選べばよいですか？

A. 開発リソースが限られる場合は、実装負担が最も軽いSaaS画面完結型が基本の選択肢で、Webサービス中心なら短期間で組み込めるタグ型も有力です。ただし2027年の改正でICチップ読取・公的個人認証の比重が高まるため、将来ICチップ読取への対応が必要になったときの乗り換え余地もあわせて見ておくと安心です。

ネイティブアプリを持ち一定の開発リソースを割けるなら、ICチップ読取まで安定して担えるSDK提供型が有力になります。

eKYCサービスの料金・資料を一括チェック

MCB FinTechカタログでは、eKYC・本人確認サービスの最新資料をまとめて請求できます。API・SDKの提供形態や対応する本人確認方式、料金は各社で異なるため、気になるサービスの資料を取り寄せて、自社の実装方針に合う候補を比較検討してください。

MCB FinTechカタログに掲載しませんか？

MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。