GitHub Copilot CLIがモデルファミリーを組み合わせて第二の意見を提供
GitHubはCopilot CLIに「Rubber Duck」という実験的機能を導入し、異なるAIモデルファミリーのモデルを独立したレビュアーとして活用することで、コーディングエージェントの計画と作業を評価し、特に複雑なマルチファイル・長時間タスクでのパフォーマンスを向上させた。
キーポイント
Rubber Duckの導入
GitHub Copilot CLIに実験的機能として「Rubber Duck」が追加され、プライマリエージェントとは異なるAIモデルファミリーのモデルを独立レビュアーとして活用し、計画と作業を評価する。
パフォーマンス向上の実証
評価では、Claude SonnetにRubber Duck（GPT-5.4）を組み合わせることで、Sonnet単体とOpus単体の性能差の74.7%を埋め、特に3ファイル以上・70ステップ以上を要する困難な問題で効果を発揮した。
自己レビューの限界克服
エージェント自身による自己レビューは訓練バイアスや盲点の影響を受けるが、異なるモデルファミリーによるレビューは新たな視点をもたらし、見落としや仮定の検証、エッジケースの考慮を可能にする。
具体的な効果
Rubber Duckは、プライマリエージェントが見逃した詳細、疑問を持つ価値のある仮定、考慮すべきエッジケースなど、高価値な懸念事項の短く焦点を絞ったリストを提示する。
Rubber Duckの自動起動タイミング
GitHub Copilotは、計画策定後、複雑な実装後、テスト作成後などのチェックポイントで自動的にRubber Duckを起動し、フィードバックを得る。
Rubber Duckの手動起動
ユーザーはいつでもCopilotに作業の批評を要求でき、Rubber Duckが起動してフィードバックを提供し、変更内容と理由が表示される。
対応モデルと実験的提供
現在はClaudeファミリーモデル（Opus、Sonnet、Haiku）でのみ利用可能で、GPT-5.4との連携も検討中。実験モードで提供されている。
影響分析・編集コメントを表示
影響分析
この発表は、単一の大規模言語モデル（LLM）に依存するのではなく、異なるモデルファミリーを組み合わせる「アンサンブル」や「レビュー」アプローチの実用化を示しており、AIエージェントの信頼性と性能向上に向けた新たな方向性を提示している。開発現場での実用的な価値が高く、AI支援開発ツールの進化に影響を与える可能性がある。
編集コメント
AIエージェントの「自信過剰な間違い」という根本的な課題に対して、技術的にシンプルながら効果的なソリューションを提案した点が秀逸。実証データを伴った発表であり、業界の実践に即した進展と言える。
コーディングエージェントにデータパイプラインの構築を依頼すると、最適な構造が採用されない場合があります。しかし、エージェントが計画を実行する前にセカンドオピニオンを得られるとしたらどうでしょうか？
本日、GitHub Copilot CLIに、実験モードとして「Rubber Duck」を導入します。Rubber Duckは、異なるAIファミリーに属する第二のモデルを活用し、独立したレビュアーとして機能します。フィードバックが最も重要なタイミングで、エージェントの計画と作業を評価します。
様々な種類のエラーを捕捉するには、異なる視点が重要です。評価の結果、Claude SonnetにRubber Duckを組み合わせることで、Sonnet単体とOpus単体の性能差の74.7%を埋め、難易度の高いマルチファイルタスクや長時間実行タスクにおいて、より優れた結果を達成できることがわかりました。Copilot CLIで /experimental コマンドを使用すると、他の実験的機能とともにRubber Duckを利用できます。
問題: 確信のある間違いが連鎖する
現在のコーディングエージェントは明確なループに従います。まずタスクを評価し、計画を立案、実装、テストを行い、必要に応じて反復します。これは強力なフローですが、盲点があります。エージェントが初期段階、特に計画段階で下す決定は、その後の作業の土台となります。仮定や非効率性は依存関係として組み込まれ、気づいた時には、最初の小さな間違い以上の修正が必要になっている可能性があります。
自己反省を行い、エージェントが次のステップに進む前に自身の出力をレビューするのは、実証済みの手法です。しかし、モデルが自身の作業をレビューしても、自身のトレーニングバイアス（同じトレーニングデータと手法、同じ盲点）に縛られてしまいます。
Rubber Duckが第二の視点を追加
Rubber Duckは、主要なCopilotセッションのモデルとは相補的なファミリーのモデルによって駆動される、焦点を絞ったレビューエージェントです。モデルピッカーからオーケストレーターとしてClaudeモデルを選択した場合、Rubber DuckにはGPT-5.4が使用されます。Rubber Duckの実験を通じて、オーケストレーターとRubber Duckに他のモデルファミリーを採用することも検討しています。Rubber Duckの役割は、エージェントの作業をチェックし、短く焦点を絞った高価値な懸念事項のリストを提示することです。これには、主要エージェントが見逃した可能性のある詳細、疑問を持つ価値のある仮定、考慮すべきエッジケースが含まれます。
クロスファミリーレビューが役立つ場面
私たちはRubber Duckを、オープンソースリポジトリから抽出された大規模で難易度の高い実世界のコーディング問題からなるベンチマーク「SWE-Bench Pro」で評価しました。結果は以下の通りです：
- Claude Sonnet 4.6に、GPT-5.4を実行するRubber Duckを組み合わせることで、Claude Opus 4.6単体の実行に近い解決率を達成し、SonnetとOpusの性能差の74.7%を埋めました。
- Rubber Duckは、3つ以上のファイルにまたがり、通常70ステップ以上を要する難易度の高い問題で、より大きな効果を発揮する傾向があることがわかりました。こうした問題では、Sonnet + Rubber DuckはSonnet単体のベースラインより3.8%高いスコアを記録し、3回の試行で特定された最も難しい問題では4.8%高くなりました。
以下は、Rubber Duckが発見した問題の例です：
- アーキテクチャ上の捕捉 (OpenLibrary/非同期スケジューラ): Rubber Duckは、提案されたスケジューラが起動後すぐに終了し、ジョブを一切実行しないこと、さらに、仮に修正されたとしても、スケジュールされたタスクの1つがそれ自体無限ループであることを指摘しました。
- ワンライナーのバグ、大きな影響 (OpenLibrary/Solr): Rubber Duckは、各反復で同じ辞書キーを警告なく上書きしてしまうループを捕捉しました。これにより、4つのSolrファセットカテゴリのうち3つがすべての検索クエリから除外されていましたが、エラーはスローされませんでした。
- クロスファイルの矛盾 (NodeBB/メール確認): Rubber Duckは、新しいコードが書き込みを停止したRedisキーを参照している3つのファイルを発見しました。このままでは、確認UIとクリーンアップの処理パスは、デプロイ時に警告なく破損していたでしょう。
Rubber Duckはいつ起動するのか？
GitHub CopilotはRubber Duckを自動的に呼び出すことができ、プロアクティブにもリアクティブにも、またユーザーがいつでも手動でトリガーして作業を批評・修正させることができます。
複雑な作業では、GitHub Copilotはフィードバックの効果が最も高いチェックポイントで自動的に批評を求めます：
- 計画立案後: 開発者にとって最大の効果が期待できる段階です。最適でない決定を早期に捕捉することで、後続工程でのエラーの連鎖を防げます。
- 複雑な実装後: 複雑なコードに第二の目を向けることで、エッジケースを捕捉するのに役立ちます。
- テスト作成後、実行前: 「すべて合格」という自己満足に陥る前に、テストカバレッジの不足や欠陥のあるアサーションを捕捉する機会となります。
また、エージェントがループに陥ったり進捗できなくなったりした場合、リアクティブに批評を求めることもあります。Rubber Duckに相談することで、行き詰まりを打破できます。
ユーザーとしても、いつでも批評をリクエストできます。CopilotはRubber Duckに問い合わせ、フィードバックを検討し、何がどのように変更されたかを表示します。
私たちは重要な設計上の選択を行いました。エージェントはRubber Duckを必要最小限に呼び出し、効果が最も高い瞬間を狙い、作業の邪魔にならないようにしています。技術的に興味がある方へ：Rubber Duckは、Copilotの既存のタスクツール（他のサブエージェントにも使用されている同じインフラストラクチャ）を通じて呼び出されます。
現在、モデルピッカーでオーケストレーターとして選択可能なすべてのClaudeファミリーモデル（Opus、Sonnet、Haiku）に対してRubber Duckを有効にしています。また、オーケストレーターにGPT-5.4を使用した場合に組み合わせる、Rubber Duck用の他のモデルファミリーについても検討を始めています。
始め方
Rubber Duckは本日、実験モードで利用可能です。
使用を開始するには、GitHub Copilot CLIをインストールし、/experimental スラッシュコマンドを実行してください。モデルピッカーから任意のClaudeモデルを選択し、GPT-5.4へのアクセスが有効になっていれば、Rubber Duckを利用できます。批評は以下の2通りの方法で表示されます：
- 自動的に: Copilotがチェックポイントでセカンドオピニオンが必要と判断したとき（計画後、複雑な実装後、テスト作成後）。
- オンデマンドで: いつでも依頼できます。Copilotに作業を批評するよう指示するだけで、Rubber Duckを呼び出し、フィードバックを取り込んで、変更点を正確に表示します。
Rubber Duckが最も役立つ場面：
- 複雑なリファクタリングとアーキテクチャ変更
- ミスが重大な結果を招くハイステークスタスク
- 包括的なテストカバレッジの確保
- 計画にコミットする前にセカンドオピニオンが欲しいとき
GitHub Copilot CLIのRubber Duckは、実験モードで利用可能になりました。ディスカッションでフィードバックを共有してください。
*この投稿「GitHub Copilot CLI combines model families for a second opinion」は、The GitHub Blogに最初に掲載されました。*
原文を表示
When you ask a coding agent to build a data pipeline, it may not use the best structure. But what if the agent got a second opinion before it executed the plan?
Today, in GitHub Copilot CLI, we’re introducing Rubber Duck in experimental mode. Rubber Duck leverages a second model from a different AI family to act as an independent reviewer, assessing the agent’s plans and work at the moments where feedback matters most.
To catch different kinds of errors, a different perspective matters. Our evaluations show that Claude Sonnet + Rubber Duck makes up 74.7% of the performance gap between Sonnet and Opus alone, achieving better results for tackling difficult multi-file and long-running tasks. Use /experimental in Copilot CLI to access Rubber Duck alongside our other experimental features.
The problem: Confident mistakes can compound
Today’s coding agents follow a clear loop. First, the agent assesses the task, then drafts a plan, implements, tests, and iterates if necessary. It’s a powerful flow that works well, but it has blind spots. Any decision an agent makes early on, especially in the planning stage, is the foundation you’re building upon. Assumptions and inefficiencies become dependencies, and by the time you notice, you may have to fix more than just the small mistake at the start.
Using self-reflection and having the agent review its own output before moving forward is a proven technique. However, a model reviewing its own work is still bounded by its own training biases: the same training data and techniques, the same blind spots.
Rubber Duck adds a second perspective
Rubber Duck is a focused review agent, powered by a model from a complementary family to your primary Copilot session. When you’ve selected a Claude model from the model picker to use as your orchestrator, Rubber Duck will be GPT-5.4. As we experiment with Rubber Duck, we are exploring other model families for the orchestrator and for the Rubber Duck. The job of Rubber Duck is to check the agent’s work and surface a short, focused list of high-value concerns: details that the primary agent may have missed, assumptions worth questioning, and edge cases to consider.
When does the cross-family review help?
We evaluated Rubber Duck on SWE-Bench Pro, a benchmark of large, difficult, real-world coding problems drawn from open-source repositories. Here’s what we found:
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.
We noticed that Rubber Duck tends to help more with difficult problems, ones that span 3+ files and would normally take 70+ steps. On these problems, Sonnet + Rubber Duck scores 3.8% higher than the Sonnet baseline, and 4.8% higher on the hardest problems identified across three trials. Here are a few examples of what Rubber Duck finds:
Architectural catch (OpenLibrary/async scheduler): Rubber Duck caught that the proposed scheduler would start and immediately exit, running zero jobs—and that even if fixed, one of the scheduled tasks was itself an infinite loop.
One-liner bug, big impact (OpenLibrary/Solr): Rubber Duck caught a loop that silently overwrote the same dict key on every iteration. Three of four Solr facet categories were being dropped from every search query, with no error thrown.
Cross-file conflict (NodeBB/email confirmation): Rubber Duck caught three files that all read from a Redis key which the new code stopped writing. The confirmation UI and cleanup paths would have been silently broken on deploy.
When does Rubber Duck activate?
GitHub Copilot can call Rubber Duck automatically, both proactively and reactively, and it can be triggered by a user at any time to critique and revise its work.
For complex work, GitHub Copilot may seek a critique automatically at the checkpoints where feedback has the highest return:
After drafting a plan: This is where we expect developers will see the biggest wins, because catching a suboptimal decision early avoids compounding errors downstream.
After a complex implementation: This is when a second set of eyes on complex code can help catch edge cases.
After writing tests, before executing them: This is a chance to catch gaps in test coverage or flawed assertions, before self-reinforcing that “everything passes.”
The agent can also seek a critique reactively if it gets stuck in a loop or can’t make progress. Consulting Rubber Duck can break the logjam.
As a user, you can request a critique at any point. Copilot will query Rubber Duck, reason over the feedback, and show you what changed and why.
We made a key design choice: the agent invokes Rubber Duck sparingly, targeting the moments where the signal is highest, without getting in the way. For the technically curious: Rubber Duck is invoked through Copilot’s existing task tool—the same infrastructure used for other subagents.
For now, we are enabling Rubber Duck for all Claude family models (Opus, Sonnet, and Haiku) used as orchestrators in the model picker. We are already exploring other model families for the Rubber Duck to pair with GPT-5.4 as the orchestrator.
Getting started
Rubber Duck is available today in experimental mode.
To start using it, install GitHub Copilot CLI, and run the /experimental slash command. Rubber Duck will be available when you select any Claude model from the model picker and have access enabled to GPT-5.4. You’ll see critiques surface in two ways:
Automatically, when Copilot decides a checkpoint warrants a second opinion: after planning, after complex implementations, or after writing tests.
On demand, whenever you ask. Just tell Copilot to critique its work, and it will invoke Rubber Duck, incorporate the feedback, and show you exactly what changed.
Where Rubber Duck helps most:
Complex refactors and architectural changes
High-stakes tasks where a miss is costly
Ensuring comprehensive test coverage
Any time you want a second opinion on a plan before committing to it
Rubber Duck in GitHub Copilot CLI is now available in experimental mode. Share your feedback with us in the discussion.
The post GitHub Copilot CLI combines model families for a second opinion appeared first on The GitHub Blog.
関連記事
2026年3月6日 Frontier Red TeamによるClaudeのCVE-2026-2796エクスプロイトのリバースエンジニアリング
Frontier Red Teamが、Claudeの脆弱性CVE-2026-2796を悪用するエクスプロイトをリバースエンジニアリングした。
フロンティア・レッドチーム、Firefoxのセキュリティ向上のためにMozillaと提携
フロンティア・レッドチームは、Firefoxのセキュリティを向上させるため、Mozillaと提携した。
59％のユーザーがより安価なモデルを選択：Sonnet 4.6の詳細解説
Anthropic社がClaude Sonnet 4.6をリリースし、Claude Codeテストで70％のユーザーが前世代モデルより好み、59％がフラッグシップモデルOpus 4.5よりも選択した。コーディング、コンピュータ利用、100万トークンコンテキストなど6次元で全面アップグレードされ、価格は据え置き。