Copilot CLIに「ラバーダック」がやってきた — 異なるモデル同士で相互レビューする時代

開発者なら一度はやったことがあるはずだ。詰まったときにデスクに置いたラバーダックに向かって自分のコードを説明し、喋っているうちに「あ、ここが間違ってる」と気づく、あの作業。

GitHubがそれをLLMでやらせ始めた。

4月6日、GitHub Copilot CLIにRubber Duckという実験機能が追加された。簡単に言えば、メインで走らせているAIエージェントとは別の「第二の頭」を裏で動かし、計画と実装にセカンドオピニオンを入れる仕組みだ。そしてこの「第二の頭」には、メインとは異なるファミリーのモデルが使われる。

派手さはないが、効きそうな機能だ。体感面でも数字面でもインパクトが大きいので、整理しておきたい。

何が新しいのか

Rubber Duckの核は「違う系統のAIに見てもらう」という一点にある。

従来のAIコーディングエージェントは、基本的に1つのLLMが計画から実装まで全部やる。セルフレビューもそのモデル自身が行う。ところが、同じモデルファミリーのセルフレビューには限界がある。Claude系のモデルは似たような前提を共有しているので、Claudeが見落とすエッジケースはClaudeに尋ねても気づけないことが多い。同じ学校の同級生にレビューしてもらうようなもので、視点が似すぎている。

Rubber Duckはこの構造を変える。たとえばオーケストレーター（メインで動かすモデル）にClaude Opus 4.6を選んだ場合、Rubber DuckにはGPT-5.4が割り当てられる。逆にオーケストレーターがGPT系なら、Rubber DuckにClaude系が入る。異なるアーキテクチャ、異なる学習データ、異なるアラインメントを持つモデル同士が、互いの盲点を指摘する仕組みだ。

GitHub公式ブログの記載によれば、Rubber Duckは3つのチェックポイントで自動的に起動する。

• エージェントがプランをドラフトした直後
• 複雑な実装を終えた直後
• テストを書いたあと、走らせる前

もちろん、開発者側から手動で「ラバーダックに聞いてくれ」と呼び出すこともできる。エージェントがループから抜け出せなくなったときのエスカレーション先としても使える。

数字で見る効果

Rubber Duckの面白いところは、GitHubがベンチマーク数字を正直に出してきたことだ。

GitHubの発表によると、Claude Sonnet + Rubber DuckはSonnet単体とOpus単体の性能差の74.7%を埋めるという。もう少し噛み砕くと、「軽くて安いSonnetを使っているのに、体感としては重くて高いOpusを使っているときの7〜8割の品質が得られる」ということだ。

これはコスト観点でそこそこインパクトがある。Claude Opus 4.6のAPI料金は入力$15 / 出力$75（100万トークンあたり）、対するSonnet 4.6は入力$3 / 出力$15。Sonnet + GPT-5.4の合算でも、Opus単体より明らかに安く収まる。マルチファイルの大規模リファクタリングや長時間走らせるエージェントタスクでは、このコスト差がそのまま効いてくる。

「Sonnetでいいのか、Opusじゃないと無理なのか」という悩みを、「Sonnet + Rubber Duckで十分」という答えに置き換える余地ができたわけだ。

日常で何が変わるか

実務での使い方を想像してみる。

たとえば、数百行の機能を追加するタスクをCopilot CLIに投げたとする。従来なら、エージェントが計画を立てて実装に入り、最後にテストを書いて終わりだった。Rubber Duckがオンだと、プラン段階で一度「このプラン、前提に甘いところないか？」と別モデルに聞きに行く。複雑な実装を終えた段階でもう一度「エッジケース見落としてない？」と確認。テストを書いたあと実行前に「このテスト、本当に意味のある検証になっているか？」と問う。

途中でRubber Duckが「ここ、競合状態の可能性がある」と指摘すれば、エージェントはその指摘を取り込んで実装を手直しする。どのフィードバックを反映したか、なぜ反映したか（あるいは反映しなかったか）はCopilotがユーザーに報告する。

要するに、人間のシニアエンジニアがレビューで言いそうな「それ、ちゃんと考えた？」をAIにやらせる機能、と考えれば実像に近い。

Claude Codeのサブエージェントとの違い

ここで気になるのが、既存の「エージェント内エージェント」機能との棲み分けだ。Claude CodeにはSubagent機能があり、メインのエージェントから別のコンテキストを持つサブエージェントを呼び出せる。OpenAI Codexにも同様の機能がある。

これらとRubber Duckの違いは、「同じファミリー内の分業」か「異なるファミリー間の相互監視」かにある。

Claude CodeのサブエージェントはどちらもClaude系で、コンテキストウィンドウの分割やタスクの専門化が目的だ。Rubber Duckは明示的に異なるファミリーのモデルを持ってくる。ClaudeとGPT-5.4では推論の癖も得意分野も違うため、相互レビューで盲点を補える——これが前提になっている。

言い換えると、Rubber Duckは「サブエージェント」ではなく「外部レビュアー」だ。ジュニアが書いた設計書をシニアがチェックするのではなく、A社のチームが書いた設計書をB社のコンサルに見てもらうイメージが近い。

使い方

Rubber Duckは実験機能なので、デフォルトではオフになっている。Copilot CLIをインストール済みなら、以下の流れで有効化できる。

# Copilot CLIを起動
gh copilot chat

# 実験機能メニューを開く
/experimental

# Rubber Duckを有効化

オーケストレーターとしてClaude Opus、Sonnet、Haikuのいずれかを選ぶと、自動的にGPT-5.4がRubber Duckに割り当てられる。組み合わせの固定化はされておらず、GitHub側でファミリーの組み合わせは今後増やす予定だと明言している。

実験機能のため、料金体系や利用上限については正式リリース時に改めて発表されると見られる。現時点ではCopilot ProやCopilot Businessの既存契約の中で追加料金なしで試せるが、本格展開後は別枠のクレジット消費になる可能性もある。

どんな現場で効くか

正直に書くと、Rubber Duckは全員に効く機能ではない。

効きそうな場面：

• 複数ファイルにまたがる大規模な変更を任せたいとき。見落としがそのまま本番バグになる領域ほど、相互レビューの価値が出る
• 長時間走らせる自律タスク。エージェントが暴走したり、ループに陥ったりするのをRubber Duckが拾える
• セキュリティやデータ整合性が絡むコード。「異なる視点からの二重チェック」そのものが要件になる業界
• コストを抑えつつ品質を上げたいチーム。Opus単体より安く、Sonnet単体より正確

あまり効かない場面：

• 数行の簡単な修正や、テンプレ通りの定型作業。Rubber Duckの起動コスト（レイテンシとトークン消費）がメリットを上回りそう
• プロトタイピングや使い捨てのスクリプト。品質より速度が重要な場面では邪魔になる
• 小規模なCLIユーティリティ。オーバーエンジニアリング感が出る

個人的には、CIパイプラインに組み込んだエージェントや、夜間に走らせるリファクタリングバッチなど、「人間の目がすぐには入らないタスク」ほどRubber Duckの恩恵が大きいと思う。逆にIDEでリアルタイムに補完してもらうタイプの使い方には向かない。

気になる点

手放しに褒めるつもりはない。いくつか懸念もある。

まず、レイテンシ。2つのモデルを使うので当然ながら応答時間は長くなる。GitHubの発表では「重要なチェックポイントでのみ起動する」と強調しているが、それでも体感上の遅さは増える。

次に、責任の所在が曖昧になる問題。Rubber Duckが「これで大丈夫」と言ったのに本番でバグった場合、どちらのモデルのせいなのか、それとも両方の見落としなのか——運用でどうハンドリングするかは手探りになる。

さらに、ベンチマーク数字の一人歩き。「Sonnet + Rubber Duckが74.7%の差を埋める」というのは特定のベンチマークセットでの話であって、あらゆるタスクに等しく効くわけではない。具体的な評価対象（SWE-benchなのか独自タスクなのか）や再現方法の詳細は、今後コミュニティでの検証を待ちたいところだ。

最後に、そもそも「異なるファミリーのモデルで相互レビュー」という発想自体が、AI各社の競争関係から見ると皮肉ではある。Copilotの中でOpenAIとAnthropicのモデルが協力し合う構図は、ユーザーから見ればありがたいが、各社の戦略担当からは複雑な気持ちで眺められているはずだ。

まとめ

Rubber Duckは、派手な新機能ではない。むしろ「セカンドオピニオンをシステムに組み込む」という地味だが重要な発想をAIエージェントに持ち込んだ。

やっていることはシンプルだ。別のモデルに聞きに行く。それだけ。ただ、そのシンプルさが74.7%の性能差を埋めるなら、十分に検討する価値がある。

Copilot CLIを普段から使っている人は、/experimentalを一度触ってみてほしい。普段のタスクが「それ、本当にちゃんと考えた？」と別モデルから問われる体験は、単に便利というより、AIエージェントとの付き合い方を少し変えてくれる。自分の計画や実装に対してセカンドオピニオンを得るという行為が、ここまで軽いコストで手に入るようになった。これが常態化したとき、「1つのモデルに全部任せる時代」は静かに過去のものになっていくのだろう。