AIコーディングエージェントを業務に組み込むチームが増えるにつれて、生成されたコードをどう検証するかという論点が一段と重くなってきました。エージェントは高速にコードを書きますが、その速度と引き換えに、書いた本人（つまり同じAIモデル）が自分の成果物を過信するという構造的な弱点を抱えています。VS Code 1.135で実験的に登場したRubber Duck機能は、この弱点に真正面から向き合った仕組みとして注目に値します。

本稿では、Rubber Duckがどのような機能なのかを確定した事実の範囲で整理したうえで、なぜ同一モデルの自己レビューでは不十分なのか、そして実務でマルチエージェントレビューをどう挿し込むかを、開発リーダーの視点で考えていきます。

Rubber Duckとは何か

Rubber Duckは、エージェントの作業に対して補完的なモデル、すなわち別のAIファミリーのモデルからセカンドオピニオンを得るための機能です。VS Code 1.135は2026年8月26日にリリースされ、この機能はそこで実験的（Experimental）な位置づけで実装されました。使い方はシンプルで、Copilot agent hostのセッション内で「/rubber-duck」というコマンドを実行すると、別モデルによるレビューが走ります。

狙いは明確で、エージェントが単独では気づきにくい見落としやエッジケースを表面化させることにあります。人間の開発現場でも、自分が書いたコードのバグは自分では見つけにくく、同僚に説明した瞬間に気づく、といった経験は珍しくありません。機能名の由来はまさにそこにあります。ラバーダック・デバッグ、つまりアヒルのおもちゃに向かって処理内容を一行ずつ説明していくうちに、自分自身で問題に気づくという古典的な手法へのオマージュです。今回はそのアヒルの役割を、別のAIモデルが担うわけです。

この機能はVS Codeが初出ではありません。先行実装はGitHub Copilot CLIで、2026年4月に実験的機能として登場しました。その後2026年5月に対応モデルが拡張され、2026年6月にはCopilot CLIで一般提供へと進みました。VS Code 1.135での実装は、この流れを受けてエディタ本体からも同じ発想を使えるようにしたものだと位置づけられます。つまり、コマンドラインでの実績を積んだうえでGUI環境へ広がってきた機能であり、思いつきの実験ではなく段階を踏んで練られてきた点は評価できます。

なぜ同一モデルの自己レビューでは足りないのか

ここが最も本質的な論点です。同一のAIモデルは、同じ学習データと同じ設計思想に由来する同じバイアスで物事を判断します。そのため、あるモデルが自信を持って書いたコードを、同じモデルにレビューさせても、判断の癖が重なってしまい問題を見逃しやすいのです。人間で言えば、自分の書いた文章を自分で校正しても誤字を素通りしてしまうのと似た構図です。

典型的なのは、テストを通過したのに後からエッジケースが見つかるという問題です。エージェントが自信を持って実装し、自分で書いたテストもすべて緑になった。それでも、境界値や異常系、並行処理のタイミング、想定外の入力形式といった領域に穴が残ることは珍しくありません。テストが通ったという事実は、テストで書いた範囲の正しさを示すだけであって、書き手が想像しなかったケースの安全を保証するものではないからです。

Rubber Duckの核心は、この壁をクロスモデルで越えようとする点にあります。レビュアーにあえて別のAIファミリーのモデルを使うことで、オーケストレーター（主担当）が持つ癖とは異なる視点を持ち込むわけです。たとえばClaude系モデルをオーケストレーターにした場合、Rubber DuckのレビュアーにはGPT-5.4が使われます。異なる系統のモデルは、着目する箇所も、危険だと感じる箇所も微妙に異なります。その差分こそが、自己レビューでは決して出てこない指摘の源泉になります。

重要なのは、これが単なる二度読みではないという点です。同じモデルにもう一度読ませても、増えるのは計算コストだけで、視点の多様性はほとんど増えません。別ファミリーのモデルを挟んで初めて、判断のバイアスをずらすという効果が生まれます。マルチエージェントレビューという言葉の実質は、エージェントの数を増やすことではなく、視点の系統を意図的に変えることにあると理解しておくと、設計を誤りません。

実務でのマルチエージェントレビュー導入パターン

実務に落とすうえで押さえておきたいのが、起動のタイミングです。Copilot CLIでは、必要なときに手動で呼び出すオンデマンド起動に加えて、自動起動が可能です。自動起動には3つのチェックポイントが用意されており、エージェントがプランを作成した後、複雑な実装を終えた後、そしてテストを書いた後で実行する前の各段階でレビューを自動的に挟めます。

この3点は、開発の流れのなかでも手戻りコストが急増する直前に置かれているのが巧みなところです。プラン確定の直後に方向性の誤りを正せば、後段の実装をまるごとやり直す事態を避けられます。複雑な実装の直後に見てもらえば、記憶が新しいうちに修正できます。テスト実行前に挟めば、通ってしまったテストへの過信を防げます。どこに挟むかで得られる効果がまったく変わるため、全部を一律にオンにするのではなく、プロジェクトの性質に合わせて選ぶのが現実的です。

Claude Code等を運用するチームでは、一般に次のような取り入れ方が考えられます。まず既存のワークフローを崩さず、オンデマンドで重要な変更にだけ別モデルレビューを走らせるところから始める設計です。慣れてきたら、リスクの高いモジュールや過去に不具合が集中した領域に限って自動起動を有効化し、対象を段階的に広げていく形が無理がありません。全変更に一律で挟むと、コストとレイテンシが積み上がってしまうためです。

そのうえで忘れてはならないのが、人間レビューとの役割分担です。別モデルによるレビューは、機械的な見落としや典型的なエッジケースをすくい上げるのは得意ですが、ビジネス上の妥当性や設計思想との整合、チーム固有の文脈判断までは代替できません。AI同士のクロスレビューで一次的な網を張り、人間は本質的な判断に集中する、という二層構造で捉えるのが健全です。

現時点でできることとできないこと

期待を正しく設定するために、限界も明確にしておきます。まず前提として、VS CodeのRubber Duckは実験的機能です。挙動や仕様は今後変わりうるものであり、本番のクリティカルな工程に無条件で依存するのは時期尚早だと考えるのが妥当です。実験的機能であるということは、便利さと同時に不確実性も引き受けるという意味だからです。

次に、ベンダーが公表する性能値の扱いには慎重さが求められます。たとえば、あるモデルにRubber Duckを組み合わせると上位モデルとの性能差を大きく埋める、といった数値が話題になることがありますが、これはGitHubが公表した数値であり、独立検証はこれからの段階です。こうした未検証の数値を、あたかも確定した事実であるかのように社内の意思決定に持ち込むのは避けるべきです。導入判断は、公表値そのものではなく、自分たちの実際のコードベースで試した手応えを基準にすべきです。

また、Rubber Duckがどのようにモデルを切り替え、内部でどうレビューを組み立てているかといった実装の詳細は公開されていません。したがって、内部挙動を推測して設計を組むのではなく、公表されている挙動、すなわちクロスモデルでセカンドオピニオンを得るという事実の範囲で活用方針を立てるのが安全です。ブラックボックスの部分に過度な期待を寄せない姿勢が、結果的に手戻りを減らします。

導入判断の勘所

最後に、導入するかどうかを判断するための観点を整理します。第一に見るべきはコストとレイテンシです。別モデルを呼び出す以上、追加の計算資源と時間がかかります。すべての変更に自動レビューを挟めば効果は上がるかもしれませんが、日々の開発体験は確実に重くなります。効果とコストのつり合う地点を、自分たちの規模感で見極める必要があります。

第二に、どのフェーズに挟むかを絞り込むことです。前述の3つのチェックポイントのうち、自分たちのボトルネックがどこにあるかを見定め、最も費用対効果の高い一点から始めるのが賢明です。プラン段階の誤りが多いチームならプラン直後、テストへの過信が問題ならテスト実行前、というように、痛みのある箇所に狙いを定めます。

第三に、スモールスタートを徹底することです。いきなり全社標準にするのではなく、限られたリポジトリやチームで試し、指摘の質と開発速度への影響を観察してから広げるほうが、失敗のダメージを抑えられます。実験的機能であることを踏まえれば、この慎重さはむしろ合理的です。

そして何より大切なのが、レビュー結果の受け止め方です。別モデルの指摘は貴重な視点ですが、それ自体が正解とは限りません。的外れな指摘も混ざりますし、逆に鋭い一言が重大な欠陥を救うこともあります。指摘を鵜呑みにも黙殺もせず、判断材料の一つとして扱い、最終的な採否は人間が責任を持って決める。この原則を守れる体制があってこそ、マルチエージェントレビューは戦力になります。Rubber Duckは、そうした人間中心の開発を支える補助線として捉えるのが、最も実務に効く向き合い方だと言えるでしょう。