Code Review Council

概述

Code Review Council は、多角的な役割を持つレビューフレームワークです。コードの問題に直面した際、単一の Claude がすべてのステップを順番に完了するのではなく、5つの独立した視点を持つ「委員」を招集し、並行して作業を進めます。最終的に、レビュー担当者がすべての結論を相互検証し、総合的な報告書を出力します。

核心的価値：シングルスレッド分析における「確証バイアス」——最初に解決策を見つけると、その判断に固執する傾向を打破します。

五名の委員の役割

1. Explorer（探索者）

責務：幅優先で、現状を記述し、解決策を提案しない。

• コードベースの構造、モジュール境界、ファイル構成を整理する
• 重要な呼び出しチェーンとデータフローを追跡する
• エントリポイント、副作用、外部依存関係をマークする
• 出力：コードマップ + 重要なパスのリスト

制約：Explorer は「何であるか」のみを記述し、「どうすべきか」を述べることは禁止されています。

2. Analyst（分析者）

責務：問題の根本原因を深く掘り下げ、Explorer とは独立して結論を導き出す。

• パフォーマンスボトルネックを分析する（時間計算量、メモリ、IO）
• 潜在的な bug、境界条件、競合状態を識別する
• 技術的負債とリスクポイントを評価する
• 出力：問題リスト（重大度順）+ 根本原因分析

制約：Analyst は根本原因を必ず提示する必要があり、「X が原因である可能性がある」のような曖昧な結論は認められません。

3. Architect（方案者）

責務：独立して 2〜3 個の実装案を提案し、各案のトレードオフを明確にする。

• 各案には以下を含める必要がある：コアとなるアイデア、実装の複雑さ、パフォーマンス特性、保守性
• 案の前提となる仮定を明記する
• 推奨案とその理由を示す
• 出力：案の比較表 + 推奨案の疑似コードまたは重要な実装スニペット

制約：Architect は 1 つの案のみを提示することはできず、少なくとも 2 つの異なる経路を網羅する必要があります。

4. Librarian（ライブラリ研究員）

責務：タスクに関連するオープンソースライブラリを調査し、実際の可用性を検証する。

• ライブラリの現在のバージョン、メンテナンス状況（アクティブかどうか）を確認する
• 重要な API の実際の使用法を検証する（記憶に頼らず、ドキュメントに基づく）
• 既知の落とし穴、breaking change、バージョン互換性の問題をリストアップする
• 同種のライブラリの長所と短所を比較する
• 出力：ライブラリ選定の推奨事項 + 重要な API のサンプルコード

制約：Librarian は「確認済みの」情報と「印象に残っている」情報を区別する必要があり、混同してはなりません。

5. Critic（審査者）⚡

責務：他の 4 人の委員の結論を横断的に審査し、矛盾、遺漏、誤った仮定を見つける。これは最後に発言する役割です。

• Explorer のコードマップが重要なパスを遺漏していないか検証する
• Analyst の根本原因が本当に根本原因であるか挑戦する
• Architect の案に暗黙の仮定が成立するかどうか疑問を呈する
• Librarian が推奨するライブラリが現在のシナリオに本当に適用可能か確認する
• 出力：審査意見リスト + 最終的な総合的アドバイス

制約：Critic は、他の委員の問題点または遺漏を少なくとも 2 つ見つける必要があり、すべてを承認することはできません。

実行フロー

第一ラウンド：並行作業
  ├── Explorer  → コードマップ
  ├── Analyst   → 問題リスト
  ├── Architect → 案の比較
  └── Librarian → ライブラリ選定

第二ラウンド：相互審査
  └── Critic すべての出力を読む → 審査意見

第三ラウンド：総合出力
  └── すべての結論を統合 → 最終的なアドバイス

出力フォーマットの仕様

各委員の出力ブロックは、以下の形式で囲みます。

## [役割名] の報告

### 結論
（核心的な発見、3〜5 件）

### 詳細な分析
（具体的な内容）

### 信頼度
高 / 中 / 低（+ 理由の説明）

Critic は追加で以下を出力します。

## [Critic] の審査意見

### 発見された問題
1. 针对 Explorer：...
2. 针对 Analyst：...
3. 针对 Architect：...
4. 针对 Librarian：...

### 総合的なアドバイス
（すべての視点を統合した最終的なアドバイス）

使用ガイド

いつすべての 5 人の委員を起用するか

• 複雑な bug の調査
• 重要な機能の案の設計
• 技術選定の意思決定

いつ一部の委員のみを起用するか

タスクの種類に応じて調整します。

実行原則

1. 各委員の独立性：後で発言する委員は、前の委員の結論を予断すべきではありません。
2. Critic は最後：他の委員が完了するまで発言してはなりません。
3. 信頼度の透明性：不確かな結論には、信頼度を明記する必要があります。
4. ユーザーの問題に焦点を当てる：すべての分析は、ユーザーの元の問題に役立つものであり、無関係な展開は行いません。

示例トリガー語

• "このコードに何か問題がないか分析してください"
• "X を実装したいのですが、どの案が良いですか"
• "このライブラリの使い方と、何か落とし穴はありますか"
• "この PR を見てください"
• "なぜここでメモリリークが発生するのですか"
• "このモジュールをリファクタリングしたいのですが、どのように設計すればよいですか"