Claude Code でサブエージェントを使い始め、便利さに気づいて数を増やしていくと、いつの間にか「誰がどのタスクを担当し、どう情報を受け渡すのか」が曖昧になっていく――そんな経験はないでしょうか。エージェント定義やスキルを一つひとつ手書きしていると、設計の一貫性を保つのが難しくなり、メンテナンスも重くなっていきます。
複数のエージェントを協働させる「Agent Teams」を本格的に組みたいと思っても、チーム構成の設計やメッセージのやり取りの定義をゼロから書き起こすのは負担が大きいものです。こうした「マルチエージェントの設計と生成を自動化したい」というニーズに応えるのが、本記事で紹介する OSS「Harness」です。
Harness は、プロジェクトの説明文を与えるだけで、Claude Code 用のエージェントチームとスキルを自動生成するメタスキルです。ただし導入を検討するうえでは、「自分のユースケースに本当に合うのか」「Agent Teams という実験的機能に依存する制約は許容できるのか」「Archon など似たツールとどう違うのか」を見極める必要があります。
本記事では、Harness の仕組み・導入方法・効果検証の読み方・類似ツールとの違いを、公式リポジトリと README をもとに整理します。最後には「向くケース・向かないケース」をまとめ、採用判断の材料を提供します。なお本記事はドキュメントベースの調査であり、実際のインストールや動作検証は行っていません。記載内容は公式情報の引用と整理に基づきます。
Harnessとは何か（Claude Codeのエージェントチームを自動設計するOSS）
最初に押さえておきたいのは、本記事で扱う「Harness」が何を指すかです。
Harnessの一言まとめとharness.ioとの違い
Harness（revfactory/harness）は、一言でいえば「ドメインの説明文から、Claude Code のエージェントチーム（.claude/agents/）と、そのエージェントが使うスキル（.claude/skills/）を自動生成するメタスキル」です。公式 README では自らを「チームアーキテクチャ・ファクトリー（Team-Architecture Factory）」と位置づけています。つまり「ハーネス（個別のエージェント編成）そのもの」ではなく、「ハーネスを生成する側」のツールという主張です。
ここで注意したいのが名前の混同です。「Harness」という語で検索すると、CI/CD やソフトウェアデリバリープラットフォームの harness.io がヒットすることが多いですが、本記事で扱う Harness はそれとはまったくの別物です。こちらは Claude Code 専用のプラグイン（スキル）であり、商用の CI/CD 製品とは無関係です。導入を検討する前に、まずこの点を取り違えていないか確認しておくと安心です。
Harness の起動は自然言語で行います。「Build a harness for this project」「ハーネスを構成して」といったフレーズを Claude Code に伝えると、ドメイン分析からチーム設計・生成までが走ります。README は英語・韓国語・日本語の3言語が用意されており、日本語版はREADME_JA.mdから読めます。プロダクトの全体像を視覚的に確認したい場合は公式LP（GitHub Pages）も参考になります。
リポジトリ基本情報（スター数・ライセンス・更新状況）
採用を検討するうえでは、プロジェクトが健全に維持されているかという「メンテナンスの健全性シグナル」も重要な判断材料です。公式リポジトリの基本情報を整理すると次のとおりです。
項目 | 値 |
|---|---|
owner/name | revfactory/harness |
スター数 | 6,074 |
フォーク数 | 814 |
ライセンス | Apache-2.0 |
バージョン | 1.2.0 |
主要言語 | HTML（公式LP 同梱のため。本体はスキル定義の Markdown） |
最終更新 | 2026年5月29日 |
主要言語が「HTML」と表示されるのは、公式 LP（GitHub Pages）をリポジトリに同梱しているためです。Harness 本体の実体は実行可能なプログラムではなく、Claude Code プラグインとしての Markdown スキル定義（skills/harness/SKILL.md と参照ドキュメント群）であることを覚えておくとよいでしょう。
このリポジトリはアーカイブされておらず、また他リポジトリのフォークでもない、オリジナルかつ現役のプロジェクトです。ライセンスは Apache-2.0 で、商用利用も含めて広く使える点は安心材料です。スター数 6,000 超・直近の更新も活発であり、メンテナンスは現時点で健全と言える状態です。
Harnessが解決する課題（サブエージェント手書きの限界）
Harness が「誰のどんな困りごと」に刺さるツールなのかを、ここで整理します。自分の状況と照らし合わせてみてください。
サブエージェント運用で起きがちな設計破綻
Claude Code のサブエージェントは、特定のタスクに特化した小さな担当者を増やせる便利な仕組みです。しかし運用を続けるうちに、次のような問題が出てきがちです。
- エージェントが増えるほど「どのタスクを誰に振るか」の判断が複雑になる
- エージェント間でどう情報を受け渡すか（入出力の取り決め）が場当たり的になる
- 同じようなスキルを複数のエージェントに重複して書いてしまう
- プロジェクトが進むにつれ、定義したエージェント・スキルと実態がずれていく（drift）
要するに、エージェントを「個別に」増やすことはできても、「チームとして」協働させる設計は人手で維持するのが難しいのです。Harness は、この「チーム設計＋スキル生成」をまとめて自動化することで、この負担を肩代わりする位置づけにあります。
Agent Teamsとサブエージェントの違い（Harnessが既定でAgent Teamsを選ぶ理由）
Harness を理解するうえで欠かせないのが、Claude Code の「Agent Teams」と従来の「サブエージェント」の違いです。
ざっくり言えば、サブエージェントは「親エージェントが個別の作業者を呼び出して結果を受け取る」形に近く、エージェント同士が直接やり取りすることは想定していません。一方の Agent Teams は、複数のエージェントが相互にメッセージを送り合い、タスクを作り合いながらチームとして自己調整して進む仕組みです。Agent Teams の詳細はClaude Code 公式ドキュメントにまとまっています。
Harness が既定で Agent Teams を選ぶのは、まさに「2体以上のエージェントが本格的に協働する」ケースを主眼に置いているためです。単発タスクをこなすだけなら従来のサブエージェントで十分ですが、複数の専門家が役割分担しながら一つの成果物を作り上げるような場面では、チームとして調整し合える Agent Teams の方が適しています。Harness はこの Agent Teams 前提のチームを設計・生成してくれるわけです。
ただし後述するとおり、Agent Teams は現時点で実験的機能です。この前提が自分の環境で許容できるかは、導入判断の分かれ目になります。
Harnessの仕組み（6つのチーム設計パターンと6フェーズ）
Harness を「ブラックボックスのまま入れる」のは不安が残ります。ここでは「何が生成され、どう動くのか」を具体的に見ていきます。
6つのチームアーキテクチャパターン
Harness は、ドメインに応じて適切な「チームの形」を選んで生成します。README では次の6つのアーキテクチャパターンが定義されています。
パターン | 概要 | 向いているタスク |
|---|---|---|
Pipeline | 順序依存のあるタスクを直列に流す | 工程が一本道で決まっている処理 |
Fan-out/Fan-in | 独立した並列タスクを分散して実行し、結果を集約する | 並列化できる作業の一括処理 |
Expert Pool | 文脈に応じて専門エージェントを選択的に呼び出す | 多様な専門領域をまたぐ作業 |
Producer-Reviewer | 生成役とレビュー役の2段構えで品質を担保する | 品質チェックが重要な成果物作り |
Supervisor | 中央エージェントが動的にタスクを分配する | 状況に応じた柔軟な割り振りが必要な作業 |
Hierarchical Delegation | トップダウンで再帰的に委任する | 大きなタスクを階層的に分割する作業 |
これらは自分のプロジェクトに合わせて手で設計してもよいものですが、定石としてのパターンを Harness が状況に応じて当てはめてくれる点が、手書きとの大きな違いです。
6フェーズのワークフロー（生成物は .claude/agents/ と .claude/skills/）
Harness が起動すると、README で定義された6つのフェーズに沿ってチームを生成します。
Phase 1: Domain Analysis（ドメイン分析）
Phase 2: Team Architecture Design（チーム設計：Agent Teams か Subagents かを選択）
Phase 3: Agent Definition Generation（.claude/agents/ の生成）
Phase 4: Skill Generation（.claude/skills/ の生成）
Phase 5: Integration & Orchestration（統合・オーケストレーション）
Phase 6: Validation & Testing（検証・テスト）
最終的に生成されるのは、.claude/agents/ 配下のエージェント定義（役割・原則・入出力プロトコル・チーム間の通信契約を含む Markdown）と、.claude/skills/ 配下のスキルです。つまり Harness は、Claude Code がそのまま読み込んで使えるファイル群を吐き出してくれます。
「一度作って終わり」ではない設計（Phase 0 の現況監査）
Harness の本体ロジックを定義する SKILL.md には、上記の6フェーズに先立つ「Phase 0（現況監査・drift 検知）」も組み込まれています。Phase 0 では既存の .claude/agents/・.claude/skills/・CLAUDE.md を読み込み、すでにあるハーネスと実態の不整合（drift）を検知したうえで、「新規構築」「既存拡張」「運用保守」の3モードに分岐します。
これは、一度生成したチーム構成を作りっぱなしにせず、プロジェクトの成長に合わせて継続的に更新していける設計になっていることを意味します。エージェント定義が実態とずれていく問題に正面から向き合っている点は、長く使ううえでの安心材料といえるでしょう。なお SKILL.md 自体は韓国語で記述されています。
実行モードは3種類（既定は Agent Teams）
Harness が生成・実行するチームには、3つの実行モードがあります。
モード | 説明 | 推奨ケース |
|---|---|---|
Agent Teams（既定） | エージェントが相互にメッセージを送り合い、タスクを作り合ってチームとして自己調整する | 2体以上の協働が必要なとき |
Subagents | Agent ツールを直接呼び出す | 単発タスクで、エージェント間の通信が不要なとき |
Hybrid | フェーズごとにチームとサブエージェントを使い分ける | フェーズごとに特性が異なるとき |
既定の Agent Teams は実験的機能であり、利用には次のセクションで触れる前提条件があります。「単発タスク中心なので Subagents で十分」というケースもあるため、自分の使い方に照らしてモードを選ぶとよいでしょう。
導入方法と使い方（プラグイン導入とトリガー）
ここでは、実際に導入する場合の最初の一歩と、見落としやすい前提条件を整理します。
インストール（Marketplace / グローバルスキル）
Harness は2通りの方法で導入できます。README からの抜粋は次のとおりです。まず Marketplace 経由でマーケットプレイスを追加し、プラグインをインストールします。
/plugin marketplace add revfactory/harness
/plugin install harness-marketplace
グローバルスキルとして直接配置する場合は、skills ディレクトリを ~/.claude/skills/ 配下にコピーします。
# skillsディレクトリを ~/.claude/skills/harness/ にコピー
cp -r skills/harness ~/.claude/skills/harness
Marketplace 経由なら Claude Code 内のコマンドだけで完結します。複数のプロジェクトで横断的に使いたい場合は、グローバルスキルとして ~/.claude/skills/ に配置する方法が便利です。
トリガー語と代表ユースケース
導入後は、自然言語で Harness を呼び出せます。「Build a harness for this project」「ハーネスを構成して」といったフレーズが代表的なトリガーです。
README で挙げられている代表的なユースケースには、ディープリサーチ（調査タスクの分担）、フルスタック Web 開発、コードレビュー、API ドキュメント生成、データパイプライン設計などがあります。いずれも「複数の専門役割が協働すると効果が出やすいタスク」であり、ここに Harness のチーム生成が活きてきます。
前提条件（Agent Teams 実験フラグ）
導入ハードルとして必ず押さえておきたいのが、既定の Agent Teams モードを使うには実験的機能の有効化が必要だという点です。具体的には、環境変数 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 を設定して Agent Teams を有効にする必要があります（Claude Code 公式ドキュメント）。
実験的機能であるということは、仕様が今後変わる可能性や、本番運用での挙動に未知数の部分が残ることを意味します。「実験フラグを有効化できない／したくない」環境では、Harness の本領である Agent Teams モードをそのまま使うのは難しく、この制約を許容できるかが採用判断の重要なポイントになります。
効果はどれくらいか（A/B検証結果とその読み方）
「実際に効果があるのか」は誰もが気になるところです。ここは数値の扱いに注意が必要なので、出典の注記も含めて誠実に整理します。
Harness の README では、姉妹リポジトリ revfactory/claude-code-harness で実施した A/B 実験の結果が紹介されています。15 タスクを対象にした実験で、平均品質スコアが 49.5 から 79.3 へと約 60% 向上し、勝率は 15 戦 15 勝、出力の分散は約 32% 減少したとされています。タスクの難度が上がるほど効果が大きくなる傾向も報告されています。
ただし、この数値をそのまま鵜呑みにするのは禁物です。README 自身が「n=15（サンプル15件）・著者自身による A/B 測定であり、第三者による再現は進行中（third-party replication pending）」と明記しています。 つまり現時点では、著者の自己測定という性格を持つデータです。本記事もこの注記をそのまま引き継ぎ、過度な期待を煽らないようにしておきます。
著者自身も「2〜4週間の社内パイロットで自前の数値を測る」ことを推奨しています。導入を検討するなら、公開数値を判断材料の一つとしつつ、最終的には自分のプロジェクトで小さく試して効果を確かめるのが現実的な進め方です。
類似ツールとの違い（Archon・wshobson/agentsとの使い分け）
「結局どれを選べばいいのか」「併用すべきか」という、最も切実な選定判断に答えます。Harness の README には、近接するレイヤーのツールを整理した "Coexistence"（共存）セクションがあり、これを一次情報として差分を整理します。
Archonとの違い（チーム設計 vs ランタイム決定論）
coleam00/Archon は、YAML でワークフロー（計画→実装→検証→レビュー→PR）を定義し、AI コーディングを決定論的・再現可能にするランタイム設定のファクトリーです。
Harness と Archon は同じレイヤー（L3）に位置づけられますが、担当するサブレイヤーが異なります。Archon が解決するのは「ランタイムの決定論」、つまり「同じ手順を再現可能に回す」ことです。対して Harness が解決するのは「チームアーキテクチャの設計」、つまり「誰がどう協働するかの編成を生成する」ことです。
README では両者を組み合わせられるとも整理されています。Harness でチームを設計し、Archon で決定論的なランタイムとして展開する、という使い分けが可能です。「再現性の高い手順の固定化」が最優先なら Archon が、「協働するチームの設計の自動化」が課題なら Harness が、それぞれ軸になります。
wshobson/agentsとの違い（ファクトリー vs 部品カタログ）
wshobson/agents は、すぐ使えるサブエージェント・スキルのカタログです（多数のエージェントとスキルの定義集）。
Harness と wshobson/agents の関係は「ファクトリー（生成器）↔ 部品供給（カタログ）」と整理できます。wshobson/agents は完成済みの部品を選んで使うカタログであり、Harness はチームを設計する側の生成器です。両者は対立するものではなく、wshobson/agents のエントリを Harness が生成するチームの部品として取り込む、という補完的な使い方ができます。
なお、Harness と同コンセプトで Codex 向けに移植された SaehwanPark/meta-harness というプロジェクトもあります。同じ考え方で異なるランタイムを対象にしたもので、Claude Code を使うなら Harness、Codex を使うなら meta-harness、という住み分けになります。
整理すると、Harness は「チーム設計の生成」、Archon は「ランタイムの決定論」、wshobson/agents は「部品カタログ」と、それぞれ役割が異なります。どれか一つを選ぶというより、自分の課題がどのレイヤーにあるかで選び、必要に応じて組み合わせるのが現実的です。
Harnessが向くケース・向かないケース（まとめ）
最後に、これまでの内容を「採用判断」の視点でまとめます。
Harness が向くケース
- 2体以上のエージェントを本格的に協働させ、そのチーム設計を自動化したい
- エージェント定義・スキルの手書きが負担になっており、生成を効率化したい
- Claude Code をネイティブに、深く使い込みたい
- 一度作ったチーム構成を、プロジェクトの成長に合わせて継続的に更新していきたい
見送り・併用を検討したいケース
- 単発タスク中心で、複数エージェントの協働を必要としない（従来のサブエージェントで十分）
- Agent Teams の実験フラグを有効化できない／したくない環境にある
- 手順の決定論的な再現が最優先で、チーム設計の自動化は二の次（この場合は Archon が軸になる）
- すぐ使える完成部品を集めたい（この場合は wshobson/agents のカタログが起点になる）
Harness は、スター数 6,000 超・Apache-2.0 ライセンス・直近の更新も活発で、メンテナンスの健全性という点では安心して検討できる状態にあります。一方で、本領を発揮するには Agent Teams という実験的機能への依存があり、効果を示す数値も著者自身による測定段階にとどまります。
だからこそ、いきなり全面導入するのではなく、まずは小さなプロジェクトで Agent Teams を有効化して試し、自分のユースケースで本当に効果が出るかを確かめるのが堅実な進め方です。仕組みや生成物を把握したうえで判断したい場合は、公式リポジトリと日本語 READMEを起点にすると、ここまで整理した内容を一次情報で確認できます。
