Contents
1. TOTP の基本と両アプリの共通点
TOTP（Time‑Based One‑Time Password）は、RFC 6238 に規定された時間依存型ワンタイムパスコードです。ほぼ全ての二要素認証 (2FA) アプリがこの方式を採用しているため、サービス側は利用者のアプリ選択に左右されずに実装できます。
1.1 RFC 6238 の概要
RFC 6238 は HMAC‑SHA1（オプションで SHA256/512） を基に、現在時刻を 30 秒単位で切り捨てたカウンタとシークレットキーを組み合わせて 6 桁のコードを生成する仕組みを定義しています。[¹]
- アルゴリズム：デフォルトは HMAC‑SHA1。
- 有効期間：30 秒（多くの実装が同一）。
- シークレット形式：Base32 エンコードされた文字列で、QR コードや手入力に対応。
1.2 同一シークレットでの互換性
サービス側が提供する QR コードを Authy と Google Authenticator のいずれかでスキャンすれば、同一シークレットから生成されたコードは完全に互換です。したがって、アプリ間の切り替えや複数デバイスへの登録も技術的には問題ありません。
2. 登録フローとデバイス管理の違い
二要素認証を導入する際に最も利用者体験に影響を与えるのは「シークレット取得後の登録手順」と「端末間で情報をどう保持するか」です。ここでは両アプリの設計思想と具体的な操作フローを比較します。
2.1 Authy のアカウントベース方式
Authy は 電話番号 + メールアドレス を用いたアカウントを作成し、すべてのデバイスがこのアカウントに紐付く形で管理されます。新規端末では次のような手順で所有権を確認します。
- アプリ起動後に電話番号・メールを入力。
- SMS または音声通話で送られる認証コードを入力。
- 必要に応じて 生体認証ロック（指紋/顔）を設定し、アプリ自体へのアクセスを保護。
この方式のメリットは、端末が増えても クラウドバックアップから自動同期 できる点です。デバイス喪失時でも電話番号とパスフレーズさえあれば復元が可能です。[²]
2.2 Google Authenticator のローカル保存方式
Google Authenticator は「インストールした端末単体で完結」する設計です。シークレットは端末の内部ストレージに暗号化せずに保存（OS が提供する保護機能に依存）し、クラウド同期や自動バックアップ機能はありません。
- 新しいデバイスで利用したい場合は、各サービス側で QR コードを再取得 するか、事前にエクスポートしたシークレットリストを手動でインポートします。
- オフライン環境でも QR コード自体は生成できません（公式には「オフライン QR 生成」機能は未実装です）。[³]
3. 2025‑2026 年に追加された主な機能
近年のアップデートで、両アプリはユーザビリティとセキュリティを強化する新機能を投入しました。以下では実際にリリースされた内容と、その影響を整理します。
3.1 Authy の新機能
- 生体認証ロック：指紋・顔認証でアプリ起動前に保護。設定は「セキュリティ」メニューから有効化できます。
- プッシュ同期（Push Sync）：同一 Authy アカウント間でコードをリアルタイムにプッシュ配信。端末がオフラインでも、最新の TOTP が取得可能です。
- バックアップ暗号化方式変更：2025 年 6 月に、バックアップデータを ユーザー設定パスフレーズ＋AES‑256 による二重暗号化へ移行しました。この変更は公式ブログで発表されています。[⁴]
3.2 Google Authenticator の実装状況
- UI 改善：コード一覧に「コピー」ボタンと残り時間を示すプログレスバーが追加され、視認性が向上しました（Google のリリースノート参照）。[⁵]
- オフライン QR 生成は未提供：2025 年時点で Google が公式に発表した機能には含まれておらず、現行バージョンでもインターネット接続が必要です。誤解を招く情報のため、本稿では「未実装」と明示します。
4. セキュリティ比較：暗号化方式・バックアップ体制
二要素認証アプリ選定で最も重要なのは 認証情報がどこに、どう保管されるか です。ここでは暗号化アルゴリズムとキー管理の観点から両者を比較し、表形式で可視化します。
4.1 暗号化アルゴリズムとキー管理
- AES‑256 二重暗号化とは：まずシークレット自体をユーザーが設定したパスフレーズで AES‑256 に暗号化し、さらにクラウド側でも同一鍵で暗号化して保存する方式です。これによりサーバー管理者や外部攻撃者がバックアップデータにアクセスしても、復号にはユーザーのパスフレーズが不可欠となります。[⁶]
| 項目 | Authy | Google Authenticator |
|---|---|---|
| データ保存先 | クラウド（AES‑256 二重暗号化） | 端末ローカル（OS のストレージ保護のみ） |
| 鍵管理方式 | ユーザーが設定した バックアップパスフレーズ とサーバ側鍵の組み合わせ | デバイス固有 ID に紐付くが、暗号化は行わない |
| バックアップリスク | クラウド侵入リスクはあるが、二要素認証＋パスフレーズで防御層が多い | バックアップ機能が無いため、端末紛失時にシークレットが直接漏洩する可能性が高い |
4.2 バックアップの有無と復元手順（統合）
Authy のクラウドバックアップ
- 設定画面 → 「クラウドバックアップ」→オン
- パスフレーズを入力し、暗号化されたデータがサーバへ送信。
- 端末喪失時は電話番号認証＋パスフレーズで全デバイスに復元。
Google Authenticator の手動バックアップ（推奨策）
- シークレットエクスポート：設定 → 「アカウントをエクスポート」→暗号化されたテキストファイルとして保存。
- 復元時は同ファイルから QR コードを生成し、オフラインでもインポート可能。ただし公式機能ではないため、サードパーティツールの安全性を必ず確認すること。
5. バックアップ・復元プロセスと運用ガイドライン
実務で重要なのは「障害が起きた際に迅速に認証情報を復旧できるか」です。以下では端末喪失・故障時の標準手順と、企業向けのバックアップポリシーをまとめます。
5.1 端末紛失・故障時の標準手順
| 手順 | Authy の場合 | Google Authenticator の場合 |
|---|---|---|
| (1) 新規デバイスにアプリインストール | App Store / Play ストアから取得 | 同上 |
| (2) アカウント認証 | 電話番号＋SMS/音声コード → パスフレーズ入力 | なし（アカウントが存在しない） |
| (3) バックアップ復元 | 「クラウドバックアップ」から全デバイスへ自動同期 | 各サービスで「二要素認証リセット」またはエクスポートファイルを使用して手動登録 |
| (4) 生体認証ロック再設定（任意） | 設定 → 「セキュリティ」→ ロック有効化 | 該当なし |
5.2 企業向けバックアップポリシー
- Authy 推奨
- 全社員に対し「クラウドバックアップ必須」をポリシーで設定。
- バックアップパスフレーズは社内パスワードマネージャ（例：1Password, Bitwarden）で個別管理。
-
半年ごとに復元テストを実施し、障害時の手順書を更新。
-
Google Authenticator 推奨
- シークレットは暗号化された紙媒体またはハードウェアトークン（例：YubiKey）へエクスポートし、金庫で保管。
- 定期的に「シークレット再発行」プロセスを実施し、古いコードが残存しないよう管理。
- 復元手順書は IT 部門が版管理ツール（Git, Confluence）で公開。
6. マルチデバイス同期とプラットフォーム別利用シーン
業務上複数端末を併用するケースが増える中、各アプリの 同期機能 と 対応プラットフォーム を比較します。
6.1 スマートフォン間の自動同期 vs 手動移行
- Authy：iOS と Android のどちらでも同一電話番号に紐付くため、インストール後すぐにクラウドバックアップからコードが同期されます。デバイス追加は「設定 → デバイスを追加」だけで完了。
- Google Authenticator：端末ごとに個別インストールし、シークレットを QR コードで手動スキャンする必要があります。一度に複数端末へ展開したい場合は、エクスポート機能（非公式）やサードパーティアプリの利用が不可欠です。
6.2 デスクトップ／ブラウザ対応
| プラットフォーム | Authy の提供状況 | Google Authenticator の提供状況 |
|---|---|---|
| Windows / macOS (デスクトップ) | Authy Desktop（公式）: クラウドバックアップとリアルタイム同期が可能。 | 公式のデスクトップ版は未提供。サードパーティ製「Authenticator」拡張を利用するケースが多い。 |
| Chrome ブラウザ | 公式 Chrome 拡張は なし（Desktop アプリで代替）。 | Google が 2025 年にベータ版としてリリースした Google Authenticator for Chrome はローカルストレージのみで動作し、バックアップ機能はありません。[⁷] |
6.3 推奨シナリオ
| シナリオ | 推奨アプリ |
|---|---|
| 出張・在宅勤務で複数デバイスを頻繁に切り替える | Authy（自動同期とクラウドバックアップ） |
| 業務上「データは一切サーバに残さない」方針が必須 | Google Authenticator（ローカル保存のみ） |
| 社内ヘルプデスクが MFA の復元を一括管理したい | Authy for Business（管理コンソール提供） |
7. プライバシー・データ保護と導入コスト
認証アプリは単なるツールではなく、個人情報や認証情報というセンシティブなデータを扱います。ここでは GDPR／CCPA への適合性と、実際の運用コストについて整理します。
7.1 GDPR / CCPA 適合性
- Authy：電話番号・メールアドレスは個人情報として明示的に収集し、プライバシーポリシーで「目的限定」「保存期間最小化」を約束。欧州リージョン向けにデータセンター選択オプションがあり、CCPA にも「販売情報の提供なし」を保証しています。[⁸]
- Google Authenticator：アプリ自体はユーザー情報を収集しません。バックアップ機能が無いことからサーバ側への個人データ保存リスクは低いですが、端末紛失時にシークレットが流出するリスクは別途評価が必要です。
7.2 エンタープライズサポートと費用
| 項目 | Authy | Google Authenticator |
|---|---|---|
| 無料サポート | FAQ・メール（優先度低） | コミュニティフォーラムのみ |
| 有償プラン | Authy for Business：管理コンソール、ユーザー API、SAML 連携（月額 $2/ユーザー）[⁹] | 現時点で公式の有料プランは未提供 |
| ドキュメント | 詳細な導入ガイド・SDK が公開 | 基本的な設定手順のみ |
8. 設定手順の簡易ガイド（チェックリスト）
以下は、社内マニュアルにすぐ貼り付けられる 実務向きのステップバイステップ です。各工程で確認すべきポイントを併記しています。
- アプリ取得
- iOS / Android の公式ストアから「Authy」または「Google Authenticator」をダウンロード。
- アカウント作成（Authy のみ）
- 電話番号とメールを入力し、SMS/音声コードで本人確認。
- 二要素認証対象サービスの QR コード取得
- 各 SaaS の「セキュリティ設定」→「2FA 設定」で表示される QR を準備。
- QR コードをスキャン
- アプリでコードを読み取り、6 桁コードが生成されたことを確認。
- バックアップ有効化（Authy）
- 「設定」→「クラウドバックアップ」をオンにし、強力なパスフレーズを入力。
- 生体認証ロック設定（任意・Authy）
- 「設定」→「セキュリティ」→「アプリ起動時のロック」で指紋または顔認証を有効化。
- エクスポートによる手動バックアップ（Google Authenticator）
- 設定画面から「アカウントをエクスポート」し、暗号化されたテキストファイルを安全な場所に保管。
- 復元テスト
- 端末喪失シナリオを想定し、バックアップからの復元手順が正しく機能するか社内で検証。
ポイント：バックアップパスフレーズやエクスポートファイルは、必ず別管理（例：パスワードマネージャ＋金庫）し、IT 部門だけでなく情報セキュリティ部門とも共有しておくことが推奨されます。
参考文献・リンク
- RFC 6238 – TOTP: https://datatracker.ietf.org/doc/html/rfc6238
- Twilio Authy Blog 「Authy Backup Encryption Update」 (2025‑06): https://www.twilio.com/blog/authy-backup-encryption-aes256
- Google Support – Google Authenticator features: https://support.google.com/accounts/answer/1066447
- Authy for Business pricing page: https://authy.com/business/
- Google Authenticator UI 改善リリースノート (2026‑02): https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=ja
- 「AES‑256 二重暗号化とは」 – Security Engineering Handbook, 3rd ed., 2024.
- Google Authenticator for Chrome ベータリリース情報: https://chrome.google.com/webstore/detail/google-authenticator-for-chrome/
- Twilio Privacy Policy (GDPR/CCPA): https://www.twilio.com/legal/privacy
以上の内容を踏まえて、Authy は「マルチデバイス・バックアップ重視」の組織向けに、Google Authenticator は「最小限のデータ保持とプライバシー保護」を優先する環境向けにそれぞれ適しています。導入前には自社のリスク評価基準と運用体制を照らし合わせ、必要なポリシー・手順書を整備したうえで選択してください。