【ITニュース解説】Why AI Agents Fail at Login Walls: SMS, OTP, Passkeys, CAPTCHA

AIエージェントは、Webブラウザを開いてフォームをクリックしたり、APIを呼び出したりと、様々な操作を自動で行うことができる高度なプログラムだ。しかし、これらのエージェントは、ログイン画面に直面すると途端に奇妙な振る舞いを見せ、しばしば処理に失敗してしまう。これはなぜだろうか。エージェントがブラウザの画面を見ているにもかかわらず、認証に必要な情報がその画面の外側でやり取りされるため、エージェントは次に何をすべきか分からず、ただ待ち続けてしまうのだ。人間は、認証コードがスマートフォンに届いたり、メールボックスに送られてきたり、デバイスを使った認証が求められたり、あるいは自分がロボットではないことを証明するCAPTCHAが表示されたりしても、それらが現在のログインプロセスの一部であることを理解し、対応できる。しかし、エージェントにはその「文脈（コンテキスト）」が欠けているため、人間と同じように判断し、行動することが難しい。

人間が行うログインプロセスは、一見するとシンプルな操作に見えるが、実は多くの「状態（ステート）」を含んでいる。例えば、どのユーザーアカウントを使うべきか、スマートフォンやメールボックスにアクセスできるか、表示された認証の指示が現在の試行と関連しているか、いつログインを止めるべきか、CAPTCHAやパスキーの要求があったときに「人間が介入すべき時だ」と判断するなど、人間は無意識のうちに多くの情報を処理し、適切な判断を下している。一方、AIエージェントは、自動化プログラムにそうした「制御層」がなければ、ただフォーム、認証の要求、そしてタイムアウト（時間切れ）しか認識できない。場合によっては、パスワードのような秘密の情報を貼り付けることしかできない。これでは、信頼性の高いログイン処理を行うには不十分なのだ。

ログインを阻む壁（ログインウォール）には様々な種類があり、それぞれエージェントを異なる方法で困らせる。 SMSによるワンタイムパスワード（OTP）は、スマートフォンに送られてくるコードを入力する方法だ。エージェントはブラウザの画面の外でコードが届くため、そのコードをどう扱うべきか判断に迷う。さらに、どの試行でこのコードが要求されたのか、この電話番号は許可されているのか、コードは有効な時間内に届いたか、一度しか使われていないか、といった多くの「状態」を適切に管理する必要がある。これらの管理ができていないと、誤ったコードを送信したり、古いコードを使ってしまったりする危険性がある。 メールによるワンタイムパスワード（OTP）やマジックリンクの場合、認証の証明がメールボックスに移動する。エージェントは、どのメールボックスを使えばよいのか、そのメールボックスをこの認証に利用することが許可されているのかを判断する必要がある。特にマジックリンクの場合、リンクをクリックすること自体がログインアクションとなるため、誤った利用はセキュリティ上の大きな問題につながる可能性がある。 パスキー（Passkey）は、単にパスワードの入力が楽になったものではない。これは、特定のデバイスやウェブサイトのドメイン、そして認証を行う「持ち主」に結びついた証明を要求するものだ。エージェントがパスキーの入力を求められた場合、それを単に「バイパスすべきもの」と捉えるのは誤りである。むしろ、これはセキュリティ上の重要な境界を示すサインであり、エージェントは人間による介入を求めるか、サポートされているテスト用のパスに切り替えるか、または明確な理由を提示して安全に処理を中止すべきなのだ。 CAPTCHA（キャプチャ）は、アクセスしているのが人間か自動化プログラムかを判別するために存在する。つまり、CAPTCHAが表示された場合、「サイレントに（こっそり）解決して先に進む」のが正しい振る舞いではない。もし開発者が所有するシステムでテストを行う場合は、テスト用の特別な設定を使ったり、特定のIPアドレスからのアクセスを許可したりする方法がある。しかし、第三者のサービスでCAPTCHAが表示された場合、それは「これ以上自動化プログラムとして先に進むな」という明確な停止信号だと解釈すべきだ。エージェントは、不明な状態で処理を続けようとするのではなく、明確に処理を停止し、結果を報告するべきである。

結局のところ、AIエージェントに求められるのは、単にWebブラウザを操作する能力だけではない。ログインウォールに直面したとき、その状況を正確に検知し、エージェント自身が「誰のために動いているのか」「対象のサービスは許可されているか」「どのチャネルで認証の証明が送られるか」といったポリシーに基づいて判断し、適切な「分岐」を選択する能力が必要だ。 これは、エージェントが「状態機械（ステートマシン）」として動作するというモデルで考えることができる。エージェントがログインウォールに到達したら、それは認証の要求を検知した状態となる。次に、その認証要求がエージェント自身、所有者、対象サービス、通信チャネル、許可されている操作、そしてアクセス権の失効といった様々なポリシーと合致するかどうかをチェックする。このチェックの結果に基づいて、エージェントは構造化された判断を下す。例えば、認証コードを受け取って、それがポリシーによって許可されていれば処理を続行する。もしタイムアウトした場合は、ポリシーが許可する場合のみ再試行する。アクセス権が取り消された場合は安全に停止する。パスキーが要求されたら、人間による介入を求めるか、処理を停止する。CAPTCHAが表示されたら、停止するか、承認されたテスト用のパスを利用する。対象サービスから拒否された場合は、その旨を報告する。 このように、エージェントは単にトークンを保持したりブラウザを監視したりするだけでなく、「運用上のアイデンティティ」を持つ必要がある。つまり、明確な権限の下で、承認された対象に対して動作し、そのライフサイクル（開始から終了まで）が監査可能で、必要に応じて権限が取り消せるような仕組みが不可欠なのだ。

「AgentSIM」は、エージェントが自身が所有する、あるいは自動化を許可されたサービスの認証ウォールに直面した際に、そのエージェントを制御するための仕組みの一つだ。例えば、AgentSIMは現在、検証済みの自社アプリケーションにおけるライブSMS認証に対応している。AgentSIMは認証要求を発行し、ポリシーを適用し、結果を待って、構造化された形でエージェントにその結果を返す。メールOTPやマジックリンクについても、テストメッセージを注入することで、その動作を検証できる。パスキーやCAPTCHAについては、特別なテスト環境がなければ、原則として処理を停止する条件として扱われる。この「狭い」適用範囲は意図的なものだ。なぜなら、安全な製品は、あらゆるログインウォールへの普遍的なアクセスを主張すべきではないからだ。むしろ、権限を明確にし、明確な結果を返し、ウォールが「これ以上進むな」と意味する場合には、安全に処理を終了すべきなのだ。

もしAIエージェントがログインウォールに直面した場合、単純なブラウザ操作の工夫を追加する前に、以下の5つの重要な質問を自問すべきだ。

1. エージェントは誰のために動作しているのか？
2. 対象となるサービスは、エージェントによる自動化が所有者によって許可されているか？
3. 認証の証明はどのチャネル（SMS、メールなど）で提供されるのか？
4. エージェントが受け取る可能性のある具体的な結果は何があるか？
5. もし実行中にエージェントの権限が変わったらどうなるのか？ これらの質問に対する答えが、単に画面上の指示に頼るだけでは、エージェントの実行は非常に不安定なものになるだろう。しかし、ポリシーと証拠に基づいて動作する「状態機械」としてこれらの答えが明確に定義されていれば、エージェントは人間になりすますことなく、安全かつ確実に処理を進めることができる。将来のエージェントは、あらゆる壁を迂回するのではなく、どの壁に直面しているのか、どのような権限を持っているのか、次にどの安全な分岐に進むべきなのかを理解できるようになるだろう。