この記事は、著者が相互に関連するものとして扱う 2 つの問題に関する取り組みを報告している。Claude に高品質なフロントエンドデザインを作らせることと、人間の介入なしに完全なアプリケーションを構築させることである。それ以前のフロントエンドデザイン用スキルと長時間稼働するコーディングエージェントのハーネスに関する取り組みでは、プロンプトエンジニアリングとハーネス設計によってベースラインを上回る性能向上が得られていたが、著者によればどちらも頭打ちになった。これが、主観的なセンスと検証可能な正しさという大きく異なる 2 つの領域にまたがって通用するアプローチを求めた理由とされている。
採用されたアプローチは敵対的生成ネットワーク（GAN）から借りたものであり、生成器と評価器を組み合わせたマルチエージェント構造である。これがなぜ有効なのかについての記事の中心的な主張は、生成ではなく自己評価に関するものである。自分の作業を評価するよう求められたエージェントは、品質が明らかに凡庸であっても自信を持って称賛する傾向がある。著者は、生成器に自分の出力を批判的に見させるよりも、独立した評価器を懐疑的になるよう調整するほうがはるかに扱いやすいと論じる。分離それ自体が甘さを取り除くわけではない。評価器もまた LLM の出力に寛大になりがちな LLM だからである。しかし分離によって、生成器は反復の拠り所となる具体的な対象を得る。
長時間稼働するコーディングに適用すると、これは数時間に及ぶ自律セッションでフルスタックアプリケーションを生み出す、プランナー–生成器–評価器の 3 エージェント構成となった。記事の後半は、モデルの向上に合わせてその構成を再び分解していった経緯の報告であり、締めくくりの立場は、興味深いハーネスの組み合わせの空間はモデルが良くなっても縮小せず、移動するというものである。
要点
- 長いタスクにおけるエージェントの 2 つの失敗モードが特定されている。コンテキストウィンドウが埋まるにつれて一貫性が失われることと、コンテキスト不安、すなわちモデルが自らのコンテキストの上限と考えるものに近づくにつれて作業を早々に切り上げてしまうことである。コンテキストリセット は両方に対処するものとして提示されている。
- リセットは コンパクション と区別される。コンパクションは履歴をその場で要約するため、連続性は保たれるがエージェントに白紙の状態を与えない。そのためコンテキスト不安はコンパクションを経ても残りうる。リセットのコストは、引き継ぎ用の成果物が十分な状態を運ばなければならないことに加え、オーケストレーションの複雑さ、トークンのオーバーヘッド、レイテンシが増えることである。
- フロントエンドデザインについて、著者は生成器と評価器の両方に与える 4 つの採点基準を書いた。デザイン品質（デザインが一貫した全体として読めるか）、独創性（テンプレートのレイアウトやライブラリのデフォルトではなく、独自の判断が見られるか）、クラフト（タイポグラフィの階層、余白、配色の調和、コントラスト比）、機能性（美観とは独立した使いやすさ）である。
- デザイン品質と独創性はクラフトと機能性より重く重み付けされた。その理由として、Claude は後者 2 つではデフォルトですでに高いスコアを出す一方、前者 2 つでは平凡な出力しか生まないことが挙げられている。基準はありきたりなパターンを明示的に減点しており、白いカードの上の紫のグラデーションを AI 生成であることの典型的な兆候として名指ししている。
- 評価器は詳細なスコアの内訳を含む few-shot の例で較正された。著者によれば、これにより評価器の判断が著者の好みに沿うようになり、反復間のスコアのドリフトが減った。
- フロントエンドのループは Claude Agent SDK 上に構築され、評価器には Playwright MCP が与えられた。これにより評価器は静的な画像を採点するのではなく、採点前に実際のページを操作してスクリーンショットを撮ることができた。5〜15 回の反復からなる実行は、実時間で最大 4 時間に及んだ。
- 基準の言い回しは、著者が十分に予想していなかった形で出力を方向づけた。たとえば「最高のデザインは美術館品質である」という表現は、デザインを特定の視覚的な収束へと押しやった。
- 反復を通じたスコアの向上は実際にあったものの、きれいな線形ではなかったと報告されている。著者は最後の反復よりも中間の反復を好むことがたびたびあった。また、最初の反復でさえプロンプトなしのベースラインを上回っていたことに触れ、評価器のフィードバックが届く前から基準がモデルを方向づけていたことを示唆している。
- 報告された実行の 1 つは不連続な変化を示している。オランダの美術館のサイトを求められたモデルは、9 回目の反復までに洗練されたダークテーマのランディングページを作り上げたが、10 回目でそれを完全に破棄し、CSS パースペクティブによる市松模様の床を持つ 3D の部屋に置き換えた。作品は自由な位置に掛けられ、ナビゲーションはスクロールやクリックではなく戸口を通って移動する方式だった。
- フルスタックのハーネスでは、プランナーが 1〜4 文のプロンプトを完全なプロダクト仕様に展開した。プランナーはスコープについて野心的であるよう、かつプロダクトの文脈と高レベルの技術設計のレベルにとどまるよう指示された。その理由として、細かな技術的詳細を前もって指定すると誤りが実装へと連鎖するためだとされている。
- 生成器はスプリント単位で、一度に 1 つの機能ずつ作業した。スタックは React、Vite、FastAPI、SQLite（後に PostgreSQL）で、バージョン管理には git を使った。各スプリントの前に、生成器と評価器はスプリント契約を交渉し、何をもって「完了」とするか、それをどう検証するかについて合意した。両者はファイルを書き、読むことで通信した。
- レトロゲームメーカーのプロンプトでは、単独実行が 20 分・9 ドルだったのに対し、完全なハーネスは 6 時間・200 ドルを要した。コストは 20 倍を超える。単独実行のアプリケーションではエンティティ定義とゲームランタイムの結線が壊れており、ゲームが入力に反応しなかった。ハーネスによる実行の仕様は 10 スプリントにわたる 16 の機能に及び、プレイ可能な結果を生み出した。
- 著者によれば、Claude はそのままでは QA エージェントとして不出来である。正当な問題を特定しておきながら、結局は自分を納得させて作業を承認してしまう様子や、エッジケースを探るのではなく表面的にテストする様子が観察された。説明されている対策は、評価器のログを読み、その判断が著者の判断と食い違った箇所を見つけ、何度かにわたって QA プロンプトを更新することである。
- ハーネス設計についての一般原則が導かれている。すべてのコンポーネントは、モデルが単独ではできないことについての仮定を符号化している。そうした仮定は誤っている可能性があり、またモデルの向上とともに古くなるため、ストレステストする価値がある。記事はその根底にある考え方として、Anthropic 自身の Building Effective Agents の記事から「可能な限り単純な解決策を見つけ、必要なときにだけ複雑さを増やす」を引用している。
- このハーネスには当初からコンテキストリセットは含まれていなかった。Opus 4.5 がそれ自体でコンテキスト不安をほぼ解消していたため、エージェントは 1 つの連続したセッションとして実行され、コンテキストの増大は Agent SDK の自動コンパクションが処理した。
- 後の簡素化の作業は、コンポーネントを 1 つずつ取り除き、それぞれの影響を検証する形で進められた。最初にハーネスを大幅に削減しようとした試みは、元の性能を再現できず、どの部分が本質的に効いていたのかを見分けにくくしてしまったためである。スプリントの構成は Opus 4.6 の登場後に取り除かれ、評価器はスプリントごとの採点ではなく、実行の最後に 1 回だけ評価する形に移行した。
- 評価器の価値は固定的なものではなく、条件付きのものだと報告されている。素のモデル能力が上がるにつれて、以前は評価器のチェックを必要としていたタスクが、生成器単独で扱える範囲に入ってきた。そのため記事が示すルールは、タスクが現在のモデルが単独で確実にこなせる範囲を超えている場合に、評価器はそのコストに見合うというものである。
- 更新後のハーネスは、ブラウザ上の DAW を約 3 時間 50 分・124.70 ドルで構築し、ビルダーはスプリント分割なしで 2 時間以上にわたって一貫して動作した。報告された内訳は、プランナーが 4.7 分・0.46 ドル、3 回のビルドラウンドが 2 時間 07 分、1 時間 02 分、10.9 分、3 回の QA ラウンドが 8.8 分、6.8 分、9.6 分である。
- その実行でも QA は実際の欠落を見つけており、記事に引用されている。1 回目のフィードバックは、DAW の中核機能が表示のみでインタラクティブな深みがないというもの、2 回目のフィードバックは、音声録音がスタブのままであり、クリップのリサイズと分割が実装されていないというものだった。
背景
これは Anthropic の Labs チームの 1 人のメンバーによる直接のエンジニアリング報告であり、管理された研究ではなく自身の実験を記述したものである。1 つのプロンプトにおける単独実行とハーネスの 1 回の比較以外にベースラインはなく、反復試行もない。また、フロントエンドの作業を方向づけた品質判断は明示的に著者自身のセンスである。この点は、評価器が著者の好みに沿うよう較正されたと記事自身が述べていることからもわかる。
記事は自らの結果の限界について率直である。ハーネスで構築されたゲームメーカーにはワークフロー上の問題が残っており、著者はそれをハーネスが対処したものではなく、ベースモデルのプロダクト的直感の欠落と読んでいる。生成されたゲームの物理挙動には粗があり、著者のキャラクターがプラットフォームに飛び乗るとそれに重なってしまった。また、AI が生成したレベルでは壁の裏で身動きが取れなくなった。DAW について著者は、そのアプリケーションがプロの音楽制作ソフトウェアには遠く及ばないこと、そして Claude は音を聴くことができないため、音楽的なセンスに関しては QA のフィードバックループの効果が薄かったことに触れている。調整済みの評価器でさえ、小さなレイアウトの問題、直感的でないインタラクション、深くネストした機能のバグを見逃すと述べられている。
著者の以前のハーネスに関する取り組みとの関係は、拡張ではなく改訂である。以前の取り組みで必要だと確認された複数のコンポーネントがここでは取り除かれており、その理由として、その下にあるモデルが変わったことが挙げられている。