「GPTとClaudeを同じパイプラインで動かせたら、精度が上がるんじゃないか？」
2026年3月30日、Microsoftがまさにその考えを製品として実装した。Copilot ResearcherのCritique機能は、OpenAIのGPTがリサーチをドラフトし、AnthropicのClaudeがそれを検証するという、競合モデル間の協調パイプラインだ。DRACOベンチマークで57.4点（競合ツール比+13.8%）を記録し、単一モデルを上回る精度を実証した。
この記事では、MicrosoftがCopilotで実現したCritique・Councilパターンを、開発者が自前のエージェントパイプラインで再現する方法を解説する。LiteLLMを使った実装コードと、よくある落とし穴を含めて紹介していく。
そもそもCopilot Critiqueとは何か
Critique機能はMicrosoft 365 Copilotの「Researcher」エージェントに組み込まれたマルチモデルパイプラインだ。仕組みはシンプルで、2つのステージに分かれている。
ステージ1では、OpenAIのGPTがクエリに対してプランニング・情報取得・ドラフト生成を担当する。ステージ2では、AnthropicのClaudeがそのドラフトを受け取り、ソースの信頼性・レポートの完全性・引用の正確性という3つの軸で構造化された検証を行う。
Critique以外にもCouncil機能がある。こちらは同じクエリを両モデルに並列で投げ、第三のジャッジモデルが合意点と相違点を整理して提示する形式だ。
| 機能 | 処理方式 | 用途 |
|---|---|---|
| Critique | 直列（GPT→Claude） | 精度重視のリサーチ検証 |
| Council | 並列（GPT+Claude→ジャッジ） | 多角的な視点を得たい場合 |
| Cowork | 並列タスク分担 | 複雑なドキュメント作成 |
開発者として注目すべきは、このパターンが汎用的だという点だ。MicrosoftはAzure AI Foundryを通じてこのマルチモデルオーケストレーション機能を提供しているが、LiteLLMを使えば同様のパターンをどんな環境でも実装できる。
LiteLLMでCritiqueパターンを実装する
LiteLLMは100以上のLLMプロバイダーへの統一インターフェースを提供するOSSライブラリだ。OpenAIとAnthropicの両方を同じAPIで呼び出せるため、Critiqueパターンの実装に最適な選択肢となる。
まずインストールと環境変数の設定を行う。
# インストール
pip install litellm
# 環境変数（.envファイルに設定すること。ハードコード禁止）
export OPENAI_API_KEY="sk-..."
export ANTHROPIC_API_KEY="sk-ant-..."次に、GPTでドラフト生成→Claudeで検証というCritiqueパターンの基本実装だ。
# critique_pipeline.py
# 動作環境: Python 3.11+, litellm>=1.30.0
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
import os
from litellm import completion
def critique_pipeline(query: str) -> dict:
"""
Stage 1: GPT-4oでドラフト生成
Stage 2: Claude Sonnet 5でファクト検証
"""
# Stage 1: GPT-4o がリサーチと下書きを担当
draft_response = completion(
model="openai/gpt-4o",
messages=[
{
"role": "system",
"content": (
"あなたは優れたリサーチャーです。"
"与えられたクエリに対して、詳細な調査結果を作成してください。"
"各主張には根拠となる情報源を明示してください。"
)
},
{"role": "user", "content": query}
],
max_tokens=2000,
temperature=0.3
)
draft = draft_response.choices[0].message.content
# Stage 2: Claude Sonnet 5 がドラフトを検証
critique_response = completion(
model="anthropic/claude-sonnet-5-20260203",
messages=[
{
"role": "system",
"content": (
"あなたは厳格なファクトチェッカーです。"
"提供されたレポートを以下の3つの軸で検証してください:n"
"1. ソースの信頼性（情報源は適切か）n"
"2. レポートの完全性（重要な観点が欠落していないか）n"
"3. 引用の正確性（主張と根拠が一致しているか）n"
"問題があれば指摘し、修正済みの最終版を出力してください。"
)
},
{
"role": "user",
"content": f"以下のドラフトを検証してください:nn{draft}"
}
],
max_tokens=2500,
temperature=0.1 # 検証タスクは低温度で安定させる
)
final = critique_response.choices[0].message.content
return {
"query": query,
"draft": draft,
"final": final,
"model_draft": "gpt-4o",
"model_critique": "claude-sonnet-5-20260203"
}
if __name__ == "__main__":
result = critique_pipeline("2026年の日本のAIエージェント市場動向を調べてください")
print(result["final"])ポイントは temperature の設定だ。ドラフト生成（Stage 1）はある程度の創造性が必要なので0.3前後、検証タスク（Stage 2）は一貫性が重要なので0.1以下に設定すると精度が安定する。
Councilパターン：並列実行でジャッジ統合
Councilパターンは2つのモデルを並列で実行し、第三のモデルが統合判断を下す方式だ。レスポンスタイムが重要な場面で特に有効で、直列のCritiqueパターンより処理時間を短縮できる。
# council_pipeline.py
# 動作環境: Python 3.11+, litellm>=1.30.0, asyncio
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
import asyncio
from litellm import acompletion # 非同期バージョン
async def council_pipeline(query: str) -> dict:
"""
GPTとClaudeを並列実行し、ジャッジモデルが統合
"""
# 2モデルを並列で実行（asyncio.gather で同時リクエスト）
gpt_task = acompletion(
model="openai/gpt-4o",
messages=[{"role": "user", "content": query}],
max_tokens=1500
)
claude_task = acompletion(
model="anthropic/claude-sonnet-5-20260203",
messages=[{"role": "user", "content": query}],
max_tokens=1500
)
gpt_resp, claude_resp = await asyncio.gather(gpt_task, claude_task)
gpt_answer = gpt_resp.choices[0].message.content
claude_answer = claude_resp.choices[0].message.content
# ジャッジモデル（GPT-4o-mini でコスト最適化）が統合
judge_response = await acompletion(
model="openai/gpt-4o-mini",
messages=[
{
"role": "system",
"content": "2つのAIの回答を比較し、合意点・相違点を整理した上で最終的な統合回答を提供してください。"
},
{
"role": "user",
"content": (
f"クエリ: {query}nn"
f"モデルA (GPT-4o) の回答:n{gpt_answer}nn"
f"モデルB (Claude Sonnet 5) の回答:n{claude_answer}"
)
}
],
max_tokens=2000
)
return {
"gpt_answer": gpt_answer,
"claude_answer": claude_answer,
"integrated": judge_response.choices[0].message.content
}
# 実行例
if __name__ == "__main__":
result = asyncio.run(council_pipeline("LangChainとLlamaIndexの違いを説明してください"))
print(result["integrated"])LiteLLM Routerによる本番運用設定
プロダクション環境では、フォールバック設定とコスト管理が不可欠だ。LiteLLMのRouter機能を使うと、モデルのロードバランシングと自動フォールバックを設定できる。
# router_config.py
# 動作環境: Python 3.11+, litellm>=1.30.0
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
from litellm import Router
# 複数デプロイメントの設定（フォールバックあり）
router = Router(
model_list=[
{
"model_name": "gpt-drafting",
"litellm_params": {
"model": "openai/gpt-4o",
"api_key": "os.environ/OPENAI_API_KEY",
}
},
{
"model_name": "gpt-drafting", # フォールバック: Azure OpenAI
"litellm_params": {
"model": "azure/gpt-4o",
"api_base": "os.environ/AZURE_OPENAI_ENDPOINT",
"api_key": "os.environ/AZURE_OPENAI_API_KEY",
}
},
{
"model_name": "claude-critique",
"litellm_params": {
"model": "anthropic/claude-sonnet-5-20260203",
"api_key": "os.environ/ANTHROPIC_API_KEY",
}
}
],
allowed_fails=2, # 2回失敗でデプロイメントをクールダウン
cooldown_time=60, # 60秒間クールダウン
routing_strategy="simple-shuffle"
)
def production_critique(query: str) -> str:
draft = router.completion(
model="gpt-drafting",
messages=[{"role": "user", "content": query}]
).choices[0].message.content
final = router.completion(
model="claude-critique",
messages=[
{"role": "system", "content": "以下のドラフトを検証し、改善してください。"},
{"role": "user", "content": draft}
]
).choices[0].message.content
return finalよくある失敗パターンと回避策
マルチモデルパイプラインを構築する際、陥りやすい失敗がいくつかある。
失敗1: Stage間でコンテキストを渡しすぎる
❌ ドラフト全体（2000トークン）をそのままCritiqueプロンプトに含める
⭕ 検証に必要な部分だけを抽出してCritiqueに渡す
ドラフトが長すぎると、ClaudeがコンテキストウィンドウのほとんどをGPTの出力に消費してしまい、検証の精度が落ちる。要約または分割して渡すこと。
失敗2: 両モデルに同じシステムプロンプトを使う
❌「優れたアシスタントとして答えてください」を両ステージで使う
⭕ Stage 1は生成特化、Stage 2は検証特化のプロンプトを用意する
各モデルの役割を明確に分離しないと、Critiqueが単なる言い換えになってしまう。
失敗3: コスト計算を無視する
❌ GPT-4o + Claude Sonnet 5をフルスペックで毎リクエスト使用
⭕ ジャッジにはGPT-4o-mini、フォールバックには軽量モデルを設定
2モデル直列はコストが2倍になる。ジャッジモデルに軽量モデルを使うだけで大幅なコスト削減が可能だ。
失敗4: APIレート制限を考慮しない
❌ 並列実行で大量リクエストを同時送信
⭕ asyncio.Semaphoreで同時実行数を制限する
# レート制限対策（同時実行数を5に制限）
semaphore = asyncio.Semaphore(5)
async def rate_limited_critique(query: str) -> str:
async with semaphore:
return await council_pipeline(query)開発者が今週やるべき3つのこと
MicrosoftのCritique/Councilパターンは、単一モデルの限界を超えるための実践的なアーキテクチャだ。自前の実装でも同じ成果を得るために、次のステップを踏んでいこう。
実は正直に言うと、マルチモデルパイプラインは「魔法の解決策」ではない。パイプラインが長くなるほど、レイテンシとコストが比例して増加する。最初は小規模なユースケースで検証し、効果が確認できてからスケールアップすることを強くすすめる。
参考・出典
- Introducing multi-model intelligence in Researcher — Microsoft Community Hub（参照日: 2026-04-09）
- GPT drafts, Claude critiques: Microsoft blends rival AI models — GeekWire（参照日: 2026-04-09）
- Router – Load Balancing — LiteLLM公式ドキュメント（参照日: 2026-04-09）
- BerriAI/litellm — GitHub（参照日: 2026-04-09）
まとめ：今日から始める3つのアクション
- 今日やること:
pip install litellmでCritiqueパターンの基本実装を試す（Stage 1: GPT-4o、Stage 2: Claude Sonnet 5） - 今週中: LiteLLM Routerでフォールバック設定を入れ、本番稼働に耐えられる構成にする
- 今月中: Councilパターン（並列+ジャッジ）を試し、ユースケースごとにどちらが合うか検証する
あわせて読みたい:
- AIエージェント構築完全ガイド — マルチエージェント設計の基礎から応用まで
- AIエージェント構築ツール徹底比較 — LangChain/Dify/n8nの使い分け
AIエージェントの設計・導入でお困りの方は、株式会社Uravationへお気軽にご相談ください。
この記事はAIgent Lab編集部がお届けしました。
