GitHub Copilot CLIの「Rubber Duck」を試してみた。異なるAIモデルがコードをレビューする

GitHub Copilot CLIの「Rubber Duck」を試してみた。異なるAIモデルがコードをレビューする

2026.04.09

どうも!オペ部の西村祐二です!

GitHub Copilot CLIに、異なるモデルファミリーを組み合わせてセカンドオピニオンを得る「Rubber Duck」が実験的機能(experimental mode)として提供開始されました。

メインのコーディングエージェントとは別のモデルファミリーが独立したレビュアーとして機能し、実装中のコードを自動的にチェックする仕組みです。

Rubber Duckとは

Rubber Duckは、Copilot CLIのコーディングエージェントが作業中に、異なるモデルファミリーのAIに独立したレビューを依頼する機能です。

名前の由来は、プログラマの間で知られる「ラバーダックデバッグ」です。机の上のアヒルのおもちゃにコードを説明することで、自分では気づかなかった問題に気づくというデバッグ手法です。Rubber Duckでは、この「説明する相手」を異なるモデルファミリーのAIが担います。

名前の由来は、プログラマの間で知られる「ラバーダックデバッグ」です。机の上のアヒルのおもちゃにコードを説明することで、自分では気づかなかった問題に気づくというデバッグ手法です。Rubber Duckでは、この「説明する相手」を異なるモデルファミリーのAIが担います。

モデルの組み合わせ

役割 モデル
メインエージェント(オーケストレーター) Claudeファミリー(Opus / Sonnet / Haiku)
Rubber Duck(レビュアー) GPT-5.4

訓練データも学習手法も異なるモデルファミリーを組み合わせることで、同一モデルでは見落としやすい点を補完するという設計思想です。自分の作業を自分でレビューしても限界がある、という発想がベースにあります。

仕組み

自動起動タイミング

Rubber Duckは以下の3つのチェックポイントで自動的に起動します。

  1. 計画策定後 -- 実装を開始する前に、プランの妥当性をレビュー
  2. 複雑な実装の完了後 -- コード変更に対してアーキテクチャ・ロジック面をチェック
  3. テスト記述後(実行前) -- テストコードの妥当性や抜け漏れを確認

これらのチェックポイントに加え、エージェントがループに陥って進展しない場合には反応的(reactive)に介入する仕組みもあります。ユーザーが明示的にレビューを依頼するオンデマンドモードも用意されています。

検出された問題の具体例

公式ブログでは、Rubber Duckが実際に検出した3つの問題が紹介されています。

  • アーキテクチャエラー(OpenLibrary): 非同期スケジューラーが即座に終了する設計上の欠陥。さらに、スケジュールされたタスク自体が無限ループだったことも追加で検出された
  • ループバグ(OpenLibrary / Solr): 辞書のキーが反復処理中に上書きされる問題。4つのファセットカテゴリのうち3つがすべての検索クエリから欠落する結果になっていた
  • クロスファイル競合(NodeBB): 複数のファイルが同じRedisキーを参照しているが、新しいコードによって書き込みが停止されるメール確認周りの整合性の問題

公式ブログでは、いずれもテストをパスしてしまう「サイレントな障害」であり、同一モデルのセルフレビューでは見落としやすいタイプの問題だと説明されています。

ベンチマーク結果

ソフトウェアエンジニアリングタスクのベンチマークであるSWE-Bench Proでの評価結果が公開されています。

  • Claude Sonnet 4.6 + Rubber Duck(GPT-5.4) の組み合わせで、Sonnet単体とOpus単体の性能差を74.7%縮小
  • Sonnetベースラインに対して3.8%高いスコア、最難関の問題カテゴリでは4.8%の向上
  • 特に複雑なタスク(3ファイル以上の変更、70ステップ以上の操作が必要なもの)で顕著な効果

つまり、比較的安価なSonnetにRubber Duckを組み合わせることで、高価なOpus単体に近い品質が得られるという結果です。一方で、単純なタスクではレビューのオーバーヘッドが目立つ場合もあると公式ブログで言及されています。

使い方

Copilot CLI上で以下のコマンドを実行して有効化します。

/experimental on

利用モードは2つあります。

  • 自動批評: Copilotが最適なタイミングで自動的にRubber Duckを起動
  • オンデマンド: ユーザーが明示的にレビューを依頼

現時点ではすべてのClaudeモデル(Opus / Sonnet / Haiku)をオーケストレーターとして利用可能で、Rubber Duck側はGPT-5.4が使われます。今後、他のモデルファミリーとの組み合わせも検討されているとのことです。

利用条件として、GitHub Copilotのサブスクリプション(Free / Pro / Pro+ / Business / Enterprise)が必要です。

試してみた

環境

  • GitHub Copilot CLI 1.0.21
  • macOS

Rubber Duckの有効化

Copilot CLIで /experimental on を実行すると、RUBBER_DUCK_AGENT を含む全実験的フラグが有効化されます。/experimental show で有効化されたフラグ一覧を確認できます。RUBBER_DUCK_AGENT が含まれていればOKです。

Feature Flags:
  PERSISTED_PERMISSIONS        - Enable persisted tool permissions across sessions on a per-location basis
  SESSION_CLEANUP              - Enable /session cleanup and /session prune commands for managing session storage
  ...
  RUBBER_DUCK_AGENT            - Enable rubber-duck subagent for constructive feedback on code and designs (available for Claude models)

Rubber Duck以外にも MULTI_TURN_AGENTS(マルチターンのサブエージェント)や EXTENSIONS(プログラマティックなツール/フック拡張)など、興味深いフラグが並んでいます。

テスト作成タスクで動作確認

既存のTypeScriptプロジェクトに対して「テストを書いて」と依頼してみました。
対象のコードは申請者のサイトURLやメールアドレスからドメインを抽出・正規化するユーティリティ関数群です。

まず、Copilot CLIがブランチ作成・ディレクトリ作成を行った直後に、Rubber Duckが自動的にテスト計画のレビューを開始しました。

● Rubber-duck Review test plan for orgcode utils
  │ Search (grep)
  │   │ "padShortDomain|normalizeDomain|generateUniqueOrgCode" in **/*.{ts,tsx} (src)
  │   └ 6 lines found
  └ Read orgcode-usecase.test.ts
      │ tests/unit/application/usecases/org-usecase.test.ts
      └ L1:220 (219 lines read)

Rubber Duckはサブエージェントとしてバックグラウンドで動作します。メインのエージェントはRubber Duckの完了を待たずにテストの実装を進めていました。

◐ The rubber-duck agent is taking longer than expected.
  Let me proceed with writing the tests based on my plan,
  and if the rubber-duck agent provides additional feedback, I can update the tests.

Rubber Duckからのフィードバック

しばらくすると、Rubber Duckからフィードバックが返ってきました。メインエージェントがそれを受けて以下のように報告しています。

● ラバーダックのフィードバックを受けました。いくつかの重要な点を指摘されました:
   - 全サフィックスのテーブル駆動テスト
   - filterCompanySuffix のエッジケース(末尾スペース・カンマ)
   - getEmailDomain の境界値(@example.com、user@)
   - 空文字入力

具体的には、以下のような指摘がありました。

  • テーブル駆動テスト: 全17サフィックスを網羅的にテストすべき
  • エッジケース: "Acme Inc. "(末尾スペース)や "Acme Inc.,"(末尾カンマ)で、サフィックス除去が正しく動くか
  • 境界値: "@example.com""user@" のような不正フォーマットのメールアドレス
  • 中間位置のサフィックス: "Co. Working Labs" のように途中にサフィックスが含まれるケースは除去しないこと
  • 空文字入力の処理

メインエージェントはこのフィードバックを受けて、最初に書いたテストを修正し、指摘されたエッジケースを追加しました。最終的に全50件のテストがパスしています。

所感

実際に試してみて感じた点をいくつか挙げます。

  • 介入タイミングが自然: テスト計画の策定後に自動的にレビューが走り、計画段階でのエッジケース漏れを指摘してくれた。手動でレビューを依頼する必要がなかった
  • バックグラウンド実行: Rubber Duckの処理を待たずにメインエージェントが実装を進め、フィードバックが来たら取り込むという並列的なワークフローになっていた
  • フィードバックの具体性: 「テーブル駆動テストにすべき」「この入力パターンを忘れている」など、実装に直結する具体的な指摘だった。抽象的な改善提案ではなく、すぐにアクションに移せる内容だった
  • 特別な設定不要: 異なるモデルファミリーの組み合わせがCopilot CLIにデフォルトで用意されており、/experimental on だけで利用できる手軽さが良い。MCPやプラグインを自分で構築しなくても、マルチモデルレビューの恩恵を受けられる

Claude Codeで同じことをやるには

Claude Codeユーザーとして気になるのは「同じような仕組みをClaude Code側でも実現できるか」という点です。

2026年4月9日時点でClaude Codeには異なるモデルファミリーによる自動レビューの組み込み機能はありません。ただし、プラグインやMCPを使うことで類似のワークフローを構築できます。

OpenAI公式のCodexプラグイン(おすすめ)

OpenAIがClaude Code向けに公式プラグインcodex-plugin-ccを公開しています。Rubber Duckと同様に、Claude Codeの作業をGPT系モデル(Codex)にレビューさせることができます。

インストールは以下の通りです。

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

主なコマンドは3つあります。

  • /codex:review -- 未コミットの変更やブランチ差分をCodexにレビューさせる
  • /codex:adversarial-review -- 設計判断やトレードオフに踏み込んだ批判的レビュー。レビュー観点をテキストで指定できる
  • /codex:rescue -- タスク自体をCodexに委譲する(バグ調査、修正など)

Rubber Duckの自動トリガーに近い仕組みとして、Review Gateも用意されています。/codex:setup --enable-review-gate で有効化すると、StopフックによってClaudeの作業完了時にCodexレビューが自動実行されます。レビューで問題が見つかった場合、Claudeが自動的に修正を試みるループが回る仕組みです。

比較

観点 Copilot CLI Rubber Duck Claude Code + Codexプラグイン
モデルの多様性 Claude系 + GPT-5.4(組み込み) Claude系 + Codex(プラグイン)
設定の手間 /experimental on で有効化 プラグインインストール + Codexログイン
自動トリガー 3つのチェックポイント + 反応的介入 Review Gate(Stopフック)で自動実行
カスタマイズ性 組み込みのため限定的 モデル・effort・レビュー観点を自由に指定可能
タスク委譲 なし /codex:rescue でCodexにタスクを委譲可能

Copilot CLIは有効化の手軽さが強みで、Codexプラグインカスタマイズやタスク委譲など柔軟性が高いという違いがありそうです。

まとめ

GitHub Copilot CLIのRubber Duckは、異なるモデルファミリーを組み合わせることで「自分の作業を自分でレビューする」限界を補おうとする機能です。SWE-Bench Proでの結果を見ると、特に複雑なタスクでの効果が高く、安価なモデルの品質を引き上げるアプローチとして興味深いものがあります。

AIコーディングエージェントの品質保証において、「異なるモデルファミリーにレビューさせる」というアプローチは今後広がっていくかもしれません。

誰かの参考になれば幸いです。

関連リンク

この記事をシェアする

関連記事