はじめに
GitHubは2026年4月6日、コーディングエージェントツール「GitHub Copilot CLI」に、異なるAIファミリーのモデルを使った自動レビュー機能「Rubber Duck」を実験的モードとして追加したと発表しました。本稿では、この機能の仕組みと評価結果、利用方法について解説します。
参考記事
- タイトル: GitHub Copilot CLI combines model families for a second opinion
- 著者: Nick McKenna、Bartek Perz
- 発行元: GitHub Blog
- 発行日: 2026年4月6日
- URL: https://github.blog/ai-and-ml/github-copilot/github-copilot-cli-combines-model-families-for-a-second-opinion/
要点
- Rubber Duckは、メインのコーディングエージェントとは異なるAIファミリーのモデルを独立したレビュアーとして活用する機能である
- SWE-Bench ProベンチマークにおいてGitHub Blogによれば、Claude Sonnet 4.6とRubber Duck（GPT-5.4）の組み合わせは、SonnetとOpusの性能差の74.7%を埋める結果を示した
- 複数ファイルにまたがる難易度の高いタスクでは、Sonnet単体より3.8%、最難問題では4.8%のスコア向上が確認された
- 計画立案後・複雑な実装後・テスト記述後の3つのタイミングで自動的に起動するほか、ユーザーが任意のタイミングで呼び出すことも可能である
- 現在、Claude Opus・Sonnet・Haikuをオーケストレーターとして利用している場合に有効で、/experimentalコマンドで機能を有効化できる
詳細解説
Rubber Duckとは何か
「Rubber Duck」とは、メインのエージェントが使うモデルとは 異なるAIファミリー のモデルを活用し、エージェントの計画や実装を独立した立場でレビューする機能です。GitHub Blogによれば、ClaudeモデルをオーケストレーターとしてCopilot CLIを使用している場合、Rubber DuckにはGPT-5.4が割り当てられます。
コーディングエージェントは「タスク把握→計画立案→実装→テスト→反復」というループで動作しますが、この流れには盲点があります。計画段階で下した判断が以降のすべての作業の土台となるため、初期の判断ミスや非効率な設計がそのまま積み重なっていく可能性があります。エージェントが自分自身の出力をセルフレビューする手法は一般的ですが、同じ学習データや手法に基づいて訓練されたモデルが自己評価する場合、固有の偏りや盲点は解消されません。異なるモデルファミリーを組み合わせることで、この課題に対処しようというのがRubber Duckのコンセプトです。
SWE-Bench Proによる評価結果
評価には SWE-Bench Pro が用いられました。これはオープンソースリポジトリから抽出した大規模・高難易度の実世界コーディング問題を集めたベンチマークで、エージェントの実用的な問題解決能力を測る指標として知られています。
GitHub Blogの発表によれば、Claude Sonnet 4.6とGPT-5.4（Rubber Duck）の組み合わせは、SonnetとOpus単独の性能差の74.7%を埋める解決率を達成しました。また、3ファイル以上にまたがる・通常70ステップ以上を要する難しい問題では、Sonnet単体より3.8%高いスコアを記録し、3回の試行を通じて特定された最難問題では4.8%の向上が確認されました。
発表では、Rubber Duckが実際に発見したバグの具体例も紹介されています。スケジューラーが開始直後に終了してしまう設計上の問題（OpenLibraryのケース）、Solrの検索クエリで毎回同一のdictキーを上書きするループの不具合（同）、複数ファイルが参照するRedisキーへの書き込みが新コードで停止し、確認UIとクリーンアップ処理がデプロイ時にサイレントに壊れてしまうケース（NodeBBのケース）など、単体テストでは発見しにくいタイプのバグが含まれています。これらはいずれも実際の開発現場で見落とされやすい問題類型と考えられます。
Rubber Duckが起動するタイミング
Rubber Duckは、フィードバックの効果が最も高いチェックポイントに絞って呼び出されるよう設計されています。GitHub Blogによれば、自動起動のタイミングは次の3つです。
1. 計画立案直後
初期の意思決定を修正することで、後続の問題の連鎖を防ぐ効果が最も大きいタイミングとされています。
2. 複雑な実装の完了後
複雑なコードに対して追加の視点を加えることで、エッジケースの見落としを減らすことが目的です。
3. テスト記述後・実行前
テストカバレッジの不足や誤ったアサーションを、「すべてパス」という状態が自己強化される前に発見するためのタイミングです。
また、エージェントがループにはまって進捗が取れない場合にも、反応的にRubber Duckを呼び出して状況を打開する動作が設計されています。ユーザー側からも任意のタイミングでレビューをリクエストでき、Copilotはフィードバックを取り込んだうえで変更点と理由を表示します。なお技術的には、Rubber DuckはCopilotが他のサブエージェントにも使う既存のタスクツールのインフラを通じて呼び出されます。
利用方法と対応環境
Rubber Duckは現在、実験的モードで提供されています。利用するには、GitHub Copilot CLIをインストールしたうえで /experimental コマンドを実行します。モデルピッカーでClaudeモデル（Opus・Sonnet・Haiku）を選択し、GPT-5.4へのアクセス権を持っている場合に利用可能です。
特に効果が高いとされるユースケースとして、大規模なリファクタリングやアーキテクチャ変更、ミスが許されない高リスクタスク、テストカバレッジの網羅性確認、計画をコミットする前のセカンドオピニオンが挙げられています。現在はClaudeファミリーをオーケストレーターとする場合のみGPT-5.4のRubber Duckが有効ですが、今後は他のモデルファミリーの組み合わせについても検討が進められているとのことです。
まとめ
GitHub Copilot CLIのRubber Duckは、異なるAIファミリーのモデルを組み合わせることで、エージェント単独では見落としやすいバグや設計上の問題を早期に発見しようとする取り組みです。評価結果や具体的なバグ発見事例は興味深く、複数モデルの協調という方向性が今後どのように発展していくか、注目したいと思います。
