こんな経験はありませんか？
同じ Claude、同じ GPT-4o なのに、ある人は 5 ヶ月で 100 万行のコードを書き、別の人は 2 時間も安定して動かせない。
モデルは同じなのに、結果は天と地の差。
問題はどこにあるのでしょうか？
最近、OpenAI、Anthropic、Martin Fowler、Phil Schmid の記事をたくさん読んだのですが、彼らは皆、同じことを言っていることに気づきました。
彼らはそれを ハーネスエンジニアリング と呼んでいます。
簡単に言えば、エージェントのための「オペレーティングシステム」を構築することです。
まず、ハーネスとは何かを理解する
Phil Schmid は HuggingFace のブログ記事で素晴らしい例えを挙げています。
エージェントシステムをコンピュータと考えてみてください。
モデルは CPU で、生の計算能力を提供します。コンテキストウィンドウは RAM で、一時的に物事を保存します。エージェントはその上で動作するアプリケーションです。
では、オペレーティングシステムは何でしょうか？
ハーネスがオペレーティングシステムです。
OS がなければ、最も強力な CPU でも単なるチップです。チップではタイピングできません。
同様に、ハーネスがなければ、最も賢いモデルでも単なるチャットボックスです。複雑なタスクを 1 時間実行させたら、コンテキストを忘れたらどうするのか？ 誰がガベージコードを書くのを止めるのか？ 間違いを犯しても気づかないとしたら？
これらは「より賢いモデルに切り替える」ことで解決する問題ではありません。
Martin Fowler が印象的な言葉を残しています。ハーネスは将来、「サービステンプレート」になるかもしれないと。今日、新しいプロジェクトをサービステンプレートで始めるように、新しいエージェントをハーネステンプレートで始めるようになる、と。
この予測は実現する可能性が高いと思います。
なぜ 2026 年に突然爆発的に広がっているのか？
なぜなら、モデルが今や十分に強力だからです。
2024 年には、誰もが自分のモデルがより賢いことを競っていました。2026 年までに、トップクラスのモデル間の差は非常に小さくなりました。Claude と GPT に同じ問題を与えても、スコアの差はわずか数ポイントです。
しかし、8 時間連続で作業させると、差が現れます。
この差はモデル自体にあるのではなく、それを取り巻く「ハーネス」にあります。
OpenAI の Codex チームには驚くべき統計があります。彼らは Codex を使って完全な製品を構築しました。5 ヶ月、100 万行のコード、手書きはゼロ行。その過程で、ボトルネックはもはや「モデルがコードを書けるかどうか」ではないことがわかりました。
ボトルネックは、人間がコードを十分な速さでレビューできるかどうかでした。
モデルの出力速度は人間のレビュー速度を超えています。この時点で、モデルを最適化しても意味がありません。最適化すべきは、レビュープロセス、品質管理、アーキテクチャの制約です。
それがハーネスの役割です。
三つの柱
では、ハーネスには実際に何が含まれているのでしょうか？
これらの記事を読んで、用語はさまざまですが、三つの中核的な柱があることがわかりました。
1. 評価のクローズドループ
これは Anthropic が最も強調している点です。
核となる考え方はシンプルです。エージェントは自分自身を採点できません。
考えてみてください。インターンがレポートを仕上げて、どうだったか尋ねると、「まあまあです」と言うでしょう。評価するには独立した人が必要です。
Anthropic はこれを「評価駆動開発」と呼んでいます。まず「うまくできた」とはどういう状態かを定義し、次にエージェントに実行させ、最後に独立した評価者にスコアを付けさせます。
評価駆動開発は、エージェント版の TDD です。まずテストを書き、次にコードを書く。ただし、ここでの「テスト」はエージェント用です。
評価者はコードを見るだけではありません。実際に製品を操作します。Playwright を使ってボタンをクリックし、フォームに入力し、テストを実行し、明確な基準に基づいて判断します。
ここで興味深い事例があります。
Anthropic の Opus 4.5 は、フライト予約テスト中に予約ポリシーの抜け穴を見つけ、正解よりも優れた解決策を見つけました。
しかし、評価者はそれを「不合格」と判定しました。
なぜでしょうか？ 評価者がそのような創造的な解決策を想定していなかったからです。正解は一つしかなく、エージェントがより良い解決策を見つけたためにペナルティを受けたのです。
この話は二つのことを示しています。第一に、エージェントは人間が考えつかなかった解決策を見つけるほど賢いということ。第二に、評価ループはエージェントをチェックするだけでなく、評価自体もチェックしているということです。評価者が硬直的すぎると、それがボトルネックになります。
別のデータポイント：Opus 4.5 は CORE-Bench で当初 42% のスコアでした。採点のバグを修正し、スキャフォールドの制約を緩和したところ、スコアは 95% に跳ね上がりました。
多くの場合、モデルが十分でないのではなく、ハーネスに問題があるのです。
この方法を用いて、Anthropic はエージェントに 6 時間で完全なゲームを 200 ドルで構築させました。
2. アーキテクチャの制約
これは OpenAI Codex チームの得意分野です。
インターンに「コードは階層化する必要がある」と言っても、彼らはうなずき、すぐに UI ロジックをデータベース層に書いてしまいます。
言葉で言っても無駄です。
OpenAI のアプローチは、リンターと CI で機械的に強制することです。アーキテクチャのルールに違反するコードは即座に拒否され、レビューすら受けません。
彼らのコード階層は次のようになっています。Types → Config → Service → UI。各層はその上の層にのみ依存でき、逆は不可です。このルールは文書に書かれているだけでなく、リンターに記述されて自動チェックされます。
さらに良いことに、これらのリンター自体が Codex によって生成されています。
エージェントは自分自身のルールを書き、それに従うのです。
Martin Fowler は OpenAI の記事を読んでこう言いました。
「信頼性と信頼性を高めるには、ソリューション空間を制約する必要がある。これは『何でも生成できる』柔軟性の一部を放棄することを意味する。」
制約が多ければ多いほど、信頼性が高まります。
直感に反するように聞こえますが、データが物語っています。LangChain が実験を行いました。モデルは変えずにハーネスだけを変更したところ、Terminal Bench 2.0 の合格率が 52.8% から 66.5% に跳ね上がりました。Vercel はさらに進んで、エージェントツールの 80% を削除した結果、ステップ数が減り、速度が向上し、結果も改善しました。
ツールが少ないほどパフォーマンスが向上することが多い——この結論はエージェント分野で繰り返し検証されています。
3. メモリガバナンス
この柱はあまり議論されていませんが、長期的には最も重要だと思います。
PrismerCloud はこの方向で深い研究を行っています。
問題は、複数のエージェントがナレッジベースを共有する場合、エージェント A が経験を書き、エージェント B がそれを真実として読むことです。しかし、エージェント A が間違っていたらどうなるでしょうか？
あるエージェントの幻覚が、共有ナレッジベースを通じてすべてのエージェントに汚染される可能性があります。
PrismerCloud のアプローチは、「進化エンジン」を構築することです。すべてのエージェントの経験はまず「シグナル」として記録されます。検証されると、シグナルは「遺伝子」に蒸留され、実際の結果に基づいて継続的に最適化されます。
簡単に言えば、遺伝子は検証された効果的な知識です。検証されていなければ、カウントされません。
興味深い統計があります。3 行のプロンプトとメモリシステムは、200 行の慎重に作成されたエキスパートプロンプトとほぼ同等のパフォーマンスを発揮します。さらに、前者は進化しますが、後者は静的です。
つまり、メモリシステムが優れていれば、複雑なプロンプトは必要ありません。エージェントは時間の経過とともに自然に改善されます。
おまけ：エントロピー耐性
これは独立した柱ではありませんが、言及する価値があります。
エージェントシステムは時間の経過とともに自然に劣化します。ドキュメントは期限切れになり、アーキテクチャは迂回され、ナレッジベースは古い情報で埋め尽くされます。
OpenAI のアプローチは、定期的に「リファクタリングエージェント」を実行して、ドキュメントの不整合やアーキテクチャ違反をスキャンすることです。彼らは次のように最もよく言っています。
「エージェントが苦戦した場合、それをシグナルとして扱う。何が不足しているかを見つけ出し、コードベースにフィードバックし、常に Codex に修正を書かせる。」
エージェントに問題がある場合、エージェントだけを修正するのではなく、ハーネスを修正してください。この考え方が鍵です。
これを実践しているのは誰か？
この分野は二つの道に分かれています。今日すぐに使えるオープンソースプロジェクトと、方法論を学ぶことしかできない企業の内部実践です。
オープンソースプロジェクト：すぐに使える
LangChain DeepAgents：おそらく「ユニバーサル Claude Code」に最も近いオープンソースプロジェクト。計画、ファイル操作、サブエージェント委任、自動コンテキスト圧縮——すぐに使えます。GitHub で 115k スター。
DeerFlow 2.0：ByteDance 製。3 月にオープンソース化され、1 ヶ月で 39k スターを獲得。自らを「SuperAgent ハーネス」と呼んでいます。v1 から完全に書き直され、サンドボックス実行、永続メモリ、LangGraph ベースのスキルシステムを備えています。
OpenHands：コーディングエージェントに特化。SWE-bench Verified で 77.6% を達成。モデルに依存せず、Laminar を使用して観測可能性を実現し、すべてのエージェントアクションをトレースします。
SWE-agent：プリンストン大学とスタンフォード大学から。評価駆動開発の完成に焦点を当てています。
Goose：Block（Square/Cash App）によってオープンソース化。依存関係のインストール、テストの実行、ファイル管理が可能な汎用オンマシンエージェント。
PrismerCloud：メモリガバナンスと進化エンジンに焦点。マルチエージェントシステムにおける幻覚汚染を防ぐための最も成熟したソリューション。
Cognee：エージェント向けのナレッジグラフ駆動型メモリエンジン。データ間の意味的な接続を確立するのに役立ちます。
企業の実践：方法論を学ぶ
Claude Code + Agent SDK：Anthropic による汎用ハーネスのベンチマーク。コーディングだけでなく、研究、動画作成、メモ作成にも使用されています。
OpenAI Codex：アーキテクチャ制約の究極の実践。自動生成されたリンターとエージェントのピアレビューに依存し、100 万行のコードを手書きゼロで実現。
私が心に留めている教訓
Rich Sutton は「The Bitter Lesson」という古典的な論文を書きました。要旨は、計算を活用する汎用的な方法は、長期的には人間が設計した特定の方法よりも常に優れているというものです。
この教訓はエージェント分野で再び証明されています。
Manus は 6 ヶ月でハーネスを 5 回リファクタリングしました。LangChain は 1 年で 3 回アーキテクチャを再構築しました。Vercel はツールの 80% を削除しました。
削除するために構築する。
今日書いた「賢いロジック」は、明日モデルがアップグレードされると時代遅れになるかもしれません。アーキテクチャはモジュール化され、いつでも破棄できる準備ができている必要があります。
Phil Schmid は覚えておく価値のある言葉を残しています。
「競争優位はもはやプロンプトではない。ハーネスによってキャプチャされた軌跡だ。すべての成功と失敗は、次世代を訓練するためのデータとなる。」
ハーネスが長く稼働し、蓄積する軌跡が多ければ多いほど、エージェントは強力になります。モデルを切り替えるだけでは追いつけません。
三つの段階
AI エンジニアリングにおけるハーネスの位置づけを次のように考えてみてください。
プロンプトエンジニアリングは「何を言うか」を解決します。単一のインタラクション。
コンテキストエンジニアリングは「何を知るか」を解決します。参照と履歴を提供します。
ハーネスエンジニアリングは「どのように継続的、安定的、かつスケーラブルに作業するか」を解決します。評価ループが品質を保証し、アーキテクチャ制約がルールを保証し、メモリガバナンスが経験の蓄積を保証します。
ハーネスがなければ、エージェントは物事を覚えていても監視がなく、混乱を招きます。三つの層がすべて整っていれば、真に長期的に作業できるキャラクターが生まれます。
OpenAI、Anthropic、LangChain はすでにこれを実践しています。
出典：OpenAI ハーネスエンジニアリング、Anthropic Demystifying Evals、Phil Schmid (HuggingFace) The Importance of Agent Harness in 2026、Martin Fowler ハーネスエンジニアリング、LangChain Agent Frameworks。
