0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kai_kou(甲斐 甲)

Anthropic マルチエージェントハーネス入門 — 自律アプリ開発の3エージェント設計

0
Last updated at Posted at 2026-04-05

はじめに

2026年3月24日、AnthropicはエンジニアリングブログにてAIエージェントが自律的にフロントエンド設計・フルスタックアプリを構築する「マルチエージェントハーネス」の設計を公開しました1。

単一エージェントではコンテキスト枯渇や自己評価バイアスが課題になる長時間タスクを、Planner・Generator・Evaluatorの3エージェント分業 で解決するアーキテクチャです。

この記事で学べること

  • 3エージェント（Planner / Generator / Evaluator）の役割と協調パターン
  • Playwright MCPを使ったEvaluatorによるUIテスト自動化
  • GeneratorとEvaluatorによる成功基準の事前合意パターン
  • コンテキスト管理の実践知見（コンパクションよりリセットが有効な理由）
  • コスト・所要時間の実績値と費用対効果の考え方

対象読者

  • AIエージェントを使ったアプリ開発の自動化に興味があるエンジニア
  • 長時間・大規模タスクへのエージェント活用方法を探している方
  • Claude APIを使ったマルチエージェントシステム設計者

前提環境

  • Claude APIアクセス（claude-opus-4-6 推奨）
  • Playwright / Playwright MCP の基礎知識があると理解が深まります
  • Python または TypeScript の読み書きができる方

TL;DR

  • 3エージェント設計: Planner（仕様策定）→ Generator（実装）→ Evaluator（UIテスト）
  • 自己評価バイアスを解消: 生成と評価を分離することで品質が大幅に向上
  • 成功基準の事前合意: 実装前にGeneratorとEvaluatorが検証可能な基準を合意
  • コンテキストはリセット: 圧縮より清書（コンテキストリセット）の方が品質が安定
  • 実績: Retro Game Maker（20分・$9 ソロ）/ $200で6時間稼働のフルハーネス

背景と課題：なぜ単一エージェントでは不十分か

コンテキスト枯渇問題

Claude Sonnet 4.5 での長時間タスク実験で、「コンテキスト不安（context anxiety）」 と呼ばれる現象が観察されました。コンテキストウィンドウが埋まるにつれ、モデルが作業を途中で打ち切る行為です。

Anthropicはこの問題に対してコンパクション（要約）アプローチを試みましたが、重要な技術詳細が消失することが多く安定しませんでした。最終的に採用した解決策は コンテキストリセット——つまり新鮮なエージェントに構造化されたハンドオフアーティファクトを渡す方法です（Opus 4.5 時代はこの仕組みが必要でした）。

Claude Opus 4.6 ではこの「コンテキスト不安」が大幅に改善されたため、長時間タスクのスキャフォールドが大幅にシンプルになりました。

自己評価バイアス問題

単一エージェントに自分の成果を評価させると、「クオリティが明らかに低い場合でも自信を持って称賛する」という傾向が確認されました。

解決策は 生成と評価の完全分離 です。GANアーキテクチャにインスパイアされたこのアプローチにより、Generator は実装に集中し、Evaluator は懐疑的な評価者として機能します。

ハーネスのアーキテクチャ

Planner：仕様策定エージェント

Plannerは1〜4文の短いプロンプトを受け取り、包括的な製品仕様 に変換します。

Input:  "レトロゲームメーカーを作ってほしい"
Output: プロダクト仕様書
        - スコープ定義（物理エンジン付きゲームエディタ、スプライトエディタ）
        - 成功基準の高レベル定義
        - 実装に影響する制約事項

Plannerが注意する点は「過剰に細粒度な技術制約を含めない」ことです。細かすぎる制約はGeneratorに連鎖的な失敗を引き起こすことがあります。

Generator：実装エージェント

Generatorは仕様を受け取り、インクリメンタルに機能を実装 します。デフォルトスタックは以下です。

レイヤー 技術スタック
フロントエンド React + Vite
バックエンド FastAPI
データベース SQLite

Generatorは各機能を実装した後、Evaluatorへハンドオフする前に 自己評価チェック を実施します（ただしこの自己評価は信頼性が低く、Evaluatorが主な品質ゲートです）。

Evaluator：UIテストエージェント

EvaluatorはPlaywright MCPを受け取り、実際のユーザーのようにアプリを操作してテスト します。

# Evaluatorが受け取るMCPツール例
evaluator_tools = [
    playwright_mcp.navigate,      # URLナビゲーション
    playwright_mcp.click,         # UI要素クリック
    playwright_mcp.fill,          # フォーム入力
    playwright_mcp.screenshot,    # 状態キャプチャ
    playwright_mcp.assert_text,   # テキスト検証
]

Evaluatorはフロントエンド品質を以下の4基準で採点します：

基準 内容
Design Quality 一貫したビジュアルアイデンティティ（色・タイポグラフィ・レイアウト）
Originality 汎用的な「AIスロップ」パターンを避けた創造的選択
Craft タイポグラフィ階層・スペーシングなど技術的な完成度
Functionality ユーザーがタスクを完遂できるかどうか

特に「AIスロップ」（画一的なAI生成UI）に対してはペナルティを与え、審美的なリスクテイクを促すよう設定されています。

成功基準の事前合意：GeneratorとEvaluatorの協調

単純に「これを作れ」と指示するのではなく、GeneratorとEvaluatorが実装前に検証可能な成功基準を合意 します。高レベルなユーザーストーリーと検証可能な実装詳細のギャップを埋めるための重要なパターンです。

成功基準合意 例（Retro Game Maker の "Level Design" 機能）:

GENERATOR の実装コミットメント:
  - タイルベースのグリッドエディタ（16x16マス）
  - 物理オブジェクト（プラットフォーム・トリガーゾーン）の配置
  - セーブ/ロード機能（LocalStorage）

EVALUATOR の検証基準:
  [PASS] グリッドにタイルを配置できる
  [PASS] 物理オブジェクトを正確に配置・削除できる
  [PASS] セーブ後にページリロードしてもステートが保持される
  [FAIL条件] グリッドが崩れる / オブジェクトがドラッグ不可

このパターンにより、実装開始前に「何をもって完了とするか」が明確になります。

コンテキスト管理：コンパクションよりリセット

長時間タスクでのコンテキスト管理について、Anthropicはいくつかのアプローチを比較しました。

試したアプローチと結果

アプローチ 結果
コンテキストコンパクション（要約） 重要な技術詳細が消失。安定性が低い
スプリント単位での評価（Opus 4.5時代） コンテキスト不安を回避できたが複雑化
コンテキストリセット（採用） 新鮮なエージェントに構造化ハンドオフ。最も安定

ハンドオフアーティファクトの構造

コンテキストリセット時にエージェント間で受け渡す構造化データの例です。

{
  "task_overview": {
    "request": "Retro Game Maker の物理エンジン統合",
    "success_criteria": ["タイルに重力適用", "プレイヤー衝突検出"],
    "constraints": ["Vite/React スタック", "ブラウザネイティブのみ"]
  },
  "current_state": {
    "completed_features": ["グリッドエディタ", "スプライト管理"],
    "modified_files": ["src/physics/engine.ts", "src/editor/grid.tsx"],
    "artifacts": ["physics-demo.mp4"]
  },
  "important_discoveries": {
    "technical_constraints": ["requestAnimationFrame でのタイミング制限"],
    "resolved_errors": ["Canvas APIの座標系変換バグ"],
    "decisions": ["Box2D.js より Matter.js の方が軽量で適切と判断"]
  },
  "next_steps": [
    "衝突コールバックのデバッグ",
    "レベルロード時の物理ステートリセット"
  ]
}

パフォーマンスとコスト実績

Retro Game Maker

構成 所要時間 コスト 成果
ソロエージェント 20分 $9 物理エンジン・スプライトエディタ・AI統合
フルハーネス（Planner+Generator+Evaluator） 6時間 $200 同上 + 高精度な設計と品質検証

Digital Audio Workstation（簡略化ハーネス）

項目 値
所要時間 3時間50分
コスト $124.70
成果 アレンジビュー・ミキサー・AI支援作曲機能付きDAW

一般的な特性

  • イテレーション回数: 5〜15回/タスク
  • 最大セッション時間: 4時間
  • 対応モデル: Claude Opus 4.6（推奨）

Claude Opus 4.6 での進化

ハーネスの設計はモデルの能力向上とともに変化しています。

コンポーネント Opus 4.5 時代 Opus 4.6 時代
スプリント分解 必須（コンテキスト管理に必要） 不要（ネイティブプランニング能力が向上）
Evaluator 毎スプリント必須 条件付き（モデル対応範囲は省略可）
コンテキスト不安（Sonnet 4.5で顕著） コンテキストリセットで対応 大幅に改善

"Every component in a harness encodes an assumption about what the model can't do on its own."
— Anthropic Engineering Blog1

コンポーネントは「モデルがまだ単独ではできないこと」の仮定を具現化したものです。モデルが進化するにつれ、ハーネスのスキャフォールドは徐々に不要になっていくという視点が重要です。

実装上の注意点

以下の問題はハーネスでも完全には解消できません：

  • 直感的でないレイアウトの微妙な不整合
  • 深くネストした機能の未発見バグ
  • エッジケースの不完全な処理

また、Playwright MCPで Web Search / Web Fetch を併用する場合、SDK がトークン使用量を誤計算しコンパクションが意図しないタイミングで発動する場合があります2。

まとめ

Anthropicのマルチエージェントハーネスは、長時間・高品質な自律アプリ開発を実現する実践的な設計パターンです。

  • Planner / Generator / Evaluatorの分業 で自己評価バイアスを解消
  • 成功基準の事前合意 で「作る前に検証基準を合意する」構造がカギ
  • コンテキストリセット がコンパクションより安定（重要な技術詳細が失われない）
  • Claude Opus 4.6 でコンテキスト不安が解消され、ハーネスの複雑さが大幅に低減

単一エージェントで数時間かかるタスクに取り組む際は、このPlanner-Generator-Evaluatorパターンを参考にアーキテクチャを設計することで品質と安定性が向上します。

参考リンク

  1. Harness design for long-running autonomous applications — Anthropic Engineering Blog（2026-03-24） ↩ ↩2

  2. Compaction — Claude API Docs ↩

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?