パスワードを忘れた方はこちら
電話番号を入力するだけ、パスワード不要で
本人認証が可能です。
「Infront Security」は、
従来の認証よりも圧倒的にセキュアで、
誰でも直感的に使える認証サービスです。
電話番号と端末情報を活用することで、ユーザーのログイン率を向上させ、
なりすましをはじめとするさまざまな不正を激減させます。
電話発信を利用した認証により、実際に使われている電話番号を基に実在するアカウントを特定。
不正対策を強化しながら、マーケティング施策の精度向上を実現するソリューションです。
InfrontSecurityでできる
3つのこと
不正リスクを大幅削減
InfrontSecurityの導入で、不正を劇的に削減。当社調べでは不正激減率 90%以上を実現し、企業の安全性を大幅に向上。
不正によるコストと
業務負担を大幅削減不正対応にかかるコストを削減し、業務の効率化と利益向上を実現。
これにより、余計な手間を減らし、より重要な業務に集中できます。
スムーズな認証で、
もっと使われるサービスへ認証がスムーズになり、ユーザーの利用率が大幅アップ。手間のかからない快適な認証体験が、売上や成長に直結します。
InfrontSecurityの特徴
-
高いセキュリティと
使いやすさを両立
高いセキュリティと
使いやすさを両立強固なセキュリティとユーザーの利便性を兼ね備えた認証システムです。
高度な不正対策を実現しながら、手間のかからない認証体験を提供。
安全性を確保しつつ、スムーズなアクセスが可能になることで、ユーザー満足度の向上とビジネスの成長を支えます。※本ポジショニングマップは当社の独自分析に基づくもので、事実を保証するものではありません。他社との比較や位置付けは当社の見解であり、市場評価とは異なる可能性があります。最新情報は随時更新されますので、ご自身の判断でご活用ください。
-
他の認証と比べて、
圧倒的にシンプルで簡単
他の認証と比べて、
圧倒的にシンプルで簡単誰でもすぐに使えるシンプルな認証システムなので、パスワード管理や面倒な初期設定は不要。
直感的な操作で、ストレスなく認証が完了します。
特別な知識やトレーニングも必要なく、あらゆるユーザーが簡単に利用できる仕組みを提供します。- 初期設定が不要!面倒な作業なしで導入可能
- 教育コストゼロ
- 直感的に使える
- 100%誰でも持っているデバイスで対応可能
-
開発も導入もシンプル。
すぐに
使える認証ソリューション
開発も導入もシンプル。
すぐに使える認証ソリューション導入のハードルが低く、スムーズに実装できます。
シンプルなAPI 連携で、開発負担を最小限に抑えながら、既存のシステムともスムーズに統合可能。
さらに、テスト環境の提供や導入サポートも充実しており、安心して運用を開始できます。- シンプルな API 連携
- テスト環境を無料提供
- 導入サポートあり
- 既存システムとの親和性が高い
- JavaScript 版なら即日トライアル可能
業界ごとに最適な形で
活用されています
コラム
-
2026/05/20Infront Securityコラム更新しました。
「認証は、いつから本人を弾く関所になったのか」——ゆうちょの一件は、過去に登録した情報を信じて目の前の本人を疑うという、認証設計の倒錯を浮かび上がらせました。経路の一本足打法と窓口頼みから抜け出すための再設計論です。本人を排除する本人確認――「ゆうちょ電話番号変更問題」が映した認証設計の倒錯
お知らせ一覧 -
2026/05/20本人を排除する本人確認――「ゆうちょ電話番号変更問題」が映した認証設計の倒錯
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...
お知らせ一覧 -
2026/04/063Dセキュア導入後、決済承認率が下がっていませんか? 見落とされがちな「運用方式」の選択肢とは?
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サイトへの影響は深刻です。...
お知らせ一覧
よくあるご質問
Infront Securityと他の認証サービスの違いは何ですか?
他のセキュリティシステムの多くがインターネット網の中で仕組みを複雑化して問題を解決しようとしているのに対し、Infront Securityは偽造や盗聴が非常に困難な電話番号を使用する電話網を活用して認証を行っており、高いセキュリティレベルを実現しています。本人の電話からの発信のみを認証し、不正アクセスを防ぎます。通話やSMS送信が不要で遅延や不達も通常はありませんのでコスト効率が高く、ワンタイムパスワードなどの入力が不要で使用が簡単です。
携帯電話以外の電話番号、固定電話やFAXも登録できますか?
はい、技術上すべての電話番号の登録が可能です。
携帯電話が圏外やバッテリー切れ、または忘れた場合はログインできますか?
SMS認証やワンタイムパスワードのトークンが手元にないのと同様に、基本的にはInfront Securityでのログインはできませんが、導入企業のセキュリティポリシーによっては別のログイン方法を用意することもあります。
Infront Securityサービスに登録している携帯電話を紛失した場合の対処方法を教えてください。
契約先の携帯電話会社に紛失を連絡し、SIMカード再発行などの対処方法を相談してください。
Infront Securityサービスに登録している電話番号を変更する方法は何ですか?
各導入企業のシステム上で電話番号の管理(登録、変更、削除)を行ってください。