Delegation

委任 — エージェントのオーケストレーションと並列化

概要

6 つのパターンを用いて作業を並列化します。組み込みエージェント、ワークツリーで分離されたエージェント、バックグラウンドエージェント、インラインブリーフを使ったカスタムエージェント、TeamCreate によるエージェントチーム、並列タスクのディスパッチです。また、委任を 2 つの負荷に分けます。ターン数に上限を設けた軽量な単発ワーカーと、ツールを使って反復するフルエージェントです。作業が 3 つ以上の独立したワークストリームに達すると、Algorithm が自動的にこのスキルを呼び出します。

課題

独立した作業を逐次実行すると時間を無駄にしますが、すべてのタスクを重量級エージェントに任せると、さらに無駄が増えます。単発の分類にフルエージェントを起動すると、何の成果もないまま起動に 10～30 秒かかります。さらに厄介なのは、共有状態を持たない使い捨てのカスタムエージェントと、互いにメッセージを送り合い、タスクリストを共有する永続的なエージェントチームという、異なる 2 つのシステムが混同されていることです。誤ったシステムを選ぶと、単純な作業を過剰に調整するか、複雑な作業の調整が不十分になります。このスキルは、それぞれのジョブに適したパターンと負荷を割り当てます。

仕組み

作業を並列化できる場合、またはエージェントの専門性が必要な場合、Algorithm によって自動的に呼び出されます。

🚨 重要なルーティング — まったく異なる 2 つのシステム

ユーザーの発言	システム	ツール	動作
"カスタムエージェント", "専門エージェント", "エージェントを起動して", "エージェントを立ち上げて"	インラインブリーフ	Task(subagent_type="general-purpose", prompt=<inline brief: name + role + stance>)	トピックごとに異なるペルソナを記述
"エージェントチームを作成して", "エージェントチーム", "スウォーム"	Claude Code Teams	TeamCreate → TaskCreate → SendMessage	共有タスクリスト、メッセージによる調整、複数ターンの協働を行う永続的なチーム

これらは同じものではありません。

• カスタムエージェント ＝ 固有のアイデンティティを持つ単発の並列ワーカー。Task() で起動し、共有状態はありません。
• エージェントチーム ＝ 共有タスクリスト、メッセージ機能、TeamCreate による複数ターンの協働を備えた、永続的な調整型チーム

Algorithm がこのスキルを使用する場面

• Extended 以上の作業負荷で、3 つ以上の独立したワークストリームがある
• 同一で逐次実行の必要がない複数のタスクを並列実行する必要がある
• 専門的な知識（アーキテクチャ設計、実装、ISC の最適化）が必要である
• 5 つ以上のファイルにまたがる大規模なコードベースの変更を、並列ワーカーで効率化できる
• 調査と実行を同時に進められる
• 「エージェントチームを作成して」 — 永続的な調整型チームには TeamCreate を使用する
• 監査可能性が速度より重要な、無人の自律作業 — Observer チームパターン（ツールのアクティビティ監査ログを読み取り専用エージェントが監視し、続行／停止／エスカレーションに投票する）はこの用途に適していますが、現在は実装されていません。Agents スキルとともに廃止されており、使用するには独立したコンポーネントとして再構築する必要があります。

委任パターン

1. 組み込みエージェント

⚠️ 組み込みエージェントは内部ワークフローのルーティング専用です。 ユーザーがカスタム、専門的、または独自の語り口を持つエージェントを求めている場合は、エージェントごとにインラインブリーフを記述し（以下のセクション 4）、general-purpose を起動してください。

専門エージェントには、Task(subagent_type="AgentType") を使用します。

エージェントタイプ	専門分野	使用する場面
general-purpose（＋役割のブリーフ）	コード、アーキテクチャ、設計作業	プロンプトにシニアエンジニア／TDD またはシステム設計のブリーフを追加します。Engineer／Architect タイプは廃止されました。
Algorithm	ISC の最適化、基準に関する作業	ISC に特化した検証
Explore	コードベースの高速検索	ファイルやパターンの素早い発見
Plan	実装戦略	実行前の設計

必ず含める項目： 全体のコンテキスト、作業負荷の予算、期待する出力形式。

2. Worktree で分離されたエージェント

ファイルの安全な並列処理のため、isolation: "worktree" を指定して、各エージェントを独自の git worktree で実行します。

Task(subagent_type="general-purpose", isolation: "worktree", prompt="Senior engineer, TDD. ...")

• 各エージェントに独自の作業ツリーが割り当てられるため、他のエージェントとのファイル競合が発生しません
• エージェントの起動時に worktree が自動作成され、エージェントの終了時に（変更が加えられていない限り）自動削除されます
• 複数のエージェントが同じファイルを編集する場合や、複数のアプローチを比較する場合に使用します
• run_in_background: true と組み合わせることで、分離された作業をブロックせずに実行できます
• frontmatter に isolation: worktree が指定された組み込みエージェントは、起動のたびに自動的に分離されます

3. バックグラウンドエージェント

ブロックせずに並列処理するには、run_in_background: true を指定してエージェントを実行します。

Task(subagent_type="general-purpose", run_in_background: true, prompt="Senior engineer, TDD. ...")

• 結果がすぐに必要ではない場合に使用します
• 出力ファイルのパスを指定して Read ツールで出力を確認します
• 次の用途に最適です：調査、長時間のビルド、並列調査

3b. フォアグラウンドエージェント（デフォルト — パターン 3 と対比するもので、7 番目のパターンではありません）

完了するまでブロックする標準的な Task() 呼び出しです。

• 先に進む前に結果が必要な場合に使用します
• 順次実行の依存関係がある場合に使用します
• デフォルトのモードで、最も一般的です

4. カスタムエージェント（インラインブリーフ）

トリガー：「カスタムエージェント」、「エージェントを立ち上げる」、「エージェントを起動する」、「専門エージェント」 **アクション：**各エージェントに、名前、役割／専門分野、スタンスを含む個別のブリーフを作成し、Task(subagent_type="general-purpose") でそれぞれを起動します。ペルソナを作成するツールはありません。オーケストレーターがペルソナを作成します。

Task(
  subagent_type="general-purpose",
  prompt=<agent brief: "You are a skeptical security reviewer focused on auth bypass..."> + <task + context>
)

• 各エージェントに異なるブリーフを与え、実際に視点が分かれるようにします
• 能力の高いモデルは、特性を検索するよりも、トピックに特化した鋭いペルソナを作成できます
• 次の用途に最適です：分野の専門家、批判的なレビュー担当者、創造的なブレインストーミング、並列分析

5. エージェントチーム（TeamCreate を使用）

トリガー：「エージェントチームを作成する」、「エージェントチーム」、「スウォーム」、「エージェントのチーム」 アクション：TeamCreate ツール → TaskCreate → Task(team_name=...) でチームメイトを起動 → SendMessage で連携

1. TeamCreate(team_name="my-project")           # Creates team + task list
2. TaskCreate(subject="Implement auth module")   # Create team tasks
3. Task(subagent_type="general-purpose", team_name="my-project", name="auth-engineer")  # Spawn teammate (senior-engineer/TDD brief in prompt)
4. TaskUpdate(taskId="1", owner="auth-engineer") # Assign task
5. SendMessage(type="message", recipient="auth-engineer", content="...")  # Coordinate

これはカスタムエージェントとはまったく異なるシステムです：

• カスタムエージェント（インラインブリーフ）＝後から連携しない並列ワーカーで、共有状態はありません
• エージェントチーム（TeamCreate）＝共有タスクリスト、メッセージング、複数ターンに対応した、継続的に連携するチームです

チームのガイドライン：

• Extended 以上で、独立して作業できる基準が 3 つ以上ある場合に使用します
• 大規模で複雑なコーディングタスクで最も効果を発揮します
• 各チームメイトは、共有タスクリストを通じて割り当てられたタスクに独立して取り組みます
• 親エージェントは SendMessage で連携し、結果をまとめます
• チームメイトは各ターンの間に待機状態になるため、メッセージを送信して作業を再開させます

チームとサブエージェントの使い分け（判断マトリックス）

要素	サブエージェント（Task）	エージェントチーム（TeamCreate）
コミュニケーション	後から連携しない。エージェント間のメッセージングなし	チームメイト間で継続的にメッセージをやり取り
コンテキスト	起動ごとに新しいコンテキスト。ウィンドウは限定的	チームメイトごとに完全なコンテキストウィンドウがあり、ターンをまたいで保持
連携	親エージェントが結果を収集。共有状態なし	共有タスクリスト、チームメイト間の直接 DM、待機／再開サイクル
期間	1 ターンの実行	複数ターンにわたる、反復的な作業と軌道修正
オーバーヘッド	低い — 起動したらそのまま任せる	高い — チームの設定、タスクの作成、メッセージの振り分け
最適な用途	並列調査、1 回限りの分析、簡単な委任	複雑な複数ファイルの変更、反復的なデバッグ、レイヤーをまたぐ連携

**判断基準：**エージェント同士の会話や、共有作業の反復が必要な場合 → チーム。各エージェントが独立した 1 回限りの作業を行う場合 → サブエージェント。

具体例：

• 「4 つのトピックを並列で調査する」→ サブエージェント（独立しており、連携不要）
• 「共有状態を使って API + UI + テストにまたがる機能を構築する」→ チーム（複数レイヤーにまたがり、連携が必要）
• 「同じパターンで 10 個のファイルを更新する」→ サブエージェント（並列、同一パターン、独立）
• 「複雑な問題を、競合する仮説を立ててデバッグする」→ チーム（調査結果を共有し、アプローチを調整する必要がある）

6. 並列タスクのディスパッチ

同一の操作を N 回行う場合（例：同じパターンで 10 個のファイルを更新する場合）：

1. 1 つのメッセージで N 個の Task() 呼び出しを作成します（並列起動）
2. 各エージェントに 1 つの作業単位を割り当てます
3. すべて完了したら結果を収集します

作業レベルに応じたスケーリング

作業レベル	委任戦略
即時／高速	委任なし — 直接ツールのみ
標準	個別のサブタスクごとに、フォアグラウンドエージェントを最大 1～2 個
拡張	エージェント 2～4 個、調査にはバックグラウンドエージェント
高度	エージェント 4～8 個、3 つ以上のワークストリームにはエージェントチーム
深掘り	チーム全体のオーケストレーション、並列ワーカー
包括的	制限なし — チーム＋並列処理＋バックグラウンド処理

2 段階の委任（軽量と完全）

すべての委任に完全なエージェントが必要なわけではありません。タスクの複雑さに応じて、委任の規模を調整します。

軽量な委任

対象： 一度限りの抽出、分類、要約、提供されたコンテンツに基づく簡単な質疑応答。

Task(subagent_type="general-purpose", max_turns=3, prompt="...")

• モデルはディスパッチごとに判断します（model パラメーター。指定しない場合はセッションのモデルを継承します）
• max_turns=3 に設定します — 3 ターン以内に完了できない場合は、完全な委任が必要です
• すべての入力をプロンプト内に含めます（ツールの使用は想定しません）
• 例：「このテキストを X／Y／Z に分類」「ここから重要なポイントを 5 つ抽出」「これを 2 文で要約」

完全な委任

対象： 複数ステップの推論、ツールの使用が必要なタスク（ファイルの読み取り、検索、ウェブの利用）、独自の反復ループが必要なタスク。

Task(subagent_type="general-purpose", prompt="...")  # or specialized agent type

• モデルを指定しない場合は、セッションのモデルを継承します（ハーネスの動作）
• max_turns の制限はありません — エージェントは完了するまで反復します
• エージェントは自律的にツールを使用します（Read、Grep、Bash など）
• 例：「X を調査してレポートを作成」「この 5 個のファイルをリファクタリング」「テスト Y が失敗する原因をデバッグ」

判断基準

質問：「ツールを使わずに、1 回の LLM 呼び出しで回答できますか？」→ 軽量。それ以外 → 完全。

判断材料	段階
入力がプロンプトに収まり、出力が抽出／分類である	軽量
ファイルの読み取り、検索、閲覧が必要	完全
反復または自己修正が必要	完全
提供されたコンテンツの単純な変換	軽量
専門知識と調査が必要	完全

重要な理由： 一度限りの抽出に完全なエージェントを起動すると、約 10～30 秒の起動オーバーヘッドと不要なコンテキストが発生します。軽量な委任なら 2～5 秒で完了します。10 回以上の委任を行う「拡張」以上のアルゴリズム実行では、これにより数分を節約できます。RLM の llm_query() と rlm_query() の 2 段階パターンに着想を得ています（Zhang/Kraska/Khattab 2025）。

Right-Sizing ゲート（PLAN、すべてのティア）

ティアごとの委任下限は、ファンアウトの最低数を定めます。このゲートは、上限と提示すべき根拠を定めます。ファンアウトを行う前に実行してください。これは、過剰な委任が振り返りログで最もコストの高い、繰り返し発生する無駄のひとつだからです。単一ファイルの書き換えのためにチームを起動したり、ディスクへの書き込みがゼロなのに「完了」と報告した執筆エージェントに11万トークンを費やしたり、検証する余力が残らないまま300エージェントを動員したりする例があります。外部の根拠として、Cloudflare のリスク階層別ディスパッチがあります。エージェント数を作業の規模に合わせてください。誤字修正のレビューにドリームチームを投入してはいけません。

• (a) エージェントゼロの確認。 答えがすでに作業メモリにある、Glob+Grep+Read で30秒以内に見つかる、または単一ファイルに限られる場合は、エージェントを0体にして、その場で対応してください。サブエージェントは無料ではありません。セットアップ、コンテキストの読み込み、結果の処理にかかるコストは、直接読み取るコストを上回ります。
• (b) 書き込みエージェントはすべてディスクへの反映を確認。 ファイルを書き込んだ、または編集したと報告するエージェントは、確認が済むまで信用してはいけません。ファイルが存在し、差分が空でないことを確認してください（Read / git diff / Grep で申告された変更を確認）。「完了」という報告は主張であって、証拠ではありません。ルール1のライブプローブは、メインエージェントと同様に委任先にも適用されます。
• (c) 約8体を超える場合の予算確保。 同時に動かすエージェントが約8体を超えるファンアウトでは、明示的に検証予算を確保してください。すべてを生成に使い切り、確認に回せる予算がない状態にしてはいけません。また、結果が使えない場合に備えて、エージェントを使わない代替案を ## Decisions に記載してください。これにより、5階層のネストが可能な仕組みに上限を設けます。ネストはエージェント数を乗算するため、上限は最上位の層だけでなく、ツリー全体に適用されます。

Delegation Gate での出力： 📐 RIGHT-SIZE: [0-agent inline | N agents, disk-probed | N>8, verify-budget reserved + fallback named]。

エージェント向けブリーフは理想状態を指示するプロンプトです

インラインのブリーフと Workflow サブエージェント向けプロンプトでは、手順ではなく理想状態を示してください。 完了結果がどのようなものか（テスト可能な成果として）、制約、利用できるツールを記述し、そのうえで方法はエージェントに任せます。エージェントの推論を順序立てて指示するブリーフ（「まず検索し、次に抽出し、その後検証してから統合する」など）は、BPE に違反する足かせです。有能なエージェントの能力を制限し、モデルの進化とともに陳腐化します。これはシステム内で最も大量に使われるプロンプトの用途です（サブエージェント向けブリーフは実行時に頻繁に作成されるため）。そのため、ここでの規律が特に重要です。維持すべき4つの分類（安全ゲート、検証済みの注意点、ツールの契約、出力形式の契約）は残し、手順の演出は削除してください。ハードコードされたファンアウト数ではなく、網羅性の成果を示してください（「3つ以上の独立した情報源が一致した場合のみ、該当すると判断する」とし、「エージェントを正確に15体起動する」とはしないでください）。標準の全文：skills/Prompting/Standards.md § Ideal-State Prompting。

アンチパターン（避けてください）

• Grep/Glob/Read で2秒未満にできる作業を委任しないでください
• 単一ファイルの変更にエージェントを起動しないでください
• 独立したワークストリームが3つ未満の場合、チームを作らないでください
• 十分なコンテキストを与えずに作業を依頼しないでください。エージェントはまっさらな状態から始めます
• カスタムエージェントに組み込みエージェント名を使わないでください
• ユーザーが専門エージェントやカスタムエージェントを求めた場合、組み込みエージェントの種類だけをそのまま使わないでください。エージェントごとに異なるインラインブリーフを書き、general-purpose を起動してください
• 1回限りの抽出や分類に全面的な委任を使わないでください。軽量なティアを使ってください

注意点

• 連携するチームには、Claude Code に組み込まれている TeamCreate を使用します — これは、単発のカスタムエージェント（general-purpose 上のインラインブリーフ）とは異なります。これらは別々のパターンです。
• 独立した作業ストリームが3つ以上ある場合は、委任が適しています。 タスクが1～2件なら、チーム連携のオーバーヘッドをかけるより直接作業するほうが速くなります。
• エージェントチームはタスクリストを共有します。 その場しのぎのメッセージではなく、TaskCreate/TaskUpdate を使って連携してください。
• 単一ファイルのタスクにチームは過剰です。（2026年3月の振り返り：「コードを読んで JSX も書けるエージェント1つのほうが、連携できない専門エージェント3つより優れています」）
• フォークされたサブエージェントは、メインスレッドの会話全体を引き継ぎ、プロンプトキャッシュを共有します（Anthropic CC v2.1.133 以降。CLAUDE_CODE_FORK_SUBAGENT=1 環境変数、またはエージェントのフロントマター context: fork で有効化）。ニュアンスに依存する作業にはフォークされたサブエージェントを使ってください。たとえば、デザインのバリエーション、追加調査、メインスレッドですでに確立したコンテキストに依存する作業などです。コードレビューではフォークしないでください — フォークされたレビュアーは自身のコードを擁護します（R Amjad：「自分のコードを擁護する傾向がある」）。結論を出すための質問では、フォークありとフォークなしを1つずつ並行して実行し、意見が異なる点を確認してください。

例

例1：並行実装

User: "build the frontend and backend in parallel"
→ Creates team via TeamCreate
→ Spawns frontend and backend agents
→ Shared task list for coordination
→ Agents work independently, merge results

例2：調査の群集

User: "launch an agent team to research these 5 topics"
→ Creates team with 5 research agents
→ Each agent handles one topic independently
→ Results synthesized by team lead

実行ログ

ワークフローを完了した後は、JSONL エントリを1つ追加してください。

echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"Delegation","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl

WORKFLOW_USED は実行したワークフローに、8_WORD_SUMMARY は入力の簡潔な説明に、SECONDS はおおよその実時間に置き換えてください。ワークフローが失敗した場合は、status: "error" を記録してください。