GitHub Copilot CLI「Rubber Duck」──異なるAIファミリーのセカンドオピニオンで盲点を潰す新機能¶

対象 / ポイント

対象: GitHub Copilot CLI を利用中、または導入を検討している開発者・テックリード。AIエージェントの品質改善手法に関心がある読者。

ポイント:

Rubber Duck は、メインモデルとは異なるAIファミリーのモデルが計画・実装・テストの3箇所で自動批評する experimental 機能
SWE-Bench Pro で Claude Sonnet 4.6 + GPT-5.4 が Sonnet→Opus 間の性能差の 74.7% を埋めた
難問（3ファイル以上・70ステップ超）ほど効果が高く、最難問題では +4.8% の改善

なぜ「同じモデルの自己レビュー」では不十分なのか¶

コーディングエージェントの標準ループは「計画 → 実装 → テスト → 修正」の繰り返しで動く。このループの中でエージェントが自身の出力をレビューする self-reflection は既に広く使われているが、構造的な限界がある。

同じモデルが自分のコードをレビューしても、同じ学習データ・同じ推論特性から生まれる盲点は検出できない。計画段階で置いた誤った前提は、実装→テストと下流に進むほど依存関係として固定化される。気づいたときには、最初の小さなミスだけでなく、それに依存して積み上がった構造全体を修正する必要がある。

self-reflection の回数を増やしても検出率はすぐに頭打ちになる。モデルの「視界」自体を変えなければ、見えないものは見えないままだ。

Rubber Duck の仕組み¶

Rubber Duck は、メインのエージェントセッションとは補完的なファミリーに属するモデルで動くレビュー専用エージェントである。

メインモデル（オーケストレーター）  Rubber Duck（レビュアー）
─────────────────────────────────  ──────────────────────────
Claude Opus 4.6                    GPT-5.4
Claude Sonnet 4.6          →      GPT-5.4
Claude Haiku 4.5                   GPT-5.4

Rubber Duck の役割は、メインエージェントが見落としたディテール、疑うべき仮定、考慮すべきエッジケースを短く焦点を絞ったリストとして提示すること。全体を書き直すのではなく、高価値な懸念だけを返す設計になっている。

技術的には、Copilot の既存のタスクツール基盤（他のサブエージェントと同じインフラ）を通じて呼び出される。

3つの自動チェックポイント¶

Rubber Duck は自動（プロアクティブ・リアクティブ）とユーザー手動の両方で起動する。自動起動のタイミングは、フィードバックのリターンが最も高い3箇所に設計されている。

チェックポイント①：計画立案後 最大のインパクトが期待される地点。計画段階の誤判断は下流で複合的に悪化するため、ここで1つ仮定を覆すだけで実装全体の手戻りを防げる。

チェックポイント②：複雑な実装後 ファイル間の依存関係やエッジケースを、異なる推論特性を持つモデルの視点で検出する。

チェックポイント③：テスト記述後・実行前 テストを実行して「全パス」と自己強化する前に、カバレッジの穴や不正なアサーションを潰す最後の機会。

また、エージェントがループにはまって進捗しない場合、リアクティブに Duck を呼び出してデッドロックを解消する設計もある。ユーザーはいつでも手動で批評を要求でき、Copilot は Duck のフィードバックを反映した差分を表示する。

SWE-Bench Pro 評価結果¶

評価には SWE-Bench Pro（大規模・高難度のオープンソースリポジトリから抽出された実世界のコーディング問題ベンチマーク）が使用された。

構成	SWE-Bench Pro 結果
Claude Sonnet 4.6 単体	ベースライン
Claude Sonnet 4.6 + Rubber Duck (GPT-5.4)	Sonnet→Opus 間の性能差の 74.7% を埋めた
Claude Opus 4.6 単体	最高性能

問題の難易度別に見ると、効果の傾斜がより明確になる。

問題カテゴリ	Sonnet 単体比の改善幅
全問題平均	性能差の 74.7% を解消
3ファイル以上・70ステップ超の難問	+3.8%
3回試行で特定された最難問題	+4.8%

難問ほど効果が高い理由は明快で、ファイル数やステップ数が増えるほど計画段階の誤りが複合化しやすく、早期の批評介入の価値が増大するためだ。

実例：Rubber Duck が検出した3つのバグ¶

公式ブログで紹介された3つの実例は、いずれもメインモデルの self-reflection では検出されなかったものである。3事例に共通するのは、エラーを出さずに壊れる（サイレントフェイル） パターンだという点。テストをパスしてしまう種類のバグこそ、異なる視点を持つレビュアーの価値が最も高い。

有効化方法¶

Rubber Duck は experimental 機能として提供されている。

# Copilot CLI で experimental モードを有効化
/experimental

# モデルピッカーで Claude 系を選択
# → Rubber Duck は自動的に GPT-5.4 が割り当てられる

対象：Claude Opus 4.6 / Claude Sonnet 4.6 / Claude Haiku 4.5 をオーケストレーターとして使用する全ユーザー。GPT-5.4 へのアクセス権が必要。

効果が高いユースケース：

複雑なリファクタリングやアーキテクチャ変更
ミスのコストが高いタスク
テストカバレッジの網羅性確認
計画にコミットする前のセカンドオピニオン

考察：「異なるファミリーによる批評」の設計思想¶

Rubber Duck のアーキテクチャが示しているのは、単一モデルの性能を上げるよりも、異なる特性を持つモデルの組み合わせで品質を上げる方がコスト効率が良い場合があるという実証だ。

Sonnet + Duck（推定コスト：Sonnet の数割増）で Opus 単体（推定コスト：Sonnet の数倍）の性能に迫るのであれば、「最強モデルを単体で回す」以外の選択肢がエンジニアリング上の合理的な判断になる。

また、チェックポイントの設計（計画後 > 実装後 > テスト後）は、ソフトウェア工学で古くから知られている「欠陥の修正コストはフェーズが進むほど指数的に増大する」という原則と整合している。AIエージェントの世界でも、人間のコードレビューと同じ原則が有効だという点は興味深い。

今後、GPT-5.4 をオーケストレーターにした場合の Duck ファミリーの探索も進行中とのことで、モデルの組み合わせ最適化がエージェント設計の新しい軸になりつつある¹。

まとめ¶

Rubber Duck は「違う学習ベースから見ると当たり前のバグ」を拾うための、構造化されたセカンドオピニオン機構
自動チェックポイントを計画後に置いた設計は、欠陥修正コストの指数的増大則に沿った合理的な判断
今後は「どのモデルを使うか」ではなく「どのモデルとどのモデルを組み合わせるか」がエージェント設計の焦点になる可能性がある