【ITニュース解説】How to Check That Your OTP SMS and Emails Actually Arrive (Synthetic Monitoring in CI)

多くのWebサービスやアプリケーションでは、ユーザーのセキュリティを確保するため、ログイン時や重要な取引の際に「ワンタイムパスワード（OTP）」をSMSやメールで送信し、本人確認を行う仕組みが使われている。システムエンジニアにとって、このOTPが確実にユーザーの手元に届くことは、サービスが正常に機能し、ユーザーがスムーズに利用できるための非常に重要な要素である。しかし、このOTPの配送には、一見するとシステム上は問題がないように見えても、実際にはユーザーに届いていないという、見落としがちな落とし穴が存在する。

例えば、システムの稼働状況を監視するツールが、ログインAPIが「200 OK」（正常終了）という応答を返していると報告し、SMS配信サービスプロバイダの管理画面でもメッセージが「送信済み」と表示されているとする。これは、システム的にはOTPが正常に送信されたと判断される状況である。だが、現実にはユーザーが「OTPが届かないためログインできない」と困っているケースが頻繁に発生し、サービスへの不満や信頼の低下につながってしまうのだ。

このような「システムは正常と判断しているが、ユーザーには届いていない」というギャップは、さまざまな原因で発生する。具体的な例としては、以下のような状況が考えられる。SMSの送信元として表示されるIDが、有効期限切れになっていたり、送信するメールのテンプレートや内容が変更されたことで、受信側のメールサービスがそれをスパムメールだと判断し、迷惑メールフォルダに振り分けてしまったりするケースがある。また、特定の通信キャリアが、不正なメッセージと判断して、企業からのSMSをひそかにブロックしている可能性や、SMSやメールの配信プロバイダのシステム内部で障害が発生しているにもかかわらず、APIは「送信成功」という誤った応答を返してしまうといったケースも存在する。

このような問題は、通常のシステム稼働監視や、配信プロバイダが提供する「配信レポート」だけでは検出が難しい。なぜなら、配信レポート自体も、検証したい対象と同じシステム（配信プロバイダ）から出力される情報であり、それが本当に最終的なユーザーに届いているかを独立した立場で確認する手段にはなりにくいからである。OTPが届かないことは、ユーザーのサービス利用を直接妨げ、顧客満足度の低下やビジネス機会の損失に直結するため、その影響は非常に大きいと言える。

この見えない問題を解決するための信頼できる方法が、「シンセティックモニタリング（Synthetic Monitoring）」である。シンセティックモニタリングとは、実際のユーザーが行う操作を模倣して、外部からシステムを監視する手法を指す。今回のOTP配送のケースで言えば、システム側が「送信した」と判断するだけでなく、「実際にOTPが届いたかどうか」を外部から確認する仕組みだ。具体的には、定期的に、自分が管理している本物の電話番号やメールアドレスに対して、テスト目的でOTPの送信をトリガーし、実際にそれが届くかどうか、またどれくらいの速さで届くかを計測する。これにより、実際のユーザー体験に近い形でOTP配送の健全性をチェックできるため、前述したような「システムは正常と判断しているが、ユーザーには届いていない」というギャップを発見することが可能になる。

シンセティックモニタリングを実現するためのサービスの一つに「otp-watch」というAPIがある。このサービスを利用したOTP配送チェックの具体的な手順は次の通りだ。

まず、APIキーの取得を行う。otp-watchサービスにアカウントを登録し、curlコマンドと呼ばれるツールを使ってAPIキーと呼ばれる特別な文字列を取得する。このAPIキーは、otp-watchのサービスを利用するための「パスポート」のようなものであり、以後の操作で認証のために必要となる。

次に、チェックの開始とターゲットの取得を行う。取得したAPIキーを使ってotp-watchにリクエストを送信し、「OTPの配送チェックを開始したい」と伝える。この際、「メール」または「SMS」のどちらでチェックしたいかを指定する。すると、otp-watchは、そのチェック専用の一時的なメールアドレス（例：0a625bab1a59@receivemail.dev）や、テスト用の物理的な携帯電話番号（英国のSIMカードを持つ番号など）を「ターゲット」として提供してくれる。このターゲットこそが、自分のアプリケーションからOTPを送信する先の情報となる。

そして、最も重要なステップが、アプリケーションからのOTP送信と結果のポーリングである。otp-watchから提供されたターゲット（メールアドレスや電話番号）に向けて、自分のアプリケーションから実際にOTPを送信する。この送信は、ユーザーが普段OTPをリクエストする際に利用するのと同じコードパス（処理経路）を通るように設計する。例えば、アプリケーションのテスト用エンドポイントを呼び出す、あるいは新規登録プロセスをシミュレートするなど、方法はさまざまだ。OTPを送信した後、otp-watchに対して定期的に「そのターゲットにOTPは届いたか？」と問い合わせる（これを「ポーリング」と呼ぶ）。otp-watchは、OTPが届いた場合は「received」（受信済み）というステータスと、送信から受信までの時間（レイテンシ）をミリ秒単位で返してくれる。もし、指定した時間（例えば120秒）が経過しても届かなかった場合は、「timed_out」（タイムアウト）というステータスを返す。

これらのOTP配送チェックの手順は、手動で行うことも可能だが、より効率的で信頼性の高い運用のためには、自動化が不可欠である。そこで、ソフトウェア開発の現場で広く使われている「CI/CD（継続的インテグレーション／継続的デリバリー）」パイプラインや、定期的に処理を実行する「Cronジョブ」にこのチェックを組み込むと非常に有効だ。例えば、GitHub ActionsやGitLab CIといったCI/CDツールの中に、シェルスクリプトとして上記のAPI呼び出しを記述する。これにより、15分ごとや30分ごとといった決まった間隔で、OTP配送チェックが自動的に実行されるようになる。もしチェックが「timed_out」で失敗した場合、CI/CDツールはそれが異常であると判断し、設定されたアラート機能を通じて開発チームに通知を発する。これにより、ユーザーがOTPの不達に気づいて問い合わせる前に、開発チームが問題を検知し、対応を開始できるようになる。これは、サービスの信頼性を高め、ユーザー体験を大幅に向上させる上で非常に大きなメリットとなる。

otp-watchのサービス利用には費用がかかる場合もある。メールアドレスへのOTPチェックは無料で提供されることが多いが、SMSへのOTPチェックは、初回無料枠の後に有料プランへの移行が必要となることがある。特に、定期的なSMSチェックを行う場合は、専用のテスト用電話番号を一定期間借り上げるような月額プランが用意されている場合が多い。一つの番号を再利用することで、チェックごとに新しい番号をレンタルする手間やコストを省き、継続的な監視を現実的にしている。

このシンセティックモニタリングは、万能な解決策というわけではない。プロバイダが提供する大規模な配信レポートや、国ごとの詳細な監視を完全に置き換えるものではない。しかし、最も重要なのは、「本当に1つのテスト経路でOTPが届くのかどうか」という基本的な部分を、独立した視点から安価に、かつ信頼性高く確認できる点にある。多くのシステムが抱える「見えないギャップ」を埋めるための、非常に有効な「独立した信号」として機能するのである。

システムエンジニアとして、ユーザーが円滑にサービスを利用できる環境を構築・維持することは重要な責務である。OTPの確実な配送は、その基盤の一つと言える。シンセティックモニタリングを活用することで、既存の監視体制では見逃しがちなOTP配送の問題を早期に発見し、ユーザーが困る前に先回りして解決することが可能になる。これは、システムの安定性を高め、ユーザーからの信頼を勝ち取るための、賢明かつ実践的な一歩である。