第1章: ハーネスエンジニアリングとは何か — 「Agent = Model + Harness」

ハーネスとは何か — モデルを「エージェント」に変える層

Claude Code、Cursor、Devin、OpenAI Codex——これらはいずれも、同じ系列の大規模言語モデル（LLM）を使いながら、振る舞いがまるで違います。 なぜでしょうか。答えは、モデルそのものではなく、モデルを取り囲むソフトウェア層にあります。この層を ハーネス（harness） と呼びます。

最も簡潔な定義は、Thoughtworks の Birgitta Böckeler が Martin Fowler のサイトで示したものです——ハーネスとは 「AIエージェントのうち、モデル自体を除くすべて（everything in an AI agent except the model itself）」。 そして LangChain の Vivek Trivedy が掲げた等式が、このシリーズ全体を貫く中心命題になります。

「harness」という英単語は、もともと馬具（馬を制御する装具）やソフトウェアのテストハーネス（テスト対象を駆動・観測する足場）を指す言葉でした。 AI の文脈では、この「対象を外から駆動・制御する足場」というメタファーがそのまま借用されています。 モデルが知性を提供し、ハーネスが手・目・記憶・安全境界を提供する——この役割分担を押さえると、エージェント開発の全体像が一気に見通せるようになります。

graph LR
  M[Model\nLLM本体\n推論・生成]
  H[Harness\nループ / ツール\nコンテキスト管理 / 権限]
  M --> A[Agent\n自律的に\nタスクを遂行]
  H --> A
  style M fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style H fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style A fill:#14b8a6,stroke:#0d9488,color:#fff

ワークフローとエージェント — 区別が出発点

ハーネスを設計する前に、そもそも「エージェント」とは何かを明確にする必要があります。 Anthropic は影響力の大きい記事「Building Effective Agents」（2024年12月、Erik Schluntz・Barry Zhang）で、両者を次のように区別しました。

重要なのは、Anthropic 自身が「多くのユースケースでは、検索とインコンテキスト例で単一のLLM呼び出しを最適化すれば十分」と述べている点です。 「エージェントを作る」と言っても、実際には固定パスのワークフローで足りる場合が大半なのです。 ハーネス設計の第一歩は、エンジニアリングの常として「本当に動的なエージェントが必要か」を見極めることにあります。

テーゼ — 「ハーネスはモデルと同じくらい重要」

なぜハーネスにこれほど注目するのか。理由は、同じモデルでもハーネス次第で性能が大きく変わるという、繰り返し観測される事実にあります。 Anthropic は SWE-bench（実際のGitHub課題でコード修正能力を測るベンチマーク）に関する記事で、こう明言しています—— 「エージェントの性能は、同じ基盤モデルを使っていても、このスキャフォールド（足場）次第で大きく変わりうる」。

この考えを最も鮮明に言い表したのが、Google の Addy Osmani です。

具体的な証拠は後の章で詳しく見ます（第5章のSWE-agentでは、モデルを変えずにインターフェース設計を改善しただけで解決率が3.8%から12.5%へ跳ね上がりました。第9章では論争の反証側も含めて検証します）。 ここではまず、「モデル選びと同じくらい、ハーネス設計が成果を左右する」という視点を持つことが出発点になります。

ハーネスの解剖 — 何でできているか

では、ハーネスは具体的に何で構成されるのでしょうか。Vivek Trivedy の整理によれば、ハーネスは次の要素から成ります。 この一覧は、そのまま本シリーズの章立てに対応しています。

注目すべきは、これらの要素がいずれも「モデルが単独ではできないこと」を補うために存在する点です。 Anthropic は「ハーネスのあらゆる構成要素は、モデルが単独ではできないことについての前提を符号化している」と述べ、 Osmani も「各ハーネス機能は、モデルが単独では実現できない振る舞いから導出される」と続けます。 この「失敗から逆算してハーネスを組む」という発想は、第10章で再び重要になります。

なぜ2026年に「規律」になったのか

ハーネスという考え方自体は新しくありません（歴史は第2章で辿ります）。しかし「ハーネスエンジニアリング」という名前を持つ独立した規律として語られるようになったのは、2026年に入ってからです。 背景には、エンジニアの関心の進化があります。

graph LR
  P[プロンプト工学\n良い指示文を書く] --> C[コンテキスト工学\n文脈を最適に\nキュレーションする]
  C --> HE[ハーネス工学\nモデル以外の\nすべてを設計する]
  style P fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style C fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style HE fill:#f97316,stroke:#ea580c,color:#fff

象徴的なのは、わずか数週間のあいだに独立した権威筋が相次いでこのテーマを論じたことです。 LangChain（Trivedy、3月10日）、Anthropic（「Harness design for long-running application development」、3月24日）、 Martin Fowler のサイト（Böckeler、4月2日）、Addy Osmani（4月19日）—— この同時多発性こそ、用語が業界に定着したことの証左だと言えます。 GitHub には「awesome-harness-engineering」のようなコミュニティ集約も生まれました。