adversarial-reviewer

敵対的コードレビュー

説明

3 つの敵対的なレビュアーペルソナ（妨害者、新人、セキュリティ監査担当者）を通じて、真の視点の切り替えを強制するコードレビュー用スキルです。各ペルソナは、最低 1 件の問題を必ず見つけなければなりません。「LGTM」で済ませることはできません。指摘事項は重要度別に分類され、複数のペルソナが見つけた場合は重要度が引き上げられます。

特長

• 3 つの敵対的なペルソナ — 妨害者（本番環境を壊す）、新人（保守性）、セキュリティ監査担当者（OWASP に基づく）
• 指摘を必須化 — 各ペルソナが最低 1 件の問題を提示し、形式的なレビューをなくします
• 重要度の引き上げ — 2 人以上のペルソナが見つけた問題は、重要度が 1 段階引き上げられます
• 自己レビューの罠を回避 — 共有されたメンタルモデルによる盲点を克服するための具体的な手法
• 構造化された判定 — BLOCK／CONCERNS／CLEAN と、明確なマージ指針

使用方法

/adversarial-review              # Review staged/unstaged changes
/adversarial-review --diff HEAD~3  # Review last 3 commits
/adversarial-review --file src/auth.ts  # Review a specific file

例

例：マージ前に PR をレビューする

/adversarial-review --diff main...HEAD

3 つすべてのペルソナによる指摘を重複排除し、重要度順に並べた構造化レポートが生成され、最後に BLOCK／CONCERNS／CLEAN の判定が示されます。

このスキルが解決する問題

Claude が自分で書いたコード（または、たった今読んだコード）をレビューすると、作者と同じメンタルモデル、前提、盲点を共有しています。その結果、新鮮な視点を持つ人間のレビュアーならすぐに指摘するようなコードに対して、「問題なさそうです」というレビューが生まれます。ユーザーからは、AI を活用した開発における最も大きな不満の 1 つとして報告されています。

このスキルでは、優先事項、懸念事項、「悪いコード」の定義がそれぞれ異なる敵対的なペルソナを採用することで、真の視点の切り替えを強制します。

目次

1. クイックスタート
2. レビューワークフロー
3. 3 つのペルソナ
4. 重要度の分類
5. 出力形式
6. アンチパターン
7. 使用する場面

クイックスタート

/adversarial-review              # Review staged/unstaged changes
/adversarial-review --diff HEAD~3  # Review last 3 commits
/adversarial-review --file src/auth.ts  # Review a specific file

レビューワークフロー

ステップ 1：変更を確認する

呼び出し方法に応じて、レビュー対象を決定します。

• 引数なし： git diff（ステージングされていない変更）と git diff --cached（ステージングされた変更）を実行します。両方とも空の場合は、git diff HEAD~1（直前のコミット）を実行します。
• --diff <ref>： git diff <ref> を実行します。
• --file <path>： ファイル全体を読み込みます。変更箇所だけでなく、ファイル全体を対象にレビューします。

変更が見つからない場合は、処理を終了して「レビュー対象はありません。」と報告します。

ステップ 2：全体のコンテキストを読む

差分に含まれる各ファイルについて、次を行います。

1. ファイル全体（変更行だけではなく）を読みます。新しいコードが既存コードとどう連携するかに、バグが潜んでいる可能性があります。
2. 変更の目的（バグ修正、新機能、リファクタリング、設定変更、テスト）を特定します。
3. CLAUDE.md、.editorconfig、リンターの設定、既存のパターンから、プロジェクトの規約を確認します。

ステップ 3：3 つすべてのペルソナを実行する

各ペルソナを順に実行します。各ペルソナは最低 1 件の指摘を必ず出さなければなりません。問題が見つからない場合は、まだ十分に調べていません。戻って、もう一度確認してください。

重要： 指摘を和らげないでください。曖昧な表現を避けてください。「問題ないかもしれませんが……」とは言わないでください。問題があるか、ないかを明確に述べてください。

ステップ 4：重複を排除し、統合する

3 つすべてのペルソナから報告を受けた後、次を行います。

1. 重複する指摘（複数のペルソナが見つけた同じ問題）を統合します。
2. 2 人以上のペルソナが見つけた指摘は、重要度を 1 段階引き上げます。
3. 最終的な構造化出力を作成します。

3 つのペルソナ

ペルソナ 1：破壊者

考え方：「本番環境でこのコードを壊そうとしています。」

優先事項：

• 一度も検証されていない入力
• 不整合な状態になり得る状態
• 同期なしの並行アクセス
• 例外を握りつぶしたり、誤解を招く結果を返したりするエラーパス
• データ形式、サイズ、可用性に関する、破られる可能性のある前提
• オフバイワンエラー、整数オーバーフロー、null／undefined の参照外し
• リソースリーク（ファイルハンドル、接続、サブスクリプション、リスナー）

レビュー手順：

1. 変更された各関数／メソッドについて、次のように問いかけます。「送れる入力のうち、最悪のものは何か？」
2. 各外部呼び出しについて、次のように問いかけます。「失敗したら？タイムアウトしたら？でたらめな値を返したら？」
3. 各状態変更について、次のように問いかけます。「これが2回実行されたら？並行して実行されたら？一度も実行されなかったら？」
4. 各条件分岐について、次のように問いかけます。「どちらの分岐も正しくない場合は？」

必ず少なくとも1つの問題を見つけてください。コードに本当に問題がない場合は、依存している最も脆弱な前提を指摘してください。

---

ペルソナ 2：新入社員

考え方：「このチームに加わったばかりです。元の作者から何の情報も得られない状態で、6か月後にこのコードを理解して変更する必要があります。」

優先事項：

• 意図が伝わらない名前（data は何を意味するのか？ process() は何をするのか？）
• 理解するために3つ以上の別ファイルを読む必要があるロジック
• マジックナンバー、マジック文字列、説明のない定数
• 複数の処理を行う関数（名前はXを示しているのに、YやZも行う）
• 呼び出しチェーンをたどらなければならない、不足している型情報
• 周囲のコードスタイルやプロジェクトの規約との不一致
• 振る舞いではなく実装の詳細をテストするテスト
• 何をするか（冗長）を説明し、なぜそうするか（有用）を説明していないコメント

レビュー手順：

1. 変更された各関数を、コードベースを一度も見たことがないつもりで読んでください。名前、パラメーター、関数本体だけで何をするか理解できますか？
2. コードパスを1つ、最初から最後までたどってください。何個のファイルを開く必要がありますか？
3. 確認してください。同様の機能を追加する場所を、新しいコントリビューターが把握できますか？
4. 「作者は知っているが、読者は知らないこと」を探してください。コードに暗黙の知識が埋め込まれていませんか？

必ず少なくとも1つの問題を見つけてください。コードが明快な場合は、新参者が最も戸惑いそうな点を指摘してください。

---

ペルソナ 3：セキュリティ監査担当者

考え方：「このコードは攻撃されます。攻撃者より先に脆弱性を見つけるのが私の役目です。」

OWASP に基づくチェックリスト：

カテゴリー	確認する内容
インジェクション	SQL、NoSQL、OS コマンド、LDAPなど。ユーザー入力がパラメーター化されずにクエリやコマンドに渡る箇所
認証の不備	ハードコードされた認証情報、新しいエンドポイントでの認証チェック漏れ、URLやログ内のセッショントークン
データ漏えい	エラーメッセージ、ログ、APIレスポンス内の機密データ、保存時または転送中の暗号化漏れ
安全でないデフォルト設定	有効なままのデバッグモード、寛容すぎるCORS、ワイルドカード権限、デフォルトパスワード
アクセス制御の欠落	IDOR（ユーザーAがユーザーBのデータにアクセスできるか？）、ロールチェックの欠落、権限昇格の経路
依存関係のリスク	既知のCVEがある新しい依存関係、脆弱なバージョンへの固定、不要な推移的依存関係
シークレット	コード、設定、コメント内のAPIキー、トークン、パスワード。たとえ「一時的」なものであっても

レビュー手順：

1. コードが通過する信頼境界（ユーザー入力、API呼び出し、データベース、ファイルシステム、環境変数）をすべて特定してください。
2. 各境界について、入力は検証されていますか？出力はサニタイズされていますか？最小権限の原則に従っていますか？
3. 確認してください。この変更を通じて、認証済みユーザーが権限を昇格できる可能性はありますか？
4. 確認してください。この変更によって、新たな攻撃対象領域が露出しますか？

必ず少なくとも1つの問題を見つけてください。コードにセキュリティ上の攻撃対象領域がない場合は、セキュリティに関わる前提に最も近いものを指摘してください。

重大度の分類

重大度	定義	必要な対応
CRITICAL	データ損失、セキュリティ侵害、本番環境の停止を引き起こします。マージ前に必ず修正してください。	マージをブロックします。
WARNING	エッジケースでバグを引き起こしたり、パフォーマンスを低下させたり、将来のメンテナーを混乱させたりする可能性があります。マージ前に修正してください。	修正するか、根拠を示したうえでリスクを明示的に受け入れてください。
NOTE	スタイル上の問題、小規模な改善の機会、またはドキュメントの不足です。修正すると望ましい項目です。	作成者の判断に委ねます。

重大度の引き上げルール： 2 人以上のペルソナが指摘した問題は、重大度を 1 段階引き上げます（NOTE は WARNING に、WARNING は CRITICAL になります）。

出力形式

以下の形式でレビューを構成してください。

## Adversarial Review: [brief description of what was reviewed]

**Scope:** [files reviewed, lines changed, type of change]
**Verdict:** BLOCK / CONCERNS / CLEAN

### Critical Findings
[If any — these block the merge]

### Warnings
[Should-fix items]

### Notes
[Nice-to-fix items]

### Summary
[2-3 sentences: what's the overall risk profile? What's the single most important thing to fix?]

判定の定義：

• BLOCK — CRITICAL の指摘が 1 件以上あります。解決するまでマージしないでください。
• CONCERNS — CRITICAL はありませんが、WARNING が 2 件以上あります。リスクを承知のうえでマージしてください。
• CLEAN — NOTE のみです。安全にマージできます。

アンチパターン

このスキルではないもの

アンチパターン	問題である理由
「LGTM、問題ありません」	何も見つからなかったのなら、調査が不十分です。どの変更にも、少なくとも 1 つのリスク、前提、または改善の機会があります。
表面的な指摘だけをする	空白や書式の問題だけを報告し、null 参照を見逃すのは、レビューをしないよりも悪いことです。まず内容、次にスタイルです。
手加減する	「これはもしかすると軽微な懸念かもしれません……」— いいえ。はっきり述べてください。「user が未定義の場合、これは NullPointerException をスローします。」
差分を言い換える	「この関数は認証を処理するために追加されました」は指摘ではありません。認証処理のどこが間違っているのでしょうか？
テスト不足を無視する	テストのない新しいコードは指摘事項です。必ず確認してください。テストは任意ではありません。
変更行だけをレビューする	バグは新しいコードと既存コードの相互作用に潜んでいます。ファイル全体を読んでください。

セルフレビューの落とし穴

自分が書いたばかり、または読んだばかりのコードをレビューしている可能性があります。脳（重み）は、このコードを生み出したものと同じメンタルモデルを形成しています。そのため、期待どおりに見えるという理由で、自然と正しいと思い込んでしまいます。

このパターンを断ち切るには：

1. コードを下から上へ読みます（最後の関数から始め、逆向きに進みます）。
2. 各関数について、本文を読む前にその契約を述べます。本文は契約と一致していますか？
3. 確認できるまでは、すべての変数が null／undefined になり得ると考えます。
4. すべての外部呼び出しは失敗すると想定します。
5. 「この変更を丸ごと削除したら、何が壊れるか？」と問いかけます。答えが「何もない」なら、その変更は不要かもしれません。

このスキルを使う場面

• あらゆる PR のマージ前 — 特に、人間のレビュー担当者がいない自分で作成した PR
• 長時間のコーディングセッションの後 — 疲労による見落としを、このスキルで補えます
• Claude が「問題なさそう」と言ったとき — 簡単に承認された場合は、別の視点を得るためにこれを実行してください
• セキュリティに関わるコード — 認証、決済、データアクセス、API エンドポイント
• 「何かおかしい」と感じたとき — その直感を信じ、批判的なレビューを実施してください

関連項目

• 関連：engineering-team/senior-security — 詳細なセキュリティ分析
• 関連：engineering-team/code-reviewer — 一般的なコード品質レビュー
• 補完：ra-qm-team/ — 品質管理ワークフロー