ハーネスエンジニアリング入門 — Agent = Model + Harness で読み解くAIエージェント運用

Posted at 2026-07-05

はじめに

AI コーディングエージェントの実力は、使うモデルよりも モデルの周りに組んだ「足場」 で決まります。この足場を ハーネス（harness） と呼び、その設計を体系化したのが、Thoughtworks の Birgitta Böckeler が Martin Fowler「Exploring Gen AI」で公開した Harness engineering for coding agent users です。本記事では、ハーネスを guides（事前統制）と sensors（事後検知） で読み解きます。さらに Feedback Flywheel、Thoughtworks 内製の SPDD、AI 駆動開発の隠れコスト Cognitive Debt までを一枚の地図に整理し、最後に筆者が個人で回している運用例を示します。

この記事で分かること: ハーネスという設計語彙（guides / sensors）、Feedback Flywheel・SPDD・Cognitive Debt の関係と出どころ、個人開発への適用例

用語の整理 ── 誰が何を提唱したのか

「Claude Code を入れました」「Cursor を試しました」という話は 2026 年にはすっかり日常になりました。一方で関心は 「で、これをどう運用し続けるのか」 に移っています。

ここで手がかりになるのが、いわゆる ハーネスエンジニアリング の語彙です。よく「Martin Fowler のハーネス理論」とまとめられますが、正確には次のように担い手が分かれています。整理しておくと混乱しません。

Harness engineering for coding agent users（ハーネスの体系化）— Birgitta Böckeler（Thoughtworks）。Fowler の martinfowler.com「Exploring Gen AI」で公開
Feedback Flywheel（AI 対話を組織学習に変える型）— Rahul Garg（Thoughtworks）。同じく martinfowler.com の連載 Patterns for Reducing Friction in AI-Assisted Development で公開
SPDD（Structured Prompt-Driven Development） — Thoughtworks の内製 IT 部門が確立した手法
Cognitive Debt（認知的負債） — Fowler と Thoughtworks が開催した「Future of Software Engineering」リトリートで Margaret-Anne Storey が提唱した概念

つまり「Fowler 個人の理論」というより、Fowler を含む Thoughtworks まわりの実践群が出どころです。本記事ではこの前提で語彙を整理します。

1. Agent = Model + Harness

ハーネスエンジニアリングの中核は、エージェントを モデルとハーネス（モデル以外の足場全部） に分けて考える点にあります。Böckeler の主旨は明快で、エージェントの振る舞いで面白い部分の大半は、モデルではなくハーネスに宿る、というものです。なお「harness」という語は Mitchell Hashimoto のブログ記事や OpenAI の Codex 事例記事 Harness engineering を通じて広まったもので、Böckeler はそれをコーディングエージェントの利用者向けに体系化し直した、という位置づけです。

Agent = Model + Harness
Harness = Agent から Model を引いた残り全部

ハーネスに含まれるのは、CLI／IDE 統合／ファイルアクセス／プロンプト規約／Skill／MCP／hooks／サンドボックス／Eval／レビュー導線、といったスタック全体です。同じ Claude Sonnet 4.6 を使っていても「CLAUDE.md が整ったリポジトリ」と「すっぴんのリポジトリ」では生産性が桁で違います。差はモデルではなく、ハーネスにあります。

guides と sensors ── 2 つの制御ベクトル

Böckeler の整理で軸になるのが、ハーネスを 制御ループとして捉える見方です。エージェントの出力を、次の 2 つのベクトルで統制します。

guides（feedforward／事前統制）: 行動を先回りで誘導する。CLAUDE.md、プロンプト規約、Skill
sensors（feedback／事後検知）: 実行後にエラーを検知して自己修正させる。テスト出力、型エラー、lint、ログ、コンパイラメッセージ

さらに guides と sensors はそれぞれ computational（決定論的） か inferential（推論的） に分かれます。テスト実行は computational な sensor、別エージェントによるレビューは inferential な sensor、という具合です。「先回りで縛る層」と「やった後で気づかせる層」を、決定論と推論で掛け合わせて設計する、と捉えると見通しが良くなります。

区分	computational（決定論的）	inferential（推論的）
guides（事前）	スキーマ・型定義・lint 設定	CLAUDE.md・プロンプト規約
sensors（事後）	テスト・コンパイル・静的解析	別エージェントによるレビュー

この語彙を持つと、個別に語られてきた道具を一枚の地図に落とせます。Claude Skill は guides をパッケージ化した再利用テンプレート、MCP（Model Context Protocol） は sensors と computational 要素の標準インターフェース、Agent Memory は guides を動的に書き換える中間層、と読み解けます。

「どのモデルが良いか」は半年で陳腐化しますが、この guides/sensors ごとに積み上げた資産はチーム固有のものとして残ります。

2. Feedback Flywheel ── AI を使うたびにチームが賢くなる

ハーネスを整えただけでは、エージェントは「便利な人」止まりです。チームが賢くなるところまで持っていく型が、Rahul Garg（Thoughtworks）が martinfowler.com で提唱した Feedback Flywheel です。原典では、Knowledge Priming（事前知識の整備）やチーム規約のエンコードといった共有アーティファクト群を、セッションごとの学びで維持・改善し続けるための「維持機構（maintenance mechanism）」として位置づけられています。

要点は、目的が「AI から良い答えを引き出すこと」ではなく「AI を使うたびにチームが賢くなること」 にある点です。これで評価軸が「アウトプットの質」から「組織能力の蓄積速度」へ切り替わります。個々の AI セッションが生む signal を、チームの共有アーティファクトに還流させて集合知に変える、という発想です。

3. Cognitive Debt ── AI 駆動開発の隠れたコスト

Feedback Flywheel の対になる概念が Cognitive Debt（認知的負債） です。これは Fowler と Thoughtworks が開催した「Future of Software Engineering」リトリートで Margaret-Anne Storey が提唱した、比較的新しい枠組みです。

定義はおおよそ「チームがシステムの理解を失っていくこと」。AI は 動くが誰も読んだことのないコードを量産できるため、開発者と「自身が責任を持つはずのソフトウェア」との距離が広がります。技術的負債の隣接概念として整理されたのが新しい点です。

観点	技術的負債	認知的負債
何が劣化するか	コードの保守容易性	チームのシステム理解
顕在化の仕方	バグ・性能低下	障害対応の遅延・属人化
返済方法	リファクタリング	Code Reading・Flywheel の書き戻し

加えて、長時間タスクで制約や文脈が積み上がると LLM エージェントの出力品質が落ちやすい、という指摘も各所でなされています。「1 セッションに詰め込みすぎると壊れる」という経験則と符合する話です。実務的には 1 セッションの仕様を 3〜5 個に絞り、超える分は sub-agent へ委譲し、こまめに checkpoint を切るのが効きます。注意したいのは、コンテキスト長が 1M トークン級になっても「全部詰め込んでよい」わけではない点で、窓が広いほど Cognitive Debt を貯めやすくなります。

4. SPDD ── プロンプトを資産として扱う

SPDD（Structured Prompt-Driven Development） は、Thoughtworks の内製 IT 部門が確立した開発スタイルです。TDD / BDD / DDD の系譜にある「X-Driven Development」の AI 時代版で、中核は次の 4 つです。

プロンプトを first-class artifact として扱う: Skill / プロンプトテンプレートをコードと一緒に version control し、レビューを通す
AI 出力を必ずテストする: 生成コードへのテストを自動化してリグレッションを防ぐ
必ずリファクタする: そのまま採用せず、チームが理解できる形に整える
学びを書き戻す: Feedback Flywheel と一体で運用する

考え方としては 「仕様（プロンプト）が真実の源、コードはそこから生成される中間言語」 に寄っていきます。Vibe Coding（なんとなく AI と対話して動くものを作る）を否定はしませんが、それを業務開発に持ち上げる橋渡しが SPDD だ、という位置づけです。

5. ハーネスエンジニアリングはどこへ向かうか

この語彙が登場して以降、ハーネスは「解説記事のバズワード」から 独立した設計テーマ へと育ちました。実務で押さえておきたい流れを 3 つ挙げます。

第一に、ハーネスを context engineering（何を渡すか）／architectural constraints（決定論的な制約・構造テスト）／garbage collection（entropy 管理、ドキュメントやダッシュボードのドリフト修復）の 3 系統で捉える整理が広がりました。これは §1 の guides/sensors と地続きで、「渡す情報を絞り、決定論で縛り、放っておくと増えるエントロピーを定期的に掃除する」という運用語彙を与えてくれます。

第二に、ハーネスの標準形として orchestrator-worker 分割（中央のオーケストレータがタスクを分解し、lint / test / docs / review を並列の sub-agent に委譲する）が定着しました。guides をオーケストレータの分解に、sensors を各 worker の専門レビューに対応づけると、自前のハーネスも同型に寄せられます。出発点は「1 worker = 1 関心事 + 終了条件の明文化」です。

第三に、dollar-budget（コスト）をハーネスの一級制約にする動きです。エージェント実行が従量課金で見えるようになり、Feedback Flywheel を「成功率」だけでなく「$/タスク」でも回すのが一般的になりました。1 run のトークン上限を予算から逆算し、sub-agent 委譲時に残予算を渡し、閾値割れで安価なモデルへフォールバックする、という設計です。「青天井で agentic loop を回す」のは設計ミスとして扱う、という空気になっています。

6. 個人開発で回してみる

ここまでの構造は、チームだけでなく 1 人でも効きます。筆者は Obsidian Vault と Claude Skills で「1 人版の Feedback Flywheel」を回しています。

ポイントは「書き戻し」が CLAUDE.md と Skill の更新として効いていることです。次に同じトピックを取り込むとき、過去の関連ノートが自動で参照され、定義の更新提案まで出るようになります。これが Flywheel の「同じ AI 対話のはずなのに、回を重ねるごとに賢くなる」感覚そのものです。Skill には小さな eval/（CI で回す最小テスト）を必ず置き、モデル更新や Skill 改訂のリグレッションをブロックできるようにしておくと、運用が安定します。

チームに展開する前に、個人で 2〜3 か月この構造を回してみるのが、結局いちばん近道だと感じています。

まとめ

整理すると、ハーネスエンジニアリングの示唆は次の 4 点に圧縮できます。

Agent = Model + Harness。論点をモデル比較からハーネス設計へ移す
ハーネスは guides（事前）/ sensors（事後） を computational / inferential で掛け合わせて育てる
Feedback Flywheel で書き戻しを回し、AI を使うたびにチームを賢くする
回らないと Cognitive Debt が溜まる。SPDD はその予防・返済機構

モデルの優劣は半年で消えますが、ハーネスとそれを運用するチーム（あるいは個人）の筋肉は残ります。半年ごとに「ハーネス健康診断」（Eval スコア / レビュー時間 / インシデント件数 / $ per タスク）を測る習慣をつけると、投資先が見えやすくなります。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up