Harness Engineering（駆御工学）
AIモデルはすでに100万行のコードを書ける。本当の課題は、より良く書かせることではなく、いかにそれを安定して、信頼でき、制御を失わずに働かせるか、ということだ。。このAIエージェントを中心に、制約・フィードバック・制御システムを構築する方法論こそが、2026年初頭にエンジニアリング界を急速に席卷した新たなパラダイム——Harness Engineering（駆御工学）。
一、Harness Engineeringとは何か？
Harness Engineering（駆御工学）は、AIエージェントを中心に設計・構築する、制約メカニズム、フィードバックループ、ワークフロー制御、継続的改善サイクルのシステムエンジニアリング実践です。
それはモデル自体を最適化するのではなく、モデルが動作する環境を最適化します。核心となる哲学は次の8文字：人類が舵を取り、エージェントが実行する（Human Steer, Agent Execute）。
Harnessという言葉は馬具——手綱、鞍、馬銜（はみ）——つまり、強力だが予測不能な動物を導くための完全な装備に由来します。駆御工学はAIの能力を弱めることではなく、AIのために黄金の手綱を造り、速くかつ安定して走らせることです。
この概念は、HashiCorpの共同創業者であるMitchell Hashimotoが2026年2月5日に初めて提唱し、6日後にOpenAIが100万行コード実験レポートでこの用語を正式に採用しました。その後、Martin Fowlerが深く分析する記事を執筆し、1か月以内に開発者コミュニティで頻出ワードになりました。
harness engineering is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent will not make that mistake again in the future.
—— Mitchell Hashimoto
この言葉の含意（サブテキスト）は：Agentの失敗は、その一つひとつが環境設計の不備を示すシグナルです。正しい対応は、より強力なモデルに替えることではなく、それが動作する環境を再設計することです。
二、なぜ駆御工学が必要なのか？実データが語る
LangChainの事例は特に説得力があります。基盤モデルのパラメータは一つも動かしていません。単に外部の駆御環境を最適化しただけで、（ドキュメント構造、検証ループ、トレーシングシステム）、コーディングAgentのTerminal Bench 2.0のスコアは52.8%から66.5%へ急上昇し、世界ランキングは30位から5位に躍進しました。
5つの独立したチームも同じ結論に達しました：ボトルネックはモデルの知能ではなく、インフラストラクチャにあります。
三、AIエンジニアリングパラダイムの3つの転換
駆御工学がなぜ重要なのかを理解するには、私たちがどのように一歩一歩ここまで来たのかを、まずはっきりと見る必要があります。
| パラダイム | 核心となる問題 | 最適化対象 | 対話モード |
|---|---|---|---|
| プロンプトエンジニアリング | どうすれば言葉を明確に伝えられるか | プロンプトの言い回し、形式、例 | 一問一答 |
| コンテキストエンジニアリング | どうやってAIに情報を与えるか | ドキュメント、コード断片、過去の会話 | 情報注入 → 生成 |
| 駆御工学 | どうやってAgentを確実に動作させるか | 制約、フィードバックループ、制御システム | 人類が舵を取り、Agentが実行する |
覚えやすいアナロジー：
- Prompt Engineering —— 馬に呼びかける技術
- Context Engineering —— 馬に見せる地図
- Harness Engineering —— 馬のために高速道路を造り、ガードレール、制限速度標識、ガソリンスタンドを備える
四、Agentによくある失敗パターン
Anthropicのエンジニアは、長時間Agentを運用する過程で、3つの典型的な失敗パターンをまとめました。これこそ駆御工学が解決すべき核心的な痛点です：
失敗パターン1：一気に完成させようとする（One-shotting）
Agentは1つのセッション内で全機能をやり遂げようとする傾向があります。その結果、コンテキストウィンドウが尽き、ドキュメントのない半製品コードの山を残し、次のセッション開始時には、以前何が起きたのかを推測するために多大な時間を費やすことになります。
失敗パターン2：早期に勝利を宣言する
プロジェクト後期、一部の機能が完了した時点で、Agentは周囲を見回し、既に進捗が見えると、まだ大量の機能が未実装であっても、タスク完了を宣言してしまいます。
失敗パターン3：機能を早期に完了とマークする
明確な指示がないまま、Agentはコードを書いたら完了とマークし、エンドツーエンドのテストを行いません。ユニットテストやcurlコマンドが通っても、機能が実際に使えるとは限りません。
さらに、エージェントにはもう一つ危険な特性があります：それはパターンの複製が非常に得意です。コードベースにあるパターンは何でも忠実にコピーして増幅します——悪いパターンやアーキテクチャの漂流も含めて。これは、制約のないAgentが驚くべき速さで技術負債を蓄積することを意味します。
五、駆御工学の四大ガードレール
OpenAI、Anthropic、LangChain、Martin Fowlerの実践を総合すると、Harnessは4つの核心コンポーネント、すなわち4本の「ガードレール」にまとめられます：
ガードレール1：コンテキストエンジニアリング（Context Engineering）——新入社員マニュアル
まるで新入社員に詳細な業務マニュアルを与えるように、AGENTS.mdそれは、AIエージェントがコードリポジトリに入ったときに最初に目にするガイドです。しかし、これは静的な1000ページの説明書ではありません――コンテキストは希少なリソースであり、過剰な指示はむしろタスク・コード・関連ドキュメントのスペースを押しのけ、古びたルールの墓場になってしまいます。
より良い方法は、安定していて小型のエントリーポイントを提供し、Agentに現在のタスクに応じてオンデマンドでより多くのコンテキストを検索・取得することを教えることです。Mitchell HashimotoのGhosttyプロジェクトのAGENTS.mdの各行は、過去のAgentの失敗事例に対応しています——ドキュメントは生きたフィードバックループであり、静的な成果物ではありません。
ガードレール2：アーキテクチャ制約（Architecture Constraints）——手綱
OpenAIチームは厳格な階層依存モデルを構築しました：
Types → Config → Repo → Service → Runtime → UI
下位層は上位層に逆依存できません。すべてのアーキテクチャルールはコード化され、カスタムLinterルール違反があればCIがマージをブロックします——コードが人によるものであれ、AIによるものであれ。
重要な詳細があります：Linterのエラーメッセージ自体もコンテキストエンジニアリングです。それは単にルールXに違反していると言うだけでなく、なぜそのルールが存在するのか、正しいやり方は何かを説明します。これにより、Agentはエラーを読んだ後に自己理解して修正でき、人間の介入は不要になります。
ガードレール3：フィードバックループ（Feedback Loop）——エージェントがエージェントを審査する
従来の開発では、人間のエンジニアがコードレビュー（Code Review）を担当していた。ハーネスエンジニアリングでは、この作業はエージェント対エージェントの方式に変わる：Codex がローカルで自身の変更をレビューし、追加レビューをリクエストし、通過するまで繰り返す。
フィードバックループ内のフックは、事前定義されたテストスイートを実行でき、失敗時にはエラーメッセージを付けてモデルにループバックするか、モデルに自身のコードを独立して評価するよう促す。AI が書いたテストケースがバグのあるコードを通過させた場合、Harness はそのテストを無効と判定し、テストの境界を再考するよう強制する。
ガードレール4：エントロピー管理（Entropy Management）——ガベージコレクション
時間の経過とともに、ソフトウェアシステムは徐々に混乱し（エントロピー増大）、技術負債が蓄積する。OpenAI は問題が深刻化してから集中的に処理するのではなく、継続的に小額を返済する戦略を採用している——彼らはこの方法を次のように表現しているガベージコレクション、そして技術負債は高金利のローンのようなものだと考えている。
具体的な施策：バックグラウンドで Codex タスクを定期的に実行し、逸脱をスキャンし、品質レベルを更新し、対象を絞ったリファクタリング PR を発起する。さらに専用のDoc-gardening Agent（ドキュメントガーデナーエージェント）がバックグラウンドでドキュメントとコードの不一致を自動スキャンし、古い内容を発見すると自動的に PR を提出して修正する——エージェントがエージェントのためにドキュメントを保守する。
六、業界の六大コンセンサス
OpenAI、Anthropic、LangChain、Stripe、HashiCorp など複数の独立した情報源を総合すると、業界は以下の6つの側面で明確なコンセンサスを形成している：
| # | コンセンサス | 核心となる見解 |
|---|---|---|
| 1 | ボトルネックはインフラにあり、モデルの知能にはない | 5つの独立したチームが同じ結論に達した。Harness のツール形式を変更するだけで、モデルのスコアを 6.7% から 68.3% に引き上げられる |
| 2 | ドキュメントは生きたフィードバックループでなければならない | 静的ドキュメントは墓場であり、動的ドキュメントにのみ価値がある。バックグラウンドのエージェントに古いドキュメントを定期的にクリーンアップさせ、PR を提出させる |
| 3 | 思考と実行の分離 | 複雑なタスクは単一のコンテキストウィンドウ内では完了できない。Orchestrator + Worker の階層アーキテクチャが必要で、状態は外部ストレージに永続化する |
| 4 | コンテキストは多ければ多いほど良いわけではない | コンテキストは希少なリソースである。巨大な命令ファイルはタスク空間を圧迫するため、オンデマンドで検索し、動的に注入すべきだ |
| 5 | 制約は自動化されなければならない | 人手によるレビューはボトルネックである。ガードレールは Linter、CI、型システムとしてコード化し、人間ではなく機械に実行させなければならない |
| 6 | エンジニアの役割は変わりつつある | コードの書き手から環境の建築家へ。最大のエンジニアリング課題は、エージェントが確実に機能する制御システムを設計することだ |
七、Harnessと従来フレームワークの関係
Harness は SDK、スキャフォールド、エージェントフレームワークの代替品ではなく、それらの上に位置する層である：
従来のフレームワークが解決するのはAI エージェントをどう構築するかであり、ハーネス層が解決するのはまったく異なる問題だ：エージェントをどう確実に運用するか。
モデルはフレームワークの約80%の機能（エージェント定義、メッセージルーティング、タスクライフサイクル……）を徐々に吸収しているが、残りの20%——永続化、決定的リプレイ、コスト管理、可観測性、エラーリカバリ——こそがハーネス層が存在する価値である。
まとめ
Harness Engineering は特定の一社の実験ではなく、業界全体が経験しているパラダイムシフトである。
Birgitta Böckeler の要約が最も的確だ：
より高い AI の自律性を得るためには、ランタイムはより厳格な制約を受けなければならない。信頼を高めるために必要なのは、より多くの自由ではなく、より多くの制約である。
高速道路のガードレールのようなものだ——ガードレールがあるからこそ、時速120kmまで踏み込めるのだ。
| コアコンポーネント | 解決する問題 | 代表的な実践 |
|---|---|---|
| コンテキストエンジニアリング Context | エージェントが何を見るべきか、どう見つけるかを知らない | AGENTS.md ライブドキュメント、オンデマンド検索 |
| アーキテクチャ制約 Constraints | エージェントが悪いパターンを複製し増幅する | 階層的依存関係、カスタム Linter、CI による強制ブロック |
| フィードバックループ Feedback | エージェントが自分の過ちに気づかない | エージェント間レビュー、自動テストスイート |
| エントロピー管理 Entropy | 技術負債とドキュメントの腐敗 | Doc-gardening Agent、継続的なガベージコレクション |
ソフトウェア開発の未来は、どれだけ速く、どれだけ良いコードを書けるかではなく、こうなるかもしれない：AI エージェントの巨大なエネルギーを操るために、どれだけ賢く、どれだけ堅牢なシステムを設計できるか。
エンジニアの価値は、実行者からイネーブラー（促進者）とシステム思考者へと移行しつつある——製品を構築することから、製品を構築できる工場を構築することへ。