【ITニュース解説】An AI agent can be approved and still leave you with an unknown result

現代のITシステムでは、AIエージェントと呼ばれる、特定の作業を自動で実行するプログラムが多くの場面で利用されている。これらのAIエージェントは、ウェブサービスやデータベースなど、様々な外部サービスと連携して動作することが多い。しかし、たとえAIエージェントが外部サービスに対して何らかの処理を行う許可（承認）を得て実行に移したとしても、その処理が本当に完了したのか、その結果はどうだったのかが、常に明確にわかるわけではないという、技術的な課題が存在する。

この記事は、このような「承認されたのに結果が不明な状態」がなぜ発生し、それをどのように管理すべきかについて深く考察している。特に、Agent Work Layer（AWL）というシステム開発における具体的な議論を例に、分散システムにおける処理の信頼性確保の難しさを浮き彫りにしている。

システムが外部サービスと連携する際、多くの場合、処理の入り口となる「ゲートウェイ」と、実際に作業を行う「レシーバー」という二つの部分が協力して動作する。例えば、ゲートウェイがレシーバーに対して「この処理を実行してほしい」と依頼を送ると、レシーバーはその依頼を受けて作業を開始し、完了後に結果をゲートウェイに返す、という流れが一般的だ。

しかし、このプロセス中にネットワークの瞬断や、どちらかのシステムが予期せず停止するなどの障害が発生すると、事態は複雑になる。たとえば、レシーバーが依頼された処理を正常に完了し、その結果をゲートウェイに返そうとした矢先に、ゲートウェイが停止してしまった場合を想像してみよう。このときゲートウェイは「処理の依頼はしたが、結果はまだ受け取っていない」という状態になる。一方、レシーバーは処理を完了している。

このような状況で、ゲートウェイが「結果が返ってこないから」と安易に同じ処理を再送してしまうと、レシーバー側で同じ作業が二重に実行されてしまう危険性がある。例えば、顧客へのメール送信であれば二通届いてしまったり、データベースの更新であれば意図しないデータの重複や不整合を引き起こしたりする可能性がある。このような重複実行を防ぐため、システムは「多くても一度だけ」処理を実行する（at-most-once）ことを保証する必要があるが、これは分散システムにおいては極めて難しい課題の一つだ。

Agent Work Layer（AWL）の開発者たちは、この問題に対して「不明（unknown）」という状態を導入することで対応しようとしている。ゲートウェイがレシーバーからの結果を受け取れなかった場合、AWLは自動的に再送を試みるのではなく、その処理の状態を「不明」として保持する。これにより、システムが勝手に重複処理を行うリスクを避け、人間が状況を確認した上で、次にどうすべきかを判断できるようにするのだ。

この変更は、GitHubのプルリクエスト（PR #43）として提案され、具体的なコード変更として実装された。このプルリクエストには、処理の重複を防ぐためのメタデータ（awl/refやawl/orderといった一意の識別子）を各呼び出しに付与し、レシーバー側でその識別子を検証して重複排除を行うための指針も含まれている。ただし、メタデータが付いているだけで自動的に重複排除ができるわけではなく、実際にレシーバー側でその識別子を適切に処理する仕組みが必要となる。

PR #43の変更の有効性を検証するため、様々なテストが行われた。例えば、「レシーバーが処理を記録した後にゲートウェイが停止するシナリオ」や、「レシーバーが応答せずに終了するシナリオ」などが検証され、その結果、AWLが意図通り「不明」状態を保持し、自動的な再送を避けることが確認された。これらのテストは、開発環境で特定バージョンのNode.jsやnpmコマンドを使って実行され、42個のテストケースが成功したことが報告されている。

しかし、これらのテストにもいくつかの限界があったことも指摘されている。例えば、システムクラッシュからの復旧は手動でのロック解除が必要であり、完全な自動復旧は検証されていない。また、テスト環境のレシーバーは「擬似的なサービス」であり、実際のGmail送信や、電力喪失といった本番環境での厳格な信頼性はテストされていない。つまり、現実の複雑なシステムで起こりうるあらゆる障害パターンを網羅的に検証することは困難であることも示唆している。

「不明な状態」を放置することはできないため、その後の議論では、この状態を手動で解決する仕組みが提案された。これは「settlement（和解・解決）」と呼ばれ、オペレーターが外部サービス（レシーバー）のログなどを確認し、その処理が実際に成功したのか、それとも実行されなかったのかを特定し、その結果をAWLに記録する。この「settlement」は、処理を再実行するものではなく、あくまで過去の処理の結果を確定させる行為である。

もし処理を再実行する必要がある場合は、別途「retry（再試行）」のステップが設けられる。この再試行では、単に同じ処理を送り直すのではなく、現在の権限が適切であるか、そしてその操作が過去の操作と論理的に同じものであるか（論理的な操作の同一性）を慎重に確認した上で、新しい試行回数を示すメタデータ（awl/try: 2など）を付与して送信する。これにより、再試行自体が新たな重複実行を引き起こすリスクを最小限に抑えることを目指している。

このような複雑な分散システムにおいて、信頼性を確保するためには、単に処理を実行するだけでなく、あらゆる段階での「証拠」を正確に記録することが極めて重要になる。具体的には、どのAIエージェントが、どのような権限のもとで、何をしようとしたのか、処理の依頼がいつ行われ、レシーバーがそれを受け取ったのか、そしてレシーバーからどのような応答があったのか、といった情報を個別に、詳細に記録しておく必要がある。さらに、これらの記録が誰によって提供され、何が実際に検証され、何がまだ未確認であるかという情報も残すべきだとされている。

このように詳細な証拠を分離して記録しておくことで、たとえ処理結果が「不明」という不確実な状態に陥ったとしても、その記録を元に人間が正確な状況判断を下し、適切な対応（settlementやretry）を取ることが可能になる。AIエージェントがITシステムと連携して動作する現代において、このような堅牢な設計と徹底した検証、そして継続的な改善が、システムの安定稼働と信頼性確保のために不可欠だと言えるだろう。