ハーネス設計解析レポート：Planner / Generator / Evaluatorを中心とした世界最高水準アーキテクチャ

作成者: Manus AI
作成日: 2026-05-11
対象動画: ハーネス設計（スタッフ）動画.mp4

1. エグゼクティブサマリー

本動画の中心的な主張は、ハーネスとは、AIが人間の意図からブレず、目的の成果物に到達するための制約・役割分担・評価ループを最初から設計しておく仕組みである、というものです。動画では、Anthropicの公開事例に触れながら、Planner、Generator、Evaluatorの3エージェント構成をプロジェクト単位で用意し、CLAUDE.mdや.claude/agents/、評価基準ファイルを通じてAIに必ず読ませる設計が提案されています。

外部調査の結果、この仮説は現在のエージェント開発の最先端と整合しています。Anthropicは、長時間自律開発でGeneratorとEvaluatorを分離し、Plannerを含む3エージェント構成を有効なハーネスとして提示しています。1 また、Anthropicのエージェント設計記事は、agentic systemを固定経路のworkflowと自律的なagentに分け、ground truth、停止条件、sandbox、guardrailsの重要性を強調しています。2 Addy Osmaniは、エージェントを「Model + Harness」と定義し、プロンプト、ツール、文脈管理、hooks、sandbox、subagents、feedback loop、recovery pathが実用性能を決めると整理しています。3 Martin Fowlerの記事では、ハーネスを事前制御であるfeedforwardと事後制御であるfeedbackの組み合わせとして捉えています。4 OpenAIは、巨大なAGENTS.mdを避け、短い入口ファイルを目次にし、詳細な知識ベースを構造化されたdocs/へ置く設計を実運用知見として示しています。5

結論: 世界最高水準のハーネス設計は、単に3つのエージェントMarkdownを置くことではありません。最適解は、短い入口ルール、プロジェクト固有の3エージェント、評価ルーブリック、決定論的品質センサー、実行ログ、失敗からルールを増やす学習ループを一体化した、自己改善型のAI実行基盤です。

2. 動画内容の解析

動画は約4分46秒で、ハーネス設計の目的、3エージェント構成、プロジェクトごとのエージェント定義、評価基準の外部化、CLAUDE.mdによる強制読込の必要性を順に説明しています。話者の仮説は、「汎用エージェントをどこかにまとめて置く」のではなく、作るものによって仕様設計・生成物・評価基準が変わるため、プロジェクトごとにPlanner、Generator、Evaluatorを定義するべきという点にあります。

この解析から、動画内の「ハーネス」は、現在の用語で言えば、agent harness、context engineering、workflow orchestration、quality gate、agent evaluationを組み合わせた設計概念です。特に「Generatorに作らせ、Evaluatorが何度も戻す」という考えは、Anthropicの長時間アプリ開発ハーネスと同じ中核構造です。1

3. 調査に基づくハーネス設計の定義

本レポートでは、ハーネス設計を次のように定義します。

ハーネス設計とは、AIモデルの周囲に、目的、文脈、権限、ツール、役割分担、評価基準、品質ゲート、観測、復旧、学習更新を配置し、AIの出力を人間が望む方向へ安定的に収束させるための実行アーキテクチャである。

この定義では、ハーネスを単なるプロンプトやディレクトリ構成に限定しません。実務上のハーネスは、読むべき情報、実行できる行動、検査される条件、失敗時の戻し方、次回以降に失敗を再発させない仕組みを含む必要があります。

4. 世界最高水準のハーネス設計アーキテクチャ

下図は、動画内容と外部調査を統合した、現時点で最も強いハーネス設計の参照アーキテクチャです。重要なのは、Planner、Generator、Evaluatorだけでなく、決定論的センサー、品質ゲート、観測、メモリ、ルール更新が閉ループを形成している点です。

このアーキテクチャは、生成と評価を分離するAnthropic型の3エージェント構成、短い入口ファイルを地図にするOpenAI型の知識管理、feedforwardとfeedbackを組み合わせるFowler型の制御設計、失敗をルールへ変換するOsmani型のratchet運用を統合しています。1 4

5. 推奨ディレクトリ構成

以下は、Claude Code、Codex、Cursor、Cline、Manus系エージェントなど、複数のAI開発環境に転用しやすい、プロジェクト内ハーネスの推奨ディレクトリ構成です。Claude Codeの公式ドキュメントでは、プロジェクト配下の.claude/にsettings、rules、skills、commands、agents、agent-memoryを置けることが示されています。6

project-root/
├── AGENTS.md                         # 全AIエージェント共通の短い入口地図
├── CLAUDE.md                         # Claude向け入口。AGENTS.mdへの委譲でもよい
├── ARCHITECTURE.md                   # システム境界、依存方向、主要設計判断
├── README.md                         # 人間向け概要
├── .mcp.json                         # MCPや外部ツール接続の共有設定
├── .claude/
│   ├── settings.json                 # 共有権限、hooks、許可ツール、環境設定
│   ├── settings.local.json           # 個人設定。原則git管理しない
│   ├── agents/
│   │   ├── planner.md                # 要件整理・仕様化・タスク分解担当
│   │   ├── generator.md              # 実装・生成担当
│   │   ├── evaluator.md              # 評価・差戻し・採点担当
│   │   ├── reviewer.md               # PR/差分レビュー担当
│   │   └── harness-janitor.md        # 失敗履歴からルール・テストを増やす担当
│   ├── rules/
│   │   ├── harness-workflow.md       # P/G/Eを必ず使う運用ルール
│   │   ├── coding-standards.md       # コーディング規約
│   │   ├── testing.md                # テスト方針
│   │   ├── architecture-boundaries.md# 依存方向・禁止依存
│   │   └── security.md               # セキュリティ禁止事項
│   ├── skills/
│   │   ├── spec-writing/SKILL.md     # 仕様作成スキル
│   │   ├── ui-verification/SKILL.md  # UI検証スキル
│   │   └── refactor/SKILL.md         # リファクタリングスキル
│   ├── commands/
│   │   ├── plan.md                   # Planner起動用コマンド
│   │   ├── implement.md              # Generator起動用コマンド
│   │   ├── evaluate.md               # Evaluator起動用コマンド
│   │   └── harness-retro.md          # 失敗振り返り用コマンド
│   └── agent-memory/
│       ├── planner/MEMORY.md
│       ├── generator/MEMORY.md
│       └── evaluator/MEMORY.md
├── docs/
│   ├── product-specs/
│   │   ├── index.md
│   │   └── acceptance-criteria.md
│   ├── architecture/
│   │   ├── context-map.md
│   │   ├── module-boundaries.md
│   │   └── data-flow.md
│   ├── adr/
│   │   └── 0001-record-architecture-decisions.md
│   ├── design-docs/
│   │   ├── core-beliefs.md
│   │   └── design-principles.md
│   ├── exec-plans/
│   │   ├── active/
│   │   ├── completed/
│   │   └── tech-debt-tracker.md
│   └── references/
│       └── llm-readable-reference.md
├── harness/
│   ├── contracts/
│   │   ├── task-contract.template.md
│   │   └── handoff.template.md
│   ├── runs/
│   │   └── YYYYMMDD-HHMM-task-name/
│   │       ├── planner-output.md
│   │       ├── generator-log.md
│   │       ├── evaluator-report.md
│   │       └── final-decision.md
│   ├── feedback/
│   │   ├── feedback-packet.template.md
│   │   └── recurring-failures.md
│   └── memory/
│       ├── failure-registry.md
│       └── harness-change-log.md
├── evals/
│   ├── rubrics/
│   │   ├── product-quality.md
│   │   ├── implementation-quality.md
│   │   ├── security-quality.md
│   │   └── documentation-quality.md
│   ├── checklists/
│   │   ├── definition-of-done.md
│   │   └── release-readiness.md
│   └── scenarios/
│       └── critical-user-journeys.md
├── quality/
│   ├── gates/
│   │   ├── pre-implementation.md
│   │   ├── pre-merge.md
│   │   └── release.md
│   ├── scripts/
│   │   ├── run-all-checks.sh
│   │   └── architecture-check.sh
│   └── reports/
├── observability/
│   ├── logs/
│   ├── screenshots/
│   ├── traces/
│   └── metrics/
├── scripts/
│   ├── bootstrap.sh
│   ├── test.sh
│   ├── lint.sh
│   └── build.sh
└── tests/
    ├── unit/
    ├── integration/
    └── e2e/

この構成で最も重要なのは、AGENTS.mdやCLAUDE.mdを巨大な指示書にしないことです。OpenAIの知見が示すように、巨大な入口ファイルは文脈を圧迫し、重要度を希釈し、腐敗しやすく、検証しづらくなります。5 したがって、入口ファイルは地図に徹し、詳細はdocs/、.claude/rules/、evals/、harness/へ分割します。

6. 最小必須ファイルの設計

すべてを一度に作る必要はありません。最小構成としては、以下の10ファイルをまず作るべきです。

7. Planner / Generator / Evaluatorの役割定義

Plannerは、ユーザー要望をそのまま実装に渡してはいけません。Plannerの仕事は、曖昧な要求を、目的、非目的、制約、前提、受け入れ基準、リスク、タスク分解、検証方法へ変換することです。Generatorは、Plannerが作った契約以外の勝手な解釈を最小化し、実装または成果物生成に集中します。Evaluatorは、Generatorと別人格として、仕様適合性、品質、リスク、保守性、セキュリティ、ユーザー価値を採点し、合格しない場合は具体的な差戻しを返します。

8. 評価ルーブリックの設計

Evaluatorは「良いか悪いか」を曖昧に判断するのではなく、採点可能な基準で評価します。Anthropicはフロントエンド設計評価において、design quality、originality、craft、functionalityなど、主観的品質を具体的な評価軸に分解しています。1 この発想を一般化すると、ハーネス設計では以下のような評価基準が必要です。

9. 運用フロー

推奨フローは、Plan → Contract → Generate → Check → Evaluate → Feedback → Regenerate → Release → Learnです。この順序をCLAUDE.mdと.claude/rules/harness-workflow.mdに明記し、AIが勝手に短絡しないようにします。

10. 導入時の実務ルール

最初から完璧なハーネスを作るより、失敗が起きるたびにハーネスを強くする運用が重要です。Addy Osmaniが述べるように、良いハーネスでは、エージェントが一度ミスしたら、そのミスを再発させないようにルール、フック、テスト、レビュー担当エージェントを増やします。3 Martin Fowlerの表現では、これは人間がハーネスを反復改善するsteering loopです。4

11. 結論

動画内の仮説は正しく、むしろ現在のエージェント設計の最前線と一致しています。ただし、世界最高水準を目指すなら、CLAUDE.mdと.claude/agents/planner.md、generator.md、evaluator.mdを置くだけでは不足です。実務で強いハーネスは、入口ファイルを短い地図にし、プロジェクト固有のエージェントを置き、評価基準を外部化し、機械的品質センサーを組み込み、失敗履歴を次のルール・テスト・ADRへ昇格させる閉ループとして設計されます。

最終的に目指すべき状態は、AIに「頑張って」と頼むことではありません。AIが迷えないほど文脈を整理し、勝手に逸脱できないほど制約を明確にし、合格できない成果物が自然に差し戻され、失敗するたびにハーネスが強くなる状態です。これが、本レポートで提案する世界最高水準のハーネス設計アーキテクチャです。

References