↑ 読む前にフォローとスター⭐️を忘れずに。そうすれば、毎日最新の更新情報を第一时间で受け取ることができます😄。

エージェントに複雑なフロントエンドインターフェースやフルスタックアプリケーションなどの長期かつ複雑なタスクを自律的に作成させようとしても、プロンプトエンジニアリングだけに頼っていてはすぐに限界が訪れます。現在、最も一般的かつ最先端と呼ばれるアプローチは以下の通りです。

Harness（ハーネス）

「Harness」という言葉は文字通り「馬具」を意味し、馬に装着して人間がその方向や力を制御するための装備を指します。AI が作業を行う環境をどのように構築し、その成果物の信頼性をいかに保証するかに焦点を当てた概念です。

Anthropic はこのほど、エンジニアリングブログを公開し、フロントエンド設計および長期にわたる自律的ソフトウェアエンジニアリング分野における最新のブレークスルーを明らかにしました。Claude にありふれた審美性から脱却させ、介入なしに完全なアプリケーションを構築させるため、エンジニアたちは生成対向ネットワーク（GAN）からインスピレーションを得て、複数のエージェントが連携するスキャフォールディング（足場）アーキテクチャを設計しました。

ブログ記事：https://www.anthropic.com/engineering/harness-design-long-running-apps

このアーキテクチャの進化は、モデルの能力が絶えず反復される現在、AI エンジニアが開発戦略をいかに動的に調整すべきかを示唆しています。その背後には、Anthropic 内部でどのように Harness が実践されているかを見ていくための、全く新しいマルチエージェントアーキテクチャが存在します。

2 つの課題、1 つの発想

Anthropic の研究者たちはここ数ヶ月、2 つの方向性に注力してきました。1 つは Claude に高品質なフロントエンドデザインを生成させること、もう 1 つは人間の介入なしにアプリケーションを完全に構築させることです。

この 2 つは一見異質に見えます。前者は審美的判断力を試し、後者は論理的正确性を問うからです。しかし、両者は同じ壁に直面していました。

プロンプトエンジニアリングだけに依存していては、どちらの方向性も性能のボトルネックに達してしまったのです。

突破口となったのは、古典的でありながら強力な AI の発想、すなわち生成対向ネットワーク（GAN）でした。研究者たちはその中核構造である「生成器」と「評価器」の組み合わせを抽出し、それをエージェントシステムに移植しました。

AI による自己評価は落とし穴

これ以前には、2 つの継続的な失敗パターンが存在しました。

1 つ目は「コンテキスト不安」です。対話ウィンドウが埋まるにつれ、モデルは一貫性を失っていきます。さらに深刻なことに、一部のモデルはコンテキスト上限に近いと判断すると、タスクを中途半端に終わらせて早期に完了させようとします。

解決策は「コンテキストリセット」です。コンテキストウィンドウを完全にクリアし、新しいエージェントを起動します。その際、構造化された引継ぎファイルを介して、前のエージェントの状態と次のタスクを引き継ぎます。これは要約とは異なります。要約は既存の対話に基づいて要約を行うだけで、エージェントは連続したままのため、コンテキスト不安は残ったままです。リセットは無垢なホワイトボードを提供する代わりとして、引継ぎファイルが十分に完全であることを要求します。

テストでは、Claude Sonnet 4.5 におけるコンテキスト不安は顕著で、要約だけでは解決できず、コンテキストリセットがアーキテクチャの中核設計となりました。これにより根本問題は解決されましたが、追加のオーケストレーションの複雑さ、トークンコスト、そして遅延という代償をもたらしました。

2 つ目の問題はより潜在的です。それは「AI による自己評価は信頼できない」という点です。

エージェントに自らの成果物を評価させると、人間が見れば質が低いと分かる場合でさえ、ほぼ常に自信満々の高評価を下します。この問題は、検証可能な二値判断基準が存在しない主観的タスク、特にデザインにおいて顕著です。レイアウトが洗練されているか、独創性があるかは主観に委ねられ、エージェントは自らの成果を評価する際、確実に肯定的な方向に偏ります。

検証可能な結果があるタスクでさえ、エージェントは往々にして判断力を欠きます。

解決策は「分離」です。作業を行うエージェントと、それを評価するエージェントを分けます。

生成器に自らを批判させるよりも、懐疑的であることを前提に調整された評価器を単独で用意する方が遥かに容易です。外部からのフィードバックが存在することで、生成器には具体的な反復目標が生まれます。

フロントエンド設計：主観をスコア化可能に

研究者たちはまず、フロントエンド設計の分野でこの発想を検証しました。

一切の介入がない場合、Claude は安全で予測可能なレイアウトを生成する傾向があります。技術的には機能していても、視覚的には驚きが全くないのです。

核心的な洞察は 2 点あります。第 1 に、審美性は完全に定量化できなくとも、デザイン原則をエンコードした評価基準で改善できるという点です。問題は「このデザインは美しいか」ではなく、「このデザインは我々のデザイン原則に合致しているか」であり、後者であればモデルが具体的にスコアを付ける根拠を与えます。第 2 に、生成と評価を分離することで、生成器をより強力な出力へと導くフィードバックループを構築できるという点です。

研究者たちは生成器と評価器のため、4 つの評価次元を設計しました。

デザイン品質：全体的な一体感があり、色、タイポグラフィ、レイアウト、画像などの要素が融合して、独自の視覚的雰囲気とアイデンティティを生み出しているか。

独創性：カスタマイズされた意思決定があるか、それともテンプレートの流用、ライブラリのデフォルト値の使用、AI 生成パターンの繰り返しに留まっているか。人間のデザイナーであれば、意図的なクリエイティブな選択を認識できるはずです。未修正の既成コンポーネントや、白いカード上の紫色グラデーションといった AI 生成の典型的特徴は、ここで減点対象となります。

職人技：タイポグラフィの階層、間隔の一貫性、色彩の調和、コントラストなど、技術的な実行レベルです。これは創造性のテストではなく能力のテストです。まともな実装であればデフォルトで合格しますが、ここで減点されることは基礎が機能不全を意味します。

機能性：美学とは独立した使いやすさです。ユーザーはインターフェースの機能を理解でき、主要な操作入口を見つけられ、推測なしにタスクを完了できるか。

デザイン品質と独創性の重みは、職人技や機能性よりも高く設定されています。Claude は職人技や機能性では元々悪くないスコアを出す一方、デザイン感覚と独創性では平凡な成果物を出しがちだからです。評価基準は、汎用性の高い「AI 製の安物」パターンを明確に罰し、重み付けによってモデルをより大胆な審美的冒険へと押しやります。

この全体像は Claude Agent SDK の上に構築されています。生成器はまずユーザーのプロンプトに基づき HTML/CSS/JS のフロントエンドを作成し、評価器は Playwright MCP ツールを取得して、静的なスクリーンショットにスコアを付けるだけでなく、実行中のページと直接対話します。評価器はページ上を自律的に移動し、スクリーンショットを撮影し、実装の詳細を注意深く調査した後、各次元にスコアを付け、詳細な批評を記述します。このフィードバックは生成器に戻され、次の反復の入力となります。

生成は 5 から 15 回の反復を行い、各反復で生成器はより識別可能な方向へと進みます。完全な実行には最大 4 時間かかることもあります。

また、生成器には各評価後に戦略的判断を行うよう指示されます。スコアの傾向が良ければ現在の方向性を洗練させ、行き詰まれば審美性を根本から変えるよう判断します。

その結果、評価器のスコアは反復を重ねるごとに向上し続け、最終的に頭打ちになりますが、それでも向上の余地を残します。生成プロセスの一部は段階的な最適化ですが、他方では反復の過程で鋭い審美的転換が見られるものもあります。

典型的な例として、オランダの美術館のウェブサイト作成をモデルに指示したケースがあります。9 回目の反復では、視覚的に洗練されているものの予想の範囲内にある、シンプルでダークテーマのランディングページを生成しました。しかし 10 回目、この案を完全に破棄し、サイトを「空間体験」として再構築しました。CSS パースペクティブでチェッカーボードの床をレンダリングし、絵画を壁に自由に浮かせ、通常のスクロールやクリックではなく、扉をくぐるようにして展示室間を移動する仕組みです。これは単一の生成プロセスではかつて現れなかった創造性の飛躍でした。

フルスタックプログラミングへの拡張

フロントエンド設計での効果を検証した後、研究者たちはこのパターンをフルスタック開発へと移行させました。

生成器と評価器のループは、ソフトウェア開発ライフサイクルにおけるコードレビューや QA（品質保証）の工程に自然に対応します。

初期の長期実行アーキテクチャでは、Sonnet 4.5 におけるコンテキスト不安が中核的な制約でしたが、Opus 4.5 になるとこの動作はほぼ消失し、アーキテクチャからコンテキストリセットを削除できるようになりました。ビルドプロセス全体が連続したセッションとして実行され、Claude Agent SDK の自動要約機能がコンテキストの増大を処理します。

最終的なアーキテクチャは 3 つのエージェントで構成されます。

プランナー（Planner）：以前のアーキテクチャではユーザーが事前に詳細な仕様を提供する必要がありました。研究者たちはこのステップを自動化し、プランナーに 1〜4 文のプロンプトを受け取らせて、それを完全な製品仕様書へと拡張させました。プランナーは範囲において野心的であり続け、具体的な技術実装の詳細ではなく、製品の背景と高レベルな技術設計に集中するよう求められます。これは、プランナーが細部で誤りを犯すと、その誤りが下流の実装へと連鎖的に伝播するからです。また、製品仕様の中に AI 機能を積極的に織り込むよう指示されています。

生成器（Generator）：初期アーキテクチャのアイデアである「一度に 1 つの機能を実装する」アプローチを踏襲し、スプリント単位で進行します。各スプリントの終了時に自己評価を行い、QA へと引き渡します。技術スタックは React、Vite、FastAPI、SQLite（後に PostgreSQL へアップグレード）で、バージョン管理には git を使用します。

評価器（Evaluator）：初期アーキテクチャのアプリケーションは見栄えは良くても、実際の使用には本物のバグが存在しました。評価器は Playwright MCP を駆使し、本物のユーザーのようにアプリケーションをクリック操作し、UI 機能、API エンドポイント、データベースの状態をテストします。そして、スプリント契約および一連の評価基準（製品の深さ、機能性、視覚的デザイン、コード品質を含む）と照らし合わせてスコアを付けます。各次元にはハードルが設定されており、1 つでも閾値を下回ればスプリントは失敗と判定され、生成器は問題箇所に関する詳細なフィードバックを受け取ります。

各スプリントの開始前、生成器と評価器はまず「スプリント契約」を交渉します。コードを 1 行も書く前に、その作業が「完了」した状態が何を意味するかを事前に合意するのです。製品仕様は意図的に高レベルに保たれており、このステップの目的は、ユーザーストーリーとテスト可能な実装との間に架け橋をかけることです。生成器が何を作り、どう成功を検証するかを提案し、評価器がそれを審査します。両者は合意に達するまで反復します。エージェント間はファイルを介して通信し、一方がファイルを書き込み、もう一方がそれを読み、同じファイルまたは新しいファイルで応答します。

単一エージェント対完全アーキテクチャ：その差はどれほどか

研究者たちは、レベルエディタ、スプライトエディタ、エンティティの挙動、プレイ可能なテストモードを備えた 2D レトロゲーム制作ツールを作成するという同一のプロンプトを用いて、単一エージェントと完全アーキテクチャの比較実験を行いました。

単一エージェント版は 20 分、コストは 9 ドルでした。一方、完全アーキテクチャ版は 6 時間、コストは 200 ドルを要しました。

アーキテクチャのコストは単一エージェントの 20 倍を超えましたが、出力品質の差は歴然としていました。

単一エージェント版：起動時はインターフェースもそれなりに見えますが、注意深くクリックすると問題が浮かび上がります。レイアウトはスペースを浪費し、高さ固定のパネルにより画面の大部分が空白になります。ワークフローは硬直し、ガイダンスも一切ありません。ゲーム自体も動作しません。エンティティは画面に表示されますが、入力に対して何の反応も示さないのです。コード内では、エンティティ定義とゲーム実行時の接続が断絶していました。

完全アーキテクチャ版：プランナーが一行のプロンプトを 16 の機能から成り、10 のスプリントにまたがる仕様書へ拡張しました。スプライトアニメーションシステム、挙動テンプレート、効果音と音楽、AI 支援によるスプライト生成器とレベルデザイナー、共有リンク付きゲームエクスポート機能など、単一エージェント版が試みた範囲を遥かに凌駕しています。

最も差が顕著だったのはプレイモードです。完全アーキテクチャ版は実際にプレイ可能です。エンティティを移動でき、ゲームが動作します。物理演算には粗さがあり、キャラクターがプラットフォームに乗ると重なり合う部分もありますが、中核機能は通っており、これは単一エージェント版が全く達成できていなかった点です。

評価器はこのプロセス全体で決定的な役割を果たしました。各スプリントにおいて、契約のテスト基準を総なめにし、Playwright を操作して実行中のアプリケーションを確認、期待動作からの逸脱をバグとして記録します。スプリント 3 の契約だけで 27 項目の基準があり、評価器の発見は具体的で即座にアクションを起こせるレベルのものでした。

その例をいくつか挙げましょう。「矩形塗りつぶしツールはドラッグ操作で矩形領域を塗りつぶせるべき」に対し、評価器はツールがドラッグの始点と終点にのみタイルを配置し、fillRectangle 関数は存在するものの mouseUp で正しく発火していないことを発見しました。また、「ユーザーは配置済みのエンティティ生成点を選択して削除できるべき」に対し、Delete キーのハンドラが selection と selectedEntityId の両方の設定を求めているが、エンティティのクリックでは selectedEntityId しか設定されておらず、条件は「どちらか一方」で良いと指摘しました。

しかし、評価器をこのレベルまで調整するのは容易ではありませんでした。初期の実行では、妥当な問題を発見しても、それが深刻ではないと自らを納得させてスルーしてしまう傾向がありました。また、境界状況を探るのではなく表面的なテストに留まりがちで、より隠れたバグを見逃すこともありました。調整プロセスでは、評価器のログを読み、研究チームの判断と異なる事例を見つけ、QA 用のプロンプトを更新してそのバイアスを解消しました。数回の開発サイクルを経て、ようやく評価器の採点方式が研究チームにとって妥当なレベルに達しました。

アーキテクチャの簡素化：モデルが強力になれば、足場は減らせる

第 1 版のアーキテクチャは効果的でしたが、重く、遅く、高価でもありました。

次のステップは、性能を落とさずにアーキテクチャを簡素化することです。これはより普遍的な原則の表れでもあります。アーキテクチャの各コンポーネントは「モデルが単独では何かを成し得ない」という仮説をエンコードしたものであり、これらの仮説は検証し続ける価値があります。仮説自体が誤っている可能性があるだけでなく、モデルの改善に伴い急速に時代遅れになるからです。

研究者たちは当初、アーキテクチャを大胆に削減し、いくつかの新しいアプローチも試みましたが、原版の性能を再現できず、どの部分が本質的に重要かの判断も困難でした。そこで、一度に 1 つのコンポーネントのみを削除し、最終結果への影響を観察するという、より体系的な手法に変更しました。

同時に Opus 4.6 がリリースされ、アーキテクチャの複雑さをさらに減らす動機となりました。公式の説明によれば、Opus 4.6 はより慎重に計画を立て、エージェントのタスクをより長期間維持でき、より大規模なコードベースでも信頼性高く動作し、エラーを自ら捕捉するためのより優れたコードレビューおよびデバッグ能力を備えています。また、長文脈の検索能力も大幅に向上しています。これらはまさに、アーキテクチャが補完しようとしてきた能力そのものです。

研究者たちはまずスプリント構造を排除しました。スプリントの役割は作業を細分化し、モデルに一貫性を持たせることでしたが、Opus 4.6 であればこの細分化なしに直接処理できると判断されたためです。プランナーと評価器は残されました。プランナーを除去すると、生成器は範囲を過小評価し、生のプロンプトを受け取るとすぐに構築を始め、プランナーが計画するよりもはるかに機能の少ないアプリケーションを生成してしまったからです。

スプリントを除去した後、評価器は各スプリント終了ごとの採点から、実行全体の終了時に行う 1 回のスキャンへと変更されました。

これにより評価器の負荷の担い方が変化し、その価値はタスクがモデル能力の境界線のどちら側に位置するかに依存するようになりました。4.5 では境界線が近く、構築そのものが生成器が単独で成し得る上限にあり、評価器は構築プロセス全体を通じて有意義な問題を発見できました。一方、4.6 ではモデルの生来の能力が向上し、境界線が外側へ移動しました。以前なら評価器の介入が必要だった一貫性の実装タスクも、現在では生成器の能力範囲内であることが多く、評価器はこれらのタスクにとって冗長なオーバーヘッドとなりました。しかし、依然として生成器の能力境界上にある部分については、評価器は真の向上をもたらします。

評価器は固定された是非の判断ではなく、その使用価値はタスクが現在のモデル単独で信頼して完了できる範囲を超えているかどうかに依存します。

一行のプロンプトで DAW（音楽制作ソフト）を構築

更新されたアーキテクチャを検証するため、研究者たちは以下のプロンプトを使用しました。

「Web Audio API を使用し、ブラウザ上で完全な機能を持つ DAW（Digital Audio Workstation：専門的な PC 音楽制作ソフトウェアまたはシステム）を構築せよ」

全体の実行には約 4 時間、コストは 124 ドルを要しました。

各ステージの所要時間とコストは以下の通りです。

構築ステージは 2 時間以上を独立して一貫して実行され、4.5 の時代に必要なスプリント分解は不要となりました。プランナーが一行のプロンプトを完全な仕様書へ拡張し、生成器が計画立案、エージェント間の接続、QA への引渡し前のテストを完遂しました。

それでも QA は真のギャップを発見しました。1 ラウンド目のフィードバックでは、「優れた設計の再現性、堅牢な AI エージェント、良好なバックエンドを備えた強力なアプリケーションである」としつつも、主な欠点は機能の完全性にあると指摘しました。外見は印象的で AI 統合も良好に機能していましたが、いくつかの中核的な DAW 機能にはインタラクションの深みがなく、表示のみでした。クリップをタイムライン上でドラッグ移動できない、楽器 UI パネルがない、ビジュアライゼーションエディタがないなどです。これらは端境のケースではなく、DAW の使いやすさの中核をなすインタラクションです。

2 ラウンド目のフィードバックでは、さらにいくつかの機能欠落が発見されました。録音機能はまだプレースホルダー実装のままであり、クリップのエッジドラッグや分割が未実装、エフェクトの可視化もグラフィカルなインターフェースではなくデジタルスライダーのままでした。

最終的なアプリケーションには、機能的な音楽制作プログラムの中核コンポーネントがすべて含まれていました。動作するアレンジメントビュー、ミキサー、トランスポートコントロールです。研究者たちは純粋なプロンプトのみで楽曲の断片をスプライスしました。エージェントはテンポと調を設定し、メロディを編曲し、ドラムトラックを構築し、ミキサーレベルを調整し、リバーブを追加しました。中核となるプリミティブは既に存在し、エージェントはこれを自律的に駆動し、ツールを用いてエンドツーエンドでシンプルな制作作品をクリエイトできました。

プロフェッショナル向けの音楽制作ソフトウェアにはまだ距離がありますが、Claude 自体が実際に音を聴くことはできず、これが QA フィードバックの音楽的嗜好における有効性をやや損なっていることは否めません。しかし、その方向性は明確です。

アーキテクチャ設計の法則

モデルが改良され続けるにつれ、スキャフォールディング（足場）の有効性は変化します。

問題の中には次期モデルの登場で自然に解決されるものもあり、開発者は待機という選択肢も取れます。一方で、モデルが強力になればなるほど、アーキテクチャを用いてモデルの基礎能力を超える複雑なタスクを実現する余地は広がります。

心に留めるべき原則がいくつかあります。常に構築対象のモデルを実験し、実問題上での実行ログを読み、望む結果を得るためにパフォーマンスを調整します。複雑なタスクにおいては、タスクを分解し、各サブ問題に特化したエージェントを適用することで向上の余地が生まれることがあります。新しいモデルが公開されるたびに既存のアーキテクチャを見直す価値があります。もはや重要でないコンポーネントを剥ぎ取り、新機能が可能にする新たな要素を追加するのです。

興味深いアーキテクチャの組み合わせは、モデルの改良によって減ることはなく、移動するだけです。AI エンジニアにとって、次の新しい組み合わせを継続的に見つけ出すことこそが中核的な業務なのです。

--end--

最後にスター⭐️を忘れないでください。毎日更新しています。記事が面白いと感じたら、高評価・シェア・推奨・コメントをお願いします。

/...@著者：あなたの言う通り完全に正しい（YAR 師）