Claude・Codex・Gemini の三者合議を /ccg で回す — 単一モデルの盲点を減らすマルチ AI 運用

Posted at 2026-04-24

この記事の対象読者と得られること

対象読者	この記事で得られること
マルチ AI 運用を検討中のテックリード	3 CLI を並列で回す具体手順
単一モデルの判断に不安を感じている方	異なる訓練データの合議で盲点を潰す発想
tmux / 並列開発に興味がある方	ペイン分割と成果物保存の実装例

はじめに

近ごろ筆者は、設計レビューや仕様の壁打ちで「本当にこの判断で良いのか」と立ち止まる場面が増えました。理由は単純で、同じモデルに何度聞いても似た答えが返ってくるからです。

単一モデルだけに相談する運用は、速度は出るものの、訓練データや RLHF の癖が判断に入り込みます。結果、得意領域では鋭く当てる一方で、苦手領域では「根拠の薄い自信」が出がちです。

本記事では、oh-my-claudecode プラグインが提供する /ccg コマンドを使い、Claude・Codex・Gemini の 3 者に同じ問いを並列で投げ、Claude が最終統合するという運用を紹介します。

/ccg は「Claude / Codex / Gemini」の頭文字です。3 者合議を 1 コマンドで回すためのスキルという位置づけです。

背景: 合議 AI という発想と 2026 年春のエコシステム

合議 AI という発想はどこから来たか

合議型の AI 運用は、ある日突然出てきた概念ではありません。ルーツを辿ると、機械学習の古典的な手法であるアンサンブル学習にたどりつきます。複数の弱学習器を組み合わせて精度を底上げする発想は、LLM の世界でも形を変えて受け継がれてきました。

代表的な例として、self-consistency（2022 年の論文で提案）と tree-of-thoughts（2023 年に登場）が挙げられます。前者は同じ問いに対して複数の推論経路を並行させ、多数決で答えを決める手法です。後者は推論を木構造で広げ、分岐を評価しながら進めます。どちらも「1 本の推論だけでは見落としが出る」という前提に立っている点が共通しています。

2024 年以降、この発想は製品レベルにも降りてきました。Claude Research、OpenAI Deep Research、Gemini Deep Research はいずれも内部で複数のモデルやエージェントを協調させ、1 つの答えを組み上げる形を取っています。ユーザーから見えるのは 1 つの回答ですが、裏では multi-model ensemble が回っているケースが増えています。

こうした流れの延長に、個人やチームが CLI レベルで合議を組み立てる試みが出てきました。oh-my-claudecode はその一例です。公式ドキュメントを読むと、zsh の oh-my-zsh にインスパイアされており、フレームワークとしての拡張性を優先した設計思想が見えます。スキル・コマンドを追加しやすく、サードパーティの貢献を取り込みやすい構造になっています。

/ccg が解決したかった課題は、素朴に言えば 2 つです。1 つ目は単一モデルの盲点、つまり訓練データや RLHF の偏りによる判断のズレです。2 つ目は「根拠の薄い自信」で、モデルは間違った回答でも断定的に返すことがあります。合議に乗せれば、3 者のうち 1 者だけが違う主張をした場合に、そのズレが可視化されます。人間が最終判断する材料として使えるわけです。

マルチ AI CLI 市場の 2026 年春時点

視点を市場側に移すと、マルチ AI CLI の選択肢はこの 1 年でぐっと増えました。2026 年 4 月時点で筆者が目にしている範囲でも、いくつか挙げられます。

Cursor の agents 機能 — 複数のサブエージェントを内部で回し、タスクを並列化
Aider の multi-model モード — architect / editor で異なるモデルを割り当てる運用
Goose — Block 社の OSS で、Tool 連携と multi-provider を前提に設計

どれも思想は近く、「1 モデルで完結させない」方向に寄せてきています。背景には、開発者界隈で言われるようになった「指揮者 AI」論の広がりがあります。Addy Osmani や Raine Virta らの発信が象徴的で、複数モデルを束ねる指揮者層をどう設計するかが議論の中心になりつつあります。

契約プラン側の変化も見逃せません。かつては ChatGPT Plus だけで済ませる開発者が多数派でしたが、2026 年に入ってからは ChatGPT Pro・Claude Pro・Gemini Advanced の 3 者契約が珍しくなくなりました。筆者の周囲でも、月 60 ドル前後を「3 者セット」で払うエンジニアが増えている体感があります。

もう 1 つの追い風が、プロジェクトコンテキストファイルの標準化です。AGENTS.md・CLAUDE.md・GEMINI.md の 3 つが広く使われるようになり、同じプロジェクトで複数 AI を並行運用する土台が整ってきました。/ccg はこの流れと親和性が高く、各 CLI が同じリポジトリのコンテキストを読めるため、問いを揃えやすくなっています。

ここまでをまとめると、合議 AI の発想はアンサンブル学習の延長線上にあり、2026 年春の時点ではマルチ AI CLI 市場の拡大と契約プランの多様化、コンテキストファイルの標準化が同時進行しています。/ccg はその流れを個人の CLI ワークフローに落とし込む 1 つの選択肢という位置づけです。

なぜ三者合議なのか

単一モデルに聞くだけでは見落としが出る構造

LLM は「確率的に尤もらしい回答」を返す仕組みで動きます。問題は、尤もらしさの基準がモデルごとに違うことです。訓練データ・RLHF の方針・safety layer の設計が違えば、同じ質問に対する「もっともらしい答え」もずれます。

筆者が実際に感じた偏りを、3 モデルで比べた体感として並べます。ケースによって逆転することも当然ありますので、あくまで傾向の話として読んでください。

モデル	強く出る傾向	弱く出る傾向
Claude	長文の構造化、文章の読みやすさ、安全寄りの助言	最新のライブラリ固有の細かい仕様
Codex (GPT 系)	アーキ判断、エッジケース列挙、コードの網羅性	日本語の自然さ、文体の統一
Gemini	UI / UX 判断、Google エコシステム連携、検索裏付け	長い推論チェーンでの首尾一貫性

この 3 者を並列で回し、Claude 側で統合するのが /ccg の発想です。どれが最強かを決めるのではなく、「同時に聞く運用に乗せる」という切り口です。

それでも合議は銀の弾丸ではない

3 者が揃って同じ誤りを返すケースも存在します。訓練データの源流が似通っているときは特に起きやすく、結果として「3 者合意だから正しい」という過信が危険になります。

ですので、以降では「人間が最終判断する前提での時短ツール」として紹介します。

`/ccg` とは何か

仕組みの概要

/ccg は oh-my-claudecode プラグインに含まれるスキルで、内部的には以下のような流れです。

ユーザーが 1 つの質問を渡す
/ask codex と /ask gemini が並列で走る
Claude Code 本体が両者の回答と自分の回答を突き合わせる
差分・合意点・対立点を整理して synthesize する

Claude Code が orchestrator 役を兼ねる点が、この仕組みの肝です。Codex・Gemini の出力を「読み手」として評価し、自分の見解と対比させてから統合します。

成果物の保存場所

プラグインの既定では、各モデルの生回答は .omc/artifacts/ask/ 以下に日時付きで保存されます。後で差分を確認したり、判断の根拠を残したい場面で便利です。

artifacts には生のプロンプトと回答がそのまま残ります。機密情報を扱う場合は、保存先をリポジトリ管理対象から外すか、プロジェクトごとに .gitignore で明示的に除外してください。

インストールと設定

プラグイン導入

Claude Code の plugin marketplace 経由で oh-my-claudecode を追加します。現時点の実行例は以下です。

# Claude Code 内で実行
/plugin marketplace add yeachan-heo/oh-my-claudecode
/plugin install oh-my-claudecode

導入後に /ccg がコマンド候補に出てくれば成功です。出てこない場合は、プラグインの再読み込みまたは Claude Code 本体の再起動を試します。

3 つの CLI の認証

/ccg は内部で 3 つの CLI を呼び出します。事前にローカルで動く状態にしておく必要があります。

ツール	代表的なログイン方法	前提プラン例
Claude Code	`claude login`	Claude Pro または API
Codex CLI	`codex auth login`	ChatGPT Plus/Pro または API
Gemini CLI	`gemini auth login`	Google アカウント

各 CLI は独立して認証情報を持ちます。片方だけ切れている状態だと /ccg が中途半端に落ちますので、導入直後は単独での動作確認を勧めます。

# 動作チェック例
claude --version
codex --version
gemini --version

実行アーキテクチャ

tmux ペイン分割でログを並べて見る

/ccg は 1 ターミナルで完結させても動きますが、3 モデルの出力を同時に眺めたい場合は tmux のペイン分割が便利です。

# 例: 左に Claude、右上に Codex、右下に Gemini
tmux new-session -s triad
# ペイン分割
# Ctrl-b % (縦分割) Ctrl-b " (横分割)

筆者は開発機では iTerm2 側で 3 ペインに分ける運用もしています。tmux が苦手な方は、iTerm2 の Cmd+D と Cmd+Shift+D の組み合わせで同じ見た目になります。

成果物の流れ

各モデルの回答は .omc/artifacts/ask/YYYYMMDD-HHMM-<モデル名>.md のような命名でディスクに落ちます。筆者の運用では、重要な意思決定の日だけ artifacts を別ディレクトリに手動退避して、後から PR 説明に引用する形を取っています。

役割分担の推奨

得意を活かす問いかけ

「どの問いをどこに投げるか」を固定する必要はありません。ただし、問いの質を上げたい場合は、以下のような役割分担を想定して書くと、合議の差分が濃く出ます。

観点	主に参照するモデル	問いかけの型
アーキ判断	Codex	「この設計のトレードオフを構造的に列挙してほしい」
UI / UX	Gemini	「画面遷移として自然か、代替パターンはあるか」
文章・要約	Claude	「3 者の意見を統合し、日本語で整理してほしい」
安全性	Claude	「この仕様で抜ける攻撃ベクトルを挙げてほしい」

もちろん、実際はモデルによって逆転することもあります。大事なのは「各モデルに別角度の問いを同時に投げ、合議で差分を炙り出す」ことで、どのモデルが優勝かを決めることではありません。

実演: 「この設計、筋は良いか？」

ここからは、擬似ログの形で /ccg の動きをイメージします。実ログそのままではなく、短く整えて再構成しています。

投げた問い

/ccg

次の設計をレビューしてください。
- 目的: ユーザー通知を複数チャネル (メール / Slack / Push) で送る
- 構成: Notification Service が Kafka に publish、各 Channel Worker が consume
- 懸念: 同一通知の重複配信、チャネル間の優先度制御、失敗時の再送

3 者の要点（擬似）

ここは筆者がテスト実行したログを要約・匿名化したものです。実際の回答はモデルのバージョンで変わります。

Codex の要点

Kafka consumer の at-least-once 配信を前提にすると、重複は必ず出る
重複排除キーを user_id + notification_id + channel で持ち、Redis SETNX で TTL 付き制御
優先度は topic 分割（notify.high / notify.normal）か、consumer group の weight で表現

Gemini の要点

ユーザー体験として、メールと Push が同時に届くと煩わしい
「Push が既読ならメール送信を抑制する」導線を UX 側に用意すべき
優先度制御より、ユーザー側の通知設定を先に設計したほうが納得感が出る

Claude の要点（synthesize）

技術面は Codex の重複排除キー案が堅実。TTL の値はチャネルごとに変える必要あり
Gemini の UX 観点は見落としていた。配信順の設計と UI 通知センターを並行で考える
今の設計は筋は悪くないが、「既読連携」「ユーザー通知設定」の 2 点が抜けている

この 3 枚を並べて見ると、Codex 単独なら設計は合格、Gemini 単独ならユーザー視点で要改善、となり、判断がぶれます。/ccg のありがたさは「どこで判断がぶれるか」を可視化してくれる点にあります。

コストモデル

月額の目安

3 モデルを日常的に回すと、プラン契約が必要になります。筆者の現在の契約を例に、概算を置きます（為替 1 ドル 150 円前提、2026 年 4 月時点の公開価格を参考に概算）。

契約	月額（概算）	主な用途
Claude Pro	20 ドル	Claude Code 本体、synthesize
ChatGPT Plus / Pro	20 ドル〜	Codex CLI、アーキ観点
Gemini Advanced	20 ドル前後	Gemini CLI、UX 観点

合計で月 60 ドル程度、円換算でおよそ 9,000 円台というのが体感です。API 従量課金に切り替えると上振れすることもありますので、まずは定額プランで使用感を確かめるのが現実的だと思います。

公開価格は各社の料金改定で変動します。導入前に各社の最新プラン表を必ず確認してください。

コスト対効果の考え方

1 つの設計判断のやり直しコストを考えると、1 回の判断ミスで数日分の工数が吹き飛ぶことは珍しくありません。月 9,000 円で「重要判断の合議」が常時手元にある、と捉えると納得しやすいと感じました。一方で、軽い質問まで全部 /ccg に流すのは過剰です。使い分けの線引きは後述します。

落とし穴

意見が割れたときの判断

3 者が割れたとき、多数決で決めると危険です。先に書いたとおり、モデル間には訓練データの偏りが残ります。割れたときは、以下の順で人間が判断します。

具体的な数値・仕様・制約に照らして、どの回答が事実に整合するか
対象ドメインで強みが出やすいのはどのモデルか（過去の実績で判断）
それでも迷うなら、追加で問いを絞り込み、再度 /ccg に投げる

認証切れ

一番多いトラブルは、3 つのうちどれかの認証が切れている状態です。/ccg 実行時に片方だけ空回答になるため、合議として機能しません。週に 1 回くらい、単独で codex --version や gemini --version を叩いて動作確認しておくと安全です。

出力量のばらつき

モデルによって、同じ問いでも返ってくる長さが極端に違う場合があります。Claude が長文、Codex が箇条書き短め、Gemini が中間、というパターンが多い印象です。synthesize 時に「箇条書きでまとめて」「300 字以内で」と指示すれば、ばらつきは抑えられます。

使い分けの線引き

筆者は次のように分けています。断定するつもりはなく、あくまで今の運用です。

場面	推奨
軽い質問・調べ物	Claude Code 単独で十分
設計レビュー・重要判断	`/ccg` で合議
コードのちょっとした修正	Claude Code 単独
セキュリティ設計・契約周り	`/ccg` + 人間レビュー

tmux が苦手な人向けの代替

iTerm2 split のセットアップ

tmux のキー操作を覚えるのが重い場合、iTerm2 の split だけで同じことができます。手順を簡単にまとめます。

iTerm2 を起動し、Cmd+D で縦に分割
右ペインにフォーカスを移し、Cmd+Shift+D で横に分割
左ペインで claude、右上で codex、右下で gemini を起動
左ペインで /ccg を実行すると、各 CLI が自分のペインで応答する

iTerm2 を使わない環境でも、VS Code の統合ターミナルで split を作れば似た運用ができます。WSL2 の Windows Terminal でも pane 機能が使えますので、環境を選びません。

他の合議・並列手段との比較

合議・並列手段 4 種の比較

/ccg を評価する際は、「他にどんな選択肢があるか」を並べて眺めるのが近道です。2026 年 4 月時点で筆者が実際に触っている範囲で、代表的な 4 種類を比較表にまとめました。oh-my-claudecode は本記事執筆時点で 2026 年春の版を前提にしています。

軸	`/ccg`	task-query-codex + gemini 個別	tmux 手動分割	Cursor multi-agent
セットアップ	plugin 追加で 1 分程度	Skill を個別に導入	自力で構築	Cursor に依存
統合者モデル	Claude 固定	各スキルごとに異なる	人間が統合	Cursor の既定
成果物保存	`.omc/artifacts/ask/` に自動保存	スキル個別の出力	基本なし	Cursor 内部に保存
合議精度	高（3 者並列 + synthesize）	中（逐次 or 個別）	人のまとめ力に依存	中（モデル選択に制約）
月額目安（例）	約 60 ドル（3 者契約）	約 60 ドル	約 60 ドル	+ 20 ドル前後

この 5 軸で見ると、/ccg は「セットアップの軽さ」と「成果物の自動保存」で優位に立ちます。一方で Claude が統合者に固定されている点は、Claude の文体や判断傾向に寄る面があります。統合者自体も交代させたい場合は、個別スキルや tmux 手動運用のほうが柔軟です。

Cursor multi-agent は IDE 内で完結する強みがありますが、契約が 1 本増える点とエディタ依存という制約が付きます。CLI 中心で作業する筆者の運用には噛み合いにくく、採用には至りませんでした。

`/ccg` を使うべき場面

判断マトリクスとして、どの手段をいつ選ぶかを整理します。あくまで筆者の現在の運用例で、読者の環境次第で重みは変わります。

/ccg — 設計判断、アーキ相談、価格判断など、後戻りコストが大きい意思決定。合議の手間を払う価値が出やすい
個別スキル（task-query-codex / task-query-gemini） — 特定のモデルだけにレビューを依頼したい場面。Codex の構造化レビュー、Gemini の UX 視点など、狙い撃ちで投げたい時
手動 tmux — 特殊な CLI 制約がある環境、プロキシや閉域網で一部ツールしか通らない場合
単一モデル運用 — 日常的な実装タスク、軽い質問、テストコードの叩き台。3 倍のコストを払うほどの判断ではない場面

「重要判断は /ccg、普段は単一モデル」という線引きが、筆者にとっては現実的でした。すべての質問を /ccg に投げる運用は、コスト面でも認知負荷面でも持続しにくい印象です。

3 倍コストの見返りはあるか

気になるのは、3 モデル契約の経済性でしょう。筆者の体感では、3 モデル合議は単一モデル比で判断精度が +20〜35% ほど上がるタスクがあります。設計レビューや要件整理のように「抜け漏れを潰すのが価値」な場面で効きやすい印象です。逆に、実装の細部をゴリゴリ書くタスクでは差が出にくく、単一モデルで十分な場合が多いです。

一方で、デメリットも正直に書きます。まず認知負荷が増えます。3 者の回答を読み比べる時間が単純に 3 倍になり、synthesize ステップで整理しないと頭が追いつきません。/ccg の強みは、この整理を Claude が引き受けてくれる点にあります。

速度面も単一モデル運用より遅くなります。並列で走らせても、最も遅いモデルのレスポンスに引っ張られるため、trailing tail が全体を支配します。経験的には、3 者並列で 1 分前後追加で待つイメージです。

月 60 ドルの見返りについては、「1 回の設計ミスで数日吹き飛ぶ」状況を月に 1 回でも防げれば元が取れる、という考え方をしています。読者の時間単価や判断の影響範囲によって、損益分岐点は動きます。ですので、まずは 1〜2 週間だけ有料契約を並べてみて、合議の質が自分の判断に効くかを確かめるのが現実的な入り口だと思います。

まとめ

マルチ AI 運用は「どのモデルが最強か」を決める競技ではなく、「どう並列化して盲点を潰すか」の設計だと感じています。/ccg は、その並列化を 1 コマンドに封じ込めた便利な入り口です。

筆者も全面的に合議に頼っているわけではなく、日々の軽い作業は Claude Code 単独で済ませています。ただ、設計判断やレビューで 30 分悩む場面では、/ccg を叩くだけで別視点が 2 枚増えるのは大きいです。

読者の環境や契約プランによって相性は違うと思いますので、まずは 1 日だけ /ccg を設計判断の場面で使ってみて、合議の質が自分の判断に効くかを肌で確かめてもらえればと思います。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up