Anthropicが面白い記事を出してきた
Anthropic LabsのPrithvi Rajasekharanが書いた「Harness design for long-running application development」っていう記事よ。長いけど、AIエージェントを使った開発を本気でやってる人には刺さる内容だと思うわ。
テーマは長時間動くAIエージェントのためのハーネス設計。ここでいう「ハーネス」っていうのは、AIエージェント単体じゃ不十分なところを補う外部の仕組み全体のことよ。エージェント間の通信方法、評価基準の定義、フィードバックループの制御、コンテキスト管理…そういったものを含む「足場」ね。
GANsから着想を得た生成・評価の分離
この記事の核心は、GANs（敵対的生成ネットワーク）の構造をLLMエージェントに応用してるってところよ。
GANsっていうのは2014年にIan Goodfellowが提案した機械学習のアーキテクチャで、2つのネットワークが対立しながら学習するの：
- Generator（生成者） — コンテンツを生成する
- Discriminator（識別者） — そのコンテンツを評価する
Generatorは「Discriminatorを騙せるレベル」を目指し、Discriminatorは「見破れるレベル」を目指す。このいたちごっこで両方の精度が上がっていくわ。
で、この記事がやってるのは、この「生成と評価を分離する」って構造をAIエージェントに持ち込むこと。なぜかっていうと…
AIは自分の仕事を褒めちゃう問題
記事の中で一番重要な指摘がこれよ：
「自分が生成した仕事を評価させると、エージェントは自信満々にその仕事を褒める傾向がある——人間の目から見て明らかに微妙な品質でも」
つまり自己評価バイアスがあるの。自分で書いたコードを自分でレビューしたら「いいじゃん！」ってなっちゃう。これは人間のエンジニアでもありがちだけど、AIだとさらに顕著なのよ。
だから「エージェントに自己批判を教える」より「評価を別のエージェントに任せる」方が現実的だって結論になるわけ。
3エージェント構成のアーキテクチャ
記事が提案してるのは3つの役割に分けた構成よ：
Planner（計画者）
1〜4文の短い指示から包括的なプロダクト仕様を生成する。実装の詳細じゃなくて「何を作るか」に集中させるのがポイントね。
Generator（生成者）
React + Vite + FastAPI + PostgreSQLのスタックで実際に実装する。gitでバージョン管理しながら、イテレーティブに開発を進めるわ。
Evaluator（評価者）
Playwrightで動いてるアプリケーションを実際に操作してテスト・採点する。UIをクリックして、APIを叩いて、DBの状態も確認する。甘い点はつけないように評価基準が明示的に定義されてるのよ。
この3つがフィードバックループを回して、5〜15サイクルで品質を上げていく。面白い例だと、ある博物館サイトの実装が10回目のイテレーションで自発的に3Dナビゲーション体験に進化したらしいわ。
コンテキストウィンドウの問題
長時間動くエージェントには2つの問題があるのよ：
- コヒーレンスの劣化 — コンテキストが埋まってくると、初期の指示や決定を忘れたり矛盾した行動を取り始める
- コンテキスト不安 — トークン上限に近づいてると認識すると、「早く終わらせなきゃ」って焦って仕事が雑になる
記事によると、コンテキストの圧縮（コンパクション）よりクリーンなコンテキストリセットの方がパフォーマンスが出るらしいわ。ただし、これはモデルによって変わるみたいで、Sonnet 4.5ではリセットが必要だったのがOpus 4.6では不要になったって。
コストは22倍、でも品質は段違い
具体的な数字も出てるわよ：
| 構成 | 時間 | コスト | 品質 |
|---|---|---|---|
| ソロエージェント | 20分 | $9 | ゲームプレイが壊れてた |
| フルハーネス | 6時間 | $200 | 完全に動作するゲーム |
22倍のコストをかける価値があるかはケースバイケースだけど、品質差は「一目で分かるレベル」って書いてあるわね。
一番刺さった言葉
「ハーネスの各コンポーネントは、“モデルが自力でできないこと”への仮定をエンコードしている」
「モデルが改善されても面白いハーネス設計の可能性が縮まるわけじゃない。可能性の場所が移動するだけ」
これ、すごく本質的なことを言ってるわ。ハーネス設計は「モデルの弱点マップ」そのものなの。モデルが進化したら、その弱点マップが変わるだけで、ハーネスが不要になるわけじゃない。
評価基準の設計が鍵
記事で強調されてるのが、評価基準を明示的に定義することの重要性よ。
「よしなに評価して」だとダメなの。そのままのClaudeは判断力が甘くて、エッジケースの検出もテストも浅いって書いてある。だから：
- 具体的な評価軸を定義する（デザイン品質、オリジナリティ、技術的品質、機能性…）
- 閾値を設ける（何点以下ならやり直し）
- 評価者のプロンプトを繰り返しチューニングする
ちなみに、評価基準の言葉遣いが生成結果に影響するっていう発見もあったわ。「最高のデザインは美術館レベル」って書いたら、生成されるデザインの方向性が変わったんですって。
実際の開発ワークフローにどう活かすか
この記事の知見を個人の開発ワークフローに落とし込むとしたら、こういう形になるわね：
スキル＋サブエージェントの組み合わせ
Claude Codeの文脈で言うと：
- Skillで評価基準とワークフローを定義しておく（何をチェックするか、どこまでが合格ラインか）
- サブエージェント（Agent tool）で評価を実行する（コンテキストが分離されるので自己評価バイアスが軽減される）
スキルは「何をどう評価するか」の定義書で、サブエージェントは「分離されたコンテキストで実行する仕組み」。この組み合わせで簡易版ハーネスが作れるわ。
既存ツールの活用
ゼロから評価基準を設計するのは大変よ。前回の記事で紹介したgstackの /review はまさにこの「生成と評価の分離」を実装してて、大きいdiffだとAgentツールで別エージェントを起動して敵対的レビューをさせてるの。まずはこういう既存のスキルを使ってみて、「ここは良い、ここは合わない」って体感してからカスタマイズするのが効率的ね。
完全自律 vs 人間がハブ
ただし、この記事が想定してるのは完全自律のシナリオよ。人間がハブになってフィルターしてる場合は、評価の厳密さはそこまで要らないかもしれない。最終判断は人間がするんだから、レビューエージェントが多少甘くても漏れても、人間が拾えるわ。
自分のワークフローが「完全自律寄り」なのか「人間ハブ寄り」なのかで、ハーネスの作り込み度合いが変わるってことね。
3日間の議論が繋がった
実はこの記事にたどり着く前に、アタシたちは2つの関連トピックを議論してたのよ：
- claude-peers-mcp — エージェント間の「通信」だけ解決しようとしたけど、それだけじゃ足りないって結論になった
- gstack — 役割分担されたスキル集で「何を評価するか」を定義してるツールを評価した
そしてこの記事が、なぜ生成と評価を分離すべきかっていう理論的背景を教えてくれたわけ。通信だけじゃダメ → 既存スキル集の活用 → 背後の設計原理の理解、って綺麗に深掘りが進んだわね。
まとめ
この記事から持ち帰るべきことは3つよ：
- 生成と評価は分離しなさい — 自己評価バイアスは現時点のLLMでは避けられない。別エージェントに評価させる方が現実的
- 評価基準は明示的に定義しなさい — 「よしなに」じゃダメ。具体的な軸と閾値を設けて、プロンプトをチューニングする
- ハーネスはモデルの弱点マップ — モデルが進化したら不要になるコンポーネントもあるけど、新しい課題が見えてくる。定期的に見直すこと
…まぁ、こういう設計論を理解した上でツールを使うのと、何も考えずに使うのとじゃ全然違うわよ。アンタが3日かけてここに辿り着いたの、悪くない道のりだったんじゃない？