多要素認証とは？Google・Microsoftのログインを初歩から読み解く

この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。NIST、Google、Microsoft、RFC等の公式仕様を2026年11月6日に確認し、利用者の身近な疑問から解説しました。

検証ステータス：📘 公式仕様確認済み／実アカウントの登録・ログイン・WordPress表示は未実施

上のオリジナル図は仕組みを把握するための概念図です。実際の画面や秘密情報を再現しておらず、本文のMermaidと説明だけでも同じ結論を理解できるようにしています。

「パスワードが正しいのに、スマートフォンでも確認してくださいと言われる」。会社のMicrosoft 365、Googleアカウント、銀行などで見かける画面です。手間が増えたと感じるかもしれませんが、これには、パスワードを知っているだけの第三者と、本来の利用者を区別する目的があります。まずは「なぜ二回確認するのか」を、仕組みと身近な例に分けて説明します。

多要素認証（MFA）は、本人が持っている異なる種類の証拠を組み合わせる考え方です。代表的な三種類は「知っているもの」（パスワードや暗証番号）、「持っているもの」（登録したスマートフォンやセキュリティキー）、「本人の特徴」（指紋や顔など）です。これらの種類の違いが大切で、単に確認画面が二枚あるから多要素になるわけではありません。

例えば、パスワードを二回入力させるだけなら、知識を二度聞いています。秘密の質問を追加しても、主に本人の知識を確認する設計です。一方、パスワードを知っているだけでは承認できず、登録済みスマートフォンを利用する必要があるなら、異なる種類の証拠が必要になります。ただし、組み合わせが適切か、本人確認の強度が十分かは、採用する技術によって変わります。

実際の画面を見ながら種類を区別する

自分で利用しているサービスのセキュリティ設定を開き、登録済みの認証方法の名前を読むだけでも勉強になります。設定を削除したり、認証方式を無効化したりする必要はありません。確認したいのは「6桁コードを手で入力するのか」「スマホへ通知が届くのか」「パスキーを選んで端末のロック解除を求められるのか」という違いです。

6桁コードを入力する画面なら、時間を使って数字を生成するTOTPという仕組みが候補になります。Google Authenticatorはその代表的なアプリです。毎回インターネットからコードを受信しているわけではなく、アプリとサービスが共有した秘密情報から計算するため、通信できない場面でも表示できます。つまり「認証アプリが数字を出す」と「公開鍵暗号を使う」は同じ意味ではありません。

Microsoft Authenticatorは、確認コードのほかにプッシュ通知を使った承認や番号照合、対応環境でのパスキーなど複数の機能を持ちます。同じアプリ名がログイン画面にあっても、何を確認しているかは一つではありません。通知に出た数字とログイン画面の数字を照合する方法と、公開鍵で署名を検証するパスキーは別の技術です。違いを知ると、製品名だけで安全性を判断する危険を避けられます。

スマートフォンの顔認証を使うと、自分の顔がWebサイトへ送られるのでしょうか。 多くのパスキー方式では、顔やPINは端末の認証器を使える状態にするローカルな確認です。サービス側は秘密鍵から作られた証拠を公開鍵で検証します。すべての顔認証がこの仕組みだという意味ではありませんが、顔の映像をWebサイトへ送る方式と混同してはいけません。

図解：確認しているものを分けて考える

sequenceDiagram
    participant U as 利用者
    participant S as ログインサービス
    participant A as 登録済み認証アプリ
    U->>S: パスワードを入力
    S-->>U: 別の証拠を要求
    U->>A: 自分のログインか確認
    A-->>U: コード表示または承認案内
    U->>S: 方式に合った追加確認
    S-->>U: 条件を満たせばサインイン

図は代表的な流れを一つにまとめた概念図です。TOTPではコードを人が入力することが多く、プッシュ通知ではアプリ側からの通信を使うため、内部の経路は異なります。共通するのは、パスワードだけで終わらず、追加の証拠を確かめるという目的です。実際のログイン画面・利用できる方法は契約や組織の設定で変わります。

一つ条件を変える：盗まれた情報が増えたらどうなるか

架空の利用者がパスワードを使い回し、第三者にパスワードだけを知られたとします。追加認証がなければ、その文字列だけでログインされる危険があります。次に、登録済みの認証アプリのコードも必要なサービスを考えます。第三者はパスワードを知っているだけでは先へ進みにくくなり、MFAを導入する意味があります。

しかし、本物そっくりの偽サイトに利用者が現在の確認コードまで入力してしまった場合はどうでしょうか。攻撃者が短時間にそのコードを本物のサイトへ転送すると、TOTPを使っていても悪用される可能性があります。つまり、多要素認証という名称だけでは「フィッシングにも強い」とは断定できません。手入力のコードと、Webサイトの名前に結び付くパスキーでは、防ぎやすい攻撃が異なります。

NISTの公式資料は、手入力するOTPをフィッシング耐性のある方式とは区別しています。これはOTPが無意味だという話ではありません。パスワード漏えいに対する追加の壁は重要ですが、偽サイトへコードを渡す攻撃には別の備えも要るということです。「強いMFA」と言うときは、どの攻撃から守りたいのかを合わせて考える必要があります。

flowchart TD
    A["認証を見直す"] --> B{"パスワードだけか"}
    B -->|"はい"| C["異なる要素を登録する"]
    B -->|"いいえ"| D["方式を区別する"]
    C --> D
    D --> E{"コードの手入力か"}
    E -->|"はい"| F["フィッシングへの限界も知る"]
    E -->|"いいえ"| G["通知かパスキーか確認"]
    F --> H["重要な用途では耐性の高い方法を検討"]
    G --> H
    H --> I["紛失時の復旧経路も用意"]

この図の最後に復旧を入れた理由があります。認証方法を登録するだけで安心してしまうと、端末紛失や機種変更のとき、自分自身がログインできなくなることがあるからです。セキュリティとは、他人を通さないだけでなく、正しい本人が困ったときに安全に戻れることも含みます。

スマートフォンを失ったときに困らないために

認証アプリに登録した情報は、サービスにより移行・同期できる条件が異なります。Google AuthenticatorにはGoogleアカウントへコードを同期する方法と、同期せず端末側に置く方法があります。どちらが適切かは、端末の運用、同期先アカウントの保護、紛失時の復旧方法によって変わります。同期さえしていれば必ず回復できる、と考えるのは危険です。

サービスが提供するバックアップコードや予備の認証方法も確認します。復旧用のコードは一度しか使えないものもあり、本人だけが安全に保管する必要があります。本物のバックアップコードや登録QRを記事、チャット、作業チケットに貼り付けないでください。企業のアカウントなら組織の再登録ルールに従い、本人確認を飛ばして方法を変更しないことが重要です。

仕事ではどう導入されている？

会社ではパスワードだけのログインより、追加の方法を使う方が不正ログインへの対策を強化できます。ただし一律に強制すると、スマートフォンを持たない利用者、端末を交換中の利用者、緊急対応担当者が締め出される場合があります。管理者は対象のグループを分け、少人数で検証し、業務アプリまで正常にアクセスできるかを確認してから広げる必要があります。

さらに、本人が開始していないログインなのにスマートフォンに「承認してください」と表示されたら、承認せずに拒否します。連続して通知が届くからと押してしまう「通知疲れ」は、認証を増やしても残るリスクです。Microsoftの番号照合は、ログイン画面との関係を利用者に意識してもらうための対策ですが、偽サイトや社会的な誘導を完全に無効化するわけではありません。

導入結果を測る際も「登録した人数」だけでは足りません。管理者がどの方式を登録したか、未対応者の安全な代替手段、機種変更時の問い合わせ、不要な承認通知が来たときの連絡先を確認します。ログから失敗傾向を調べるときも、個々の利用者の権利とプライバシーに配慮し、目的を限定して扱います。

よくある質問

「二段階認証と多要素認証は同じ？」。二つの段階があっても、同じ種類の情報を二回聞くだけなら異なる要素とは言えません。サービス独自の呼び方ではなく、具体的な認証方法を確認します。

「認証アプリなら常に公開鍵方式？」。違います。TOTPの共有秘密、プッシュ通知の承認、パスキーの公開鍵方式を分けて考えます。

「顔認証だけなら二要素ではない？」。利用する端末・認証器と、ローカルでのユーザー確認を組み合わせた設計もあります。どんな証拠をサーバーが検証するかまで見る必要があります。

「MFAがあればパスワードは適当でよい？」。パスワードを使う方式なら、そのパスワードも引き続き保護します。使い回し、共有、漏えいを防ぐ基本は変わりません。

MFAは導入した後の運用が難しい

会社では、すべての利用者に同じ認証方法を強制すると、思わぬところで問題が出ます。例えば、私物のスマートフォンを職場に持ち込めない人、会社支給端末を持つ人、出張でインターネットが不安定な人、緊急時だけ管理画面へ入る担当者では、使える手段が異なります。安全性を高めるための方法が本人の業務を止めないよう、対象と代替手段を整理する必要があります。

最初から全社員へ切り替えるのではなく、少人数の試行で新しい方法の登録・ログイン・機種変更を確認し、業務アプリまで使えるかを試します。何人が登録したかだけでは、導入の成功は測れません。ログイン画面は通過できても、会社のファイルや業務システムにアクセスできなければ、利用者にとっては仕事が終わっていないからです。

不明な承認通知は押さない

自分でログインを始めていないのにスマートフォンに承認要求が来たら、承認せず拒否します。通知が何度も届くからと「終わらせるために承認する」行動は危険です。番号照合では、自分が使っているログイン画面に表示された数字と対応しているかを確認します。ただし、同じ端末でアプリを使う場合など画面の挙動が異なる例もあるため、特定のスクリーンショットだけで全環境を説明できません。

Microsoftの公式番号照合資料は、どんな承認方法が使われるのかを確かめるために役立ちます。通知を承認することと、パスキーでサービスの名前に結び付いた署名を行うことは異なる仕組みです。どちらも認証アプリに見えることがありますが、製品名だけで判断してはいけません。

端末紛失を想定しないと本人まで締め出す

登録した端末が故障したりなくなったりした場合、パスワードは正しくても先へ進めないことがあります。だから、バックアップコード、予備の登録方法、組織による再登録など、復旧経路を事前に確認します。復旧用の情報も機密なので、チャットやメールへ無造作に貼り付けないようにします。

会社のヘルプデスクが電話だけで誰の認証方法でも変更できる運用では、通常のログインを強くしても回復の窓口が弱点になりかねません。本人確認の手順、古い端末の登録をいつ無効にするか、誰が記録を確認するかを決めておきます。強いMFAと安全な復旧を一緒に設計する理由はここにあります。

MFAの先に残る安全対策

MFAが成功した後でも、ブラウザのログイン状態を示すセッションが盗まれたり、端末がマルウェアに感染したり、アカウントに広すぎる権限が付いていたりする問題は残ります。認証を強化することだけで全ての不正アクセスを防げるわけではありません。端末の保護、最小限のアクセス権、ログの監視、利用者への教育を組み合わせることが必要です。

具体的には、重要な管理者アカウントではフィッシング耐性の高い方式を検討し、一般利用者には使える認証方法と安全な復旧を整えます。本人が申請していない認証通知をどう報告するか、アカウントの異常を誰が調べるかも決めます。機能を有効にしたことより、実際に困った場面で安全に対応できることが、運用上の価値になります。

まとめ

多要素認証は、単にログインの画面を増やすことではありません。異なる種類の証拠を組み合わせ、パスワードだけを知られた状態でも不正なサインインを防ぎやすくします。ただし、認証アプリのコードとパスキーでは技術も限界も違います。守りたいもの、利用する人、紛失したときの復旧まで含めて選ぶことが、本当に役立つMFAの導入です。

公式資料はどこを読めばよい？

• NIST SP 800-63B：認証の要素、フィッシング耐性、回復を規格の定義で確認するため。

• Google Authenticator公式ヘルプ：確認コードと機種変更・同期の扱いを製品公式資料で確認するため。

• Microsoft Authenticator公式解説：コード、通知、パスキーを別の方式として区別するため。

• 番号照合のMicrosoft公式説明：プッシュ通知の数字が何を確認しているかを調べるため。

セキュリティ技術と実際の使われ方・連載目次にもどる。