orchestrate

マルチエージェントのオーケストレーション

独立したエージェントを活用して有用な処理能力を高めながら、一貫性のある成果を維持します。独立して進められる質問、成果物、リソースごとに作業を分割します。コーディネーターが統合と最終的な完了の判断を担います。

ユーザーの指示は、このスキルのガイドラインより優先されます。委任、ツール、外部アクションには、引き続き現在のホストの指示と許可が適用されます。このスキルによって、ワーカーにコーディネーターより広い権限が与えられることはありません。

ディスパッチ前に機能を確認する

利用可能なツールと現在のスキーマを確認します。ホストによって、エージェントのライフサイクル、継承されるコンテキスト、ファイルシステムの共有、ワークツリーの分離、非同期の結果、権限は異なります。製品名から推測したり、古い引数を使い回したりせず、それらの特性を確認してください。

許可されている場合は、ホストがサポートする委任ツールを使用します。外部 CLI レビュアーもリソースを消費し、委任と権限のルールに従う必要があります。制限を回避する手段ではありません。適切な委任機能がない場合は、直接作業するか、許可された外部ワーカー向けにタスクを準備します。タスクキューを用意しただけでは、エージェントは起動しません。

依存関係に応じて作業形態を選ぶ

作業形態	調整パターン
独立した調査課題	並列で調査し、根拠に基づいて統合する
安定したインターフェースを持つ、分離された機能の担当	並列で構築し、統合担当者を指定する
複数のモジュールで繰り返す1つの変更	範囲を限定した自動変換または分割したワーカーを使い、検証を統合する
依存関係のある編集や、共有される可変状態	依存関係の担当者を1人にし、その周辺の作業を並列化する
重要なレビュー	リスクの観点を活かせる独立した読み取り専用のレビュアーに依頼する
小規模で密接に結合した変更	直接実行する

エージェントの人数は、明確で有用な作業レーン、利用可能な処理能力、統合コストに応じて決めます。異なる根拠を提供したり、独立した作業を短縮したりできる場合は、エージェントを増やす価値があります。過去の大規模な編成を標準として使わないでください。クリティカルパスを確認します。すでに1つの共有インターフェース待ちになっている分岐を高速化しても、処理能力は向上しない場合があります。

所有権と統合を確立する

ビルダーを起動する前に、リポジトリの状態と既存のワークツリーを確認してください。ファイルだけでなく共有リソースも把握してください。生成物、スキーマ、ロックファイル、データベースのフィクスチャ、ポート、ビルド出力、パッケージキャッシュは、互いに独立したモジュール間でも競合する可能性があります。

作業に応じて分離方法を選択してください。

分離方法	適切な用途	必要な調整
共有ツリー、パスの分離	所有権が明確な、小規模で独立した変更	競合するファイルと Git インデックス操作の担当者を1人にする
個別のワークツリー	作業者が個別のブランチまたはビルド状態を必要とする	既知のベース、ブランチ／パス、マージ順序、統合担当者を決める
読み取り専用リビジョン	レビューまたは調査	固定されたリビジョン／差分と、許可された一時出力を指定する

ワークツリーで分離されるのは追跡対象のファイルとインデックスです。ポート、データベース、外部サービスが自動的に分離されるわけではありません。プロジェクトのワークツリー構成に従ってください。競合を解消するために、人間や他の作業者の編集内容を上書きしてはいけません。

共有ツリーでは、別の明示的な所有権の仕組みに合意していない限り、作業者にはパッチとチェック結果を報告してもらい、1人のコーディネーターが範囲を限定して変更をステージングし、コミットしてください。並行編集の最中に、広範囲のステージングやリポジトリ全体への自動修正を避けてください。コミットを受け入れる前に、フックによる副作用を確認してください。ロックが競合する場合は、実際の所有者を調べてください。プロセス一覧で所有者が特定できなくても、ロックを安全に削除できる根拠にはなりません。復旧方法については git を参照してください。

作業を割り当てる前に、部分的な進捗をどのように統合済みの進捗にするかを定めてください。各利用者が期待する成果物と、それが利用可能になる条件を明示してください。完了したブランチを、確認して統合する担当者がいないまま放置してはいけません。

必要なコンテキストを引き継ぐブリーフを書く

各作業者には、関連する依頼の原文と、範囲を限定した担当作業を伝えてください。再発見に時間がかかる事実や、作業者のチェックアウトに含まれない情報、特にユーザーからの修正や、まだ記録されていない決定事項を含めてください。場所が重要な場合は、絶対パスと正確なリビジョンを使用してください。

ブリーフの要素	目的
成果と範囲	必要な結果、担当する領域、対象外の事項
現在の根拠	関連するコード、バージョン、インターフェース、検証済みの前提
依存関係	何が準備済みか、何が約束されているか、誰が担当しているか
権限	許可される変更、コミット権限、外部での操作
検証	この作業へのチェック項目と受け入れ条件
返却内容	変更した成果物または調査結果、根拠、制限事項、正当な逸脱

作業者が前提に異議を唱え、必要な範囲の拡大を報告できるようにしてください。ブリーフは作業を制約するものであり、既知の問題がある手段を強制するものではありません。必須テンプレートは簡潔にし、詳細な例は references/dispatch-briefs.md に記載してください。

独立した初回レビューでは、実装者が望む結論へ誘導することなく、依頼の原文と変更内容の生データを提示してください。追加検証では、指摘事項と修正の主張を含め、問題が解消されたかをレビュー担当者が検証できるようにしてください。これらは異なるレビュー作業です。

ボトルネックにならずに監督する

独立した作業を同時に開始し、その間も有用なローカル作業を続けます。恣意的な一斉処理の完了を待つのではなく、依存関係が解決して準備が整った結果を、届き次第取り込みます。実際に共有のチェックポイントがある場合や、広範囲に作業を割り当てる前に手法の調整が必要な場合は、ウェーブを使います。

結果、ツールの状態、成果物の進捗、報告された障害を監視します。反応がないだけでは、エージェントが停止しているとは限りません。進捗が止まった場合は、割り込む前に状況を見分けられる質問をするか、関連するリソースを調べます。ユーザーが状況を調整できる応答性を保ち、ポーリングや待機はホストの実際の制限を守る必要があります。

要件が変わった場合は、影響を受ける作業者に通知し、共有契約を更新します。完了済みの有効な作業は維持します。不要になった処理は安全な時点で停止し、この実行が所有するプロセスや監視処理だけをキャンセルします。放棄した作業と、すでに発生した副作用を報告します。

監視処理には、確認可能な完了条件、失敗の検出方法、有効期限またはエスカレーション条件、そして許可されたアクションを実行する前の古い状態の確認が必要です。既知の状態で、そのシグナルをテストしてください。監視処理の詳細なガイダンスは references/dispatch-briefs.md にあります。

取り込み、統合、検証する

結果だけでなく、逸脱や制限事項も確認します。実際の差分を調べ、重要なソースファイルを開いて確認します。作業者の要約は主張であり、証拠ではありません。不完全な貢献にも利用できる成果が含まれている場合がありますが、採用するかどうかは、長さや作業者の自信ではなく、タスクと照らし合わせて確認したうえで判断します。

安定したチェックポイントで統合し、統合後の動作を対象とするチェックを実行します。作業者ごとに別々に行ったテストでは、インターフェース間の前提の不整合を見逃すことがあります。累積した差分が、引き続きユーザーの目的と明示された制約に沿っていることを確認します。

重要な変更について、プロジェクトが独立した検証を求める場合は、完了前にそれを実施します。実装担当者は実施したチェックを報告できますが、独立した PASS を認定することはできません。追加のレビュアーには、異なるリスクを確認してもらうか、意図的に独立した評価を依頼します。指摘の件数を目標にしてはいけません。

レビューの証拠は、リビジョンまたは記録された作業ツリーのスナップショットと、環境に結び付けます。次の判定を使用してください。

判定	意味
PASS	宣言されたレビュー範囲の確認が完了し、未解決の重大な指摘がありません
FAIL	裏付けのある不具合が、要求された成果または適用される契約に違反しています
INCOMPLETE	レビューまたは必須のチェックが完了していません。未確認の範囲を列挙します

中断されたレビューでは、完全な PASS を付与できません。意見の一致だけでは重大度は確定しません。影響と悪用可能性が判断基準です。意見の相違は、コード、仕様、または再現手順を通じて裁定します。ベースで再現された障害は、回帰と既存の動作を区別するのに役立ちますが、どちらの判定も変更された経路の分析に代わるものではありません。

変更後は、レビュー済みのどの主張が無効になったかを再評価し、影響を受ける動作と関連する統合を再検証します。変更された実行時コードに PASS を使い回してはいけません。プロジェクトの方針で求められている場合を除き、ドキュメントのみの変更を理由に、無関係な実行時チェックを行う必要はありません。

状態を正直に伝えて完了する

統合した成果、実際に行ったチェックとその対象リビジョン、未解決の制限事項、残りの成果物の場所を報告します。外部のゲートを利用できない場合は、許可された独立作業を完了し、具体的な阻害要因と必要な対応を明示します。タスクや目標の状態を記録するホストのルールに従い、必須作業が未検証のまま完了を主張してはいけません。

調整に関する長期的に有用な失敗情報は、設定済みのプロジェクトメモリに記録します。競合したリソース、失敗の仕組み、修正内容、条件を含めます。一時的なログや作業者同士のやり取りは、恒久的なガイダンスに含めないでください。

根拠と制約

2026-09-04 にレビュー済みです。Anthropic のマルチエージェント調査の事例研究では、スコープを明確に定め、独立した調査を並行して進めることが推奨される一方、調整の手間やトークンのオーバーヘッドについて警告しています。調査結果から、最適なコーディングエージェントの数が明らかになるわけではありません。

Astra のガイダンスでは、委任に関する期待を明確にすることが推奨されています。実際のホストの仕様の範囲内で適用してください。API の機能が、特定の CLI でもその機能が公開されていることを示すわけではありません。

反パターン

反パターン	より良い方法
独立した作業を見つける前にエージェントの数を決める	有用な作業領域と、その統合方法を明示する
ファイルが異なれば分離されていると考える	共有ランタイムリソースと生成された出力を調べる
外部レビュー担当者をポリシー回避手段として扱う	同じ権限と許可の境界を適用する
不完全なレビューに無理に二択の判定を求める	不足しているカバレッジを示して INCOMPLETE と報告する
指摘を票数で判断する	仕組みと影響を検証する
共有ツリーで全ワーカーが同時にコミットできるようにする	インデックスとコミット操作の担当者を決める
時間の経過に応じてレビューを自動的に減らす	現在のリスクと変更された根拠に応じてチェックを行う

参考資料

ワーカー、調査、検証、監視担当者への指示を作成する際は、references/dispatch-briefs.md を参照してください。

このスキルに含まれないもの

• ホストの委任ルールやユーザーの所有権を無視する許可ではありません。
• 固定されたパイプライン、エージェントの上限数、複数エージェントの使用要件ではありません。
• 統合的な検証やコーディネーターの判断の代替ではありません。