SMS認証をONにしても安全とは限らない|AIフィッシング時代、仕事アカウントを守る3つの扉

仕事用メールに「請求書を確認してください」と届く。いつもの取引先名、自然な敬語、しかも自分の案件名まで入っている。ログイン画面では、SMSで届いた6桁のコードも入力した。それでもアカウントを奪われることがある。
「SMS認証を設定しているから大丈夫」という思い込みが危ないのは、SMSが無意味だからではありません。SMS認証にはパスワード単独より一段強い防御があります。一方で、電話番号の乗っ取り、偽サイトへのコード入力、ログイン後のセッション窃取という別々の弱点が残ります。
AI時代に必要なのは、怪しいメッセージを完璧に見抜く能力ではなく、一度だまされても仕事が連鎖的に止まらない認証設計です。この記事では、個人事業主・フリーランスが本当に守るべきアカウントを選び、今日から移行できる順番まで整理します。
最初に結論:SMS認証しか選べないサービスではOFFにしない。大事なメール・決済・クラウドからパスキー/FIDO2へ移行し、復旧手段と既存セッションも一緒に見直す。NIST SP 800-63Bも、SMS等の電話網を使う認証を全面禁止ではなく制限付きで扱っています。
SMS認証の「6桁」が守れるもの、守れないもの
- SMS追加認証
- パスワード単独より強い
- SIM乗っ取り・OTP中継には弱い
- 認証アプリ(OTP)
- 番号乗っ取りへの依存を減らす
- 偽サイトへ入力すると中継され得る
- パスキー / FIDO2
- 偽サイトへの認証中継に強い
- 復旧・セッション管理は別途必要

パスワードが漏れたとき、追加のSMSコードが必要なら攻撃者はもう一段突破しなければいけません。これが二要素認証の大切な価値です。ただし、本人がコードを受け取った事実と正規のサイトにログインしている事実は別。SMSコードそのものは、入力先が本物かどうかを検証してくれません。
認証方式を比べると、次のように弱点が異なります。
- パスワードだけ:漏えい・使い回しに弱い。まず追加認証を設定したい。
- SMSの追加認証:パスワード単独より強い。ただしSIMスワップや偽サイトへのコード転送に弱い。
- 認証アプリのワンタイムコード:電話番号が奪われてもコード自体は直ちに移らない。ただし偽サイトへ手入力すれば中継され得る。
- パスキー/FIDO2セキュリティキー:正規サイトとの結び付きがあるため、偽サイトへの認証中継に強い。
ここで重要なのは「SMSより認証アプリ、さらにパスキー」という単純な順位を暗記することではありません。認証アプリでもコード手入力型はフィッシング耐性を持たないこと。NISTはSMSなどのout-of-band方式とOTP方式を、いずれもフィッシング耐性のない方式と説明しています。出典:NIST SP 800-63B(フィッシング耐性・制限付き認証)、IPA(多要素認証の推奨)
SIMを奪われなくても、コードは盗まれる

SMS認証を突破する代表的な経路は二つ。番号そのものを奪うSIMスワップと、届いたコードを本人に入力させるリアルタイムフィッシングです。似て見えて、必要な対策は違います。
経路A:SIMスワップ
攻撃者が通信会社の手続きを悪用して電話番号を別のSIM・端末へ移すと、その番号宛てのSMSを受け取れる可能性があります。番号に結び付いたログインやパスワード再設定が危険にさらされます。携帯契約のアカウント保護・本人確認・PINの有無を確認し、突然の圏外やSIM変更通知を放置しないことが防御の起点です。
経路B:リアルタイムフィッシング
攻撃者は本物に似たログイン画面を用意し、入力されたID、パスワード、OTPをすぐ正規サイトへ中継します。SMSが自分のスマホに届いていても、この攻撃は成立します。さらにAiTM(中間者)型では、認証後のセッションクッキーが狙われる場合があります。
だから、コードが届いたことを「サイトが本物である証拠」と考えない。自分で開いたブックマークや公式アプリからログインする習慣は有効ですが、それだけに依存しないパスキー移行が長期の答えです。出典:FTC(SIMスワップ対策)、IPA NEWS(リアルタイムフィッシング)、Microsoft(Tycoon2FA)
AIが破るのはSMSの暗号ではなく、こちらの判断

「AIがSMS認証をハッキングする」という見出しは刺激的ですが、問題の本体をずらします。確認できる攻撃の変化は、暗号解読よりも個人化された偽メッセージを、安く速く大量に作れることです。
Microsoftは2026年4月の報告で、AIを組み込んだフィッシングのクリック率が最大54%に達し、従来型の約12%と対比される事例を紹介しました。これはMicrosoftが観測したキャンペーンの話であり、全業種・全利用者で「54%の確率で引っかかる」という意味ではありません。
フリーランスの場合、公開ポートフォリオやSNSの情報から「先週のデザイン修正の件」「請求書の振込先確認」といった、今まさに対応しそうな文脈が作られます。文体の違和感だけで見抜く防御は、これから不利になります。
そこで発想を変えます。本物に見える連絡が来ても、認証コード・パスキー登録・端末承認をメールのリンク先から始めない。高リスクな操作は登録済みの公式アプリ・ブックマークから独立に行い、メール本文で指示された操作と切り離す。出典:Microsoft Security Blog(2026年4月2日)
仕事アカウントは「ログイン・復旧・セッション」の3つで守る
- ログイン
- Passkey / FIDO2
- 主要アカウントから優先
- 復旧
- バックアップコード・復旧先
- 同じ番号・メールへの集中を点検
- セッション
- 端末・履歴・トークンの確認
- 認証後の侵害経路を点検

パスキーを導入しても、守るべき入口はまだ残ります。フリーランスのアカウント防衛を、三つの扉に分けると判断しやすくなります。
扉1:ログイン
メール、クラウド、決済など重要なサービスでパスキー/FIDO2が使えるなら優先導入。パスキーはサイトと紐づく公開鍵認証で、偽サイトに同じ鍵を使わせにくい仕組みです。顔認証だけがパスキーなのではなく、生体認証や端末PINは多くの場合、鍵を使うためのローカルな解除操作です。
扉2:復旧
登録済みのパスキーが強くても、古い予備メールやSMSだけで簡単にアカウントを取り戻せる設定が残っていれば、そこが弱点になり得ます。バックアップコードは安全な別経路に保管し、復旧用メール自体にも強い認証を設定する。サービスごとに使える復旧方法は違うので、登録したつもりで終わらず確認します。
扉3:セッション
ログインが成功した後のセッショントークンや、別の認証フローで発行されたトークンを攻撃者が得る事例もあります。Microsoftは2026年9月、パスキーを口実に利用者を別の承認フローへ誘導する攻撃を報告しました。これはパスキーの暗号が破られたという意味ではありません。見覚えのない端末、サインイン履歴、OAuth連携、メール転送ルールも定期的に点検する必要があります。
出典:Google(Passkeys)、NIST(フィッシング耐性)、Microsoft(パスキーを口実にした侵害事例)
今日の30分、守るべき5アカウントから始める
- パスキー / FIDO2に対応重要アカウントから登録し、復旧・セッションも点検
- パスキー非対応で認証アプリが利用可能SMSからの切替・併用条件を確認し、OTPの中継リスクも意識
- SMSしか利用できないSMS MFAを残し、携帯アカウント保護と復旧手段を強化

全部のサービスを一度に見直す必要はありません。まずは一つ乗っ取られると他のサービスまで崩れるアカウントを先に守ります。優先度を決める基準は利用頻度ではなく、攻撃された際の連鎖被害です。
- 仕事のメインメール:各SaaSの再設定通知と顧客連絡が集まる。最優先。
- Google/Microsoft等の基幹ID:ログイン連携やファイル、端末同期の中心。
- 銀行・決済・請求サービス:金銭と振込先情報に直結する。
- GitHub・クラウド・ドメイン:Webサイト、顧客データ、公開環境を握る。
- 会計・広告・EC管理:売上、個人情報、広告予算に影響する。
実行順は簡単です。①公式サイトのセキュリティ設定を開く。②パスキー/FIDO2を選べるなら登録して実際にログインする。③選べなければ認証アプリなどSMS以外の方式を検討する。④SMSしかなければOFFにせず固有のパスワード、携帯契約の保護、復旧手段を強化する。⑤バックアップコードと登録済み端末を確認する。
最後に、「パスキーを設定したのに、SMSでも簡単にログイン・復旧できる状態」が残っていないかをサービスの仕様の範囲で見直してください。SMSを無理に消してログイン不能になるより、利用可能な強い方式を優先し、復旧経路を安全に維持する方が実務的です。
Microsoftも2026年9月1日から、Entra IDでパスキー登録を促すデフォルト認証体験を段階的に展開しています。ただし適用時期や管理者の許可、アカウント種別によって利用できる設定は異なります。出典:Microsoft(2026年7月13日)、FTC(多要素認証)
仕事用eSIMを増やしても、認証の弱点は消えない

「仕事用の番号を分ければSMS乗っ取りは防げる?」という疑問には、答えを二つに分ける必要があります。仕事と私用の番号を分ける運用価値はある。一方、番号自体が認証手段である限りSIMスワップへの耐性は根本的には変わりません。
番号分離で期待できるのは、公開する連絡先を限定できること、顧客連絡の整理、紛失時の回線BCPなどです。だから追加のeSIMを選ぶ理由は「SMSの防御が完成するから」ではなく、業務上の連絡・回線・復旧の運用を分ける利益が月額費用を上回るかで判断したいところ。
実務的には、仕事用番号の運用を考える前に、メールや基幹IDのパスキー化を先に進めるのが合理的です。SIMを追加したい場合は、フリーランスの仕事用番号とeSIMの分け方で回線設計を確認できます。また、eSIM機種変更でSMSが届かないときの復旧手順は、認証と電話番号が同時に失われるリスクを考える際にも役立ちます。
注意:電話番号分離による被害率の低下を示す日本国内の確かな横断データは今回確認できていません。防御効果を数字で断定せず、運用分離のメリットとして評価します。
もし「突然圏外」「知らないログイン通知」が来たら
電話番号を確保
突然の圏外やSIM変更通知は公式キャリア窓口へ確認
セッションを遮断
正規画面から認証方法・端末・ログイン履歴・セッションを点検
仕事への波及を止める
メール転送・振込先変更・外部連携を調べ、必要なら別経路で顧客へ連絡

侵害の兆候が出たときは、設定を片っ端から触るより、攻撃者がまだ使える経路を止めることから始めます。状況に応じて次の順番が目安です。
- 電話番号に異変がある:突然圏外・SIM変更通知・SMS不着が続くなら、別回線・別端末から契約キャリアの公式サポートへ連絡し、不正なSIM変更の有無を確認する。
- アカウントに異変がある:信頼できる端末と正規アプリからパスワード・MFA・復旧手段・登録端末・セッションを確認し、利用可能なら不審なセッションを失効させる。
- 仕事への波及を止める:不審なメール転送設定、請求先・振込先変更、クラウド/APIトークン、外部連携を確認する。顧客へのなりすましや誤送金が疑われるなら、いつもの連絡経路とは別の方法で取引先へ事実確認する。
既にお金や顧客情報が関係している場合は、銀行・決済事業者・関係先への連絡を優先してください。端末自体の感染が疑わしいときは、同じ端末だけで復旧を完結させないことも重要です。出典:FTC(SIMスワップ被害時の対応)、Microsoft(トークン窃取後の行動)
結論:SMS認証は「役に立たない」のではなく、「それだけでは仕事を守り切れない」。まずは重要な5アカウントのログインを強くし、復旧ルートとセッションを別々に点検する。AI時代に必要なのは、詐欺を全部見抜くことではなく、ひとつの突破で全部を失わない設計です。認証以外の防御まで広げたい場合は、フリーランスのAI時代セキュリティ防衛設計も参考にしてください。









