「AIにアプリを作らせましょう」——最近あちこちで聞くフレーズですが、現実はどうでしょうか。確かに、ちょっとしたツールならAI aloneでも作れるようになりました。しかし、本格的なアプリとなると話は別です。UIは整っているのに中身がスカスカ、ボタンを押しても何も起きない……そんな「見せかけの完成品」に悩まされた経験はないでしょうか。
AnthropicのLabsチームが2026年3月に公開した技術ブログ「Harness design for long-running application development」は、この問題に真正面から取り組んだ興味深いレポートです。著者のPrithvi Rajasekaran氏は、AIに品質の高いフロントエンドデザインをさせ、かつ完全なアプリを人間の介入なしで構築させるという2つの課題に取り組みました。
その解決策が、なんとGAN（敵対的生成ネットワーク）の発想から生まれたのです。
AIエージェントに「このアプリを作って」と頼んで放置する、いわゆる「ナイーブな実装」は、なぜうまくいかないのでしょうか。Anthropicは2つの根本的な問題を特定しました。
長時間のタスクでは、AIのコンテキストウィンドウ（記憶領域）が徐々に埋まっていきます。するとAIは「もうすぐ上限に達するから早く終わらせなきゃ」と焦り始め、作業を途中で打ち切ってしまう現象が起きます。これが「コンテキスト不安」です。
対策として、Anthropicはコンテキストリセットという手法を採用しました。会話を完全にクリアし、前のセッションの状態をハンドオフファイルとして引き継ぐことで、AIに「きれいな白紙」を与えるのです。これはコンテキストをその場で要約し続ける「コンパクション」とは異なり、AIに本当の意味でリフレッシュさせることができます。
もう一つの問題はAIの自己評価が当てにならないことです。AIに「自分の成果を評価して」と頼むと、たとえ品質が明らかに mediocre（並以下）でも「素晴らしい出来です！」と自信満々に答える傾向があります。
これは特にデザインのような主観的なタスクで顕著です。「このレイアウトは洗練されているか？」という問いに対して、AIは自分の作品を甘く採点してしまいます。テスト可能な客観的タスクであっても、作業中の判断ミスが発生することがあります。
ここでGANの登場です。GAN（Generative Adversarial Network）は、画像を生成するGenerator（生成器）と画像を評価するDiscriminator（識別器）が競い合うことで品質を高めていく機械学習の仕組みです。Anthropicはこの発想をAIエージェント設計に応用しました。
つまり、「作るAI」と「評価するAI」を分離するのです。
単に分離するだけでは不十分で、評価側のAIも同じLLMなので最初は甘くなります。しかし、独立した評価AIを厳しく調整（チューニング）することは、生成AI自身に自己批判させるよりずっと簡単だというのが重要な洞察です。一度外部からの厳しいフィードバックが存在すれば、生成AIはそれに対して具体的に改善を重ねられます。
フロントエンドデザインの実験では、4つの評価基準を定義しました。
| 評価基準 | 内容 |
|---|---|
| デザイン品質 | 色、タイポグラフィ、レイアウトが一体となって独自の雰囲気を作れているか |
| 独創性 | テンプレートやAI生成の典型パターン（紫のグラデーション＋白カード等）に堕していないか |
| 技術的品質 | 文字階層、余白の一貫性、カラーハーモニーなどの基本ができているか |
| 機能性 | ユーザーがインターフェースの目的を理解し、操作できるか |
特にデザイン品質と独創性を重視し、「AIスロップ」と呼ばれる典型的なAI生成パターンを明確にペナルティ対象にしました。
GANの発想をフルスタック開発に拡張した結果、3つのエージェントが協働するアーキテクチャが完成しました。
ユーザーが入力した1〜4文の短いプロンプトを、完全な製品仕様書に拡張します。ここで重要なのは、詳細な技術実装までは指定しないこと。技術的な詳細で間違えた場合、そのエラーが下流の実装全体に波及するからです。プロダクトの文脈と高レベルの技術設計に留め、実装の道筋は現場に任せるという判断です。
スプリント単位で1機能ずつ実装します。React + Vite + FastAPI + SQLite（のちにPostgreSQL）というモダンなスタックを採用。各スプリントの終わりに自己評価を行い、次のQAに引き継ぎます。Gitによるバージョン管理も備えています。
ここがGANの「Discriminator」に相当する存在です。Playwright MCPを使って実際のアプリを操作し、UI機能、APIエンドポイント、データベースの状態をテストします。単なるコードレビューではなく、ユーザーと同じようにクリックして回るため、見た目だけ良くて中身がない「ハリボテ」を見破ることができます。
エージェント間のコミュニケーションはファイル経由で行われます。一方のエージェントがファイルを書き、もう一方が読んで応答するというシンプルな仕組みです。
このアーキテクチャをテストするため、Anthropicは次のようなプロンプトを投げました。
「Web Audio APIを使って、ブラウザ上で動く本格的なDAW（デジタル・オーディオ・ワークステーション）を作って」
DAWとは、音楽制作ソフトのこと。作曲、録音、ミキシングまでを一台でこなす本格的なアプリです。これをブラウザ上で一から作らせるという、かなり野心的な課題です。
結果は以下の通りでした。
| フェーズ | 所要時間 | コスト |
|---|---|---|
| Planner（仕様策定） | 4.7分 | $0.46 |
| Build（ラウンド1） | 2時間7分 | $71.08 |
| QA（ラウンド1） | 8.8分 | $3.24 |
| Build（ラウンド2） | 1時間2分 | $36.89 |
| QA（ラウンド2） | 6.8分 | $3.09 |
| Build（ラウンド3） | 10.9分 | $5.88 |
| QA（ラウンド3） | 9.6分 | $4.06 |
| 合計 | 約3時間50分 | $124.70 |
QAエージェントが各ラウンドで具体的な指摘をしています。1回目のレビューでは「見た目は素晴らしいが、クリップをドラッグできない、シンセのノブUIがない、EQカーブのグラフィカルエディタがない」と指摘。2回目でも「オーディオ録音がスタブのまま」「クリップの分割が未実装」と具体的な機能ギャップを捉まえました。
完成品はプロ用DAWには程遠いものの、アレンジビュー、ミキサー、トランスポートというDAWのコア機能がブラウザ上で動作し、AIエージェントがテンポ設定→メロディ生成→ドラムトラック構築→ミキサー調整→リバーブ追加まで、プロンプトだけで一連の楽曲制作プロセスを自律的に実行できたとのことです。
コストは約$125（約2万円）と決して安くありませんが、人間の開発者が数週間かかるような本格的なアプリを数時間で自動生成できた意義は大きいです。
この実験で最も感動的なエピソードが、オランダ美術館のウェブサイトを作らせた時の出来事です。
9回目の反復までは、ダークテーマの洗練されたランディングページができあがっていました。見た目は綺麗ですが、予想の範囲内です。
しかし10回目のサイクルで、突然すべてが変わりました。
AIはそれまでのアプローチを完全に捨て、サイトを空間体験として再構築したのです。CSSのperspectiveを使った3Dルーム、チェッカーボードの床、壁に自由な配置で掛けられた絵画、そして部屋から部屋へドアを使って移動するナビゲーション。スクロールでもクリックでもない、まったく新しいギャラリー体験でした。
これはGAN的な反復ループがもたらした創造的飛躍です。単発の生成では決して出てこなかったアイデアが、GeneratorとEvaluatorの繰り返しの緊張関係の中から突然生まれたのです。評価AIからの「もっと独創的に」という圧力が、生成AIを安全なデフォルトから引きずり出した結果と言えます。
この研究は、AIを日常的に使う僕たちにも重要なメッセージを含んでいます。
AIは自分の仕事を褒めすぎます。「これでいいですか？」と聞くと「素晴らしいです！」と返ってくる。本当に品質を高めるなら、別の視点（別のAI、あるいは人間）からのレビューが必要です。
長時間のタスクでは、会話を要約し続けるだけ（コンパクション）では限界があります。思い切ってセッションをリセットして引き継ぎドキュメントで繋ぐ方が、AIのパフォーマンスが安定することがあります。これは僕たちがプロンプトを設計する際にも参考になります。
これが最も実用的な教訓です。コードを書かせた直後に「レビューして」と同じAIに頼むより、別セッション（別のAI）にレビューさせる方がはるかに効果的です。Anthropicの実験でも、独立した評価AIを厳しくチューニングする方が、生成AIを自己批判的にさせるよりずっと容易でした。
Anthropicの結論は示唆に富んでいます。モデルが進化しても、ハーネス（足場）設計の重要性は消えない。むしろ、モデルが良くなるほど「より面白いハーネスの組み合わせ」が可能になり、AIエンジニアに求められるのは「次の斬新な組み合わせを見つけ続けること」だと言います。
GANという古くて新しいアイデアが、AIエージェントの設計にこんなにも自然にマッチするとは。AIの進化は、ただモデルを大きくするだけじゃなく、どう組み合わせるかにあるのかもしれません。
📰 参考元: Harness design for long-running application development - Anthropic Engineering