2026年の春、AIエージェント界隈に新しい言葉が駆け巡った。「ハーネスエンジニアリング」——直訳すれば「馬具工学」。AIを馬に見立て、その力を正しい方向に導くための手綱・鞍・道路を設計する技術のことだ。
「また新しいバズワードか」と思った人も多いだろう。実際、Zennでは「ハーネスエンジニアリング、それGit Workflowをbashで書き直してるだけでは」という記事が出ているし、X上でも「適当にやってたらハーネスエンジニアリングになってたわ」という冷めた声がある。
しかし、この言葉が急速に広まった背景には、無視できない実証データがある。
「プロンプト→コンテキスト→ハーネス」の進化は何が違うのか
プロンプトエンジニアリングは「AIへの指示の書き方」、コンテキストエンジニアリングは「AIに渡す情報の設計」だった。ハーネスエンジニアリングはその両方を含みつつ、モデル以外のすべて——ツール接続、権限管理、テスト、フィードバックループ、状態永続化——を対象にする。
Martin Fowler のサイトに掲載された Birgitta Boeckeler の分類（2026年4月2日）が、この概念を最も体系的に整理している。ハーネスの制御メカニズムを ガイド（フィードフォワード） と センサー（フィードバック） に分け、さらにそれぞれを 計算的制御（テスト、リンターなど決定論的なもの）と 推論的制御（AIコードレビューなど非決定論的なもの）に分ける。この4象限で考えると、自分の環境のどこが手薄かが見えてくる。
AnthropicとOpenAI、2つのアプローチ
面白いのは、AnthropicとOpenAIでハーネスの設計思想がかなり異なることだ。
Anthropic（2026年3月） はGANにインスパイアされた3エージェント構成を発表した。Planner（何を作るか）、Generator（どう作るか）、Evaluator（品質を評価しフィードバック）。核心的な洞察は「モデルは自分の作品を自信を持って褒めがち」という自己評価バイアスの問題で、だからこそ作る側と評価する側を分離する必要がある、というものだ。
OpenAI（2026年2月） はもっと壮大だ。Ryan Lopopolo（Frontier Product Exploration）がLatent Spaceポッドキャストで語った内容によると、Codexチームは5ヶ月間で100万行のプロダクションコードを「手書きコードゼロ、人間のレビューゼロ」で開発した。Elixir製の「Symphony」という7層オーケストレーションシステムを構築し、1日10億トークンを消費する。「唯一の根本的に希少なリソースは同期的な人間の注意」という言葉が印象的だ。
特にユニークなのが「Ghost Libraries」というアイデアで、まだ存在しないライブラリのスペック（型定義とインターフェース）を先に書いておき、AIがそれに向かってコードを書く。ビルドループは1分以内を厳格に強制している。
新しい概念なのか、名前がついただけなのか
正直に言えば、両方だと思う。CLAUDE.md を整備し、フックでリンターを自動実行し、テストで品質を担保する——こうした実践は、ハーネスエンジニアリングという言葉が生まれる前からやっていた人が大勢いる。
しかし「名前がついた」こと自体に価値がある。@Shin_Engineer のポスト（170いいね）が本質を突いている。「今のプログラマにとって重要なスキルは『如何にAIに素晴らしいコードを自律的・安定的に書かせられるか』というハーネスエンジニアリングだ」——つまり、プログラマという職業の定義が変わりつつあることを言語化する道具として、この概念は機能している。
マネージャーとしては、バズワードに振り回される必要はないが、「モデルを変えるより環境を整える方が影響が大きい」という核心だけは押さえておきたい。次の記事で、そのことを数字で裏付ける。