コラム
MFAを入れていても乗っ取られる？Microsoftが警告した「AIフィッシング」の新手口と、...
「多要素認証（MFA）を導入しているから安全」―そう考えている方は多いのではないでしょうか。しかし2026年4月、Microsoftが公開したレポートは、その安心感を根本から揺るがす内容でした。報告されたのは、AIを活用した大規模なフィッシング攻撃の実態です。この攻撃の厄介なところは、MFAのパスワードを「盗む」のではなく、認証の仕組みそのものを「すり抜ける」設計になっていること。しかも攻撃ツールが「サービス」として流通しており、高度な技術を持たない攻撃者でも実行できる状況が生まれています。Microsoftによると、この攻撃は2025年2月に確認された類似のキャンペーンからさらに進化しており、手動スクリプトに依存していた従来型と異なり、AIを活用したエンドツーエンドの自動化が実現されています。攻撃の成功率とスケールにおいて「重大なエスカレーション」と位置づけられました。この記事では、何が起きているのかをできるだけ平易に整理し、企業として何を見直すべきかを考えます。 1. いま何が起きているのか―「本人が正規の画面で認証してしまう」攻撃 MFAをすり抜ける仕組み 今回の攻撃で悪用されたのは、「デバイスコード認証」と呼ばれる正規のログイン方式です。これはスマートTVやプリンタなど、キーボードのないデバイスからログインするために用意された仕組みで、画面に表示されたコードを別のPCやスマホで入力して認証を完了します。 ポイントは、「コードを発行した側」と「コードを入力する側」が別のデバイスであることです。攻撃者はこの構造を悪用し、自分が発行したコードを、フィッシングメール経由で被害者に入力させます。 被害者はMicrosoftの正規のログイン画面でコードを入力し、いつも通りMFAの認証も完了します。URLも本物、画面も本物。しかしその裏で、認証の「成果」―つまりアカウントへのアクセス権―は攻撃者の手に渡っている。パスワードは一切盗まれていないのに、アカウントが乗っ取られるのです。 たとえるなら、「鍵を盗む」のではなく「本人に鍵を開けさせて、そのまま入る」ようなもの。鍵の複雑さ（MFAの強度）をいくら上げても、本人が正規の手順で開けてしまう以上、防ぎようがありません。 「怪しいURLに注意しましょう」という従来のセキュリティ教育が、この攻撃にはほぼ通用しないという点が、特に深刻です。 AIで「あなた専用」のフィッシングメールが届く 従来のフィッシングメールは、「パスワードの有効期限が切れます」のような汎用的な文面が中心でした。しかし今回の攻撃では、AIがターゲットの役職や業務内容に合わせたメールを自動生成しています。経理担当者には請求書、営業担当者には提案依頼、製造部門にはワークフロー通知―日常業務の延長として自然に受け取れる内容が届くため、警戒心が働きにくい設計です。 さらに技術面でも巧妙な工夫がありました。デバイスコードには15分の有効期限がありますが、従来の攻撃ではメール送信前にコードを発行していたため、受信者がメールを開くまでに期限切れになることが多かったのです。今回の攻撃では、被害者がリンクをクリックした瞬間にコードを発行する仕組みに進化しており、この時間制限を実質的に無効化しています。 生成されたコードは被害者のクリップボードに自動コピーされ、正規のMicrosoftログインページに遷移後、ペーストするだけで認証が完了します。攻撃の「使いやすさ」は、もはや正規のWebサービスと変わらない水準です。 加えて、フィッシングページ自体もよく作り込まれています。ドキュメントのプレビュー画面をぼかし表示にして「本人確認」ボタンを配置するパターンや、ブラウザの中に偽のブラウザ画面を表示してMicrosoftのログイン画面を再現するパターンが確認されています。電子署名や音声メール通知など複数のテーマが使い分けられており、「このパターンに注意」と一律に伝えること自体が難しい状況です。 攻撃が「サービス化」している現実 今回のキャンペーンでは「EvilToken」と呼ばれる攻撃ツールキットの関与が確認されています。これはPhaaS（フィッシング・アズ・ア・サービス）―フィッシング攻撃のインフラをサービスとして提供するビジネスモデルです。 攻撃の裏側では、Railway.comやCloudflare、AWSといった正規のクラウドサービス上に攻撃基盤が構築されていました。一般企業が業務で使うのと同じプラットフォーム上で攻撃が動いているため、「怪しい通信先をブロックする」というアプローチでは、正規の業務通信まで止めてしまうリスクがあります。 いまやサイバー攻撃もクラウド上で自動運用される時代。防御側が年に1回のセキュリティ監査で対抗しようとするのは、馬車で新幹線を追いかけるようなものかもしれません。 2. 「MFAを入れているから安全」はもう通用しない MFAは万能ではない――残り10%の脅威 誤解のないように補足すると、MFA自体は依然として有効な防御策です。米国の安全保障当局によれば、MFAはサイバー攻撃の約90%を防いでいるとされています。 問題は残りの10%です。MFAの普及が進んだことで、攻撃者の関心は「MFAで守られていないアカウント」から「MFAをすり抜ける方法の開発」へと移っています。Microsoftによれば、同社が過去1年間でブロックしたパスワード攻撃は毎秒7,000件、前年比75%増。MFAの壁に阻まれた攻撃者が、より高度な迂回策に投資するのは必然的な流れです。 現在確認されているMFAをすり抜ける主な手法は3つあります。正規サイトとの通信に割り込んで認証情報を横取りする「中間者攻撃」、承認リクエストを大量に送りつけてうっかり許可させる「MFA疲労攻撃」、そして今回レポートされた「デバイスコードフィッシング」です。 前の2つがMFAの「運用上の隙」を突くのに対し、デバイスコードフィッシングは認証の仕組みそのものの「設計上の特性」を利用しているため、より根本的な対策が求められます。しかも、これらの手法は単独ではなく組み合わせて使われるのが実態です。今回のキャンペーンでも、メール配信には乗っ取り済みの正規ドメインが使われ、リダイレクトにはクラウドサービスが活用されるなど、複数の攻撃手法が何層にも重ねられていました。 「MFAを入れているか」ではなく、「どんな仕組みのMFAを、どこに適用しているか」が問われる時代に入りました。 乗っ取り後、10分で何が起きるか 今回のレポートで特に深刻なのは、アカウント乗っ取り後の行動の速さです。 Microsoftの観察によると、攻撃者はアクセス権を取得してから最短10分以内に、乗っ取ったアカウントに新しいデバイスを登録して長期的なアクセス手段を確保し、社内の組織図や権限情報を自動スキャンしてCFOや経理担当者など「お金を動かせる人」を特定していました。 最終的には、ターゲットのメールに不正な転送ルールを仕込み、本人に気づかれないまま送金情報や請求書データを抜き取り続けます。しかも攻撃者は大量に乗っ取ったアカウントの全てを攻撃するのではなく、「高価値なターゲット」を選別して集中投資する、まさにビジネス化された攻撃オペレーションを展開しています。...
お知らせ一覧
「パスキーを導入すれば安全」は本当か？―実装の落とし穴と、認証設計のもう一つの視点
パスキー認証はプロトコルとして堅牢ですが、RP（サービス提供者）側の実装ミスにより深刻な脆弱性が生まれ得ます。本記事では9つの実装リスクを整理し、パスキーの「手前」に認証レイヤーを置くことで得られる構造的なリスク低減効果を解説します。パスキー（Passkey）の普及が加速しています。メルカリは2025年5月にパスキー登録者数1,000万人を突破し、FIDOアライアンスのJapan Working Groupには64の組織が参加、国内で50以上のパスキープロバイダーが稼働または計画中という状況です。金融庁も2025年の対話資料でフィッシング対策としてパスキー利用の促進を明記し、日本証券業協会はフィッシング耐性のある多要素認証の必須化を求めるガイドライン改正案を公表しました。「パスキーを導入すれば安全」―そう考える企業が増えるのは自然な流れです。しかし、「導入した」と「安全になった」は同義ではありません。2025年6月、GMO Flatt Securityの技術ブログがパスキー認証のRP（Relying Party）実装に起因する9つの脆弱性パターンを公開しました。本記事では、この指摘を起点に、パスキー時代の認証設計に必要な「もう一つの視点」を整理します。 1. パスキーは万能ではない―実装が生む9つの脆弱性 パスキー普及の加速と「導入＝安全」という誤解 パスキーの勢いは数字が示しています。FIDOアライアンスの2024年調査によれば、パスキーの世界的な認知度は2022年の39%から57%へと50%増加しました。認知している人の62%が実際にパスキーを利用しており、世界の上位100サイトの20%がすでにパスキーに対応しています。日本国内でも、証券口座の不正アクセス事件を受けて規制当局が動き、金融庁は「ID・パスワードのみの認証やSMS OTPではもはや不十分」と明言しました。パスキーへの移行は、もはや先進的な取り組みではなく「やらなければならないこと」になりつつあります。この流れ自体は歓迎すべきものです。ただし、ここで見落とされがちな事実があります。パスキーのプロトコル（WebAuthn）がどれだけ堅牢でも、それを「実装する側」にミスがあれば、従来と同じセキュリティリスクが残り続けるという点です。 GMO Flatt Securityが指摘した9つの実装脆弱性 2025年6月、セキュリティ企業GMO Flatt Securityの技術ブログが、W3CのWeb Authentication Level 3仕様を読み解き、RP側の実装で注意すべき9つのセキュリティ観点を公開しました。主な指摘は以下の通りです。署名の検証不備―認証器から返されたデジタル署名の検証が不十分な場合、攻撃者が偽装したアサーション（認証応答）が受け入れられ、不正ログインを許す可能性があります。チャレンジの検証不備―リプレイ攻撃（傍受したアサーションの再利用）を防ぐためのチャレンジ値が正しく検証されていない場合、過去のアサーションを悪用されるリスクが生じます。Credential IDの重複検証不備―登録時にCredential IDの一意性を確認しない場合、攻撃者が被害者の認証情報を自身のアカウントに紐づけ、被害者を攻撃者のアカウントにログインさせるという巧妙な攻撃が成立し得ます。ユーザーの検証不備―アサーションに含まれるuserHandleと、署名検証に使用する公開鍵の紐づけを正しく確認しない場合、なりすましが可能になります。このほか、チャレンジの安全性（エントロピー不足）、オリジンおよびRP ID検証不備、安全でないフォールバック処理、Non Discoverable Credentialのフロー混在、アカウント登録状態の漏洩と、合計9つの観点が整理されています。特に注目すべきは、実際にCVE番号が付与された脆弱性が存在する点です。CVE-2025-26788（CVSS 8.4・HIGH）は、オープンソースのFIDO認証サーバーであるStrongKey FIDO Serverにおいて、Non Discoverable CredentialとPasskeyの認証フローが混在する際の検証不備により、任意のユーザーアカウントを乗っ取れるものでした。...
お知らせ一覧
【海外事例】デリバリー詐欺の48%は「返金詐欺」 | 新規アカウント大量作成を止める「電話番号...
「届いていない」と言われたら、確かめる術はあるか ある飲食店オーナーが、デリバリーアプリ経由の注文に頭を抱えていました。 注文どおりに調理し、配達員に渡した。にもかかわらず、数時間後に「商品が届いていない」と返金申請が入る。月に何件かなら泣き寝入りも仕方ない、と諦めていたところ、同じ氏名で住所だけが少し違う注文が、別アカウントで何度も入っていることに気づいたといいます。これはフードデリバリー業界に限った話ではありません。後払い決済を使ったECや、無料トライアルを設けるサブスクリプション事業でも、同じ構造の不正が日常的に発生しています。 そして共通する手口は、ひとつに集約されます。 「新規アカウントを大量に作る」という、極めて単純な攻撃です。 本記事では、業界調査が示す不正の実態と、なぜ既存の本人確認手段が突破されてしまうのか、そして「電話番号」という意外な角度からの解決策を整理します。 1. 【海外事例】フードデリバリー詐欺の「48%は返金詐欺」だった オンライン不正検知ベンダーのSift社が公表した調査レポートによれば、フードデリバリープラットフォームで発生している消費者詐欺のうち、約48%が「返金詐欺」に分類されるとされています。（出典：Business Insider Japan掲載のSift社レポート言及記事、2025年2月26日 https://www.businessinsider.jp/article/2503-food-delivery-customers-fraud-asking-for-refunds-orders-they-got/ ）返金詐欺とは、商品が正常に配達されたにもかかわらず、「届いていない」「中身が違った」と虚偽の申請を行い、返金や代替品の発送を受け取る行為を指します。記録上は注文・配達ともに完了しているため、店舗側からは反証が難しく、結果として泣き寝入りに近い処理が積み上がっていきます。 レポートが指摘する手口の特徴は、二つあります。 ひとつは「複数のメールアドレスを使い分け、新規アカウントを次々と作成する」こと。もうひとつは「初回限定クーポンや配送無料特典を使い回し、実質的に半額以下で食事を入手する」ことです。返金詐欺と無料クーポン乱用は、同じ人物が同じ手口で連続的に行うケースが多く、業界全体で問題視されています。 2. 後払い決済でも進む「なりすまし注文」 同じ構造の問題は、ECサイトの後払い決済領域でも観測されています。 NP掛け払いやNP後払いを提供するネットプロテクションズ社の運用案内には、第三者が架空の氏名・住所・電話番号を入力し、本人になりすまして商品を購入する事例について、注意喚起と対応プロセスが整理されています（出典：株式会社アスターリンク「NP掛け払い・NP後払いによるいたずら（なりすまし）」https://www.aster-link.co.jp/posts/np-kakebarai/ 後払い決済の構造的な弱点は、購入時点で支払いが発生しないため、本人確認の精度が「氏名・住所・電話番号」程度にとどまる点にあります。クレジットカードのように与信審査やカード情報の照合プロセスが入らないため、「他人の住所や架空の住所を登録し、転送サービスや営業所止めで荷物を受け取る」といった手法が成立してしまいます。 参考までに、日本クレジット協会が2026年3月に公表したデータでは、2025年通年のクレジットカード不正利用被害額は510.5億円で、このうち番号盗用による被害が475.4億円を占めました。番号盗用比率は約93%です。（出典：日本クレジット協会発表、ECのミカタ記事 https://ecnomikata.com/ecnews/marketing/49820/ ）被害総額は11年ぶりに前年比減少となりましたが、番号盗用-つまり「なりすまし型」の構造そのものは、依然として9割以上を占め続けています。 カード決済でも、後払いでも、フードデリバリーでも。 不正の入口は、いずれも「アカウントを新しく作る」という同じ動作に集約されているのです。 3. 共通する手口は「新規アカウントの大量作成」 不正のパターンを並べてみると、表層の手口は違っても、根底のメカニズムは同じです。 ・メールアドレスを使い分け、新規ユーザーとして次々に登録する ・入手したカード番号や個人情報を、複数のアカウントに割り当てる ・初回特典・無料クーポン・トライアル価格を、何度も適用させる ・返品・返金・キャンセル申請を、各アカウントから散発的に送る 事業者側の視点で見ると、被害は「個別の不正注文」として計上されますが、攻撃者側から見れば「ひとつのオペレーション」です。一人の人物が複数のアカウントを回しているケースが多く、業界レポートでもこの構造が繰り返し指摘されています。...
お知らせ一覧
本人を排除する本人確認――「ゆうちょ電話番号変更問題」が映した認証設計の倒錯
2026年5月、ある一本のYouTubeショートが公開されました。投稿者がゆうちょ口座の登録電話番号を変更しようとした体験記です。結末は、最終的に投稿者がATMに足を運ぶというものでした。一見、よくある「行政手続きの不便さ」の話に見えます。しかし、この出来事の本当の特異点は別のところにあります。本人を確認するための仕組みが、本人をもっとも強く拒絶した――この一点に尽きます。本記事では、この一事例を起点に、「認証は、いつから本人を弾く関所になったのか」という問いを立て、認証設計に潜む3つの構造欠陥と、それを反転させる設計思想を整理します。 1. 起きていたのは「不便」ではなく「倒錯」だった ゆうちょ電話番号変更で起きた5重ループ 動画で描かれていた経緯を、淡々と並べてみます。投稿者は、固定電話の番号が変わったため、ゆうちょ口座の登録電話番号を変更しようとしました。まず通帳アプリから手続きを試みると、「ゆうちょ認証アプリ」のインストールを求められます。指示通りにアプリを入れ、口座番号・暗証番号・生年月日を入力し、本人確認書類を読み取り、顔写真も撮影しました――ここまでで本人確認のステップはほぼ完走したように見えます。ところが最後の確認手段として案内されたのが、「登録電話番号への音声による確認コードの伝達」でした。その電話番号が使えなくなったから変更しに来ている人に対して、です。代替手段として案内された「ゆうちょダイレクト」も、トークン――専用の小さな認証機器――が電池切れで使えませんでした。トークンの電池は交換できず、再発行は有料です。さらに、認証アプリを登録すると今後トークンは使えなくなる仕様だといいます。最終的に投稿者は、ATMに足を運ぶことで番号変更を完了させました。オンラインで手続きを始めた人が、5回はじき返されて、最後はオフラインの窓口へ――これがこの動画の全貌です。 これは「UXの悪さ」ではなく「認証設計の倒錯」 不便なシステムは世の中にいくらでもあります。そして、不便であることそれ自体は、必ずしもニュースになりません。この件の特異性は、起きていたのが「動線の悪さ」ではなく、もっと根の深い倒錯だったという点です。本人を確認するための仕組みが、本人をもっとも強く拒絶していました。投稿者は本人確認書類も顔写真も提出し、本人であることをそれ以上ないほど明示的に示しています。にもかかわらず、システムが信頼したのは「目の前の本人」ではなく「過去に登録された電話番号」のほうでした。ここで一度、立ち止まって問いを置きたいと思います。「認証は、いつから本人を弾く関所になったのか」以下では、この問いに対する答えを、構造の側から3つの欠陥として分解します。 2. 本人排除パラドックスを生む3つの構造欠陥 欠陥①｜「本人の現在」ではなく「過去に登録された情報」を認証している 多くの認証システムが認証対象としているのは、「今、目の前にいる本人」ではなく、「登録時点で本人が登録した情報」のほうです。両者が一致しているうちは、この設計はうまく機能します。ところが、引越し・電話番号変更・端末故障といったライフイベントが起きた瞬間、「現在の本人」と「過去に登録された情報」のあいだにズレが生まれます。そしてシステムは、ほとんど例外なく過去側を信じます。本人がその場で本人確認書類を提示していても、です。これは技術的な欠陥というより、設計思想の問題です。「本人とは何か」を「事前に登録されたデータと一致する人」と定義してしまうと、登録データが古くなった瞬間に、本人はシステムから締め出されます。 欠陥②｜「経路の一本足打法」がトークン電池切れで全滅する 動画のもうひとつの核心は、認証アプリ・トークン・音声コード送付――一見複数あるように見える経路が、実は全部「登録電話番号」というひとつの足にぶら下がっていた、という点です。セキュリティ業界では「2要素認証」という言葉が広く使われています。ただ、ここでよく混同されるのが、「2要素」と「2経路」の違いです。2要素は、「知っているもの(パスワード等)」と「持っているもの(電話・トークン等)」のように、性質の違う2種類の情報を組み合わせるという発想です。これに対して2経路は、情報を運ぶ通り道そのものを2本に分けるという発想です。たとえばインターネット網と電話網は、まったく別の通信経路として独立しています。要素を増やしても、それらがすべて同じ経路に乗っていれば、その経路が落ちた瞬間に全滅します。動画のケースでは、認証アプリもトークンもSMSも、すべて「登録電話番号」というたった一本の経路上にぶら下がっていたため、その番号が古くなった瞬間にすべての手段が一斉に機能停止しました。「2要素にすれば安全」ではなく、「2経路にしなければ安全にならない」――この区別は、認証設計の出発点に置かれるべき認識です。 欠陥③｜「店舗・窓口」を最後の砦にしている設計の限界 3つ目の欠陥は、もっとも語られにくい部分です。オンライン化を本気で進めている事業者であっても、最後の認証手段として残されているのは、店舗・窓口・ATMといったオフライン拠点です。動画の投稿者も、最終的にはATMへ行きました。これを「最後の砦として人手による対応を残しておくべき」と捉える見方があります。たしかにそれは一面の真実です。ただ、別の側面からも見ておく必要があります。窓口は安全装置であると同時に、オンラインで設計しきれなかった例外処理の「引き取り先」になっています。これは設計の敗北宣言でもあります。投稿者から見れば、本人確認書類も顔写真もアプリで提出させられた末に、結局オフラインに戻されたわけです。事業者から見れば、デジタル化のコスト削減効果が、最後の最後で例外処理の人件費に吸われています。顧客信頼から見れば、「結局オンラインでは完結しないんだ」という学習が、デジタル投資全体の体験価値を毀損しています。窓口を「最後の砦」と呼ぶか、「負債の引き取り先」と呼ぶかで、設計に向かう姿勢はまったく変わります。 3. 「本人を弾かない認証」のために設計を反転させる 3つの構造欠陥を踏まえたうえで、ではどう設計を組み直すか。3つの反転で整理します。 反転①｜認証の主語をユーザーに戻す 第一の反転は、認証の主語を企業からユーザーに戻すことです。現在の主流の発想は、「企業がユーザーを確認する」というものです。SMSを送る、コードを発行する、トークンを配る――いずれも主体は企業側にあります。ユーザーは、企業が用意した手段を受け取り、それに応答する側に置かれています。これを反転させると、「ユーザーが自分から名乗り出る」という発想になります。たとえば、ユーザーが自分のスマートフォンから指定された番号に1コール発信するだけで本人確認が完了するという方式です。発信者は本人、発信元の電話番号は契約時に公的証明書で本人確認済み、通話料はかからず、1秒で終わります。この反転は、UXだけでなくコスト構造も逆転させます。SMS認証は、企業側がSMSを送るたびにコストを負担します。実運用では、再送信を含めて1認証あたり平均4回のSMS送信が発生するという観測もあります(自社調べ)。これがユーザー発信に切り替わると、企業側の通信コストはゼロになります。 反転②｜経路を「情報×物」の2経路に分ける 第二の反転は、認証経路をインターネット網と電話網の2系統に分けることです。インターネット網は情報の経路です。アプリもブラウザもSMSのプッシュ通知も、すべてこの経路を通ります。一方、電話網は「物」――回線契約という物理的な実体――の経路です。電話の音声通話は、インターネット網ではなく、通信キャリアが管理する電話交換網を通ります。この2経路は独立しているため、片方が落ちてももう片方は生きています。さらに、音声通話の回線契約には公的証明書による本人確認が法律で義務付けられています(携帯電話不正利用防止法)。つまり電話番号という「物」は、その背後に公的な本人確認の裏付けを持っているわけです。加えて、フィッシングサイトには電話回線がありません。偽サイトがどれだけ本物そっくりに作られていても、「電話を持っていない」という一点で構造的に破綻します。「偽サイトはあなたの電話回線を持っていない」――この一文は、フィッシング対策の根拠を一行で言い切る表現として有効です。 反転③｜端末変更・電話番号変更の「再開導線」をオンラインで閉じる 第三の反転は、ライフイベントへの備えを最初から設計に組み込むことです。電話番号が変わる、端末が壊れる、海外に長期滞在する――こうした事象は例外ではなく、必ず一定割合で発生します。にもかかわらず、多くのシステムでは「番号が変わったらどうするか」が後付けの例外処理として扱われています。結果、その例外処理の入口が窓口になります。これを設計時点から組み込むやり方があります。たとえば、旧電話番号が使える時点で新しい電話番号を一度認証しておき、移行を完結させる手順。あるいは、事前に登録した秘密の質問への回答による本人確認。あるいは、カスタマーサポートとはがき送付、eKYC連携を組み合わせた段階的な復旧手順。いずれも、「窓口に行ってください」を最後の選択肢ではなく、最初から想定された複数の経路の一本として位置づけ直す試みです。オフラインの選択肢を消すという話ではありません。オフラインを「敗北の引き取り先」ではなく、「設計に含まれた一つの経路」に格上げするという話です。 4. 認証から「接点保証」へ――INFRONT Securityの位置づけ ここまで述べてきた3つの反転――主語をユーザーに戻す、経路を情報と物の2系統に分ける、再開導線を事前設計する――を、そのまま製品として実装したのがInfront Securityです。ユーザーがログイン時にワンタップすると、スマートフォンから指定番号に1コールが自動発信されます。通話料はかからず、1秒で完了します。サーバー側で発信者番号と端末情報を照合して本人確認が完了するため、企業側はSMSコストもトークン管理コストも負担しません。導入実績では、ログイン完了率が最大45%向上した事例があります(同社導入時実績)。不正利用率はほぼ0%の実績で推移しています。私たちはこのアプローチを、「接点保証」と呼んでいます。本人確認の精度を高めることと同時に、本人と企業がストレスなくつながり続ける状態そのものを保証する、という発想です。ゆうちょの事例のように、本人確認の仕組みが本人を排除するパラドックスは、技術ではなく設計思想の問題です。設計思想を反転させた瞬間に、コストもUXも顧客信頼も同時に回復します。認証設計の見直しを検討されている方は、ホワイトペーパーや個別のご相談をお受けしています。 不正は劇的に、ユーザーは快適に。Infront...
お知らせ一覧
3Dセキュア導入後、決済承認率が下がっていませんか？ 見落とされがちな「運用方式」の選択肢とは？
2025年3月末、すべてのEC加盟店に対して3Dセキュア2.0（EMV 3-Dセキュア）の導入が義務化されました。 クレジットカードの不正利用被害額は2024年に555億円と過去最高を更新しており、義務化そのものは避けられない流れでした。 しかし、対応を終えた多くのEC事業者が今、別の問題に直面しています。 「3Dセキュアを入れたのに、CVR（コンバージョン率）が下がったまま戻らない」「カゴ落ちが増えた実感がある」――こうした声が、導入後に急増しています。 実は、3Dセキュアには複数の運用方式があり、どの方式を選ぶかによって売上への影響はまったく異なります。 本記事では、JCA（日本クレジット協会）が定める3つの運用方式の違いと、CVR低下の構造的な原因、そして売上を回復させるためのアプローチを解説します。 1．3Dセキュア義務化後にEC事業者が直面している現実 義務化は「対応して終わり」ではなかった 3Dセキュア2.0の導入義務化により、多くのEC事業者がシステム対応を完了しました。 しかし、導入後の月次レポートを見ると、CVRが導入前の水準に戻っていないケースが少なくありません。 YTGATE社の調査によると、EMV 3-Dセキュア導入後に決済承認率が95％台から85％前後へ低下し、8割の加盟店が「カゴ落ちが増えた」と実感しています。 65％以上の消費者が認証エラーを経験しているというデータもあり、「義務化対応＝問題解決」とはなっていないのが実態です。 3Dセキュアは不正利用を防ぐための仕組みですが、導入しただけでは売上への悪影響を最小化できない――この認識が、まず重要な出発点になります。 3Dセキュアの運用方式は「1つ」ではない 見落とされがちですが、JCA（日本クレジット協会）は3Dセキュアの運用について、不正対策のレベルに応じた3つの方式を認めています。 「方式①（リスク判断で認証）」は、包括的な不正防止体制が整っている加盟店が対象で、最大98％の取引を3DS認証なしで処理できます。AI不正検知や24時間体制の運用が必要で、カード会社の個別承認も求められます。 「方式②（初回登録時だけ認証）」は、カード登録時のみ3DS認証を実施し、以降のリピート購入は加盟店のリスク判断で処理するモデルです。アカウント乗っ取り防止（ATO対策）の実装が前提条件となります。 「方式③（毎回認証）」は、すべての決済で3DS認証を通すデフォルト運用です。特別な条件はなく、方式①②に該当しない加盟店は自動的にここに分類されます。 現在、大半のEC事業者はこの方式③で運用しています。 そして方式③こそが、CVR低下の構造的な原因になっています。 方式③がCVRを押し下げる「二重の痛み」 方式③で運用する加盟店は、2つの要因の掛け算で売上を失っています。 1つ目は、「追加認証を求められる割合の高さ」です。 3Dセキュア2.0ではリスクベース認証が導入されており、低リスクと判定された取引は追加認証なし（フリクションレス）で通過します。しかし、世界平均でも認証なしで通過できる割合は58〜64％にとどまっています（Ravelin社グローバル決済レポート）。つまり、全取引の約40％で追加認証が発生しているのが現状です。 3Dセキュア2.0のチャレンジ認証は、従来の固定パスワード方式から、ワンタイムパスワード（OTP）や生体認証へと移行が進んでいます。OTPはSMS・メール・専用アプリで発行され、「パスワードを忘れて離脱する」という1.0時代の課題は改善されました。 しかし、OTPには別の離脱要因が存在します。SMSが届かない（スパム判定・電波状況）、認証アプリの事前設定をしていない、メールの受信に気づかない――こうした理由で認証が完了できず、離脱するケースが依然として発生しています。 2つ目は、「追加認証画面での離脱率」です。 OTPや認証画面に遷移した利用者のうち、15〜25％が離脱すると報告されています。特に60代以上のカード会員では3Dセキュアの登録率自体がわずか約16％にとどまっており（かっこ社調査）、高単価商材や健康食品など、高齢者層が主要顧客であるECサイトへの影響は深刻です。...
お知らせ一覧
不正ログイン対策、もう先延ばしできない セキュリティチェックリストが届いたEC加盟店へ【202...
近年、不正ログインや不正利用への対策は、一部の大手事業者だけの課題ではなく、規模を問わずすべてのEC加盟店に求められるテーマになっています。2025年3月に公表されたクレジットカード・セキュリティガイドライン6.0では、3Dセキュアの義務化に加え、不正ログイン対策も必須要件として明確化されました。その影響を受け、決済代行会社（PSP）からセキュリティチェックリストが送付され、各加盟店の対策状況を確認する動きが広がっています。 本記事では、なぜ今このタイミングで不正ログイン対策が求められているのか、その背景を整理したうえで、売上と両立し得る現実的な選択肢を考えていきます。 1. なぜ今、EC加盟店は不正ログイン対策に「向き合わざるを得ない」状況になっているのか 義務化を理解しつつも対応を後回しにしてきた背景 不正ログイン対策や本人認証の強化が求められる流れ自体は、2024年から2025年にかけて、すでに業界内で広く共有されていました。実際、経済産業省のガイドライン改訂や、不正利用被害額の増加といった情報に触れ、3Dセキュアについては対応を完了しているEC加盟店は少なくありません。一方で、不正ログイン対策については、具体的に何をどこまで実装すべきか判断が難しく、CV低下や離脱増加への懸念から、後回しにされがちな領域でもありました。とくに中小規模のECでは、ログインや購入フローに手間が増えることが、そのまま売上減少につながるという感覚が根強くあります。 認証を強化した結果、初回購入やリピート初期で離脱が増えたという話を見聞きし、「セキュリティは重要だが、事業への影響が大きい施策は選びにくい」と判断するのは、当時としては決して不自然な選択ではありませんでした。 結果として多くのEC加盟店は、不正ログイン対策の必要性を理解しつつも、「いずれ対応すべきだが、今ではない」という判断を続けてきたのです。 決済代行会社からのチェックリスト送付が意味するもの 近年、決済代行会社（PSP）からセキュリティチェックリストが送付されるケースが増えています。このチェックリストは、不正ログイン対策や本人認証の実装状況を確認するための書類であり、多くの場合、「Yes」「No」での明確な回答が求められます。 重要なのは、これが単なる形式的な書類提出ではなくなっている点です。 これまで「推奨」や「努力目標」とされてきた対策が、実際に実装されているかどうかを確認・管理する対象へと変わりました。書類上でYesと回答する以上、実運用や仕組みが伴っていることが前提となります。 その結果、セキュリティ対策は加盟店の自主判断に委ねられるものではなく、PSPによって確認される事項として扱われるようになりました。 さらに、チェックリストには提出期限が設けられるケースもあり、これまでのように判断を先延ばしにすることが難しくなっています。 これ以上先延ばしにできない状況で起こり得るリスク セキュリティチェックリストを提出しない、あるいは実装が確認できない場合、PSP側から不正対策未実施と判断される可能性があります。 PSPは多数の加盟店を抱えているため、すべてを個別に精査することは現実的ではなく、判断はどうしても書類ベースにならざるを得ません。 その結果、対策状況が不明確な加盟店は、リスクの高い取引先として内部管理されることになります。即時ではなくとも、状況次第では段階的な制限がかかり、決済停止や利用制限に発展することもあります。 一度停止や制限がかかった場合、その解除には追加資料の提出や再審査が必要となり、想像以上の時間と工数を要するケースも少なくありません。 決済が止まることで発生する売上損失は、事前に対策を講じておくためのコストを大きく上回ることもあります。 こうした背景から、現在は不正被害が発生してから対応するのではなく、未然に防ぐことが前提となっています。 2. IP制限やMFAでは踏み切れない、不正ログイン対策のジレンマ IPアドレス制限が実運用で機能しにくくなっている理由 IPアドレス制限は、比較的導入が容易でコストも抑えやすいことから、不正ログイン対策の第一歩として多くのEC加盟店に採用されてきました。 大きなシステム改修を伴わずに導入できる点は、特に中小規模の事業者にとって現実的な選択肢だったと言えます。また、「海外IPを遮断すれば一定の不正は防げる」という考え方も、過去には一定の効果を発揮してきました。 しかし現在では、VPNやプロキシ、ボットを用いて国内IPや正規ユーザーと同じ地域からアクセスする手法が一般的になり、「海外IP＝怪しい」という単純な判別は通用しなくなっています。加えて、モバイル回線ではIPアドレスが頻繁に変動するため、正規ユーザーを誤って遮断してしまうケースも少なくありません。 その結果、IP制限はチェックリスト上では「対策済み」と回答できる一方で、実運用においては不安が残る対策になりやすくなっています。 本人確認を行う仕組みではない以上、手法を変えた不正を完全に防ぐことは難しいのです。 多要素認証（MFA）が離脱やCV低下につながりやすい現実...
お知らせ一覧