ccg-workflow レビュー: Claude Code を多モデル指揮官に変える Go ブリッジの実像

単一モデルの壁を「委譲」で崩すという発想

ccg-workflow が解こうとしているのは、コーディングエージェントに 1 つのモデルだけを使わせたときの限界である。README は CCG を「a workflow engine for Claude Code」と位置づけ、Claude を multi-model orchestrator に変えると説明する。ポイントは Claude を置き換えるのではなく、Claude を指揮官として残す点だ。分析やレビューといった工程を Codex (OpenAI)、Grok (xAI)、Kimi Code (Moonshot)、Antigravity へ振り分ける。想定読者は、Claude Code をすでに使い込んでいて、別モデルの視点をレビュー工程に混ぜたい個人開発者や小規模チームである。モデルごとに得意分野が違うという前提に立ち、1 つのモデルの自己採点に頼らないワークフローを組みたい人向けの道具だと言える。

Claude が指揮し、Go バイナリが橋を架ける構成

README の Architecture 節によれば、中心にあるのは Claude Code であり、これが意図を分析し、戦略を選び、ワークフロー全体を管理する。状態の維持を担うのが Hook Engine で、毎ターン状態を注入することでコンパクション後も Claude が文脈を失わないと説明されている。外部モデルとの接続は codeagent-wrapper というコンパイル済みの Go バイナリが担当し、並列分析とレビューを仲介する。つまりデータの流れは、Claude Code が意図を解釈し、codeagent-wrapper 経由で外部モデルへ問い合わせ、返ってきた結果を Claude 側の計画に統合する、という形になる。Go で書かれているのは配布バイナリとして動かすためだと推測できるが、README はその理由までは述べていない。リポジトリの主要言語が Go である一方、導入口が npm パッケージである点は、Node.js 側のラッパーと Go バイナリの二層構造を示している。

/ccg:go 一発でタスク定義が書き出されるまで

README は /ccg:go の実行例を載せている。利用者が「add JWT authentication to this API」のように依頼を書くと、エンジンはまず git status、技術スタック、ファイル構成といったプロジェクト文脈を読む。次に feature / L complexity / backend / high risk のように分類し、full-collaborate という戦略を選ぶ。そして .ccg/tasks/add-jwt-auth/task.json を作成し、Codex と Gemini による並列分析を起動する。ここで一度ハードストップが入り、生成された計画に対して利用者の承認を待つ。承認後に Agent Teams Builders が並列実装へ進む、という流れだ。注目したいのは、タスクの状態が .ccg/tasks/ 配下の JSON としてディスクに残る設計である。会話ログではなくファイルとして残るため、作業の再開や差分確認がしやすい半面、リポジトリ内にツール固有のディレクトリが生えることになる。

導入コマンドと設定の入口

導入手順として README が示すのは npx ccg-workflow の一語である。インストーラは対話形式で、Step 1 で API プロバイダを選択する。スポンサーである APIMart は Anthropic 互換エンドポイントを提供しており、Claude Code 本体の API プロバイダとしても使えると README は説明している。DeepSeek Harness 向けの構成も同じパッケージに同梱されており、npx ccg-workflow dsh install で全プロファイルへ、--profile <name> を付ければ特定プロファイルへインストールできる。npx ccg-workflow dsh list で導入済みプロファイルを確認できる。プリビルドバイナリは preset というリリースで配布されており、codeagent-wrapper がその中身にあたる。設定キーの全量は README に列挙されていないため、プロバイダ選択以降の詳細は公式ドキュメントを参照する必要がある。

外部 CLI 依存と .ccg/ ディレクトリという代償

見逃せない制約が 2 つある。第一に、Claude Code 側の構成は外部 CLI とバイナリブリッジを前提としている。README は DeepSeek Harness 版の利点として「No external CLI, no binary bridge, no cold-start tax」を挙げており、これは裏を返せば従来構成が外部 CLI とブリッジに依存していることの表明である。Codex や Gemini の CLI を別途導入できない統制環境では、この経路がそのまま使えない。第二に、タスク定義が .ccg/tasks/<task-name>/task.json としてリポジトリ内に書き出される。生成物をバージョン管理に含めるか除外するかは利用側の判断になるが、除外設定を忘れるとタスクファイルがコミットに混ざる。並列実装を Agent Teams Builders が担う以上、同時に複数のタスクを走らせたときのファイル衝突は利用者の設計責任になる。

DeepSeek Harness 版との違いが示す設計の分岐

同じリポジトリに dsh-ccg という別系統が同梱されている。役割分担のマトリクスは共通だが、動作の土台が異なる。dsh-ccg はすべてのホップがプロバイダの API リクエストで完結し、外部 CLI もバイナリブリッジも介さない。加えて Claude Code 側ではきれいに実現しにくい 2 つの機能を挙げている。1 つは Model panels で、1 つの役割に複数モデルを割り当てて同じ依頼を独立に答えさせ、会話内に並べて表示する。投票も平均もせず、意見の不一致そのものを結果として扱う。もう 1 つは ccg_team による Live teammates で、役割をターンをまたいで生存する同僚として雇い、ファイルの所有権を持たせ、衝突する採用は警告ではなく拒否される。採用のたびに承認を求める点も明記されている。同じ作者による別実装が併存していることは、Claude Code 経由の構成が万能ではないという判断の表れだと読める。

どの層に賭けるかを決めてから入れる

MIT ライセンスで公開されており、fork や改変の自由度は高い。ただし同梱される codeagent-wrapper はコンパイル済みバイナリとして配布されるため、ソースから再現ビルドしたい場合は Go 側のビルド経路を自分で確認する必要がある。アップグレードは npm パッケージの更新とバイナリの更新が連動するため、片方だけを固定すると不整合が起きうる。依存の更新頻度は README からは判断できない。採用の判断は、Claude Code を主軸に据えたまま複数モデルのレビュー工程を足したいのか、それとも外部 CLI を挟まない dsh-ccg 側の構成に寄せるのか、という選択と切り離せない。両方を同時に評価しようとすると、検証すべき設定面が二重になる。

編集部の結論

採用を検討すべきなのは、すでに Claude Code を日常的に使い、Codex や Gemini のアカウントも持っていて、単一モデルの出力を別モデルにレビューさせたい開発者だ。逆に、モデルを 1 つに絞ってコストと再現性を管理したいチーム、外部 CLI のインストールを統制している環境、そして .ccg/tasks/ 以下にタスク定義を書き出す挙動を許容できないリポジトリには向かない。導入前に確認すべきは 3 点で、第一に codeagent-wrapper がどのモデルへどう接続する設定を要求するか、第二に .ccg/ ディレクトリが .gitignore の対象になっているか、第三に MIT ライセンスの範囲で同梱バイナリが再配布されているかどうかだ。

公式情報源

1. fengshao1227/ccg-workflow on GitHub
2. License: MIT
3. Project website
4. README
5. Releases