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も顧客信頼も同時に回復します。
認証設計の見直しを検討されている方は、ホワイトペーパーや個別のご相談をお受けしています。
