Claude CodeのAgent Teams機能を本気で使いこなしている開発者はどれだけいるだろうか。チームを組むには複数のエージェント定義ファイル・スキルファイル・オーケストレーションルールを手で書く必要があり、ハードルは決して低くない。
GitHub Stars 2,400超のHarnessは、そのハードルを「プロンプト1行」まで下げるClaude Codeプラグインだ。「build a harness for this project」と伝えるだけで、プロジェクトに最適なエージェントチーム構成・スキル・オーケストレーションを自動設計する。revfactoryが公開した公式A/Bテストでは、コード品質スコアが平均49.5→79.3へ+60%改善し、15戦全勝という結果も出ている。
本記事ではHarnessの全体像を、公式リポジトリのreferences/配下に格納されたドキュメントをベースに体系的に解説する。Claude Codeの全機能を踏まえて読むと、なぜHarnessがここまで支持されているのかが腑に落ちるはずだ。
この記事ではAIエージェントに特化して解説します。AIエージェント全般は AIエージェントフレームワーク比較2026年版 をご覧ください。
Harnessとは：エージェントチームを自動設計する「メタスキル」
Harnessは一般的なプラグインとは性質が異なる。通常のClaude Codeプラグインが「特定の機能を追加する」のに対し、Harnessが生み出すのはエージェント定義とスキルそのものだ。言い換えれば、Harnessはエージェントを作るためのエージェント——いわゆる「メタスキル」に位置づけられる。
「ハーネスとは、馬に装着する革製の装具の総称だ。プロジェクトというチームに、役割と手綱を付ける。それがHarnessの意図するところだ」 —— revfactory/harness README
Harnessの内部は6つのフェーズで構成される。最初にドメインを分析し、タスクに合う6つのアーキテクチャパターンから最適なものを選び、エージェントとスキルのMarkdownファイルを生成する。最後にオーケストレーション設定と検証を加えて完了する——というのが大まかな流れだ。
ドメイン分析"] --> B["Phase 2
チームアーキテクチャ設計"] B --> C["Phase 3
エージェント定義生成
.claude/agents/"] C --> D["Phase 4
スキル生成
.claude/skills/"] D --> E["Phase 5
統合・オーケストレーション"] E --> F["Phase 6
検証・テスト"] style A fill:#4A90D9,color:#fff style B fill:#4A90D9,color:#fff style F fill:#2ECC71,color:#fff
入力は自然言語のプロンプト1行、出力は.claude/agents/と.claude/skills/に生成される複数のMarkdownファイルだ。生成後はClaude CodeのAgent Teams機能がそのまま読み込むため、追加のランタイム設定なしで動作する。
your-project/
├── .claude/
│ ├── agents/ # エージェント定義ファイル
│ │ ├── analyst.md
│ │ ├── builder.md
│ │ └── qa.md
│ └── skills/ # スキルファイル
│ ├── analyze/
│ │ └── SKILL.md
│ └── build/
│ ├── SKILL.md
│ └── references/
Harnessプラグイン自体の構造も把握しておくと、カスタマイズの幅が広がる。references/配下にはアーキテクチャパターン、オーケストレーターテンプレート、QAガイドなどの「設計レシピ」が整理されており、これらを編集することで組織独自の設計ルールに書き換えられる。
harness/
├── .claude-plugin/
│ └── plugin.json # プラグインマニフェスト
├── skills/
│ └── harness/
│ ├── SKILL.md # メインスキル（6フェーズ定義）
│ └── references/
│ ├── agent-design-patterns.md # 6つのアーキテクチャパターン
│ ├── orchestrator-template.md # オーケストレーターテンプレート
│ ├── team-examples.md # 5つの実践チーム例
│ ├── skill-writing-guide.md # スキル作成ガイド
│ └── qa-agent-guide.md # QAエージェント統合ガイド
└── README.md
Claude Skillsの基礎を踏まえると、Harnessは「スキルの仕組み」を使って「エージェントチーム設計のノウハウ」をパッケージ化した実例と捉えられる。スキルでスキルを生む——これがメタスキルと呼ばれる所以だ。
Harnessは「エージェント定義・スキル」を自動生成するメタスキル
6フェーズ（分析→設計→生成→スキル→統合→検証）でチームを構築
references/配下の設計レシピを編集すれば組織独自の設計ルールに書き換え可能
インストール方法：3通りの導入パターンを使い分ける
Harnessのインストールには3つのルートがある。自動アップデートを重視するか、バージョンを固定したいか、プロジェクト単位で閉じたいかで選ぶ。
方法1：マーケットプレイス経由（推奨）
もっとも公式的な導入ルートだ。Claude Code内で以下のスラッシュコマンドを順に実行するだけで、自動アップデートの対象になる。
# マーケットプレイスにHarnessを追加
/plugin marketplace add revfactory/harness
# プラグインをインストール
/plugin install harness@harness
方法2：グローバルスキルとして直接コピー
~/.claude/skills/harness配下に直接コピーする方法だ。すべてのプロジェクトで横断的に使えるうえ、任意のコミットで固定できる。
git clone https://github.com/revfactory/harness.git
cp -r harness/skills/harness ~/.claude/skills/harness
方法3：プロジェクトローカルに配置
プロジェクトごとにバージョンを揃えたい場合は、.claude/skills/harnessに直接入れる。リポジトリにcommitすれば、チーム全員が同じHarnessで作業できる。
cp -r harness/skills/harness .claude/skills/harness
Agent Teams機能はまだ実験的扱いのため、環境変数の設定が必要だ。.bashrcや.zshrcに追加しておくと毎回打つ必要がなくなる。
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
| 導入方法 | 適用範囲 | アップデート | バージョン固定 |
|---|---|---|---|
| マーケットプレイス | 指定プロジェクト | 自動 | △ |
| グローバルコピー | 全プロジェクト | 手動 | ◎ |
| ローカルコピー | このプロジェクトのみ | 手動 | ◎ |
.claude/skills/harnessをGit管理下に置いてリポジトリにcommitすれば、PRレビュー時にHarnessの改変も一緒にレビューできる。CI環境でも同じ構成でAgent Teamsを再現できるため、マルチエージェント前提の開発では方法3が扱いやすい。
導入は「マーケットプレイス」「グローバルコピー」「ローカルコピー」の3通り
Agent Teams機能を使うには
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 が必須チーム運用ではローカルコピー＋Git管理が再現性の面で扱いやすい
6つのアーキテクチャパターンの選び方
Harnessの中核は、タスクの性質に応じて適切なチーム構成を選ぶ「設計パターン」にある。公式のagent-design-patterns.mdにまとめられた6パターンそれぞれに、明確な使い分けが存在する。
| パターン | 概要 | 適用場面 | エージェント数の目安 |
|---|---|---|---|
| Pipeline | タスクを順序どおりに処理 | ビルド→テスト→デプロイのような依存関係がある処理 | 3〜5 |
| Fan-out/Fan-in | 並列実行後に結果を統合 | コードレビュー（セキュリティ/パフォーマンス/スタイルを並列チェック） | 3〜6 |
| Expert Pool | コンテキストに応じて専門家を選択 | フロントエンド/バックエンド/インフラなど分野別対応 | 4〜8 |
| Producer-Reviewer | 生成→品質レビューのペア | ドキュメント生成、テストコード生成 | 2〜4 |
| Supervisor | 中央エージェントが動的に配分 | 要件が変動するプロジェクト管理 | 3〜6 |
| Hierarchical Delegation | トップダウンで再帰的に委譲 | 大規模システムの設計・実装 | 5〜10 |
OpenHandsのような単体AIコーディングエージェントが「一人の優秀なエンジニア」だとすれば、Harnessは「チーム編成を最適化するテックリード」だ。タスクの規模や複雑さに応じて、この6パターンから最も適したものを自動で選択する。
特に注目したいのは Fan-out/Fan-in と Hierarchical Delegation だ。前者はコードレビューのように観点が独立している作業で強力に働き、後者は大規模システム設計のように複数階層の意思決定が必要なケースで効果を発揮する。
実行モード：Agent TeamsとSubagentsの違い
パターン選択に加え、Harnessは2つの実行モードも自動で選ぶ。協調が必要かどうかが判断軸だ。
| 項目 | Agent Teams（デフォルト） | Subagents |
|---|---|---|
| 通信方式 | TeamCreate + SendMessage + TaskCreate | 直接Agent tool呼び出し |
| エージェント間通信 | あり | なし |
| 推奨場面 | 2名以上のエージェントが協調する場合 | 単発タスク、通信不要な処理 |
| オーバーヘッド | やや大きい | 小さい |
Agent Teamsモードではエージェント同士がメッセージを送り合い、互いの進捗を参照しながら作業を進める。Subagentsモードは独立タスクの並列実行に特化し、通信オーバーヘッドを最小化する軽量モードだ。
「協調が必要な仕事にはAgent Teams、独立した仕事にはSubagentsを使う。これはチームで働くか、外注に出すかの違いと同じだ」 ——
references/orchestrator-template.mdより意訳
パターンはPipeline / Fan-out/Fan-in / Expert Pool / Producer-Reviewer / Supervisor / Hierarchical Delegationの6種
実行モードはAgent Teams（協調）とSubagents（独立）の2種
Harnessはタスクの性質から両者を自動で選択し、適切な規模のチームを構成する
実践：プロンプト例とチーム生成の流れ
Harnessの使い方はシンプルで、Claude Codeに自然言語のプロンプトを投げるだけだ。READMEに掲載されている代表例を見ていこう。
コードレビュー（Fan-out/Fan-inパターン）
Build a harness for comprehensive code review. I want parallel agents
checking architecture, security vulnerabilities, performance bottlenecks,
and code style — then merging all findings into a single report.
このプロンプトを与えると、Harnessは以下のような4ワーカー＋1アグリゲーター構成のチームを生成する。
コードレビュー統括"] --> A["Agent 1
アーキテクチャ分析"] S --> B["Agent 2
セキュリティ脆弱性チェック"] S --> C["Agent 3
パフォーマンス分析"] S --> D["Agent 4
コードスタイル検査"] A --> R["Aggregator
レポート統合"] B --> R C --> R D --> R style S fill:#E74C3C,color:#fff style R fill:#2ECC71,color:#fff
生成されるエージェント定義はYAMLフロントマター付きMarkdownで、たとえばagents/security-reviewer.mdは次のような形になる（references/team-examples.mdの例を簡約）。
---
name: security-reviewer
description: セキュリティ脆弱性（SQLi/XSS/認証バイパス）を専門にレビューする
allowed-tools: Read, Grep, Bash(git diff *)
model: sonnet
---
## 役割
コードからOWASP Top 10相当の脆弱性を検出し、重要度（Critical/High/Medium/Low）を添えて報告する。
## 手順
1. 変更差分を `git diff` で取得
2. 入力バリデーション・権限チェック・暗号化処理を重点確認
3. 発見した脆弱性を Markdown 表で列挙し、Aggregator に送る
その他のユースケース
READMEには8つのプロンプトテンプレートが用意されている。実案件で選びやすい代表的なものを挙げる。
- Deep Research — Web検索・学術論文・コミュニティ意見を並列収集し、クロスバリデーションを経てレポート化
- フルスタックWeb開発 — デザイン→フロントエンド→バックエンド→QAをPipelineパターンで連結
- 技術ドキュメント生成 — APIエンドポイント分析→説明文生成→使用例作成→完全性レビュー
- データパイプライン設計 — スキーマ設計→ETLロジック→バリデーション→モニタリングを階層委譲
MCPサーバーの作り方ガイドと組み合わせれば、Harnessが生成したエージェントに外部API接続を持たせられる。Harnessがチーム編成とワークフローを、MCPが外部データの取り込みを担当する構図だ。Skillsが「専門知識」、MCPが「外部接続」、Harnessが「編成設計」という3層で役割分担するとイメージしやすい。
「何を作るか」だけでなく「誰がチェックするか」「どう統合するか」まで1行に織り込むと、Harnessがパターン選択を誤らない。例: "with parallel security and performance reviewers, then a final aggregator report" のように、検証フェーズを明示するとFan-out/Fan-inパターンが確実に選択される。
Harnessの起動は自然言語のプロンプト1行——生成物はAgent Teams互換のMarkdown
READMEには8つのテンプレート（コードレビュー、ディープリサーチ、フルスタック、ETL等）
MCPと組み合わせれば「編成（Harness）＋知識（Skills）＋接続（MCP）」の三層構成が完成
A/Bテストで実証された品質改善効果
Harnessの開発元revfactoryは、claude-code-harnessリポジトリで15種類のソフトウェアエンジニアリングタスクを対象にA/Bテストを公開している。同じプロンプトを「Harnessあり／なし」で実行し、出力のコード品質を比較した実験だ。
| 指標 | Harness未使用 | Harness使用 | 改善幅 |
|---|---|---|---|
| 平均品質スコア | 49.5 | 79.3 | +60% |
| 勝率 | — | — | 15戦15勝 |
| 出力のばらつき | — | — | -32% |
特筆すべきは、タスクの難易度が上がるほど改善幅が大きい点だ。単純な処理では差が小さいが、複数観点の検討が必要な難しいタスクほど、チーム構成による分業のメリットが利いてくる。
- Basic: +23.8ポイント
- Advanced: +29.6ポイント
- Expert: +36.2ポイント
単純タスク"] -->|"+23.8"| B["差は比較的小さい"] C["Advanced
中規模タスク"] -->|"+29.6"| D["差が顕著"] E["Expert
複雑タスク"] -->|"+36.2"| F["差が最大化"] style A fill:#B7E1CD style C fill:#F9CB9C style E fill:#F4B183
これはForgeCodeのようなAIコーディングツールを単体で使う場合との対比として興味深い。単体エージェントは「速くて軽い」が、複雑タスクでは一人で全てを負うため抜け漏れが出やすい。Harnessは編成の力で抜け漏れを補う——同じモデルでも役割分担で成果が変わることを、A/Bテストが示している。
ばらつきが32%減る意味
実務で効いてくるのは、平均値の改善よりも「出力のばらつきが-32%」という事実かもしれない。マルチエージェント構成は結果のブレを吸収する機構として働き、プロンプトの書き方や日による揺らぎを平準化する。チーム開発では「再現性」が機能そのものと同じくらい重視されるため、この効果は大きい。
15タスクのA/Bテストで平均品質+60%、15戦全勝の実績
タスクが難しいほど改善幅が大きい（Basic +23.8、Advanced +29.6、Expert +36.2）
出力のばらつきが-32%——マルチエージェントは再現性にも効く
Harnessが向いているケースとそうでないケース
Harnessは万能ではなく、向き不向きがある。どんなタスクで効き、どんなタスクでは過剰になるかを整理する。
| 場面 | Harnessが向くか | 理由 |
|---|---|---|
| 単発のバグ修正 | × | 編成コストが上回る。単体エージェントの方が速い |
| 小規模リファクタリング | × | 同上 |
| コードレビュー（多観点） | ◎ | Fan-out/Fan-inで観点を並列化 |
| ドキュメント生成＋レビュー | ◎ | Producer-Reviewerで品質担保 |
| フルスタックWeb開発 | ◎ | Pipelineで工程を分業 |
| 大規模システム設計 | ◎ | Hierarchical Delegationで階層委譲 |
| ディープリサーチ | ◎ | 並列収集＋統合に強い |
単体のコーディングタスク（バグ修正、小規模リファクタリング、1ファイル修正など）にはOpenHandsのような単体エージェントの方が適している。Harnessの強みは「複数観点の同時チェック」「工程が多段」「抜け漏れが許されない」タスクで発揮される。
コスト面の考慮
マルチエージェント構成はトークン消費が増える。Harness使用時は単体実行の2〜4倍のトークンが消費されることもある。そのため、以下のような使い分けが実務的だ。
- 日常の小タスク → 単体エージェント
- マージ前の最終レビュー → Harnessの Fan-out/Fan-in
- 新機能の設計フェーズ → Harnessの Hierarchical Delegation
・タスクに複数の独立した観点が含まれるか
・工程が多段で、前工程の成果が次工程の入力になるか
・抜け漏れの許容度が低く、再現性が重要か
これらに1つでも該当するならHarnessの導入価値は高い。単発・単観点のタスクなら単体エージェントで十分だ。
Harnessの強みは「複数観点」「多段工程」「抜け漏れ厳禁」なタスク
単発バグ修正など軽い作業は単体エージェントの方が速くて安い
コスト面ではトークン消費2〜4倍を覚悟してマージ前レビュー等に絞ると費用対効果が高い
Harnessの位置づけ：Claude Code拡張の中で何をするか
Claude Codeには複数の拡張プリミティブがあり、それぞれ役割が異なる。Harnessがどの層に属するかを整理する。
Claude Codeの拡張プリミティブと Harness の位置関係：
┌────────────────┬────────────────┬────────────────────────┐
│ プリミティブ │ 役割 │ Harness との関係 │
├────────────────┼────────────────┼────────────────────────┤
│ CLAUDE.md │ 常時コンテキスト │ Harness生成物の前提 │
│ スキル │ 手順・専門知識 │ Harnessが生成する │
│ エージェント │ 独立した専門家 │ Harnessが生成する │
│ フック │ ツール自動前後処理│ Harness生成物に組み込む可 │
│ MCPサーバー │ 外部接続 │ Harness生成物に接続可能 │
└────────────────┴────────────────┴────────────────────────┘
Harnessは単独で何かをするわけではなく、スキルとエージェント定義を生成して他のプリミティブと繋ぐ「接着剤」だ。CLAUDE.mdに書かれたプロジェクトルール、MCPで接続された外部API、フックで自動化された前後処理——これらを適切なエージェントに割り当てて、チームとして動かすのがHarnessの仕事と言える。
なぜ「自動生成」にする必要があったのか
手でエージェント定義を書こうとすると、以下のような課題にぶつかる。
- パターン選定が難しい — Fan-outかHierarchicalか、判断基準が曖昧
- 役割定義が重複する — エージェント間の守備範囲が被りやすい
- オーケストレーションが複雑 — メッセージのやり取りルールを設計するのが面倒
- スキルとの整合が取れない — 各エージェントのスキル一覧がバラバラになる
Harnessはこれらをまとめて解決する「設計の自動化」そのものだ。プロンプト1行で、パターン選定・役割定義・オーケストレーション・スキル整合を同時に満たす雛形が手に入る。もちろん生成された定義は編集可能なので、雛形を土台に自分のプロジェクトへ最適化していける。
HarnessはCLAUDE.md・スキル・エージェント・フック・MCPを「繋ぐ接着剤」
手書きで組むと詰まる4つの課題（パターン選定・役割重複・オーケストレーション・スキル整合）をまとめて自動化
生成物はMarkdownなので編集可能——雛形を土台に自分仕様に寄せていける
📌 まとめ
Harnessは、Claude CodeのAgent Teams機能を使い倒したい開発者に向いた「チーム設計の自動化ツール」だ。GitHub Stars 2,400超・Fork 350超という規模は、Claude Codeプラグインとして最大級の支持を集めていることを示している。
要点を振り返る。
- 立ち位置: エージェント定義とスキルを自動生成する「メタスキル」
- 導入: マーケットプレイス / グローバルコピー / ローカルコピーの3通り
- パターン: Pipeline、Fan-out/Fan-in、Expert Pool、Producer-Reviewer、Supervisor、Hierarchical Delegationの6種
- モード: Agent Teams（協調）／Subagents（独立）を自動選択
- 実績: A/Bテスト15戦全勝、平均品質+60%、ばらつき-32%
- 得意領域: 多観点レビュー、多段工程、設計タスク、ディープリサーチ
「エージェントを1人で作り込むのではなく、チームを編成する方向に舵を切れ」——Harnessが示す設計思想だ。
Apache 2.0ライセンスで公開されており商用利用も可能。Agent Teams前提の開発を始めるなら、まずは/plugin marketplace add revfactory/harnessで試し、READMEのプロンプトテンプレートを1つ動かしてみてほしい。生成された.claude/agents/と.claude/skills/を覗けば、マルチエージェント設計のベストプラクティスがそのまま教材になる。
