# Harness Design for Long-Running Application Development [[Prithvi Rajasekaran]]（Anthropic Labs）による 2026-03-24 の技術記事。高品質なフロントエンド設計と完全なアプリ自律開発を実現するための発展的なハーネス設計を報告する。前編 [[@2025__Anthropic Engineering Blog__Effective Harnesses for Long-Running Agents]] と並ぶ Anthropic のハーネス設計の実践知。 ## 核心問題 ### 自己評価バイアス（Self-Evaluation Limitation） Claude に自分の出力を評価させると、「品質が明らかに低くても確信を持って高評価を返す」傾向がある。特にデザインなど客観的メトリクスが存在しない主観的タスクで深刻。 ### コンテキスト管理の 2 問題 1. **コンテキスト不安（Context Anxiety）**：モデルがコンテキスト上限に近づくと感知し、早期に作業を打ち切る 2. **コヒーレンス喪失（Coherence Loss）**：コンテキストウィンドウが埋まるにつれてモデルが焦点を失う 解決策：コンテキスト**圧縮**ではなく**リセット**——セッションごとに白紙から再開しつつ、構造化された成果物で継続性を維持する。 ## フロントエンド設計実験：ジェネレータ・エバリュエータ GAN（敵対的生成ネットワーク）に着想を得たマルチエージェント構成： - **ジェネレータ**：HTML/CSS/JavaScript フロントエンドを生成 - **エバリュエータ**：Playwright MCP でライブページをブラウザ操作してから採点 ### 評価基準（4 軸） | 軸 | 内容 | |---|---| | **デザイン品質** | 統一されたムード・アイデンティティを持つ審美性 | | **独自性** | テンプレートデフォルトでなく独自の意思決定の証拠 | | **クラフト** | タイポグラフィ・余白・カラーハーモニー・コントラスト比 | | **機能性** | ユーザビリティとタスク完了 | エバリュエータは 1 生成につき 5〜15 回イテレーション。詳細な批評をもとにジェネレータが戦略的に改善または方向転換する。 ## フルスタック開発ハーネス：3 エージェント構成 ### Planner エージェント - 簡潔なプロンプトを包括的な製品仕様に展開 - スコープを意欲的に設定しつつ技術詳細は過度に指定しない - AI 機能統合の機会を特定 ### Generator エージェント - React + Vite + FastAPI + SQLite/PostgreSQL スタックで実装 - 仕様を体系的に消化 - QA への引き渡し前に自己評価を実施 ### Evaluator エージェント - Playwright MCP でエンドユーザーとしてアプリを操作・テスト - 基準に照らして採点・バグを特定 - コーディング開始前にスプリントコントラクト（「完了」の定義）を交渉 ### エージェント間コミュニケーション ファイルベースの構造化コミュニケーション。高水準ユーザーストーリーとテスト可能な実装の橋渡しを、ジェネレータの自由度を過度に制約せずに行う。 ## 主要な成果 ### レトロゲームメーカー比較 | 方式 | 所要時間 | コスト | 品質 | |---|---|---|---| | ソロエージェント | 20 分 | $9 | ゲームロジック破綻・動作不可 | | フルハーネス | 6 時間 | $200 | 動作するゲームプレイ・スプライトアニメ・AI 支援機能搭載 | ### Opus 4.6 へのアップグレード後の簡略化 | 削除したコンポーネント | 理由 | |---|---| | スプリント分解 | 改善されたモデルが長い一貫した作業を単独でこなせる | | スプリント単位の評価 | ビルド終了時の単一 QA パスに移行しオーバーヘッドを削減 | DAW（デジタルオーディオワークステーション）を約 4 時間・$124.70 で構築（アレンジビュー・ミキサー・AI 駆動作曲機能を含む）。 ## 核心的洞察 ### 荷重仮定（Load-Bearing Assumptions） > 「ハーネスの各コンポーネントは、モデルが単独ではできないことに関する仮定をエンコードしている。それらの仮定はストレステストする価値がある。」 モデルが改善するにつれて、かつて必要だったコンポーネントは不要になる。ハーネスは常に削減の余地を持って設計するべき。 ### 主観性を測定可能にする 「審美性はスコアに完全に還元できない」が、設計原則を具体的な基準にエンコードすれば一貫したフィードバックが可能。「これは美しいか？」は答えられないが「これは良いデザインの原則に従っているか？」は答えられる。 ### モデル能力境界の移動 エバリュエータの価値はモデル能力とタスク難易度の相対関係に依存する。Opus 4.5 ではほぼ全ビルドに外部検証が必要だったが、4.6 では境界が移動——単純タスクは QA オーバーヘッドが不要になり、複雑タスクは引き続き恩恵を受ける。 ## 関連 - 概念: [[ループエンジニアリング]] / [[Harness Engineering]] / [[マルチコンテキストウィンドウエージェント]] / [[LLM自己検証]] - エンティティ: [[Prithvi Rajasekaran]] / [[Anthropic]] - 前編: [[@2025__Anthropic Engineering Blog__Effective Harnesses for Long-Running Agents]]（Justin Young、2025-11-26） - 関連 MOC: 未設定 ## 出典 - 原文: https://www.anthropic.com/engineering/harness-design-long-running-apps (2026-03-24) - ローカル: `.raw/articles/harness-design-long-running-apps-2026-03-24.md`