認証コード（ワンタイムパスワード）の仕組み・種類・導入判断のポイント

サービスにログイン認証を導入するとき、「ID・パスワードだけでいいのか」「コストはどのくらいかかるのか」「ユーザーが途中で諦めないか」という点が判断の難しいところです。

認証コード（ワンタイムパスワード）は、ログインや重要な手続きのたびに発行される使い捨てのパスワードで、ID・パスワードだけでは防ぎにくい不正ログインを構造的に防ぎます。4種類の配信方式があり、それぞれセキュリティ・コスト・ユーザー操作の面で特性が異なります。

この記事では、認証コードの仕組みと4種類の配信方式の比較・導入時に検討すべきコストとUXの課題・2025年時点のパスキー移行の動向を整理します。情シス・DX推進・開発部の担当者が、認証フローの設計や導入判断の材料として使えることを意識しました。

この記事が役立つ場面

認証コードの仕組み：5ステップで完結する

認証コードは、ID・パスワードによる「知識要素」に「所持要素（スマートフォン等）」を加えた多要素認証（MFA）の仕組みです。パスワードが外部に漏れても、スマートフォンに届いたコードがなければログインできません。

動作の流れはシンプルです。ユーザーがログインを開始すると、システムが4〜6桁のランダムコードを生成し、SMS・メール・音声などで送信します。ユーザーがコードを入力し、照合が一致すれば認証完了です。コードには有効期限（TTL）が設定されており、数十秒〜数分が実務上の一般的な設定範囲です。

鈴木 伸吾 (監修)

有効期限の設計がUXと運用コストに直結します。短すぎると入力が間に合わず再送リクエストが急増し、配信コストと問い合わせ件数が増えます。長すぎるとセキュリティリスクが上がります。「数十秒〜3分」の範囲で実機検証しながら決めるのが現実的です。

なぜ認証コードが必要か：不正ログイン被害の現状

IPA(情報処理推進機構)の「不正ログインに関する相談件数の推移」は、2025年第3四半期（7〜9月）で387件に達し、前四半期比44.9%増を記録しています。2025年7月の月間144件は過去最多です。

主な手口はリスト型攻撃と言われる、一度流出したパスワードをさまざまなサービスに試すものです。多くのユーザーがパスワードを使い回しているため、1件の漏洩が連鎖的な被害につながります。認証コードはこの連鎖を「パスワードが漏れても認証コードがなければ入れない」という構造で断ち切ります。

Microsoftの調査によれば、多要素認証を導入することでアカウント侵害リスクを99.9%以上削減できるとされています。認証コードは「追加すれば安心」という次元ではなく、現在の標準的なセキュリティ設計の前提になっています。

4種類の認証方式を比較する

主な配信方式はSMS・メール・認証アプリ（TOTP）・IVR（電話認証）の4種類です。選定の軸は「セキュリティ」「ユーザーの利便性」「運用コスト」の3点です。

▶ NTT CPaaSではSMS・IVR・メール・電話認証の4方式すべてをAPIで提供しています。

SMS：最も普及している基本手段

専用アプリのインストールや登録作業は不要で、携帯電話番号さえ持っていればほぼすべての端末で使えます。会員登録時の「電話番号確認」と「本人認証」を同時に行えるため、EC・金融・SaaSで広く採用されています。

注意点はSIMスワップ攻撃（電話番号の乗っ取り）のリスクと、海外ローミング時の遅延・不達です。また、国際接続網（海外ルート）経由の送信基盤を使っている場合、到達率が80%前後に落ちることがあります。到達率99%を超える国内キャリア直収接続のサービスを選ぶことが到達率維持の基本です。

海外ローミング時などSMSが届かない場合に備え、IVR認証やメール認証へフォールバック設計を組み込むのが実務上の標準となっています。

関連記事：SMSが届かない固定電話での認証時に、企業ができる対処法

メール：補完手段として有効、単独使用は避ける

既存システムへの組み込みが最も容易で、コストも最小です。ただし米国国立標準技術研究所（NIST SP 800-63）のガイドラインでは、メール認証の単独利用は非推奨とされています。対象サービスとメールアカウントのパスワードが共通の場合、メール自体が乗っ取られると認証コードも盗まれるリスクがあるためです。そのためSMSや認証アプリの補完手段として位置づけるのが適切です。

認証アプリ（TOTP）：セキュリティを重視する場合の選択肢

Google AuthenticatorやMicrosoft Authenticatorなどを使い、30秒ごとに自動更新されるコードをアプリへ表示させる方式です。通信不要・送信費用なし・コードが短時間で切り替わるという特性があり、セキュリティ強度は4方式中最高水準です。

ハードルは、ユーザーがアプリをインストールし、設定をする必要がある点です。導入時に手間がかかるだけではなく、機種変更時の認証設定の引き継ぎでトラブルが出やすいため、移行手順の案内とサポート体制の整備が運用上の重要ポイントです。

IVR認証（電話認証）：固定電話・SMS不達への対応と高齢者層へのフォールバック

指定番号へ自動発信し、合成音声で認証コードを読み上げます。固定電話でも使えるため、SMS受信ができないユーザー層への対応手段として、また「SMSが届かなかった場合の自動切替先」として設計に組み込まれるケースが多いです。

コードが画面テキストとして残らない特性から、視覚的な盗み見リスクを抑えやすい点も特徴である一方、ユーザーは認証コードを記憶したり、メモをとる必要があります。誤って記憶してしまったり、忘れてしまった時のために、繰り返し認証コードを確認できる設計が必要になります。

また電車内など電話を受けたくない状況も考慮すると、標準にするのではなく、SMSの補完手段として位置づけるのがおすすめです。

導入時に検討すべき課題と対処法

認証コードの導入を検討するとき、実務上よく問題になる3点を整理します。

コスト：従量課金が積み上がる

SMS・IVR・メールはいずれも送信のたびに通信費が発生します。ユーザー数が増えると費用が積み上がるため、認証アプリ（TOTP）の活用・リスクベース認証の導入（高リスクアクセス時のみ認証を求める）・APIプラットフォームの活用（自前インフラ構築より安価）の3つが代表的なコスト最適化策です。

UX：認証ステップが増えると離脱する

ログイン・購入フローに認証コードのステップが加わると、ECではカゴ落ちが発生する場合があります。「このデバイスを信頼する」設定（一度認証した端末では一定期間再認証を省略）・リスクベース認証（平常アクセスはスキップ、不審時のみ認証）・認証コード自動入力（iOS・AndroidのAutoFill対応）の3つが離脱を抑える主な設計手法です。

サポート負荷：「コードが届かない」問い合わせが増える

導入後に増えやすい問い合わせが「コードが届かない」「機種変更後にログインできない」の2類型です。受信設定確認ガイドの設置・バックアップコード発行機能の用意・SMS不達時のフォールバック設計（IVR自動切替）の3つを実装することで、問い合わせ件数を構造的に減らせます。

2025年の動向：パスキー（FIDO2）との関係

2025年時点で、次世代認証規格であるパスキー（FIDO2）への移行が加速しています。パスキーはパスワードも認証コードの入力も不要にする「パスワードレス認証」で、フィッシングサイトでは認証が失敗するという構造的な耐性を持ちます。

IPA（情報処理推進機構）は2025年8月、多要素認証（MFA）の設定と並んでパスキーの利用を推奨しています。ただし、対応デバイス・対応サービスの整備が前提となるため、全ユーザーに即時移行できる状況ではありません。

現実的な移行戦略は「まず認証コードで多要素認証の基盤を整え、ユーザーのデバイス環境が整い次第パスキーへ段階的に移行する」アプローチです。2025年時点では認証コードを基本に置きつつ、パスキーを選択肢として提供するハイブリッド設計が主流になっています。

NTT CPaaSで実現できること

NTT CPaaSは、SMS・メール・音声（IVR）・着信番号認証をAPIで統合して提供するプラットフォームです。OTP（ワンタイムパスワード）の生成・照合APIは追加料金なしで提供されており、自社でゼロから認証ロジックを実装する必要がありません。

REST API連携で既存システムに後付け実装でき、複数チャネルを1つのAPIで管理できるためフォールバック設計の工数を最小化できます。10年連続SMS送信市場シェアNo.1のNTTグループが運営しており、国内キャリア直収接続・日本語専任サポートが揃っています。

サービス

▶ 60日間の無料トライアルで機能と到達率を確認できます

認証コードの送信・OTP（ワンタイムパスワード）照合APIの動作確認、自社システムへの組み込み検証、認証フロー設計の相談まで対応しています。

まとめ：認証コード導入の判断ポイント

認証コードは、不正ログインを構造的に防ぐための現時点での標準的な設計手段です。SMS・メール・認証アプリ・IVR認証と様々な方式がありますが、その選択はセキュリティ要件・ユーザー層・コストの3軸で判断します。

SMSを基本にIVR認証のフォールバックを組み込む設計が、多くのサービスで費用対効果のバランスが取れた一般的な構成です。またコスト最適化にはリスクベース認証とAPI型プラットフォームの活用が有効です。

最もセキュリティが強固なパスキーへの移行も視野に入れながら、まず認証コードで多要素認証の基盤を整えるのが現実的な進め方です。

よくある質問