Tool-Genesis: A Task-Driven Tool Creation Benchmark for Self-Evolving Language Agent

既存の評価手法の限界を克服し、抽象的な要件からツールを自律的に生成・活用する言語エージェントの能力を多角的に診断する新しいベンチマーク「Tool-Genesis」を提案し、現状の最先端モデルでも初期の微小な欠陥がパイプライン全体で増幅され性能が急激に低下することを明らかにしました。

要約

この論文は、**「Tool-Genesis（ツール・ジェネシス）」**という新しい基準（ベンチマーク）について書かれています。

一言で言うと、**「AI に『道具を作る力』をテストする、新しい試験問題」**です。

これまでの AI の研究では、「すでに完成された道具（API）を上手に使えるか？」が問われていました。しかし、現実世界では「必要な道具なんてまだ存在しない！」という状況が頻繁に起こります。そんなとき、AI はゼロから道具を設計し、作って、使いこなせるでしょうか？

この論文は、その**「ゼロから道具を作る力」**を厳しく、そして詳しく測るための新しいテスト方法を紹介しています。

---

🛠️ 従来の AI と「Tool-Genesis」の違い

この論文では、AI の道具作りを 3 つのシチュエーションに例えています。

1. 従来の方法（使い捨ての紙飛行機）

   • 状況: 「今すぐこの問題を解決して！」と急かされる。
   • AI の行動: 紙をただの紙飛行機に折って投げる。
   • 結果: 一瞬は飛ぶけど、壊れやすく、二度と使えない。
   • 問題点: 失敗しても「なぜ飛ばなかったか」がわからない（ブラックボックス）。

2. 従来の方法（設計図の機械的翻訳）

   • 状況: 完璧な設計図（仕様書）が手元にある。
   • AI の行動: 設計図をただ機械的にコードに書き換える。
   • 結果: 設計図にミスがあれば、そのままバグった機械が完成する。
   • 問題点: 「設計図がない」現実世界では役に立たない。

3. Tool-Genesis の方法（職人の道具作り）

   • 状況: 「重い箱を運んでほしい」という抽象的な要望だけがある。
   • AI の行動: 「じゃあ、この箱に合う『手押し車』を作ろう！」と、素材から設計し、組み立て、テストする。
   • 結果: 壊れにくく、将来も使える**「高品質な道具」**が完成する。
   • 特徴: 失敗したとき、「設計ミスか？組み立てミスか？」を詳しく診断できる。

---

🔍 このテストが特別な 3 つのポイント

このテストは、ただ「正解かどうか」を見るだけでなく、**「どこでつまずいたか」**を 4 つの段階で詳しくチェックします。

1. 形が合っているか？（表面のチェック）

• 例え: 道具を作ったとき、その形が「工具屋の棚」に収まる規格（MCP 規格）に合っているか？
• チェック: 設計図（スキーマ）が読める形か？サーバーは起動するか？

2. 設計図が正しいか？（意味のチェック）

• 例え: 「ハンドルは赤く、タイヤは 4 つ」という設計図が、本当に意図した通りになっているか？
• チェック: 作られた道具の仕様と、本来あるべき仕様を比べる。

3. ちゃんと動くか？（機能のチェック）

• 例え: 実際に箱を乗せて走らせてみる。
• チェック: 普通の使い方だけでなく、「タイヤが外れたらどうなるか？」「重すぎる箱を乗せたら壊れるか？」といった**「失敗するパターン（ネガティブテスト）」**も含めてテストする。

4. 問題が解決したか？（実用性のチェック）

• 例え: 最終的に「箱を運ぶ」という目的は達成できたか？
• チェック: 作った道具を使って、実際にタスクをこなせるか？

---

📉 驚きの発見：AI は「完璧な道具」を作れない

このテストで、最新の AI 模型（GPT-4 や Claude など）を試したところ、意外な弱点が見つかりました。

• 小さなミスが致命傷になる:
  AI が「道具の設計図」を 1 回で書こうとすると、小さなミス（例えば、数字の型を間違えるなど）をよく犯します。
• 雪だるま式に悪化する:
  その小さなミスが、次の「組み立て」や「テスト」の段階で増幅され、最終的に**「道具が全く使えない」**という結果に繋がってしまいます。
  • 例え: 車の設計図で「ネジのサイズ」を 1 ミリ間違えただけで、最終的にエンジンが回らなくなるようなものです。

また、**「一度で完璧に作るのは難しいが、作って試して直す（フィードバックループ）」**というプロセスを踏むと、AI の性能が劇的に向上することもわかりました。

---

🚀 この研究の意義：なぜ重要なのか？

これまでの AI 研究は、「既存の道具をどう使うか」に焦点を当てていました。しかし、未来の AI は**「必要な道具を自分で作り出し、メンテナンスし続ける」**必要があります。

この「Tool-Genesis」は、AI が**「自らの進化」**を遂げるための重要なステップです。

• 一時的な解決策（使い捨ての紙飛行機）ではなく、
• 長く使える資産（高品質な道具）を作れるか？

を測ることで、AI が現実世界の複雑な課題にどう向き合うべきか、道筋を示しています。

まとめ

この論文は、**「AI に『道具職人』としての能力を問う、新しい試験」**の提案です。
「設計図がない状況で、ゼロから道具を作り、テストし、改良する」というプロセスを詳しく分析することで、AI が本当に「自立して進化」できるかどうかを、これまで以上に深く理解できるようになります。

AI が単なる「道具使い」から、「道具を作る創造者」へと成長するための、重要な第一歩となる研究です。

技術概要

Tool-Genesis: 自己進化型言語エージェントのためのタスク駆動型ツール作成ベンチマーク

技術的サマリー（日本語）

本論文は、自己進化型言語エージェント（Self-Evolving Language Agents）の能力を評価するための新しい診断ベンチマーク**「Tool-Genesis」を提案するものです。既存のツール利用ベンチマークが「事前に定義された仕様」に依存しているのに対し、Tool-Genesis は抽象的な要件からツールをゼロから作成・適応・維持する能力**に焦点を当て、エージェントの真の自律進化を評価します。

以下に、問題定義、手法、主要な貢献、実験結果、および意義について詳述します。

---

1. 背景と問題定義

従来の言語エージェントの研究は、「推論（Reason）→ 呼び出し（Call）→ 実行（Execute）」のパラダイムに依存しており、ツールインターフェースやスキーマが信頼でき、事前に定義されていることを前提としていました。しかし、現実の展開環境では以下の課題が存在します。

• 仕様の欠如: 明確なドキュメントやスキーマが存在しない場合、エージェントは要件からインターフェースを推論する必要があります。
• ブラックボックス評価: 既存のベンチマークは、最終的な回答の正解率や粗い呼び出しレベルのチェックに依存しており、失敗の原因が「ツールの設計ミス（スキーマの誤り、ロジックのバグ）」なのか「ツールの使い方の戦略ミス」なのかを区別できません。
• 一過性のスクリプト: 多くのシステムは、特定のタスクを解決するための使い捨てスクリプトを生成するだけで、再利用可能なツール資産として蓄積・進化させることができていません。

これらの課題に対し、Tool-Genesis は**「要件からツールを作成し、再利用可能な資産として維持する能力」**を定量的に評価することを目的としています。

2. 手法とベンチマーク設計

データセット構築 (Dataset Construction)

Tool-Genesis は、以下のパイプラインを通じて高品質なデータセットを構築しました（図 2 参照）。

1. MCP サーバーの収集: Web 上の MCP (Model Context Protocol) サーバー（GitHub, HuggingFace など）から収集し、構造的検証、実行可能性検証、重複排除、LLM による意味的検証を経て、**86 個のサーバー（508 個のツール）**を抽出しました。
2. タスクと軌道の生成: LLM を用いて、各サーバーのツールから現実的なタスクを生成。さらに、サンドボックス環境でエージェントを実行し、実際の API 応答に基づいた「軌道（Trajectory）」を生成・フィルタリングしました。
3. 包括的な単体テスト生成: ツールの機能検証のために、正例だけでなく、境界値や不正な入力を含む9,441 件の単体テストを生成・フィルタリングしました。
4. 手動品質検査: 専門家がタスクの妥当性、軌道の整合性、テストのカバレッジなどを厳格にチェックし、Cohen's κ = 0.85 の合意率を達成しました。

最終的に、24 のドメインクラスにまたがる2,150 件のタスクと、多段階のツール呼び出しを必要とする複雑なタスク構造を備えたデータセットが完成しました。

評価プロトコル (Evaluation Protocol)

ツール作成プロセスを**「ツールインターフェース予測（Interface Prediction）」と「ツール具現化（Materialization）」**の 2 段階に分解し、4 つのレベルで評価します。

• Level 1 (表面準拠): 生成されたツールレジストリが MCP 仕様に準拠しているか、サーバーが起動して応答するか（Compliance Rate, Server Execution Rate）。
• Level 2 (セマンティック・インターフェース忠実度): 予測されたツールスキーマと正解スキーマの一致度を F1 スコアで測定（Schema-F1）。
• Level 3 (機能的正しさ): 生成されたツールが、緩和条件（UTsoft）および厳格な境界値・否定テスト（UThard）をパスするか。
• Level 4 (ダウンストリームタスク有用性): 固定された代理エージェント（Qwen3-14B）を用いてタスクを解決させ、正解率（SR）を測定。さらに、オラクル正規化された成功率を導入し、生成ツールと正解ツール（Ground Truth）の性能差を定量化します。

3. 主要な貢献

1. 要件駆動型のツール作成ベンチマークの確立:
   事前の仕様書なしに、抽象的な自然言語要件から実行可能なツールコードとスキーマを生成するタスクを形式化しました。
2. 診断的評価プロトコルの提案:
   「ブラックボックス」な結果評価を脱却し、コンプライアンス、スキーマ忠実度、単体テスト、ダウンストリームタスクの 4 段階で失敗原因を特定できるフルライフサイクル評価を導入しました。
3. オラクル正規化された有用性ギャップの定量化:
   生成されたツールが、理想的な実装と比較してどの程度の性能損失があるかを測定する指標を提供し、実用的な自己進化能力を評価可能にしました。

4. 実験結果と知見

主要な大規模言語モデル（LLM）（GPT-4o, Claude, Gemini, Qwen3, DeepSeek など）を対象に、**Direct（一発生成）とCode-Agent（実行フィードバックによる修正ループ）**の 2 つの戦略で評価を行いました。

• 一発生成の限界: 最先端モデルであっても、ワンショット設定では正確なツールインターフェースや実行可能なロジックの作成に苦戦しています。初期の微小な欠陥がパイプライン全体で増幅され、ダウンストリームの指標が急激に低下することが確認されました。
• クローズドループ修正の重要性:
  • Code-Agent戦略（実行フィードバックに基づく修正）を採用すると、機能の正しさやタスク成功率が劇的に向上しました（例：Gemini-3-Flash の SR が 0.103 → 0.581 に向上）。
  • 高い準拠性や一見正しいスキーマ（L1/L2）があっても、実行時のバグや境界値処理の欠如により、ダウンストリームの成功（L4）が保証されない「変換のボトルネック」が存在することが示されました。
• スケール依存性とファインチューニング:
  • 修正の恩恵はモデルサイズに依存し、大規模モデルほど実行フィードバックを効果的に活用できます。
  • Tool-Genesis データセットでのファインチューニングは、一発生成の品質向上だけでなく、Code-Agent におけるバグ特定と修正の効率化にも寄与し、中間検証の改善が最終タスク成功に直結することを示しました。

5. 意義と将来展望

Tool-Genesis は、言語エージェントの研究を「単発のツール呼び出し」から「持続可能で再利用可能なツール資産の構築・進化」へと転換させるための基盤を提供します。

• 研究の方向性: 将来的には、モデルが長期的なタスク分布にわたってツールを誘導（Induction）、修復（Repair）、検証（Verification）する能力を高めるための研究を促進します。
• 実用性: 現実世界の複雑な課題に対処するために、エージェントが自律的にツールを設計・維持する能力の向上に寄与します。

本ベンチマークは、ツール作成における「ブラックボックス」な評価を解消し、より透明性が高く、診断的な進歩を可能にすることで、自己進化型エージェントの実用化に向けた重要な一歩となります。