AIエージェントの性能は、モデルの賢さだけでは決まらない。モデルを取り巻く「実行環境・制約・フィードバックループ」の設計が、エージェントの品質を左右する。この考え方が「ハーネスエンジニアリング」である。プロンプトエンジニアリング、コンテキストエンジニアリングに続く第3世代のAI活用技術を整理する。
ハーネスエンジニアリング（Harness Engineering）とは、LLM（大規模言語モデル）を中心とするAIシステムにおいて、モデルの周囲にある実行環境・制約・フィードバックループ・ツールを体系的に設計・最適化する技術である。
ハーネス（harness）とは、馬車を制御する「馬具」のことである。馬がいくら強力な力を持っていても、適切な馬具がなければその力を制御できない。AIエージェントも同様で、モデルがどれだけ高性能でも、適切な「環境設計」がなければ能力を引き出せない。
| 組織・人物 | ハーネスエンジニアリングの定義 |
|---|---|
| LangChain社 | ハーネスとは「モデル以外のコード、設定、実行ロジックのすべて」。システムプロンプト、ツール定義、サンドボックス、オーケストレーション、フックなどを含む |
| OpenAI社 | 「環境を設計し、意図を仕様化し、検証と回復のフィードバックループを作って、エージェントが信頼できる仕事をできるようにすること」 |
| Mitchell Hashimoto氏 | 「エージェントが間違えたら、その間違いが二度と起きないように環境側を改善すること」。AGENTS.mdの改善とプログラムされたツールの整備を重視 |
ハーネスエンジニアリングは「エンジニアの役割を、コードを書くことから、エージェントのコードの書き方を制御するシステムを設計することへと移行させる技術」とも言えよう。
↑ 目次に戻るハーネスエンジニアリングが急速に注目され始めたのは、2025年末から2026年初めにかけてである。AIの利用形態が「チャットボットとの対話」から「自律的にタスクを完遂するエージェント」へと進化したことが直接の背景にある。
概念として最初に提唱したのはHashiCorpの共同創業者・Mitchell Hashimoto氏で、2026年2月5日のブログ記事「My AI Adoption Journey」が起点とされる。その後、OpenAI（2026年2月11日）、LangChain、Thoughtworks社のBirgitta Böckeler氏（2026年3月）が相次いで定義や事例を公表したことで、業界全体に広まった。またAnthropicは2025年11月に「Effective harnesses for long-running agents」と題した論考の中で、コンテキストの断絶と記憶の欠如を「未解決の問題」として提起しており、ハーネス設計の重要性をいち早く指摘していた。
↑ 目次に戻るAIを活用するための技術は、ChatGPT登場（2022年）以降、3つの世代を経て進化してきた。
「AIへの指示の質が回答の質を決める」という考え方。Few-shot学習やChain-of-Thoughtなどの技法が生まれた。目標は単発の入力から最高の回答を引き出すことで、長期タスクや複雑な相互作用の管理は困難だった。
例え：完璧な依頼メールを書く技術Andrej Karpathy氏らが提唱。モデルのコンテキストウィンドウを「適切な情報で満たす」ことに焦点を当てた。RAGやメモリシステム、構造化されたコンテキスト注入などを含む。情報の密度を最適化し単一の意思決定を支援する段階にとどまっていた。
例え：メールに正しい資料をすべて添付する作業前の2世代を包含しつつ、エージェントの継続的な作業を統制するルール・フィードバック・インフラのシステム全体を設計する。焦点は「指示」や「情報」ではなく、エージェントが活動する「世界そのもの」の設計にある。
例え：オフィス全体のアーキテクチャを設計する作業Böckeler氏はまずハーネスを2種類に分類している。内部ハーネスはAIエージェント製品に最初から組み込まれているもの（システムプロンプト、オーケストレーション機構など）、外部ハーネスはユーザーやエンジニアが自分で構築するもの（CLAUDE.md、テストスクリプト、カスタムリンターなど）である。
ハーネスの制御は、作動するタイミングによって2種類に分けられる。
| 制御タイプ | 役割 | 具体例 |
|---|---|---|
| ガイド （フィードフォワード制御） |
行動の前に方向付ける。エージェントが思考する際の「レール」として機能し、最初の試行で正解に到達する確率を高める | CLAUDE.md・AGENTS.mdのルール記述、コーディング規約、設計思想の明文化 |
| センサー （フィードバック制御） |
行動の後に結果を検証し、自己修正を支援する | テスト、リンター、コードレビュー、LLM-as-Judge |
さらにセンサーは「計算的制御」（テスト・リンターなど確定的で高速）と「推論的制御」（AIコードレビュー・LLM-as-Judgeなど意味的判断で低速）に分かれ、それぞれ適切なタイミングで使い分けることが重要である。
Qianyu Meng氏の分類とBöckeler氏の知見を統合すると、現在のハーネスエンジニアリングには7つの構成要素が存在する。
「Plan-Execute-Verify（PEV）ループ」が標準。各ステップで出力が仕様から乖離していないか確認し、必要に応じて軌道修正する。
ファイル操作、コード実行、HTTPリクエストなど外部環境とのインターフェース群。MCPが定義・呼び出しの標準基盤となっている。
現在のタスクに最も関連性の高い情報だけを動的に取捨選択する「段階的な情報開示」の戦略が重要。
セッションをまたいでエージェントの作業状況を保持するメモリレイヤー。チェックポイントやスキルファイルを含む。
タスクの開始・終了・エラー時に特定処理を自動実行するイベント駆動の仕組み。コミット前のセキュリティスキャンなどがこれにあたる。
出力が基準を満たすかを判定する機構。計算的手法（テスト、リンター）と推論的手法（LLM-as-Judge）を組み合わせる。
CLAUDE.mdやAGENTS.mdに記述するルール群。センサーが事後チェックを行うのに対し、ガイドはエージェントが行動する前に「正しい方向」を示す。エージェントが思考する際の「壁」として機能し、最初の試行で正解に到達する確率を高める役割を果たす。
理論だけでなく、先進企業はすでにハーネスエンジニアリングを大規模に実践している。
ハーネスエンジニアリングは有望な技術だが、現時点では未解決の課題も多い。
基盤モデルの能力差が縮まるにつれ、システムの優位性は「どのモデルを使うか」ではなく「どのようなハーネスを持つか」に移行する。スタンフォード大学の「Meta-Harness」研究では、同じモデルを使ってもハーネスの設計を変えるだけで数学的推論の精度が4.7ポイント向上することが示されており、ハーネスがパフォーマンスの「決定要因」になりつつある。
ハーネス自体をAIが最適化する「Meta-Harness」の手法では、AIが過去の実行ログを分析して「なぜ失敗したか」を言語的に推論し、ハーネスのコードを自ら書き換える。モデルを再学習させるより低コストで高い効果が得られるとされ、「人間は高次の目的関数を定義するだけでよい」段階が近づいている。
エンジニアの役割の変化
OpenAIやStripeの事例は、「人間がコードを一行も書かないエージェント・ファーストのワークフロー」が大規模プロダクトで既に可能であることを示している。これからのエンジニアの役割は、実装から「AIが逸脱せず効率的に働ける環境をいかに設計・維持するか」というガバナンスへとシフトする。
ハーネスエンジニアリングは、AIエージェントの「失敗のパターン」を環境側で吸収するという発想の転換である。エージェントが間違えるたびにプロンプトを書き直すのではなく、「二度と同じ間違いを犯せないように環境を改善する」という考え方は、ソフトウェアエンジニアリングの本質に通じるものがある。
AIが「強力な力を持つ馬」だとすれば、その力を目的地に向けて制御する「馬具」の設計がハーネスエンジニアリングである。モデルの性能向上競争が一巡した先に、ハーネスの設計力こそがAI活用の真の差別化要因になる時代が来るかもしれない。