■ 1. 概要
- 本資料はKinopee（きのぴー）による「ハーネスエンジニアリングとは何か」をテーマとした発表スライドである（2026年4月24日）
- ハーネスエンジニアリングという概念には複数の流派が存在し、論者によって定義と重心が異なる
- 資料はハーネスエンジニアリングの5つの流派の整理と、ハーネス・ガードレール・フィードバックループの実践的解説の2部構成をとる
■ 2. ハーネスエンジニアリング 5つの流派
- Chase派（広義・分類論）:
- 代表者はHarrison Chase（LangChain創業者）
- 出典は2025年10月のブログ記事「Agent Frameworks, Runtimes, and Harnesses」
- 原器はDeepAgents（LangChain）
- framework / runtime / harness の三分類を提示し、モデル以外のすべての構成要素（ツール・メモリ・サブエージェント・ガードレール・オーケストレーション・リトライ・状態管理）をハーネスに包含する
- ハーネスは「コンテキストを生成する外側の層」であり、コンテキスト設計はその一構成要素として位置づけられる
- 代表フレーズは「If you're not the model, you're the harness.」（Vivek Trivedy）
- Hashimoto派（運用哲学・失敗駆動）:
- 代表者はMitchell Hashimoto（HashiCorp創業者）
- 出典は2026年2月の自身のブログ記事で、OpenAI Codex事例と合わせて急速に普及
- 原器はAGENTS.md / CLAUDE.md / .cursorrules
- エージェントが失敗した際に同じミスが物理的に発生しないよう環境を再設計することを基本原則とする
- AGENTS.mdに失敗防止ルールを一行ずつ追加していく「運用の累積」がハーネスエンジニアリングの実体である
- ハーネスは設計物ではなく育てていくプロセスとして捉える
- 日本の.cursorrules運用者と地続きであり、現場感覚に最も近い流派とされる
- サイクルは「実行→失敗→AGENTS.mdへの追記→再発不能」の繰り返しである
- Fowler派（狭義ハーネス・制御理論）:
- 代表者はMartin Fowler（Thoughtworks Distinguished Engineer）
- 出典は2026年のThoughtworks記事「Harness engineering for coding agent users」
- 原器はClaude Code / Cursor / Devinなどコーディングエージェント全般
- 5流派の中で唯一、ハーネスをコンテキストの内側（特殊形）に位置づける
- guides（feedforward制御：事前ルール・制約）とsensors（feedback制御：テスト・lint・事後検証）の両輪でエージェントを信頼に足るものにする
- 「不要な出力を事前に防ぐ仕組み」と「逸脱を検知して自己修正させる仕組み」の組み合わせとして定義する
- 制御工学の語彙（フィードバックループ・センサー）に接続する理論志向をとる
- 代表フレーズは「ハーネス設計はコンテキスト設計の特殊な一形態である」
- Chawla派（同心円モデル・OS比喩）:
- 代表者はAvi Chawla（Daily Dose of DS）および教育系ライター群
- 出典は2026年前半「The Anatomy of an Agent Harness」ほか
- 原器は特定ツールではなく概念モデル
- プロンプト・コンテキスト・ハーネスを三重の同心円で整理する
- Beren Millidge（2023）のOS比喩を継承し、LLMをCPU・コンテキストをRAM・ツールをデバイスドライバ・ハーネスをOSに対応させる
- 定義の厳密さより初学者への説明しやすさを優先する立場をとる
- Chase派と論理的には整合的だが、より図解寄り・入門記事向きの位置づけである
- 代表フレーズは「LLMはOSなしの裸のCPUだ。ハーネスがOSに当たる。」（Beren Millidge）
- Codex派（スケール駆動・プロダクション答え）:
- 代表者はRyan Lopopolo / OpenAI Codexチーム
- 出典は2026年2月のOpenAI事例公表（エンジニア3名で百万行・95%AI生成）
- 原器はOpenAI Codexおよびその内部ハーネス
- プロンプト・コンテキスト設計では解決できない、多段ステップ・自律実行・並列処理に特有の故障モードが存在することを前提とする
- それらの故障モードを解くものとしてハーネスを定義する（スケール駆動の動機づけ）
- 他流派と直接対立せず、ハーネス概念が要請された背景と理由を提供する立場をとる
- Prompt Engineering（2022年〜）→ Context Engineering（2024年〜）→ Harness Engineering（2026年〜）という進化の文脈で位置づける
- 代表フレーズは「Agents aren't hard; the Harness is hard.」（Ryan Lopopolo）
■ 3. 流派間の対立構造
- 包含関係の逆転が流派間で最も劇的な噛み合わなさを生む
- Chase派・Chawla派の立場:
- ハーネス ⊃ コンテキスト（ハーネスが外層、コンテキストを包含する）
- 総合フレームワーク設計の視点
- Fowler派の立場:
- コンテキスト ⊃ ハーネス（コンテキスト設計が外層、ハーネスはその特殊形）
- 制御理論（feedforward / feedback）の視点
- 日本に紹介する際は、どちらの意味で語られているかを毎回明示する必要がある
■ 4. ハーネスとガードレールの定義
- ハーネス（馬具）:
- 役割は走り出す前に「どう走ってほしいか」を伝える事前設計の層
- 具体的な道具はカスタムインストラクション・プラン・Skills・サブエージェント
- ハーネスは主観的な設計物であり、現場では名称がつく前から実践されてきた
- ガードレール（道を外れないための柵）:
- 役割は走った後に「道から外れていないか」を機械で自動検証する事後検証の層
- 具体的な仕組みは静的解析（lint・型チェック）・ビルド・テスト
- ガードレールは客観的な機械判定であり、判定の強度がエージェントの自律性を高める鍵となる
■ 5. フィードバックループ
- ハーネス（馬具）とガードレール（柵）だけでは、エージェントは目的地にたどり着けない
- ループの構造:
- 走らせる（エージェントにタスクをやらせる）
- 逸脱を観察（期待からのズレを検知する）
- 軌道を戻す（失敗を受けて修正・再実行する）
- 上記を繰り返す
- 具体的な適用:
- テストが落ちたら直させる
- lintが出たら修正させる
- 型が通らなければやり直させる
■ 6. 結論
- 言葉の定義の優先順位は低い
- 大切なのは期待した結果を得ることである
- ハーネス・ガードレール・フィードバックループのいずれも、今使える手段を総動員して適切な場所で適切に使い、良い結果を得ることが目的である