GitHub Copilot CLIを使っている開発者や管理者にとって、今回のポイントは「Rubber DuckがGPT系セッションでも使いやすくなり、Claude系セッションでは批評側のGPTモデルが強化された」という点です。2026年5月7日のGitHub公式Changelogでは、GPTモデルをオーケストレーターとして使うセッションで、Claude-poweredのRubber Duck批評エージェントが利用可能になったこと、ClaudeセッションではRubber Duck側のGPTモデルがGPT-5.5に強化されたことが案内されています。利用するにはCopilot CLIでcopilotを起動し、/experimental onを有効にします。(The GitHub Blog)
今回の変更は、GitHub Copilotのコード生成機能そのものが別物になるアップデートではありません。むしろ、複雑な設計変更、複数ファイルにまたがる修正、テスト設計などで、Copilot CLIが「別系統のモデルに一度レビューさせる」場面が広がったと理解すると実務に落とし込みやすくなります。管理者は、Copilot CLIの利用可否、モデルポリシー、Copilotシート割り当て、実験機能の扱いを確認してから展開するのが安全です。(GitHub Docs)
GitHub Copilot CLIのRubber Duckとは何か
Rubber Duckは、GitHub Copilot CLIに組み込まれている批評用エージェントです。メインのCLIエージェントが作成した計画、設計、実装、テストを別のAIモデルに確認させ、見落としや設計上の弱点、実装上の問題を指摘する役割を持ちます。(GitHub Docs)
名前の由来は、開発者がラバーダックに向かってコードや考え方を説明することで問題に気づく「ラバーダック・デバッグ」です。Copilot CLIのRubber Duckでは、人間が説明する代わりに、Copilotが自分の計画や変更内容を別モデルに見せて批評を受けます。
重要なのは、Rubber Duckがファイルを直接編集する主体ではないことです。公式ドキュメントでは、Rubber Duckは提案された変更をレビューするためのものであり、ファイル変更を行うかどうかはメインエージェントが判断すると説明されています。(GitHub Docs)
つまり、Rubber Duckは「もう1人の実装者」ではなく、「実装前後に呼ばれるレビュー担当」と考えると分かりやすいでしょう。
2026年5月7日のアップデートで変わったこと
今回の変更点は、大きく2つです。
| 利用中のCopilot CLIセッション | 変更前の考え方 | 今回の変更後 |
|---|---|---|
| GPTモデルを使うセッション | Rubber Duckの対象が限定的だった | Claude-poweredのRubber Duck批評エージェントが利用可能に |
| Claudeモデルを使うセッション | GPT系モデルが批評役として使われる | Rubber Duck側のGPTモデルがGPT-5.5に強化 |
| 利用条件 | 実験機能として扱われる | copilot起動後に/experimental onを有効化して試す |
GitHubの公式Changelogでは、GPTモデルをオーケストレーターとして選んだ場合にClaude-poweredのRubber Duckエージェントがセカンドオピニオンを提供し、ClaudeオーケストレーターのセッションではGPT-5.5がRubber Duckモデルとして使われると説明されています。(The GitHub Blog)
ここでいう「オーケストレーター」は、CLIセッション全体を進める中心モデルのことです。たとえば、開発者がGPT系モデルを選んでCopilot CLIに作業を依頼した場合、Rubber Duck側にはClaude系の批評エージェントが入り、逆にClaude系モデルのセッションではGPT系モデルが批評役になります。
この構成の狙いは、同じモデルに自己点検させるのではなく、別ファミリーのモデルから異なる視点を得ることです。GitHub Docsでも、Rubber Duckはセッションを駆動するモデルとは異なるAIモデルを使い、現在のセッションモデルと対照的な批評モデルを選ぶと説明されています。(GitHub Docs)
開発者にとってのメリット
開発者側のメリットは、「Copilot CLIの出力をそのまま信じる」リスクを下げやすくなることです。特に、次のような作業では恩恵を受けやすいでしょう。
| 活用シーン | Rubber Duckが役立つ理由 | 開発者が確認すべきこと |
|---|---|---|
| 複数ファイルにまたがるリファクタリング | 依存関係や呼び出し元の見落としを指摘しやすい | 変更対象ファイルだけでなく関連ファイルも差分確認する |
| 新機能の実装計画 | 実装前に設計の弱点を見つけやすい | 実装前に「Rubber duck your plan.」のように明示的に批評を求める |
| テスト追加・修正 | テスト観点の抜けや前提の誤りを検出しやすい | 正常系だけでなく異常系・境界値も確認する |
| 不具合修正 | 同じアプローチを繰り返す前に別視点を得られる | 修正後に/diffなどで人間が最終確認する |
| 本番影響が大きい変更 | 早い段階で設計ミスを止めやすい | PRレビューやCIを省略しない |
Rubber Duckは、計画後、複雑な実装の途中、テスト作成後、またはCopilotが行き詰まったときなど、高い効果が見込めるタイミングで使われると説明されています。小さく単純な変更では、通常はRubber Duckが使われない場合があります。(GitHub Docs)
実務では、Copilot CLIに大きな変更を頼む前に、次のようなプロンプトを挟むと効果的です。
まず実装計画を作成し、その計画をRubber Duckで批評してから修正してください。計画が出た後で明示的に依頼する場合は、次のように短くても十分です。
Rubber duck your plan.GitHub Docsでも、Rubber Duckは通常自動で呼ばれますが、自然言語プロンプトで明示的にセカンドオピニオンを求めることもできると案内されています。(GitHub Docs)
管理者が確認すべき影響範囲
今回のアップデートは、GitHub Copilot CLIを利用している組織に影響します。IDE上の通常のコード補完だけを使っているユーザーには、直接の作業変更は少ないと考えられます。
ただし、組織でCopilot CLIを許可している場合は、Rubber Duckの利用可否がモデル設定やCLIポリシーに左右される点に注意が必要です。GitHub Docsでは、Copilot CLIはエンタープライズまたは組織レベルで有効・無効を管理でき、ユーザーが利用できるAIモデルはエンタープライズで有効化されたモデルに限定されると説明されています。(GitHub Docs)
管理者は、次の項目を確認してください。
| 確認項目 | 見るべきポイント | 放置した場合のリスク |
|---|---|---|
| Copilot CLIの有効化 | EnterpriseまたはOrganizationでCopilot CLIが許可されているか | 開発者がCLIでRubber Duckを試せない |
| Copilotシート | 対象ユーザーにGitHub Copilotシートが割り当てられているか | 一部ユーザーだけ利用できず問い合わせが増える |
| モデルポリシー | GPT系・Claude系モデルの利用が許可されているか | Rubber Duckが期待通り別ファミリーの批評を使えない可能性がある |
| 実験機能の扱い | /experimental onを許可する運用にするか | チーム内で利用可否や手順がばらつく |
| 利用量・コスト | プレミアムリクエストの消費状況を監視するか | 大規模利用時に想定以上の利用量になる可能性がある |
| 開発ルール | AI出力のレビュー、CI、PR承認を維持するか | Rubber Duckを人間レビューの代替と誤解する |
Copilotのポリシーには、機能ポリシー、プライバシーポリシー、モデルポリシーがあり、モデルポリシーではCopilotで使える追加モデルの可用性を管理できます。(GitHub Docs)
また、Copilot CLIでは/modelコマンドで利用可能なモデルを確認・選択できます。コマンドリファレンスにも、/modelまたは/modelsでAIモデルを選択できること、/experimentalで実験機能を切り替えられることが記載されています。(GitHub Docs)
利用前に確認したい設定と手順
開発者がRubber Duckを試す場合は、次の流れで確認するとトラブルを減らせます。
| 手順 | 操作 | 確認内容 |
|---|---|---|
| Copilot CLIを起動 | copilot | CLIが正常に起動するか |
| 実験機能を有効化 | /experimental on | Rubber Duckを含む実験機能を使える状態か |
| モデルを確認 | /model | GPT系またはClaude系モデルを選べるか |
| 計画作成を依頼 | /planまたは自然文で依頼 | 実装前に方針を確認できるか |
| Rubber Duckを明示依頼 | Rubber duck your plan. | セカンドオピニオンが反映されるか |
| 差分確認 | /diff | 最終的な変更内容を人間が確認する |
特に初回導入時は、いきなり本番影響の大きいリポジトリで試すのではなく、小さな内部ツールや検証用ブランチで使い勝手を確認するのがおすすめです。Rubber Duckは品質向上に役立つ機能ですが、AIによる批評である以上、人間の設計判断やセキュリティレビュー、CI/CDの検証を置き換えるものではありません。
移行作業は必要か
今回の変更に対して、アプリケーションコード側の移行作業は基本的に不要です。変更対象はGitHub Copilot CLI内のRubber Duckのモデル対応範囲であり、既存のソースコードやGitHub Actionsワークフローを直接変更する必要があるアップデートではありません。
一方で、組織利用では「移行作業は不要」と「運用確認も不要」を混同しないことが重要です。特に、Copilot BusinessやCopilot Enterpriseでモデル利用を制御している場合、GPT系モデルとClaude系モデルのどちらかがポリシーで制限されていると、期待するクロスファミリーのレビュー体験にならない可能性があります。
管理者は、少なくとも次の3点を確認しておきましょう。
- Copilot CLIが対象組織で有効になっているか
- 対象ユーザーにCopilotシートが割り当てられているか
- Rubber Duckで使われる可能性のあるモデルがポリシー上利用可能か
GitHub Docsでは、Copilot CLIに影響する管理項目として、CLIの有効化、モデル選択、カスタムエージェント、MCPサーバーポリシー、監査ログ、シート割り当てなどが挙げられています。(GitHub Docs)
展開時に失敗しやすいポイント
Rubber Duckを組織に展開するときは、機能説明よりも「使いどころ」と「使ってはいけない理解」をセットで伝えることが大切です。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| Rubber Duckを万能レビューと誤解する | 人間レビューやCIを省略してしまう | 「第二意見であり最終承認ではない」と明文化する |
| 実験機能であることを伝えない | 仕様変更や挙動差に混乱する | チーム内の利用ルールに「experimental機能」と明記する |
| モデルポリシーを確認しない | 一部ユーザーだけ期待通り動かない | 管理画面でCLIとモデル設定を事前確認する |
| 大規模変更を一度に任せる | 差分が大きすぎてレビューしにくい | 設計、実装、テストを段階的に依頼する |
| コスト・利用量を見ない | 利用拡大後に請求や上限で慌てる | プレミアムリクエストの消費を定期的に確認する |
Copilot CLIでは、プロンプトごとにプレミアムリクエストが消費され、デフォルト以外のモデルではモデルのレートに応じて乗算されると説明されています。Rubber Duckの利用が常に個別の追加請求として明示されるとは限らないものの、追加の推論パスやモデル利用が発生するため、組織展開では利用量の監視をセットで考えるべきです。(GitHub Docs)
開発現場でのおすすめ運用
Rubber Duckは、毎回すべての作業で使うというより、失敗コストが高い作業で意図的に使うと効果を出しやすい機能です。
おすすめは、次のような運用です。
| 作業タイプ | Rubber Duckの使い方 | 人間側の確認 |
|---|---|---|
| 小さな修正 | 通常のCopilot CLI利用で十分 | 差分とテスト結果を確認 |
| 中規模の機能追加 | 実装前の計画をRubber Duckで批評 | 要件漏れ、API設計、例外処理を確認 |
| 大規模リファクタリング | 計画、途中差分、テスト後の3段階で批評 | 依存関係、互換性、ロールバック方法を確認 |
| セキュリティ影響のある変更 | Rubber Duckを補助的に利用 | セキュリティ担当または専門レビューを必須にする |
| 障害対応中の修正 | 原因分析や修正案の批評に使う | 本番反映前に最小差分と検証手順を確認 |
特に有効なのは、実装前の段階です。設計ミスは、コードを書いた後に直すよりも、計画段階で見つけた方がはるかに安く修正できます。GitHub Docsでも、Rubber Duckは非自明な変更の計画後、複雑な実装中、テスト作成後などに使われると説明されています。(GitHub Docs)
今回のアップデートで次に取るべき行動
開発者は、まずCopilot CLIで/experimental onを有効にし、普段使っているGPT系またはClaude系モデルのセッションでRubber Duckの挙動を確認しましょう。最初は、複数ファイルにまたがる軽めのリファクタリングやテスト追加で試すと、どのような指摘が出るか把握しやすくなります。
管理者は、Copilot CLIの有効化、モデルポリシー、シート割り当て、利用量監視の4点を確認してください。チームに展開する際は、「Rubber DuckはAIによる第二意見であり、人間レビューやCIを置き換えるものではない」と明確に伝えることが重要です。
今回の「Rubber Duck in GitHub Copilot CLI now supports more models」は、Copilot CLIをより実務的な開発支援ツールに近づけるアップデートです。複雑な変更ほど、最初の計画ミスが後工程に響きます。Rubber Duckを設計段階のレビュー役として組み込めば、Copilot CLIを単なるコード生成ではなく、実装前の判断品質を高める補助ツールとして活用しやすくなるでしょう。
コメント