独自のエージェントチームを構築する

これまで、エージェントの作成（第9章）、スキルの記述（第10章）を学び、ハーネス全体の構造を理解しました（第3〜4章）。この章では、これらすべての要素をひとつに束ねて独自のエージェントチームを構成する方法を学びます。team-builderスキルがどのように要件を収集し、ベンチマークし、提案書を生成するのかを段階的に見ていき、実際にClaudeへチーム構成を依頼してみましょう。

なぜエージェントチームが必要なのか？

実務シナリオ

AIエージェントはさまざまな分野で活用されています。各分野の特性に合わせてエージェントを組み合わせれば、はるかに強力なシステムを作れます。いくつかの実務シナリオを見ていきましょう。

単一AIの限界

単一のAIアシスタントでも多くの作業はできます。しかし複雑なプロジェクトでは単一AIの限界が明白になります。

• 役割分離の難しさ — ひとつのAIが企画・執筆・レビューをすべて行うと、各役割の品質が落ちます。「自分の文章を自分でレビューする」のは偏りが生じかねません。
• 専門性の不足 — セキュリティチェック、ドキュメント品質レビュー、効果分析など、各分野の専門知識を要する作業は、専門エージェントの方がうまくこなせます。
• 拡張性 — プロジェクトが大きくなると、単一AIは作業を順次処理しなければならず時間がかかります。チーム構成なら並列処理が可能になります。

エージェントチームの利点

複数の専門エージェントが協力すれば、次のような利点が得られます。

• 役割分担 — 各エージェントが自分の専門分野だけに集中するため、成果物の品質が高まります。
• 品質ゲート — 執筆エージェントとレビューエージェントが分離しているため、客観的な品質レビューが可能です。
• 再利用性 — スキルは複数のエージェントで共有できるため、重複作業を減らし一貫した結果を得られます。
• 並列処理 — 独立した作業は同時に実行できるため、プロジェクト全体の所要時間が短縮されます。

team-builderスキルの紹介

team-builderとは？

team-builderは、プロジェクトの目的と要件に合ったカスタムエージェントチームを構成するスキルです。ユーザーとのインタビューで要件を収集し、Web検索で業界のベンチマークを参照し、既存チームの状態を診断したうえで、最適なチーム構成を提案します。

このスキルは二つのレイヤーで構成されます。

• AIレイヤー（Steps 1〜5） — Claude（AI）が直接実行するステップです。要件インタビュー、ベンチマーク、診断、提案書の生成、ユーザー承認ゲートを含みます。
• スクリプトレイヤー（Steps 6〜14） — ユーザーが承認した提案書JSONをもとに、bun scripts/team-builder.tsスクリプトがエージェントファイルを自動生成し、システムに登録します。

なぜ二層なのか？

「すべての作業をAIに任せればよいのではないか」と思うかもしれません。その答えは信頼性と責任の所在にあります。

• AIが得意なこと — 意図の理解、リサーチの実施、トレードオフの評価、創造的な提案の生成です。Step 1〜4はまさにこれらの強みを活かします。
• スクリプトが得意なこと — 決定論的なファイル操作です。ディレクトリの作成、正確な書式でのファイル書き込み、相互参照される複数ドキュメントの同時更新、毎回一貫した結果の出力が該当します。Step 6〜14にはまさにこの信頼性が必要です。
• ユーザーがゲートになる — Step 5で、ユーザーの同意なしには一切の変更が起きないことを保証します。これにより、AIが誤ってエージェントを削除したり、ハンドオフチェーンを切断したり、ガバナンス文書を不整合にしたりする事故を防げます。

既存システムの4つのチーム構成パターン

co-consultシステムには、すでに検証済みの4つのチーム構成パターンが存在します。team-builderはこれらのパターンを参考にして、新しいチームを提案します。

AIレイヤー5ステップワークフロー

AIレイヤーは次の5段階で進みます。各ステップを順番にたどりながら、Claudeがユーザーと対話しながら最適なチーム構成を提案します。

Step 1: 要件インタビュー

最初のステップで、Claudeはユーザーに6つの必須質問を行います。これらの質問への回答がチーム構成の基準となります。

Step 2: ベンチマーク

要件が確認されると、ClaudeはWeb検索によって業界の標準的なチーム構成を調べます。権威ある情報源（McKinsey、BCG、Gartner、Forresterなど）を最低2つ以上参照し、各参照チーム構成の適合度を1〜5点の尺度で評価します。

• 情報源の信頼性検証（直近5年以内、公式ドメイン）
• 参照チームの役割、階層構造、強み/弱みの分析
• ユーザー要件との適合度スコアの算出

Step 3: 現在のチーム診断

ベンチマーク結果をもとに、Claudeは既存チームの状態を診断します。現在のプロジェクトにすでに存在するエージェント、スキル、依存関係を把握し、不要な重複を避けるとともに既存の資産を最大限活用します。

• エージェントインベントリ — 既存agents/*.mdファイルの一覧と状態
• スキルインベントリ — 既存skills/*/SKILL.mdファイルの一覧とオーナー
• 依存関係マップ — エージェント間のハンドオフ関係、スキル所有関係
• スキル移譲計画 — 削除されるエージェントのスキルを他のエージェントへ移譲する計画

Step 4: 提案書の生成

診断結果とベンチマークを総合して、Claudeは構造化された提案書を生成します。提案書には、チーム比較表、エージェント変更内容、スキル変更計画、ワークフロー設計、ベンチマークの根拠が含まれます。

Step 5: ユーザー承認 (MANDATORY GATE)

提案書が完成すると、Claudeはユーザーに提案書全体を示して明示的な承認を求めます。このステップは必須ゲート(Mandatory Gate)であるため、ユーザーが“approve”と明示的に答えるまで次のステップには進みません。

提案書の形式

提案書JSONの構造

team-builderが生成する提案書はJSON形式で保存されます。このJSONはスクリプトレイヤー（bun scripts/team-builder.ts）の入力として使われます。提案書の主なフィールドは次のとおりです。

提案書JSONの例

次は提案書JSONを簡略化した例です。

{
  "version": "1.0.0",
  "timestamp": "2026-08-10T14:30:00Z",
  "teamName": "digital-marketing",
  "benchmarkSources": [
    "https://www.mckinsey.com/.../marketing-operations"
  ],
  "changes": {
    "agentsToCreate": [
      {
        "name": "content-strategist",
        "formalName": "Content Strategist",
        "tier": { "claude": "medium" },
        "description": "Plans and outlines content strategy",
        "phases": ["1", "2"],
        "requiredSkills": ["research", "seo-analysis"],
        "rationale": "ベンチマークより：コンテンツ戦略の役割は必須"
      }
    ],
    "agentsToDelete": [],
    "skillsToCreate": [
      {
        "name": "seo-analysis",
        "owner": "content-strategist",
        "description": "Performs SEO keyword and trend analysis"
      }
    ],
    "workflowPhases": [
      { "phase": 0, "name": "Initiation", "lead": "pm" },
      { "phase": 1, "name": "Research", "lead": "content-strategist" }
    ]
  },
  "approvedBy": "user",
  "approvedAt": "2026-08-10T15:00:00Z"
}

トップレベルフィールド

提案書JSONのトップレベルフィールドは、メタデータフィールドとchangesオブジェクト内の変更配列に分かれます。

ワークフローフェーズエントリ

workflowPhases配列は、プロジェクトライフサイクル全体を通じてエージェントがどう協力するかを定義します:

{
  "phase": 0,
  "name": "Project Initiation",
  "lead": "engagement-leader",
  "supporting": ["strategy-analyst"]
}

各フェーズは、オーケストレーションを担うリードエージェント(lead)と、任意で貢献するサポートエージェント(supporting)を指定します。この構造は前章で見たAGENTS.mdのディスパッチテーブルと直接対応します。

スキル再割り当てエントリ

エージェントを削除するときは、そのエージェントが所有するスキルを必ず残存エージェントへ移譲しなければなりません。提案書はこの内容を次のように記録します:

{
  "skill": "research",
  "fromOwner": "old-analyst",
  "toOwner": "strategy-analyst"
}

これにより、エージェントが削除されても孤立するスキルが発生しません。Step 3の事前スキル移譲計画により、削除が行われる前にすべてのスキルが有効なオーナーを持つことが保証されます。

スクリプトレイヤー

提案書JSONから実際のファイルへ

ユーザーがStep 5で提案書を承認すると、Claudeは提案書をJSONファイルとして保存します（memory/team-builder-proposal-YYYY-MM-DD.json）。その後ユーザーがbun scripts/team-builder.tsスクリプトを実行すると、スクリプトがJSONを読み込んで次の作業を自動的に行います。

# スクリプトレイヤーの実行コマンド
bun scripts/team-builder.ts memory/team-builder-proposal-2026-08-10.json

スクリプトの動作方式

上記のコマンドでスクリプトを実行すると、提案書JSONを読み込み、決められた安全な順序に従って変更を実行し、各ステップごとにチェックポイントログを記録します:

問題が起きたらどうなるか？

スクリプトはすべてのステップでチェックポイントロギングを行います。途中でエラーが発生した場合（例: ファイルが既に存在する、権限が拒否された）、スクリプトはどのステップが失敗し、何がすでに完了したのかを正確に報告します。問題を修正してからスクリプトを再実行すると、すでに成功済みのステップはスキップされます。

既存のチーム構成パターン参考

co-consultシステムには、すでに検証済みの4つのチーム構成パターンがあります。新しいチームを構成するときにこれらのパターンを参考にすれば、素早く始められます。

パターン別エージェントロスター

各パターンを構成する実際のエージェント編成は次のとおりです。

パターン選択ガイド

状況に合ったパターンを選ぶときは、次のガイドを活用してください:

実習: 独自のエージェントチームを作る

実習の目標

今回の実習では、Claude Desktop Appで/team-builderコマンドを使って独自のカスタムエージェントチームを構成してみます。関心のある分野を選び、要件を準備して、Claudeにチーム構成を依頼してみましょう。

実習のステップ

プロンプトの例

/team-builder

教育コンテンツ制作のためのエージェントチームを構成したいと思っています。

1. ドメイン: オンライン教育コンテンツ制作
2. チーム規模: 4〜5個のエージェント
3. 主要業務: 講義資料の企画、スライド作成、クイズ出題、品質レビュー
4. 技術スタック: Markdown, HTML,Claude Code
5. 協業方式: 順次パイプライン (企画→執筆→レビュー→完成)
6. 成果指標: 完成度、一貫性、学習目標達成率

章のまとめ