ツールを共通化するとコストが下がり、保守も楽になる。そのはずが、GitHub社内ではまったく逆の結果が出た。Copilot コードレビュー機能を共通CLI（コマンドラインインターフェース）ツールセットへ移行した直後、レビューコストが上がり、検出される問題の数も減ったのだ。この事例は、AIエージェント（自律的にタスクを遂行するAIシステム）のアーキテクチャ設計において「ツールの品質」と「指示の品質」がまったく別の関心事であることを鮮明に示している。
共通化の動機とトレードオフ
GitHubのCopilot コードレビューは、もともと独自の探索ツール群を持っていた。ディレクトリ一覧・ファイル検索・コード読み取りなど、初期の言語モデルに特化して設計されたものだ。一方、複数のCopilot製品で使われるCLIツールセットは、Unix系の汎用コマンド（grep・glob・view）を束ねた共通基盤として運用されていた。
工学的な判断として、共通ツールへの一本化は合理的に見える。重複コードの削減、メンテナンス箇所の集約、ツール改善が全製品に自動で波及する、といった恩恵が期待できる。こうした考え方は「DRY原則（Don't Repeat Yourself）」として知られ、ソフトウェアアーキテクチャの文脈では長く支持されてきた考え方だ。しかしGitHubのオフラインベンチマーク（本番環境を模した評価環境）では、移行後にレビューコストが増加し、有用な指摘件数が減少するという逆行が発生した。
問題の本質は、「ツールが何をできるか」と「エージェントがそのツールをどう使うか」が分離していた点にある。エンジニアのNapalys Klicius氏が指摘したように、「ツールではなく指示が問題だった」。移行時に共通ツール側のシステムプロンプト（エージェントの行動方針を定義する指示文）をそのまま流用したことが、品質低下の直接原因だった。
ツールトレースが明かした「探索モード」の問題
ベンチマークが単なるスコアではなくツールトレース（エージェントがどのツールをどの順序で呼び出したかの記録）を取得していた点が、今回の分析を可能にした。トレースを見ると、エージェントはコードレビューをするというより、コードベース全体を初めて探索するような動きをしていた。差分（diff）から出発せず、広範囲にgrepをかけ、関係のありそうなファイルを推測しながら大量のコンテキストを読み込んでいた。
この挙動は汎用的なコード調査タスクには合理的だ。しかしプルリクエストのレビューは異なる目的を持つ。ゴールはコードベース全体を理解することではなく、「この変更が問題を引き込んでいるかどうか」を最小限のコンテキストで判断することだ。
読み込まれた余分なコンテキストはそのまま作業メモリに残り、LLM（大規模言語モデル）のトークン消費を押し上げた。アーキテクチャ的に言えば、エージェントが「タスクに適したコンテキスト取得戦略」を持たず、「汎用コンテキスト取得戦略」のまま動いていた状態だ。
プロンプト設計はAPIドキュメント設計と同じ問題を持つ
Klicius氏はツール説明とシステム指示をAPIドキュメントに喩えている。ドキュメントが曖昧であれば、開発者は正しいAPIを知っていても誤った呼び出し順序や過剰なリクエストを行う。エージェントも同じで、ツール自体が正しくても、指示が汎用的すぎると不必要な探索を繰り返す。
修正の中身は次のようなものだった。
- 差分（diff）を出発点として固定し、そこから候補を絞る
- grepとglobで候補を絞り込んでからviewを呼ぶ順序を明示する
- 検索結果が空の場合は一度だけ簡略化したクエリで再試行し、推測でファイル探索を広げない
ツール自体は何も変えていない。変えたのは「どの順序で、どの条件で、各ツールを呼ぶか」という行動指針だけだ。結果として、レビューコストは約20%削減され、品質の低下は見られなかった。
アーキテクチャ設計への示唆
この事例が示すのは、AIエージェントのシステム設計において「非機能要件（コスト・精度・応答時間）」と「ツール設計」と「指示設計」が互いに独立した関心事として存在するということだ。共通化・再利用というアーキテクチャ方針は依然として有効だが、指示（プロンプト）はその適用範囲を慎重に定める必要がある。
たとえば汎用的なコード調査タスクとコードレビュータスクは、利用するツールは同じでも「コンテキスト取得の最適戦略」が異なる。このような違いは、ツール共通化の恩恵とは切り離して、タスク固有の指示として明示的に管理するべき設計判断だ。
ソフトウェアアーキテクチャの文脈では、「再利用可能なコンポーネント」と「コンポーネントの使い方を定義する設定・ポリシー」は別レイヤーとして分離するのが定石だ。AIエージェント設計でも同じ分離が求められる。ツールを共有しながら、指示を用途別に管理するという構造が、今後のエージェント基盤設計において標準的なパターンになっていく可能性は高い。
ツールトレースのような観測手段を最初から設計に組み込んでおくことで、エージェントの挙動が意図と乖離したときに素早く根本原因を特定できる。可観測性（observability）はAIエージェントにとっても、従来のマイクロサービス設計と同様に設計段階で確保しておくべき性質だ。