ハーネスエンジニアリングの現在地 — 2026年4月時点の用語マップ¶

対象:

AIコーディングエージェントを実務で使い、「ハーネスエンジニアリング」という言葉の定義の揺れに整理を求める開発者・テックリード。3月公開の5層モデル記事の続編。

この記事のポイント¶

この章が答える問い: この記事で先に持っておくべき地図は何か。

2026年4月時点で「ハーネス」の定義は各社で割れている。が、「誰が組むか」で二層化するとほぼ整理がきく
ユーザー側の整理は「ガイド/センサー × 計算的/推論的」の2×2が骨格
既存5層モデル (制約/情報/検証/回復/レビュー) と二層×2×2は直交関係にあり、組み合わせて使える

この記事の問いは単純である。同じ「ハーネス」という言葉で違う話が混ざるとき、実務者はどの地図を使えば迷わず判断できるのか。

なぜ「ハーネス」が掴みにくいのか¶

この章が答える問い: なぜ同じ「ハーネスエンジニアリング」という言葉で人によって違うものを指しているのか。

「ハーネス」という語は、もともと馬具を指す。AI分野では、少なくとも2021年のEleutherAI lm-evaluation-harness によって、モデルを一定条件で走らせる評価基盤の名前として使われていた⁹。2024年にはCopilot Evaluation Harnessのように、IDE上のLLM支援を評価する文脈にも広がった¹⁰。

2026年初頭になると、Mitchell HashimotoがAI活用の第5段階として「Engineer the Harness」と名付けた⁷。その数日後、OpenAIがCodexで大規模にソフトウェアを作る実践報告を公開し、ハーネスエンジニアリングという言葉は一気に開発者の語彙へ入った⁴。

広く議論される分野で用語が揺れるのは普通である。問題は、言葉の広まり方が速すぎたことだ。LangChain、Anthropic、OpenAI、Thoughtworks、個人の実践者が、それぞれのプロダクトや関心に合わせて「ハーネス」を語り始めた。

ここで混乱の芯が見える。ベンダー側が作る土台の話と、利用者側が自社コードベースに合わせて足す外側の話が、同じ言葉で混在している。

一番効く整理軸: 誰が組むハーネスか¶

この章が答える問い: この混乱を最低限の労力で抜けるには、どの軸で切ればいいか。

最初に切るべき軸は「誰が組むか」である。Birgitta BöckelerはMartin Fowlerサイトで、モデルの外側に「ビルダーハーネス」と「ユーザーハーネス」が重なる同心円モデルを示した¹。この二層化だけで、かなりの混乱は解ける。

ビルダーハーネスは、Anthropic、OpenAI、Cursorなどのエージェント開発元が出荷時に組み込む土台である。システムプロンプト、ツール定義、エージェントループ、コンテキスト圧縮、メモリ管理、サンドボックスなどがここに入る。

LangChainのHarrison Chaseは、Claude Codeのリーク資料について「512k lines」と紹介している³。これはOpenAIが推奨した短いAGENTS.mdの約100行⁴と比べると、3桁以上大きい規模である。真偽や内訳は別として、ビルダー側の土台が巨大になり得ることは伝わる。

ユーザーハーネスは、利用者が自社コードベースに合わせて組む外側である。AGENTS.md、Skills、Hooks、MCP、lint/test、レビューエージェント、設計ドキュメント、CIの品質ゲートがここに入る。

重要なのは、多くの開発者にとって関心領域はユーザーハーネスだけで十分だという点である。Claude CodeやCodexの中身を書き換える必要はない。手元で設計すべきなのは、自社のコード・ルール・検証・回復をどう外側に置くかである。

各社の定義が割れている理由¶

この章が答える問い: なぜ各社・各人の定義が違うのか。混乱は本当に解消可能なのか。

定義の差は、かなりの部分を「そのプレイヤーが何を売っているか」で説明できる。エージェント基盤を売る会社は広く定義する。自社エージェントの設計を語る会社は制御ループを強調する。利用者向けガイドは、宣言的制約やサンドボックスに寄る。

プレイヤー	ポジション	定義のキーフレーズ	主な関心領域
LangChain	エージェント基盤	Model + Harness	状態・ツール・実行
Anthropic	エージェント開発元	制御ループ	長時間実行・評価
OpenAI	Codex実践者	環境と制約	リポジトリ知識・検証
Birgitta Böckeler	コンサル視点	ガイドとセンサー	利用者側の制御
Phil Schmid	教育的整理	Harness = OS	長時間タスク基盤
Ashpreet Bedi	システム設計	普通のソフトウェア	全体最適・運用

LangChainのVivek Trivedyは「Agent = Model + Harness」と置き、モデル以外のコード・設定・実行ロジックを広くハーネスに含める²。この定義は、利用者にエージェントを作らせるプラットフォームの視点として自然である。

AnthropicはClaude Agent SDKや長時間実行の実験を語るため、ハーネスを「LLMを呼び、ツールを回し、状態を引き継ぐ制御ループ」として扱う⁵⁶。OpenAIはCodex利用者に向けて、短いAGENTS.md、構造化されたdocs/、サンドボックス、custom linters、structural testsを強調する⁴。

Birgittaは、利用者が組む外側の制御をサイバネティクスの言葉で説明する¹。Phil Schmidは、モデルをCPU、コンテキストをRAM、ハーネスをOSに喩えた¹¹。Bediは、agentic softwareを「普通のソフトウェアにエージェントが入ったもの」と捉え、agent/data/security/interface/infrastructureをまとめて設計すべきだと主張する¹³。

どの定義も完全な間違いではない。立場が違うだけである。読者に必要なのは、まず立場が「エージェント開発元」なのか「コーディングエージェント利用者」なのかを確認することだ。

ユーザーハーネスを切るもう一つの軸¶

この章が答える問い: ユーザーハーネスの内側はどう構造化されているか。

利用者側のハーネスは、もう一段だけ分解できる。Birgittaの軸を使うと、横軸はガイド/センサー、縦軸は計算的/推論的である¹。ガイドは行動前に確率を上げる。センサーは行動後に検知して自己修正させる。

2×2

ガイド
行動前

センサー
行動後

計算的
決定論

LSP
CLI
codemod

linter
型チェック
ArchUnit / test

推論的
LLM判断

AGENTS.md
Skills
設計ドキュメント

AIコードレビュー
LLM-as-judge
設計レビューagent

CLAUDE.mdやSkillsを整えるだけだと、右上の推論的ガイドしか埋まらない。これは効果があるが、センサーがなければ失敗を見つけられない。計算的なガイドがなければ、いつもLLMの判断に頼ることになる。

ただし、全象限を埋めなければならない、という話でもない。構造違反が多いチームなら計算的センサーを先に置く。仕様の読み違いが多いなら推論的ガイドを整える。AIレビューが重いなら、先にlintや型チェックへ寄せる。

既存5層モデルとの対応¶

この章が答える問い: 3月の既存記事で示した5層モデルは、Birgittaの二層×2×2とどう関係するのか。

3月の5層モデル記事では、ハーネスを制約 / 情報 / 検証 / 回復 / レビューに分けた⁸。これは「何を制御するか」を見る軸である。一方、Birgittaのガイド/センサー軸は「いつ制御するか」を見る。

5層	ガイド (前)	センサー (後)
制約	サンドボックス境界権限・編集範囲	ほぼ存在しない構造的に弾くためガイド側で完結
情報	AGENTS.md / Skills 設計ドキュメント	Context Rot監視古い文書の検知
検証	型 / 契約 / スキーマ受け入れ条件	lint / test / ArchUnit CI品質ゲート
回復	自己修正プロンプトロールバック方針	エラーメッセージ最適化失敗ログの要約
レビュー	レビュー観点指示重大度分類	AIレビューエージェント LLM-as-judge

この表がこの記事の中心である。5層は何を制御するか、2×2はいつ・どう制御するかを示す。 軸が違うので、両者は重複しない。直交して補完する。

もう一つ見えることがある。5層を上から下に見ると、制約・情報は比較的決定論寄りで、回復・レビューは確率的でコストが高くなりやすい。つまり、下の層を増やす前に、上の層で構造的に潰せないかを確認した方がよい。

境界はグラデーションで動く¶

この章が答える問い: ビルダー/ユーザーの二項対立は、現場ではどう崩れているか。

二層モデルは便利だが、境界は固定ではない。Claude Agent SDKはClaude Codeのツール、エージェントループ、コンテキスト管理をライブラリとして使えるようにしている¹⁴。OpenAIのCodex SDKも、Codex CLIを支えるagent implementationを自社ワークフローへ組み込める¹⁵。

この中間層では、純粋なビルダーハーネスでも純粋なユーザーハーネスでもない設計が増える。典型例は、GeneratorとEvaluatorを分ける構成、決定論的ステップとエージェント自由を交互に配置するパイプライン、SDKでツール承認やセッション管理を自前UIに接続する構成である。

Garry Tanの「Thin Harness, Fat Skills」は、この中間層を薄く保つ考え方として読める¹²。ハーネスは約200行程度の薄いCLIにし、知能はSkillsへ、実行は決定論的ツールへ寄せる。すべてをハーネスに詰め込まない、という設計判断である。

境界はさらに曖昧になる。SDKが増えるほど、利用者はビルダー側の部品を借りながら、自社専用のオーケストレーションを組めるようになる。

どこまで頓着するか¶

この章が答える問い: 結局、明日から何をすればいいか。

結論は、用語に頓着しすぎなくていい、である。必要なのは、自分のチームがどの地図で迷っているかを見つけることだ。

判断軸は3つで足りる。

2×2のどの象限が手薄か
5層のどの段階に投資余力があるか
ビルダーハーネスを書く必要が本当にあるか

大半のチームで、3つ目の答えはNoである。既製のClaude CodeやCodexを使い、外側にAGENTS.md、Skills、Hooks、MCP、lint/test、レビューを足せばよい。最小テンプレートはこれで足りる。

AGENTS.md
- 変更前に関連する設計文書を読む
- 変更後に `npm test` と `npm run lint` を実行する
- 失敗したら原因と次の一手を短く残す

ただし、「CLAUDE.mdを書いたらハーネスエンジニアリング」で止まるのは罠である。推論的ガイドだけでは、計算的センサーの実行ループ、検証ループ、効果計測が抜けやすい。失敗を検知しない仕組みは、失敗を学習しない。

用語の整理は地図にすぎない。地図を握ったら、自分のチームの地形に戻る。