1つのLLMに聞き続けるのをやめて、Gemini・Claude・GPTを「討論・推敲・メタ認知」させるAgent Skillsを開発してみた

WRITER: 李俊浩
このエントリーをはてなブックマークに追加

はじめに

こんにちは。サイバーエージェント AIオペレーション室の李俊浩（@buddypia）です。

前回の記事『AI駆動開発のワークフロー設計』では、1体のエージェントを上流から下流まで走らせるワークフロー設計を紹介しました。

しかし、日常的にエージェントを活用する中で「1体のエージェント（単一のLLM）だけに聞き続けることの限界」を感じる場面が増えてきました。どれだけプロンプトを工夫して「もう一度よく考えて」「別の角度からレビューして」と頼んでも、同じモデルは同じ思考の癖を反響させるだけで、本質的な突破口が得られないケースがあるためです。

そこで今回、Gemini・Claude・GPT という異なる3大ベンダーのLLMを協調・対立・推敲させる 3つの Agent Skills を開発・公開しました。

この記事でわかること

  • どんな課題を解決するのか ── 単一モデルの盲点を「異なるベンダーのLLM」で相互チェックする理由
  • どのように振る舞うのか ── 討論（Debate）/ 推敲（Reflection）/ メタ認知（Recursive Meta-Cognition）の3つのパイプライン
  • どんな結果を出すのか ── 構造化された評決・改善稿・最終解のリアルな出力例
  • 導入手順と活用ケース ── npx skills add で既存のCLIエージェントに今すぐ組み込む方法

どんな課題を解決するのか

難しい判断に納得できず「もう一度、よく考えて」と 同じモデル に投げ直しても、返ってくるのは 同じ思考の癖でこねた別の言い回し です。自分の出力が入力に戻って反響し続ける ―― いわば 同じ考えが響き合うだけの閉じた部屋 で、視点は広がりません。

単一LLMの限界と複数モデル協調の対比

医療のセカンドオピニオンと同じで、大事なのは 「別の診断者」 に診てもらうことです。しかも、ただ同じモデルを何個も並べるのではなく あえて提供元（ベンダー）の違うモデル を混ぜます。同じデータで学んだモデルは、同じ間違いも共有する ため、同一モデルの多数決では全員が仲良く同じ盲点に落ちるだけだからです。ベンダーを変えれば、学習データも、安全性の調整のされ方も、推論の癖も違うので、それぞれの誤りが 「互いに独立した誤り」 になり、片方の盲点をもう片方が突けます。

この3スキルは、その「別ベンダーに検証させる」を 仕組み にしたものです。ざっくりの配役は次のとおりです。

ベンダー 使うCLI ざっくりの得意 主な配役
Gemini agy（Antigravity） 発想を広げる・網羅性・高速 分解 / 生成
Claude claude（Claude Code） 慎重な読み込み・リスク洗い出し 批評 / 検証
GPT codex（Codex CLI） 段階的推論・統合・厳密な整形 統合 / 熟考

3つのスキルと使い分け

3つのスキルは、同じ土台（ベンダーの違うCLIを subprocess で呼び出し、構造化JSONでやり取りする基盤）の上に、目的の異なる型 を載せたものです。まずは全体像と「どれを使うか」を掴んでください。

3つのmulti-llmスキルの俯瞰マップ

選び方は「答えの性質」で決めるのが一番シンプルです。

スキル使い分けのフローチャート

こんなとき 使うスキル 具体例
賛否が割れる判断をしたい debate 「AIを問い合わせ対応に導入すべきか？」「この技術選定は妥当か？」
成果物を磨きたい reflection 設計ドキュメント / 提案資料 / ブログ下書きの推敲
多段の難問を解きたい recursive-meta-cognition 「リリース6ヶ月前倒しのリスクと緩和策を段階的に洗い出す」

どれを使うか自体を迷うなら、multi-agent-orchestrator に丸投げすれば、討論・推敲・メタ認知のどれが効くかを判断して振り分けてくれます。

どのように振る舞い、どんな結果を出すのか

各役割は それぞれ独立した文脈 で動き、構造化JSONを出力し、次の段が前の段の出力だけを受け取って進みます。以下、1つずつ「振る舞い」と「出力」を見ていきます。

① multi-llm-debate（討論）

賛否が割れる 意思決定 に向いています。賛成 → 反対 → 中立評価の3つの役割が順番に討論します。

debateパイプライン: 賛成→反対→中立評価

「誰がどの役をやるか」は 既定では毎回入れ替え ます。「Gemini は常に賛成役」のように固定すると、ベンダー特有のクセ（偏り）がその役割に染み付いてしまうためです（--fixed で固定も可能）。

出力は、両者のスコア・論点・最終評決・推奨アクションを1つのJSONに集約した DebateResult です。

    {
      "final_verdict": "段階導入なら妥当。ただしSOC2対応を前提条件とすべき",
      "recommendation": "まずFAQ領域に限定してPoC。有人エスカレーションは必須で残す",
      "proponent_score": 7,
      "opponent_score": 6,
      "key_insights": ["初期は誤答リスクが高い領域を除外", "コスト削減効果は問い合わせ量に依存"],
      "degraded": false
    }

② multi-llm-reflection（推敲）

文章・設計案・分析ドキュメントなど、成果物をレビューで磨きたいとき に向いています。生成 → 批評 → 改善 の3段です。

reflectionループ: 生成→批評→改善

肝は、「書いた本人ではなく、別ベンダーが批評する」 こと。自分で書いたものを自分で直すと身内びいきが残りますが、別ベンダーの批評は本当に「外からの目」になります。出力は、批評を織り込んで書き直された 改善済みの最終稿 です。

③ multi-llm-recursive-meta-cognition（メタ認知）

一発では届かない 多段の難問 向けで、3つの中で最も重いスキルです。分解 → 解答 → 検証 → 統合 → 内省 の5段を走らせます。

recursive-meta-cognitionの5段階パイプライン

ポイントは、検証（Verify）で挙がった論点が統合・内省へフィードバックされる こと。「解いて終わり」ではなく「解いたものを疑い、疑いを踏まえて組み直す」メタ認知のループを1本に畳み込んでいます。出力は、検証を経た厳密な最終解 ＋ 内省メモ（限界・改善点）です。

5段すべてが推論の重いステージなので時間がかかります。重いスキルをエージェントから呼ぶときは background 実行 を推奨します。

インストールと使い方

スキルの追加は skills CLI で一発です（Claude Code / Codex / Cursor / Gemini CLI などで動作します）。

npx skills add buddypia/agent-skills

続いて multi-llm-* の土台となる 3つの公式CLIを入れてログインしておくだけ（command -v agy claude codex で確認）。Python の依存は各スキルの run.sh が自動で準備します。

# 土台のCLI（未導入なら）: agy は https://antigravity.google → agy install
    npm i -g @anthropic-ai/claude-code   # claude → ログイン（サブスク）
    npm i -g @openai/codex               # codex login（ChatGPT）

あとは、導入済みのエージェント（Claude Code など）に 自然文で頼むだけ です。スキルの説明文にマッチして自動で発火し、内部で3つのCLIを順に呼びます。

クイックスタートの3ステップ

# Claude Code などのエージェントに、こう頼む
multi-llm-debate で「AIを問い合わせ対応に導入すべきか？」を検討して。
[前提] B2B SaaS / 月間3,000件 / 年間予算500万円 / SOC2準拠が必須

スクリプトを直接叩きたいときは <skill-dir>/scripts/run.sh "…" も使えます（--verbose で各段の詳細、--json でJSON出力）。

設計上の工夫（要点だけ）

「概念」より、毎回・壊れずに走らせる 作り込みに差が出ます。詳細はリポジトリに譲り、要点だけ挙げます。

  • 重いSDKを捨て、CLIを subprocess で叩く ── ベンダーSDKはOS固有バイナリを数百MB同梱し配布不能だったため、導入済みCLIを直接呼ぶ軽量方式に統一。長文入力は stdin 経由、各CLIは tempdir を作業ディレクトリにして純粋生成だけをさせる。
  • 3者バラバラの出力を同じ Pydantic 型に正規化 ── claude は --json-schema、codex は --output-schema、agy はプロンプト指示＋Pydantic検証。作法は違っても段間I/Oは型安全。
  • Gemini は OAuth を最優先 ── 環境に残った GEMINI_API_KEY に OAuth セッションを横取りさせない。API キーは agy が使えないときの代替手段に限定。
  • 締切を伝播させ、殺される前に着地 ── エージェント/Bashの約600秒上限の前に部分結果を返す（degraded フラグで明示）。速度は MULTILLM_REASONING_EFFORT を下げて調整（CLI_TIMEOUT をむやみに上げない）。
  • タイムアウト時はプロセス「ツリー」ごと停止 ── CLIが産む node/bun の孫を孤児化させないよう、グループ単位で SIGTERM → 猶予 → SIGKILL。

まとめ

  • ベンダーの違うモデルで「独立した誤り」を作る ── 同一モデルの多数決は同じ盲点を共有する。Gemini / Claude / GPT を混ぜて初めて相互チェックが効く。
  • 目的で3つの型を使い分ける ── 割れる判断は debate、推敲は reflection、多段の難問は recursive-meta-cognition。迷ったら orchestrator に任せる。
  • サブスクCLIで今すぐ試せる ── APIキー不要・重いSDK不要。npx skills add して、エージェントに頼むだけ。

「1つのモデルに聞き続ける」から「別ベンダーに検証させる」へ。まずは手元の悩ましい意思決定を multi-llm-debate に1回投げてみてください。返ってくる「反対役」の指摘が、思いのほか効きます。

免責・注意

  • 本プロジェクトは、ユーザー自身が導入した公式CLI（agy / claude / codex）を 順に呼び出して組み合わせるだけ で、認証や課金を回避しません。各プロバイダ/CLIの規約遵守は利用者の責任です。
  • 既定のモデルID（gemini-3.5-flash / claude-sonnet-5 / gpt-5.5 など）は2026年6月時点のもので、--*-model で上書きできます。
  • マルチモデル化は視点を増やすための設計上の選択であり、結果の品質を保証しません。出力は信頼できないものとして扱い、プロンプトインジェクションにも留意してください。> 本スキルの設計は、Multi-Agent Debate（Du+ 2023 ほか）、Self-Refine（Madaan+ 2023）、Reflexion（Shinn+ 2023）、Least-to-Most（Zhou+ 2023）などの公開研究のアイデアから着想を得た独自実装です。
要件策定から本番環境への展開までの完全自動化を目指して96プロダクトのAI活用力を強化した話｜プロダクトのキーパーソン向け施策『AIナレッジ共有会』
次の記事