Verified Tool Calls Improve LLM Agent Reliability Under Non-Atomic Failures

あなたは宇宙船の船長になったと想像してください。ただし、自分で船を操縦するのではなく、非常に賢くておしゃべりなロボットの副操縦士に話しかけています。あなたの仕事は、「エンジンを始動せよ」や「救難信号を送れ」といった指示をロボットに与えることです。人工知能の世界では、これらのロボットはLLMエージェントと呼ばれ、彼らが操作するものはツール（コンピュータプログラムやデータベースなど）と呼ばれます。長い間、科学者たちは、ロボットがツールに対して何かを実行するよう求めると、ツールは即座に「完了！」または「失敗しました！」と答えると想定してきました。それは、ボールが常に即座に戻ってくる完璧なピンポンゲームのようなものでした。

しかし、現実の世界はもっと混沌としています。メッセージを送ってもネットワークが遅いために、しばらく返答がないことがあります。あるいは、メッセージは実際に届いていてエンジンも始動しているのに、ロボットが「完了！」という信号を受け取れなかっただけかもしれません。もしロボットが返事がないことにパニックを起こして、「もう一度やって！」と叫んでしまったら、誤ってエンジンを2回始動させてしまうかもしれません。この論文は、こうした混乱する瞬間を、混乱を引き起こすことなく対処する方法をこれらのロボット副操縦士に教える方法について述べています。それは、ただ推測してリトライするのではなく、作業が実際に完了しているかどうかを確認するために、素早く様子を伺うべきだと提案しています。

問題： 「本当にうまくいったのか？」という謎

研究者たちは、これらのAIエージェントの動作における大きなギャップに気づきました。現在のほとんどのシステムは、完璧で即時的な世界であるかのように振る舞います。彼らは、ツール呼び出し（メールの送信や銀行記録の更新など）に対して明確な「成功」メッセージが得られない場合、それは確実に失敗したのだと想定しています。

しかし、現実のコンピュータシステムは、忙しい郵便局のようなものです。手紙は届けられたものの、「配達完了」の受領証が郵便の中で紛失してしまうことがあります。手紙は届いているものの、郵便受けを確認する人がまだそれに気づいていないこともあります（遅延）。あるいは、手紙が半分だけ届いていることもあります。論文の中で、著者らはこれらを**非アトミックな失敗（non-atomic failures）**と呼んでいます。「アトミック（原子的な）」とは、電灯のスイッチを入れるように、物事が一斉に起こることを意味します。「非アトミック」とは、遅延や部分的なステップを伴う、もっと泥臭い状態を意味します。

AIエージェントがこのような混乱に直面すると、しばしばパニックに陥ります。コマンドを送信してタイムアウト（応答なし）になると、エージェントは「大変だ、うまくいかなかった！」と考えます。そして、もう一度試みます。しかし、もし最初のコマンドが実は成功していたとしたら、エージェントは単に重複を作成してしまったことになります。ピザを注文して、店から返事がないので、5回電話し直す場面を想像してください。今や、1枚の代わりに5枚のピザが届いてしまいました。デジタルの世界でも、これは顧客に5通の怒りのメールを送ったり、クレジットカードに5回請求したりすることを意味するかもしれません。

解決策： 「チェック・ファースト」のラッパー

これを修正するために、著者らはエージェントが使用するツールの周囲に、シンプルで軽量な「ラッパー」（安全層）を構築しました。彼らはこれを**検証してからリトライする（verify-before-retry）**システムと呼んでいます。

その仕組みを、簡単な例えで説明します。
壁に絵を掛けようとしている場面を想像してください。

1. 古いやり方（ナイーブなリトライ）： あなたは釘を打ちます。「ドン」という音が聞こえないので、打ち損じたと思って、もう一度打ちます。また打ちます。結果として、すでに絵は掛かっているのに何度も打ち続けてしまい、壁に巨大で台無しな穴を開けてしまいます。
2. 新しいやり方（検証してからリトライ）： あなたは釘を打ちます。「ドン」という音が聞こえません。すぐにまた打つ代わりに、あなたは壁を見ます。そして確認します。「絵は掛かっているか？」
   • もし絵がそこにあるなら、あなたは止まります。二度と打ちません。
   • もし絵がまだ掛かっていないなら、その時に初めて、もう一度釘を打ちます。

このラッパーは、エージェントの振る舞いに3つのスマートなルールを追加します。

1. 信号と現実を切り離す： 「成功」のメッセージを受け取らなかったからといって、そのアクションが失敗したとは限りません。
2. リトライする前に確認する： エージェントがコマンドを再度試みる前に、まず世界の実際の状態（事後条件）を確認し、作業がすでに完了しているかどうかをチェックしなければなりません。
3. 魔法の鍵（べき等性）を使う： もしエージェントがどうしてもリトライする必要がある場合、「べき等性キー（idempotency key）」という特別な魔法の鍵を使用します。これにより、コンピュータシステムに対して「おい、これは同じリクエストの再試行だ。もしすでに実行済みなら、この2回目は無視してくれ」と伝えることができます。

結果： 間違いは減り、成功は維持される

研究者たちは、エージェントがどのように反応するかを見るために、意図的に不具合を起こすシミュレーション環境でこのアイデアをテストしました。彼らは主に2つのタスクを作成しました。

• 顧客の有効化： ユーザーアカウントを作成し、正確に1通のウェルカムメッセージを送信する。
• 請求書の記録： 請求書を更新し、支払い済みとしてマークする。

彼らは、ネットワークのタイムアウト、更新の遅延、部分的な失敗など、さまざまな種類の「不運」をシステムに注入しました。そして、従来の「ただリトライする」方法と、新しい「検証してからリトライする」方法を比較しました。

結果は明白であり、非常に劇的でした。

• 重複アクション： 古い手法は、問題が発生すると悲惨な状況になりました。「顧客の有効化」タスクにおいて、失敗が頻発した場合、古いエージェントは72%の確率で重複したウェルカムメッセージを送信しました。新しい「検証してからリトライする」エージェントは、これをわずか20%に抑えました。「請求書の記録」タスクでは、高い故障率の下で古いエージェントは76%の確率で重複レコードを作成しましたが、新しいエージェントはそれを20%（低故障時の0%から中故障時の16%からの低下）まで下げました。
• タスクの成功： 新しい手法は、単に間違いを止めるだけでなく、エージェントが仕事をより良くやり遂げる助けにもなりました。顧客タスクにおいて、システムが壊れていても、新しいエージェントは**100%の成功率を達成しました。古いエージェントの成功率は、状況が悪化すると64%まで低下しました。請求書タスクでは、ベースライン（従来の方法）も十分に強力でしたが（低故障で100%、高故障で96%）、新しいラッパーは、ベースラインがわずかに低下する中で、最高レベルの故障レベルにおいても100%**の成功率を維持しました。

著者らはまた、彼らの新しいシステムのどの部分が最も大きな役割を果たしているのかを確認するために、特別なテストを行いました。その結果、**検証（作業が完了したかどうかの確認）**が最も重要な要素であることが分かりました。状態を確認してリトライしないだけで、フルシステムに近い成果が得られました。これは、エージェントに「もっと一生懸命やらせる」ことが問題なのではなく、「必要のない時に一生懸命やりすぎてしまう」ことが最大の問題であったことを示唆しています。

なぜこれが重要なのか

この論文は、これらの問題を解決するためにAIを「より賢く」したり、その脳を作り変えたりする必要はないと示唆しています。代わりに、ツールとの対話方法を変えるだけでよいのです。「跳ぶ前に見る（Look before you leap）」というシンプルなステップを加えることで、AIエージェントをはるかに信頼性の高いものにできます。

これは、お金を送ったりファイルを削除したりするように、2回行うことが災難につながるタスクにおいて特に重要です。この研究は、コンピュータシステムがしばしば混沌とし、遅延を伴う世界において、最も信頼できるロボットを作る方法は、パニックになって何度もやり直す前に、自分の仕事をダブルチェックすることを教えることであると示しています。これは、デジタルの混乱を防ぐことができる、ソフトウェアへの小さな変更なのです。