# Harness Engineering

AIエージェントでシステムを構築するとき、昔はコンテキスト!コンテキスト!って言ってたけど、最近はハーネス!ハーネス!って言っている気がする。また数か月後には別の名前になっているかもしれない。まぁ**コンテキストエンジニアリング** にしろ **ハーネスエンジニアリング** にしろ、AIエージェントを使うときの思考のフレームワークみたいなものなので、言葉遊びの域を出ない気もする。

ハーネスとは、動物を制御したり人を安全に固定するベルトやストラップを指すので[^1]、AIエージェントを制御するとか、そういうニュアンス

コンテキストエンジニアリングについては[昔メモした]({{< relref "../../2025/11/02_context_engineering.md" >}})ので、今回はハーネスエンジニアリングのメモ

## Agent = Model + Harness

LangChainのブログでは、AIエージェントのモデル以外の全てがハーネス、と言い切っている。

{{< embed url="https://www.langchain.com/blog/the-anatomy-of-an-agent-harness" >}}

> A harness is every piece of code, configuration, and execution logic that isn't the model itself. 
>
> _(ハーネスとは、モデル本体以外のすべてのコード、設定、および実行ロジックを指します。)_

エージェントに望む動作（修正）を行うための動作を機能セットとして落とし込む、これをハーネス設計としている。この記事を引用する形で、ThoughtworksのBirgitta Böckeler氏はもう少しハーネスエンジニアリングを体系化している。

{{< embed
  url="https://martinfowler.com/articles/harness-engineering.html"
  og_title="Harness engineering for coding agent users"
  og_description="A mental model for building trust in coding agents through feedforward guides, feedback sensors, and iterative harness engineering."
  og_image="https://martinfowler.com/articles/harness-engineering/card.png" >}}

{{< image url="https://martinfowler.com/articles/harness-engineering/harness-bounded-contexts.png" caption="ブログ記事の図1より: 「ハーネス」という用語は、文脈によって意味が異なる" size="75%" >}}

ハーネスには事前に予測するガイド型（フィードフォワード）と動作後にわかるフィードバック型があり、それらの学習ループを回すことが大事。

### OpenAI's Harness Engineering

本家OpenAIが、コーディングを全てAIエージェントに任せられるようにソフトウェア開発全体を設計し直したエピソードを、ハーネスエンジニアリングとしてまとめている

{{< embed
  url="https://openai.com/index/harness-engineering/"
  og_title="Harness engineering: leveraging Codex in an agent-first world"
  og_description="By Ryan Lopopolo, Member of the Technical Staff"
  og_image="https://images.ctfassets.net/kftzwdyauwt9/2TjayW57xam6dBbbV28sae/887861e21b8d205c2c392ec5315d3681/SEO.png?w=1600&h=900&fit=fill" >}}

* コードは全てCodexが記述した。人が書く時間の1/10ほどの時間と推定される
* 人間は、大きな目標をデザインやコードに分解し、エージェントがそれらタスクのブロックを解決する **環境づくり** に集中した
* 人間によるQAチェックがボトルネックになってきたため、アプリ起動や監視メトリクスもAIエージェントが参照できるようにし、エージェントを強化した
* 巨大な単一のドキュメントではなく、簡潔な `AGENT.md` と構造化された `docs/` がエージェントに検証させるときのコツ
* エージェントのコンテキストの外にある情報は「知らない情報」と同義（例: Slackでの人間の議論など）。全てアーティファクトとしてエージェントがアクセスできるようにし、場合によっては車輪の再発明も行う
* アーキテクチャ制約（例: スキーマ検証、命名規則など）はエージェントにとっては拡張機能の1つ
* 高スループットを活用した開発へと変わる。とにかく修正、待機は悪
* 運用していくとエージェントは既存の設計を再実装しがちなため、定期的にガーベージコレクションするような"黄金律"をリポジトリに入れた

記事中では「ハーネス」という単語は"Evaluation harnesses"でしか使われていないが、「AIエージェントを制御・運用する仕組み（ハーネス）を設計することがソフトウェア開発の本質になった」という意図で、ハーネスエンジニアリング、というタイトルなんだろう、多分。

## AutoHarness

チェスなどのゲームの「ルールを遵守する」というハーネスをAIエージェントに記述させる **AutoHarness** というフレームワークがある。DeepMindの研究で、ICLR2026の[RSI Workshop](https://recursive-workshop.github.io/papers.html)にて採択されている。

{{< embed url="https://arxiv.org/abs/2603.03329" og_image="https://info.arxiv.org/brand/images/brand-logo-primary.jpg" >}}

行動ポリシーの更新をツリー上で管理し、[Thompson sampling](https://en.wikipedia.org/wiki/Thompson_sampling)で探索し、ルール遵守をコード化する。ルールという前提条件があれば、プランニングを利用してハーネスそのものも生成できる、という一例。

### まとめ

* **Context Engineering**（再掲）: AIシステムがタスクを理解し、実行するために使用する情報を、設計・構造化・最適化する手法
* **Harness Engineering**: AIエージェントが安全・確実にタスクを実行できるように、ツール・制約・検証・フィードバックループを設計・構造化・最適化する手法。

[Akshay](https://x.com/akshay_pachaar)氏ははっきりと、プロンプト、コンテキスト、ハーネスという3層のエンジニアリング構造があると明記している[^2]。同氏の、各ベンダーのハーネスツールの考え方の違いの表が面白かった。

<span class="hidden-footnote-refs">[^2]</span>
{{< image url="https://pbs.twimg.com/media/HFOZ6DqawAAMSNf?format=jpg" caption="同氏投稿より、各社ハーネス実装早見表[^2]" zoom="true" >}}

[^1]: [HARNESS | English meaning - Cambridge Dictionary](https://dictionary.cambridge.org/dictionary/english/harness)
[^2]: [Akshay 🚀 on X: "The Anatomy of an Agent Harness " / X](https://x.com/akshay_pachaar/status/2041146899319971922)

