harness

name	harness
description	長時間実行タスクや複雑な実装にHarness設計パターンを適用する。Planner/Generator/Evaluatorの分離、スプリント分割、品質ループ、ファイルベースのハンドオフを行う。大きな機能実装、長時間のコーディングタスク、品質の担保が重要な作業に使用する。

Harness

長時間実行タスクでAIエージェントの品質を維持するための設計パターン。

参考: Harness design for long-running apps

なぜHarnessが必要か

単一エージェントで長時間タスクを実行すると:

• コンテキストが膨らみ一貫性を失う
• 自分の成果物を客観的に評価できない（楽観バイアス）
• 複雑なタスクで配線ミスや機能の欠落が起きる

3エージェント・アーキテクチャ

GANに着想を得た分離パターン。生成と評価を別エージェントが担う。

Planner（計画者）

• ユーザーの短いプロンプトを詳細な仕様に展開する
• スコープは野心的に、実装詳細は避ける
• スプリント単位で作業を分割し、各スプリントの「完了条件」を定義する
• 出力: 仕様ファイル（plan.md や sprints/sprint-N.md）

Generator（生成者）

• 仕様に基づいて実装する
• スプリント単位で作業し、各スプリント完了時に自己評価してEvaluatorに引き継ぐ
• Gitで各スプリントをコミットする
• 出力: 実装コード + 自己評価レポート

Evaluator（評価者）

• 実際にアプリケーションを動かしてテストする
• スプリント契約（完了条件）に基づいて検証する
• Generatorとは独立した視点で評価する
• 出力: 評価レポート + 修正指示

核心: 自分の仕事を自分で評価させない。生成者が「できた」と言っても、評価者が検証するまで完了としない。

ファイルベースのハンドオフ

エージェント間の通信はファイル経由で行う。

project/
├── harness/
│   ├── plan.md                 # Plannerの出力: 全体仕様
│   ├── sprints/
│   │   ├── sprint-1.md         # スプリント1の仕様と完了条件
│   │   ├── sprint-1-eval.md    # スプリント1の評価結果
│   │   ├── sprint-2.md
│   │   └── sprint-2-eval.md
│   └── status.md               # 現在の進捗状況

このパターンにより:

• 各エージェントが必要な情報だけを読める
• セッション間で状態が追跡可能
• コンテキストウィンドウを圧迫しない

スプリント契約

各スプリントに事前合意された「完了」の定義を設ける。

## Sprint 1: ユーザー認証

### 完了条件
- [ ] ログインフォームが表示される
- [ ] メールアドレスとパスワードでログインできる
- [ ] ログイン後にダッシュボードにリダイレクトされる
- [ ] 無効な認証情報でエラーメッセージが表示される
- [ ] ログアウトボタンが機能する

Evaluatorはこの条件に基づいて検証する。曖昧な「動いている」ではなく、具体的な基準で判定する。

適用の判断

Harnessを使うべきとき

• 実装に1時間以上かかる見込みのタスク
• 複数の機能が連携する複雑なシステム
• 品質の客観的な検証が重要な場面
• 仕様が曖昧で、計画フェーズが必要なとき

Harnessが不要なとき

• 単純なバグ修正や小さな機能追加
• 明確な仕様があり、迷いなく実装できるとき
• 30分以内に完了するタスク

実践的な適用方法

Claude Codeでの実装方法は references/implementation.md を参照。

原則

• 最もシンプルなソリューションから始める: 必要な場合のみ複雑さを増す
• モデルの進化に合わせて調整する: 新モデルでは不要な足場を削除し、シンプルにする
• 実験と観察: 実際のタスクでテストし、トレースを読んで調整する
• スプリント契約を守る: 完了条件を事前に定義し、曖昧にしない

リファレンス

• 実装ガイド