Agent-First Tool API: A Semantic Interface Paradigm for Enterprise AI Agent Systems

本論文は、従来の人間向け CRUD インターフェースを意味論的 6 動詞プロトコルと構造化された意思決定支援メタデータに置き換える「エージェントファースト・ツール API」パラダイムを提案・検証し、企業向け本番システムにおける自律エージェントのタスク成功率とエラー回復を大幅に向上させるものである。

要約

あなたが非常に賢いものの、少しばかり文字通りの解釈をするロボットアシスタントに、複雑な指示を出そうとしている状況を想像してみてください。

従来の方法（「CRUD」問題）:
現在、銀行や小売店が使用するシステムなどの大部分のエンタープライズソフトウェアは、人間向けに構築されています。「先月オープンしたダウンタウンの支店を探してほしい」と人間に頼めば、その人は地図を見たり看板を読んだりして、それを特定できます。

しかし、今日の標準的なソフトウェアインターフェースを使ってロボットにこれをやらせようとするのは、ロボットに、作業を開始する前に支店の正確な 10 桁の ID 番号を必ず知っていなければならないような、税務申告書の記入を強いるようなものです。ロボットが ID を間違えて推測すると、システムは単に「エラー 404」と表示して停止します。ロボットは再度推測し、別のエラーを受け、最終的には諦めるか、人間の助けを求めるしかありません。これが論文で指摘されている「CRUD」のミスマッチです。ソフトウェアは正確な ID と精密なデータを求めますが、AI は曖昧な自然言語の目標から始まるからです。

新しい方法（エージェントファーストのツール API）:
著者らは、AI エージェント向けにこれらのツールを設計する新しい方法を提案しています。硬直したフォームの代わりに、曖昧さを処理する方法を知る親切な人間のアシスタントのようにツールを扱います。

彼らの「6 つの動詞」システムが、旅行代理店の比喩を用いてどのように機能するかを示します。

1. セマンティック検索（「どういう意味ですか？」フェーズ）:
   • 従来の方法: 「JFK 行きのフライトを予約してください」と言わなければなりません。
   • 新しい方法: 「タイムズスクエアに近い空港へのフライトを予約してください」と言います。ツールはパニックになりません。データベースを検索し、タイムズスクエアの近くにある 3 つの空港を見つけ、「JFK、ラガーディア、ニューアークが見つかりました。どれをお望みですか？」と尋ねます。
2. 候補の解決（「明確化」フェーズ）:
   • AI がリストから正しいもの（JFK）を選びます。ツールは「了解しました、JFK です」と確認します。
3. アクションのプレビュー（「ドライラン」フェーズ）:
   • 実際にチケットを予約する（お金がかかる）前に、ツールは草案を表示します。「今から行うことはこれです：500 ドルで JFK 行きのフライトを予約します。これでよろしいですか？」これにより、ミスが発生する前に防止されます。
4. アクションの実行（「実行」フェーズ）:
   • AI（または人間の管理者）が「はい」と言うと、ツールは実際にチケットを予約します。
5. 結果の検証（「うまくいったか？」フェーズ）:
   • ツールは直ちに自身の作業をチェックします。「チケットを予約しました。確認番号が本物か、データベースを再確認しましょう。」
6. エラーからの回復（「プラン B」フェーズ）:
   • 何か問題が発生した場合（例：フライトが満席）、ツールは単にクラッシュするわけではありません。「そのフライトは満席ですが、代替となる 3 つのフライトがあります。どれを試すべきでしょうか？」と言います。

セーフティネット（ガバナンス）:
論文では、厳格な「セキュリティガード」システムも導入されています。

• 二重レイヤーの権限: 2 つのことを確認します。「この AI はこの作業を行う役職を持っていますか？」（能力）AND「この AI はこの特定の店舗のデータに触れることを許可されていますか？」（スコープ）。
• 動的リスク: AI がチケットの確認のような小さなことを試みる場合、そのまま通過します。しかし、500 件のレコードを削除したり、ブランド全体の価格を変更したりするような大きなことを試みる場合、システムは自動的に一時停止し、進行前に人間の管理者の承認を求めます。

結果:
著者らは、作業注文の管理、スタッフのトレーニング、機器の修理など、85 種類の異なるツールを備えた実世界のシステムでこれをテストしました。

• 成功率: 新しいシステムはタスクの 88% を解決しましたが、従来のシステムは 64% しか解決できませんでした。
• 人間の支援の減少: 新しいシステムは、人間の介入を 6% の場合のみ必要とし、従来のシステムは 22% でした。
• ミスの減少: ツールがまず正しい ID を見つけるのを助けたため、AI は「幻覚」（間違った ID を推測すること）を大幅に減らしました。

トレードオフ:
新しいシステムは、検索、プレビュー、検証といった追加のチェックを行うため、個々のステップごとに少し多くの時間とより多くの「計算資源（トークン）」を消費します。しかし、失敗が少なく、推測のループに陥ることがないため、作業全体を完了するまでの総時間は実際には速く、はるかに信頼性が高くなります。

まとめ:
論文は、AI エージェントを実際のビジネスで真に有用なものにするためには、人間が使用するのと同じツールを単に与えるだけでは不十分だと主張しています。ツールを会話型で、自己修正可能で、安全を意識したものとして再設計し、AI を「盲目の推測者」から「監督された専門家」へと変える必要があります。

技術概要

技術概要：エージェントファースト型ツール API

1. 問題定義

本論文は、大規模言語モデル（LLM）エージェントの台頭する能力と、企業向けソフトウェアインターフェースのレガシーな設計との間に、決定的なアーキテクチャのミスマッチが存在することを特定している。LLM エージェントが急速に企業システムの主要なオペレーターとなりつつある一方で、それらが呼び出す API は、依然として人間駆動型のユーザーインターフェース（UI）向けに設計されたままとなっている。

著者らは、従来の CRUD（Create, Read, Update, Delete）API が、呼び出し元が人間ではなく自律型エージェントである場合に崩壊する 5 つの前提に依存していると主張している。

1. 正確なパラメータ: CRUD は、呼び出し元が正確な識別子（例：UUID）を知っていることを前提とするが、エージェントは曖昧さの解消を必要とする自然言語の目標から始まる。
2. レンダリング可能なデータ: REST API は UI 描画用の生 JSON を返却し、エージェントの推論に必要な意思決定支援メタデータ（信頼度スコア、出典）を欠いている。
3. 単一ラウンドトリップ: CRUD は 1 回のアクションにつき 1 回のリクエストを前提とするが、エージェントは多ターン推論ループ内で動作する。
4. 静的な権限: 従来のアクセス制御はユーザーに紐付いており、ユーザーの UI 権限とは独立して「ツール」が何を実行できるかを示す第 2 層の権限管理が欠けている。
5. 不透明なエラー: HTTP ステータスコード（例：400 Bad Request）は人間開発者に情報を提供するが、エージェント向けの構造化された回復戦略を提供しない。

既存のフレームワーク（例：LangChain、AutoGPT）やトランスポート規格（例：Model Context Protocol/MCP）は、オーケストレーションと発見には対応しているが、ツールインターフェース自体をレガシーな慣習に準拠した「ブラックボックス」として残しており、開発者を脆いプロンプトエンジニアリングや応急処置的なエラー処理に追いやっている。

2. 手法と設計パラダイム

本論文は、ツールインターフェースを「フォーム送信エンドポイント」ではなく「目標達成プロトコル」として再定義する「エージェントファースト型ツール API」パラダイムを提案する。この設計は、6 つのビジネスドメインにわたる 85 のツールにまたがる、本番環境のマルチテナント SaaS ワークオーダー管理システム内で実装された。

A. 6 動詞意味プロトコル

コアとなる相互作用モデルは、ツール利用を 6 つの意味動詞からなる有限状態機械（FSM）に分解し、すべての相互作用を推論ループとして構造化する。

1. 意味検索（S）: 記述的、曖昧、または部分的な自然言語入力を受理し、関連性スコア付きのランク付けされた候補を返す。
2. 候補の解決（R）: 複数の候補が存在する場合や信頼度が低い場合に曖昧さを解消し、エージェントに選択を促すか、解決策を提供する。
3. アクションのプレビュー（P）: 状態変更を行うツールの場合、実行前に予測される変更とリスク評価のドライラン要約を提供する。
4. アクションの実行（E）: トランザクション境界内で変更を実行し、呼び出し元が提供するキーを通じて冪等性を強制する。
5. 結果の検証（V）: 実行後、状態を再読み取りして、エージェントの元の意図と一致していることを確認する。
6. エラーからの回復（C）: 不透明なエラーコードではなく、構造化された回復ガイダンス（候補、提案）を返す。

すべてのツールが 6 つの動詞をすべて必要とするわけではない。読み取り専用ツールは通常、検索（および任意で解決）のみを実装し、高リスクツールは完全なサイクルを実装する。

B. 正規化ツール契約（NTC）

生 JSON 応答に代わるものとして、著者らは NTC（正規化ツール契約）を導入する。これは、すべてのツール出力に以下の要素を追加する標準化された応答仕様である。

• 意思決定支援: 計画決定を導くための confidence スコア（0〜1）。
• 証拠に基づく出典: 一致数、ソース、適用されたロジックを詳細に記述した構造化された evidence 配列。
• アクションの連続性: プランナーの探索空間を削減するための論理的な次のツールを提案する next_actions 配列。
• 結果の追跡可能性: 下流での消費のための型付きエンティティ識別子を含む result_refs。

このシステムは、経験的な成功率に基づいて静的な信頼度スコアを調整するベイズスライドウィンドウ較正メカニズムを採用している。

C. 二重層ガバナンスパイプライン

この設計は、6 層の検証パイプラインと二重層の権限モデルを導入する。

• 検証パイプライン: スキーマ検証 → 機能権限 → オブジェクトスコープ → 動的リスク評価 → 承認ゲート → 実行。
• 二重層権限: 機能（ロールが呼び出せるもの）と オブジェクトスコープ（テナント→ブランド→店舗→ユーザーの階層内のどのデータにロールがアクセスできるか）を分離する。
• 動的リスクエスカレーション: 影響を受けるエンティティの数、クロスブランド操作、不可逆的なアクションなどの要因に基づき、実行時にリスクレベルが調整される。高リスク操作は、エージェントのスレッドをブロックせずに実行を一時停止する組み込み承認ワークフローをトリガーする。

D. 記述的入力

定義的な原則として、ツールは「ダウンタウン支店」などの記述的入力を受理し、内部で解決を行う。これにより、LLM の確率的コンテキストウィンドウから決定論的なバックエンドロジックへと負担が移行する。

3. 主要な結果

著者らは、同一の MiniMax-M2.7 LLM と ReAct プロンプト戦略を用い、50 のタスクにおいて、エージェントファースト型パラダイムと従来の CRUD API ベースラインを比較する制御実験を実施した。

• タスク成功率: 64.0%（CRUD）から88.0%（エージェントファースト）に増加し、**37.5%**の改善。
• エラー回復: エラーからの成功した回復が5.8 倍改善（72.7% 対 12.5%）。
• 幻覚の削減: ID 幻覚エラーが**85.7%**減少（28% から 4%）。
• 人間の介入: 必要な人間の介入が**72.7%**減少（22% から 6%）。
• 効率性: マルチフェーズプロトコルにより 1 回あたりの呼び出しレイテンシとトークン消費は高くなるが、探索的再試行ループが排除されたため、タスクあたりの平均 API 呼び出し回数は**33.3%**減少（4.8 から 3.2）。
• ネットレイテンシ: 個別のツール呼び出しは長くなった（+48.4%）ものの、失敗した再試行サイクルの排除により、ネットのタスクレイテンシは平均1.3 秒短縮された。

4. 意義と主張

本論文は、エージェントファースト型ツール API パラダイムが、本番環境の企業向けにおける信頼性の高いエージェント型 AIにとって不可欠であると主張している。その主な貢献は以下の通りである。

1. パラダイムギャップの橋渡し: LLM が推論する方法（自然言語、多ターン、確率的）と、従来の API が動作する方法（正確な ID、単一ターン、決定論的）の間の根本的な断絶に対処する。
2. トランスポート規格との直交性: 著者らは、この研究が Model Context Protocol（MCP）などの規格と補完的であることを強調している。MCP がトランスポートと発見を解決するのに対し、エージェントファースト型 API はアプリケーション層における信頼性と管理可能性を解決する。
3. 企業グレードのガバナンス: 権限、リスク評価、承認などのガバナンスをツールインターフェースに直接埋め込むことで、外部オーケストレーション層なしに自律実行を安全に管理できることを実証する。
4. 実用性: ライブ SaaS 環境における 85 のツールでの検証は、このパラダイムがアーキテクチャ的に堅牢であり、「超人間的」な LLM 能力を必要とせずに曖昧さに起因する失敗を削減する上で効果的であることを証明している。

著者らは、このアプローチがエンジニアリングのオーバーヘッド（二重の API 表面の維持）を伴うものの、失敗モードの劇的な削減と真に自律的な企業エージェントの実現というトレードオフは正当化されると結論づけている。