情報

属する価値: エージェンティックループエンジニアリング · マルチセッションオーケストレーション

カンバンモードは、一度にひとつの SPEC を単一セッションで進めていた旧モデルをマルチセッションボードに置き換えます。リードセッションがひとつ指揮を執り、同伴セッションがそれぞれの worktree で同時に作業し、完了したカードがボードを流れていきます。そのボードの骨格が Origin-Trail Chain です。

セッションランチャーに --kanban(短縮形 -k)スイッチを付けて開始します。新しいサブコマンドでも新しいランタイムでもありません — ランチャーがカンバンモード環境を武装するための進入契約にすぎません。チェーンの3段階(plan → run → sync — レビュー判定は sync ゲートが吸収)とヒューマンゲートは、既存の /moai goal エンジンと full-pipeline チェーニング規則をそのまま継承します。カードを複数枚まとめて番号付きレーンで同時に運ぶ大量処理の形はファクトリーモード(-f)として分かれており、このページの下の「ファクトリーモード」節で扱います。

このページでは、カンバンモードの進入条件、Origin-Trail Chain の設計、チェーンの段階、そして「何が自動化されていないか」までを扱います。ワークフローコマンド視点の短い紹介は、/moai 統合コマンドを先に参照してください。

情報

比喩: カンバンボードの各カードはひとつの worktree セッションです。カードがボード上を流れるように、セッションがチェーンを流れます。

旧モデルでは、ひとつの SPEC をひとつのセッションが最初から最後まで担当していました — plan を書き、run で実装し、sync でドキュメントを整えます。SPEC が大きくなると単一セッションでは支えきれず、コンテキストウィンドウの限界に当たるとセッションを分割する必要がありました。

カンバンモードはこの構造をボード視点に変えます:

• リードセッションがひとつ plan を書き、進行を調整します。
• run セッションが複数、それぞれの worktree で並列に実装します。
• 各セッションはボードのカードであり、カードは段階を経て流れていきます。

このマルチセッションボードが動くには、「このセッションはどこから来たのか」「親セッションは生きているか」「どこまで終えたか」を失わないことが必要です。この役割を Origin-Trail Chain が担います。

Origin-Trail Chain は、マルチセッション worktree の系譜(lineage)を追跡する append-only ツリーです。各 worktree セッションがノードになり、親子エッジが「このセッションはあのセッションから分岐した」を記録します。

チェーンは .moai/state/chain/events.jsonl に保存されます。すべての書き込みは O_APPEND で一行ずつ追記されます — 上書きも切り詰めもありません。カーネルが同時 append を直列化するため、複数セッションが同時に書いても一行が別の行を壊すことはありません。

flowchart TD
    Root["ルートノード
(primary checkout)"]
    Spawn1["セッション A
(worktree 1 · depth 1)"]
    Spawn2["セッション B
(worktree 2 · depth 1)"]
    Spawn3["セッション C
(worktree 3 · depth 2)"]
    Root -->|"node-enter"| Spawn1
    Root -->|"node-enter"| Spawn2
    Spawn1 -->|"node-enter"| Spawn3
    Spawn1 -->|"completion-edge"| Done1["マイルストーン完了"]
    Spawn2 -->|"completion-edge"| Done2["マイルストーン完了"]

3種類のイベントタイプがストリームに記録されます:

イベントストリームはフラットなファイルですが、読み込み時に BuildNodes() がイベントを再生して現在のノード状態を導出します。可変(mutable)なツリーファイルは存在しません。

各ノードは読み込み時に13フィールドを持つ状態ビューとして再構成されます:

同じ worktree パスを再利用するセッション同士が衝突することがあります — worktree を消して同じパスに再作成すると、2つのセッションが同じ worktree_path を持ちます。チェーンは (worktree_path, session_id) のペアでこれを区別します:

1. 一次キー: (worktree_path, session_id) ペアに正確に一致するノードを探します。
2. fallback: session_id が空か一致するノードがなければ、そのパスに最後に進入したノードに解決します。

このメカニズムにより、/clear 後にセッションを再開する際「このパスの現在のノードは何か」を正確に復元できます。

Origin-Trail Chain が解く二つの問題があります:

深さの健忘 (depth amnesia) — 深くネストした worktree で /clear 後に再進入すると、「このセッションの祖先は誰か」が失われます。grep やスクロールバック考古学で復元する必要がありました。チェーンは origin_chain フィールドにルートからリーフまでの完全な ID 経路を非正規化(denormalize)して保持するため、探索なしで O(1) で系譜を復元します。

dead leader socket — リードセッションが死んでいるのに子セッションがそれを知らない状態です。子は死んだリーダーを待ったまま止まっています。チェーンは completion-edge イベントでセッション終了を記録するため、ハートビートの鮮度(exited_at 導出)と合わせて、子が親の状態を検知できます。

無限に深くネストするセッションツリーは複雑度を制御不能にします。チェーンは深さに上限を設けて複雑度を管理します — 上限を超えるとそれ以上深いスポーンを拒否し、より浅い階層で作業するよう誘導します。

worktree をスポーンする時点ではまだセッション ID が分かりません — Claude Code ランタイムが子プロセスを起動した後にセッション ID を割り当てるためです。そこで2段階に分けます:

1. スポーン時: node-enter イベントを append しますが session_id は空のままにします。このとき MOAI_CHAIN_NODE_ID 環境変数で子プロセスにノード ID を渡します。
2. 子 SessionStart: ランタイムがセッション ID を割り当てたら、node-update イベントで session_id を backfill します。

このプロトコルのおかげで、スポーン時点とセッション ID 割り当て時点の間の隙間を埋められます。

v3.1 では、カンバンモードの進入経路は最後までつながっています。ただし表面ごとに完成度が異なるため、今コマンドで触れるものと、まだライブラリ層にしかないものを区別しておきます。

• -k / --kanban ランチャースイッチ — moai cc と moai glm の両方に配線されています。引数なし(または SPEC 識別子と一緒)に渡すとリードとして進入し、-k --name <ロール> 形式で渡すと、すでに開いているランに同伴セッションとして合流します。混合バックエンドランチャーの moai cg はセンチネルとともに拒否します。
• -f / --factory ランチャースイッチ — ファクトリーモード専用の進入です。moai cc -f N はリードとともにレーン lane-1…lane-N の実行コマンドを知らせ、moai cc -f lane-<n> でレーンを1つずつ増やします。下の「ファクトリーモード」節で扱います。
• ブートストラップ案内 — リードセッションが開くと、SessionStart フックがラン識別子と3つの同伴セッション実行コマンド(moai cc -k --name plan など)をユーザーの言語で出力します。同伴セッションに届く案内は、どのランに合流したかとセッション名を伝えます。名前はロールだけで付けられ(plan, run, sync)、同じロール名がすでに生存セッションに取られていれば次の番号が付きます(plan-1, plan-2, …)。案内にはバックエンドの推奨組み合わせと、セッションあたりの同時エージェント上限(10個)も一緒に載ります。
• セッションレコード — 進入したセッションのロール・バックエンド・対象 SPEC が記録されます。
• moai chain CLI — status(現在のノード要約)、lineage(ルートからリーフまでの系譜)、back(親ノードの再開目標とコマンド)、list(全ノードと鮮度)、prune(終了した古いノードをアーカイブに畳む)の5つのサブコマンドが動作します。下記の internal/chain/ 保存層がその背後にあります。
• ディスパッチ — カードを列の間で動かす主体はリードセッションのオーケストレーターです。規約は .claude/rules/moai/workflow/kanban-dispatch.md にあり、同伴セッションは人が各ターミナルで直接実行します。セッションが別のセッションを起動する経路はありません。

• internal/chain/store.go — append-only JSONL writer/reader。O_APPEND で一行ずつ追記し、壊れた行は skip + warn で読み飛ばします。
• internal/chain/node.go — WorktreeNode(13フィールド) + ChainEvent 型定義。
• internal/chain/populate.go — Populator: スポーン時ノード生成、セッション ID backfill、マイルストーン更新、completion-edge 記録、現在ノード解釈。
• GenerateNodeID — 単調タイムスタンプ + 乱数で、外部依存なしに ID 生成。

internal/kanban/ のボード状態ストアは、コードとしては完成しています — 5列の閉じた列挙(backlog → plan → run → sync → done)、primary checkout の一点に収束する単一起点状態ファイル、ファイルロック、破損復旧、SPEC フロントマター状態との調整(不一致を修正せず表示だけ行う)まであります。しかし、これを読み書きするプロダクションの呼び出し元がまだありません。つまり列位置はファイルではなくリードセッションの記憶と SPEC 状態で維持され、ボードを照会したりカードを動かしたりする CLI 動詞は存在しません。

注意

moai kanban というコマンドは存在しません。 カンバンモードの CLI 表面は、ランチャースイッチ -k と系譜照会コマンド moai chain だけです。

情報

スラッシュコマンドではありません: カンバンモードは Claude Code チャットの / コマンドではなく、セッションそのものを開くスイッチです。ターミナルでセッションを開始するときに付けます。

ターミナルで MoAI ランチャー(moai cc または moai glm)に --kanban(短縮形 -k)を付けて開始します。SPEC 識別子を一緒に渡すとその SPEC を目標にし、省略すると最初のプロンプトで plan フェーズを開始します。

# リードとして進入 — SPEC を目標にカンバンチェーン開始
$ moai cc --kanban SPEC-AUTH-001

# 短縮形
$ moai cc -k SPEC-AUTH-001

# 目標 SPEC なし — 最初のプロンプトで plan 開始
$ moai cc -k

# GLM バックエンドでも同じ進入
$ moai glm -k SPEC-AUTH-001

リードセッションが開くと、ラン識別子とともに3つの同伴セッション実行コマンドが出力されます。それぞれを人が別々のターミナルで直接実行してボードを埋めます。

# 同伴セッション — ロール名だけで合流 (run-id はリードの識別子)
$ moai cc -k --name plan
$ moai cc -k --name run
$ moai cc -k --name sync

進入が成功すると、ランチャーはカンバンモード環境(MOAI_KANBAN チェーンシード)をセッションに武装し、リードの SessionStart 案内がラン id と同伴セッションの実行コマンドを伝えます — 新しいランタイムでも新しいフックでもなく、すでにある機械の上に乗る進入契約です。

moai cc -k でリードを開くと、ラン識別子とともに同伴セッションごとに実行コマンドをひとつずつ表示します。運営者はそれをそれぞれ自分のターミナルで開き、4セッションのランを完成させます — リードが指図し、plan · run · sync がそれぞれの worktree で作業します。

カードはこう流れます。リードが plan セッションに作成を指示し、run セッションがその計画から実装を引き継ぎ、sync セッションがコードを SPEC と突き合わせて整えコミットします。レビュー判定は独立した列ではなく、sync ゲートが吸収します — sync 段階がレビュー・レンズを自ら回して判定を下します。各ディスパッチは、リードがそのフェーズの進行証拠を読んで確認した後にはじめて行われます。

3つの列の同伴セッションは、それぞれ下位エージェントを並列に呼べます。とくに plan セッションは、複数枚のカードの SPEC 作成をカードディレクトリごとに分けて並列 Agent() ワーカーへ fan-out します — 作成が1枚ずつ順番を待つことはありません。同時エージェント数はセッションごとに10個が上限です。ランチャーが同伴セッションに CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS の上限を注入するので、4セッションが同時にファンアウトを回してもマシンの容量は構造的に分割されます。

情報

なぜこの形か — 役割ごとのバックエンド。 設計と指揮は Opus、実装は GLM で動かします。同伴セッションを開くとき moai cc -k --name ... の代わりに moai glm -k --name ... を使うと、そのセッションは GLM バックエンドで合流します。高価なモデルは判断が必要な席にだけ置き、実装の分を安いバックエンドに流すこの配分が、マルチセッションランのトークンコストを持続可能にする核心です。セッション同士はメッセージをやり取りし、セッション間メッセージングは注入された --settings を通じて自動的に許可されています。

ブートストラップ案内が既定の推奨も一緒に知らせます。トークンの空きを優先するなら:

moai glm -k                    # リード — キューを見張ってカードを運ぶ席
moai cc  -k --name plan        # plan — 設計・判断は Claude
moai glm -k --name run         # run — 実装中心は GLM
moai cc  -k --name sync        # sync — レビュー・整理は Claude

理由は役割ごとに必要な推論の種類です。plan と sync は判断とレビューを回す列なので Claude に置き、run は実装中心なので GLM でコストを下げます。リードは判定を下す席ではなく、キューを見張ってカードを運ぶ席なので、待ち続けても安い GLM が合います。GLM リードの下で Claude の判定が必要になったら、judge という名前のセッションから抜け道を作ります — GLM リードが Claude を使う唯一の経路です。あるアカウントが 429 で詰まり始めたら、セッションをアカウントに分散して置く運用が効きます。この組み合わせはあくまで既定の推奨 — 別の組み合わせも、全セッションをひとつのバックエンドに統一しても構いません。

スクリーンショットのステータスラインに見えるモデルラベルは、撮影時のひとりの運営者のセッション構成を反映したもので、配布既定値ではありません。

情報

属する価値: マルチセッションオーケストレーション · トークノミクス

カンバンが「3つのロールが1枚のカードを段階ごとに運ぶ」形なら、ファクトリーモードは「番号付きレーン N 本が複数のカードを同時に運ぶ」形です。カードは列の間を移り歩かず、空きレーン1本へ丸ごと入り、そのレーンがセッションの中で plan → run → sync を順番に通過します — 各段階は Agent() の下位エージェントとして実行されます。進入は専用トークン -f です。moai cc -f 4 でリードとレーン4本を開き、moai cc -f lane-<n>(または moai glm -f lane-<n>)でレーンを1本ずつ増やします。

レーンごとの同時エージェント上限(10個)、順次起動の理由、レーン番号の所有(workers.json)、書き込みスポーンの worktree 隔離、カンバンと分かれる点の本編は、専用ページ ファクトリーモードが扱います。

4つのターミナルを目で追う代わりに、moai webなら同じ状態を1画面で見られます。カンバン画面はカンバン・チェーンボードとSPECパイプラインを並べて表示し、Overview・Specs・Monitor・Settingsの画面も付きます。

コンソールはループバックにのみバインドされます。詳しい使い方はmoai web コンソールを参照してください。

カンバンチェーンは full-pipeline 契約(ひとつの SPEC に対して run → sync の自動チェーンを結ぶ約定)を拡張します。3段階が順に進みます:

flowchart TD
    Entry["--kanban 進入
(目標 SPEC または最初のプロンプト)"] --> Plan["plan
SPEC 作成 + 独立監査"]
    Plan --> Gate1{"実装着手承認
(ヒューマンゲート)"}
    Gate1 -->|"承認"| Run["run
実装サイクル → AC 収束"]
    Gate1 -->|"却下"| Stop1["中断"]
    Run --> Sync["sync
レビュー・レンズ + ドキュメント・チェンジログ・完了"]
    Sync --> Done["チェーン完了"]

各段階の詳細な手順は、既存のチェーニング規則を継承します:

• plan — SPEC ドキュメントを作成し、独立監査(plan-auditor)が内容を検証します。/moai plan 参照。
• run — 実装サイクル(TDD または DDD)が受入基準(AC)に収束するまでコードを実装します。/moai run 参照。
• sync — sync ゲートがレビュー・レンズ(変更が触れた表面に合わせた観点)を自ら回してレビュー判定を下したうえで、ドキュメントを更新し、チェンジログを書き、フェーズを完了させます。/moai sync を参照。

カンバンモードが新しく載せるのはマルチセッションボード視点です — リードセッションが調整し、run セッションが並列に作業し、Origin-Trail Chain がその系譜を追跡します。チェーン段階自体の詳細な規則は、/moai 統合コマンドと /moai goal を参照してください。

バックログに積もるものの大半は小さな雑務です — 1行の修正、古くなった参照、フラグ名の変更。これらを plan → run → sync まで通すと、変更の価値より儀式のコストが大きくなります。そこでリードは、カードが backlog を離れるたびに3つのクラス(Class A · Class B · Class C)のいずれかに分類し、配車文にそのクラスを名指します。

クラス A は、確認された証拠だけで認めます。 3つの性質のうち2つは機械で確認できるため、実際に確認して引用します — 1ファイルに測定された diff(git diff --stat)と、マージされる HEAD の上でのグリーンの CI。残りの1つ(設計判断がないこと)は判断なので、配車文に書いて運営者が異議を唱えられるようにします。どちらか一方でも引用できないカードは、クラス A ではありません。根拠が「速い」であってはなりません — 速さは列を飛ばした結果であって理由ではなく、速さだけでクラス A を主張するカードは、急かされたクラス C です。

クラス B は plan だけを飛ばし、レビューは飛ばしません。 原因の立っていない欠陥こそレビューが捕まえるものなので、sync ゲートの審査はそのまま回ります。代わりに、原因確立の証拠 — 再現コマンドとそれが出力した内容 — をカードの進行記録に残し、run セッションが完了報告でそのパスを名指します。リードはそのパスを読んで原因を確認します — 主張を信じて通しません。

並列の視点で見ると、クラスは並列がどこから来るかを定めます。3つのセッションにカードを1枚ずつ丸ごと任せれば3枚のカードが同時に流れ、1枚のカードを3つの列にパイプラインで通せば1枚だけが流れます。パイプラインは、各列がまともな分担の仕事をするときにだけ引き継ぎコストを返します — それがクラス C のケースであり、plan 中の調査ファンアウトがクラス C 専用である理由でもあります。

このプロジェクトでは引数なしで /loop と入力すると、そのセッションがカンバンフォアマン (foreman) の 1 サイクルを無人で繰り返します。通常の反復修正ループではなく、バックログキューを見張ってカードを動かす監視・配車・回収のサイクルです。

1 回のイテレーションがやることは小さく、冪等です。

flowchart TD
    Start["bare /loop — 1 イテレーション開始"] --> Skill["moai-kanban-foreman スキルを読み込む"]
    Skill --> Fail{"スキルが無い、または
読み込みに失敗?"}
    Fail -->|はい| Stop["ループ停止 + 一行の理由
(代替プロトコルの即興は禁止)"]
    Fail -->|いいえ| Watch["キュー監視が未装着なら装着する"]
    Watch --> Check["バックログキューを確認"]
    Check --> One["カード 1 枚について配車または証拠回収
(1 イテレーションにつき最大 1 枚)"]
    One --> Report["2〜6 行の報告で閉じ、次を再スケジュール"]

三つの境界がこのループを縛ります。

• オペレーターに尋ねられません。 スキルが有効な間、AskUserQuestion はツールプールから外れます。見ている人がいない状態で回るループなので、尋ねる先がありません — 判断が要るものはイテレーションの出力に報告として残します。
• 仕事を作らず、配車するだけです。 バックログにカードを入れること (moai todo add) と次のカードを選ぶことは、依然としてオペレーターの行為です。フォアマンは既に選ばれたカードを空きレーンへ動かすだけです。
• 承認ゲートを代理で答えません。 実装着手承認をはじめとするヒューマンゲートは無人ループの中でも同じように発火し、フォアマンが代理で通すことはありません。

完了の判定は常に読んだ証拠です — レーンの返信ではなく、ディスクに残った進捗記録を読んでカードを動かします。1 サイクルだけ手で試したい場合は moai-kanban-foreman スキルを直接呼び出せます。

情報

リードひとつ、同伴3つ。 進入とディスパッチは v3.1 で動作します。ただし、列位置をファイルで保持するボード状態ストアにはまだ呼び出し元がなく、カードの現在位置はリードセッションと SPEC 状態が維持します。

使うとき — 複数の worktree セッションでひとつの SPEC(または複数の SPEC)を同時に進めるとき。Origin-Trail Chain でセッション系譜を追跡する必要があるとき。ひとつの SPEC を完了まで一気に進めるとき。同じパターンのカードが何枚も積み上がり、レーンに分けて並列処理したいときは、ファクトリーモード(-f)がその形です。

使わないとき — フェーズの間ごとに人が直接判断しながら中間成果物をレビューしたいとき(この場合は通常の plan → run → sync をターン単位で進めてください)。1〜2ターンで終わる短い作業。混合バックエンド(moai cg)を使わなければならないとき。

このページがしないことを明示します:

• 新しいサブコマンドではありません — --kanban はランチャースイッチであり、/moai kanban のような対話コマンドではありません。
• ヒューマンゲートをスキップしません — 実装着手承認、事前品質ゲート、ドキュメント範囲ゲートはそのまま発火します。チェーンが自動的に流れても、各ゲートで人の承認が必要です。
• サポートしないバックエンド — 混合バックエンドランチャーの moai cg ではカンバンモードが拒否されます。moai cg はひとつのバックエンドでリーダーを、別のバックエンドでチームメンバーを動かしますが、これはチェーンが前提とする「ひとつのセッション / ひとつのバックエンド / ひとつのチェーン」に矛盾するためです。拒否センチネルとともに、セッションは開きません。

• /moai 統合コマンド — ワークフローコマンド視点の短い紹介
• /moai todo — ボードにカードを入れるバックログキュー
• /moai loop — bare /loop で駆動する無人フォアマン: バックログキューを見張り、運営者が選んだカードを空きレーンに配分・証拠収集をひとつのセッションで繰り返す
• /moai goal — カンバンチェーンを駆動するゴールエンジン
• ファクトリーモード — カードをレーンへ丸ごと積んで複数枚を同時に運ぶ2つ目の形
• manager-lead リードコーディネーター — カンバン・ファクトリーのリードセッションでディスパッチを担う調整エージェント
• 自律連続ループ — /moai goal、/moai loop、ネイティブ /goal の所有権とガードレールの比較
• /moai run — run フェーズ自律性の配線。カンバンチェーンの run 段階が継承する規則
• ハーネスエンジニアリング — フェーズチェーニングと観測がハーネス設計の上でどう位置づくか
• ステータスライン — セッション系譜と worktree 状態がステータスラインにどう表示されるか