GitHub Copilot CLI の外でもラバーダックしたくて、duck-critic という Agent Skill を作った話

Last updated at 2026-06-22Posted at 2026-06-21

こんにちは、AIエージェントに自分の書いたコードをレビューさせると「いいと思います！」しか言わせられず、なんだか出来レースだなと感じていたアーキテクトのやまぱん！です 😅
補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！

今回は、自作の Agent Skill duck-critic を紹介します。
ざっくり言うと「生成役の自分とは別のAIモデルに、節目ごとに批評させて、OK が出るまで直し続ける」ループを、SKILL.md 本体＋判断基準の参照ファイル群としてまとめた Skill パッケージです。

用語補足：Agent Skill とは、AI エージェントに「この種のタスクではこう動いて」という手順や判断基準を渡す、Markdown ベースの拡張のことです。SKILL.md に書いた内容を、エージェントが必要なときに読み込んで使います。

この記事は、以前書いた goal-loop（最後までやり切らせる Skill）の姉妹編です。goal-loop が「止まらず進める」側だとすると、duck-critic は「独りよがりに進めない」側、という関係になっています。

TL;DR

元ネタは GitHub Copilot CLI の公式機能 Rubber Duck。「セッションとは別のAIモデルが、読み取り専用で、レビューが効くタイミングにだけ批評してくれる」second opinion の仕組みです（GitHub Docs）
ただ、この「別モデルが自動で批評してくれる」体験を箱から出してすぐ使えるのは、調べた限り GitHub Copilot CLI だけでした。VS Code の agent mode も Claude Code も Codex も「自分で組めばできる」止まりです
そこで「他のハーネスでも同じ動きを持ち運びたい」と思って、producer-critic のループを Skill にしたのが duck-critic です
キモは「ラバーダックで実装して、を“サブエージェントに丸投げ”にしない」こと。生成は自分（メイン）が持ち続け、批評だけを別モデルに出します
おまけに、この Skill 自身でこの Skill の再設計をレビューさせたら、別モデルが本当に 2 件のバグを指摘してくれました。その実録も載せます

先に結論

私がこの Skill で言いたいことは 1 つです。

「レビューさせた」を自己満足で終わらせず、別の視点・別のモデルに・丸投げせずに当てよう。

自分が書いたものを自分で採点すると、どうしても甘くなります。これは人間もAIも同じで、後述するように「自己評価には自分びいきのバイアスがある」という研究もあります。
duck-critic は、そこを「別モデルの批評を、作業の節目に挟む」という仕組みで縛るための Skill です。

そもそも「ラバーダック」とは

ラバーダックデバッグ（rubber duck debugging） は、名著 The Pragmatic Programmer（Hunt & Thomas, 1999）の逸話が由来の古典的な手法です（Wikipedia）。
机の上のゴム製のアヒルに、コードの動きを 1 行ずつ声に出して説明していくと、その途中で「あれ、ここおかしくない？」と自分で気づく。アヒルは一言もしゃべりません。

GitHub Copilot CLI の Rubber Duck は、これを AI 文脈に持ち込んだ公式機能です。公式ドキュメントの表現が言い得て妙で、こう書かれています。

Unlike a real rubber duck, this one talks back.
（本物のアヒルと違って、こっちのアヒルは喋り返してくる）

要するに「黙って聞くアヒル」を「構造化された批評を返してくる別のAIモデル」に置き換えたわけです。公式ドキュメントから要点を拾うと、こういう設計になっています。

観点	Rubber Duck の挙動
批評役のモデル	セッションを動かしているのとは別のモデル（Claude で動かしていたら GPT 系、のように別ファミリー）
権限	読み取り専用。レビューはするが、ファイルは書き換えない
いつ呼ぶか	詰まったときだけでなく、計画後・実装中・テスト後・反復失敗時といった、レビューが効くタイミング
呼ぶ回数	固定ではなく判断ベース。誤字直しのように見ればすぐ正しいと分かる変更なら呼ばない（0 回）のも正常
返すもの	Blocking / Non-blocking / Suggestions に重大度分類した指摘

「別のモデルを使う」のがポイントで、公式も「同じモデルだと同じ盲点・同じバイアスを共有してしまうから」と説明しています。自分のミスは自分では見つけにくい、を回避するために、わざわざ別ファミリーに見せるわけですね。

でも、これが使えるのは GitHub Copilot CLI だけだった

このラバーダック、めちゃくちゃ良い体験なんですが、私が「他の環境でも使いたい」と思って調べたら、ここで詰まりました。

「別モデルの批評役を、自動で起動してくれる専用機能」を、インストールするだけで・箱から出してすぐ使えるのは、調べた限り GitHub Copilot CLI の Rubber Duck だけだったんです。

VS Code の agent mode にも、自分で書いて自分で直す自己修正ループ（テストが通るまで自律的に回る動き）はありますが、別モデルの批評役という概念ではありません。Claude Code は subagent で second opinion を組めるものの標準は Claude ファミリー内で、別ベンダーの批評は自分で用意する必要があります。OpenAI Codex も Skill や subagent でレビューを自作する世界です。どれも「カスタムエージェントやサブエージェントを使えば同じループは組める」のですが、その「組む」を毎回やるのは面倒です。

ここは 2026 年 6 月時点の調査です。VS Code も Claude Code も Codex も更新が速いので、将来「別モデル批評の組み込み」が入る可能性は十分あります。

だったら、「別モデルに節目で批評させて、OK まで回す」という段取りそのものを Skill に書いておけば、Copilot でも Claude Code でも Codex でも、同じ SKILL.md で近い動きを持ち運べるはずです。これが duck-critic を作った動機でした。

duck-critic の全体像：producer-critic ループ

duck-critic は、作業を「生成役（producer）」と「批評役（critic）」に分けて、節目ごとに交代させながら回します。
このパターンは、Anthropic が Building effective agents で evaluator-optimizer と呼んでいるものに近く、その批評役を「別モデルファミリー」にした版だと考えると分かりやすいです。

大事なのは、ループの主役はあくまで producer（自分） だということです。
批評役は「読むだけ」で、ファイルは触りません。指摘を受けて実際に直すのは、いつも生成役の自分です。ここが次に書く「丸投げにしない」に効いてきます。

なお図の「レビューが効く節目」というのは、そこで批評を挟むと効果が大きいタイミングのことです。具体的には「計画ができた直後（実装に入る前）」「重要な部分を実装した後」「テストを書いた後」「同じ失敗を繰り返したとき」あたり。逆に、誤字直しのように見ればすぐ正しいと分かる変更なら、わざわざ呼びません。

キモ①：「ラバーダックで実装して」を丸投げにしない

実はこの Skill、最初のバージョンは失敗作でした。「ラバーダックでレビューして」と言うと、作業まるごとを別のサブエージェントに丸投げして、その結果をそのまま採用する作りになっていて、これではただの委譲です。

本家の Rubber Duck は違います。メインの自分が手を動かし続けたまま、節目で「ここまでの成果」を別モデルに見せて、戻ってきた指摘を自分で取り込む形です。

なので duck-critic では、ルールとしてこう縛りました。

生成（plan / code / tests）は、メインの自分が最後まで保持する
批評役に渡すのは「レビュー」だけ。実装そのものを丸投げしない
批評役は読み取り専用。ファイルを書き換えさせない

「rubber duck で実装して」と言われたときに、実装を自分でやりつつ、節目で別モデルのチェックを挟む。この当たり前を、明文化して守らせるのが ① の役割です。

キモ②：多層の「止め方」

次に悩んだのが「いつループを止めるか」です。
批評役が毎回ちょっとずつ難癖をつけてくると、「直す→また指摘→また直す」で永遠に終わりません。かといって、1 回 OK が出たら即終了でも雑です。

そこで止め方を多層にしました。

加えて、3 ラウンド回しても収束しない場合は打ち切る、という安全弁（fail-safe）も入れています。
ここは誤解されたくないので補足すると、公式ドキュメントを読む限り、Rubber Duck に「何回まで」という固定回数は書かれていません。ドキュメント上は「節目で必要なら呼ぶ、小さい変更なら呼ばない」という判断ベースの説明です（内部の実装で上限があるかどうかまでは分かりません）。

duck-critic の「3 ラウンド上限」は、目標ではなく無限ループを止めるための保険です。普通はそれより手前で、Blocking が消えて残す注記もない状態（PASS）か、残る注記を明示的に受理した状態（PASS_WITH_NOTES）で止まります。

キモ③：別モデルが使えないときのフォールバック

本家の Rubber Duck は「メインが Claude か GPT のときだけ」使えます。じゃあ別ファミリーの批評役が用意できない環境ではどうするのか。ここを止まらずに段階的にフォールバックさせました。

優先度	批評役	報告での扱い
1	別ファミリー（明示指定 or 自動選択）	そのまま
2	同一ファミリーの別インスタンス	「同一ファミリーの批評」と明記する
3	セルフレビュー（自分で採点軸を当てる）	「独立した second opinion ではない」と明記する

ポイントは、批評の質が落ちたときに、それを正直に報告させることです。
「別モデルが取れなかったので同一モデルで見ました」と一言添えるかどうかで、その second opinion をどれくらい信用していいかが変わります。黙って格下げするのが一番まずい、と考えました。

設計の裏付け（参考にした文献）

「別モデルに批評させると良い」と言い切る前に、どこまでが裏付けのある話で、どこからが設計上の判断なのかを分けておきます。面白いのは、自己修正が効くかどうかは研究の間でも意見が割れているところです。

文献	何を言っているか	duck-critic への効き方
LLMs Cannot Self-Correct Reasoning Yet (arXiv:2310.01798)	外部フィードバック無しの自己修正は、推論でむしろ精度を下げうる（否定側）	だから外部の批評を入れる動機になる
Self-Refine (arXiv:2303.17651)	同一モデルの自己改善でも良くなるタスクはある（肯定側）	自己評価にも一定の価値はある（賛否両論）
LLM-as-a-Judge (arXiv:2306.05685)	LLM 評価は人間選好とよく一致するが、自分びいきのバイアス（self-enhancement bias）がある	別モデルに評価させる理由の傍証
Reflexion (arXiv:2303.11366)	言語的フィードバックを記憶に残して反復改善する	指摘を受けて直す→再レビューの反復の裏付け
Building effective agents（Anthropic）	evaluator-optimizer / parallelization などのパターン。明確な評価基準があるとループが効く	producer-critic の構造そのものの土台

調べた範囲では、「別モデルの批評は同一モデルより常に優れる」を直接証明した査読論文は見つかりませんでした。なので「別モデルを使う」根拠は、**学術的な傍証（自己評価バイアスや外部フィードバックの有効性）＋ GitHub の製品設計上の論拠（別モデルは盲点を共有しにくい）**の合わせ技だと整理しています。盛らずに書いておきます。

実際に使ってみた：この Skill 自身でこの Skill を批評させた

せっかくなので、duck-critic をこの Skill 自身の再設計に使ってみました。
構図はこうです。

producer（生成役）：私を動かしている Claude 系モデル
critic（批評役）：別ファミリーの GPT 系モデル（読み取り専用のサブエージェント）

結果、ちゃんとループが回りました。

ラウンド	批評役の判定	内容
Round 1	NEEDS_CHANGES	Blocking が 2 件。「PASS と PASS_WITH_NOTES の境界が曖昧で、注記が残ってても素通りできてしまう」「Claude 用の設定例が、批評役を同じファミリーにしてしまう書き方になっている」
（修正）	—	上の 2 件を producer（自分）が修正
Round 2	PASS	2 件とも解消を確認、新しい Blocking なし

Round 1 の 2 件はどちらも自分では気づきにくいやつでした。特に「設定例が批評役を同じファミリーにしてしまう」のは、別モデルで批評させるという Skill の根っこを自分で裏切っていたミスで、別モデルに見せたから見つかった、という納得感がありました。
少なくとも今回は、別の視点を入れたことで自分の見落としに気づけました。作者自身が一番それを実感した瞬間でした。

使い方

起動のトリガー

duck-critic は、次のような言い回しで呼び出すことを想定しています。

「duck-critic で」
「ラバーダックでレビューして」
「別モデルでレビューして」
「second opinion ちょうだい」
「この設計、批評して」

スラッシュコマンドでスキルを呼べるハーネス（GitHub Copilot など）では /duck-critic で起動するのが手早いです。対応していない環境では、上のキーワードで呼んでください。

導入

Agent-Skills リポジトリの duck-critic/ を、お使いのエージェントの Skill 置き場に配置すれば使えます。
SKILL.md 本体に加えて、references/ 配下に判断基準を分けて置いてあります。

loop-protocol：節目と停止条件（PASS / PASS_WITH_NOTES / 上限の保険）
harness-adapters：Copilot CLI / VS Code / Claude Code それぞれでの回し方
critic-packets：批評役に渡すプロンプトの型（初回用・再レビュー用）
reviewer-rubric：指摘の重大度分類
output-format：ラウンド数や批評役のモデル系を含む報告フォーマット
model-lanes：レビュー観点のレーンと、モデルが取れないときのフォールバック

Skill のインストール方法そのものは、お使いのエージェント（GitHub Copilot / Claude Code など）の Skill 読み込み仕様に従ってください。

おまけ：Agent Skills Ninja で入れると楽

「Skill 置き場ってどこ？」「複数のエージェントに同じスキルを配るの面倒」という人には、以前作った VS Code 拡張 Agent Skills Ninja がおすすめです。GitHub のスキルリポジトリから検索してワンクリックで導入したり、入れたスキルを AGENTS.md などのインストラクションファイルに自動で同期したりできます。詳しくは別記事 Skill を管理する "Agent Skill Ninja" を作ってみたにまとめています。

goal-loop との関係

この記事の冒頭でも触れましたが、duck-critic は goal-loop の姉妹 Skill です。
2 つは、エージェントの「進める力」と「正す力」を別々に担当しています。

Skill	役割	ひとことで
goal-loop	ゴールまで止まらず回す	「やり切る」
duck-critic	別モデルの批評で軌道を正す	「独りよがりにしない」

念のため goal-loop 単体も一言で説明すると、ゴールと完了条件を最初に固定し、テストやビルドの exit code のような外部シグナルの合否を一次情報にしながら、完了条件を全部満たすまで回す Skill です。「テストも回さず動くはずですと言い切る」みたいな自己申告の完了を防ぐのが狙いです。

こうして並べると、duck-critic は「別の目（別モデルの視点）」を足す Skill、goal-loop は「客観的な合否（外部シグナル）」を足す Skill、と棲み分けが見えてきます。どちらも「エージェントの気分任せにしない」という同じ動機から出発していて、片方はレビューのさせ方を、もう片方は止め方と進め方をルール化した兄弟、という関係です。

goal-loop のほうが気になった方は、姉妹記事 AIエージェントを「最後までやり切らせる」 goal-loop という Agent Skill を作った話もどうぞ。

おわりに

duck-critic は、「AIにレビューさせました」という一言を、ちゃんと意味のある second opinion にしたいという気持ちから生まれました。

レビューは別の視点・別のモデルに当てる
「ラバーダックで実装して」を丸投げにしない（生成は自分が持つ）
止め方を多層にして、無限ループも早すぎる完了も避ける
別モデルが使えないときは正直に格下げを報告する

「うちはこうやって別モデルレビューさせてるよ」みたいな話があれば、ぜひコメントで教えてください～！
最後まで読んでいただき、ありがとうございました！

参考リンク

Rubber Duck / ハーネス（公式）

設計の裏付け（論文・パターン）

ラバーダックの語源

Rubber duck debugging（Wikipedia）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up