ツール呼び出しの評価: 引数、認可、および副作用

最近のツール使用の作業により、ポリシーとテキストが分離されました

2026 年 7 月のプレプリントである NetInjectBench は、信頼できない運用アーティファクトを信頼できるポリシー メタデータから分離します。その実験では、明示された仮定の下で、プロンプトレベルのアプローチと実行時間制御を比較します。これにより、慎重なプロンプトが不適切なアクションを防止すると仮定するのではなく、ツールの境界自体を評価するようになります。

証拠: NetInjectBench: ネットワーク操作用の大規模言語モデル エージェントを使用したツールでの間接プロンプト インジェクションのベンチマーク [1]

正しさの 4 つの層を定義する

ツールの選択では、操作がタスクに一致するかどうかが尋ねられます。引数の正確性では、識別子、単位、日付、および必須フィールドが正しいかどうかが問われます。承認では、要求されたアクションがこのユーザーおよびコンテキストに対して許可されるかどうかが尋ねられます。結果の正しさは、実際に何が変わったかを尋ねます。あるレイヤーでのパスは、次のレイヤーでのパスを意味しません。

機械的要件に対する正確なバリデータと、制限されたアクションに対する独立したポリシー チェックを作成します。曖昧なエンティティを解決するには、エージェントがいつ明確にする必要があるかを定義します。もっともらしい顧客名は、同じ名前の 2 つのレコードから選択するための十分な証拠ではありません。

境界を中心にケースを構築する

Rubrex は、有効な操作、引数の欠落、不正な形式のツール応答、あいまいな識別子、タイムアウト、重複したリクエスト、およびアクセス許可の拒否のケースを推奨します。エージェントが情報と指示を区別できるように、コマンドを引用する無害な文書を含めます。ツールが変更を加えることができる場合は、テスト データと分離状態を使用します。

拒否された通話がアプリケーションによって正しくブロックされたか、エージェントによって回避されたか、または単に試行されなかったかを記録します。これらは異なる観察です。エージェントのリクエスト計画の改善が必要な場合でも、強力な権限レイヤーによってシステムを保護できます。

実例: 2 人の顧客が同じ名前を持っています

営業アシスタントは、Northstar という名前のアカウントを更新するように求められます。 2 つのアカウントが一致します。 API はどちらの識別子も受け入れるため、スキーマの検証だけでは正確さを判断できません。予期される動作は、利用可能な曖昧さ回避コンテキストを使用するか、変更の前に明確化を要求することです。

リクエストに一意のアカウント識別子が含まれるコントロールを追加します。エージェントは、不必要な中断をせずにそのタスクを完了する必要があります。このペアの設計は、有用な注意と、すべての操作について確認を求めるシステムを区別するのに役立ちます。

統合の回復契約を評価する

各操作について、再試行が安全かどうか、冪等キーがサポートされているかどうか、および現在の状態を確認する方法を文書化します。明確な失敗と不確実な結果の両方をテストします。欠陥を適切なレイヤーに割り当てます。アプリケーション ガードレールの欠落をモデル プロンプトの問題として偽装してはなりません。

よくある質問