ハーネスエンジニアリングとは何か──「エージェント＝モデル＋ハーネス」という考え方

コーディングエージェントに「もっと自律的に働いてもらいたい」と思うほど、突き当たるのが信頼の壁だ。LLMは非決定的で、こちらの文脈を完全には理解せず、コードを「理解している」というよりトークンとして扱っている。この不信を埋めるための実践知として2026年に体系化されつつあるのが「ハーネスエンジニアリング（Harness Engineering）」という考え方だ。

「エージェント＝モデル＋ハーネス」

ThoughtworksのDistinguished Engineerであり20年以上のソフトウェア開発経験を持つBirgitta Böckeler氏は、2026年4月2日にmartinfowler.comで公開した論考「Harness engineering for coding agent users」で、この用語をこう定義している。

"The term harness has emerged as a shorthand to mean everything in an AI agent except the model itself - Agent = Model + Harness."

つまり「ハーネス」とは、AIエージェントからモデルそのものを除いた、それ以外すべてを指す略記法だ。この定義は非常に広いため、Böckeler氏は自身の論考の範囲を「コーディングエージェントを使う」という文脈に絞り込んで説明している。コーディングエージェントの場合、ハーネスの一部（システムプロンプトやコード検索の仕組み、洗練されたオーケストレーションシステムなど）はツール側にあらかじめ組み込まれているが、ユーザー側にも自分の使い方・システムに合わせて「外側のハーネス」を構築する余地が数多く提供されている、としている。

良く作られた外側のハーネスは2つの目的を果たす。エージェントが最初から正しい結果を出す確率を上げること、そして人間の目に触れる前に問題を自己修正させるフィードバックループを提供すること。結果としてレビューの手間を減らし、システムの品質を上げ、無駄なトークン消費も減らせる、という。

2つの分類軸

論考は、ハーネスを構成する要素を2つの軸で整理している。

1. フィードフォワードとフィードバック

• Guides（フィードフォワード制御）: エージェントの挙動を事前に予測し、行動前に方向づける。最初の試行で良い結果が出る確率を上げる
• Sensors（フィードバック制御）: エージェントの行動後に観測し、自己修正を助ける。LLMが消費しやすい形の信号（自己修正の指示を含んだカスタムlinterメッセージなど、「良性のプロンプトインジェクション」）を出すと特に強力だとしている

フィードバックだけだと同じミスを繰り返すエージェントに、フィードフォワードだけだとルールを組み込んでも実際に効いたかを確認できないエージェントになる、という指摘も付されている。

2. 計算的（Computational）と推論的（Inferential）

• Computational: 決定的で高速、CPUで実行。テスト・linter・型チェッカー・構造解析など。ミリ秒〜秒単位で結果が出て、信頼性が高い
• Inferential: 意味論的分析、AIコードレビュー、「LLM as judge」など。GPU/NPUで実行されることが多く、より遅く高価で、結果もより非決定的

3種類の具体的なハーネス

論考は基本概念の説明に続けて、実際にどこにハーネスを作れるかを3つの領域に分けて論じている。この部分は前回、紙幅の都合で紹介を見送っていたが、martinfowler.comの本文をcurlで再取得し、あらためて読み込んだ。

さらに論考は、コードベース自体の「ハーネスの付けやすさ（Harnessability）」にも触れている。強い型付けの言語なら型チェックが自然にセンサーとして機能し、モジュール境界が明確ならアーキテクチャ制約ルールを組みやすく、Springのようなフレームワークは詳細を抽象化することでエージェントの成功率を暗黙的に上げる。逆にこれらの性質を欠くコードベースでは、そもそもそうした制御を組めない、という指摘だ。同僚のNed Letcher氏が使う「ambient affordances（環境が備える手がかり）」という用語も紹介されており、エージェントが動作する環境自体の構造的な性質（読み取りやすさ・辿りやすさ・扱いやすさ）を指すという。

論考の終盤では、「Harness templates（ハーネステンプレート）」という発展的なアイデアにも触れている。多くの企業は、API経由でデータを公開するビジネスサービス、イベント処理サービス、データダッシュボードなど、全体の8割をカバーする少数の共通トポロジーを持っており、これらをガイドとセンサーの束として定型化した「ハーネステンプレート」に発展させられるかもしれない、という将来的な発想だ。この裏付けとして、論考のサイドバー「Ashby's Law」で、サイバネティクスの「必要多様性の法則（Ashby's Law of Requisite Variety）」を引いている。原文は2つの条件を並べて書いている——「制御者は、自分が統治する系と少なくとも同等の多様性を持たなければならない。そして制御者は、自分がモデルを持っているものしか制御できない」（原文: 「a regulator must have at least as much variety as the system it governs, and it can only regulate what it has a model of」）。LLMベースのコーディングエージェントはほとんど何でも生成できるが、トポロジーを絞ることでその空間が狭まり、包括的なハーネスが現実的になる、という論の運びだ。ただし著者自身、サービステンプレートと同じ課題（時間が経つと実装が元のテンプレートから乖離していく問題）に直面するだろうとも認めている。

他社のエージェント設計ドキュメントにも近い発想が見つかる

「ハーネス」という用語そのものはBöckeler氏の論考に沿って使っているが、似た発想が他社の技術文書にも独立に現れているかを確認するため、Anthropic・OpenAI・Claude Codeそれぞれの公式ドキュメントを直接読んだ。いずれも「ハーネス」という言葉は使っていないが、Guides/Sensorsや計算的/推論的という分類軸と重なる部分がある。

Anthropicが2024年12月19日に公開した「Building effective agents」は、複数のLLM呼び出しを組み合わせる設計パターンの1つとして「evaluator-optimizer」を挙げている。

"In the evaluator-optimizer workflow, one LLM call generates a response while another provides evaluation and feedback in a loop."

1つのLLM呼び出しが応答を生成し、別のLLM呼び出しがそれを評価してフィードバックをループさせるという設計だ。これはBöckeler氏の言う「Inferential（推論的）なSensor」に近い発想だが、この記事の公開は2026年4月のharness engineering論考より1年以上前であり、独立に生まれた設計パターンとして扱うのが妥当だろう。なお同記事には「本記事で説明しているツール群は2024年12月以降に変化しており、現在のアプローチについてはClaude Managed Agentsのドキュメントを参照してほしい」という注記が付いていることも確認できた。

OpenAIのAgents SDKドキュメント「Guardrails」は、エージェントの入力・出力・ツール呼び出しを検査する仕組みを説明している。

"If the guardrail detects malicious usage, it can immediately raise an error, saving time and money."

ガードレールが不正利用を検知すると即座にエラーを発生させ、時間とコストを節約できるという説明だ。ドキュメントによれば、ガードレールは入力用・出力用・ツール用の3種類に分かれ（見出し構成も Input guardrails / Output guardrails / Tool guardrails の3つ）、tripwire_triggeredが真になった場合に例外を発生させる仕組みだ。実行モード（Execution modes）の節は入力ガードレールの下位見出しとして置かれており、並行実行では「ガードレールが完了する前に高価なモデルが動き出している可能性がある」、ブロッキング実行では「高価なモデルが起動しないことが保証される」と説明されている。これはBöckeler氏の言う「Sensor」に相当する仕組みを、OpenAI自身が別の語彙で実装したものと見なせる。

Claude Codeの公式ドキュメント「Automate actions with hooks」は、hooksという仕組みを次のように説明している。

"Hooks are user-defined shell commands. Claude Code runs them at specific points in its lifecycle, which gives you deterministic control: certain actions always happen rather than relying on the LLM to choose to run them."

hooksはユーザーが定義するシェルコマンドで、Claude Codeがライフサイクルの特定のタイミングで自動実行し、LLMの判断に頼らず「特定の行動を必ず起こす」決定論的な制御を提供するという。これはBöckeler氏の分類でいう「Computational（計算的）」かつ「Guide（フィードフォワード）」寄りの仕組みに近い。ドキュメントは、判断を伴う条件分岐にはhooksでなく「プロンプトベースのフック」や「エージェントベースのフック」（Claudeモデル自体に条件を評価させる方式）を使うようにとも案内しており、この使い分けはBöckeler氏の「Computational対Inferential」という軸とほぼ対応している。

いずれの企業も「ハーネス」という統一用語は使っておらず、これら3つの文書とBöckeler氏の論考の間に直接の参照関係があるわけでもない。あくまで、独立に発展してきた複数の実務知が同じような形（生成と検証を分離する、決定論的なチェックと確率的な判断を使い分ける）に収束しているという状況証拠として扱うべきだろう。

人間が持っている「暗黙のハーネス」

論考は最後に「人間の役割」という節で、人間の開発者自身が持つ経験やチームの文脈理解を、一種の「暗黙のハーネス」として位置づけている。人間は規約や良い習慣を体得し、複雑さへの認知的な苦痛を実際に感じ、コミットに自分の名前が残ることを意識し、チームが何を目指しているか・どの技術的負債がビジネス上許容されているか・その文脈での「良い」が何を指すかを暗黙に把握している。一方コーディングエージェントには、社会的な説明責任も、300行の関数への美的な嫌悪感も、「うちのチームはそういうやり方をしない」という直感も、組織的な記憶もない、とBöckeler氏は書いている。

メタファーの限界について

Böckeler氏自身、「ハーネス」という比喩には限界があると認めている。「犬の内側にハーネスを付けようとしたことがあるか？」という指摘を受けたと明かしつつ、それでも実用上有用ならこの言葉を使い続ける、という立場を取っている。またこの論考は、以前公開した「ハーネスエンジニアリングについての第一印象」というメモを更新したものだと明記されている。

用語の広がり方について

本記事の作成にあたり複数の情報源を横断的に確認したところ、「ハーネス」という語自体は2026年初頭に複数の実務者から使われ始めたとされ、HashiCorp共同創業者Mitchell Hashimoto氏の2026年2月のブログ投稿や、LangChainのVivek Trivedy氏の発信を起源とする説明も見られた。ただし本記事はこれらの起源説そのものを一次資料で直接検証したわけではなく、martinfowler.comの論考本文で確認できた定義・分類のみを核として扱っている。

「ハーネス」という用語の発祥元は一次確認できていない

• 本記事はmartinfowler.com掲載のBirgitta Böckeler氏による論考（2026年4月2日付）のみを一次資料として深く読み込んでいる。「ハーネス」という用語そのものの発祥（Hashimoto氏やTrivedy氏に帰する説）については、本記事作成の過程で検索により見つけた情報であり、当該人物の一次発信（原文のブログ記事）そのものは本記事では未確認である
• 論考本文の「Maintainability harness」「Architecture fitness harness」「Behaviour harness」「Harnessability」「Harness templates」「人間の役割」の各節は、この記事のためにcurlで再取得し読み込んだ。ただし論考にはさらに「Metaphors only go so far」「context engineeringとの関係」「Ambient affordances」を扱うサイドバーもあり、それらの全文までは本記事では引用していない（「Ashby's Law」のサイドバーは上で引用した範囲のみ確認した）
• 「ハーネスエンジニアリング」が業界内でどの程度広く定着した用語なのか（一部の実務者コミュニティ内の用語か、より広く使われているか）についての普及度の検証は行っていない
• Böckeler氏が挙げる"approved fixtures pattern"（振る舞いハーネスの一部の解決策として一部の同僚が使っているという手法）の具体的な仕組みは、論考本文でも詳細な説明はなく、この記事でも深掘りしていない

関連記事

• AIコーディングアシスタント比較──Copilot/Cursor/Claude Code【2026年】
• context engineeringとは
• サブエージェントとは──分けると速くなる作業と、分けると壊れる作業
• Google「ハーネス・エンジニアリングの解剖」──行動評価をpytestで5秒
• Balyasnyの自社基盤BAMAgent──数千のエージェントを24時間、能力が上がっても権限は広げない