# Multi Review

> multi-review: マルチエキスパート並列レビュー

- Skill: `shotaiuchi/multi-review-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add shotaiuchi/multi-review-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shotaiuchi/multi-review-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ShotaIuchi (https://skillmd.com/u/shotaiuchi)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/shotaiuchi/multi-review-2

---


# multi-review: マルチエキスパート並列レビュー

複数のドメイン専門家がレビュー対象を同時に分析し、それぞれ異なる観点から指摘を行う。全ての指摘は優先度順にまとめた統合レポートとして出力されるため、見落としを防げる。

## 専門家ロール

以下のロールが利用可能。レビュー対象に最も関連するものを選択する — 全てのレビューで全ロールが必要なわけではない。

| ロール | 観点 |
|--------|------|
| セキュリティ | 脅威、脆弱性、認証、データ漏洩 |
| パフォーマンス | 効率、スケーラビリティ、計算量、キャッシュ |
| 保守性 | 設計、可読性、SOLID、結合度 |
| 品質 | 正確性、エッジケース、エラー処理、テスト |
| 並行性 | レースコンディション、デッドロック、async/await、ロック |
| 分散システム | 一貫性、冪等性、リトライ、サーキットブレーカー |
| 状態管理 | ステートマシン、キャッシュ整合性、ライフサイクル |
| 障害耐性 | 耐障害性、グレースフルデグラデーション、回復 |
| 最新動向 | 最新の推奨事項、非推奨API、既知のCVE |

**ロール選択**: レビュー対象を見て関連するロールを選ぶ。シンプルなユーティリティ関数ならセキュリティ・品質・保守性だけで十分。分散非同期サービスなら多くのロールを使う。判断して選択する — 無関係な専門家をスポーンするとトークンが無駄になるだけで価値が増えない。

### 最新動向エージェント

最新動向エージェントは他のロールとは異なる。**WebSearch** を使い、モデルの学習データを超えた最新情報を調査する。ツールなしのClaudeと比べて本質的に差別化される唯一のロール。

このエージェントの動作：

1. レビュー対象で使用されている言語・フレームワーク・ライブラリを特定する
2. それぞれについてWeb検索を実行：
   - `"{ライブラリ名} security advisory {現在の年}"` — 既知のCVE、セキュリティパッチ
   - `"{フレームワーク名} best practices {現在の年}"` — 現在の推奨パターン
   - `"{ライブラリ名} deprecated API"` — 移行が必要な非推奨API
3. 検索結果を実際のレビュー対象コードと照合する
4. **コードに直接関連する**指摘のみ報告する — 汎用的なベストプラクティス一覧は不要

最新動向エージェントのプロンプトでは WebSearch の使用を指示し、他のエージェントと同じJSON形式で返させる。`detail` フィールドにソースURLを含めること。

## レビュー対象の特定

`$ARGUMENTS` を解析してレビュー対象を判断する：

| 入力 | アクション |
|------|----------|
| ファイルパス（`src/auth.ts lib/db.rs`） | 指定ファイルを読み込んでレビュー |
| `staged` または `--staged` | `git diff --staged` を実行 |
| `diff` | `git diff`（ステージされていない変更）を実行 |
| PR番号（`#123` または `123`） | `gh pr diff <number>` を実行 |
| 空 | まず `git diff --staged` を試行、空なら `git diff` にフォールバック |
| 自然言語の説明 | 説明から関連ファイルを特定、曖昧な場合はユーザーに確認。例: `"認証フローをレビューして"` → `auth`、`login`、`session` に一致するファイルを検索して読み込み、一致が不確実な場合はユーザーに確認してから進める。 |

差分ベースのレビューでは、変更行だけでなく変更対象のファイル全体も読み込んでコンテキストを提供する。ただし、**差分**（実際の変更）と**コンテキスト**（変更されていない周辺コード）を明確に区別すること。差分の変更部分のみがレビュー対象であり、コンテキストはコードを理解するためだけに提供される。

## 実行フロー

### ステップ1 — 対象の収集

上記ルールに基づきレビュー素材を取得する。

### ステップ2 — 専門家を並列スポーン

Agent ツールを使い、選択した全ての専門家を **1つのメッセージで** スポーンする（専門家ごとに1つのツールコール）。各エージェントにはロールとレビュー対象を渡す：

```
あなたは {Role} の専門家としてコードレビューを行います。

以下のレビュー対象をレビューし、JSON形式で指摘を返してください：

## 変更内容（レビュー対象 — この変更についてのみ指摘すること）
---
{diff}
---

## コンテキスト（参照用 — 変更されていないコードについて指摘しないこと）
---
{full_file_contents}
---

**スコープ**: レビューは差分で追加または変更されたコードに**限定**すること。
コンテキストセクションは周辺コードの理解を助けるためだけに提供されている。
変更されていない行の問題を指摘しないこと — たとえ問題があっても、このレビューの
スコープ外である。

**エラーハンドリング**: 読み取れないファイル、バイナリファイル、またはパースできない
コンテンツに遭遇した場合、無視してはいけません。代わりに severity "important"
（下記の重要度ガイドを参照）、title "読み取り不能またはパース不能なコンテンツ" の
指摘を追加し、どのファイル/セクションが処理できなかったか、その理由を記載してください。
残りのコンテンツは通常通りレビューを続行してください。
ツールコールが失敗した場合（ファイル読み取りエラー、タイムアウトなど）、1回リトライ
してください。再度失敗した場合は、その失敗を指摘として報告し、取得できたコンテンツで
レビューを続行してください。説明なしに空の findings リストを返さないでください。

重要度レベルは下記の **重要度ガイド** セクションの定義に従ってください
（critical, important, suggestion, positive）。

以下の形式で返してください：
{
  "expert": "{role}",
  "findings": [
    {
      "severity": "<重要度ガイドを参照>",
      "title": "簡潔な1行の説明",
      "location": "file_path:line_number（該当する場合）",
      "detail": "なぜこれが問題で、何が起こりうるか",
      "recommendation": "具体的な修正案またはアクション"
    }
  ],
  "summary": "あなたの観点からの全体評価（1段落）"
}
```

### ステップ3 — レポートの統合

全エージェントの指摘を収集し、最終レポートを作成する。

**デフォルト：統合レポート** — 重要度順に整理（レベルの定義は下記の **重要度ガイド** を参照）し、専門家名を角括弧でタグ付け：

```markdown
# レビューレポート

**対象**: <レビュー対象>
**専門家**: <使用した専門家の一覧>

<!-- 重要度ガイドの4つのレベルを使用 -->
| 重要度 | 件数 |
|--------|------|
| Critical | N |
| Important | N |
| Suggestion | N |
| Positive | N |

## Critical（致命的）
- [セキュリティ] `db.query()` での文字列補間によるSQLインジェクション — `auth.ts:42`
  パラメータ化クエリを使用する。

## Important（重要）
- [パフォーマンス] ユーザー一覧エンドポイントでのN+1クエリパターン — `api.ts:55`
  単一のJOINで関連レコードを一括取得する。

## Suggestions（提案）
...

## Positive（良い点）
...

## 専門家間の重複指摘

| 指摘内容 | 指摘した専門家 | 重要度 |
|---------|-------------|--------|
| 入力バリデーション不足 | セキュリティ、品質 | Critical |

## 専門家サマリー
- **セキュリティ**: ...
- **パフォーマンス**: ...
```

**代替：専門家別レポート** — ユーザーが `--by-expert` を指定した場合、全ての指摘を各専門家の見出しの下にグループ化する。この場合も「専門家間の重複指摘」表を含める。

## 重要度ガイド

これは重要度レベルの **正規定義** である。全てのエージェントプロンプトとレポートテンプレートはこの表を参照する — 他の場所でレベルを再定義しないこと。

| レベル | 意味 | アクション |
|--------|------|----------|
| Critical | セキュリティホール、データ損失、クラッシュ、レースコンディション | マージ前に必ず修正 |
| Important | パフォーマンス問題、設計負債、テスト不足 | 早期に修正すべき |
| Suggestion | スタイル、軽微な最適化、防御的改善 | 検討を推奨 |
| Positive | 維持すべき良いプラクティス | この方針を継続 |

## ヒント

- レビュー対象が非常に大きい場合（1000行以上）、軽微な問題を全て列挙するのではなく、専門家あたり上位5〜8件の指摘に集中させる。
- PRレビューでは、PR説明とリンクされたIssueもコンテキストとして読み込む。
- 専門家間の重複指摘は最も価値ある出力の一つ。2人の専門家が独立して同じ問題を指摘することは、その問題が重要である強いシグナル。必ず重複指摘表を含めること。