コラム
GoogleもNISTも「SMSをやめろ」と言う時代——SMS廃止後、EC・金融が選ぶべき認証...
Gmail・GビズID・NISTが相次いでSMS認証を見直す中、EC・金融が次に選ぶべき認証は何か。リアルタイムフィッシング、パスキー、電話発信認証など主要選択肢を比較し、廃止後の設計指針を解説します。
お知らせ一覧
介護情報基盤2026年度スタート——デジタル化する介護現場で「つながる保証」をどう担保するか
2026年度開始の「介護情報基盤」で介護現場の連携が変わる中、本人確認・本人アクセスの空白をどう埋めるか。高齢者デジタルデバイドへの現場対応と、「つながる保証」という考え方を解説します。
お知らせ一覧
AIが“なりすまし”のコストをゼロにした時代に —突破されない認証は「AIが触れない場所」にある
先日、あるセキュリティ責任者の方が書かれた一文を読んで、背筋が伸びる思いがしました。自社に届いたフィッシングメールを眺めていて、思わず二度見してしまった—3年前なら件名と差出人を見た瞬間に鼻で笑っていたはずのメールが、いまでは「これ、本物では?」と疑ってしまうレベルで届くようになった、と。 これはwevnalのCTO・鈴木和夫氏がnoteで公開した「AIがセキュリティの前提を壊した日」という記事の冒頭です。日本語の不自然さも、ロゴの解像度も、偽装ドメインの精度も、すべてが別物になった—氏はそう書いています。 ここで起きているのは、単に「フィッシングが巧妙になった」という話ではありません。AIによって、攻撃する側と守る側のコストのバランスが、根本からひっくり返ったということです。本稿では、その変化を正面から受け止めたうえで、それでも突破されない認証はどこにあるのか—という一点に絞ってお話しします。 1. AIは「なりすますコスト」をゼロに近づけた 日本語の壁が崩れた—「人を最後の砦にする」運用の限界 これまで日本の現場には、ある種の安心材料がありました。海外発のフィッシングメールは機械翻訳の不自然さが残り、敬語や時制が崩れていたため、注意深い社員ならかなりの確率で見破れたのです。いわば「日本語というファイアウォール(防火壁)」に守られていた、と言ってもよいと思います。 ところが、その壁が崩れました。生成AIの登場で、敬語にも業界の慣習にも沿った自然な文面が、秒単位で量産できるようになったのです。社内の決裁プロセスや日本特有の取引慣行まで踏まえたビジネスメール詐欺—取引先や経営者になりすまして偽の送金先に振り込ませる手口です—も増えています。 これは個人の感覚論ではありません。IPA(独立行政法人 情報処理推進機構)が公表した「情報セキュリティ10大脅威 2026」でも、生成AIの進化によってビジネスメール詐欺の巧妙さにさらに磨きがかかっている、と明記されています(出典:IPA「情報セキュリティ10大脅威 2026」2026年)。 つまり、「人の目で最後に見破る」という運用が、いよいよ限界に来ているということです。冒頭の「二度見してしまうメール」は、その象徴だと言えます。 攻撃の自律化—偵察から窃取まで、人手を介さなくなる もう一つ、見逃せない変化があります。攻撃そのものをAIに任せる動きです。 2026年に入ってから、AnthropicがGTG-1002と呼ぶ脅威グループによる攻撃を公表しました。同社の説明によれば、偵察から脆弱性の発見、横方向への侵入、認証情報の窃取、データの持ち出しまで—その8〜9割が自律的に実行されていたとされています(出典:Anthropic「Disrupting AI espionage」2026年)。 ここで起きているのは、「攻撃者がAIを補助的に使う」段階から「攻撃そのものをAIに任せる」段階への移行です。攻撃のコストは劇的に下がり、スピードと品質は跳ね上がります。守る側にとっては、人の手の数を前提にした検知・対応のモデルそのものが古くなっていく、ということを意味します。 2. SMSとワンタイムパスワードは、なぜ“原理的に”突破されるのか 「コードを入力させる」方式の構造的な穴 ここで、いま多くのサービスが使っている本人確認の方法を振り返ってみます。SMS認証は、企業がショートメッセージで数字のコードを送り、ユーザーがそれを画面に入力する—という流れです。 この方式には、構造的な穴があります。「ユーザーにコードを入力させる」という設計そのものが弱点なのです。攻撃者が本物そっくりの偽サイトを用意し、そこにコードを入力させれば、攻撃者はそのコードをそのまま本物のサイトに横流しして、なりすませてしまいます。 身近なたとえで言うと、合言葉で本人確認をする仕組みに似ています。「合言葉を言ってください」と聞く方式では、間に立った偽者が「合言葉は?」と尋ね、聞き出した言葉をそのまま奥の本物に伝えてしまえば、通れてしまう—そういう穴です。SIMスワップ(携帯番号を不正に乗っ取る手口)による傍受のリスクもあります。 この穴は、すでに実害として表れています。フードデリバリーの分野では、海外の使い捨て番号やVoIP(インターネット経由の電話番号)を使ったSMS認証の突破が常態化し、いたずら注文による配達員の無駄な稼働や飲食店の廃棄ロスが発生しています。後払い決済の分野でも、メールアドレスと電話番号だけで使える手軽さの裏で、架空の個人情報による「取り込み詐欺」が未回収を押し上げています。 AIがなりすましのコストをゼロに近づけたいま、「コードを入力させる」方式の穴は、これまで以上に突かれやすくなっています。 AIは「情報」を盗めても、「物理的な回線」は持てない では、攻撃側がどれだけ賢くなっても、決して複製できないものは何でしょうか。 それは、契約された電話回線そのものです。AIは文面を完璧に偽装できます。コードを盗み、画面を真似ることもできます。しかし、特定の人が通信会社と契約した物理的な電話回線—その回線から発信するという行為だけは、画面の向こうの攻撃者には代行できません。...
お知らせ一覧
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の認証フローが混在する際の検証不備により、任意のユーザーアカウントを乗っ取れるものでした。...
お知らせ一覧
本人を排除する本人確認――「ゆうちょ電話番号変更問題」が映した認証設計の倒錯
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...
お知らせ一覧