はじめに
2026年、「ハーネスエンジニアリング」という言葉をよく見かけるようになりました。
OpenAIが「3人で5ヶ月、100万行」という数字とともに発表し、LangChainが「ハーネス改善だけでベンチマーク30位→5位」と続いています。自分も気になって調べてみたのですが、調べれば調べるほど「あれ、これ自分がもうやっていることでは？」という感覚が出てきました。
CLAUDE.mdを書いて、リンター設定して、CIでテスト回して。名前は知らなかったけど、AIを日常的に使っていると自然とそういう工夫をするようになります。同じ感覚の方も多いのではないでしょうか。
そこから「これは本当に新しい概念なのか？」という疑問が湧いてきました。
さらに調べていくと、Martin Fowlerが同じ問いについて書いているのを見つけました。『リファクタリング』の著者であり、ThoughtWorksのチーフサイエンティスト、アジャイル宣言の署名者でもある人物です。彼の批評を軸に、ハーネスエンジニアリングについて改めて考えてみたいと思います。
そもそも何が「新しい」のか
ハーネスエンジニアリングの中身を、一つずつ見てみましょう。
- コンテキストエンジニアリング — AIに正しい情報を渡す → ドキュメント整備
- アーキテクチャ制約 — リンター、型チェックで制約する → 静的解析
- フィードバックループ — CI/CDで自動検証する → DevOps
- エントロピー管理 — コードベースの劣化を防ぐ → 技術的負債管理
ドキュメント整備 + 静的解析 + DevOps + 技術的負債管理。こうして並べてみると、既存のプラクティスとかなり重なって見えます。
もちろん「AIエージェント向けに最適化するところが新しい」という視点は理解できます。ただ、それは既存プラクティスのAI時代版であって、まったく新しいパラダイムかと言われると少し疑問が残ります。
Fowlerもこう書いています：
おそらく誰かがワンプロンプトのLLMベースコードレビューエージェントを「ハーネス」と呼ぶ日も近いだろう
概念のインフレーションは、すでに始まっているのかもしれません。
Fowlerが指摘する、見過ごされがちな問題
1. 「正しく動くか」を検証する仕組みがない
Fowlerの批評で個人的に最も印象に残ったのはこれです：
振る舞い（behavior）と機能性（functionality）の検証が欠けている
ハーネスが守っているのは内部品質です。コードの一貫性、アーキテクチャへの準拠、ドキュメントの正確性。
しかし、「コードは綺麗だけど、ユーザーにとって正しく動くの？」 という最も重要な問いには答えられていません。
リンターが通った。型チェックが通った。CIが緑。でもユーザーが求めていた機能と違う。
ハーネスは「構造の門番」であって「意味の番人」ではありません。この区別は意識しておいた方がいいと感じました。
2. 成功事例のバイアス
Fowlerはこう指摘しています：
OpenAIには、AIが保守可能なコードを書けると我々に信じさせる既得利益（vested interest）がある
これはOpenAIの主張が嘘だという話ではありません。ただ、成功事例だけが公開される構造は意識しておいた方がいいと思います。3人で5ヶ月かけて上手くいったケースの裏に、上手くいかなかったチームもいるはずです。
LangChainやAnthropicも同様にAIエージェントのエコシステムを推進する立場にあります。こうした背景は頭に入れておいて損はないかなと思います。
3. 「半日で始められる」と「5ヶ月」のギャップ
入門記事では「CLAUDE.md書いてHook設定するだけ、半日でOK」と紹介されていることも多いです。
一方、OpenAI Codexチームの現実：
- 3人のエンジニアが5ヶ月フルタイム
- 100万行以上のコードベース
- 1,500のPR
Fowlerもこう述べています：
Markdownのルールファイルを書いて管理するだけよりも、はるかに多くの作業が必要だ
CLAUDE.mdを書くのはハーネスのごく一部に過ぎません。本気のハーネスはそれ自体が一つのソフトウェアプロダクトになります。この規模感のギャップは知っておいた方がいいかなと思います。
さらに気になる点
4. レガシーコードベースとの相性
実務的に気になったのはFowlerのこの指摘です：
エントロピーに溢れた既存コードベースでは努力に見合わないかもしれない
AIはリポジトリ内の既存パターンを複製します。良いものも悪いものも。OpenAI自身がこれを認めています。つまり、既存コードがカオスなプロジェクトにハーネスを導入しても、悪いパターンが再生産されるだけの可能性があります。
ハーネスエンジニアリングの議論は新規構築を前提としている印象がありますが、多くの現場は長年の歴史を持つコードベースと向き合っています。このあたりはもう少し語られてもいい気がします。
5. 作り込みの逆効果
興味深い事例があります。Vercelが包括的なツールライブラリを揃えた結果、エージェントはツール間で混乱し、冗長な呼び出しを繰り返すようになりました。ツールの80%を削除したら、エージェントは速く正確になったそうです。
Claude Codeの開発者も「Claude Codeのハーネスは最小限であり、仕事のほとんどはモデルの力を最大限に引き出すこと」と述べています。
AIエージェントを一番うまく使っている人たちがハーネスを最小限にしている。この事実は、「ハーネスを充実させるほど良い」という直感に反していて、考えさせられます。
6. テックスタックへの影響
ハーネスが前提になると、技術選定の基準が「最適な技術」から「良いハーネスが存在する技術」に寄っていく可能性もあります。Dockerの調査では76%がAIエージェント実装でのベンダーロックインを懸念しているそうです。
7. 過渡的技術としてのハーネス
AI研究には**Bitter Lesson（苦い教訓）**という有名な原則があります。計算量のスケーリングが常に人間が設計した構造を凌駕する、というものです。
実際、2024年に複雑なパイプラインが必要だった機能が、2026年には単一プロンプトで処理できるようになっています。業界自身が「Rippable（剥がせる）設計」を提唱し始めていて、Vercel、LangChain、Anthropicが共通して「次のモデルが不要にしたら削除する前提で設計せよ」と言っています。
「剥がす前提で作れ」と言われる技術に大きく投資する際は、その前提を忘れないようにしたいところです。
結局どう向き合うか
冒頭に書いた通り、自分はハーネスエンジニアリングという言葉を知る前から、同じようなことをやっていました。たぶん多くのエンジニアがそうだと思います。ドキュメントを整備して、リンターを設定して、CIを回して、テストを書く。それはAI以前から当たり前にやってきたことです。
ハーネスエンジニアリングという概念に名前がついたことで、こうした工夫が体系的に語られるようになったのは良いことだと思います。ただ、名前がつくと「新しいパラダイム」として一人歩きしがちで、そこにはFowlerが指摘するような落とし穴もあります。
自分としては、あまり構えずに、これまでやってきたエンジニアリングの基本を、AIとの協業に合わせてちょっとずつ調整していく。そのくらいの温度感がちょうどいいのかなと思っています。
新しい名前に振り回されず、でも中身はちゃんと取り入れる。そういう付き合い方ができればいいなと思い、この記事を書きました。
参考文献
- Martin Fowler — Harness Engineering
- OpenAI — Harness Engineering
- Latent.Space — Is Harness Engineering real?
- LangChain — The Anatomy of an Agent Harness
- Epsilla — Harness Engineering: Why the Focus is Shifting
- Docker — Flexibility Over Lock-In: The Enterprise Shift
- Anthropic — Effective Harnesses for Long-Running Agents