【ITニュース解説】One broken call in a batch: how seven agent frameworks handle it

AIシステムがますます高度になり、私たちの生活や仕事に深く関わるようになる中で、AIが外部のツールを適切に利用する能力は非常に重要になる。ここで言う「AIエージェント」とは、単に指示に従うだけでなく、自律的に判断し、計画を立て、必要に応じて様々なツール（例えば、検索エンジン、データベース、予約システムなど）を呼び出してタスクを遂行するAIのことだ。システムエンジニアを目指す皆さんにとって、このようなAIエージェントがどのように動作し、特にエラーが発生したときにどう振る舞うかを理解することは、将来、信頼性の高いシステムを構築する上で不可欠となるだろう。

今回のニュース記事は、「バッチ処理の中で一つだけ壊れた呼び出しがあったとき、7つの主要なAIエージェントフレームワークがどのようにそれに対応するか」という、非常に実践的な問題を扱っている。バッチ処理とは、AIモデルが複数のツールを一度に呼び出す際に、それらの呼び出しをまとめて実行することを指す。例えば、「今日の天気予報を調べて、次にレストランの予約状況を確認して」といった複数の指示を、AIがまとめて処理するような場合だ。このような状況で、もしツール呼び出しの一つに問題（エラー）が発生したら、そのフレームワークは成功した処理の結果と、発生したエラー情報をAIモデルにどのように伝えるべきか、という点が今回の測定の焦点となっている。

具体的にどのような「壊れた呼び出し」がテストされたかというと、主に三つの種類があった。一つ目は「未知のツール名」で、AIが呼び出そうとしたツールが実際には存在しない場合だ。二つ目は「引数の形式不正」で、ツールに渡すべき情報（引数）の形式が間違っている場合。例えば、数字を渡すべきところに文字を渡してしまうようなケースだ。三つ目は「必須引数不足」で、ツールを実行するために必要な情報の一部が欠けている場合である。これらのエラーは、それぞれ有効な（成功するはずの）ツール呼び出しと組み合わせて、バッチ処理として実行された。

様々なフレームワークがこの問題にどう対処したかを見てみよう。vanilla、pydantic_ai、microsoft_afという三つのフレームワークは、テストされたすべてのエラータイプにおいて、成功したツール呼び出しの結果と、発生したエラー情報の両方をAIモデルに報告した。これは、「both」と表現され、AIモデルが何が成功し、何が失敗したかを正確に把握できるため、望ましい振る舞いと言える。

一方で、他のフレームワークは異なる振る舞いを見せた。langgraphは、未知のツール名と必須引数不足のエラーでは「both」だったが、引数の形式不正のエラーでは「good only」と報告された。これは、成功した結果だけがモデルに伝わり、エラー情報はモデルに報告されなかったことを意味する。smolagentsは、未知のツール名と必須引数不足のエラーでは「error only」、引数の形式不正では「good only」と、エラー情報だけを伝えたり、成功情報だけを伝えたりと、一貫性がない対応だった。openai_agentsとgoogle_adkは、一部のエラーで「raises」という振る舞いを見せた。「raises」とは、エラーが発生した際に、処理を中断して明示的にエラーを発生させることを意味する。これはAIモデルに情報を伝える前に、システム全体に問題があったことを知らせるものだ。

これらの結果から、システムエンジニアが特に注意すべき三つの「間違った」エラー処理パターンが明らかになった。一つ目は「サイレントな部分的失敗」だ。これは、壊れたツール呼び出しが何の報告もなく消えてしまい、AIモデルはエラーがあったことを知らずに、不完全な情報に基づいて回答してしまう状態を指す。これは最も危険なパターンであり、ユーザーはAIの回答が間違っていることに気づかず、重大な結果を招く可能性がある。

二つ目は「成功した兄弟が破棄される」パターンだ。これはsmolagentsの一部で見られた振る舞いで、エラーは報告されるものの、その際に成功した他のツール呼び出しの結果や、それまでの対話履歴までが破棄されてしまう。結果として、AIモデルは同じツール呼び出しのバッチを再度実行しようとし、システムの効率が著しく低下する。

三つ目は「エラー発生（Raises）」パターンだ。これは、処理を中断して明示的にエラーを発生させるものだ。一見するとシステムが止まってしまうため良くないように見えるかもしれないが、今回の記事では、この「raises」が最も望ましい振る舞いの一つとして挙げられている。なぜなら、何らかの問題が発生した際にそれがサイレントに隠蔽されることなく、開発者やオペレーターがすぐに問題に気づき、対処できるためである。サイレントな失敗は、問題を特定し解決することを非常に困難にする。

また、今回の検証で「バッチ処理が単独実行の結果を変える」という重要な発見があった。langgraphフレームワークの例では、引数の形式が不正なツール呼び出しを単独で実行すると、グラフの処理が停止し、エラーが明確に「見える」状態になった。しかし、同じ不正な呼び出しを、成功する他の呼び出しと一緒にバッチで実行すると、グラフは処理を続行し、不正な呼び出しが失敗したという事実が外部からは「見えなく」なってしまった。このことから、単独で動くときには問題が顕在化するのに、複数の処理と混ぜて実行すると問題が隠れてしまうことがある、というバッチ処理の落とし穴が明らかになった。システムを設計する上で、「バッチ処理は、個々の呼び出しが単独で実行される場合よりもフレームワークの振る舞いを悪化させてはならない」という原則を守ることの重要性を示している。

さらに、今回の測定自体にも興味深い側面があった。最初の測定では、フレームワークが返すメッセージの中に特定の単語（「observation」）が出現するかどうかでエラーを判断していた。しかし、「communications and observation tower」（通信と観測の塔）というフレーズのように、文脈によっては無関係な箇所でこの単語が出現することがあり、誤った測定結果を招いてしまったという。これは、複雑なシステムをテストし、その動作を正確に測定することの難しさ、そして測定方法自体の信頼性を確保することの重要性を示唆している。

最後に、これらの測定結果の限界も理解しておく必要がある。今回の検証はすべて「モックモード」で実行されたものだ。つまり、AIモデルの応答は事前にスクリプト化されており、常に同じ応答を返すように設定されていた。これにより、異なる結果が生じた場合は、それが純粋にフレームワークのエラーハンドリングの違いによるものであると断定できる。しかし、これは「動作の測定」であり、「AIの回答品質のランキング」ではない。実際の運用環境で、AIが生きているモデルと対話しながらツールを使う場合、その回答の品質は様々な要因で変動する可能性があり、今回の結果だけを見て「どのフレームワークが最も優れた回答を生成するか」を判断することはできない。

システムエンジニアを目指す皆さんにとって、AIエージェントがツールと連携し、エラーにどのように対処するかという知識は、将来的に堅牢で信頼性の高いAIシステムを設計・開発する上で非常に役立つだろう。特に、エラーが「サイレント」に隠蔽されないようにすること、そしてバッチ処理が単独実行よりも問題を隠蔽しないようにすることは、常に心に留めておくべき重要な原則となる。