TL;DR
- Opus × GPT のサブスク利用可能モデルを組み合わせて、従量課金となる Fable 級の判断正確性能を実現する ClaudeCode の スキル
dual-engineを作成し、MIT ライセンスで公開しました。 - Claude Code(CC) と Codex(OpenAI) に独立して起案させ、相互に批判させ、両者が気づかないうちに共有している前提を、Web で裏取りするレッドチームが専従で叩き、最後に統合します。
- 処理時間や消費トークンは単発のおよそ 4〜5 倍です。スキルなので、常時 on ではなく、明示的に呼んだときだけ動きます。
- 狙いは「賢さを上げる」ことではなく、出来のばらつきを小さくする＝大きな失敗をなくす。下振れ＝ミス・抜け・事故を消すことです。
- リポジトリ: https://github.com/anode-llc/dual-engine
はじめに：高性能モデルが従量課金に移りつつある
2026 年 7 月、正式リリースされたFable 5 は、7/12以降従量課金へ移行するとアナウンスされています。
「一番賢いモデルを常用する」という使い方が、コスト的に成り立ちにくい場面が増えていきます。
今回のスキルを作った動機は、次の一言に尽きます。
圧倒的に低コストで使えるサブスク対象のモデルで、高性能モデルに近い判断品質を得たい！
素直な代替案は「安いモデルを複数系統で相互に反証させて、判断品質を確保する」ことですが、複数の AI を並べれば安心かというと、そう単純ではありません。重要な判断を AI に任せるとき、本当に怖いのは AI が間違えることそのものより、複数の AI が揃って自信満々に間違えることだからです。この記事は、その「揃って外す」を減らすために作った仕組みの設計と、うまくいった／いかなかった PoC の記録です。
何が問題なのか
対象にしているのは、間違えたときの損失が大きく、あとから引き返しにくく、答えが一つに決まらない考えごとです。具体的には、戦略の立案、撤退や集中の判断、市場規模や数値の見積もり、経営・人事・顧客に出す重要な資料の品質担保などです。こうした判断は、間違えたときのコストが大きく、あとから引き返しにくいという共通点があります。
ここで単体の LLM に「自分の答えを批判して」と頼んでも、限界があります。自己批判は、そもそも誤りを生んだのと同じ分布から出てくるため、自分が握っているバイアスを自力では消せません。
では複数の AI を並べて多数決を取ればよいかというと、これも足りません。同じような学習分布を持つモデルは、同じ前提を共有しやすく、同じ方向に揃って外すことがあります。素朴な多数決や「一致したら信頼」という設計は、この共有された盲点にはまったく効きません。むしろ一致が安心材料に見えてしまう分だけ危険です。
作ったもの：dual-engine deliberation
dual-engine は、この「揃って外す」を減らすための Claude Code スキルです。異なる学習系統の 2 モデル（CC と Codex）に独立して答えさせ、相互に批判させ、両者が合意した前提を外部のレッドチームが専従で崩し、最後に 1 つの改訂版へ統合します。
全体像は次のとおりです。
各段階は出力をファイルに書き出し、ストリームには 1 行の確認だけを流します。ファイルを唯一の正とすることで、オーケストレータのコンテキストを小さく保ち、言い換えによる意味のドリフトを防いでいます。
適したタスク・不適なタスク
このプラグインは万能ではありません。処理時間が単発の 4〜5 倍かかるので、それに見合うだけ「誤り・漏れのコスト」が大きい仕事にしか向きません。
| 適したタスク | 不適なタスク |
|---|---|
| 設計、重要な判断（戦略・撤退/集中・見積り）、重要レポートや提案書の品質担保 | 難易度が低いタスク、時間をかけたくないタスク、即答で足りる質問 |
| 「誤り・漏れのコスト ＞ 実行コスト（単発の 4〜5 倍）」が成り立つもの | コードレビューや実装ゲート（専用ツールの領分） |
判断基準はシンプルで、「間違えたときのコストが、余分にかかる実行コストより明確に大きいか」です。そうでなければ、素直に単発で回したほうが合理的です。
仕組み（4 ステップ）
1. 独立起案
CC と Codex が、同じ課題に並列で答えます。互いの存在も答えも知らせません。これは、一方の答えがもう一方を引きずる（アンカリングする）のを防ぎ、本当に独立した出発点を確保するためです。
2. 相互反証（1 往復・固定）
各エンジンが相手の草稿を批判します。指摘は必ず根拠か一次資料に基づかせます。ここでラウンド数を 1 往復に固定しているのが要点です。往復を増やすと、2 つのエンジンが「自信はあるが誤っているかもしれない合意」へ収束していきやすいためです。反対意見を、なれ合いの合意に変えてしまう前に止めます。
3. 共有前提の外部レッドチーム
Web 検索を持つ CC のサブエージェントが、2 つの答えが合意している前提（定義・スコープ・換算・データ源・除外シナリオ）を抽出し、それを別の裏取り（強制的な Web 検索と、反対の前提での再計算）から攻撃します。ここがこのツールの核です。2 つのエンジンが互いにカバーできない唯一の弱点は、両者がそろって握っている前提だからです。
4. 統合
改訂版は、反証を生き残った主張だけから組み直します。平均でも折衷でもありません。レッドチームが共有前提を崩した箇所では、確信度を下げ、レンジを広げ、あるいは別の推計を併記します。決着しない相違は溶かさず、そのまま人間へ返します。判定するのは最後まで人間です。
検証事例：公開データで検証した「レポート品質対決」
一番はっきり効果が出たのがこの事例です。題材にはパーソル総合研究所「第四回 副業の実態・意識に関する定量調査」の付録データを使いました。公開データなので機密性はゼロです。全アームに同じ付録データを供給し、変数を「分析・表現の質」だけに絞りました。
採点は、系統バイアスを避けるために 異なる系統の 2 判定（Claude 判定と Codex 判定）をブラインドで並列に行いました。結果は次のとおりです（各観点 5 点・合計 25 点満点）。
| 観点 | 合成B（Claude / Codex 判定） | Codex 単体 | CC 単体 |
|---|---|---|---|
| 網羅性 | 5 / 5 | 4 / 5 | 4 / 5 |
| 粒度 | 5 / 5 | 4 / 5 | 4 / 5 |
| 深さ | 5 / 5 | 3 / 5 | 4 / 5 |
| 妥当性・正確性 | 5 / 5 | 4 / 5 | 3 / 5 |
| 分かりやすさ | 4 / 5 | 5 / 5 | 4 / 5 |
| 合計（25 点満点） | 24 / 25 | 20 / 25 | 19 / 25 |
異系統の 2 判定が独立に合成 B を総合 1 位（24 点）としました。5 観点中 4 つで最優秀です。系統のバイアスを超えて頑健に出た結果と言えます。価値の出方を具体的に見ると、次の 3 点でした。
- Codex 単体が落とした論点（受入率の属性別、過重労働の年代別）を、合成 B が補いました（網羅性 5）。
- CC 単体の過剰な断定（「若年男性が牽引」など）を、反証が仮説の水準へ格下げしました（妥当性 5）。
- 一方で、「48.6% は前年の値の誤記だ」という反証を、付録の照合によって退けています。反証を鵜呑みにして過剰修正することも避けられました。
とくに分かりやすかったのが、資料化（A4 縦 1 ページのワンページャー）の出来です。CC 単体・Codex 単体・合成 B の 3 枚を並べます。
【Opus4.8 単体】
綺麗にまとまっていますが、余白が目立ったり、フォントサイズが小さく読みにくいところが多いです。
【GPT5.5 単体】
グラフが多く色使いもハッキリしていますが、CSSのミスが目立ちます。
【Opus4.8 × GPT5.5 合成（dual-engine）】
Opus4.8 のデザインが優先されたうえで、フォントサイズや配置が改善され、かなり見やすい仕上がりになりました。
（3 枚とも、パーソル総合研究所「第四回 副業の実態・意識に関する定量調査」の付録データをもとに各アームが作成したものです）
開発段階で発見された問題点：数値推計
別の題材である 数値の見積もりでは、合成結果が単体の結果を下回りました。 CC も Codex も、同じ狭い定義（過小に見積もる前提）を共有したまま揃って外し、レンジ（幅を持たせた見積もり）すら真の値を捕捉できませんでした。しかも、これは相互の批判でも統合でも消せませんでした。
これがこの合成手法の弱点、前提の共有による偏り （共有バイアス）です。相互の批判は、片方だけが持つ弱点には効きますが、両者が一緒に握っている盲点には届きません。だからこそ、共有した前提そのものを外から叩くレッドチームが必要になる——という設計上の必然につながりました。
外部レッドチーム：一致こそ疑う
レッドチームは、両エンジンが 合意した前提 （定義・スコープ・換算・データ源・除外シナリオ）を専従で抽出し、強制的な Web 検索と反対の前提で崩しにかかります。既存の多くの合議系ツールが「一致したら信頼する」のに対し、このプラグインは逆に「一致こそ疑う」という立場を取ります。これは奇をてらった逆張りではなく、共有バイアスを実際に観測したうえで導いた設計です。
分かりやすいスモークテストが、ペット市場規模の推計でした。2 つのエンジンは、いずれも矢野経済研究所の公表値である約 1.9 兆円にアンカーして収束しました。
【レッドチームによる推計の補正（1.9 兆円 → 1.7 兆円）】
ところがレッドチームが Web 検証で、「その公表値は、今回の課題が除外するはずの生体（ペット販売）を含んでいる。医療単独の数字は非開示だ」と看破しました。結果、スコープに準拠した約 1.7 兆円へ補正し、確信度を格下げしました。相互レビューだけでは崩せなかった共有思い込みを、レッドチームが破った好例です。このレッドチームの導入によって、別の推計課題では誤差が -33% から -16% へ縮み、レンジが真の値を捕捉するようになりました。
本質：上限を上げるより「出来のばらつきを小さくする」
ここまでの結果を通して見えてきたのは、このスキルの価値が「賢さの上限を挙げる」ことではない、という点です。価値は、下振れ＝ミス・抜け・事故を消す（出来のばらつきを小さくする）ことにあります。
【ばらつきの圧縮（大きな失敗の裾が消える）】
単体は、上振れ（時に卓越した切り口やデザイン）も下振れ（見落としや誤り）も大きく出ます。双発は、尖った良さを少し削る代わりに、致命的な抜けや誤りを取り除きます。上手くいったケースも単体を下回ったケースもここまで載せてきたとおり、効き方は題材によって変わりますが、狙いは一貫して下振れの抑制にあります。
使い方 / セットアップ
前提は、Claude Code、認証済みの Codex CLI（codex login か OpenAI API キー）、そして macOS・Linux・WSL のいずれかです。
インストール
Claude Code の中で次を実行します。
/plugin marketplace add anode-llc/dual-engine
/plugin install dual-engine@dual-engine
リポジトリを clone しておく必要はありません。Claude Code のプラグイン配布は分散型で、marketplace.json を含む GitHub リポジトリ自体が配布元として機能します。1 行目で Claude Code がリポジトリを自動取得し、2 行目でインストールされます（公式マーケットプレイスへの登録も不要な仕組みです）。
起動する
間違えたときの損失が大きく、あとから引き返しにくい課題を名指しで依頼するか、次のコマンドで明示的に起動します。(エージェントに自然文で依頼するのが推奨)
/dual-engine:deliberate
モデルを選ぶ
各アームのモデルはハードコードされておらず、実行時に名前を渡します。将来のモデルも、存在した瞬間から指定できます。たとえば起動時に次のように指定できます。
cc=opus, redteam=opus, codex=gpt5.5
安いモデルの組み合わせで判断品質を確保できることが、従量課金時代の現実的な代替になります。1 点だけ注記します。Codex を ChatGPT サブスクリプションで認証している場合、OpenAI 側が明示的な --model 指定を拒否し、アカウント既定のモデルしか受け付けないことがあります。任意の Codex モデルを固定したい場合は、OpenAI API キーで認証してください。
出力を読む
最終成果物 final-answer.md は、次の構造で出力されます。
## Revised Answer
## Unresolved Divergences
## Catch Log
## Rejection Log
最初に読んでほしいのは Unresolved Divergences（未決の相違リスト）です。判断が残っている箇所を、そのまま示す部分だからです。共有前提が大きく崩れたとき（結論が 2〜3 倍動くなど）、高深刻度の相違が統合後も生き残ったとき、あるいは片方のエンジンが空の出力を返したときには、上部にエスカレーションフラグが自動で立ちます。
同様の仕組みのサービスとの違い
同様の設計は様々なサービスで展開されていますが、それらとの違いは下記になります。
| 対象 | 型 | dual-engine との違い |
|---|---|---|
| OpenRouter Fusion API | 融合型 SaaS | 複数モデルを 1 答に融合。一致した前提を攻撃するレッドチームが無い。簡便さ・レイテンシは向こうが上 |
| Sakana AI「Fugu」 | RL オーケストレーション SaaS | タスク分解→並列→合成の自動最適化。前提を疑う専従ステップが無い。分解の自動化は向こうが上 |
| council-review（MIT） | 同一エンジンの合議 | 合議型で Web による前提攻撃なし。多角視点は向こうが充実 |
| adversarial-review | Claude×Codex の相互批評 | コードレビュー特化。異系統の反証は類似するが、前提攻撃・人間判定の終端は無い |
| agent-review-panel | 多レビュアー討論→審判 | 多数決/合議型。ドメインチェックリストは向こうが充実 |
| Microsoft AutoGen | 汎用フレームワーク | 自分で設計・実装が必要。dual-engine はそのまま使えるワークフロー |
【既存ツールとの立ち位置（一致は安心材料ではなく検証対象）】
優位点は、次の二本柱が中心です。
- 一致を疑うことに専従する、外部でその場で裏取りするレッドチーム。Web 検索を持つレッドチームが、2 つの答えが合意した前提そのものを攻撃します。調べた比較対象（Fusion API・Fugu ほか）はいずれも「融合の最適化」か「合議・多数決」であり、二者が合意した前提を攻撃する発想がアーキテクチャに含まれていません。ここが設計上の最大の差別化です。
-
有償の外部サービスを新規契約するのではなく、オープンソースの Claude Code スキルとして手軽に導入でき、自分の環境に合わせて自由にカスタマイズできる（MIT）。Fusion API も Fugu も、新しく契約する有償の外部 SaaS です。一方 dual-engine は、Claude Code のプラグインとして 2 コマンド（
/plugin marketplace addと/plugin install）で入り、追加の契約は要りません。しかも中身は全部書き換えられます——各エンジンに渡すプロンプトも、レッドチームの攻撃の仕方も、統合の判定基準も、自分の用途に合わせて変えられます。
一方で劣る点もあります。未検証ではありますが、単一 API 呼び出しの簡便さ・レイテンシ管理は Fusion、複雑なタスクの分解・オーケストレーション自動化は Fugu の方が高度に処理しているかと思います。
まとめ
dual-engine は、間違えたときの損失が大きく、あとから引き返しにくい判断のために作った Claude Code プラグインです。
- 異系統の 2 モデルに独立起案させ、相互に批判させ、共有した前提を Web で裏取りするレッドチームが叩き、統合する。
- 狙いは「処理能力を上げる」ではなく「出来のばらつきを小さくする」。効き方は題材によって変わり、単体を下回るケースもあります。
- 既存の合議系が「一致したら信頼」なのに対し、「一致こそ疑う」機構とすることで、AIで陥りがちなハルシネーションをできる限り防いでいます。
高いモデルを 1 発で回す代わりに、安いモデルを 2 系統で反証させて判断品質を守る、という選択肢です。従量課金時代の代替として、ぜひお試しください。
リポジトリ（MIT / anode-llc）: https://github.com/anode-llc/dual-engine