AI-DLC Workflow V2のオーケストレーター: `/aidlc` の内側で何が起きているか
`/aidlc` と打ったあと、あの一連の流れって誰が仕切っているんだろう？ この記事では、オーケストレーターを「コンダクター」と「決定論エンジン」の分業として解きほぐし、`next → 指令 → 実行 → report` というループがどう回るのかを見ていきましょう。シリーズ第24回。
Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 24AI-DLC Workflow V2のオーケストレーター: `/aidlc` の内側で何が起きているか This article
1. はじめに
「オーケストレーター」と一言で言っても、実は1つの部品ではありません。
/aidlc の司会役を務める生きた AI セッションと、その裏で routing を静かに決めている決定論的なエンジン。この2者に役割が分かれています。この記事では、その分業と、/aidlc を実行したときに内部を流れる制御の道筋を追っていきます。この記事を読み終えると、次の2点が分かります。
- コンダクターと決定論エンジンの分業、つまり「誰が何を決めるか」を自分の言葉で説明できる。
/aidlcを実行したとき内部で何が起きているか、next → 指令 → 実行 → reportのループを追える。
読者としてはハーネス実装者やコントリビューター寄りの層を想定しています。抽象的な概念紹介ではなく、構造を追える深さで書いていきます。
2. オーケストレーターとは何か
オーケストレーターは、役割の異なる2者の分業として設計されています。
一方はコンダクター（
/aidlc の司会役）です。これは実際に会話を進める生きた AI セッションで、エンジンが名指しした「その一手」の中で実行の品質に責任を持ちます。適切なペルソナを与える、良い質問をする、ステージの日誌（memory.md）を書く、矛盾を解消する、そして承認ゲートで判断を人間に差し出す、といった作業です。もう一方は決定論エンジン（
aidlc-orchestrate.ts）です。エンジンはステージ間の routing をすべて所有します。スコープの解決、フラグの優先順位、ステージの順序づけ、ゲートの状態、ワークフローの完了判定などです。コンダクターはこれらを散文で再導出しません。ここで肝心なのは、エンジンが状態を一切変更しない点です。エンジンへの
next 呼び出しは、ワークフローの状態とコンパイル済みステージグラフを読み取り、次に取るべき一手を**ちょうど1つの型付き指令（directive）**として標準出力に返すだけです。状態を変えるのはコンダクターが指令に従って動き、その結果を report で報告したときです。この報告の往復（round-trip）が状態遷移を確定させ、次の next が新鮮な状態を読めるようにします。言い換えると、エンジンは「決める」役、コンダクターは「その決定の内側で上手にやる」役です。決定論エンジンは同じ入力に対して同じ指令を返すので、routing はハーネスをまたいで再現可能になります。
図1: コンダクター/エンジンの分業図
なお、図中の「人間 → 決定論エンジン」の矢印は、人間がエンジンを直接操作するという意味ではありません。人間が
/aidlc を起動することがループの起点になり、その最初の next 呼び出し（実際に発行するのはコンダクター）がエンジンに届く、という起動のトリガーを表しています。3. フォワーディングループ
コンダクターの制御構造は、
/aidlc が呼ばれた瞬間から回り始める1つのループに尽きます。これをフォワーディングループ（forwarding loop）と呼びます。手順は次のとおりです。nextを呼んで指令を1つ受け取る。- 指令の
kind（種類）が名指しする一手を実行する。 - ステージ作業の指令に対しては、実行後に
reportで結果を報告する。 - 指令の
kindがdoneになるまで繰り返す。
要点を押さえておきます。各
next はちょうど1つの型付き指令を返し、それ自体は状態を変更しません。指令の kind が「次に取る唯一の一手」を名指しし、コンダクターがその一手を実行します。そして report が結果の遷移を確定させるので、次の next は新鮮な状態を読み取れます。この「報告してから次を読む」順序が、ループの各周回で状態が一貫することを保証します。コマンドとしては、ループの各ステップは次のように実行されます。
1
2
bun .kiro/tools/aidlc-orchestrate.ts next
bun .kiro/tools/aidlc-orchestrate.ts report --stage <スラッグ> --result <outcome> --user-input "<回答>"なお
load-steering の指令だけは例外で、これは「ステージ作業」ではなく rule を運ぶための転送（transport）です。受け取ったら report せず、continue で即座に継続します。図2: フォワーディングループのフロー図
4. 指令の種類
指令は
kind という判別子（discriminator）を持ち、その種類が必要とするフィールドだけを載せた型付きのオブジェクトです。ここで事実関係を正確に区別しておきます。指令の型を定める契約ファイル
.kiro/tools/aidlc-directive.ts の DirectiveKind は10種類を定義しています。一方、オーケストレーター aidlc-orchestrate.ts が next 経路で実際に発行するのは8種類です。残りの dispatch-subagent と present-gate は、ループの形を完全に保つための文書化されたプレースホルダで、今日のエンジンは発行しません。したがって「指令は全部で8種類」ではなく、「実行時に発行=8種類、契約上の定義=10種類」という関係になります。以下の表は、エンジンが今日発行する8種類の一行の意味です。
| 指令の kind | 一行の意味 |
|---|---|
load-steering | アクティブなステージの rule バンドルを分割して運ぶ転送。適用して即 continue する（report しない）。 |
run-stage | 解決済みの rule・ペルソナ・consumes を読み込み、ステージ本体を実行し、produces を書く。承認の要否は gate フィールドに畳み込まれている。 |
invoke-swarm | 自律付与下で条件を満たす Construction バッチを、並列ワーカーへ fan-out する。 |
ask | 特定の構造化質問を提示する。多くは report で回答を返し、new-work-routing の亜種だけは next へ回答を回す。 |
print | message を指示どおりに扱う。terminal / run-then-continue / run-then-stop の3形がある。 |
error | message をそのまま提示してループを止める。回復や再試行はしない。 |
done | ワークフロー（または単一ステージ実行）の完了。完了サマリを提示してループを止める。 |
parked | ワークフローがステージ境界で意図的に中断された。再開方法（/aidlc --resume）を伝えて止める。 |
指令の実際の形は、次のように
kind ごとに必要なフィールドだけを持ちます。run-stage の代表的な形は次のとおりです（フィールドは抜粋）。1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
"kind": "run-stage",
"stage": "domain-design",
"phase": "inception",
"lead_agent": "aidlc-architect-agent",
"support_agents": ["aidlc-aws-platform-agent", "aidlc-design-agent"],
"mode": "inline",
"gate": true,
"memory_path": "aidlc-docs/inception/domain-design/memory.md",
"consumes": ["aidlc-docs/inception/requirements/requirements.md"],
"produces": ["aidlc-docs/inception/domain-design/components.md"],
"stage_file": ".kiro/aidlc-common/stages/inception/domain-design.md",
"next_stage": "Units Generation"
}ask は質問文を運ぶだけの単純な形です。1
2
3
4
{
"kind": "ask",
"question": "Resume from the last checkpoint, or start fresh?"
}done はループを止める理由を載せます。1
2
3
4
{
"kind": "done",
"reason": "Workflow complete — all in-scope stages approved."
}コンダクターはこれらを標準出力から受け取り、
kind を読んで対応する一手だけを行います。指令が壊れていたり実行できない一手を名指ししたりしていれば、その旨を率直に伝えて止めます。routing を散文で改変することはしません。5. ステージ実行の中身
run-stage の指令を受け取ったあと、コンダクターがステージ内部で行う流れは、おおむね「ロード → ステージ本体 → レビュー → 承認ゲート」の順になります。まずロードです。
run-stage の直前には load-steering の列が届き、アクティブなステージの rule バンドルを順に運びます。コンダクターは rules_content を配列順に適用し、continue で継続します。run-stage を受け取ったら、inline_context_paths の各パス（lead と support のペルソナなど）と stage_file、consumes を読み込み、memory_path の日誌を初期化します。次にステージ本体を走らせます。どう走らせるかは
mode フィールドが決めます。inline（このセッション内で lead ペルソナをまとって実行）、subagent（別のエージェントへ委譲）、pipeline（連鎖）、mob（並列の合議）などの通信トポロジです。ステージが質問を持つ場合は、成果物を書く前に質問チェックポイントを通します。続いてレビューです。指令が
reviewer を持つ場合は、ステージ本体の完了後にレビュアーを別のサブエージェントとして呼び出します（stage-protocol の §12a）。review_class が adversarial なら成果物への反証を試みる修正ループが回り、advisory なら1パスで所見を承認ゲートへそのまま渡します。レビュアーの検証記録は監査台帳（REVIEW_REQUESTED / REVIEW_COMPLETED）に残ります。最後が承認ゲートです。
gate: true のステージでは、学びの儀式（§13）を経てから承認ゲートを構造化質問（Approve / Request Changes）として提示します。ゲートはターンをそこで止め、人間の判断を待ちます。人間が Approve すれば report --result approved、Request Changes なら report --result rejected から修正ループに入り report --result revised を経て再提示します。ゲートが「人間のためにターンを止める」点が、AI-DLC がユーザーの制御を保つ要になっています。なお
gate: false の初期化ステージは Q&A なしで直接完了し、承認や学びの儀式は走りません。図3: ステージ実行のシーケンス図
ロードから承認までの流れを、コンダクター / エンジン / レビュアー / 人間の間で示します。
6. まとめ
この記事では、オーケストレーターを2つの視点から見てきました。
1つ目は、コンダクターと決定論エンジンの分業です。エンジン（
aidlc-orchestrate.ts）はステージ間の routing をすべて所有し、状態を変更せずに next ごとに型付き指令を1つ返します。コンダクター（/aidlc の司会役）は、その指令が名指しした一手の内側で実行の品質に責任を持ち、動いた結果を report で報告します。「誰が何を決めるか」の切り分けが、この分業の核心です。2つ目は、
/aidlc 実行時に内部を流れる制御の道筋、フォワーディングループです。next → 指令 → 実行 → report を done まで繰り返し、report の往復が遷移を確定させて次の next が新鮮な状態を読みます。指令の種類は、実行時に発行される8種類（load-steering / run-stage / invoke-swarm / ask / print / error / done / parked）と、契約上定義される10種類（8種類＋未発行の dispatch-subagent / present-gate）という関係で理解できます。この2点を押さえておけば、次に
/aidlc を実行したとき、画面の裏でどんなループが回り、どこで判断が人間に差し出されるのかを追えるはずです。Series: AI-DLC Workflow V2の解説 (31 articles)
- …
- 24AI-DLC Workflow V2のオーケストレーター: `/aidlc` の内側で何が起きているか This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article