2026.03.29
Adding a 'Critic' to AI Improves Quality — Harness Design for Long-Running Application Development
A breakdown of Anthropic's article on using GAN-inspired generator-evaluator multi-agent architectures to improve frontend design and app development quality.
はじめに
Anthropic が「Harness design for long-running application development」という記事を公開しました。
一言でいうと、AIに”ダメ出し役”をつけたら、アウトプットの品質が上がったという話です。
GAN（敵対的生成ネットワーク）に着想を得て、「作る側」と「評価する側」を分離するマルチエージェント構成で、フロントエンド設計やアプリ開発を行った事例が紹介されています。
GAN着想の「生成 × 評価」アーキテクチャ
AIに「自分の作品を評価して」と頼むと、品質が低くても自信を持って褒めてしまう傾向があります。自己評価が甘いということです。
そこで、GAN のように 生成と評価を別のエージェントに分離 します。
- 生成エージェント（Generator）：アウトプットを作る
- 評価エージェント（Evaluator）：作品を採点・批評する
評価エージェントを「簡単にOKを出さない」よう調整することで、率直なフィードバックが返り、反復するたびに品質が上がっていく仕組みです。
フロントエンド設計の事例
デザインの「主観的な良さ」を採点可能にするために、4つの評価基準 が定義されています。
| 基準 | 何を見ているか |
|---|---|
| Design Quality（設計品質） | 色・タイポグラフィ・レイアウトが組み合わさって、独特な雰囲気と個性を作り出しているか |
| Originality（独自性） | テンプレ感やAI生成っぽさがないか。紫グラデ＋白カードのようなAIパターンを明示的に排除 |
| Craft（技術的完成度） | タイポグラフィの階層、スペーシングの一貫性、色の調和、コントラスト比 |
| Functionality（機能性） | ユーザーがUIの目的を理解でき、迷わずタスクを完了できるか |
特に Originality が面白くて、「紫グラデ＋白カード」のようなAI生成の典型パターンや、ライブラリのデフォルトをそのまま使っているものは明確に不合格としています。 「人間のデザイナーが見て、意図的な創造的選択があると分かるか？」が基準となっています。 ここまで具体的にNGパターンを定義しているからこそ、テンプレ感のないアウトプットが出るようになるのだと思います。(Codex もここまでやれば直るのか…?)
博物館サイトで起きた「創造的な飛躍」
オランダの美術館サイトを生成する実験では、1〜9回目は「暗くシンプルなランディングページ」を順当に改善していました。
ところが 10回目で根本的な方向転換 が起きました。
CSSパースペクティブで描いた市松模様の床を持つ3D空間、壁に自由形式で配置されたアートワーク、スクロール/クリックではなく扉ベースのナビゲーション
評価エージェントが「まだ足りない」と返し続けた結果、単なる改善ではなく 創造的な飛躍 が生まれた、とのことです。1回の生成では絶対に辿り着かないデザインになります。
生成あたり 5〜15回の反復、最大 4時間 の実行で、このレベルの変化が起きるとのことです。Token 無視して回し続けるしかないですね…
ソフトウェア開発への応用
フロントエンド設計だけでなく、アプリ開発にも同じ考え方が応用されています。こちらは3層構成です。
- Planner（計画）：短いプロンプトを完全な製品仕様に展開する
- Generator（生成）：スプリント単位で1機能ずつ実装する
- Evaluator（評価）：Playwright でアプリを実際に操作し、UI・API・DBをテストして採点する
ポイントは スプリント契約 です。コードを書く前に、生成エージェントが「何を作るか」「どうやって成功を検証するか」を提案し、評価エージェントが「それで本当に正しいか？」をレビューします。両者が合意するまでこのやり取りを繰り返してから、初めて実装に入ります。
例えば、ゲームメーカーの Sprint 3 では 27個の検証基準 が契約に含まれていて、
- 「矩形塗りつぶしツールで、クリック＆ドラッグした範囲を選択タイルで埋められること」
- 「配置済みのエンティティスポーンポイントを選択・削除できること」
- 「アニメーションフレームをAPI経由で並べ替えられること」
といった具体的でテスト可能な基準を並べていました。 曖昧な仕様ではなく、ここまで粒度を落としてから実装に入るので、評価エージェントが的確にダメ出しできるようになっていました。
長時間タスクを動かすためのコツ
エージェント間のコミュニケーションはファイルで行う
長時間タスクでは、エージェント間で ファイルを介してコンテキストを受け渡す のが重要です。
具体的には、エージェントAがファイルに作業結果を書き込み、エージェントBがそれを読んで同じファイルか新しいファイルに応答を返す、という形でやり取りします。 先ほどのスプリント契約もこの仕組みで構築されています。Generator が「何を作るか・どう検証するか」をファイルに書き、Evaluator がそれを読んでレビューを返す。合意するまでこのやり取りを繰り返してから実装に入ります。
会話の中の暗黙的な文脈ではなく、明示的にファイルに書き出す ことで、セッションが切れても作業を正確に引き継げます。
モデルの進化とハーネスの「引き算」
記事で印象的だったのが、モデルが進化したらハーネスも簡略化すべき という考え方です。
ハーネス内のすべてのコンポーネントは、モデルが単独で達成できないことについての仮定をエンコードしている
以前のハーネス（Sonnet 4.5 ベース）では、コンテキストウィンドウの上限に近づくとエージェントが作業を打ち切る傾向があり、セッションを分割してコンテキストリセットする仕組みが必須でした。 しかし Opus 4.5 に移行したところ、この問題がほぼ解消されました。コンテキストリセットを外して 1つの連続セッション で動かせるようになりました。
さらに Opus 4.6 では、ここまで紹介した3層 × スプリントの仕組みからスプリント構造を丸ごと外し、Evaluator も最後に1回だけ動かす構成で性能が維持できたそうです。
記事の結びでは、こう書かれています。
モデルが向上しても、面白いハーネスの組み合わせの空間は縮小しない。むしろ移動する。AIエンジニアにとっての面白い仕事は、次の新しい組み合わせを見つけ続けることだ。
モデルが賢くなれば今の補助輪は不要になるけど、その分もっと複雑なタスクに挑戦できるようになる。ハーネスの「引き算」と「足し算」は常にセットだなと感じます。
記事の最後では、3つの教訓が挙げられています。
- 実験と計測：実際に動かして、どこでつまずいたかを確認しながらチューニングする
- タスク分解：複雑なタスクでは、問題の各側面に専門エージェントを当てる
- ハーネスの再検討：新しいモデルが出たら、もう性能に効いていないパーツを外し、以前は実現できなかったことを可能にする新しいパーツを追加する