3Dセキュア2.0（EMV 3-Dセキュア）とは？仕組み・認証フローとEC決済への実装を開発視点で解説

3Dセキュア2.0（EMV 3-Dセキュア）とは、ECサイトなどカードを提示しない決済で、そのカードを使っているのが本人かどうかを確認する本人認証のプロトコルです。2025年3月末を期限に、原則すべてのEC加盟店へ導入が求められたことで、決済システムを実装する側にとっては「入れるかどうか」ではなく「どう組み込むか」を考える前提になりました。この記事では「3Dセキュア2.0とは何か」という定義から一歩踏み込み、1.0との違い、3DS Server・DS・ACSという登場人物と認証メッセージの流れ、フリクションレスとチャレンジの分岐、オーソリとの位置関係、そして自前構築せずPSP経由で実装する際の責務の境界と内製・受託の判断軸までを、開発者が設計に落とせる粒度で整理します。

まとめ｜3Dセキュア2.0の仕組みと実装判断の要点

3Dセキュア2.0は、決済の途中でカード発行会社（イシュア）が名義人本人かを確かめる認証の層です。1.0が全件に固定パスワード入力を課してかご落ちを招いていたのに対し、2.0は取引情報やデバイス情報からリスクを判定し、低リスクなら追加入力なしで通し（フリクションレス）、疑わしい取引だけワンタイムパスワードや生体認証を求める（チャレンジ）二段構えに変わりました。加盟店側の3DS Server、国際ブランドのDS、発行会社のACSが認証メッセージ（AReq/CReq/RReq）をやり取りし、認証が成った取引は不正チャージバックの責任がイシュア側へ移る（ライアビリティシフト）のが利点です。

実装で押さえるべきは、3Dセキュアはオーソリ（与信照会）の前段に位置する別レイヤであること、そして自前でACS連携まで組むのではなく、StripeなどのPSP・決済代行に認証処理を委ね、自社は「認証が要求されたときにユーザーをチャレンジ画面へ誘導し、非同期の結果を冪等に受け取る」部分を担うのが定石だという二点です。判断の分岐点は決済フローの独自要件の重さで、標準のチェックアウトで足りるなら内製、二段階決済や定期課金と絡んで認証の再実行や失敗ハンドリングが複雑になるなら、決済設計の経験がある体制で固める価値が出ます。

3Dセキュア2.0（EMV 3-Dセキュア）とは｜定義と1.0からの変更点

3Dセキュア2.0は、ECのようにカードを物理的に提示しない取引（CNP＝Card Not Present）で、決済者がカードの正当な名義人かを確認するための国際的な本人認証プロトコルです。正式名称をEMV 3-Dセキュアといい、EMVCoという国際団体が仕様を策定しています。「3-D」はドメイン（後述する三つの領域）に由来する呼称で、3Dグラフィックスとは無関係です。

3Dセキュア2.0の定義とEMV 3-Dセキュアという正式名称

3Dセキュアは、加盟店・国際ブランド・発行会社の三者が連携し、カード情報の入力だけでは判別できない「使っているのが本人か」を発行会社側で判定する仕組みです。決済代行やゲートウェイが提供する「本人認証サービス」の実体がこのプロトコルで、Visa・Mastercard・JCB・American Express など主要ブランドがそれぞれのブランド名（Visa Secure など）で実装しています。EC決済に固有の仕組みで、店頭のIC決済のようにカードとPINで本人性を担保できない領域を補う位置づけです。

3Dセキュア1.0の固定パスワード方式からリスクベース認証への移行

旧来の3Dセキュア1.0は、決済のたびに利用者があらかじめ登録した固定パスワードの入力を求める方式でした。全件に一律の入力を課すため、パスワードを忘れた利用者がそこで購入をやめる「かご落ち」を招きやすく、スマートフォンでの体験も悪いという課題を抱えていました。2.0はこの構造を見直し、取引金額・購入履歴・デバイス・配送先といった多数の情報を発行会社がリアルタイムに分析するリスクベース認証（RBA）を導入しています。国際的には1.0のサポートが終了・移行済みで、現在の実装対象は2.0（EMV 3-Dセキュア）です。バージョンは2.1.0・2.2.0を経て2.3.1系まで改訂が進み、2.3系ではFIDO認証やパスキー（SPC＝Secure Payment Confirmation）との連携を見据えた仕様が加わっています（2026年7月時点）。

3Dセキュア2.0の登場人物と認証フロー｜3DS Server・DS・ACSの役割

3Dセキュアがどの主体を通って可否を返すのかを押さえると、認証でつまずいたときにどの層の問題かを切り分けられます。プロトコル名の「3-D」が示すとおり、認証はアクワイアラ・イシュア・相互接続の三つのドメインにまたがって進みます。

三つのドメインと3DS Server・DS・ACSという構成要素

登場する主要コンポーネントは三つです。3DS Server（旧称MPI）は加盟店側に立ち、認証の要求を組み立ててやり取りを仲介する要素で、実務では決済代行やPSPが提供します。DS（Directory Server）は国際ブランドが運用する経路制御役で、対象カードの発行会社を特定して認証要求を正しいACSへ振り分けます。ACS（Access Control Server）は発行会社（イシュア）側にあり、リスク判定と本人認証そのものを担う中枢です。加盟店から見た認証は「3DS Server に投げると、DS を経由して発行会社の ACS が判定を返す」という流れになり、それぞれがアクワイアラ・相互接続・イシュアの各ドメインに対応します。

AReq・CReq・RReqという認証メッセージのやり取りの全体像

認証は決まった電文の往復で進みます。決済時にまず3DS Serverが認証要求（AReq＝Authentication Request）を送り、DS経由でACSが受け取って、リスク判定の結果を応答（ARes）として返します。ここで追加認証が不要（低リスク）と判定されればそのまま認証完了です。追加認証が必要なら、利用者へチャレンジ要求（CReq）を出してワンタイムパスワード等の入力を受け、その結果（CRes）を返します。最終的な認証結果は結果通知（RReq/RRes）としてやり取りされ、成立した認証からは発行会社の認証値（CAVVやAAVと呼ばれる値）が得られます。この認証値を後続の与信電文に載せることで、その取引が本人認証を通ったことを証明する設計です。

ブラウザとアプリでの実装差（3DS Methodと3DS SDK）

2.0では、認証の精度を上げるためにデバイス情報を収集する仕組みが加わっており、実装の入口がブラウザ決済とアプリ決済で分かれます。ブラウザでは3DS Methodと呼ばれる非表示のiframeを使って画面遷移前にブラウザ・デバイス情報を集め、その情報をリスク判定へ渡す設計です。ネイティブアプリでは3DS SDKを組み込み、SDKがデバイス情報の収集とチャレンジ画面の表示を担います。この情報量の増加が、1.0にはなかったフリクションレス判定を成り立たせる土台で、実装側はどちらの経路でも「情報収集 → 判定 → 必要時のみチャレンジ表示」という同じ骨格を扱うことになります。

決済フローにおける3Dセキュアとオーソリ（与信照会）の位置関係と実行順序

3Dセキュアを決済のどこに差し込むかを誤ると、二重処理や認証漏れの原因になります。本人認証（3Dセキュア）と与信照会（オーソリ）は目的が違う別のレイヤで、実行順序と受け渡す値を分けて設計します。

本人認証（3DS）と与信照会（オーソリ）を分けて扱う設計上の原則

3Dセキュアは「使っているのが本人か」を確かめる認証で、オーソリは「このカードで、この金額を決済して大丈夫か」を発行会社に照会する与信の処理です。一般的な順序は、まず本人認証を通し、その認証結果を持って与信照会（オーソリ）へ進む流れになります。認証で得た認証値（CAVV等）を与信電文に含めて送ることで、発行会社側は本人認証済みの取引として扱える設計です。実装ではこの二つの成否を切り分け、認証で落ちたのか与信で落ちたのかを区別してハンドリングすると、利用者への案内を的確に出せます。与信そのものの仕組みや二段階決済との関係はオーソリ（決済オーソリゼーション）とは？仕組み・売上確定との違いと実装パターンを開発視点で解説で具体的に確認でき、本稿の認証はその前段に位置づけられます。

ライアビリティシフト｜不正チャージバック責任の移転という利点

3Dセキュアを導入する実務上の見返りが、ライアビリティシフト（責任転嫁）です。本人認証を通した取引で不正利用が起きた場合、そのチャージバック（利用者からの支払い拒否）の責任は原則として発行会社（イシュア）側へ移ります。認証を通していない取引では加盟店がチャージバックの損失を被りがちであるのに対し、認証済み取引では加盟店の負担が軽くなる仕組みです。この責任分界があるため、単なる不正対策にとどまらず、加盟店が損失リスクを下げる手段としても機能します。ここが、EMV 3-Dセキュアの導入が制度として求められる背景にもつながっています。

2025年3月末の導入義務化と決済システムに実装が求められる範囲

日本では、経済産業省とクレジット取引セキュリティ対策協議会がまとめる「クレジットカード・セキュリティガイドライン」において、原則すべてのEC加盟店に2025年3月末までのEMV 3-Dセキュア導入を求める方針が示されました。同ガイドラインは割賦販売法に基づく実務上の指針として位置づけられ、2025年3月4日には6.0版が公表されています。すでに期限を過ぎた現在、クレジットカード決済を扱うECサイトでは3Dセキュア2.0の実装は前提要件となっており、新規に決済を組む場合も既存フローを改修する場合も、本人認証を織り込んだ設計が出発点になります。

3Dセキュア2.0の実装パターン｜PSP経由で組み込む設計と責務の境界

ここは実装の勘所です。3Dセキュアは自社でACS連携まで作り込むものではなく、決済代行・PSPが提供する認証機能を通じて組み込むのが基本で、自社が担う範囲を正しく見極めるのが設計の第一歩になります。

PSP・決済代行に認証を委ねる実装と自社が担う責務の切り分け

3DS ServerやDSとの接続、ACSとの認証メッセージのやり取りは、StripeやGMOペイメントゲートウェイといったPSP・決済代行が提供します。自社アプリケーションが担うのは、その手前と後始末の部分です。具体的には、決済実行時に認証が必要と判定されたら利用者をチャレンジ画面へ遷移（またはSDKで表示）させ、チャレンジ完了後に決済処理を再開し、最終結果をWebhookなどで受け取って注文ステータスへ反映する流れを組みます。ACSの内部やブランドごとの差異はPSPが吸収するため、自社は「認証が要求される状態」と「認証後の状態」を扱う状態管理に集中できる構成です。この責務の切り分けを曖昧にすると、認証中の注文を確定済みと誤認するなどの不整合を招きます。

Stripeでの実装イメージ｜Payment Intentsと認証要求の扱い

実装イメージは、決済プラットフォームのAPIで具体化します。StripeのPayment Intents APIは、取引に本人認証（SCA／3Dセキュア）が必要かを自動的に判定し、必要な場合はPaymentIntentのステータスをrequires_actionにして、next_actionにチャレンジへ誘導するための情報を返します。フロントエンドではStripe.jsのhandleNextAction（または確認系メソッド）がこのnext_actionを解釈してチャレンジ画面を提示し、利用者が認証を終えると決済が続行される挙動です。認証をどの程度要求するかは、決済意図の作成時にパラメータ（request_three_d_secureをautomaticかanyにする等）で制御できます。決済処理全体の実装パターンや手数料の考え方はStripeとは？決済プラットフォームの仕組み・手数料・実装パターンを開発視点で解説で確認でき、本稿の本人認証はその決済フローに差し込まれる一段として位置づけられます。

チャレンジ完了後の非同期ハンドリングで崩れやすい三つの実装論点

3Dセキュアの事故は、正常系ではなく認証をまたぐ状態遷移で起きます。第一に、チャレンジは画面遷移やアプリ内表示を挟むため、認証中に利用者が離脱したり戻ったりする経路を想定し、認証未完了の注文を「保留」として明確に保持する設計です。第二に、最終的な決済成否は同期レスポンスだけに頼らず、PSPからのWebhookで受け取り、同一イベントの再送でも二重に確定しないよう冪等（べきとう）に処理します。第三に、対象カードや発行会社が2.0に対応していない、あるいはタイムアウトした場合のフォールバック（認証なしで進めるか、決済を止めるか）を方針として決めておくことが前提です。これらを設計に織り込まないと、認証は成立したのに注文が未反映、あるいは離脱を成功と誤認して在庫を引き当てる、といった食い違いが生じます。

3Dセキュア2.0の導入で内製と受託開発を分ける判断軸と外注が向く局面

ここからは判断を言い切ります。3Dセキュアの組み込みは、標準的なチェックアウトを使うなら内製で回りますが、独自の決済フローと絡むと認証まわりの例外処理が事故率を左右するため、体制の選び方が結果を分けます。

内製で完結できる3Dセキュア2.0導入の要件と設計上の前提条件

次の条件に収まるなら、内製での実装が現実的です。PSPが提供するホスト型のチェックアウトや標準の決済フォームをそのまま使え、決済が一段階（本人認証と与信・売上確定が一続き）で足り、注文と決済のタイミングにタイムラグがない、というケースです。この範囲であればPSPが3Dセキュアの分岐（フリクションレス／チャレンジ）を画面込みで巻き取ってくれるため、自社は決済結果のWebhook受信と注文反映を実装すれば組み切れます。まずこの標準構成で公開し、要件が複雑になってから作り込むのが工数を抑える進め方です。

受託開発で設計を固めるべき複雑な決済・認証要件と外注が向く局面

逆に、次の要件が絡むと、初期の設計品質がその後の事故率を大きく決めるため、決済設計の経験がある体制で固める価値が出ます。本人認証とオーソリ・売上確定を分ける二段階決済、認証を挟む定期課金・サブスクリプションの更新やカード変更、独自UIのカスタムチェックアウトでチャレンジ遷移を自前制御する構成、複数ブランド・複数PSPをまたぐ決済基盤、そして基幹システムとの受注・売上連携などです。これらは認証の状態管理・冪等設計・フォールバック方針が密に絡み、後から作り替えるとデータ不整合のリスクが高い領域になります。こうした本人認証を含む決済・サブスクリプションの実装は決済・サブスクリプションシステムの受託開発で設計から相談でき、決済方式そのものの選定を迷う段階では決済システムとは？仕組み・種類と接続方式・自社構築の判断軸で全体像から整理できます。内製で走り出しつつ、認証を挟む難所だけ外部の設計を挟む進め方も有効です。

3Dセキュア2.0でよくある質問｜仕組み・導入・実装の疑問に回答

3Dセキュア2.0の実装検討でよく挙がる質問に、仕組み・導入・実装の観点から簡潔に答えます。

3Dセキュア1.0と2.0は何が違いますか？

1.0は決済のたびに固定パスワードの入力を全件に課す方式で、かご落ちを招きやすい構造でした。2.0（EMV 3-Dセキュア）は取引情報やデバイス情報からリスクを判定し、低リスクなら追加入力なしで通し、疑わしい取引だけ追加認証を求めます。国際的に1.0は移行が済んでおり、現在の実装対象は2.0です。

フリクションレスとチャレンジはどう決まりますか？

発行会社（イシュア）のACSが、取引金額・購入履歴・デバイス・配送先などをリアルタイムに分析し、リスクの高低で判定します。低リスクなら利用者の追加操作なしで認証が完結し（フリクションレス）、中〜高リスクならワンタイムパスワードや生体認証などの追加認証を求めます（チャレンジ）。加盟店側で分岐を制御するのではなく、発行会社が判定する設計です。

3Dセキュア2.0は自社で一から実装する必要がありますか？

通常は不要です。3DS ServerやACSとの連携はStripeやGMOペイメントゲートウェイなどのPSP・決済代行が提供します。自社が担うのは、認証が要求されたら利用者をチャレンジ画面へ誘導し、認証後に決済を続行して、結果をWebhookで受けて注文へ反映する部分です。ブランドごとの差異はPSPが吸収します。

3Dセキュアとオーソリはどちらが先に走りますか？

一般に本人認証（3Dセキュア）が先で、その認証結果（認証値）を持って与信照会（オーソリ）へ進みます。役割が異なる別レイヤで、認証は「本人か」を、オーソリは「与信が通るか」を確かめる処理です。実装では両者の成否を切り分け、認証で落ちたのか与信で落ちたのかを区別してハンドリングします。

ライアビリティシフトとは何ですか？

本人認証を通した取引で不正利用が起きた場合に、そのチャージバック（支払い拒否）の責任が原則として発行会社側へ移ることです。認証を通していない取引では加盟店が損失を被りがちなのに対し、認証済み取引では加盟店の負担が軽くなります。3Dセキュア導入の実務上の見返りとして働く仕組みです。

関連記事

• 決済システムとは？仕組み・種類と、決済代行との接続方式・自社構築の判断軸を解説：本人認証を含む決済システム全体の種類・接続方式・自社構築の判断軸を整理できます。
• オーソリ（決済オーソリゼーション）とは？仕組み・売上確定との違いと実装パターンを開発視点で解説：本人認証の後段に走る与信照会と、二段階決済の実装を開発視点で確認できます。
• Stripeとは？決済プラットフォームの仕組み・手数料・実装パターンを開発視点で解説：Payment Intentsを含む具体的な決済実装のパターンを開発視点で確認できます。
• トークナイゼーションとは？決済のカード情報を守る仕組みと暗号化との違い・実装方式を開発視点で解説：本人認証と並ぶカード情報保護の仕組みを実装視点で確認できます。
• 決済・サブスクリプションシステム開発：本人認証を含む要件の重い決済実装を設計から相談できます。