oma-coordination

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

スケジューリング

目標

PM、フロントエンド、バックエンド、モバイル、QA の各担当にまたがる複雑な作業について、手動で複数エージェントを調整する方法を案内します。

意図シグネチャ

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

使用する場合

• 複数の分野にまたがる複雑な機能（フルスタック、モバイル）
• フロントエンド、バックエンド、モバイル、QA 間の調整が必要な場合
• ユーザーが複数エージェントの段階的な調整ガイダンスを求めている場合

使用しない場合

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

想定される入力

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

想定される出力

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

依存関係

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

制御フロー機能

• タスクの複雑さ、優先度の階層、依存関係の順序、自動化を希望するかどうかに応じた分岐
• 適切な場合、同じ優先度で独立しているタスクのエージェントを並行して起動
• 進捗ファイルと契約の整合性を監視

構造フロー

開始

1. 複数エージェントでの調整が必要なほどタスクが複雑であることを確認します。
2. 現在の計画と引き継ぎ状態を再利用します。タスクの分解や契約の変更が必要な場合は PM を使用します。
3. 優先度の階層と共有契約を特定します。

フェーズ

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

遷移

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

失敗と復旧

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

終了

• 成功：専門エージェントの成果が調整され、QA レビューを受けています。
• 部分的な成功：エージェントのブロック、契約の競合、または QA の不合格が明示されています。

論理操作

アクション

アクション	SSL プリミティブ	根拠
依頼と分野を読み取る	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 ワークツリーを作成するために --isolation worktree を使用します）
6. ../_shared/core/code-intelligence.md に従います。設定済みのツールを検出し、自動インストールや追跡は行いません。利用できない場合やタイムアウトした場合に限り、このプロジェクト外のパス、または無視対象のパスに対してネイティブ検索を使用します
7. 現在のハンドオフ状態から再開し、該当するステップを依存関係の順に実行します。適用されない分岐については、その理由を記録します

ワークフロー

ステップ 1：PM エージェントで計画する

有効な既存の計画を再利用します。ない場合は、PM が要件を分析し、タスクの分解、受け入れチェック、コントラクト、優先度を作成します。注入されたセッション ID、タスク ID、実行 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：監視と調整

• 注入された実行成果物と受領確認を読み取ります。人が読める進捗／結果は {memoryConfig.basePath}/progress-{agentId}-{taskId}-{runId}-{sessionId}.md と、それに対応する result- 名のファイルに保存されます。../_shared/runtime/memory-protocol.md を参照してください。構造化された claim のパスは変更しないでください。
• エージェント間で API コントラクトが一致していることを確認します
• 共有データモデルに一貫性があることを確認します

ステップ 4：QA レビュー

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

自動化された代替手段

手動での起動を行わずに実行を完全に自動化するには、代わりに orchestrator スキルを使用してください。

参考資料