【ITニュース解説】The Swiss Army Knife Trap: Why Wrapping Every API as an Agent Tool Backfires

AIエージェントが、アプリケーションのバックエンドシステム（サーバーやデータベースなどの裏側の仕組み）と連携する際、その接続方法には二つの主要な考え方がある。この連携の設計次第で、エージェントの能力やシステムの安定性に大きな違いが生じる。

一つ目の方法は、「浅いツール」としてバックエンドの機能を提供するアプローチである。これは、バックエンドの個々のAPIエンドポイント（特定の機能を提供するURLのようなもの）を、それぞれ独立した小さなツールとしてAIエージェントに公開するやり方だ。この方法の最大の利点は、非常に高い柔軟性にある。エージェントはこれらの小さなツールを自由に組み合わせて、開発者が事前に想定していなかったような新しい処理を実行できる可能性がある。そのため、情報探索や研究といった、予測不能な動きが求められるエージェントにはこの自由度が有効だ。

しかし、この浅いツールのアプローチにはいくつかの課題が伴う。まず、複数の小さなツールを連続して呼び出す必要がある、長大な処理チェーンが必要な場合に問題が生じやすい。エージェントは、プロンプト（AIに与える指示文）の中からツールの実行順序やルールを推測しなければならないため、常に正しい順番で呼び出しを実行できるとは限らない。また、すべてのツールの詳細な情報（スキーマと呼ばれる、APIが受け取るデータや返すデータの構造を定義したもの）を、エージェントは常に記憶しておく必要がある。この情報が大量になると、AIが処理できる情報の最大量（コンテキストサイズ）をすぐに消費し、多くのトークン（AIが情報を処理する際の最小単位）を必要とすることになり、処理コストの増加や応答速度の低下を招く。

さらに、個々のツールの成功率が100%ではない場合、長大なチェーン全体での成功率は大幅に低下する。例えば、6つのステップからなる処理で、各ステップの成功率が92%だとしても、全体での成功率は約60.6%まで落ち込む可能性がある。これは、エラーが連鎖的に発生しやすいためだ。加えて、「XのツールをYのツールより先に必ず呼び出す」といったビジネス上の重要なルール（不変条件）がプロンプトの中に記述されることになるため、エージェントがこのルールを見落としたり、誤解したりするリスクがあり、予期せぬ動作につながる可能性がある。多くの選択肢があるほど、AIが正しいツールを選択することも難しくなるという研究結果も存在する。

これに対して、「深いツール」のアプローチがある。これは、複数のAPI呼び出しや複雑なロジックを一つにまとめ上げ、特定の大きなタスクを完遂するための一つのツールとして設計するやり方だ。例えば、「サブスクリプションをキャンセルする」という一つの深いツールが、内部で複数のAPIを適切な順序で呼び出し、エラー処理も行うというイメージだ。このアプローチでは、実際の処理ロジックや手順、エラーハンドリング、ビジネスルールなどは、ツールのコードの中にカプセル化（外部から見えないようにまとめて隠すこと）される。エージェントは、この深いツールに対して「サブスクリプションをキャンセルして」といった高レベルな指示を出すだけでよく、細かい手順を気にする必要がない。

深いツールの利点は、複雑な処理をコード内で確実に実行できる点にある。認可（アクセス権限の確認）、ロック（同時に複数の処理が実行されないようにする排他制御）、不変条件のチェック（ビジネスルールの確認）、冪等な支払い（何度実行しても結果が変わらない支払い処理）といった重要な機能は、コードの中で厳密に管理できる。このため、金銭が関わるような顧客向けの自動化システムでは、深いツールが安全性の観点から推奨される。

しかし、深いツールにも制約がある。それは、事前に開発者がモデル化していない（つまり、コードに落とし込んでいない）タスクには対応できないという点だ。高い柔軟性を持つ浅いツールとは異なり、深いツールは決められたタスクの範囲内でしか機能しない。

この浅いツールと深いツールの考え方は、ソフトウェア設計の原則と共通している。シンプルで分かりやすいインターフェースの背後に多くの複雑な機能を隠し持つ「深いモジュール」に対し、「浅いモジュール」はほとんど何も隠さず、呼び出し元に多くの作業を委ねる。AIエージェントがAPIを直接1対1で呼び出す浅いツールは、AIエージェントに多くの作業を課すことになる。

したがって、AIエージェントとバックエンドの役割を明確に分けることが重要だ。AIエージェントは、ユーザーの要求を理解し、それに合致する「一つの高レベルなツール」を選択する役割を担うべきだ。そして、ユーザーにその処理のプレビューを表示し、確認を促す。一方、実際の処理（認可、ロック、不変条件チェック、冪等な支払いなど）は、バックエンドのコードが責任を持って確実に実行する。

しかし、コードで処理を記述すればすべてが正しいというわけではない。AIエージェントが間違ったツールを選んだり、間違った引数を渡したりする可能性は依然として存在する。また、コードに誤った計算ルールが記述されていれば、その間違いも正確に繰り返されてしまう。そのため、実際のビジネスルールに対するテストは不可欠であり、特に返金のような重要な処理の前には、ユーザーからの明示的な確認を求めるべきだ。

もし既存のツール群を見直す機会があれば、以下の点を考慮すると良い。まず、常に連続して実行されるような複数のツールは、一つの深いツールとして統合することを検討する。これにより、エージェントが管理すべきステップ数を減らし、エラーのリスクを低減できる。次に、システムプロンプトの中に記述されている「常にXの前にYを呼び出す」といったルールを特定し、これらをツールの内部チェックロジックとして実装し、プロンプトからは削除する。これにより、AIが不変条件を無視するリスクをなくすことができる。最後に、ツールの境界線（どの機能がどのツールに属するか）を設計記録（ADR: Architecture Decision Recordなど）として明文化し、新しいAPIエンドポイントをツールとして公開する前に、それが既存の深いツールの一部として統合されるべきか否かを慎重に検討する機会を設けることが望ましい。