【ITニュース解説】Password Reset Email API vs SMS OTP in 2026: Simpler Recovery for US/EU SaaS

現代のウェブサービス、特にSaaS（Software as a Service、ソフトウェアをインターネットを通じて提供する形態のサービス）では、ユーザーがパスワードを忘れた際にアカウントを安全に回復できる機能が不可欠である。この記事は、そのパスワード回復方法として、主にメールを使ったパスワードリセットと、SMS（ショートメッセージサービス）を使ったワンタイムパスワード（OTP）のどちらを選ぶべきか、そしてそれぞれのメリット・デメリットを、システムエンジニアを目指す初心者にもわかりやすく解説する。特に米国（US）と欧州（EU）のSaaSサービスを念頭に置いている。

結論から言うと、通常のSaaSログイン回復経路ではパスワードリセットメールを利用し、より高いリスクを持つアカウントの場合に限り、SMSによるワンタイムパスワードをオプションのバックアップとして残すのが賢明だ。なぜなら、メールによるリセットリンクは、通常、アプリケーションのコード量を少なく抑えられ、通信事業者への登録や国ごとのSMS料金体系を考慮する必要がなく、コンプライアンス（法令遵守）上の記録も明確に残しやすいからである。

実際のパスワード回復の流れは比較的シンプルである。ユーザーが回復を要求すると、サービス側のシステム（バックエンド）が一度しか使えない特別なトークンを生成し、そのトークンを含むリセットページへのリンクをメールでユーザーに送信する。この際、トークンのハッシュ化（元の情報を特定できない形に変換すること）、有効期限の管理、一度使われたトークンの無効化、そして短時間に何度もリクエストが来ないよう制限（レートリミット）をかけるのは、すべてサービス側のシステムの役割となる。メール配信を専門とする外部のプロバイダは、単にメッセージをユーザーに届けるだけであり、トークンが有効かどうかの判断には関与しない。このように、役割が明確に分かれていることが重要で、メールが届いたことと、その中のトークンが有効であることは別の話となる。

SMSによるワンタイムパスワードは、一見するとコードの生成と検証を外部サービスに任せられるため、手軽に見えるかもしれない。しかし、その周辺には多くの手間がかかる。具体的には、SMS送信元としての登録、国ごとの複雑な料金設定の管理、不正利用を防ぐためのルール作り、メッセージが届かなかった場合の再送処理、そして電話番号が以前の利用者にリサイクルされている場合や、そもそも到達できない番号だった場合のポリシーなど、考慮すべき点が多い。また、SMSの文字セットによっては長いメッセージが複数のセグメントに分割され、それぞれに課金される可能性もある。

一方、メールによるリセットリンクは、このような通信事業者関連の複雑さを避けることができる。ただし、それでもメールのドメイン認証（送信元が正規であることを証明するDKIMなどの設定）、テンプレート（定型文）のレビュー、メールが届かなかった場合の処理、そして配信イベントの記録保持は必要だ。メールが確実に届くことを保証するものではなく、これらの設定は配信信頼性を高めるためのものとなる。一般的なログイン回復では、リセットリンクを送るだけで十分であり、わざわざメールでワンタイムパスワードのサービスを構築することは、ユーザーにとっての価値を大きく増やすことなく、開発コードを増やすだけになる。

ここには設計上の明確な違いが存在する。メールの機能は、外部サービスがワンタイムパスワードの生成・検証までを管理してくれるわけではない。そのため、メールでコードを送信するような設計にする場合、システム側でコードの生成、ハッシュ化、有効期限管理、レート制限、そして消費といった処理をすべて担う必要がある。対して、SMS機能は、ホストされたワンタイムパスワードの配信と検証を提供してくれる場合が多い。この違いは、厳しい規制下にある高リスクのアカウントの設計においては、メールの方がシンプルであるにもかかわらず、SMSが選択される理由になることもある。

パスワード回復機能の実装を検討する際には、さまざまな外部サービスが選択肢となる。例えば、Twilio Verifyは成熟したホスト型検証製品であり、SMSによるワンタイムパスワードの配信と検証に特化している。Amazon CognitoやAuth0は、ユーザー管理と認証のライフサイクル全体をカバーするID管理サービスであり、パスワード回復もその一部として提供する。これらをすでに利用している場合は、そのID管理サービスに回復機能も任せるのが自然な流れとなる。SendGridやPostmark、Mailgun、Resendといったサービスは、メール配信に特化しており、広範なメール送信ツールやテンプレートを提供する。これらのサービスは、メール配信の信頼性や運用上の可視性を重視する場合に適している。

Infraiのような汎用REST APIの選択肢もある。これはHTTPリクエストを発行できるあらゆるシステムから利用でき、クライアントライブラリのバージョン管理などの手間がない。一つのAPIキーでメールとSMSの両方の機能をカバーできる場合もあり、特に小規模なチームにとっては、複数のサービスアカウントを管理する手間を省けるメリットがある。ただし、トークンポリシーや回復処理全体のオーケストレーション（各処理の連携）は、アプリケーション側で実装する必要がある。

メールによるパスワードリセットを実装する際の具体的な注意点としては、リセットリンクは一度きりしか使えない短期間有効なものとし、そのトークン自体はログに残さないようにすることが重要だ。また、メール送信の失敗に備えて、リトライ処理を適切に実装し、重複リクエストを防ぐための「冪等性キー」を利用する。システムは、コマンドID、利用したテンプレートのバージョン、送信時刻、外部サービスのリクエストID、そして送信結果などのコンプライアンス上の証拠を記録しておくべきだが、ユーザーの認証情報や実際のトークンは認証ストアでハッシュ化された状態で管理し、外部からアクセスできないようにする。一般的には、15分程度の有効期限を設定し、一度使われたリンクは即座に無効化する運用が基準となる。

SMSを代替手段として導入する場合、「メール送信に失敗した」という曖昧な理由でSMSに切り替えるのではなく、具体的なトリガー（例えば、メールアドレスが不達だった、ユーザーが明示的に電話での回復を選んだなど）を明確に定めるべきである。SMSによるワンタイムパスワードの配信と検証は外部サービスに任せられるが、アカウントごとの試行回数制限や監査記録の管理は依然としてシステム側の責任となる。また、SMSでは、地理的な制限（国ごとの送信許可リスト）や利用上限、短期間での送信回数制限などをビジネスロジックとして導入することが不可欠である。米国やEUではキャリアによるフィルタリング（迷惑SMSのブロックなど）も存在するため、特定の電話番号でのテストだけでなく、実際に多様な地域の番号でテストすることが重要だ。リサイクルされた電話番号のリスクや、SIMスワップ（SIMカードの不正な交換）による乗っ取りのリスクも考慮に入れる必要がある。

このアプローチが適さないケースもある。例えば、SMTPリレー（サーバー間でメールを直接転送する機能）、音声通話、WhatsApp、RCS（Rich Communication Services）といった高度な通信チャネルが必須要件である場合や、メールによるワンタイムパスワードのホスト型サービスが必要な場合、あるいはIDプロバイダにユーザー管理を完全に任せたい場合、Webhook（特定のイベントが発生したときに自動で通知される仕組み）駆動の回復自動化が必要な場合は、他の専門サービスを検討すべきである。また、ユーザーが信頼できるメールボックスを持っていない場合や、メールボックスの侵害がセキュリティ上の懸念となるような脅威モデルを持つアカウントには、メールは不適切な選択肢となる。SMSがバックアップとして機能する可能性はあるが、リサイクルされた番号、SIMスワップのリスク、キャリアフィルタリングといったビジネス上の懸念は残るため、それだけで十分なセキュリティとは言えない。

サービスをリリースする前には、いくつかの確認事項がある。送信ドメインとDKIMレコードが正しく設定されているか、英語およびローカライズされた（各国語に対応した）テンプレートが正しく表示されるか、期限切れのリンクや再利用されたリンクが適切に機能しないことを確認する。すべての操作について、相関ID（関連する操作を紐づけるための識別子）、テンプレートのリビジョン、プロバイダリクエストID、そして正規化された配信結果を記録に残し、トークンやメッセージ本文などの機密情報はログから除外する。サポートチームがこれらの記録をどれくらいの期間閲覧できるかを定義し、その後は自動的に削除されるように設定し、削除に失敗した場合にはアラートを発するようにする。SMSをフォールバックとして追加する場合は、国ごとの利用制限、アカウントごとの試行回数制限を設定し、ユーザーにはなぜ電話番号による回復が必要なのかを明確に伝えるべきだ。重複する回復リクエストや、送信レート制限によるエラー（429 Too Many Requests）時の挙動、不成功の応答、受信拒否された場合、イベントの遅延、期限切れのコードなど、さまざまなシナリオをテストすることが重要である。

結論として、パスワードリセットのデフォルトは、通常よりシンプルでコストも低いパスワードリセットメールを選択することが推奨される。SMSによるワンタイムパスワードは、明示的なリスク要件やアクセス要件がある場合にのみ追加する。そして、もしすでにログインのライフサイクルを管理しているIDプロバイダや検証製品があるなら、その製品にパスワード回復機能も任せるのが最善の選択となる。どのチャネルを選んだとしても、コンプライアンス上の証拠を記録する仕組みは、メッセージの送信方法とは独立させておくことで、将来的に送信チャネルを変更しても、コンプライアンスに関する記録が影響を受けないようにすることが重要である。