GitHub Copilot CLIに2026年4月6日、「Rubber Duck」と名付けられた実験的機能が追加された。コーディングタスクを実行するAIモデルとは別ファミリーのモデルを呼び出し、成果物を批評的にレビューさせる仕組みだ。Anthropicのモデルがオーケストレーター（作業担当）として動いているとき、OpenAIのGPT-5.4がRubber Duckとしてクリティーク（批評的レビュー）役を担う。GitHubの社内評価では、Claude Sonnetにこの組み合わせを適用することで、SonnetとOpus単体の性能差の74.7%が縮小したとされる。「同一モデルが自らの成果物をレビューすると、同じ学習バイアスに縛られる」という設計思想は、AIコーディングツールの精度向上をめぐる議論に新たな視点を持ち込んでいる。
AIが自分の盲点を見抜けない理由
コードを書いたあと、それを書いた本人がレビューするのは難しい。見落とした前提条件は、何度読み返しても見落としたままになりがちだ。人間の開発者はこの問題をコードレビューのプロセスによって補ってきたが、AI同士のやり取りでも同じ構造的な問題が生じる。
GitHubブログの共著者であるNick McKenna氏は、この点を明快に言語化している。「自らの成果物をレビューするモデルは、依然として自身の学習バイアスに縛られている。同じ学習データ、同じ手法、同じ盲点というわけだ」というGitHubの発表によれば、この課題認識が今回の機能設計の出発点にある。言い換えると、AIの精度問題は「より大きなモデルへの切り替え」だけでは解決しない構造的な性質を持つということだ。
同一モデルファミリー内では、上位モデルへの乗り換えが精度向上の主な手段だった。Claude Sonnetの限界に達した開発者はOpusに切り替え、コストの上昇を受け入れるしかない。しかし、同じ訓練アプローチから派生したモデル同士では、Opusに乗り換えてもSonnetが気づかなかった盲点の一部は共有されたままになる可能性がある。Rubber Duckはこの「同一系統の限界」を別ファミリーのモデルを挟むことで突破しようとする試みだ。
Rubber Duckの仕組み：役割分担と自動起動タイミング
Rubber Duckという名称はプログラミング界隈の慣習「ラバーダック・デバッグ」から来ている。行き詰まった開発者がゴム製のアヒルのおもちゃに向かってコードを説明することで、問題を自力で発見するという手法だ。GitHubはこの名称を借りることで、機能の役割、すなわち「外からの目」によるレビューの本質を端的に表現している。
Rubber Duckが効果を持つ根拠は、レビュアーに選ばれたGPT-5.4がClaudeファミリーとは独立した訓練バックグラウンドを持つ点にある。AnthropicとOpenAIは異なるデータ戦略と強化学習アプローチを取っており、GPT-5.4はClaudeが構造的に見落としやすい盲点を共有していない可能性が高い。Claudeがコーディングタスクを担い、GPT-5.4がその成果物を外側から批評する分業は、同一プロバイダー内でのモデル切り替えとは本質的に異なるアーキテクチャだ。
GPT-5.4によるクリティークは、「計画立案後」「複雑な実装後」「テスト作成後」という3つのチェックポイントで自動起動する。これらは方針の誤りや見落としが後工程に持ち込まれるリスクが最も高い節目であり、作業の流れを止めずに批評的な目を差し込むタイミングとして設定されている。/experimentalスラッシュコマンドを使えば、任意のタイミングでオンデマンドにGPT-5.4のレビューを要求することもできる。
本機能は現在実験的ステータスにあり、GitHub Copilot CLIのユーザーであれば/experimentalコマンドから即座に試せる。一般提供（GA）への移行時期は公表されていないが、GitHubはGPT-5.4がオーケストレーター側に回る構成や他のモデルファミリーとのRubber Duck連携も探索中だとされる。現時点の実装はAnthropicモデルをオーケストレーターとした場合の検証に主眼を置いており、マルチモデル協調の実験はより広い構成へ拡張していく見込みだ。
74.7%というベンチマーク数値の意味
Rubber Duckの効果を示す指標としてGitHubが示したのが、SWE-Bench Pro（ソフトウェアエンジニアリング作業の再現性を測る標準的なベンチマーク）での結果だ。GitHubの社内評価によれば、Claude Sonnet + Rubber Duckの組み合わせは、SonnetとOpus単体の性能差の74.7%を縮小した。Sonnet単独の性能を0、Opus単独の性能を100と置くと、Rubber Duckを組み合わせたSonnetは74.7まで到達できる計算であり、Opusへの乗り換えなしに近い精度を引き出せるならば、コスト意識の高い企業ユーザーにとって選択肢が広がる。
内訳の数値も注目に値する。多ファイルにまたがるタスクでは3.8%の性能向上があり、最難度問題（3ファイル以上・70ステップ以上のタスク）では4.8%の向上が確認されたとされる。単純なタスクより複雑なタスクで効果が大きいという傾向は、「異なる視点によるレビューが複雑な文脈でこそ機能する」という仮説と整合する。
ただしこの評価はGitHub自身のSWE-Bench Pro評価に基づくものであり、第三者機関による独立した検証は行われていない。GPT-5.4というモデル名もGitHub公式ブログに記載されたものだが、現時点で独立した確認が取れていないため、GitHubが採用したOpenAIのモデルという位置づけで理解しておくのが妥当だ。74.7%という数値を受け取る際には、これらの前提を踏まえて判断する必要がある。
異モデル協調が示す開発ツールの次の姿
GitHub Copilot CLIは2025年10月、/modelコマンドによるモデル切り替え機能をすでに実装していた。ユーザーがOpenAI、Anthropic、Googleなどのモデルを自由に選べる体制は、GitHub Universe 2024で打ち出したマルチモデル戦略の延長線上にある。今回のRubber Duckはその先にある一歩で、「複数のモデルを並べて選ぶ」から「複数のモデルが協調して動く」への移行を示している。
AIコーディングアシスタント市場ではCursor、VS Code上のCopilot、JetBrains AI Assistantなどが激しく競合している。差別化の軸がモデルの性能だけでなく、モデルをどう組み合わせてワークフローに組み込むかへと移りつつある中で、競合するAIメーカーのモデルを同一ワークフロー内で協調させるアーキテクチャは一つの方向性を示す。
Rubber Duckが実験的ステータスから抜け出すかどうかは、実際の開発者からのフィードバックと性能検証にかかっている。74.7%という数値がGitHub社内評価を超えて再現されるのか、そして「競合するAIを組み合わせてコスト効率よく精度を引き出す」というアーキテクチャが業界標準になり得るのか——これらの問いへの答えは、今後の実装の成否が示すことになる。
Sources