agent-box と Agent Tools は、作った直後には必要だと思っていたが、一瞬で陳腐化した。
現在、私はどちらも使っていない。
sandboxを自分で用意しなくなった
agent-box は、Claude CodeやCodexのようなAIエージェントCLIを軽量VMへ隔離し、ホスト側の認証情報やファイルを守りながら自律的に実行するために作った。
権限確認を外して長く作業させたいが、ローカル環境全体へアクセスさせたくない。そのためにApple Containerを使い、認証情報の渡し方、GitHubへの接続、ファイルのマウント、実行ユーザーを一つずつ制御した。
しかし、sandbox化された実行環境がサービス側から提供されるようになった。現在なら、Cursor Cloud Agentsのような環境へ仕事を渡せばよい。
VMの作成、CLIの更新、認証情報のコピー、イメージの保守を自分で持つより、最初から分離されたクラウド環境でエージェントを動かすほうが簡単である。
agent-box が解決しようとしていた問題は残っている。ただ、その解決を自分の薄いラッパーで所有する必要がなくなった。
検証CLIも先に作らなくてよくなった
Agent Tools は、サイトを収集するsitesnap、UIを検証するShimon、PDFを生成するpdfmintというCLIツール群だった。
エージェントが毎回ブラウザ操作やファイル生成の方法を考えなくて済むように、処理をCLIへ固定し、JSONの結果と再読可能な成果物を返す。エージェントはその出力を読み、次の操作を選ぶという設計にしていた。
これも、現在のモデルを使うと前提が変わる。
達成したい目的だけを渡せば、エージェントは必要な検証方法を考え、その場で小さなツールやスクリプトを作り、結果を見ながらループを回せる。既存の検証手段で足りなければ、タスクに合う観測方法を自分で用意する。
あらかじめ汎用CLIとして切り出し、コマンド、JSONスキーマ、終了コード、配布方法を保守し続けるより、その仕事に必要な検証をエージェント自身へ作らせたほうが早くなった。
能力の外側を補う道具だった
二つに共通していたのは、AIエージェント単体では不足する部分を外側から補う発想である。
安全に長時間動かす環境がなければVMを用意する。検証ループを安定して組めなければCLIとして固定する。当時は、その境界を人間が先に設計する意味があった。
ところが、実行環境はクラウド側へ組み込まれ、モデルは目的から必要な道具を作れるようになった。人間が先回りして用意していた外側の仕組みが、環境とモデルの内側へ移った。
AIエージェント向けのツールは、通常の開発ツール以上に前提が変わりやすい。モデルができないことを補うために作ると、次のモデルがその仕事をできるようになった瞬間に役割を失う。
作ったことに意味がなかったわけではない
agent-box も Agent Tools も、一般的に使い道がなくなったと断言するものではない。ローカル実行を自分で管理したい環境や、CIで同じ検証を決定論的に繰り返したい場面では、固定された道具が必要になる。
ただし、少なくとも現在の自分の作業では使っていない。
必要になるかもしれないという理由だけで保守を続けるより、当時どの問題を解こうとしたかを残し、役割を終えたことも記録したほうがよい。
AIエージェントのために何かを作るときは、機能を増やすことより、その機能が次のモデルでも本当に外部ツールとして残るのかを考える必要がある。
そして、目的を渡すだけで環境と検証ループまで組めるなら、今は何も作らないことが最もよい設計かもしれない。