本文へ移動
cccskills
無料GitHub で公開

multi-agent-orchestration

Agent tool で複数のサブエージェントを並列起動する/エージェントチームを組成する前に、編成パターン(サブエージェント vs エージェントチーム、レビュアー Teammate の要否、各役割のモデル選択)を決定するためのガイドを適用する。

トリガー:3 つ以上の Agent を並列起動する/タスク間に依存関係がある/チームメイト同士の相互通信が必要/設計や計画フェーズで複数視点が欲しい/ある成果物を別の成果物がレビュー・参照する構造になる。単発のサブエージェント呼び出しや、依存のない fire-and-forget な並列調査では発火しない。

インストール方法を見る

含まれるファイル(1)

  • SKILL.md6.1 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

マルチエージェント編成パターン

Agent tool で非自明な並列・チーム作業を委譲する前に、以下の 3 つの判断を済ませる。

1. サブエージェント vs エージェントチームの判定

状況採用
各タスクが独立、結果は親が統合するだけサブエージェント並列(Agent を fire-and-forget で複数起動)
タスク間に依存(A の出力が B の入力になる)エージェントチーム(TeamCreate → team_name 付き spawn)
チームメイト同士で相談・通知が発生するエージェントチーム
計画/設計フェーズで複数視点を組み合わせたいエージェントチーム

サブエージェントの限界: 親 → 子の一方向通信のみ。並列起動はできるが互いに会話できないため、依存があると「古い情報で並列実行 → 後で書き直し」になる。

エージェントチームの利点: SendMessage でチームメイト間の双方向通信が可能。TeammateIdle フックでアイドル時の振る舞いも制御できる。Plan Approval ワークフローで段階的承認も取れる。

2. レビュアー Teammate の組み込み

エージェントチームを組成する場合は、原則としてレビュアー Teammate を 1 人入れる。理由:

  • オーケストレーター(Team Lead)が「設計者かつ判定者」になるのを避ける
  • 3 冊跨ぎ・複数ファイル跨ぎの整合性は、独立した目で見たほうが取りこぼしが少ない
  • メンタリングで自分自身が教えてきた「ガードレール 3 層」「Devil's Advocate」の実践

レビュアーの設計

1 人のレビュアー Teammate に 2 フェーズ で実行させる:

  1. 整合性チェック: 既存方針(DESIGN.md / CLAUDE.md / その他規約)との齟齬、章番号・誘導リンク・命名の矛盾
  2. Devil's Advocate: 「本当にその追加が必要か」「読者像/スコープから外れていないか」「既存で代替できないか」を逆張りで問う

レビュアーを 2 人に分けると視点がブレるので、1 人 2 フェーズが推奨。

レビュアーを省略してよい場合

  • 出力が小規模(1 ファイルの単純編集など)
  • 不可逆的な影響がない(ドラフトレベル)
  • ユーザーが明示的に「レビュー不要」と言っている

3. 役割別モデル選択

役割モデル根拠
計画・設計・章立て・判断Opusトレードオフ評価、整合性判断、抽象化が必要
実装・調査・整理Sonnet速度重視、決められた手順の実行
単純な変換・抽出・コピペHaikuコスト最適化
レビュアー TeammateOpus(原則)視点を持って判定するため

model パラメータは明示する。省略すると agent definition の frontmatter or 親から継承で意図と異なるモデルになる可能性がある。

実行フロー(典型例)

依存ありのチーム作業の場合:

  1. TeamCreate でチームを作る(名前は作業内容を表す、例: book-update-team)
  2. 第 1 段の Teammate を Opus で spawn(team_name + name 付き)
  3. 第 1 段完了 → 結果を見て第 2 段の Teammate に SendMessage で前提を伝える
  4. 第 2 段の Teammate を並列 spawn(依存がない範囲で)
  5. 全成果物が出揃ったらレビュアー Teammate を spawn(2 フェーズで実行)
  6. レビュー結果を踏まえて元 Teammate に修正依頼を SendMessage
  7. 最終成果物を Team Lead が統合・書き込み

アンチパターン

  • 依存があるのにサブエージェント並列で済ませる: 後段が古い情報で動く
  • レビュアーなしでオーケストレーターが自己レビュー: 設計者バイアスで甘くなる
  • モデル省略で全部 Sonnet になる: 計画フェーズの判定が浅くなる
  • チームメイトに name を付けない: SendMessage で再開できず、毎回 Agent 新規起動になる
  • 作業中にチームを跨いで指示を出す: team_name を省略すると現在のチーム context に入る — 意図しないチームに紛れ込ませない

エフォートレベル別の適用範囲

現在のエフォートレベル: !echo ${CLAUDE_EFFORT:-high}

  • low: 編成パターンの判定のみ(レビュアーの追加は省略)
  • medium: 標準的な編成判定+レビュアーの組み込み
  • high/xhigh/max: 全ステップを完全実行(Devil's Advocate フェーズ含む)

注意事項

  • このスキルは「編成パターンの決定」だけを担う。実装の詳細(具体的な SendMessage の中身や Agent への prompt)は呼び出し側のロジックに任せる
  • CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 が有効な環境を前提とする。無効な環境ではエージェントチーム機能は使えないため、サブエージェント並列にフォールバックする
  • 判定に迷ったらユーザーに確認する。特に「レビュアーを入れるか省略するか」はコスト感が出るので相談したほうが良い場面がある

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

auto-fix-pr

無料日本語概要

pr-auto-fix プラグインの監視ループを起動するトリガースキル。Hook で PR 作成が検知された後、Claude が `pr-auto-fix:auto-fix-pr` として呼び出すと Monitor (`pr-auto-fix-watcher`) がバックグラウンドで起動する。Monitor からの通知を受けて pr-auto-fixer エージェントへディスパッチする責務を持つ。ユーザーが手動で起動するスキルではなく、Hook 経由でのみ呼ばれる前提。

honeststack/claudecode-marketplace62026年7月23日 更新

creating-plugins

無料日本語概要

Claude Codeマーケットプレイス用のプラグインを作成する。新規プラグイン作成、コマンド・エージェント・フック・MCPサーバーの追加時に使用。

honeststack/claudecode-marketplace62026年7月23日 更新

writing-style

無料日本語概要

ユーザー本人の声で日本語のプローズを起草・推敲・レビューする際に文体ガイドを適用する。対象は Qiita/Zenn 技術記事、note 記事、Slack メッセージ下書き、ユーザーが書く PR/コードレビューコメント、その他ユーザー名義で外部に出る日本語の長文。基本トーン・句読点ルール・用語表記・禁止表現(em ダッシュ「——」、「刺さる/効く」、「リポ」略称など)・シチュエーション別温度感を読み込んだ上で文章を組み立てる。コード・ログ・コミットメッセージの定型文、および他者が書いた文章のレビュー(他人の PR コメントの校正など)には適用しない。

honeststack/claudecode-marketplace62026年7月23日 更新

honeststack のスキルをすべて見る

このスキルの問題を報告する