エージェントに必要な基本ツールセット

皆さんがエージェントのツールセットについて話しているのを見て——シェルを提供すればすべて解決できるのでは？と思ったが、holonを作った後で気づいたのは、実はそんなに簡単ではないということだ。
読：なぜRead/Globを放棄し、すべてシェルに切り替えたのか
holonのツールセットは何度かバージョンアップを重ね、最終的にClaude Codeが提供するRead（ファイル読み取り）、Glob（パターン検索）といった専用ツールは廃止し、読み取りや検索はすべてシェルを通じて行うようになった。これはCodexの路線と一致している——CodexのExecCommandは一つのコマンドで済ませ、ファイルの読み取りはcat、コードの検索はrg、各"読み取り"操作に個別のツールを定義しない。
このやり方の理由は非常に素朴だ：シェルはLLMが最も馴染みのある「プログラミング言語」だからだ。モデルにReadツールのパラメータの意味を学習させるよりも、すでに何十億回も訓練されたシェルコマンドを書かせた方が効率的だ。専用ツールを増やすたびにモデルの認知負担は増すが、シェルというインターフェースにはモデルはすでに十分に習熟している。
しかし、すべてをシェルだけで済ませるには代償もある：出力の切り捨てだ。フレームワークはシェルの返り値が長すぎてコンテキストを圧迫しないように、各コマンドに出力上限を設けている。Agentがcatで大きなファイルを読むと、前半だけしか取得できず、残りはartifactファイルにあり、再度catを何度も繰り返して読む必要がある。Claude CodeのReadツールは圧縮閾値が一般的なシェルよりも高く、大きなファイルを一気に読むことができ、往復の手間を省いている。本質的には取捨選択だ：少ないツール定義で認知負担を軽減する一方、専用ツールは境界シナリオでの効率が高い。
書き：sedからApplyPatch、そしてfree grammar toolの課題
しかし、書き込み操作はシェルだけでは完全に対応できない。
もしAgentがsedだけで編集を行うと、複雑な複数行のマッチングに対応するのは難しい——改行、エスケープ、インデント、いずれかに問題があれば編集に失敗する。そこで多くのシステムはReplace Stringのような編集ツールを提供し、Agentに古い文字列の大きな塊を渡して正確に一致させ、新しい文字列に置換させる。これは不器用だが、sedよりもはるかに安定している。
Codexはさらに一歩進み、自身のApplyPatchツールを発明し、Agentが直接patchを生成できるようにした。一度に大量の編集を完結させる仕組みだ。holonもこのアイデアを参考にしている。
しかし、実装時に落とし穴があった：CodexはOpenAIが独自に定義した簡略化されたpatchフォーマットを使い、さらにfree grammar toolと呼ばれる特殊なツールメカニズムを組み合わせてフォーマット伝達の問題を解決している。
なぜ新しい仕組みを作る必要があるのか？それは、LLMの標準ツール定義はtool(args)のようなJSONパラメータ形式だからだ。patchをJSON文字列のパラメータとして渡すと、多くのエスケープ処理が必要になる——改行は変換され、引用符にはバックスラッシュを付け、インデントも注意深く処理しなければならない。Agentがpatchを書くときに既にミスしやすいのに、さらにJSONエスケープを重ねるとエラーの確率は倍増する。free grammar toolのアイデアは、patchの原文をそのままツールの入力にし、JSONパラメータのエンコードを経由しないことで、モデルが書く内容そのままを反映させることだ。これにより、patch生成時のエラー率が大きく低減される。
この仕組みは現状、OpenAIのCodexインターフェースだけがサポートしている。holonは複数モデル提供者に対応する必要があり、これだけに頼るわけにはいかない。
そこでholonのアプローチは：モデルごとに異なるApplyPatch定義を注入することだ。free grammarをサポートするモデルには原始的なpatchフォーマットを使い、他のモデルには標準的なgit diffフォーマットを受け入れる。私は、LLMはGitHub上の何十億回ものdiff訓練を経て、git diffフォーマットにはかなり習熟していると考えている。実際の運用でも効果は上々——エラーも多いが、多くの場合正しく修正できるし、訓練データが増えればこの能力はさらに向上するだろう。ただし、各モデルメーカーにはfree grammar toolのサポートも推奨したい。これはエージェントのコーディングシナリオにとって本当に必要不可欠だからだ。
スケジューリング：長時間コマンドとタスクの抽象化
三つ目の問題は、エージェントが実行するシェルコマンドが必ずしもすぐに終わるわけではないことだ——開発サーバーの起動、テストの実行、プロジェクトのビルドなど、長時間かかる場合もあり、場合によっては終了しないこともある。初期のエージェントフレームワークは非常に粗雑だった：同期的にブロックして自分を固めるか、すべてのコマンドをバックグラウンドに投げるかのどちらかで、結果的に同じコマンドを何度も繰り返し実行してしまう。
現在では、業界は次第に共通認識に収束している：エージェントに「前面/背面」の選択をさせない——これはエージェント自身が判断できないからだ。より良い方法は、タイムアウト閾値を設定し、コマンドが超過したら自動的にバックグラウンドに切り替えることだ。これにより、エージェントはコマンドをバックグラウンドにすべきかどうかを予測せず、ランタイムが自動的に処理する。
しかし、自動的にバックグラウンドに切り替えるのは第一歩に過ぎない。バックグラウンドに移行した後に、真のエンジニアリングの課題が浮き彫りになる——そしてこれらの問題については、現時点で業界に標準解は存在しない。
まず出力の読み取りだ。バックグラウンドタスクはまだ動いている場合もあれば、既に終了している場合もあり、出力も膨大になることがある。しかし、各APIの意味合いは統一されていない——ポーリング方式もあれば、イベント通知方式もある。
次に、タスクの停止だ。各社にはキャンセル機能があるが、キャンセルは即座にkillするのか、優雅に終了させるのか、既に出力された部分を保持するのか。
最後に、誰がエージェントを呼び戻すのかだ。エージェントがタスクをバックグラウンドに投げて休眠状態になったとき、タスク終了時に誰が呼び戻すのか？これにはランタイムとエージェントのスケジューリングの深い連携が必要であり、単なるツール層の問題では解決できない。
この三つ——出力の読み取り、タスクの停止、エージェントの呼び戻し——を合わせて、バックグラウンドタスクの完全なライフサイクル管理となる。各社は「バックグラウンド実行可能」を実現しているが、その管理の標準化はまだ進んでいない。これは次の段階のエージェントツールチェーンの進化において重要なポイントになるだろう。
無思考で既成のパターンを使う時代はまだ来ていない
したがって、冒頭の問いに戻ると、シェルは80%の問題を解決できるが、残りの20%——編集の正確性、patchフォーマットとモデルの能力のマッチング、長時間タスクのスケジューリングと抽象化——が、エージェントをデモから実用システムへと進化させるかどうかを決める決定的な要素だ。
ツールセットの選択は「シェルをラップするだけ」以上のものであり、また「既成のパターンを無思考で適用できる」段階にはまだ到達していない。これが、CodexとClaude Codeがこれらの基本的な問題に対して異なる解答を示し、holonが自分たちのシナリオに合わせて異なる妥協をしている理由だ。今後も探索と改善の余地は多く残されている。