Martin Fowler「ハーネスエンジニアリング」を読み解く ── Guides/Sensorsフレームワークの実践

この記事の位置づけ

2026年3月、「ハーネスエンジニアリング」がはてなブックマークで連日バズりました。OpenAI、Martin Fowlerサイト、個人ブログ。記事を読み比べると、同じ言葉なのに定義がバラバラです。

この記事では、Martin Fowlerサイトに掲載されたBirgitta Bockeler氏のHarness Engineering for Coding Agentsを軸に、Guides/Sensorsフレームワークを正確に解説します。さらに、各論者が何を主張しているのかを整理し、CLAUDE.mdやAGENTS.mdの設計にどう活かせるかを考えます。

ハーネスエンジニアリングとは何か

Bockeler氏の定義はシンプルです。

Agent = Model + Harness

モデル以外のすべて、つまりエージェントを取り巻く制御システム全体がハーネスです。ハーネスエンジニアリングとは、AIコーディングエージェントの出力に対する信頼性を高めるための制御システムを構築する実践を指します。

この記事が扱うのは「アウターハーネス」、つまりエージェント利用者側が構築する外側の制御です。エージェント製品の内部実装（インナーハーネス）とは区別されます。

ハーネスの語源は馬具です。馬（モデル）の力を制御し、望む方向に導く仕組み。サイバネティクスの「ガバナー（調速機）」に近い概念として説明されています。

Guides/Sensorsフレームワーク

Bockeler氏の記事の核心は、制御を2つの軸に分類する点です。

Guides（フィードフォワード制御）

エージェントが動く前に方向を与える仕組みです。問題が起きる前に予防します。

具体例	説明
AGENTS.md / CLAUDE.md	コーディング規約、プロジェクト構造の指示
ブートストラップスクリプト	新規プロジェクトのセットアップ手順
アーキテクチャドキュメント	システム設計の方針と制約
LSP統合	言語サーバーによるリアルタイムの型情報提供
MCPサーバー	チームのナレッジベースへの接続
API仕様 / Skills	ツールの使い方を定義した参照ドキュメント
コードモッド / OpenRewriteレシピ	構造変更のパターン定義

Sensors（フィードバック制御）

エージェントが出力した後に品質を検知し、自己修正を促す仕組みです。

具体例	説明
静的解析 / Linter（ESLint, Semgrep）	コードスタイルとパターン違反の検出
型チェッカー	型の整合性を検証
テストスイート / カバレッジ監視	機能の正当性とカバレッジの確認
ミューテーションテスト	テストの品質そのものを検証
コードレビューエージェント	LLMによるセマンティックな判断
依存関係スキャナー	脆弱性とライセンスの検出
デッドコード検出	不要コードの特定
アーキテクチャ制約チェック（ArchUnit）	モジュール境界の違反検出
パフォーマンステスト	レスポンス劣化の検知
ランタイム監視（SLO、エラー率）	本番環境でのフィードバック

なぜ2軸に分けるのか

片方だけでは制御が成立しません。それぞれが単独で破綻するメカニズムを掘り下げます。

Guidesだけでは破綻する理由

CLAUDE.mdに100個のルールを書き、MCPで大量のドキュメントを接続する。一見、万全に見えます。しかし3つの構造的な問題があります。

第一に、検証手段の不在です。ルールが守られているかを確認する仕組みがなければ、エージェントがルールを無視しても気づけません。CLAUDE.mdに「テストを書いてから実装する」と書いても、実際にテストが先に書かれたかを検知するSensorがなければ、ルールは願望にすぎません。

第二に、コンテキストウィンドウの圧迫です。LLMのコンテキストウィンドウは有限です。Guidesを増やすほど、実際のタスクに使える領域が減ります。100個のルールのうち、今のタスクに関係するのは5個かもしれません。残り95個はノイズとして推論精度を下げます。

第三に、過剰適応の問題です。制約を詰め込みすぎると、エージェントはルールに従うこと自体が目的化し、ルールに書かれていない状況で判断停止します。「CLAUDE.mdに書いてないからできません」という応答が増えるのは、Guidesの過積載が原因であることが多いです。

Sensorsだけでは破綻する理由

Linterとテストを充実させれば、品質は測定できます。しかしこちらにも3つの問題があります。

第一に、トークンの浪費です。方向の指示がないまま走り出したエージェントは、高確率で間違った方向に進みます。Sensorが検出して修正を指示し、エージェントがリトライする。このループが3回、5回と繰り返されると、1回目で正しく走った場合の数倍のトークンを消費します。

第二に、自己修正ループの非収束です。エージェントが「Linterエラーを直す→別のエラーが出る→直す→最初のエラーが再発する」というサイクルに入ることがあります。Guideで設計方針を示していれば回避できた問題に、Sensorだけで対処しようとすると泥沼化します。

第三に、Sensorが検出できない問題の存在です。「動くけど設計が悪い」「テストは通るがビジネスロジックが間違っている」といった問題は、Computational Sensorsでは原理的に検出できません。Guideで意図と方針を伝えておかなければ、Sensorをすり抜ける問題が蓄積します。

両輪が揃って初めて制御が成立する

Bockeler氏はこの組み合わせを、サイバネティクスのフィードフォワード制御とフィードバック制御の両輪として説明しています。Guidesで「最初の一手」の精度を高め、Sensorsで「外れた場合」の修正速度を上げる。この両輪が揃うことで、エージェントの出力が一定品質に収束するまでの時間とコストが最小化されます。

GuidesとSensorsは独立した2つの投資対象です。Guidesへの投資（ドキュメント整備、MCPサーバー構築）とSensorsへの投資（テスト充実、Linter設定）を意識的にバランスさせる必要があります。今のプロジェクトでどちらが手薄かを判断する簡単な方法は、「エージェントが最初の出力で間違える」ならGuide不足、「間違いに気づかず完了と報告する」ならSensor不足です。

Computational vs Inferential：もう1つの軸

Bockeler氏はGuides/Sensorsに加え、制御の実行方式も区別しています。

	Computational（計算的）	Inferential（推論的）
実行基盤	CPU、決定論的	LLM/GPU、確率的
速度	ミリ秒〜秒	秒〜分
コスト	低い	高い
具体例	Linter、型チェッカー、テスト	コードレビューエージェント、AI Judge
得意領域	客観的な違反検出	意味レベルの判断、文脈依存の評価

この区別が重要なのは、コストと信頼性のトレードオフが根本的に異なるからです。

Computational Sensorsは決定論的です。同じコードに対して同じLinterを走らせれば、毎回同じ結果が返ります。コストはほぼゼロで、毎回の変更で回せます。一方、Inferential Sensorsは確率的です。同じコードに対してコードレビューエージェントを走らせても、指摘内容が毎回微妙に変わります。コストも高く、CIパイプラインやポストマージで実行するのが現実的です。

ここから導かれる設計原則は明確です。ルールで表現できる品質基準はすべてComputational Sensorsに落とし込み、「意味的に正しいか」「設計意図に沿っているか」といった判断だけをInferential Sensorsに任せる。この棲み分けができていないと、LLMベースのレビューエージェントがセミコロンの有無を指摘するような無駄が発生します。

実例を挙げます。「関数は50行以内」というルールをコードレビューエージェント（Inferential）に判定させているチームがあったとします。これは行数カウントという純粋に計算的な判定です。ESLintの max-lines-per-function ルール（Computational）に置き換えるだけで、判定速度は数百倍になり、コストはほぼゼロになり、しかも判定結果が安定します。Inferential Sensorsは「この関数は責務が多すぎないか」という意味レベルの判断に集中させるべきです。

CLAUDE.md / AGENTS.mdをGuides/Sensorsで分類する

実際のCLAUDE.mdから例を挙げて分類します。筆者のプロジェクトで運用しているルールです。

Guidesに該当するルール

# CLAUDE.md より抜粋
- シンプル第一: 変更をできる限りシンプルに。影響するコードを最小限にする
- 3ステップ以上のタスクは必ずPlanモードで開始する
- メインのコンテキストをクリーンに保つため、リサーチはサブエージェントに任せる

これらはエージェントの行動方針を事前に定めるフィードフォワード制御です。エージェントが作業を始める前にコンテキストウィンドウに読み込まれ、判断の方向性を制約します。

このGuideがなかった場合に何が起きるかを具体的に見てみます。「3ステップ以上のタスクは必ずPlanモードで開始する」というルールがないと、エージェントは複雑なリファクタリングでもいきなりコードを書き始めます。途中で設計の矛盾に気づいて手戻りし、既に変更した5ファイルを元に戻すところからやり直す。筆者の経験では、このルールの有無でタスク完了までのトークン消費量が2〜3倍変わることがありました。Guideの価値は「最初の一手の精度」に直結します。

Sensorsに該当するルール

# CLAUDE.md より抜粋
- 動作を証明できるまでタスクを完了とマークしない
- テストを実行し、ログを確認し、正しく動作することを示す
- コードを読まずに書かない: ファイルを読んでいないコードを直接書くのは禁止

これらは出力後の検証を義務づけるフィードバック制御です。エージェントが「完了」と判断する前にセルフチェックを挟ませます。

「コードを読まずに書かない」というルールは、一見すると当たり前に思えます。しかしこのSensorがないと、エージェントはコンテキストウィンドウの残りが少なくなったとき、ファイルを読む手間を省いて「たぶんこうだろう」で書き始めます。既存のインターフェースと異なる引数の順序、既に定義されているユーティリティ関数の再実装、プロジェクト規約と異なる命名。これらはLinterでは検出できない類の問題です。このルールがSensorとして機能することで、エージェントは「まず読む、次に書く」という行動パターンを維持します。

GuidesでもSensorsでもあるルール

# CLAUDE.md より抜粋
- 途中でうまくいかなくなったら、無理に進めずすぐに立ち止まって再計画する

これはGuide（事前の行動指針）であると同時に、エージェント自身の「うまくいっていない」という内部センシングを前提としたSensorでもあります。このような二面性を持つルールは実際に多く、分類は必ずしも厳密である必要はありません。

MCPサーバーの位置づけ

MCPサーバーは主にGuideです。ナレッジベース、API仕様、チーム規約などの情報をエージェントに供給します。ただし、MCPを通じてLinter結果やテスト結果を返す場合はSensorとしても機能します。

用語の混乱を整理する：誰が何を言っているのか

はてなブックマークで「全員が違うことを言っている」と話題になりました。各論者の主張を整理します。

論者	用語	定義	焦点
Phil Schmid（Google DeepMind）	Context Engineering	適切な情報とツールを、適切な形式で、適切なタイミングで提供する体系	LLMのコンテキストウィンドウに何を入れるか
Andrej Karpathy（OpenAI元VP）	Context Engineering / Agentic Engineering	コンテキストウィンドウを適切な情報で満たす技芸。Agentic Engineeringはエージェント群のオーケストレーション	コンテキスト設計とエージェント協調
Mitchell Hashimoto（HashiCorp創業者）	Harness Engineering	エージェントの間違いを見つけたら、二度と起こさないよう環境側を改善する	失敗からの学習ループ
Aakash Gupta（プロダクトアナリスト）	Agent Harness	モデルの周囲に構築する制御インフラ全体。「モデルはエンジン、ハーネスは車」	差別化要因としてのインフラ
OpenAI（Codexチーム）	Harness Engineering	エージェントが正しく動ける環境を最初から設計する	Codexでの100万行実績
Birgitta Bockeler（Martin Fowlerサイト）	Harness Engineering	Guides/Sensorsによる体系的な制御アーキテクチャ	制御の分類と設計戦略

3つの概念の関係

整理すると、これらは包含関係にあります。

Context Engineeringは最も広い概念です。Phil Schmidの定義では、プロンプト、メモリ、RAG、ツール、出力形式など、LLMに渡す文脈のすべてを設計する体系です。

Harness Engineeringは、Context Engineeringの中でもコーディングエージェントの制御に特化した実践です。Bockeler氏自身が「ハーネスエンジニアリングはコンテキストエンジニアリングの特定形態」と位置づけています。

Agentic Engineeringは、Karpathyが提唱する「人間が直接コードを書かず、エージェント群をオーケストレーションする」開発スタイルの総称です。ハーネスエンジニアリングは、そのスタイルを実現するための具体的な設計手法と言えます。

Hashimotoの定義はボトムアップ（失敗から学んで環境を改善）、Bockelerの定義はトップダウン（制御アーキテクチャを体系的に設計）です。アプローチは違いますが、目指す先は同じです。

変更ライフサイクルへの配置

Bockeler氏は制御を時間軸でも分類しています。

統合前（コーディング中）

• LSP、アーキテクチャドキュメント、Skills（Guides）
• 高速なLinterと基本的なコードレビュー（Sensors）

自己修正ループ（コミット前）

• ESLint、Semgrep、カバレッジツール（Computational Sensors）
• 基本的なセマンティックチェック（Inferential Sensors）
• ここでエージェントが自動修正し、人間のレビュー負荷を下げる

統合後パイプライン（CI/CD）

• ミューテーションテスト、詳細なアーキテクチャレビュー
• 高コストなInferential Sensorsの実行

継続的監視（変更サイクル外）

• デッドコード検出、依存関係スキャン
• ランタイムフィードバック（SLO劣化、エラー率上昇）

品質チェックを左（開発の早い段階）に寄せる「Keep Quality Left」の原則は、従来のShift-Leftと同じ思想です。ただし、エージェント開発では2つの重要な違いがあります。

第一に、Sensorsの結果がそのままエージェントの自己修正入力になる点です。人間の開発では、CIが失敗したら人間がログを読んで判断します。エージェント開発では、Sensorの出力をエージェントが直接パースして修正を試みます。つまりSensorのエラーメッセージの質が、自己修正の成功率を左右します。「Error: line 42」より「Error: line 42 - 関数fooの第2引数はstring型ですがnumber型が渡されています」の方が、エージェントは正確に修正できます。

第二に、フェーズごとのコスト構造が異なります。コーディング中のLSP補完（Guide）はほぼ無料です。コミット前のLinter実行（Computational Sensor）も安価です。しかしCI上のInferential Sensor（コードレビューエージェント）はLLM呼び出しを伴うため、PRごとに数十円〜数百円のコストが発生します。左で拾えるものを右に流すのは、品質の問題だけでなくコストの問題でもあります。

ハーネサビリティ：すべてのコードベースが平等ではない

Bockeler氏は「ハーネサビリティ」という概念も提示しています。ハーネスを構築しやすいコードベースの特性です。

• 強い型付け（型チェッカーがSensorとして機能する）
• 明確なモジュール境界（アーキテクチャ制約を定義しやすい）
• フレームワーク抽象化（エージェントの判断空間を狭められる）
• 構造化された規約（自動適用しやすい）

なぜこれらの特性がハーネサビリティを高めるのか、型付けを例に掘り下げます。

TypeScriptのプロジェクトでは、エージェントが間違った型の引数を渡した瞬間に型チェッカーがエラーを返します。これはComputational Sensorが自動的に機能している状態です。一方、型のないPythonプロジェクトでは、同じ間違いを検出するためにランタイムテストを書くか、Inferential Sensor（コードレビューエージェント）に頼るしかありません。つまり型システムの有無だけで、Sensorの構築コストが桁違いに変わります。

Morph社のSWE-bench検証では、AGENTS.mdの導入前後でベンチマークスコアに22ポイントの差が出たと報告されています。この数値はGuide単体の効果ですが、注目すべきはMorph社のコードベースがTypeScript + 明確なモジュール境界という高ハーネサビリティの構成だった点です。同じAGENTS.mdをハーネサビリティの低いコードベースに適用しても、同等の効果は期待できません。Guideの効果はコードベースのハーネサビリティに依存します。

皮肉なことに、ハーネスが最も必要なレガシーコードベースほど、ハーネスの構築が難しいという課題があります。型がない、モジュール境界が曖昧、テストがない。このようなコードベースでは、Sensorを設置する場所すら見つけにくいのです。

ここでの実践的なアドバイスは、レガシーコードベースに対してはまずハーネサビリティを上げる投資から始めることです。型の段階的導入（JSDocの型アノテーション、TypeScript化）、モジュール境界の明確化（パッケージ分割、API層の整理）、最低限のテストスイート構築。これらはエージェント活用の前提条件であり、エージェントなしでも開発効率を上げる投資です。グリーンフィールドのプロジェクトであれば、最初からハーネサビリティを意識した技術選定が可能です。

残された課題

Bockeler氏は記事の最後に、未解決の問いを列挙しています。それぞれがなぜ難しいのかを補足します。

ハーネスの一貫性問題

Guides/Sensorsが増えると、互いに矛盾するルールが紛れ込みます。たとえばCLAUDE.mdに「シンプル第一」と書きつつ、別のGuideで「すべてのエッジケースをテストでカバーする」と指示する。エージェントはどちらを優先すべきか判断できず、中途半端な出力を返します。人間のチームならコンテキストで判断できる矛盾も、エージェントは文字通りに受け取ります。ハーネスが成長するほど、この矛盾の発見と解消が運用上の課題になります。

サイレントSensor問題

Sensorが一度も発火しない場合、2つの解釈があります。コードの品質が高いのか、Sensorの検出力が足りないのか。ミューテーションテストはこの問題に対する部分的な答えです。コードを意図的に壊してテストが検出するかを確認する。しかしミューテーションテスト自体が高コストであり、すべてのSensorに対して「Sensorのテスト」を書くのは現実的ではありません。

行動ハーネスの困難さ

最も未成熟な領域です。コードスタイルの違反はLinterで検出できます。アーキテクチャの違反はArchUnitで検出できます。しかし「仕様通りに動いているか」を検証するのは格段に難しい問題です。なぜなら「仕様」自体が自然言語で書かれており、形式的な検証に落とし込めないからです。「ユーザーが退会したらデータを30日後に削除する」という仕様に対して、エージェントが即時削除を実装しても、テストが「削除された」ことだけを確認していれば通ってしまいます。行動レベルの正しさを検証するには、仕様を形式化する技術か、仕様理解力の高いInferential Sensorの進化が必要です。

まとめ：明日から何をすべきか

Bockeler氏のGuides/Sensorsフレームワークは、散らばっていたハーネスの要素を整理する実用的な枠組みです。ここまでの内容を、明日からの行動に落とし込みます。

まず自分のハーネスの現状を棚卸しします。CLAUDE.mdやAGENTS.mdに書いたルールを1つずつ「Guide」「Sensor」「両方」に分類してみてください。多くの場合、Guideに偏っていることに気づくはずです。ルールは書いたが、守られているかを検証する仕組みがない。この状態は「願望リスト」であってハーネスではありません。

次に、不足している側を補強します。判断基準はシンプルです。

• エージェントが最初の出力で方向を間違える → Guide不足。CLAUDE.mdの整理、アーキテクチャドキュメントの追加、MCPによるナレッジ供給を検討する
• エージェントが間違いに気づかず完了と報告する → Sensor不足。Linterルールの追加、テストカバレッジの強化、pre-commitフックの導入を検討する
• エージェントがリトライを繰り返してトークンを浪費する → GuideとSensorの接続不良。Sensorのエラーメッセージが修正方法を含んでいるか、Guideが具体的な判断基準を示しているかを確認する

そして、Computational SensorsとInferential Sensorsの棲み分けを意識します。ルールで表現できるものはすべてLinterやテストに落とし込み、LLMベースのレビューは意味レベルの判断に集中させる。これだけでSensorの運用コストが大幅に下がります。

用語の混乱に惑わされる必要はありません。Context Engineering、Harness Engineering、Agentic Engineering。呼び名は違っても、「モデルの外側をどう設計するか」という問いは共通です。その問いに対する現時点で最も体系的な答えが、Guides/Sensorsフレームワークだと筆者は考えます。

参考リンク

• Harness Engineering for Coding Agents - Martin Fowler's site（Birgitta Bockeler, 2026/4/2）
• The New Skill in AI is Not Prompting, It's Context Engineering - Phil Schmid
• My AI Adoption Journey - Mitchell Hashimoto
• 2025 Was Agents. 2026 Is Agent Harnesses. - Aakash Gupta
• Harness engineering: leveraging Codex in an agent-first world - OpenAI
• Karpathy on Context Engineering - X