第5章: ツール設計とACI — エージェント・コンピュータ・インターフェース

ツールは、モデルが外界と相互作用する唯一の手段です。ファイルを読む、コマンドを実行する、Webを検索する—— これらはすべてツールを通じて行われます。どんなツールをどんな粒度で与えるかが、エージェントの能力範囲を直接決めます。 そして驚くことに、ツール設計の良し悪しはモデルを変えるのと同じくらい性能を左右します。本章はその核心、ACI を扱います。

ACI — エージェント・コンピュータ・インターフェース

第2章で触れた SWE-agent 論文（2024）の中心概念が ACI（Agent-Computer Interface） です。 人間向けのGUI（HCI＝Human-Computer Interface）を丁寧に設計するように、LMという新種のユーザー向けに専用のインターフェースを設計せよ、という発想です。 SWE-agent は専用ACIを設計しただけで、モデルを変えずに SWE-bench の解決率を 3.8% から 12.5% へ引き上げました。

ツール設計はプロンプトと同等の厳格さで

Anthropic は「ツール設計をプロンプトと同等の厳密さで扱え」と勧告し、自社の SWE-bench 実装では「全体プロンプトよりツールの最適化に多くの時間を費やした」と明かしています。 具体的な指針はこうです——モデルが「自分を行き詰まらせる前に考える」十分なトークンを与える。 フォーマットはネット上の自然な文章に近いものに保ち、数千行のコード行数を正確に数えさせる、文字列を厳密にエスケープさせる、といった「フォーマットのオーバーヘッド」を避ける。 ツール定義には使用例・エッジケース・入力形式要件・他ツールとの境界を含める。

poka-yoke — 構造的に誤りを防ぐ

特に効くのが poka-yoke（ポカヨケ＝構造的にミスを防ぐ設計） です。 Anthropic の有名な例——エージェントが cd したあとに相対パスでファイル編集ツールを呼ぶと誤りが頻発しました。 そこで絶対パスを必須にしたところ、このミスがきれいに消えました。「気をつけてね」と注意するのではなく、間違えようがない形にするのです。

並列ツール呼び出し

ツールは1つずつ順番に呼ぶとは限りません。Anthropic のマルチエージェント研究システムでは、 リードエージェントが3〜5のサブエージェントを並列起動し、各サブエージェントがさらに3つ以上のツールを並列に使う構成で、 複雑なクエリの調査時間を最大90%短縮しました。 並列化はレイテンシを大きく下げる強力な手段ですが、書き込みが衝突しうるタスクでは諸刃の剣でもあります（この論点は第6章のマルチエージェント論争で深掘りします）。

配線標準としてのMCP

ツールを増やすたびに、各ハーネスが個別に統合コードを書くのは大変です。これを標準化するのが MCP（Model Context Protocol）。Anthropic が2024年11月に公開したオープンプロトコルで、「AIアプリのUSB-Cポート」とも称されます。 クライアント・サーバ型で、AIアプリ（MCPホスト）がサーバごとにMCPクライアントを生成して接続します。

graph LR
  H[MCPホスト\nClaude Code / IDE]
  H --> C[MCPクライアント]
  C --> S1[MCPサーバーA\nTools / Resources / Prompts]
  C --> S2[MCPサーバーB]
  S1 --> EX[外部API / DB / ファイル]
  S2 --> EX
  style H fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style C fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style S1 fill:#f97316,stroke:#ea580c,color:#fff
  style S2 fill:#f97316,stroke:#ea580c,color:#fff
  style EX fill:#14b8a6,stroke:#0d9488,color:#fff

MCPサーバーが公開する3つのコアプリミティブは Tools（実行可能関数）/ Resources（文脈データ）/ Prompts（再利用テンプレート）。 基盤プロトコルは JSON-RPC 2.0 です。OpenAI や Google も採用し、いまやツール接続層の事実上の標準になりました。 そのガバナンスとライセンス、そしてエージェント間連携の標準A2Aについては、第8章で詳しく扱います。