Rubber Duck で学習バイアスを補完する — GitHub Copilot CLI の新概念を Claude Code で実装する
はじめに
2026 年 4 月 6 日、GitHub は Copilot CLI に「Rubber Duck」という実験的機能を追加しました。AI コーディングエージェントが自分の作業を別モデルにレビューさせる仕組みで、SWE-Bench Pro での性能ギャップを 74.7％ 埋めたという数値とともに発表されています。
この発表を見て「面白いが、自分の Claude Code 環境にどう落とし込めばよいか」と感じた方は多いのではないでしょうか。実は Rubber Duck が体系化したパターンは、筆者が過去の連載・記事の中で先行的に試みていたものでもあります。本記事では Rubber Duck の構造を整理したうえで、筆者が公開してきた一連の実例記事と接続し、概念から実装へ橋渡しします。
なお本記事は 概念解説とメタ視点の整理 に焦点を当てています。Codex CLI を用いた具体的なコマンド操作や Adversarial Review の実装手順については、姉妹記事「Codex × Claude Code Copilot 2026」を参照してください。
対象読者は、Claude Code または GitHub Copilot CLI を日常的に使用しており、マルチエージェント構成を 1 つ以上組んだ経験を持ち、AI コードレビューの自動化に関心のあるエンジニアです。マルチエージェント構成の基礎は「Claude Code 開発フロー実践ガイド (1/3) — マルチエージェント戦略編」にも整理しています。
本記事で使う主な用語
- オーケストレーター: タスク全体を主導するプライマリエージェント。本記事の文脈では Claude（Opus / Sonnet / Haiku）が該当します
- モデルファミリー: 同じ提供元・基盤モデル系統（Anthropic 系の Claude、OpenAI 系の GPT、Google 系の Gemini など）の総称
- 学習バイアス: 訓練データ・学習手法の偏りに由来する盲点。同じ訓練を受けたモデルは同じ盲点を共有しやすいという性質
- SWE-Bench Pro: 実プロジェクトのバグ修正タスクで AI コーディングエージェントの解決率を測定するベンチマーク
- GA（一般提供）: General Availability の略。実験段階を経て安定機能として提供される状態
- task tool / focused review agent: Copilot CLI が持つ subagent 起動の仕組みと、レビュー特化の補助エージェント。Rubber Duck もこの基盤に乗ると推測されています
Rubber Duck とは何か — GitHub が提唱した「Second Opinion」の構造
Rubber Duck は、AI コーディングエージェントの作業に対して 別ファミリーのモデルが独立した第二の視点でレビューする仕組み です。これは Anthropic が提唱する Generator-Verifier パターンを、異なるモデルファミリーを組み合わせることで実装した例と言えます。オーケストレーターが Claude（Opus / Sonnet / Haiku）、Rubber Duck 側が GPT-5.4 という構成で動作します。
Rubber Duck の動作モデル
Rubber Duck は単独で動くツールではなく、既存のオーケストレーター（プライマリエージェント）の判断プロセスに対して チェックポイントごとに割り込み ます。GitHub のブログ記事（Nick McKenna & Bartek Perz 著、2026-04-06 公開）によれば、起動タイミングは次の 3 つです。
- 計画立案後（After drafting a plan）— オーケストレーターが立てた実装計画を、別モデルの目で検証する段階
- 複雑な実装後（After a complex implementation）— 大きな差分を伴う変更を入れた直後、コミットする前
- テスト記述後・実行前（After writing tests, before executing them）— テストコード自体に誤りがないかを確認する段階
加えて、エージェントが「ループに陥った」場合には自動で Rubber Duck が呼び出されます。開発者はセッション中に明示的に critique（批評）を要求でき、3 チェックポイント以外でも能動的に Second Opinion を引き出せる柔軟性があります。
ここで重要なのは、Rubber Duck が 判断の主導権を奪わない 点です。最終的にコードを書き、テストを実行し、コミットするのはオーケストレーター（プライマリエージェント）であり、Rubber Duck はあくまで助言者として振る舞います。これは人間のチーム開発における「ペアプログラミングのナビゲーター役」に近い設計思想だと言えます。
図中の実線は 3 チェックポイントでの自動割り込み、点線は「ループ検知時の自動起動」と「開発者からの能動 critique」という別経路を示しています。3 チェックポイントは内部的に自動で発火するため、開発者が毎回明示的に呼び出す必要はありません。
性能評価とその前提条件
GitHub が発表した数値は SWE-Bench Pro での評価結果です。原文を引用します。
"Claude Sonnet 4.6 paired with Rubber Duck running GPT-5.4 achieved a resolution rate approaching Claude Opus 4.6 running alone, closing 74.7% of the performance gap between Sonnet and Opus."
「GPT-5.4 を動かす Rubber Duck と組み合わせた Claude Sonnet 4.6 は、Claude Opus 4.6 単独に近い解決率に到達し、Sonnet と Opus の性能ギャップの 74.7% を埋めた」
ここで重要なのは、Rubber Duck によって Sonnet 4.6 が Opus 4.6 を超えたわけではない という点です。あくまで「Sonnet 単独」と「Opus 単独」の差を 74.7％ 埋めたのであり、Opus に近づいたが追い越してはいません。
また、評価は Claude Opus 4.6 / Sonnet 4.6 世代で行われており、本記事執筆時点（2026-05-03）の最上位モデル Claude Opus 4.7（2026-04-16 リリース）はこの評価に含まれていません。
Rubber Duck が特に効く問題のプロファイル
GitHub は Rubber Duck の効果が大きい問題について、次のように述べています。
"Rubber Duck tends to help more with difficult problems, ones that span 3+ files and would normally take 70+ steps."
「Rubber Duck は 3 ファイル以上にまたがり、通常 70 ステップ以上を要する難しい問題で特に効果を発揮する」
なお、この「3+ files / 70+ steps」は Rubber Duck の効果プロファイル であって、SWE-Bench Pro 全体の評価条件ではありません。記事や SNS でこの数字を引用する際には混同しないよう注意が必要です。
既存基盤の流用（推測）
公式記事では明示されていないものの、Rubber Duck は Copilot CLI が既に持つ task tool（focused review agent を呼び出すための仕組み）の上に構築されていると推測できます。新規のサブエージェント基盤を作るのではなく、既存のレビュー用 subagent インフラに別ファミリーのモデルを差し込む形です。
なぜ「自己レビュー」では足りないのか？ — 学習バイアスという根本問題
自己レビューの限界は 同じ訓練データに由来する盲点を、自分自身では検出できない ことにあります。
GitHub は「異なる種類のエラーを捕まえるには、異なる視点が重要だ」（"To catch different kinds of errors, a different perspective matters."）と続けます。これは経験的にもうなずける主張です。同じプログラマがコードを書いて自分でレビューしても、文法的な誤りには気付けても設計上の盲点には気付きにくい——という現象を、AI エージェントの世界に翻訳した概念だと言えます。
具体例として、GitHub の記事は「Scheduler が起動直後に終了してしまう設計欠陥」を Rubber Duck が事前に検出した事例を紹介しています。実装したモデル自身は「正しい計画である」と確信していたものを、別ファミリーのモデルが初見で違和感に気付いたわけです。これは「自信を持った間違いは積み重なる」という前述の指摘を裏付ける事例でもあります。
つまり Rubber Duck の本質は性能向上というより、学習バイアスの相互補完 にあります。性能差の埋め合わせは結果であり、目的は「同じ盲点を共有しないモデルにレビューさせること」です。だからこそオーケストレーターを Claude にした場合は Rubber Duck 側に GPT-5.4 が選ばれており、同じファミリー内の小型モデル（例: Sonnet を Haiku がレビューする）では同じ効果は期待できないと推察されます。
筆者が過去に試みていた Rubber Duck 的アプローチ
Rubber Duck の発表は 2026 年 4 月ですが、「異なるモデルファミリー間でコードレビューを相互に行う」という発想自体は、筆者がそれ以前から自分のリポジトリで継続的に試みてきたものでした。本節ではその実例を整理します。
なお、英語圏でも Aider（複数モデルでの相互レビュー機能）や ChatDev / AutoGen（マルチエージェント協調フレームワーク）といったオープンソースが同種の発想を先行的に実装してきました。それらとの詳細な比較は別の機会に譲り、本記事では 筆者の公開実例に絞って Rubber Duck との対応関係を Claude Code 環境の文脈で具体的に示します。
以下の 3 つの記事を順に紹介します。詳細は各リンク先に委ね、ここでは Rubber Duck との対応関係を中心に整理します。
-
Codex × Claude Code のコミット前レビュー —
codex-plugin-ccを使った GPT 系 × Anthropic 系の協調 - Claude × Gemini Code Assist の役割分離 — 実装担当とレビュー担当の二層構造
- 70 PR × 321 件で実証された効果 — 個人開発レベルでクロスモデルレビューを定量分析した連載
Codex × Claude Code のコミット前レビュー
codex-plugin-cc は OpenAI が 2026 年 3 月 31 日に公式公開した Claude Code プラグインで、/codex:review コマンドにより uncommitted changes やブランチ差分を Codex にレビューさせることができます。Rubber Duck の 3 つのチェックポイント（計画後・実装後・テスト記述後）のうち、特に「実装後」のチェックポイントに対応するワークフローを、Claude Code 環境で先行的に実現していたと言えます。
技術的な実装詳細（プラグインのインストール手順、/codex:review の使い分け、Adversarial Review モードの活用など）は元記事に詳述されています。
Claude × Gemini Code Assist の役割分離
この構成では、Claude Code がコードを生成し、Gemini Code Assist が PR コメントとして指摘を入れます。Rubber Duck と異なるのは、Gemini 側もインタラクティブな対話エージェントとして応答する点です。これは Rubber Duck の「critique を返す側」が必ずしも GPT 系である必要はないことを示唆しており、概念のモデルファミリー非依存性を裏付ける実例になっています。
実装に必要な VS Code 拡張のセットアップ、PR レビュアクフローの組み方、Claude と Gemini の役割定義の詳細は元記事を参照してください。
70 PR × 321 件で実証された効果
この 4 本の連載では、AI 間で交換されたレビュー指摘を 7 パターンに分類し、AI 同士の対話の原文（第 2 回 で反論や撤回を含む 5 件を抜粋）を分析しています。さらにシフトレフトの 4 本柱（第 3 回）として「設計レビューの前倒し」「テスト記述前のレビュー」「コミット前検証」「マージ後の振り返り」が抽出されています。このうち前 3 つは Rubber Duck の 3 チェックポイント（計画後・実装後・テスト記述後）と概ね対応し、「マージ後の振り返り」だけは Rubber Duck の射程外という関係になります。完全一致ではないものの、独立に到達した観点が大部分で一致しているのは興味深い符合です。
番外編では、gh CLI × Python でレビュー履歴を集計する analyze_prs.py の実装も公開されており、自分の環境で同様の定量分析を再現する手段が提供されています。
analyze_prs.py が解いている処理（折りたたみ）。
番外編で公開されている analyze_prs.py は、gh CLI 経由で PR データを取得し、レビュー指摘を構造化・カテゴリ分類するスクリプトです。要点だけ整理すると次のとおりです。
-
データ取得:
gh apiで PR ごとに Issue Comments / Reviews / Review Comments の 3 種類 を別エンドポイントから取得し、NDJSON として 1 行 1 オブジェクトで保存します -
NDJSON のストリーミング解析:
json.JSONDecoder.raw_decodeを使い、巨大ファイルでもメモリー消費を抑えて 1 オブジェクトずつ読み出します - カテゴリ分類: コメント本文に対し キーワードマッチング を適用し、指摘を「テスト / UI/UX / 命名 / DRY / Architecture / Performance / Documentation」など 7 パターンに振り分けます
- 集計出力: PR 単位の指摘件数・平均マージ時間・カテゴリ分布を CSV と Markdown で出力し、Zenn 記事に貼り付けやすい形にまとめます
実装上の落とし穴（subprocess 標準出力のバッファリング、3 種コメント API の差異、NDJSON 末尾の改行扱いなど）は番外編記事で詳述されています。gh CLI と Python さえあれば自分のリポジトリにそのまま流用可能です。
Rubber Duck パターンと自リポジトリ実装の対応表
ここまでの 3 事例と Rubber Duck の対応関係を整理すると次のようになります。
| 評価軸 | Rubber Duck（公式） | Codex × Claude Code | Claude × Gemini |
|---|---|---|---|
| 異モデル協働 | Claude + GPT-5.4 | Claude + GPT 系 | Claude + Gemini |
| バイアス補完 | 学習データ差を活用 | OpenAI / Anthropic の差 | Anthropic / Google の差 |
| Second opinion | 必須要素 |
/codex:review で実現 |
PR コメントで実現 |
| チェックポイント注入 | 計画 / 実装 / テスト前 | 実装後（コミット前） | PR 作成時 |
| サブエージェント基盤[1] | task tool 流用 | プラグイン経由 | IDE 拡張 + CLI |
| プライマリ判断 | Claude が保持 | Claude が保持 | Claude が保持 |
Rubber Duck が体系化したパターンの大部分が、別の組み合わせで先行実装されていたことが見て取れます。
Rubber Duck をリポジトリにどう導入するか — 3 ステップの起点
Rubber Duck の概念を自分のリポジトリに導入するには、次の 3 ステップが起点になります。Copilot CLI の experimental mode が GA になるのを待たずに、Claude Code 環境でも近い体験を組み立てられます。
ステップ 1: チェックポイントを言語化する
まずどのタイミングで Second Opinion を欲しいかを決めます。Rubber Duck の 3 チェックポイント（計画後・実装後・テスト前）はそのまま採用可能ですが、すべてを毎回回すとトークン消費が大きくなります。プロジェクトの規模やコスト感に応じて「PR 作成時のみ」「マージ前のみ」「コアロジックの変更時のみ」のように削減・条件分岐させても構いません。重要なのは どこで判断の独立性を欲しいか をあらかじめチームで合意しておくことです。
具体的なチェックポイント設計の参考例として「Claude Code × Gemini 協調開発 実録 (3/3) — シフトレフト 4 本柱」が役立ちます。Rubber Duck の 3 チェックポイントとほぼ同じ位置に独立して到達した実例です。
ステップ 2: 別ファミリーのモデルをレビュアーとして接続する
Claude Code 環境であれば codex-plugin-cc が最短の選択肢です。/plugin marketplace add openai/codex-plugin-cc でインストールし、/codex:review をレビュー用コマンドとして使います。Gemini Code Assist や Grok など、別系統のモデルを接続する選択肢もあります。重要なのは オーケストレーターと異なるファミリー を選ぶことです。同じファミリー内で小型モデルにレビューさせても学習バイアスは共有されたままで、Rubber Duck が狙う「異なる盲点」の効果は得にくくなります。これは前章で触れた「同じ訓練データを共有するモデルは同じ盲点を共有する」という原理に直接由来します。
ステップ 3: レビュー履歴を蓄積し、効果を計測する
Rubber Duck の 74.7％ に対応する数値を、自分の環境でも追跡することをおすすめします。gh CLI でレビューコメントを集計し、修正前後の差分や指摘パターンを記録する仕組みを用意しておけば、後から「どの種類の指摘が自モデルでは見つからなかったか」を可視化できます。前述の Interplay Insights 連載番外編で公開した analyze_prs.py は、こうした集計を Python で半自動化する出発点として活用いただけます。
まとめ
Rubber Duck の本質は性能向上ではなく 学習バイアスの相互補完 であり、その思想は筆者の過去記事の中でも、Codex プラグイン・Gemini との協調・PR レビュー定量分析という形で先行的に試みてきたものでした。冒頭で「自分の Claude Code 環境にどう落とすか」という課題に触れましたが、解は意外と身近にあります。codex-plugin-cc や Gemini Code Assist との連携、PR レビュー履歴の定量分析といった既存資産を、Rubber Duck の 3 チェックポイント構造に沿って組み直すことで、experimental mode の解放を待たずに同等の体験が得られます。
関連記事として、複数 AI による議論を編集会議に応用した記事と、Grok / Gemini / Claude の 3 ファミリー協調を扱った記事も併せて参照いただくと、クロスモデル協調の全体像が掴みやすくなるはずです。
最後までお読みいただきありがとうございます。本記事が、Rubber Duck の概念を自分のリポジトリへ移植する際の地図として役立てば幸いです。
-
「サブエージェント基盤」行の Rubber Duck 列（task tool 流用）は公式の明言がなく、focused review agent への言及からの推測です。Codex × Claude Code と Claude × Gemini の列は公開実装に基づく事実です。 ↩︎
Discussion