AIエージェントのハーネス設計｜Anthropicが公開した「生成と評価の分離」パターンを読み解く

「AIエージェントに自分の仕事を評価させるな」

Claudeを作っているAnthropic自身が、そう警告しています。

2026年3月24日、Anthropicのエンジニアリングブログに「Harness design for long-running application development」という記事が公開されました。著者はAnthropic LabsチームのPrithvi Rajasekaran氏。

内容を一言でまとめるなら、AIエージェントに長時間かけてアプリを作らせるための設計パターンです。

これが刺さったのは、自分自身がClaude Codeで長いタスクを回したときの「あの感覚」を思い出したからでした。最初は快調にコードを書いてくれるのに、コンテキストが膨らむにつれて品質がじわじわ落ちていく。同じミスを繰り返す。自分で「完了しました」と言うけど、動かしてみると全然動かない。

「自分の仕事を自分で採点させたら、そりゃ甘くなるよな」と思っていた問題に、Anthropicが正面から答えを出してきました。

ハーネス設計の核心｜2つの問題を3つのエージェントで解く

元記事が指摘する根本的な問題は2つあります。

コンテキスト不安

LLMには「コンテキストウィンドウ」という作業記憶の上限があります。Claude Sonnet 4.5では、この上限に近づくと作業を途中で切り上げようとする傾向があったそうです。「もうすぐ限界だから早く終わらせよう」という焦りのような挙動ですね。

元記事では、この問題に対してコンテキストリセットが有効だったと報告しています。会話の要約（コンパクション）ではなく、まったく新しいエージェントを起動し、構造化された引き継ぎ情報だけを渡す。完全なリフレッシュです。

自分もClaude Codeのサブエージェント運用で似た体験をしています。メインのコンテキストウィンドウをクリーンに保つために、調査やコード探索はサブエージェントに任せる。自分のプロジェクト設定にも「サブエージェントを積極的に使ってメインコンテキストをクリーンに保て」と書いているのは、まさにこの問題を体感していたから。ただ、自分の場合は経験則で辿り着いたもので、Anthropicの記事のように体系化されたものではありませんでした。

自己評価の罠

もう1つの問題がこれ。「自分の仕事を自分で評価させると、自信満々に褒める」という現象です。

元記事の表現を借りると、「人間の目には明らかに品質が低いのに、エージェントは堂々と自分の仕事を称賛する」。特にデザインのような主観的なタスクでは、テストを通す/通さないのような二値判定ができないため、この問題が深刻になります。

ここでGAN（敵対的生成ネットワーク）の発想が登場します。

元記事が提案するのは、3つのエージェントによる分業。

• Planner: ユーザーの短いプロンプト（1〜4文）を、包括的なプロダクト仕様書に変換する。具体的な技術詳細には踏み込まず、スコープを広げる役割

• Generator: 仕様書に基づいて、スプリント単位で機能を実装する。コードを書き、自己テストをし、評価者のフィードバックに応じて修正する

• Evaluator: Playwright MCPを使って実際のアプリをブラウザで操作し、ユーザー視点でテストする。具体的な評価基準に基づいてスコアをつけ、バグを特定する

「生成する人」と「評価する人」を分けることで、自己評価の甘さを構造的に排除する。元記事によれば、Evaluatorを懐疑的にチューニングするのは、Generatorに自己批判させるよりはるかに簡単だったとのこと。

$9で壊れたアプリが$200で完動品に

理論だけではありません。元記事には具体的な実験結果が載っています。

レトロゲームメーカー（Opus 4.5）

まず、ソロエージェント（ハーネスなし）の結果から。

• 所要時間: 20分

• コスト: $9

• 結果: ゲームプレイが機能しない。エンティティの配線が壊れていて、ワークフローが硬直

次に、ハーネス構成（Planner + Generator + Evaluator）の結果。

• 所要時間: 6時間

• コスト: $200

• 結果: 物理演算が動く完全にプレイ可能なゲーム。スプライトアニメーション、AI支援機能、共有リンクまで実装済み

コストは22倍。でも出力の質は比較にならないレベルです。$9では壊れたおもちゃしかできなかったものが、$200で16機能を備えた完動品になっている。

ここで面白いのがスプリント契約という仕組み。GeneratorとEvaluatorが実装前に「何を作るか」「どう検証するか」を合意してから着手します。あるスプリントでは27項目の検証基準を含む契約が交わされたそうです。仕様書レベルでは抽象的すぎ、コードレベルでは詳細すぎる。そのちょうど中間の粒度を、この契約が埋めていました。

DAWアプリ（Opus 4.6での改善）

モデルがOpus 4.6に進化した結果も報告されています。

• 所要時間: 3時間50分

• コスト: $124.70

• 内訳: Planner 4.7分/$0.46、Build 3回 合計3時間20分/$113.85、QA 3回 合計25分/$10.39

注目すべきは、Opus 4.6ではスプリント構造そのものが不要になったこと。モデル自身が長い一貫したタスクを処理できるようになり、細かいスプリントに分解する必要がなくなりました。Evaluatorの価値も「常に必要」から「タスクによっては有効」に変化しています。

自分のAPIコスト感覚で言えば、$124.70（約1.9万円）は決して安くはないです。ただ、「4時間弱で完動品のDAWアプリが出来る」と考えると、フリーランスのエンジニアに依頼するコストとは桁が違う。問題は「何を作らせるか」のセンスのほうにあるんだろうなと感じます。

私の見解｜ハーネス設計は「モデルと一緒に育てるもの」

ここからは元記事を踏まえた自分の考察です。

「興味深い領域」は縮小ではなく移動する

元記事で最も印象に残ったのがこの一節でした。

Opus 4.5では必須だったコンテキストリセットが、Opus 4.6では不要になった。スプリント分割も不要に。じゃあハーネスは要らなくなるのかというと、そうではない。モデルが賢くなった分、より複雑なタスクに挑戦できるようになり、そこには新しいハーネスの出番がある。

これは自分がClaude Codeを使っていて体感していることとも一致します。半年前は「ファイルを1つ修正する」レベルの依頼が限界だったのに、今はサブエージェントを使ったリサーチ、並行タスクの実行、品質チェックの自動化まで任せられるようになりました。ツールの能力が上がると、「任せたい仕事」のレベルも上がる。ハーネスは不要になるのではなく、別のところで必要になるんです。

評価基準の言語化が出力を形づくる

元記事の中で実践的に最も重要だと感じたのは、「評価基準のwording（言い回し）がGeneratorの出力を方向づける」という発見。

たとえば、評価基準に「最高のデザインは美術館品質である」と書いたら、出力が特定のビジュアルスタイルに収束した。しかも最初のイテレーション時点で、基準なしのベースラインより明らかに良い出力が得られたそうです。

これはプロンプトエンジニアリングの話でもありますが、もう少し深い話だと思っています。評価基準は「ジャッジの道具」であると同時に、ゴールの解像度を上げる道具でもある。「良いコードを書いて」ではなく「テストカバレッジ80%以上、関数あたり30行以内、型安全」と書いたほうが良い出力が出るのは、評価しやすいからだけではなく、ゴールが具体的になるからです。

自分のプロジェクト設定にも「タスク完了を宣言する前に必ず動作確認を行う」と書いていますが、これは「評価基準を事前に言語化する」の簡易版だったのだと気づきました。

「素のClaudeはダメなQAエージェント」という正直さ

元記事には「Out of the box, Claude is a poor QA agent（素の状態では、ClaudeはダメなQAエージェントだ）」という一文があります。

自社モデルの弱点をここまで率直に書くのは、かなり信頼できるなと感じました。「こうすればうまくいく」だけでなく、「ここは上手くいかなかった」「このコストがかかった」と正直に書いている。技術ブログとしてお手本のような記事です。

この記事が示す次の一手

元記事の知見を踏まえて、今日から試せることを3つ挙げます。

1. 生成と評価を分ける習慣をつける

Claude Codeでコードを書かせたら、別のコンテキスト（サブエージェントや新しいセッション）でレビューさせる。同じ会話の中で「これで合ってる？」と聞いても、「はい、合っています」と返ってくるだけです。

2. 評価基準を先に書く

「いい感じにして」ではなく、具体的な評価基準を言語化してから作業を依頼する。基準の解像度がそのまま出力の品質に直結します。元記事が示したように、基準を書くだけで初回の出力が改善する。これは今すぐ誰でも試せる。

3. ハーネスの「賞味期限」を意識する

今うまく機能しているワークフローも、モデルのアップデートで不要になる可能性があります。定期的に「この仕組み、まだ必要？」と検証する習慣が大切。元記事の言葉を借りれば、「ハーネスの全コンポーネントは、モデルが単独でできないことについての仮定をエンコードしている。その仮定はストレステストする価値がある」。

Anthropicの元記事は、AIエージェントを「使う」から「設計する」へのシフトを促す内容でした。モデルが賢くなればなるほど、「何を任せ、何をチェックし、どう分業するか」の設計力が問われます。これはエンジニアだけの話ではなく、AIを使って仕事をするすべての人に関わるテーマです。

元記事はこちらから読めます。
Harness design for long-running application development - Anthropic

#takibiラボ #takibiラボ_AI #ClaudeCode #AIエージェント #Anthropic #ハーネス設計 #LLM #AI開発