はじめに
2026年に入ってから、AnthropicとOpenAIが立て続けに「harness」という同じ言葉でエンジニアリングブログを出しました。解いている問題もほぼ同じで、エージェントを数時間〜十数時間走らせて、破綻させずに最後まで持っていくにはどうすればいいか、という話です。
ところが、出してきた答えは見事に逆方向でした。Anthropicはエージェントを三つに分けて互いに監視させる方向に進み、OpenAIはコードベースと環境そのものをharnessにする方向に進んでいます。
ぼく自身、最初は「両方ともモデルが伸びた末に必要になった足場の話だな」くらいに読んでいたんですが、何度か読み返すうちに、これは単なるアーキテクチャ比較じゃなくて、harnessというものをどう捉えるかの哲学の違いだと気付きました。そして実は、入り口は逆方向なのに、二社とも最後はまったく同じ結論に辿り着いているんです。
この記事では、両社のアプローチを並べて読み解きながら、その共通結論が何を意味するのかまで踏み込んでみます。引用元はAnthropicのHarness design for long-running application developmentと、OpenAIのHarness engineering: leveraging Codex in an agent-first world、それぞれの公式エンジニアリングブログです。
そもそもharnessとは
harnessというのは、ざっくり言えばモデルの重み以外のすべてです。最近よく引用される定義に「Agent = Model + Harness。If you're not the model, you're the harness.」というのがありますが、これがそのまま実態を言い当てています。
似た言葉にscaffoldingがありますが、両者は別物として扱う流派が増えています。scaffoldingは最初のプロンプトが投げられる前にエージェントを組み立てるためのテンプレートやプロンプト構造、harnessはプロンプト後に走り続ける部分、つまりツール実行、コンテキスト管理、状態の永続化、ガードレール、サブエージェントの編成、観測性などです。
具体的にharnessに含まれるものを並べると、システムプロンプトとスキル定義、MCPサーバーやCLIツール、サンドボックスやファイルシステム、サブエージェントのスポーン、フックやpre-commitチェック、ログとコスト計測、このあたりです。要するに、モデルが世界と関わるための配管全部、と思っておけばだいたい合っています。
ここで一つ覚えておくと後の話が楽になるのは、harnessの各部品は「モデルがまだこれをできない」という仮定を内包しているということです。この前提が、後半の核心と関わってきます。
Anthropicの答え：三つのエージェントを分離する
Anthropicの記事が解こうとしたのは、Claudeに数時間かけて1本の完全なアプリを作らせる、というかなりハードな問題でした。
このスケールで何が起きるか、原文では二つの失敗モードを挙げています。
一つ目がcontext anxietyです。コンテキストウィンドウがまだ余裕があるのに、モデルが「そろそろ終わりに近いな」と勝手に判断して、タスクを早めに切り上げてしまうという現象。Sonnet 4.5世代では、このcontext anxietyが強く出ていて、コンテキストを単に圧縮（compaction）するだけでは足りなかった、と書かれています。
二つ目がself-evaluationの甘さです。エージェントに自分の成果物を評価させると、人間の目から見て明らかに微妙な出来でも、自信を持って褒めてしまう。これは長時間タスクだと致命的で、何ターンも自己評価を続けるうちに、品質がどんどん下がっていきます。
この二つに対して、Anthropicが取った答えが三層構造です。
- Planner：1〜4文の要望を、完全な製品仕様に展開する。「何を、なぜ作るか」に集中して、「どう作るか」までは降りない
-
Generator：実際に実装する。一つのコンテキストウィンドウで進めて、JSON仕様、
claude-progress.txt、git commitを通じて次のセッションに申し送る - Evaluator：Playwright MCPで実際にブラウザを動かして、UI、APIエンドポイント、データベースの状態を本物のユーザーのように検証する。スクリーンショットを採点するんじゃなくて、本当に画面を触る
ここで個人的に一番効いているなと思ったのが、EvaluatorがPlaywrightで実物を触るという設計です。LLM-as-judgeで静止画を見せて点数を付けさせる、というよくあるパターンとは決定的に違っていて、ルーティングの順序ミスのような、画面を触らないと露呈しないバグまで拾えます。
そしてもう一つ、原文で丁寧に区別されているのがcompactionとcontext resetです。
compaction:
同じエージェントの履歴を要約・圧縮して、続きを走らせる
連続性は保てるが、汚れたコンテキストはそのまま残る
context reset:
コンテキストを完全に空にして、新しいエージェントを起動
前任者の状態と計画は構造化されたファイルで申し送る
オーケストレーション複雑度・トークン消費・遅延すべて増える
でもSonnet 4.5世代では必須だった
Sonnet 4.5でcontext anxietyが強かった頃は、compactionだけでは粘れなくて、resetを組み込むしかなかった。これは原文にもはっきり書いてあります。
数字も具体的で、レトロゲームメーカーを作るタスクの場合、単一エージェントだと20分・$9で済むところが、フルharnessだと6時間・$200まで膨らむ。ざっと20倍の差です。harnessはタダじゃない、というのが実装数字でちゃんと示されているのは個人的に好印象でした。
OpenAIの答え：環境そのものをharnessにする
ほぼ同じ時期、OpenAIもHarness engineering: leveraging Codex in an agent-first worldというタイトルでブログを出しました。問題意識は同じで、長時間走るエージェントをどう破綻させずに動かすか。
ところがアプローチが正反対です。エージェントを増やすのではなく、コードベース（環境）自体をharnessにするという発想なんです。
中核のアイデアを一文で言うと「the right thing to do is obvious and the wrong thing is hard」。エージェントが正しいことをするのが当たり前で、間違ったことをするのが難しい、そういう環境を先に作っておく、ということです。
具体的に何をしているかというと、まずコードベースに厳密な依存層を強制します。
Types → Config → Repo → Service → Runtime → UI
下の層は上の層に依存できない。これをlinterとCIで機械的に強制する。型システムも噛ませる。こうすると、エージェントが「正しい場所に正しいものを書く」しかない状態になります。間違ったレイヤーに書こうとした瞬間、CIが赤くなる。モデル側の判断ミスが、環境の側で勝手に弾かれる仕組みです。
長時間タスクの持続については、OpenAIは別の記事Run long-horizon tasks with Codexでもう少し具体的に書いています。鍵になるのが4つのmarkdownファイルです。
Prompt.md : ゴール、制約、完了条件の仕様書
Plan.md : チェックポイント単位のマイルストーン + 検証コマンド
Implement.md : 実装ランブック。エージェントの作業規律
Documentation.md : 進捗ログ。共有可能な状態
各マイルストーンの後で、テスト、lint、型チェック、ビルドを必ず走らせる。失敗したら次に進む前に直す。この検証ループが、エージェントが文脈を失ってもプロジェクトを継続させる仕組みになっています。
数字もインパクトがあって、Codexは25時間連続で動き続け、1300万トークンを消費して、3万行のコードで機能する設計ツールを作り上げたと報告されています。さらに5ヶ月の実験では、3名のエンジニアが約1500のPRをマージ、100万行のコードを生成。1人あたり1日3.5PRというペースです。
ここで個人的に印象に残ったのは、OpenAIのharnessにはLLMで構成されたEvaluatorが見当たらないことです。検証はテストとCIとビルド、つまり決定論的な仕組みでやらせている。Anthropicが「モデルにモデルを監視させる」のに対して、OpenAIは「環境にモデルを矯正させる」。同じ問題に対する答えとして、これだけ違う方向に振り切れるのか、と素直に驚きました。
二つのアプローチを並べてみる
ここまでを整理すると、こうなります。
| 観点 | Anthropic | OpenAI |
|---|---|---|
| harnessの形態 | LLMエージェントを複数（Planner/Generator/Evaluator） | コードベース・CI・linterそのもの |
| 検証の仕方 | 別エージェントがPlaywrightで実物を触る | 環境が機械的に許さない（型/CI/lint） |
| 長時間化の方法 | Context Reset + 構造化申し送りファイル | Prompt.md/Plan.md/Implement.md/Documentation.md |
| 比喩 | GAN：生成と判別の対立で品質を上げる | コンパイラ＋CI：間違いは弾かれて通らない |
| 代表数字 | 6時間 / $200（フルharness） | 25時間 / 13Mトークン / 3万行 |
これを見て、どっちが優れている、という話にしたくなる気持ちもあるんですが、ぼく個人的にはどっちも筋が通っていて、前提にしている世界観が違うだけだと感じています。
Anthropicはモデルにモデルを監視させるほうに賭けています。Evaluatorはモデル単独の判断より厳しい目を持てる、という前提です。だからEvaluatorのプロンプト調整に何ラウンドもかけて、人間の判断と揃うまで磨き込む。
OpenAIは環境にモデルを矯正させるほうに賭けています。型システムとCIは決定論的で、モデルがどれだけ自信満々でも間違いは間違いとして弾ける、という前提です。だから依存層をきっちり切って、各マイルストーンで検証コマンドを必ず走らせる。
どちらが効くかは、たぶんタスクによります。フロントエンドのデザイン品質みたいに主観評価が重い領域ではAnthropicのEvaluatorが筋が通っていますし、大規模コードベースで一貫性を保ちたいようなルールが明文化しやすい領域ではOpenAIの環境制約のほうが安く済むはずです。
それでも両社が同じ結論に辿り着いた
ここからが本記事で一番言いたい部分です。
入り口がこれだけ違うのに、AnthropicもOpenAIも、最後は同じ結論に辿り着いています。モデルが強くなっても、harnessは消えない。ただ移動するだけ、という結論です。
Anthropicの原文の言葉を借りると、こうなります。
"the space of interesting harness combinations doesn't shrink as models improve. Instead, it moves, and the interesting work for AI engineers is to keep finding the next novel combination."
これは、おそらく何度も引用されることになる一節だと思います。
実際、AnthropicはOpus 4.6の登場でsprint構造を丸ごと削除しました。以前は1ターンずつ細かく区切らないとモデルが連貫性を維持できなかったんですが、新世代では一つのタスクを2時間以上連続で走らせても破綻しなくなった。Evaluatorも、毎ターン呼ぶ必要がなくなって、本当に難しいフェーズだけに絞るようになりました。harnessが薄くなっています。
ところがOpenAIの側を見ると、harnessは薄くなったというより、重心が違う場所に移ったように見えます。モデルが25時間走れるようになったから、harnessの仕事は「エージェント間の細かい調整」から「環境の制約力をどう設計するか」のほうに移っていった、という構図です。
つまり両社とも、harnessを消したわけじゃないんです。別の場所に移している。
そして、この原稿を書いている間にも、両社はさらに新しいモデルを投入しています。Anthropicは2026年4月にOpus 4.7を、OpenAIは同月にGPT-5.5を出しました。Opus 4.7は「long-horizon agentic work」で大きく伸びたと公式に書かれていて、harnessの重心がさらにどこかへ移動し続けることは、ほぼ確実です。記事中の数字（Opus 4.6の3時間50分、GPT-5.3-Codexの25時間）も、半年後には「あの頃はそうだったね」という話になっている可能性が十分あります。
ここで思い出してほしいのが、最初のほうで触れた「harnessの各部品は、モデルがまだこれをできないという仮定を内包している」という話です。この仮定は、モデルが代替わりするたびに再検証が必要で、それを怠ると、もう要らない部品をずっと抱え込むことになります。逆に、新たに必要になる部品もあるはずで、そこに気付けるかどうかが、harness設計者の腕の見せどころになる気がしています。
まとめ
harnessは固定テンプレートじゃなくて、モデル能力の境界が動くたびに再計算するものだと考えるのが、たぶん一番健全な向き合い方だと思います。
強いAIエンジニアは、足場を組める人だけじゃなくて、外せる人でもある。ぼく自身、これは結構刺さった話で、自分の手元のharnessを見直して「これ、もう要らないんじゃないか」と問い直すクセを付けるようになりました。
皆さんのharness、まだ承重しているのはどの部品でしょうか？もし「これは要らないかも」「ここは新しく必要になりそう」みたいな気付きがあれば、コメントで教えてもらえると嬉しいです。