「何でもこなせる」究極のテストハーネスを目指して

あらゆる状況に対応可能な、万能なテストハーネスの開発についての考察です。

ハーネス（harness）を開発する上で一番役立った教訓がこれ：

迷ったらシンプルにすること。削って、整理して、最小限にする。問題を可能な限り小さなケースで再現し、設計全体を完全に理解する。これに近道なんてない。

このアイデアすごくいいし、コンセプトをUnixのプリミティブにマッピングしたやり方も納得感がある。確かにLLMはすでに「Unixネイティブ」な存在だよ。自分もk8sのプリミティブを使って似たようなイベント駆動のワークフローを試行錯誤してるところだけど、それはスタックの1段上の話。共有のメンタルモデルを整理するという点で、すごくしっくりくる。絶対にチェックさせてもらうよ。素晴らしい仕事だね。

エージェントに対する考え方が少し違うかも。決定論的な足場（scaffold）の必要性には完全に同意するけど、エージェント自体も可能な限り決定論的であるべきだと思うんだ。コードが多ければ多いほどいい。

例えば、今のClaude Codeに要求するような典型的なループを考えてみて（TDDは使わない前提で）。フェイルファストモードでテストスイートを走らせ、失敗が最近の機能変更に起因するものか診断する（バックエンド/フロントエンド、GitHubのissue、PRDなどを参照させる）。Claude Codeにテスト失敗が機能変更のせいかを判断させて、テストを更新させる。場合によってはサブエージェントを呼び出して調査・修正させる（必要と判断された場合）。修正をコミットして次に進む。

もちろん、これだと失敗する余地はたくさんあるけど、ここではエラーを起こしやすいテストメンテナンスじゃなくて、エージェントそのものの話をしたい。もし、コードベースの文脈を理解していて、テスト、リンター、フックなどを決定論的に実行できるエージェントがあったらどうだろう？「自然言語」のプロンプトはコードループの一部になり、LLMは「テスト失敗が機能変更によるものか」を判断するためだけに呼び出されるようになる。GitログやJIRAなんかも抽出できるしね。

ここでのツールはすべて本物のコード。他のツールを呼び出す実行可能なコードであって、エッジケースに遭遇した時だけLLMに聞くという形。エッジケースの定義は必要だけど、エージェントを使ってそうしたツールのメンテナンスを加速させることはできるはず。システムは「単一の機能をうまくこなすプログラム」の組み合わせを基盤にして、特定のエッジケースの判断だけをLLMに頼る。エージェントっていうのは、そうした実行可能ファイル同士を連携させるための仕組みであるべきだよ。

各ラボはハーネスの入出力データを使ってどの程度ポストトレーニングを行っているんだろう？「汎用的な」ハーネスが可能かどうかを見極める上で、そこはかなり重要なポイントだと思う。

ドメイン特化型のハーネスの方が、すでに汎用的なものを凌駕してると思う。それに、ソフトウェア開発そのものが一つのドメインでもあるしね。

自分が作ってるハーネスはClaude Codeのプラグインで、独自のブレインストーミング、ADR（アーキテクチャ決定記録）、計画策定スキルがあって、レビューやインタビューの能力も備えてる。受け入れ基準に関連する振る舞いテストも組み込み済み。自分のハーネスでは、作業が泥沼化（ratholes）しないようにすべて制御をかけてる。

最近、コンテナを立ち上げてClaudeに安全モードオフで一連の作業をさせた時、やることなすこと全部に問題があることにすぐ気づいてさ……結局、自分のハーネスをインストールし忘れてただけだった。

エンジニアリング用のハーネスなしでClaudeを走らせるなんて、ブレーキもハンドルもない車を運転するようなもんだよ。

Unix哲学とLinux FSについての言及、すごくいいね。リーンで透明性が高く、監査可能性（auditability）を最優先にするという方向性は、ハーネスが追求すべきものだと思う。

ただ一つ確信しているのは、すべてのタスクにおいて「ベスト」なハーネスなんて存在しないだろうってこと。トークン消費の予算管理やコスト追跡の観点も含めると、ワークロードによって最適なモデルとハーネスの組み合わせは変わってくるはず。

Ambianceは、唯一無二の究極のハーネスというよりは、そうしたバリエーションを構築するための優れた「カーネル」として機能しそうだな。

この記事は耳障りのいい抽象的な話ばかりだね。「何でもできるハーネス」の実現に向けて具体的な進歩が何一つない。小さなNodeアプリケーションを特定のツールに置き換え、VMを使って「能力を持たせる」と提案しているけど、それって既存のエージェント・サンドボックスと何が違うの？サンドボックスをハーネスと呼び変えたところで、具体的なゴールにはたどり着けないよ。

ファイルというメタファーがLLMにとって適切だという意見には反対だな。ファイルにはシークやバイトストリームがあるけど、LLMにとっては無用な抽象化でしかない。データを適切に保存・整理していれば、LLMがファイルの途中にジャンプしたりシークしたりする必要なんてないからね。

（人間ユーザー向けに設計された）UNIXのデザイン原則だからといって、わざわざベクターデータベースやキーバリューストアよりもファイルを強制させる意味がわからない。

「Preliminary Truths」のようなセクションを、まるで新しい洞察のように語る人がこんなに多いのは興味深いね。

有能なマネージャーなら（自分はそうじゃないと思ってるけど）、歴史的にずっと前から知っていた原則だよ。「簡潔に書け」「意図を明確に伝えろ」。これらがAIを巧みに操るための新しい「戦略」として持て囃されているのは滑稽だ。

「すべてはファイルである」という考えも同意しかねる。ファイルはバイトの配列だけど、LLMにとって「すべてはトークン/エンベディングのベクトル」だからね。

最近聞いた格言にこんなのがあった。
「あらゆる十分に進化した技術は、最終的にWebブラウザになる」

チャットウィンドウからハーネスへ、そして「何でもできるハーネス」へと進化していく今の流れを見ると、まさに的を射ている気がする。

自分もClaudeやCodex用のラップ……いや、ハーネスを構築してるから他の人の意見は参考になるよ。最初は「ノードエディタをプロンプトで操作する」ようなルートを考えてたんだけど、どうせなら完全にメタにして、ハーネスが生成出力として別のハーネスやツールの設定をブートストラップできるようにしたらどうだろう？

現在のプロジェクト：https://sxp.studio/apps/subjectivezero