Multi LLM Review

multi-llm-review

概要

レビュー対象（設計/コード/文章）を複数の異なるLLMに並列独立レビューさせ、ホストLLM（現在動いているLLM）が当初目的を唯一の基準に取捨選択して元案へ統合し、よりよい改訂案を作る。

核心価値: モデル多様性。既存の doubt-driven-development（同LLM adversarial）/ sentaku L3（同LLM弁証）/ superpowers:dispatching-parallel-agents（同LLM並列）は全て context 多様性（同一LLM内での視点切り替え）。本スキルは 異なるLLMの死角を補完する ことで直交する価値を提供する（直交＝観点パックは共通でも、異なるLLMが独立に発見する指摘の非重複度。3ラウンド実例で両LLMが同じ致命点を独立指摘した際に価値が実証される）。

トリガーワード（自然言語・スラッシュコマンド両方可）

• 「マルチLLMレビューして」「複数LLMでレビュー」「各LLMにレビューして」「各LLMでレビューして」
• 「3つのLLMで」「3機でしっかり」「しっかりレビューして」→ triple モード（3機・後述）
• 「panel review」「jury review」「クロスLLMレビュー」
• /multi-llm-review / /multi-llm-review --triple

lite（multi-llm-review-lite）との切り分け（鉄則）: 「軽く」「サクッと」が入ったら lite（箇条書きツッコミ・改訂案なし）。「改訂案が欲しい」「しっかり」「3機で」は本スキル（normal）。曖昧なら確認。

既存スキルとの棲み分け（機械的振り分け表）

曖昧な場合はユーザーに確認する。

環境前提（2層・ホスト以外の利用可能LLM全部を自動呼出）

• ホスト自身はレビュアーに含めない（自己レビューは多様性ゼロ）
• ホスト以外の利用可能LLM全部を自動呼出（利用不能LLMは discover で検知してスキップ）
• triple 時の OpenRouter 機選定: purpose 別（code=cohere/north-mini-code:free / design=openai/gpt-oss-20b:free / general=nvidia/nemotron-3-super-120b-a12b:free・liteと共通）。退役時は /api/v1/models で最新 slug 確認

🔐 機密情報の取り扱い（必須・冒頭確認）

レビュー対象がコード・社内文章・シークレット含む設計の場合、外部LLM送信のリスクがある。フロー開始前にユーザーへ「対象に機密が含まれるか」を必ず確認する:

• 機密フラグ ON: 外部LLM送信前にリスク警告→必要なら対象をマスク/要約して送信、または限定モデルのみ使用（ホスト=ローカル等）
• CLAUDE.md セキュリティルール（APIキー値の送信禁止等）に準拠。~/.secrets.env の値は絶対にレビュアープロンプトに含めない

全体フロー

1. ユーザー: トリガー + 対象（設計/コード/文章）+ 目的/観点
2. ホスト: 機密確認 → プロンプト組み立て（slot）
3. discover / health check: 各LLMの呼出可能性確認・失敗LLMはスキップ
4. ホスト: レビュアーLLMを並列独立呼出（2段階ファイル経由）
5. 各レビュー収集（JSON抽出＝必須前提）
6. 統合ロジック（8ステップ・Step6 が pre-flight 中断フェーズ）
7. 出力: 改訂案 + review_log.md

実行メカニズム:

• 並列・独立: 各LLMに互いの結果を見せず同一プロンプト（先入観なし・anchoring bias 回避）
• 1ラウンド固定: 反復は廃止（深さが必要なら sentaku L3 / doubt-driven へ誘導）
• 当初目的ホールド: 各統合ステップのプロンプト先頭に目的文を再注入（機械的ホールド）

discover / health check（スキル冒頭で実行）

各LLMの呼出可能性を実行時検知する:

縮退判定: 呼出成功LLM数 M ≥ 2 で続行。M < 2 は中止（多様性が保証できないため）。

外部LLM呼出手段（経路分岐表）

実装手順（Claude Code環境・2段階ファイル経由・必須）

直接 curl はクォート/改行エスケープが破綻するため、2段階ファイル経由を標準手順とする:

1. 各LLMのAPIリクエストJSONペイロードを一時ファイルに書出（Write ツール or python3）:
   • /tmp/req_gemini.json（Windows Desktop は環境に応じた一時パス）
   • triple時: /tmp/req_or.json（OpenRouter用）も生成
2. 並列送信（同一メッセージでツール呼出・triple時は3ツール同時）:
   • MiniMax: mcp__minimax__minimax_ask（prompt に同一プロンプトを指定）
   • Gemini: Bash で curl -s -H "Content-Type: application/json" -d @/tmp/req_gemini.json "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.1-pro-preview:generateContent?key=$GEMINI_API_KEY"
   • OpenRouter（triple時のみ）: Bash で set -a; source ~/.secrets.env 2>/dev/null; set +a; curl -s --max-time 90 https://openrouter.ai/api/v1/chat/completions -H "Authorization: Bearer $OPENROUTER_API_KEY" -H "Content-Type: application/json" -d @/tmp/req_or.json（プロンプトはPROMPT環境変数経由でpython3に渡してペイロード生成・liteと同一手順）
3. JSON抽出: 結果から文字種ステートマシンでJSON配列を再構成（下記「JSON抽出」参照）

python3 でペイロード生成する例: python3 -c "import json; open('/tmp/req_gemini.json','w').write(json.dumps({'contents':[{'parts':[{'text':PROMPT}]}],'generationConfig':{'temperature':0.4,'maxOutputTokens':8000}},ensure_ascii=False))"

Gemini 空応答時のリトライ（思考モデルの罠・2026-07-05 実証）

Gemini 思考モデル（2.5 Pro / 3.1 Pro 等）は maxOutputTokens=8000 設定でも、長大コード＋長focus の組合せで思考トークンが枠を消費して空応答を返すことがある（finishReason: MAX_TOKENS・本文空）。

検知: レスポンス本文が空、または candidates[0].content.parts[0].text が空文字列。

対策（空応答時のリトライ戦略・順に実施）:

1. focus 短縮: "all" / "readability" → "bug" 等の1観点1単語に短縮（思考負荷を下げる）
2. コード圧縮: コメント・docstring・空行を削除し核心ロジック・差分のみに圧縮（入力トークン削減で思考の余裕生成）
3. 再送信: 上記2点を適用した圧縮ペイロードで再実行

実証例（2026-07-05・daily_triage.py レビュー）:

• 1回目（focus=readability・コード全文）: 空応答
• 2回目（focus=bug・コード圧縮・背景1行追加）: 具体的指摘2件（状態列動的特定・ヘルパー化）を獲得

MCP直接呼出 mcp__gemini__review_with_gemini は maxOutputTokens 指定不可（スキル外で直接呼ぶ場合）で特に空応答しやすい。multi-llm-review スキル経由の curl REST（8000指定）でも長大コードでは発生するため、本リトリア戦略を標準手順に組み込む。

レビュアープロンプト雛形（全LLM共通・slot化・順序固定）

ホストは以下テンプレの {...} を埋めて、全レビュアーに同一プロンプトを送る（先入観なし・同条件）:

[ロール] あなたは {security reviewer / consistency reviewer / simplicity advocate / ...} です。
[目的] 以下の元案が「当初目的: {目的}」を達成するか、観点「{観点}」でレビューしてください。

[元案]
{対象}

[出力形式] JSON配列のみで返答してください（挨拶・markdownコードブロック不要）:
[{"issue": "...", "severity": "critical/high/med/low", "quote": "元案からのコピペ抜粋", "suggestion": "改善案"}]
※ quote 内の `}` は必ずエスケープすること（例: `}` → `\}`）。文字種ステートマシンで解析するため壊れます。
※ 目的外でも致命的欠陥があれば含めてください（メタ指摘歓迎）。
※ 【サボりバイアス防止・必須（2026-07-25 C″追加）】"作らない/省略/後回し/既存で足りる/実装不要"方向の指摘をする場合、以下3点を**必ず出力に言語化**すること（"自問せよ"でなく出力義務・内部処理に埋没すると効果薄い）:
    (1) 省略した場合のデメリット・事故リスクを最低1つ明示
    (2) 既存ファイル/既存実装以外の代替シナリオを検討したか明示
    (3) "新規〇〇発生ゼロ/検証済"等の根拠が**測定方法のアーティファクト**（測定範囲の偏り・未検証シナリオ）でないことの証明
   ※ 検証範囲の偏りに依存する"作らない"推奨は**LLM集団サボりバイアス（実装コスト回避）**の典型（2026-07-25 承認スキーマPhase2事象で実証）。
※ 【サボりバイアス防止・Phase0拡張（2026-07-26）】省略方向だけでなく**全レビュー共通**で以下も出力義務（個別LLMの単独サボりも形式で捕捉・ホスト単独レビューでも有効）:
    (4) **反証シナリオ1つ**: 元案を支える前提が崩れるケース（確証バイアス対策）
    (5) **最悪ケース1つ**: "問題ない"とする場合の最悪の影響（楽観バイアス対策）
   ※ 詳細: `@rules/_shared/LLMサボりバイアス防止.md`（13類型カタログ）

デフォルト観点パック（観点未指定時・全採用／指定時は指定観点のみ）

[ロール] の例: security reviewer / consistency reviewer / simplicity advocate / performance reviewer / clarity reviewer

JSON抽出（文字種ステートマシン・必須前提）

前処理: 各LLM応答から本文を抽出（必須・2026-07-28追記）

curl/MCP の生レスポンスは API用JSONで包まれている（Gemini/OpenRouter）。文字種ステートマシンに渡す 前 に、各LLMの応答構造から本文（レビューJSON配列が入った text/content）を抽出すること。生レスポンスをそのまま食わせると外側JSONの [ ] に誤ヒットして 指摘が1件しか取れない事故 が起きる（2026-07-28 実証: Gemini 5件中1件のみ抽出 → 本文抽出後5件全取得）。

抽出例（python3）:

import json
resp = json.load(open('/tmp/res_gemini.txt'))
text = resp['candidates'][0]['content']['parts'][0]['text']
open('/tmp/gemini_text.txt','w').write(text)
# → /tmp/gemini_text.txt を extract.py の stdin に渡す

※ lite スキルの OpenRouter 実装（d['choices'][0]['message']['content']）と同じ前処理。本スキルにも明示化（2026-07-28・これまで抜けていた）。 ※ 「封筒（API用JSON）に入った届く」→「封筒を開けて中身（本文）を取り出す」→「本文からJSON配列を抽出（文字種ステートマシン）」の3ステップ。

LLMにはJSON配列のみを返すよう指示するが、markdownブロックや挨拶文を混入する。本文抽出後のテキストから 文字種ステートマシン でJSON配列を抽出する:

• 文字列リテラル（" で囲まれた範囲）内の } は無視して split する（{"quote":"if(x){}"} 破綻回避）
• 抽出した要素のうち 必須key（issue/severity/quote/suggestion）が全て揃った指摘が ≥50% なら成功・未満ならテキスト扱いで統合（Step1の閾値）

python3 抽出実装例（スクリプトを /tmp/extract.py に保存し python3 /tmp/extract.py < /tmp/res_<llm>.txt でパイプ入力・結果をファイルへもリダイレクト可能）:

import json, sys

def extract_issues(text):
    """文字種ステートマシン: [ と ] の中身だけ走査し、
    文字列リテラル内の } を無視して各 {...} オブジェクトを切り出す。"""
    s, e = text.find('['), text.rfind(']')
    if s == -1 or e == -1 or e < s:
        return []
    body = text[s+1:e]  # 外括弧 [ ] は除外（中身のみ）
    items, buf, in_str, esc = [], '', False, False
    depth = 0
    for ch in body:
        if esc:                       # 直前が \（文字列内のエスケープ）
            esc = False
            if depth > 0: buf += ch
            continue
        if ch == '':
            esc = True
            if depth > 0: buf += ch
            continue
        if ch == '"':
            in_str = not in_str
            if depth > 0: buf += ch
            continue
        if in_str:                    # 文字列内は } { を無視
            if depth > 0: buf += ch
            continue
        # 以下 in_str == False
        if ch == '{':
            if depth == 0:
                buf = '{'             # 新オブジェクト開始（手前の [,カンマ,空白は捨てる）
            else:
                buf += ch
            depth += 1
        elif ch == '}':
            depth -= 1
            buf += ch
            if depth == 0:
                try:
                    items.append(json.loads(buf.strip()))
                except Exception:
                    pass
                buf = ''
        else:
            if depth > 0: buf += ch
    return items

text = sys.stdin.read()
res = extract_issues(text)
print(json.dumps(res, ensure_ascii=False, indent=2))

severity 正規化マップ

各LLMの severity を {critical, high, med, low} に正規化する:

統合ロジック（ホストLLM・8ステップ・Step6が中断フェーズ・当初目的ホールド）

各ステップのプロンプト先頭に「当初目的: {目的}」を再注入する（機械的ホールド）。

1. JSON抽出（上記・文字種ステートマシン）
2. severity 正規化: 上記マップで各指摘を {critical, high, med, low} に正規化
3. Fact Check: 各指摘の quote が元案に部分一致するか（トークン Jaccard ≥ 0.7・正規化後）→ 不存在は即却下（ハルシネーション除外）
   • ※要約渡し時（対象サイズ大）は Fact Check をスキップ（要約ベースでは quote が元案と一致せず全却下される矛盾を回避）。判定基準: ホストが Step2 のプロンプト組み立て時に「全文渡し or 要約渡し」のフラグを保持し、要約渡し時は本ステップをスキップ（コスト・レート制限の要約渡しとも整合）
4. ペルソナ切替（著者バイアス対策・ホストの認知ステップ）: 「あなたは元案の作者ではない。冷徹な品質管理責任者として外部指摘を客観的に裁定せよ」＋盲点カタログ（著者が見落としがちな観点を列挙）＋devil's advocate（自分がこの指摘を出した側ならどう反論するか）。※これは統合側のホスト認知であり、追加のLLM呼出は行わない（独立性命題を維持。Step4でレビューアーを再呼びしない）
5. 当初目的 3tier 分類:
   • 直接（目的関連）→ 採否判断（必須）
   • メタ（目的自体への疑義・致命的欠陥）→ Step 6 でユーザー確認
   • 完全目的外 → 切る（理由1行記載）
6. 【pre-flight・中断フェーズ】 メタ指摘があれば統合前にユーザー確認:
   • JSONは保持・LLMセッション有効期間内のみ再開（再呼出＝コスト2倍を回避）
   • メタ却下後は当初目的維持・tier判定は変更なし（暴走防止）
   • メタ指摘がなければ Step 7 へ直行
7. 競合調停: 相反指摘（A「削除」vs B「詳細化」等）は当初目的基準でトレードオフ評価・採用理由を明記
8. 統合: 採用指摘を元案の構造を保持し指摘箇所のみ置換/追記→改訂案。末尾に「却下サマリ（リスト・各1行理由）」＋「当初目的: X / 改訂案が満たす根拠: Y」を強制記載

※Step6（pre-flight）は統合内の中断フェーズ。メタ指摘がなければ Step5 → Step7 へ直行する（spec v3 整合）。

Step 6.5: 集団サボりバイアス検知（機械的・2026-07-25 C″追加）

複数レビュアーが「作らない/省略/後回し/既存で足りる/実装不要」方向に一致した場合、**LLM集団サボりバイアス（実装コスト回避）**の疑義を検知する。

判定条件（両方満たす・ホストは"サボりか否か"の判断を生成せず機械的に適用）:

1. 方向一致: 複数レビュアー（≥2機、または全機）が省略方向の推奨で一致
2. 根拠の構造的条件: 推奨の根拠が「新規X発生ゼロ/検証済/既存でカバー」等の測定結果に依存している（単なる方向一致では誤検知・M1指摘）

成立時のアクション（ホストは判断を生成せず機械的に実行・G1+M6指摘）:

• 反証シナリオ生成: 「この『ゼロ/十分』は測定範囲の偏り（未検証シナリオ）のアーティファクトでないか？」→ 未検証シナリオを1つ明示生成（M3指摘・ユーザー丸投げ回避）
• 行動可能警告を付与: 改訂案/review_log の冒頭に以下を機械挿入（G3+M4指摘・術語は内部ログ）:

  ⚠️ 集団サボりバイアス疑義: 両レビュアーが省略（実装不要）推奨で一致。この結論が特定の検証条件（例: 既存データの再利用のみ）に依存したアーティファクトでないか、未検証シナリオ「<生成した反証>」をユーザーが再確認推奨。

設計根拠（Bの完全却下を訂正・M6指摘）: ホストもLLMで盲点共有リスクがあるため、ホストに「サボりかどうか」の判断を委ねず条件成立→機械的にフラグ+反証生成。これでホストの判断バイアスを排除しつつ、ユーザーへの行動可能な警告を実現する。

scope（M5指摘・MVP明記）: 本ステップは「省略方向のサボり」限定。過剰同意バイアス・権威バイアス・均質化バイアス等の他の集団バイアスは将来拡張ロードマップ。

出力（2ファイル・デフォルトパス）

• 報告時の平易な解説併記（必須）: 統合結果をユーザーに提示する時は、専門説明の後に素人にもわかる一言（💡一言でいうと）を必ず併記する（CLAUDE.md平易解説ルール）
• デフォルト出力先: ./multi-llm-review_<timestamp>/
• 改訂案（revised_proposal.md）: 本文（元案構造保持）＋却下サマリ＋「根拠 Y」。Step6.5成立時は冒頭に集団サボりバイアス疑義の行動可能警告（反証シナリオ+再確認推奨）を機械挿入
• review_log.md: 全指摘の {LLM, issue, severity(正規化), quote, decision(採用/却下/保留), reason}（重要度順・上位Nを本体・残りは折りたたみ/参照リンク）。decision 行のフォーマット例: decision: 採用 / reason: [当初目的:X]の要件R3を満たすため・quote Yが該当（判断が目的から演繹であることを追跡可能に・spec尊重却下も理由1行で明記）

実測証跡と計測frontmatter（2026-08-17追加・判断収束ループ計測用）

revised_proposal.md には frontmatter で以下の3数値を記載する（判断収束ループ「3回計測」の自動蓄積・レビュー経緯は 00_SYSTEM/マルチLLMレビュー/2026-08-17_判断収束ループ計測自動化-設計レビュー/revised_proposal.md）:

findings_total: <指摘総数>
converted_to_cmd: <検証コマンドに変換できた数>
overturned_by_measurement: <実測で覆した数>

• 「実測で覆した」の定義（境界3規則つき）: LLMの指摘・主張が検証コマンド（grep/wc/curl/gh等）の実行結果と矛盾し、採用撤回・却下・設計変更に至った件。(a) 部分覆は二値丸め（0.5件扱いなし）(b) 表記修正レベルは除外（構造・事実判断のみ）(c) コマンド実行失敗（エラー）は不採用 (d) 文言裁定・合議のみは不可算
• 「## 実測証跡」セクション必須: 覆した件ごとに ### 証跡N（検証コマンド1行+出力抜粋）を列記。frontmatter の overturned_by_measurement はこの項目数と一致させること（grep -c '^### 証跡' で機械検証）→ LLMによる数値の盛り・架空証跡を機械的に封じる
• 引用制約: 実行していないコマンド・ユーザーが提供していない実行結果の引用は禁止

コスト・レート制限

• 各LLMの RPM/TPM 制限を考慮。3並列で制限抵触時（HTTP 429 受信等）は順次化または2モデルに縮退
• 対象サイズが大きい場合は要約を渡す（元案全文でなく観点に関連する部分）→ 要約時は Fact Check スキップ（Step3 参照）

WSL（GLMホスト時）の統合スキップ

• 指摘件数 > 50 または 統合入力 > 100K トークン（推定） の場合、「統合スキップ・並列出力を束ねるだけ」をユーザーに提案（統合負荷がホストに集中するため）
• review_log.md は LLM別グルーピングで出力

impact モード（影響範囲分析）

自動起動はしない（手動発動・例外: 静的危険操作カタログ一致時のみ層aが限定自動発動を推奨）。 LLMの「想像力の欠如」（変更の副作用を未来投影で想像できない）を、複数LLMペルソナで補完する。

トリガー

• 「impact」「影響範囲分析」「未来の副作用」「取りこぼしチェック」

層a（自動・PostToolUse）

• git diff --unified=0 走査 → trigger_keywords 正規化マッチ → category enum 判定
• additionalContext に 3択（「起動 / 無視 / 何もしない」）を軽量注入
• 検知失敗は silent skip + 検知失敗カウンタ（spec §5.1）

層b（手動発動・本モードの本体）

• 入力: 変更内容（git diff）+ antipatterns.md 抜粋 + dangerous-ops 一致情報
• ペルソナ分割（spec §3.2）: 2機時 = P1+P2 / triple時 = P1+P2+P3
  • P1 ドメイン専門家 / P2 破壊的変更検知 / P3 時系列変化
• 暫定コスト上限: P1=8k/30s/$0.10・P2=6k/20s/$0.08・P3=4k/15s/$0.05・合算$0.30/60s
• Future Logic Check（再設計）: シナリオ現実性を相互検証（正典照合でなく）
• 統合: 指摘LLM数 × severity マトリクスで並び替え

静的危険操作カタログ（M7=A'）

• ファイル変更で副作用が起きる系のみ（DBマイグレーション/本番シークレット変更/BLACKLIST追加/閾値変更/権限スコープ）
• 一致時: 層aが「限定自動発動候補」を追加注入
• コマンド実行系（git push --force等）は Phase2 送り

ゴールデンセット（精度評価用）

• #7 BLACKLIST副作用 / #8 キーワードトリガー早合点 / #9 未来シナリオ想像の欠如
• 想定2件（実装時に合成データ追加）

既存 multi-llm-review との関係

• 層bは既存の「8ステップ統合ロジック」（§266 以降）を再利用して impact モードで起動
• ペルソナ以外の Step1〜8 は変更なし（破壊的変更は最小化）
• 既存 opt-out フラグ --no-impact で layer-b 影響を回避可能

詳細参照

• spec: docs/superpowers/specs/2026-07-30-multi-llm-review-impact-mode-design.md v0.2
• antipatterns: 00_SYSTEM/impact-antipatterns.md
• dangerous-ops: 00_SYSTEM/dangerous-ops.yaml

YAGNI（切り捨て）

• 反復ラウンド（1ラウンド固定）・第4のパーティ判定役・採用率の数値ルール・自動LLM選択（利用可能LLM全部を呼ぶ）・自発発動（手動のみ）