長時間動くエージェントのハーネス設計 — Anthropicが社内で組んだPlanner / Generator / Evaluatorの三段構成

Anthropic LabsのPrithvi Rajasekaran氏が2026年3月24日付で公開した「Harness Design for Long-Running Application Development」は、1行のプロンプトから3 〜 6時間動き続けてフルスタックアプリを書き上げるエージェントをどう組んだかを内部視点で書いた記事です。プロンプトエンジニアリング単体ではなく、エージェントを取り囲むハーネス(harness、足場)の設計が主題で、Generator-Evaluatorループ・Sprint Contract・モデル更新時のハーネス削減という3つのトピックを軸に語られています。

本記事では原文の主張をなぞるのではなく、設計判断の背景・実務に翻訳した示唆・前後のAnthropic engineering記事との位置付けを順に見ていきます。

背景: なぜ「ハーネス」を独立した設計対象として扱うのか

長時間動くエージェントは、単に良いプロンプトと強いモデルを用意しただけでは安定しません。コンテキストウィンドウが満杯に近づくと出力品質が落ち、自己評価は甘く、複雑なタスクではどこかで筋が外れる、というのが従来の実装で繰り返されてきた失敗パターンです。

Rajasekaran氏のチームは、この現象をモデル能力の限界ではなく、モデルを使う側の設計(ハーネス)の限界として切り分け直しました。プロンプトエンジニアリングが頭打ちになったあとに上限を引き上げるのは、モデルの周りに置く構造、つまり「いつコンテキストをリセットするか」「誰が誰の出力を評価するか」「タスクをどう分割するか」といった足場の設計だ、というのが出発点です。

Anthropicはすでに長時間エージェントのコンテキスト戦略で、context rot(文脈の擦り切れ)に対抗する4つの戦略を整理しています。本記事はその戦略を実際のフルスタック開発エージェントに当てはめて、どの戦略がどのモデル世代で必須・不要になったかをログ付きで開示した実装報告として読めます。

「コンテキスト不安」とCompaction / Context Resetの使い分け

記事のなかで最も具体的に書かれているのが、Claude Sonnet 4.5を使った長時間タスクで観測されたcontext anxiety(コンテキスト不安)です。コンテキストが上限に近づくとモデルが「そろそろ終わらせなければ」と判断するように振る舞い、まだ終わっていないタスクを途中で切り上げてしまう挙動を指します。

これに対する選択肢として、記事は次の2つを提示しています。

要約だけでは「不安そのもの」が引き継がれてしまうため、根本対処としてはContext Resetを採る、というのがLabsチームの結論です。リセット時には自由記述の要約ではなく 構造化されたファイル(structured artifact)で次のエージェントに状態を渡し、再開時の認知負荷を下げる作りになっています。

これはエージェント向けツール設計の原則の「エージェントに渡す情報はtoken-efficientなフォーマットを選ぶ」という指針と裏表の関係にあり、エージェント間の情報受け渡しでも同じ思想が貫かれています。

フロントエンド設計を数値化するGenerator-Evaluatorループ

主観的な評価軸しかないと思われがちなビジュアルデザインを、4つの基準でスコア化したのが本記事の前半の山場です。

4つの評価軸

評価基準そのものが生成内容を方向付けるという観察も書かれていて、たとえば "museum-grade(博物館級)" のような言葉を採点軸に入れると、生成側のビジュアルが収束しやすくなる、と報告されています。

GeneratorとEvaluatorの分離

GeneratorがHTML/CSS/JSを生成し、EvaluatorはPlaywright MCPを使って実際に立ち上がったページをクリック・スクリーンショット・遷移させ、4軸でスコアを付ける、という構図です。1サイクルの評価に5 〜 15イテレーション、トータルで4時間に及ぶケースもあるとのこと。

GeneratorとEvaluatorを同じモデルでも別エージェントとして分けることには明確な意図があります。記事中で繰り返し触れられているのは「Claudeはデフォルトでは甘いQAエージェント」という指摘で、自分の出力を自分で採点させると、客観的基準のないデザイン領域では特に肯定的に評価しがちだ、ということです。Evaluatorにスケプティカルな(疑り深い)プロンプトを与え、生成者と分離することで、はじめて意味のあるフィードバックが回り始めると書かれています。

Playwright MCPのようなブラウザ操作系MCPサーバを評価器に組み込む発想は、UIを実際に触らないと検出できないバグを拾うために必要な構成です。MCPの使いどころを広げたい場合はMCP実用ガイドも併せて読むと、自作MCPサーバをEvaluator側に立てる選択肢が見えてきます。

フルスタック開発に拡張した三段構成

フロントエンド設計で得た「生成と評価を分ける」発想を、フルスタックアプリ生成に拡張したのがPlanner / Generator / Evaluatorの三段構成です。

役割分担

• Planner: 1 〜 4文のシンプルなプロンプトを16機能規模の詳細仕様まで拡張する。実装詳細ではなく、製品コンテキストと高レベル技術設計、AI機能の組み込み機会の発掘に集中する
• Generator: React / Vite / FastAPI / SQLiteまたはPostgreSQLのスタックで、Sprint(機能1つ単位)ごとに実装とGitコミットを行う
• Evaluator: Playwright MCPでアプリを実際に動かし、UI・APIエンドポイント・DBの状態をスプリント単位で硬い閾値付きで採点する

Sprint Contractという橋渡し

三者の連携を支えるのがSprint Contractという仕組みです。実装に入る前にGeneratorとEvaluatorが「このスプリントの完了の定義」を交渉して合意し、その契約をファイルベースで保存しておきます。Plannerが出した抽象的な仕様と、Generatorが書ける具体的な実装単位の橋渡しを担う層で、Agent SDKが提供するファイル管理機能が裏で動いています。

Sprint Contractの発想はAgent SDK入門で扱う「エージェント間で状態をどうファイルに落とすか」の延長線上にあり、エージェントを増やすほど「どこに何を置くか」のプロトコル設計が利いてくることが実装報告として裏付けられています。

2Dレトロゲーム生成での比較データ

本記事のもう1つの見どころは、単一エージェント方式とフルハーネス方式を同一プロンプトで並べた比較データです。題材は「2Dレトロゲームメーカー」。

費用は22倍、時間は18倍ですが、動かないアプリと動くアプリの差を生んだ、というのがAnthropic側の評価です。9ドルの単一エージェント版はproductionとしては使えない、という線引きが明示されています。

ハーネス側のコストが時間と金額の両方で重いことは、後段のOpus 4.6への移行で大きな意味を持ってきます。

Opus 4.6への適応で外した部品

記事の後半は、新しいモデルが出たときにハーネスをどう作り直したかの記録です。

Sprint構造を廃止できた理由

Opus 4.6では「より慎重な計画、長期agenticタスクの持続力、大規模コードベース操作の信頼性、コードレビュー・デバッグスキル」が向上し、長文脈検索も大幅に改善した、とAnthropic側は説明しています。これによって、

• Sprintで機能を1つずつ刻まなくても、2時間以上の連続構築が一貫性を保てる
• Evaluatorはタスク難度に応じて条件付きで挟む(必須ではない)

という形に簡素化されました。

DAW(デジタル・オーディオ・ワークステーション)生成の実例

Opus 4.6でSprintなしのハーネスを動かした例として、ブラウザ上のDAWをWeb Audio APIで作るタスクが紹介されています。

EvaluatorがOpus 4.6のビルドに対して指摘したギャップとしては、「Clipがタイムライン上でドラッグできない」「シンセのつまみやドラムパッドのUIパネルがない」「エフェクトの可視化が数値スライダーのままでEQカーブのようなグラフィカル表示がない」といった、UIを実際に触らないと出てこない指摘が並びます。Generator単体では検出しにくいレベルの欠落を、外部評価者が拾えていることが示されています。

Sonnet 4.5のフルハーネス(6時間 / 200ドル)と比べると、Opus 4.6 + 簡素化ハーネスは3時間50分 / 124.70ドルで同等以上の成果を出しています。モデルが進化したらハーネスも作り直せるという主張の裏付けデータとして読める数字です。

モデル更新時のハーネス再点検という運用観点

記事全体を通して繰り返されるテーマは「モデルが上がるたびにハーネスを1コンポーネントずつ外して影響を測る」という運用思想です。

新モデルが出たときに、

1. ハーネスを丸ごと使い回す
2. 各部品を1つずつ無効化して採点を比較する
3. 改善が出ない部品(load-bearingでない部品)を取り除く
4. 必要に応じて新しい部品を入れ替える

という手順で、ハーネスを「最もシンプルな形」まで削っていく作法が示されています。Sonnet 4.5では必須だったSprint分割がOpus 4.6では条件付きになった、というのはまさにこの手順の結果として記述されています。

これはAnthropicが公開したClaude Codeの自動承認モードやサンドボックス設計の文脈とも通底していて、エージェントを取り巻く外側の仕掛け(承認・サンドボックス・ハーネス)はモデル能力に応じて簡素化していくのが中長期の方向だ、と読めます。

ハーネス設計の判断早見表

記事から読み取れる判断軸を、開発者がハーネスを組むときに参照しやすい形にまとめます。

編集視点: 「ハーネスは消耗品」という前提が示されたこと

本記事の踏み込みどころは、ハーネス自体を使い捨て前提の消耗品として扱う姿勢をAnthropic側が公式に書いた点と読めます。これまでのエージェント設計ノウハウは「再利用できる足場をどう作るか」という方向で語られがちでしたが、Rajasekaran氏はモデルが変わったら同じハーネスは合わない可能性が高い、という認識を実装ログ付きで示しています。

エージェントを業務システムに組み込む立場から読むと、これは「ハーネスをライブラリ化して長期保守する」発想に対する一定のブレーキでもあります。Sonnet 4.5用に組んだ精緻なSprint分割が、Opus 4.6では純粋なオーバーヘッドになるケースがある、というのは、企業内で1 〜 2年かけて作ったエージェント基盤が陳腐化しうることを示唆しています。

実務での現実的な落としどころは、ハーネスのコンポーネントを疎結合に保ち、各部品を独立に有効化 / 無効化できる作りにしておくことだと読めます。Plannerだけ、Evaluatorだけ、Sprint Contractだけ、というように粒度を保ってあれば、新モデルが出たときの「1コンポーネントずつ外す」運用がそのまま回ります。

まとめ

• 長時間動くエージェントの上限を引き上げるのは、プロンプトではなくエージェントを取り囲むハーネス(足場)の設計
• 主観的な品質も、Evaluatorを分離して4軸で採点すれば数値化できる(Generatorの自己採点は甘い)
• Planner / Generator / Evaluatorの三段構成とSprint Contractで、1行のプロンプトから6時間動くアプリ生成が成立した
• モデルが上がると(Sonnet 4.5 → Opus 4.6)Sprint分割のような部品は外せる場合があり、コストと時間が同時に下がる
• ハーネスは消耗品。新モデル登場時に1コンポーネントずつ無効化して、load-bearingでない部品を削ぎ落とす運用が前提

具体的な実装テンプレートやAgent SDKのコード例は記事内では公開されていませんが、設計思想と評価軸は再現可能な粒度で書かれています。自社で長時間エージェントを組む場合、まずはGenerator-Evaluatorの分離だけを導入して、PlannerやSprint Contractを後段で足していく順序が現実的に思えます。