oma-coordination

マルチエージェントワークフローガイド

スケジューリング

目標

PM、フロントエンド、バックエンド、モバイル、QA の各担当にまたがる複雑な作業について、手動でのマルチエージェント連携をガイドします。

意図のシグネチャ

• ユーザーが、完全な自動化を行わずに、段階的な連携、手動でのエージェント起動、または複数領域にまたがる作業計画を求めている。
• タスクが複数の専門エージェントにまたがり、契約の調整が必要である。

使用する場面

• 複数の領域にまたがる複雑な機能（フルスタック、モバイル）
• フロントエンド、バックエンド、モバイル、QA 間の連携が必要
• ユーザーがマルチエージェント連携について段階的なガイダンスを求めている

使用しない場面

• 単一領域の簡単なタスク → 該当するエージェントを直接使用します
• ユーザーが自動実行を求めている → オーケストレーターを使用します
• 迅速なバグ修正や軽微な変更

想定される入力

• 複雑な機能またはプロジェクトの目標
• 必要な領域と優先度の段階
• ワークスペース／セッションの制約、および API／データ契約の要件

想定される出力

• 手動での連携手順
• PM によるタスク分解、エージェントの起動順序、進捗監視のガイダンス、QA レビューの手順
• API／データ契約の調整チェックポイント

依存関係

• PM、フロントエンド、バックエンド、モバイル、QA、オーケストレーターのスキル
• CLI oma agent spawn および進捗／結果のメモリー規約

制御フローの機能

• タスクの複雑さ、優先度の段階、依存関係の順序、自動化の要否に応じた分岐
• 適切な場合、同じ優先度で互いに独立したタスクを並行して起動
• 進捗ファイルと契約の調整状況を監視

構造フロー

開始

1. タスクがマルチエージェント連携を必要とするほど複雑か確認します。
2. 現在の計画と引き継ぎ状態を再利用し、タスクの分解や契約の変更が必要な場合は PM を使用します。
3. 優先度の段階と共有契約を特定します。
4. 並行作業を割り当てる前、または担当範囲の引き継ぎや結果の取りまとめを調整する前に、共有のコラボレーションポリシーを適用します。

シーン

1. PREPARE：セッション、領域、タスク分解の要件を定義します。
2. ACT：優先度に応じて、個別のワークスペースでエージェントを起動します。
3. VERIFY：進捗と API／データ契約の調整状況を監視します。
4. FINALIZE：QA レビューを実施し、修正対応を調整します。

遷移

• タスクが簡単な場合は、1 つの専門エージェントに振り分けます。
• ユーザーが自動実行を求めている場合は、オーケストレーターを使用します。
• QA がブロッキング不具合または必要な検証の不足を報告した場合は、既存の復旧予算内で、該当する作業を担当エージェントに割り当てます。

失敗と復旧

• 契約に食い違いがある場合は、バックエンド／API 契約の整合が取れるまで、後続のフロントエンド／モバイル作業を一時停止します。
• エージェントのワークスペースが競合する場合は、担当範囲を分割します。
• 進捗が停滞した場合は、進捗ファイルを確認し、対象を絞った指示を再発行します。

終了

• 成功：専門エージェントの出力が調整され、QA レビュー済みです。
• 部分的な成功：ブロックされたエージェント、契約の競合、または QA の失敗が明示されています。

論理操作

アクション

Action	SSL primitive	Evidence
依頼と領域を読み取る	READ	ユーザーのプロンプトとプロジェクトのコンテキスト
エージェント計画を選択する	SELECT	PM によるタスク分解と優先度の段階
エージェントを起動する	CALL_TOOL	oma agent spawn
進捗を監視する	READ	注入されたタスク／実行単位の進捗、担当状況、受領記録
契約を検証する	VALIDATE	API／データモデルの整合
連携状況を通知する	NOTIFY	最終的な連携の概要

ツールと手段

• oma agent spawn、PM／フロントエンド／バックエンド／モバイル／QA エージェント
• メモリー／進捗／結果ファイル
• 設定済みのコードインテリジェンス。ネイティブフォールバックについては ../_shared/core/code-intelligence.md を参照

標準コマンドパス

# If planning is required, dispatch the declared PM task first; otherwise reuse the current plan.
oma agent spawn pm <pm-prompt-file> <session-id> --task-id <plan.pm_task.id> -w ./pm
oma agent spawn backend <backend-prompt-file> <session-id> --task-id <plan.backend_task.id> -w ./backend &
oma agent spawn frontend <frontend-prompt-file> <session-id> --task-id <plan.frontend_task.id> -w ./frontend &
wait

ネイティブランタイムのディスパッチが利用可能な場合（エージェントごとのターゲットベンダーが現在のランタイムベンダーと一致する場合）は、ランタイムのネイティブなサブエージェントパスを優先し、ベンダーをまたぐ場合のフォールバックとして oma agent spawn を使用します。oma-orchestration と同じ解決ルールです。

便利な agent spawn オプション：--vendor <vendor>（CLI ベンダーの上書き）、--isolation worktree（起動ごとに git worktree を作成し、ファイルの競合を防止）、--read-only（レビュー／QA などに使用する、破壊的でないツールのみ）。

リソースのスコープ

スコープ	リソースの対象
LOCAL_FS	進捗／結果ファイルとワークスペース
PROCESS	エージェントの起動コマンド
MEMORY	セッションの状態とタスクボード
CODEBASE	共有コントラクトと実装領域

前提条件

• タスクに複数のドメインが必要です。
• 現行の計画で、タスクの担当者、受け入れチェック、依存関係、優先度の段階が明確になっています。

効果と副作用

• 複数のエージェントを起動、またはその実行をガイドします。
• ワークスペースの所有権とQAフィードバックを調整します。

ガードレール

1. 有効な計画を再利用し、分解やコントラクトの変更が必要な場合に限りPMを呼び出します
2. 独立したタスクは並行して起動します（同じ優先度の段階内）
3. API境界が変更された場合は、依存するフロントエンド／モバイル作業の前にコントラクトを再利用または更新します
4. QAレビューは常に最後のステップです
5. ファイルの競合を避けるため、別々のワークスペースを割り当てます（または、起動ごとに git worktree を作成する --isolation worktree を使用します）
6. ../_shared/core/code-intelligence.md に従います。設定済みのツールを検出し、自動インストールや追跡は行いません。また、ネイティブ検索が利用できない、またはタイムアウトした場合に限り、このプロジェクト外のパスや無視対象のパスにネイティブ検索を使用します
7. 現在の引き継ぎ状態から再開し、該当するステップを依存関係の順に実行します。適用しない分岐については、その理由を記録します

ワークフロー

ステップ 1：PM Agent と計画を作成する

既存の有効な計画を再利用します。該当する計画がない場合は、PMが要件を分析し、タスクの分解、受け入れチェック、コントラクト、優先度を作成します。注入されたセッション／タスク／実行IDを保持し、ディスパッチによってすでに確定した計画を再生成しないでください。

ステップ 2：優先度に応じてエージェントを起動する

エージェントごとにディスパッチパスを解決してから、起動します。

1. oma-config.yaml の agents: オーバーライド、またはそれがない場合は model_preset から、エージェントごとのターゲットベンダーを解決します
2. ターゲットベンダーが現在のランタイムベンダーと一致し、ネイティブなサブエージェントパスが存在する場合は、ネイティブディスパッチを使用します
3. それ以外の場合は、そのエージェントに oma agent spawn を使用します
4. 同じ優先度の段階にあるすべてのタスクを、バックグラウンドプロセスで並行して起動します

# Example: spawn backend and frontend in parallel
oma agent spawn backend backend-prompt.md session-id --task-id plan.backend_task.id -w ./backend &
oma agent spawn frontend frontend-prompt.md session-id --task-id plan.frontend_task.id -w ./frontend &
wait

ステップ 3：監視と調整

• 実行期限、リソースの所有権、キャンセルには ../_shared/core/execution-policy.md を適用します。ホストからの完了通知を優先し、利用できない場合は、制限付きバックオフポーリングを行うコーディネーターを1つ使用します。キャンセルまたは期限切れになった場合、新たなディスパッチ、レビュー、リカバリーを停止します。制限付きの終了確認を行い、引き継ぎ時に残存プロセスやキャンセル非対応について報告します。
• 注入された実行アーティファクトと受領記録を読み取ります。人が読める進捗／結果は {memoryConfig.basePath}/progress-{agentId}-{taskId}-{runId}-{sessionId}.md および対応する result- のファイル名で記録されます。../_shared/runtime/memory-protocol.md を参照してください。構造化された claim のパスは変更しないでください。
• エージェント間でAPIコントラクトが一致していることを確認します
• 共有データモデルに一貫性があることを確認します

ステップ 4：QAレビュー

QAと連携して、調整済みの成果物をレビューします。ブロッキングとなる欠陥や必須の検証漏れは担当エージェントに解決させ、最終確定前に影響を受けるチェックを再実行します。

自動化された代替手段

手動で起動せずに実行を完全に自動化するには、代わりに orchestrator スキルを使用します。

参考資料

• 並列ワーカーの連携：../_shared/core/collaboration-policy.md（並列作業の割り当てや、ピア間の問題、担当の引き継ぎ、結果の収集を調整する前に参照してください）