GitHub Copilot CLIに「Rubber Duck」登場：ClaudeとGPT-5.4が相互レビュー

プログラマーが行き詰まったときに机の上のアヒル人形に語りかける「ラバーダック・デバッグ」は有名ですが、コーディングAIに自分自身の作業を振り返らせても、同じ訓練バイアスや死角から抜け出せないのが常でした。

GitHubは4月6日、GitHub Copilot CLIの実験的機能として「Rubber Duck」を公開しました。同一モデルによる自己検証ではなく、あえて競合する別系統のAIモデルをレビュアーに据えるというユニークなアプローチを採っています。

Claudeの計画にGPTがダメ出しする仕組み

現在のコーディングエージェントは、要件確認、計画立案、実装、テストというループで自律的に動きます。しかし、初期の計画段階で間違った前提を置くと、それが負債となって下流の実装すべてを狂わせてしまいます。

自己内省（Self-reflection）を行わせても、同じモデルであれば同じ死角を見逃しがちです。そこでGitHubは、オーケストレーターにAnthropicのClaudeファミリー（Opus、Sonnet、Haiku）を選んだ場合、Rubber Duck役にOpenAIのGPT-5.4を割り当てるクロスモデル検証を導入しました。

オープンソースの難関課題を集めたベンチマーク「SWE-Bench Pro」での検証によると、Claude Sonnet 4.6とGPT-5.4によるRubber Duckを組み合わせることで、上位モデルであるClaude Opus 4.6単体との性能差を74.7%縮めることに成功しました。

特に効果を発揮したのが、3ファイル以上をまたぎ70ステップを超えるような大規模タスクです。Sonnet単体と比べて成功率は3.8%向上し、3回の試行で最も困難と判定されたタスク群では4.8%スコアを伸ばしました。

GitHubが公表した検出事例も実践的です。OpenLibraryの非同期スケジューラ改修では、起動直後にジョブを実行せず即座に終了する不具合やタスク内の無限ループを指摘しました。また、Solr検索のループ処理で辞書のキーが上書きされ4つのファセットのうち3つが無言で失われるバグや、NodeBBでRedisへの書き込み廃止に伴い別ファイル側の参照処理が壊れる競合も未然に防いでいます。

必要な瞬間だけ呼び出す設計

2つのフロンティアモデルを常時走らせると、レイテンシもAPIコストも跳ね上がります。そのためGitHubは、成果が最も出やすいチェックポイントに絞ってRubber Duckを自動起動する仕組みにしました。

1つ目は計画策定直後です。ここで設計ミスを摘み取ることで、手戻りを最小限に抑えられます。

2つ目は複雑なコード実装の完了直後で、見落としがちなエッジケースの点検に充てられます。

3つ目はテストコード作成後、それを実行する直前です。テストケースのアサーション自体に欠陥があり「全テスト合格」と誤認する事態を防ぎます。

エージェントが思考ループに陥った場合の打開策としても呼び出されるほか、開発者が手動でレビューを指示することも可能です。Copilot CLIで /experimental コマンドを実行し、ClaudeモデルとGPT-5.4へのアクセス権があればすぐに試せます。

なぜ重要か

開発者にとっての価値は、手頃なコストで上位モデル並みの精度を手に入れられる点にあります。高価なOpusをフル稼働させずとも、日常のコーディングは軽快なSonnetに任せ、急所でのみGPT-5.4のチェックを挟むことで堅牢なコードを生成できます。複数ファイルに影響が及ぶリファクタリングなど、サイレント障害が怖い現場なら試す価値は十分にあります。

業界全体にとっても、単一モデルの性能向上だけに頼る開発競争に一石を投じる動きと言えます。訓練データやアライメント方針の異なる別系列のモデル同士を組み合わせるほうが、単独のモデルを肥大化させるより実務上の死角を消しやすいことが実証されました。今後はCursorなどの競合ツールでもマルチベンダー連携が標準機能になる可能性があります。

GitHubのやり方は、全ステップではなく設計・実装・テスト直前の3点に絞って呼び出す点で非常に実用的で賢明です。ただし、外部APIを2系統跨ぐことによるレスポンスの遅延や、両モデルの意見が割れた際に主エージェントがどう裁定を下すのかといった課題については、今後の運用を見極める必要がありそうです。