Google Authenticatorの6桁はなぜ一致する？TOTPと共有秘密を図解

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

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

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

「飛行機の中でも、認証アプリの数字が変わり続けるのはなぜ？」。スマートフォンに通信が届かない場面でも6桁程度の確認コードが表示されると、アプリが何をしているのか不思議に感じます。Google Authenticatorなどで使われる代表的な方法は、TOTP（Time-Based One-Time Password）と呼ばれる時刻ベースのワンタイムパスワードです。

TOTPは毎回サーバーからコードを受け取っているわけではありません。スマートフォン側とログインサービス側が、登録時に同じ秘密情報を持ち、現在時刻から求めた値を使って、それぞれ計算します。この二つの計算結果が一致することを確認します。ここで使うのは共通の秘密情報で、パスキーの公開鍵暗号とは違う仕組みです。

最初のQRコードが重要な理由

認証アプリを登録するとき、サービスはQRコードを表示することがあります。一般的なTOTPでは、QRコードに秘密情報やアカウントの識別名、コードの桁数、計算方法などの登録情報が含まれます。すべてのサービスが完全に同じ内容を使うわけではありません。QRを読み取った認証アプリは、その情報を登録して次のログインで使います。

このQRコードは、説明用のただの画像ではありません。本物の登録用QRを他人へ見せると、その人が同じ秘密情報を登録できる危険があります。パスワードを他人に送らないのと同じように、TOTPの共有秘密も守る必要があります。この記事に本物のQRやシークレット、実際の6桁コードは載せません。会社の設定画面のスクリーンショットを共有するときも、登録用QRが写っていないか注意します。

登録後、サービスがアプリに表示された確認コードの入力を求めるのは、双方が同じ秘密を使える状態かどうかを確認するためです。しかし登録が済んだからといって、スマートフォンをなくしても必ず復旧できるとは限りません。認証方法の登録と復旧手段の用意は、別の作業として考えます。

図解：二つの場所で同じ計算をする

sequenceDiagram
    participant U as 利用者
    participant S as ログインサービス
    participant A as スマホの認証アプリ
    S-->>U: 登録用のQRを表示
    U->>A: QRを読み取って登録
    Note over S,A: 同じ共有秘密を持つ
    A->>A: 秘密と現在時刻からコードを計算
    A-->>U: 数字を画面に表示
    U->>S: 数字を入力
    S->>S: 秘密と時刻から期待値を計算
    S-->>U: 一致と利用条件を確認

この図で注目したいのは、コード表示時にスマートフォンとサービスの通信が描かれていないことです。時刻と秘密が分かれば、それぞれの場所で計算できるためです。入力したときはサーバーとの通信が必要ですが、数字そのものを画面に出すためにネット接続が必要とは限りません。

なぜ数字は一定の間隔で変わる？

TOTPの標準を定めたRFC 6238は、時刻を一定の区間に分けて計算の入力にする方法を示しています。代表的な時間幅は30秒です。ただし、実際のサービスがどの桁数、どの時間幅、どのアルゴリズムを採用しているかは設定次第です。「どの認証アプリでも必ず6桁・30秒」とは言えません。

計算ではHMACという秘密鍵を使うメッセージ認証の仕組みを利用します。TOTPはHOTPという方式を土台にしており、HOTPが使うカウンターの代わりに、現在時刻から導く値を使うと理解できます。入力しやすい短い数字は元の計算結果を一定の規則で変換して得られます。数字が短いのでサーバー側では試行回数を適切に制限する必要があり、入力の失敗を何度も繰り返すことは避けます。

詳しく知りたい人にはRFC 6238のAlgorithm Requirementsが役立ちます。共有秘密と同じ時間の区間が必要だと説明しています。さらに土台の仕組みを知りたい場合はRFC 4226を読むと、HMACを用いるHOTPからTOTPへつながる関係を確かめられます。

一つ条件を変えたら：スマホの時刻がずれる

スマートフォンの時計が正しい時刻から大きくずれると、アプリが計算している区間とサーバー側の区間が一致しなくなる可能性があります。サービス側でわずかな時刻差を許容することはありますが、何秒まで許されるかは一律ではありません。コードが誤りだと表示されたら、即座にスマートフォンの設定を大きく変更するのではなく、安全に切り分ける必要があります。

まず登録しているサービス・アカウントの組を正しく選んでいるか確認します。次に、コードが切り替わった直後か、有効時間を過ぎていないかを見ます。その後、端末のOSで自動時刻設定が有効かを確認します。何度も連続入力してロックされるより、正しい順序で確かめた方が被害を減らせます。

flowchart TD
    A["コードが受け付けられない"] --> B{"正しいサービス名か"}
    B -->|"いいえ"| C["登録名を確認する"]
    B -->|"はい"| D{"有効時間内か"}
    D -->|"いいえ"| E["次のコードで試す"]
    D -->|"はい"| F["OSの時刻同期を確認"]
    F --> G{"解消しないか"}
    G -->|"はい"| H["サービスの公式復旧手順へ"]
    G -->|"いいえ"| I["通常のログインへ"]

図は確認の順番を示すもので、試行回数制限や企業のアカウント保護方針を無視するものではありません。管理者に連絡する必要がある環境では、その手順を優先します。端末の時計を故意にずらして実業務サービスの挙動を実験することはすすめません。

Google Authenticatorは機種変更できる？

Google AuthenticatorにはコードをGoogleアカウントに同期する機能があり、同期せずに使用する方法もあります。同期を利用しているかどうかで、機種変更の際の操作が異なります。同期先のアカウントが使えなくなることや、端末を紛失することも考え、サービスごとの復旧方法を確認しておきます。

Google公式ヘルプでは、オフラインでコードを生成できること、同期や手動移行、紛失時の扱い、時刻が正しいかの確認方法が説明されています。検索で見つけた古い手順では、現行アプリとメニューの名称が異なる場合があります。現在のバージョンで何ができるかを確認する根拠として公式資料を使います。

バックアップコードを発行できるサービスでは、認証アプリとは別に安全に保管します。復旧コードは普通のメモではなく、本人確認に使える秘密情報です。もし秘密のQRや登録キーが外部へ漏れた疑いがあるなら、その登録情報を無効にし、正規の手順で再登録する必要がある場合があります。

6桁コードのフィッシングへの限界

確認コードは短時間で変わりますが、偽サイトにその場で入力させる攻撃がなくなるわけではありません。攻撃者はログインの途中でコードを求め、本物のサービスへ転送できる場合があります。TOTPの「一度限り」という性質と、「誰にコードを渡してよいか」を技術的に結び付ける性質は別です。

NISTのSP 800-63Bでは手入力のOTPをフィッシング耐性のある方法として扱っていません。だからといってTOTPをやめるべきと短絡する必要はありません。パスワードだけより安全性を高める一方、重要度に応じてパスキーなど別の方式との比較が必要だという意味です。

仕事で使う際の運用

企業でTOTPを利用する場合、アプリ登録と再登録に誰が許可を出すか、端末の買い替えでどう本人確認するか、古い登録をどう無効化するかを決めます。本人が保管する秘密のバックアップをヘルプデスクが安易に要求したり、QRをメールで共有したりしてはいけません。日常の便利さと事故時の対応は両方設計する必要があります。

また、監視では失敗したログインが続いた場合に、ただ「利用者が入力を間違えた」と決めつけず、端末の時刻、登録したサービス、試行の発生時間、本人の申告を突き合わせます。調査に不要な実コードをログへ記録しないこと、個人情報をむやみに配布しないことも重要です。

確認しておきたい誤解

「コードが出るからサーバーの公開鍵を使っている」わけではありません。TOTPは共有秘密を使う方式です。「数字が6桁だから秘密そのものは6桁」でもありません。登録時の共有秘密は別の情報です。「スマートフォンにネットがないと使えない」も一般的には誤りです。コードの生成自体はオフラインで可能です。ただしサインイン先との通信、同期・移行などにはネット接続が関わります。

同じ6桁が出ても共有秘密を見せてよいわけではない

表示される数字が6桁でも、基になる共有秘密が6桁の数字そのものというわけではありません。長く保持する秘密と現在時刻を使い、入力しやすい短い数字に変換しているのです。短い数字を無制限に試せるサービスでは危険なので、サーバー側は試行回数や有効期限、再利用を適切に管理する必要があります。利用者が見るコード入力欄の裏側には、別の防御がいくつもあります。

同じ時刻、同じ秘密と計算条件を持つ認証アプリが二つあれば、同じ確認コードが表示される可能性があります。二つのスマホが通信しているわけではありません。正しい移行では役立つ性質ですが、他人に登録用QRを複製された場合にも同じ状態が起こり得ます。登録用QRをパスワードと同じくらい慎重に扱うべきなのは、このためです。

機種変更の前に確認したい順番

古いスマートフォンを初期化する前に、新しい端末で各サービスにログインできるか、バックアップコードや別の方法で戻れるかを確認します。Google Authenticatorでは同期と手動移行という方法がありますが、サービスごとに事情が異なります。同期があるからといって、すべての登録先の移行が保証されるわけではありません。新しい端末での確認が済むまでは、古い端末の情報を安易に消さない方が安全です。

スマートフォンを紛失したときは、コードが手元にない状態でどう本人確認できるかが問題になります。利用するサービスの公式回復手順を確認し、企業のアカウントなら管理者の再登録手続きに従います。復旧を急ぐ気持ちにつけ込み、偽サポートがバックアップコードを要求する場合も考えられます。秘密の値を他人へ渡す前に、連絡先が正規の窓口かを確認しましょう。

SMSの数字との違い

SMSで届く確認コードも一時的な数字ですが、TOTPとは生成と配送の方式が異なります。TOTPは認証アプリが共有秘密と時刻から計算するため、数字の表示自体にモバイル回線は必ずしも必要ありません。SMSはサービス側が生成した内容を通信回線経由で届ける方式が代表的で、受信できる状態が必要です。見た目の数字だけで同じ技術と考えないことが大切です。

一方、どちらも人が偽サイトの入力欄へ数字を渡してしまう可能性があります。認証アプリはSMSと異なる利点があるからといって、フィッシングを防ぐ仕組みまで自動的に備えるわけではありません。自分がアクセスしているサービスの正しさを確認し、重要な用途ではパスキーなどの方式も比較します。

ヘルプデスクでコードを聞く必要はない

利用者から「コードが使えない」と相談された場合、本物の6桁や登録QRをチャットで送ってもらう運用は避けます。サービス名、アカウントの選択、機種変更の有無、OSの時刻設定、止まった画面など、秘密以外の情報でも切り分けられることがあります。必要な場合は定められた本人確認のうえで再登録へ進みます。

RFC 6238はコードの計算方法を定めていますが、Google Authenticatorのメニュー名や同期の操作を定める文書ではありません。計算の仕組みはRFC 6238、端末移行や設定はGoogle公式ヘルプを読むと、規格と製品の案内を混同せずに済みます。技術を学ぶことは、秘密をむやみに集めずにサポートできることにもつながります。

まとめ

認証アプリの数字は、共有秘密と時刻を使った計算の結果です。登録用QRが機密情報になる理由、電波がなくても数字を出せる理由、時計がずれると失敗しやすい理由が一本の仕組みで説明できます。大事なのは6桁を覚えることより、共有秘密を守ること、正しいログイン先を確認すること、困ったときの復旧手段を確保することです。

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

• RFC 6238：TOTPの時刻・共有秘密・30秒間隔の標準的な扱いを確認。

• RFC 4226：HOTPとHMACがTOTPの計算の基礎になることを確認。

• Google Authenticator公式ヘルプ：コード表示、同期、端末移行、時刻不一致時の対応を確認。

• NIST SP 800-63B：OTPの有効期限、再利用防止、フィッシング耐性の限界を確認。

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