計画と実行

計画・実行ワークフローは、1つの作業を2つの役割に分担させるしくみです。作業を準備して検証する計画セッションと、実際に作業を行う1つ以上の実行セッションで構成されます。この章では、メニューまたはセッションからワークフローを開始する方法、タスク分割の確認、作業ディレクトリの選択、ワークフローの進捗の確認方法を説明します。

1. ワークフローの流れ

ワークフローには2つの役割があり、それぞれがサイドバー上で独立したセッションとして動作します。

• 計画と検証。 計画セッションは、タスクとプロジェクトを調査し、実行セッションへの指示を作成して、各結果を検証します。結果が受け入れられる状態になるまで修正を依頼し、実際の変更内容と検証の根拠を確認したうえで初めて受け入れます。
• 実行。 実行セッションは、指示された内容を実装して報告します。修正の依頼は同じ実行セッションに送られ、実行セッションはやり取りの間もコンテキストを保持します。

サイドバーでは、実行セッションが計画セッションの子として表示されます。どちらのセッションも会話ビューで動作します。役割間でやり取りされるメッセージには、送信元のエージェントのアイコン、セッション名、役割（「計画」または「実行」）が表示されるため、どちらの会話でもやり取りの流れを追えます。

どちらの役割にも、会話ビューに対応したエージェント（Claude Code、Codex、OpenCode、Pi、OMP）が必要です。計画セッションと実行セッションで、異なるエージェント、モデル、思考の深さを使うこともできます。

どちらのセッションも、いつでも読んだり、応答したり、中断したりできます。どちらの役割からの権限の要求も、通常どおりユーザーの応答を待ちます。

2. メニューから開始する

プロジェクト、グループ、セッションのいずれかのコンテキストメニュー、またはその「新規子セッション」サブメニューを開き、「計画・実行セッションを新規作成…」を選びます。ダイアログには次の項目があります。

• 「作成先」：計画セッションを作成する場所です。実行セッションは計画セッションの下に作成されます。
• 「タスクの指示」：タスクの内容、要件、受け入れ基準を記述します。画像を貼り付けることもでき、画像は計画セッションへのタスクと、実行セッションへの最初の指示に添付されます。
• 「複数のタスクに自動分割」：§4 を参照してください。
• 「計画と検証」と「実行」：それぞれの役割のエージェント（「セッションの種類」）、「モデル」「推論強度」です。モデルと推論強度の選択肢は、選択したエージェントから取得されます。ダイアログは、役割ごとに前回の選択を記憶します。
• 「作業ディレクトリのパス」とディレクトリの選択：§5 を参照してください。

「作成して起動」を選ぶと、計画セッションが起動します。計画セッションは、計画が整った時点で実行セッションを作成します。ダイアログを開いたりキャンセルしたりしただけでは、何も作成されません。ダイアログには専用のアドレスがあるため、リンクのコピー、ページの再読み込み、ブラウザの戻る・進むを行ってもダイアログは失われません。

3. セッションから開始する

VelaTerm が起動した任意のセッションで、次のコマンドを実行します。

vspawn --plan-execute \
  --plan-agent claude --plan-model opus --plan-effort high \
  --exec-agent codex --exec-model gpt-5.5 --exec-effort medium \
  "Implement the agreed changes and verify all acceptance criteria"

Claude Code では /vspawn --plan-execute <task>、Codex では $vspawn --plan-execute <task> で同じ操作ができます。スキルは、ワークフローを開始する前に、現在の会話から自己完結したタスクを作成します。これらのスキルを使うには Vela Skills（「設定」▸「一般」）が必要です。

新しい計画セッションは、コマンドを実行したセッションの下に作成されます。要求を送ると、まずセッションの生成とGitによるコラボレーションの§4 で説明した確認カードが開き、タスクと両方の役割の設定を確認して変更できます。

エージェントを明示的に指定しない場合、Claude、Codex、OpenCode、Pi、OMP のセッションから開始した計画セッションは同じエージェントを使い、その他のセッションから開始した場合は Claude Code を使います。選択したエージェントが対応していないモデルや思考の深さを指定すると、何かが起動する前に拒否されます。

新しいセッションからは、開始元の会話は見えません。これまでの決定事項、既存の変更、制約、成果物の提出先をタスクに含めてください。

4. 複数のタスクに分割する

ダイアログで「複数のタスクに自動分割」をオンにするか、vspawn --plan-execute に --split-tasks を付けます。すると、計画セッションが作業を調査し、1〜12個の独立したタスクを提案します。ユーザーが確定するまで、実行セッションは起動しません。

提案が届くと、「実行タスクの確認」ダイアログが開きます。

• 一覧でタスクを選ぶと、その「セッション名」「タスクの指示」、エージェント、「モデル」「推論強度」を編集できます。タスクを切り替えても、編集内容は保持されます。
• 「タスクを除外」でタスクを外し、「除外を取り消す」で元に戻します。タスクは少なくとも1つ残す必要があります。
• 起動ボタン（「N 件のセッションを起動」）を押すと、タスクごとに1つの実行セッションが作成されます。
• ダイアログを閉じても、提案は確認待ちのまま残ります。その間は「実行タスクの確認」リンクが画面に表示され、ダイアログを開き直せます。提案をキャンセルすると、実行セッションを作成せずにワークフローが停止します。
• ダイアログには専用のアドレスがあり、ページを再読み込みしても失われません。ただし、まだ確定していない編集内容は、再読み込みすると失われます。

スキルでタスク分割を使う場合、スキルは --yes を付けるため、この最終確認だけが表示されます。確認画面では各実行セッションの設定を変更できますが、すでに動作している計画セッションの設定は変更できません。

1つの計画セッションがすべての実行セッションの報告を受け取り、タスクごとに個別の修正のやり取りを行いながら検証します。ワークフロー全体は、すべてのタスクが受け入れられた時点で完了します。

タスクは、同じファイルを編集しない単位に分割してください。実行セッションはそれぞれ独自のエージェントプロセスを実行するため、タスクの数はマシンのリソースを考慮して決めてください。

5. 作業ディレクトリとワークツリー

ディレクトリの選択は、ワークフロー内のすべての役割に適用されます。

新しいワークツリーは現在のコミットから作成され、未コミットの変更は含まれません。ワークツリーを作成できなかった場合、該当するセッションは起動せず、別のディレクトリで代わりに起動することもありません。コマンドラインでは、--worktree だけを指定すると shared を意味します。

結果は、マージするまでワークツリーに残ります。ブランチをマージするには、セッションで「Git」▸「Merge…」を使います（セッションの生成とGitによるコラボレーションの§6 を参照）。ワークフローが自動的にマージ、プッシュ、ワークツリーの削除を行うことはありません。

6. 進捗を確認する

• 計画セッションの会話には、すべての報告と修正の依頼がリアルタイムで表示されます。実行セッションが作業している間、計画セッションはその報告を待ちます。
• vflow status <workflow-id> は、ワークフローの状態、タスク、セッション、現在のやり取りの回数を表示します。ワークフロー ID は、ワークフローのメッセージに表示されます。
• vflow stop <workflow-id> は、以降のやり取りを停止し、実行中のセッションに停止を求めます。ワークフロー全体を停止するとそのタスクもすべて停止しますが、1つのタスクを停止しても他のタスクには影響しません。
• vstat は、作業中のセッション、権限の確認を求めているセッション、待機中のセッションを表示します。実行セッションが待機中でも、タスクが完了したとは限りません。完了とみなされるのは、計画セッションが受け入れた場合だけです。
• ある役割が作業を引き渡さずにターンを終えると、ワークフローはブロック状態になります。会話を確認し、必要な応答をしてから、計画セッションで作業を続けてください。

これらのコマンドについては、セッションコマンドで説明しています。