Language: 日本語

Coding Agent用タスクグラフ Ramune の紹介

複数のCoding Agentへ仕事を割り当て、検証済みの変更を順番に統合するタスクグラフ、Ramuneを紹介します。

Ramuneは、複数のCoding Agentへ仕事を割り当て、検証済みの変更だけを順番に統合するタスクグラフ実行機構です。

会話の中にTODOを書く代わりに、.ramune/graph.jsonへタスク、依存関係、担当、実行結果を保存します。セッションが切れても、次のAgentはグラフを読んで続きから作業できます。

現在はwebapp-blueprintのtools/ramune/に同梱しており、Claude Code、Antigravity、Codex CLIから同じグラフを操作できます。

起動

最初に共有MCP serverを起動します。

mise run mcp:ramune:serve

すべてのsessionとgit worktreeが一つのserverへ接続します。二つ目のserverはport bindで失敗するため、グラフへ書くprocessを一つに保てます。

serverを起動しただけではRamune modeには入りません。 Agentへ「Ramuneでこのtaskを進めて」と依頼すると、Orchestratorがsessionをactiveにします。これは制限ではなく、通常の編集とRamuneの権限管理を分けるための選択です。

Plannerは依頼を依存関係付きのDAGへ分解します。

        ┌─ APIを変更 ─┐
start ─┤              ├─ E2Eを更新 ─ end
        └─ 画面を変更 ┘

依存関係がないnodeは並列にclaimできます。 read-only viewerでは、pending、running、blocked、統合待ちの状態を一覧できます。

pnpm --filter @webapp-blueprint/ramune-viewer dev

Workerは担当nodeを実装できますが、グラフ構造を変更できません。 Plannerはグラフを編集できますが、repositoryのファイルは編集しません。

この分離はpromptだけに書かず、PreToolUse hookでも検査します。 clientごとの入力はadapterで共通policyへ変換します。

repositoryを変更するWorkerには、隔離したgit worktreeを割り当てます。 Workerはcandidate commitを作り、統合待ちとして提出します。

Worker A ─→ candidate A ┐
                        ├─→ Integrator ─→ mise run check ─→ canonical
Worker B ─→ candidate B ┘

Workerは並列に動きますが、Integratorはcandidateを一件ずつ処理します。検査が通り、期待していたcanonical HEADも一致したときだけpublishします。

claimにはsessionとassignmentを識別するfenceが付きます。古いWorkerが遅れて結果を返しても、現在の割当と一致しなければ拒否されます。

Workerが仕様不足や設計上の矛盾を見つけた場合、ramune_request_replanでPlannerへ戻せます。 merge conflictが起きた場合は、serverがconflict解消nodeを追加し、通常のWorkerと統合経路で解消します。

WorkerまたはIntegratorが終了した場合、Orchestratorは終了とGitの状態を確認してからramune_abandon_assignmentを実行します。時間切れによる自動再割当はしません。

一方、Orchestratorやserverが終了した後にsessionを継続するときはramune_resumeを使います。 Worker死亡時の回復とsession再開は別の操作です。

複数の独立作業があり、最後に同じrepositoryへ統合するtaskに向いています。大きめのrefactoring、複数packageの変更、調査と実装を分けられる作業などです。

一つのファイルを少し直すだけなら、グラフを作る方が面倒です。常に有効にしていないのもそのためです。

RamuneはAgentを賢くする仕組みではありません。誰が何をしていて、どの変更まで検証済みかを見失わないための実行基盤です。

実装はwebapp-blueprintのtools/ramuneで公開しています。