ハーネスエンジニアリング

Harness Engineering とは、モデルが十分に強くなった後、エンジニアリングの重心が「どう聞くか」（Prompt Engineering）と「モデルに何を見せるか」（Context Engineering）から、agent にツールとフィードバック経路を渡し、何を見るべきか・何を検証すべきかを自分で判断させる方向へ移ることを指す。同時に sandbox、権限、テスト、CI の回数上限、構造的制約といった境界で暴走を防ぐ。

三重スパイラルの要点は分類そのものではなく、各リングが成熟すると次のリングのインフラになることだ。prompt の技法はテンプレートとシステムプロンプトに固まり、context の組み立ては検索・圧縮パイプラインに固まり、その上で harness 層が「ループの中で誰が次の一手を決めるか」を引き受ける。

「モデルがここまで強いなら harness に何の意味があるのか」への答え（agent-harness bitter lessons の実戦振り返り）：harness の仕事は複雑性を消すことではない——複雑性は消せない——複雑性を配分することだ。個々のビジネス上の真実を、それに責任を負うべき層へ送り返す。アンチパターンは暴走ループ（benchmark → bad case → Prompt パッチ → 局所指標の改善 → 新たなリグレッション → 全体の硬直化）、正しいパターンは帰着ループ（bad case → 失敗層の特定 → 責任層での最小修正 → エンドツーエンド回帰 → ルールの去就判断）。判定基準の一文：benchmark は診断器であって System Prompt のオートコンプリートではない。bad case は証拠であって答えではない——どこかが壊れたことは教えてくれるが、どの層で直すべきかは教えてくれない。

同じソースが示すルール統治観：システムに入る新しいルールは四つの問いに答えられなければならない——どの失敗から来たのか、本当はどの層に属するのか、有効かつ隣接 case を傷つけないことをどの指標で判断するのか、上流が変わったときに削除可能だとどう知るのか。この記録がなければ、一時的な足場は System Prompt に永久に残り、後任は消す勇気がなく回り道で積み増すだけになる——「足場はやがて監獄になる」。これは The Bitter Lesson のエンジニアリング的読解とも一致する：人間の局所的経験をルールに固めると短期では効くが、長期ではモデルの汎化空間を圧縮する。ただし結論は「ルールを書くな」ではなく、決定論的な境界はコード／状態／テスト可能な契約に置き、理解・探索・汎化が必要な部分だけをモデルに委ねることだ。評価の単位もそれに応じて、単一の Prompt・ノード・オフラインスコアではなく、ユーザーが本当に完了したいタスクになる（コンポーネントと契約／エンドツーエンドの連鎖／本番プロダクトの成果という三つのスケール、agent-runtime-design を参照）。

一次経験による裏付けは記事 一つの Video Agent イテレーションがハーネス手法に育つまで にある：動画スタイル agent の改善圧力から、共有コンテキスト（比較マトリクス + phase trace）、独立レビュー（三層 review stack）、境界知識ベース（boundary / exemplar store）、回帰保護（golden set + regression gate）が自然に育った——この四つを合わせたものが、そのまま harness である。

執筆方法論レベルの観察は LLM Harness Writing Study に記録している。