第4章 議論の変遷 ── コミュニティがどう形にしてきたか
定義から実践へ
Hashimotoの定義（2025年後半）とOpenAIの事例発表（2026年初頭）は火付け役だったが、「ハーネスエンジニアリング」という概念を産業的・工学的に体系化したのはその後の各プレイヤーによる議論の蓄積だ。
本章では主要な論者とその貢献を時系列に整理し、どこに合意が形成され、どこに依然として議論が残っているかを示す。
Birgitta Böckeler（Martin Fowler.com）：工学的体系化
2026年初頭、ThoughtWorksのシニアエンジニアBirgitta Böckelerが Martin Fowler.com にハーネスエンジニアリングを主題とした記事を寄稿した。この記事は概念の工学的定義として最も広く参照されているものの一つだ。
Böckelerはハーネスを「決定論的アプローチとLLMベースアプローチを組み合わせた統合システム」と定義し、三つの構成軸を提示した。
mindmap
root((ハーネス))
コンテキストエンジニアリング
動的オブザーバビリティデータ
ブラウザ操作の自動化
充実した知識ベース
アーキテクチャ制約
カスタムリンター
ArchUnitによる構造テスト
AI + 決定論的ツールの併用
定期クリーンアップ
矛盾検知エージェント
制約違反スキャン
ドキュメントの自動更新Böckelerの最も挑発的な提言は「新世代のサービステンプレート」論だ。
従来のサービステンプレート（チームが新サービスを立ち上げる際の標準的な出発点）は、CI/CDパイプライン、ロギング設定、テストフレームワーク等を含んでいた。Böckelerはその延長線上にハーネスを位置づける。次世代のサービステンプレートはAIエージェント向けに最適化されたハーネスを含む、という主張だ。
これに関連してもう一つの提言がある。エージェントが使いこなせるテックスタックは多様ではない。訓練データに豊富に含まれる技術でなければ、エージェントの判断精度は落ちる。結果として、「AIエージェント保守性の観点から、採用するテックスタックが絞り込まれていく」という収束論だ。この観点から 「退屈な技術を選べ」 という格言が生まれた。
LangChain：解剖学的整理
LangChainは “The Anatomy of an Agent Harness” において、ハーネスを構成要素単位で解剖した。その核心は一行で表現できる。
Agent = Model + Harness
モデルが「知性」を担い、ハーネスが「機能性」を担う。この式はシンプルだが、実装上の含意は多い。モデルを替えてもハーネスは使い回せる。ハーネスの品質がエージェントの実用性を決める。
LangChainが整理したハーネスの構成要素は以下だ。
| 構成要素 | 役割 | 実装例 |
|---|---|---|
| ストレージ・状態管理 | ファイルシステム・Git・DB | ロールバック可能な変更管理 |
| 実行環境 | サンドボックス化されたシェル | 安全なBash実行、権限制御 |
| 知識アクセス | AGENTS.md・MCP・Webサーチ | プロジェクト固有知識の注入 |
| コンテキスト最適化 | コンパクション・ツール出力整形 | ウィンドウ圧迫の防止 |
| 長時間実行サポート | 自己検証ループ・Ralphパターン | 早期終了の防止 |
RalphパターンはLangChainが命名したパターンで、エージェントの早期終了を防ぐ強制継続ループのことだ。エージェントは「完了した」と判断した時点でタスクを終わらせようとする。しかし「完了の判断」が正しいとは限らない。Ralphパターンはエージェントに「本当に完了したか」を自己問答させ、完了条件を満たすまでループを継続させる。
Anthropic：長期実行エージェントへの特化
Anthropicは “Effective Harnesses for Long-Running Agents” において、複数コンテキストウィンドウにまたがるタスクという難問に焦点を当てた。
従来のエージェント議論の多くは単一セッションを前提にしていたが、実際のプロダクション開発では1タスクが複数日・複数セッションにまたがることがある。セッションが終わると「記憶」は消える。これをどう扱うか。
Anthropicの提案は二段階アーキテクチャだ。
sequenceDiagram
participant U as ユーザー
participant IA as 初期化エージェント
participant CA as コーディングエージェント
U->>IA: 高レベルの仕様を渡す
IA->>IA: 200+項目の具体的要件に展開
IA->>U: 機能リスト（JSON）を提示
U->>IA: 承認・修正フィードバック
IA->>CA: 検証済み要件を渡す
loop 各機能の実装
CA->>CA: 実装 → テスト → コミット
CA->>CA: progress.txt を更新
end
Note over CA: セッション終了・再開時
CA->>CA: progress.txt を読み込み
CA->>CA: 前回の続きから再開このアーキテクチャには明確な役割分担がある。
初期化エージェントは「何を作るか」を確定させる。高レベルの仕様を受け取り、それを200項目以上の具体的・テスト可能な要件（JSON形式）に分解する。各要件には「検証方法」が明示される。このフェーズに人間のレビューと承認が入る。
コーディングエージェントは「どう作るか」のみに集中する。承認された要件を順に実装し、テストし、コミットする。セッションをまたいでも、progress.txt と feature-list.json を参照することで継続性が保たれる。
HumanLayer：「スキルイシュー」フレーミング
HumanLayer は少し異なる角度からハーネスエンジニアリングを論じた。
彼らの主張の核心は「エージェントの問題はスキル（モデルの能力）の問題ではなく、設定の問題だ」というものだ。「もっと良いモデルが出るまで待つ」という姿勢を批判し、現在のモデルでも、適切に設定されたハーネスがあれば十分高品質な仕事ができる、と主張する。
よくある認識（誤り） ハーネス観点（正しい）
「エージェントがテストを → 「テストを書かせる設定が
書かない」 ないか、書いても確認されない
仕組みになっている」
「エージェントが間違いを → 「間違いを検知して
繰り返す」 自動修正する仕組みがない」
「エージェントが完成と → 「完成条件が定義されておらず、
言うのに壊れている」 エージェントが自己申告で終わる」この「スキルイシュー」フレームは、エンジニアの自己効力感を取り戻させるという意味でコミュニティに受け入れられた。モデルの能力は自分で変えられないが、ハーネスの設計は自分で変えられる。
Ignorance.ai：新興プレイブック
“The Emerging ‘Harness Engineering’ Playbook” は実践者の知見を集約した記事だ。Boris Taneをはじめ複数の実践者の体験が引用されており、コミュニティの現状把握としての価値が高い。
この記事で注目すべきは、著名な実践者たちの発言が同じパターンに収束していることだ。
Peter Steinberger（PSPDFKit創業者）：「すべてのコード行を読まずにコードを出荷するが、アーキテクチャと設計の決定は注意深く管理する」
Boris Tane（Baselime創業者）：「計画を確認して承認するまで、エージェントにコードを書かせてはいけない」
Anthropicのドキュメント：「ハーネスを事前設計する誘惑に抵抗せよ。シンプルに始め、実際の失敗を観察し、実際の問題への対応としてインフラを追加せよ」
三者の言葉は異なるが、指しているものは同じだ。人間はアーキテクチャを管理し、エージェントは実装を担い、ハーネスはその橋渡しをする。
収束した合意と残る議論
2026年前半時点で、コミュニティが収束した合意と、依然として議論が続いている点を整理する。
合意が形成されているもの
- AGENTS.md は「失敗の記録」として継続更新する
- アーキテクチャ制約はドキュメントではなく機械的に強制する
- 計画と実装のフェーズを分離し、計画に承認を挟む
- フィードバックはエラーのみを表示し、成功出力でコンテキストを圧迫しない
- 先回りのハーネス設計は避け、実際の失敗を待って対処する
依然として議論が続いているもの
- グリーンフィールドでの成果がレガシーコードベースで再現できるか
- マルチエージェント並列実行の競合をどう防ぐか
- モデルの世代が上がったときにハーネスの設計をどうアップデートするか
- 「ハーネスエンジニアリング」の定義範囲（コンテキスト管理を含む派 vs 含まない派）
次章では、これらの議論の中で実践者が「効いた」と報告するベストプラクティスを具体的に掘り下げる。