Copilot CLIのRubber Duckとは｜クロスモデルレビューの仕組み・対応モデル・導入手順【2026年最新】

GitHubは2026年4月6日、Copilot CLIに「Rubber Duck」という実験的機能を追加しました。プライマリのAIとは別ファミリーのモデルをレビュー役に立て、計画・実装・テストの要所で独立した視点から指摘を返すクロスモデルレビューの仕組みです。発表時はClaudeをオーケストレーターにした場合にGPT-5.4がレビュー役でしたが、2026年5月7日の更新で対応モデルが広がり、ClaudeセッションはGPT-5.5と、GPTセッションはClaude製のレビュー役と組めるようになりました。この記事では、Rubber Duckが解こうとしている構造的課題、動作の仕組みと発動タイミング、SWE-Bench Proでの実証結果、最新の対応モデルと導入手順、そして実務での使いどころまでを一次情報にもとづいて整理します。

まとめ：Copilot CLIのRubber Duckの要点

• 正体：プライマリと異なるAIファミリーのモデルが計画・実装・テストを点検するレビューエージェント。単一モデルの自己レビューでは同じ学習バイアスに縛られて見つからない盲点を補う。
• 対応モデル（2026年5月更新）：Claudeセッションのレビュー役はGPT-5.5、GPTセッションのレビュー役はClaude。Copilot CLIがセッションと対照的なモデルを自動で選ぶ。
• 発動：計画立案後・複雑な実装後・テスト作成後の3つで自動発動、加えて行き詰まり検知で発動。/rubber-duck で任意に手動起動もできる。
• 効果：SWE-Bench Proで、Sonnet＋Rubber DuckがSonnet単体とOpus単体の性能差の74.7%を埋めた。効果は3ファイル以上・70ステップ超の高難度タスクほど大きく、単一ファイルの軽微修正では小さい。
• 提供状況：experimentalモード（/experimental on で有効化）。GA時期と追加料金は未公表のため、本格運用は範囲を絞るのが無難。

単一モデルの自己レビューでは埋まらない構造的な弱点

Rubber Duckが何を解こうとしているのかを押さえると、どの場面で効くのかが判断できます。「ラバーダックデバッグ」は本来、プログラマーがゴム製のアヒルに問題を声に出して説明するうちに、言語化の過程で自力で解決策に気づくデバッグ手法です。GitHubのRubber Duckはこの発想をAIエージェント同士の対話に持ち込みましたが、相手は「ただ聞いているだけ」ではなく、独自の分析でエッジケースや前提の穴を指摘してくる点が決定的に異なります。

計画段階の判断ミスが下流工程で増幅する問題

いまのAIコーディングエージェントは、タスクの評価・計画・実装・テスト・修正のループを回します。強力な流れですが、計画段階の判断がすべての土台になるため、ここでの見落としが最も広く波及します。たとえばデータパイプラインの構築で最初に選んだアーキテクチャが最適でなくても、その前提の上に実装が積み上がってしまう。計画段階の小さな誤りは、実装では複数ファイルにまたがる設計上の問題へ、テストでは表面上パスするのに本質を見逃す欠陥へと育ちます。問題に気づいたときには修正範囲が当初想定をはるかに超えている、というのがGitHubの指摘です。

同一学習データのバイアスが自己評価の精度を制限する理由

モデルが自分の出力を振り返って直すセルフリフレクションは、品質向上策として広く使われ、Copilotも従来から対応していました。ただし自己レビューには構造的な限界があります。評価もまた同じ学習データと学習手法から生成されるため、同じバイアスに支配されるからです。あるモデルが特定のデザインパターンを好むなら、そのパターンが不適切な場面でも自己レビューでは問題として検出されにくい。異なる学習データとアーキテクチャを持つ別ファミリーのモデルにレビューさせることで、この盲点を外から補うというのがRubber Duckの出発点です。

複数ファイル横断・70ステップ超でエラー蓄積率が急上昇する傾向

効果が顕著に出るのは、タスクの規模と複雑さが一定の閾値を超えたときです。GitHubの評価では、3つ以上のファイルにまたがり通常70ステップ以上を要する高難度タスクで、エラーの蓄積が急激に増える傾向が確認されています。単一ファイルの簡単な修正なら多少の判断ミスも影響は限定的ですが、ファイル間の依存を正しく把握して進める必要があるタスクでは、1つの見落としがサイレントな障害として潜伏し、デプロイ後に初めて発覚するリスクが高まります。Rubber Duckはこうした複雑なタスクで、計画段階のチェックを通じてエラーの連鎖を未然に止める役割を担います。

Rubber Duckの仕組みと発動タイミング（2026年5月の対応モデル拡大）

Rubber Duckの核心は、プライマリとは異なるAIファミリーのモデルにレビューさせるクロスモデル方式と、開発者が意識しなくても要所でレビューが入る自動発動の設計にあります。ここは発表後にもっとも動いた部分で、対応モデルと手動起動の方法が更新されています。

異なるAIファミリーを審査役に置く構成とClaude↔GPTの双方向対応

Copilot CLIは、現在のセッションモデルと対照的なファミリーのモデルをレビュー役（critic）として自動的に選びます。公式ドキュメントは「Claudeモデルをセッションに選べば、Rubber DuckはGPTモデルをcriticに使うことがある」と説明しています。2026年4月の発表時点ではClaudeオーケストレーター＋GPT-5.4の一方向でしたが、5月7日の更新で次のように広がりました。

異なるファミリーは学習データ・アーキテクチャ・学習手法が違うため、バイアスの方向も異なります。だから一方が見落としやすい問題を他方が拾える確率が上がる、というのがクロスモデルの前提です。技術的には、Rubber DuckはCopilotの既存のタスクツール基盤を通じて呼ばれます。他のサブエージェントと同じインフラを使うため、開発者は特別な環境構築なしにクロスモデルレビューを受けられます。

計画後・実装後・テスト後の3つの自動チェックポイント

Rubber Duckは、GitHubが「効果が高い」と判断した3つの局面で自動発動します。公式ドキュメントの記載どおり、(1)重要な変更を計画した後・実装に入る前、(2)複雑な実装の途中で盲点がないかを確認するとき、(3)テストを書いた後にカバレッジが十分かを検証するとき、の3点です。

最も効くのが計画直後のチェックです。計画段階の誤りは最もコストの低い時点で直せるため、実装前に方針を正せば下流の連鎖エラーをまとめて防げます。実際、SWE-Bench ProのOpenLibraryの非同期スケジューラのタスクでは、Rubber Duckが計画段階で「スケジューラが起動直後に終了する」という根本的な欠陥を指摘し、実装が始まる前に方針転換が行われました。テスト後のチェックには、テストが全部パスすると「問題なし」という誤った確信が強まるのを防ぐ狙いがあります。

行き詰まり検知によるリアクティブ発動

3つのプロアクティブなチェックポイントに加えて、GitHubのブログによれば、エージェントがループに陥って進捗が止まったときに自動で呼び出されるリアクティブな発動条件もあります。同じアプローチを繰り返しても解決しない状況では、同一モデル内で考え続けても突破口が見えにくく、まったく異なる視点の指摘が状況を打開する鍵になります。長時間のタスクをバックグラウンドで走らせ、エージェントがスタックして無駄にトークンを消費し続けるリスクを抑える意味でも働きます。

手動トリガー「/rubber-duck」と変更理由の可視化

自動発動を待たずに、任意のタイミングでレビューを頼むこともできます。公式ドキュメントは、/rubber-duck [質問] というスラッシュコマンド、または「Rubber duck your plan」のような自然言語での依頼を挙げています。発表当初は「レビューを頼むだけ」でしたが、専用コマンドが用意され、計画段階で意図的にレビューを挟む運用がしやすくなりました。

手動トリガー後のフローには工夫があります。Copilotはフィードバックを受け取ると、それを踏まえて推論し、何を変更したのか・なぜ変更したのかを開発者に明示します。差分だけでなく理由が出るため、開発者は指摘の妥当性を自分で判断できます。AIが黙って修正を適用するブラックボックスではなく、結果を理解したうえで次の一手を選べる透明性の高いワークフローになっています。

SWE-Bench Proで実証された効果（性能差74.7%縮小）

Rubber Duckの効果は、実世界のコーディング問題を集めたSWE-Bench Proベンチマークで測定されています。GitHubは、Claude Sonnet 4.6にRubber Duck（GPT-5.4）を組み合わせた構成が、Claude Opus単体との性能差の74.7%を埋めたと報告しました。

74.7%が意味すること（測定の基本構造）

「74.7%のギャップ縮小」は、SWE-Bench Proの解決率を基準にした数値です。Sonnet 4.6単体の解決率とOpus単体の解決率を両端に置き、Sonnet 4.6＋Rubber Duckの解決率がその差分のどこに位置するかを算出したものです。つまり、より安価なSonnetにRubber Duckを足すだけで、より高価なOpus単体に迫る性能が得られたことを示します。ただしRubber Duck役（発表時GPT-5.4、現在はClaudeセッションでGPT-5.5）の追加呼び出しに料金が発生するかは未公表のため、正味のコスト対効果は現時点では確定できません。それでも、大量のタスクを回すパイプラインではモデル選択の方針を見直す材料になります。

高難度タスクで解決率3.8%向上・最難関では4.8%

難易度別の内訳も公開されています。3つ以上のファイルにまたがり通常70ステップ以上を要する高難度タスクでは、Sonnet＋Rubber DuckがSonnet単体より解決率が3.8%向上し、3回の試行で最も難しいと判定されたサブセットでは4.8%に達しました。効果がタスクの複雑さに比例して大きくなることを示す結果です。逆に、単一ファイルで完結する修正や数ステップで終わる定型的な変更では、プライマリ単体でも十分な精度が出るため、クロスモデルレビューの上積みは小さくなります。GitHubがRubber Duckを「控えめに」発動させる設計にしたのは、この効果の非対称性を踏まえてシグナルの高い場面に集中させるためです。

SWE-Bench Proの評価基準（人手増強型の問題文）

SWE-Bench Proは、実世界のオープンソースリポジトリから抽出された大規模で難しいコーディング問題で構成されます。一般的なコーディングベンチマークとの違いは、人手増強型の問題文（human-augmented problem statements）を使う点にあります。実際のソフトウェアエンジニアリングタスクから要件を導くため、単なるアルゴリズム問題ではなく、バグ修正・機能追加・リファクタリングまで、複数ファイルの変更を要するタスクが多く含まれます。実験室的な条件ではなく実務に近い環境で有効性が確認された点が、自分のプロジェクトへの適用を検討する際の信頼性につながります。

Rubber Duckが検出した3つのバグ事例

数値だけでなく具体的な検出事例を知ると、どんなバグに強いのかが見えてきます。GitHubは公式ブログで、SWE-Bench Proの評価中にRubber Duckが見つけた3つのバグを公開しました。いずれもプライマリモデルが見逃していた「サイレント障害」——エラーが出ず、コードは動くのに期待どおりに動かないタイプです。

OpenLibraryの非同期スケジューラ：即時終了と無限ループの二重欠陥

1つ目はOpenLibraryの非同期スケジューラです。プライマリが提案した設計には2つの重大な欠陥がありました。まずスケジューラが起動直後に終了し、スケジュールされたジョブが1つも実行されない。さらに仮にそれを直しても、スケジュールされたタスクの1つが無限ループを含み、システムが停止する設計でした。Rubber Duckが単一の欠陥だけでなく、相互に関連する複数の欠陥を同時に検出できることを示す例です。コードレベルではなくアーキテクチャレベルの根本問題を、別ファミリーの視点で俯瞰して浮かび上がらせました。

Solrファセット処理：辞書キーの上書きで4カテゴリ中3つが消失

2つ目はOpenLibraryのSolr検索のファセット処理です。4つのSolrファセットカテゴリを処理するループで、各イテレーションが同じ辞書キーを上書きし、前のカテゴリの結果が次で潰され、最終的に4カテゴリのうち3つが検索クエリから完全に消えていました。厄介なのはエラーが一切出ないことです。コードは正常に走り、検索結果も返るのに、返るのは4分の1のカテゴリだけ。こうしたサイレント障害はテストでも検出が難しく、ユーザー報告で初めて発覚しがちです。Rubber Duckが実行パスだけでなくデータの流れに着目してレビューしたことで、辞書キーの上書きという一見些細な問題が検索品質の大幅な劣化につながる因果を特定できました。

NodeBBメール確認：書き込みを止めたRedisキーを3ファイルが読み続ける不整合

3つ目はNodeBBのメール確認機能です。新しいコードがあるRedisキーへの書き込みを止めたのに、他の3つのファイルがそのキーからの読み取りを続けていました。修正されずにデプロイされれば、メール確認のUI表示やクリーンアップ処理がサイレントに機能しなくなるところでした。変更したファイル単体を見れば問題は見つかりません。その変更が他ファイルにどう影響するかを横断的に分析して、書き込み停止と読み取り継続の不整合を発見しています。複数ファイルにまたがる状態管理の問題は人間のレビューでも見落としやすく、異なるファミリーの視点が効く典型です。

3事例に共通するサイレント障害パターン

3事例に共通するのは、いずれもエラーが出ずコードは動くのに期待と異なる結果を生む点です。プライマリがこれらを見落とした構造的原因は、「コードが正常に動作する」ことと「コードが正しく動作する」ことを混同したところにあります。単一モデルの自己レビューは構文エラーや実行時例外は容易に検出できても、ビジネスロジックの正確さやデータフローの整合性は同じバイアスの中で見落とされがちです。異なるファミリーが持つ「異なる盲点」が互いを補完する——3事例はその効果を裏づけています。Rubber Duckが特に効くのは、ファイル間依存に起因するバグ、状態管理の不整合、サイレントに失敗するロジックエラーで、型エラーやシンタックスエラーのようにリンターやコンパイラで自動検出できる問題への上積みは小さい、という切り分けができます。

Rubber Duckの導入手順と対応モデルの設定要件

ここからは実際の導入です。2026年時点では実験的機能として提供され、いくつかの前提条件があります。

Copilot CLIのインストールからexperimental有効化まで

最初のステップはGitHub Copilot CLIのインストールです。Copilot CLIはターミナル上で動くGitHubのAIコーディングアシスタントで、タスクを自然言語で記述するとエージェントが自律的に計画・実装・テストまで進めます。エディタ内の補完だけでなくCLIから使いたい場合の導入は、動作モードや料金も含めてGitHub Copilot CLIとは？Autopilot・Planなど動作モードと料金・インストールを解説にまとめています。インストール後、Rubber Duckを含む実験的機能は /experimental on で有効化します。特別な設定ファイルの編集やプラグイン追加は不要で、コマンドで準備が整います。

対応モデルの組み合わせ（セッションと対照的なcriticを自動選択）

レビュー役はモデルピッカーでの選択に応じて自動で割り当てられます。開発者がRubber Duck用のモデルを個別指定する必要はありません。現在は、セッションがClaude系ならレビュー役はGPT-5.5、セッションがGPT系ならレビュー役はClaude系、というかたちで、Copilot CLIが対照的なモデルを選びます。公式ドキュメントは「Rubber DuckはメインのエージェントがClaudeまたはGPTの大規模言語モデルを使っている場合にのみ利用できる」と明記しています。

SWE-Bench Proで74.7%のギャップ縮小が確認されたのはSonnet 4.6との組み合わせです。Opusをオーケストレーターにすると元の性能が高いぶん上積みは相対的に小さく、Haiku構成の具体的な数値は公開されていません。費用対効果の検証がもっとも進んでいるのは、現時点ではSonnet＋Rubber Duckの構成です。

追加料金の未公表とチーム導入時の確認事項

注意すべきは、Rubber Duck役のモデル利用に追加料金が発生するかをGitHubが公式に発表していない点です。experimentalの機能であるため、GA移行時に料金体系が設定される可能性があります。大量のタスクを自動処理するワークフローに組み込む場合は、呼び出し回数に応じて予想外のコストが出るリスクを想定しておくべきでしょう。チームで導入する場合は、Copilot Businessなどで組織管理者が機能を制御している点、experimentalの有効化とモデルピッカーの選択肢が許可されているかを管理者設定で確認します。加えて、Rubber Duckはコードの一部を別ファミリーのモデル（ClaudeセッションならGPT、GPTセッションならClaude）に送る点も考慮が必要です。セキュリティポリシーやコンプライアンス要件が厳しい組織では、外部モデルへのコード送信が許可されているかを事前に確認し、機密性の高いコードベースでの利用は慎重に判断してください。

効果を最大化する実務運用と使いどころの判断

最後に、実務でどう使い分けるかを整理します。experimentalの段階でも、効果的な運用を先に固めておけば、GA移行時にスムーズにワークフローへ組み込めます。

Rubber Duckが効く場面と、無効化してよい場面の判断基準

投入が費用対効果を生むのは、ミスが発覚した時点での修正コストが高い場面です。GitHubは、複雑なリファクタリングやアーキテクチャ変更、失敗時のコストが大きい高リスクタスク、テストカバレッジの網羅性を確認したい場面、実装前に計画の妥当性を検証したい場面を挙げています。実務では、タスクを頼む前に「この変更が失敗したとき、エラーメッセージなしで問題が潜伏しうるか」を自問し、答えがイエスなら価値が高いと判断できます。具体的には、次のような場面が該当します。

• データベースやキャッシュの状態を複数モジュールが共有し、変更の影響範囲が広い
• API呼び出しチェーンが複数サービスをまたぎ、障害が連鎖しうる
• テストカバレッジが薄い領域に変更を加え、サイレント障害のリスクが高い
• 設定ファイルや環境変数の変更が複数コンポーネントの挙動に影響する

逆に、変更が単一ファイルに閉じている、修正が定型的でパターンが確立している、リンターやコンパイラで自動検出できる、といった軽微修正では上積みは小さく、レビュー時間とコストに見合いません。方向性がまだ固まっていないプロトタイピングや探索的なコーディングでも、レビューが試行錯誤を妨げることがあります。手動トリガーのみを使う運用にすれば、不要な場面での発動は避けられます。

計画フェーズで意図的に手動レビューを挟む

効果が最も高いのは計画段階のレビューです。この知見を活かすなら、複雑なタスクでは計画の立案が終わった時点でいったん実装開始を保留させ、/rubber-duck で計画のレビューを明示的に要求します。アーキテクチャレベルの問題点を洗い出し、必要に応じて計画を直してから実装に進む——この一手間で、実装後に方針を根本から見直すリスクを大きく減らせます。マイクロサービス間の通信設計やデータベーススキーマの変更など、影響範囲が広い判断ほど効きます。

大規模タスクの分割とチェックポイント設計

70ステップを超える長時間タスクは効果が高い一方で、長大になるほどレビューの焦点がぼやけます。これを避けるには、大きなタスクを意味のある単位に分割し、各単位の完了時にレビューを受けます。たとえば100ステップ超のリファクタリングなら、モジュール単位やレイヤー単位で区切り、各分割タスクの完了時にレビューを挟む。レビュー対象が限定されるぶん指摘が具体的になり、問題が見つかった場合の手戻りも小さく収まります。分割の粒度は、ファイル間の依存関係を基準に決めると検出力を活かせます。タスクのリスクに応じて、低リスクは自動発動のみ、中リスクは計画段階で手動を1回追加、高リスクは各フェーズで手動を挟む、と段階を分けるのが実用的です。

偽陽性を前提に人間レビューと併用する（過信しない運用）

ここは強調しておきます。Rubber Duckの指摘は常に正しいわけではありません。クロスモデルレビューでも、両方のモデルが共通して見落とすタイプの問題には対処できず、逆に正しいコードを誤りと指摘する偽陽性も起こります。偽陽性の指摘をそのまま修正に反映すると、かえって品質を落としかねません。したがって、Rubber Duckのフィードバックを最終判断としてそのまま受け入れず、人間の開発者が妥当性を検証する工程を必ず組み込むべきです。変更点と理由が明示される仕様は、この検証を助けます。Rubber Duckが指摘した問題と修正内容をプルリクエストの説明欄に記録しておけば、人間のレビュアーはゼロからコードを読む負担が減り、AIが見落としうる領域に集中できます。Rubber Duckの位置づけは、単一モデルの自律実行から複数モデルの協調によるコード品質保証への転換点であり、人間のチーム開発におけるピアレビューをAIに持ち込んだものと捉えると運用を設計しやすくなります。エージェントの構成そのものをどう組むかはシングルエージェントとマルチエージェントの違いと使い分けの判断基準も参考になります。

よくある質問

Rubber Duckは無料で使えますか

Rubber Duck機能自体はexperimentalモードで提供されていますが、レビュー役のモデル（ClaudeセッションならGPT-5.5、GPTセッションならClaude系）の呼び出しに追加料金が発生するかは、2026年時点でGitHubから公式発表がありません。GA移行時に料金体系が設定される可能性があるため、本格運用の前に最新の料金情報を確認してください。

Rubber Duckのレビュー役にはどのモデルが使われますか

セッションと対照的なファミリーのモデルが自動で選ばれます。Claude系をセッションに使っている場合のレビュー役はGPT-5.5（2026年4月の発表時はGPT-5.4）、GPT系をセッションに使っている場合のレビュー役はClaude系です。開発者がレビュー役を個別に指定する必要はありません。

GPTモデルをオーケストレーターにしてもRubber Duckは使えますか

使えます。2026年5月7日の更新で、GPTモデルをセッションに選んだ場合にClaude製のレビュー役が割り当てられる双方向対応が追加されました。発表当初はClaudeセッション＋GPTレビュー役の一方向のみでしたが、現在はClaude↔GPTの両方向でクロスモデルレビューを受けられます。

Rubber Duckを手動で呼び出すには

Copilot CLIのセッション中に /rubber-duck スラッシュコマンド（質問を続けて指定可能）を実行するか、「Rubber duck your plan」のような自然言語で依頼します。手動でも自動発動と同じクロスモデルレビューが走り、計画や実装への指摘が返ります。効果が高い計画段階で意図的に呼び出すのがおすすめです。

experimentalモードはどう有効化しますか

Copilot CLI上で /experimental on を実行すると、Rubber Duckを含む実験的機能が有効になります。実験的機能であるため予告なく変更・廃止される可能性があり、Rubber Duckに強く依存したワークフローを構築しすぎないことも運用上の注意点です。

「rubberduck」という別ツールのインストールが必要ですか

Rubber DuckはCopilot CLIに組み込まれた機能で、独立したツールを別途インストールする必要はありません。Copilot CLIをインストールし、/experimental on で有効化すれば利用できます。同名の無関係なツールと混同しないよう注意してください。

関連記事

• GitHub Copilot CLIとは？Autopilot・Planなど動作モードと料金・インストールを解説
• シングルエージェントとマルチエージェントの違い｜使い分けの判断基準とコスト・失敗モード
• GitHub Copilotのコードレビュー機能が正式リリース：AIが開発現場に与える革新とは
• Greptileとは？AIコードレビューの機能・料金・導入手順を解説