モチベーション

PRレビューを人間がやると、チェック漏れやムラが発生する。

Claude Codeのスラッシュコマンドを使ってレビュースキルを作成することで、PRの内容を自動解析する仕組みを構築した。

レビューの作業のうち、コード品質やセキュリティ観点などは機械に任せ、ユーザーは仕様の正確性やオーバーエンジニアリングの判断など、AIが苦手な判断を行うことに時間を使う。

Claude Codeには公式プラグインとして /code-review や /pr-review-toolkit:review-pr などがあるが、いずれもセキュリティ観点やコードポリシーのチェックは含まれていない。弊社のコードポリシーに従った観点や時間軸を考慮したレビューを行うための独自レビューを用意することにした。

設計

3つの軸でレビューを自動化する。

• セキュリティチェック: OWASP Top 10ベースの脆弱性検出 + レッドチーム/ブルーチーム分析
• コードポリシー: N+1クエリ、認可チェック、型安全性などのコーディング規約チェック
• スコープ分析: PRの目的に対して変更が適切か、目的外の変更(オーバーエンジニアリング)が混ざっていないかの検出

オーバーエンジニアリングはプロジェクト時間軸の考慮などが必要だったりAIには難しい観点なので、 サマリを読んで人間が判断する形とする。(ここは粒度の調整が現在の課題)

サブエージェント設計

各チェックはサブエージェントとして並列に起動する。いくつか構成のポイントを紹介する。

ファイル単位でエージェントを分割

1つのエージェントに大量のファイルを読ませると、前半のファイルのコンテキストが後半の判定に影響する。

数ファイル単位でエージェントを分けることで、各ファイルに対してフラットな目線でレビューできる。トークン節約にもなる。

サボり防止

サブエージェントは放っておくと一部のファイルをスキップする。

対策として、レビュー開始前に検査対象ファイルのリストを出力させ、完了時に全ファイルが処理されたか評価する。

これでもファイル数が多い大規模PRではサボるのが課題。

セキュリティレビュー

セキュリティチェックは /security-audit コマンドをベースに自作しており、red-teamが攻撃シナリオを洗い出し、blue-teamがそれを検証して偽陽性をフィルタする構成。

観点はOWASP Top 10に加えて、業務システム・マルチテナントシステムにありがちな認可境界にフォーカスしている。

BOLA(他テナントのリソースへのアクセス)やBFLA(権限昇格)のような、機能テストでは見つけにくい脆弱性を重点的にチェックする。

ワークスペース構造

レビュー資材はすべて ~/.local/claude/review-pr/ 配下に出力している。

実行元のパスに依存しないようにしている。

~/.local/claude/review-pr/{owner}-{repo}/
├── source/                            # regular clone (レビュー間で共有)
└── {pr-branch}/                       # PRブランチ名でディレクトリを分離
    ├── target/                        # git worktreeで作成した作業コピー
    ├── r1/                            # round 1（レビュー結果、永続保持）
    │   ├── diff.patch
    │   ├── changed-files.txt
    │   ├── diff-stat.txt
    │   ├── task-tracker.md            # 進捗管理マトリクス
    │   ├── analysis/                  # 各エージェントの分析結果
    │   └── findings.md               # 最終指摘リスト
    └── r2/                            # round 2（再レビュー時に自動インクリメント）

ソースはregular cloneとして保持し、レビューごとに git worktree でブランチのコピーを作る。 レビューはラウンド制（r1/, r2/, …）で管理され、再レビュー時も過去のレビューサマリは保持される。

重大度の定義

指摘の重大度は攻撃可能性ベースで3段階に分類する。

• 攻撃可能: 外部からの攻撃パスが存在し、防御がなく、具体的な被害シナリオがある
• リスク有: 今後実装変更が行われた場合に脆弱性となる可能性がある
• 改善提案: 直接的な攻撃ベクタはないが、品質・保守性の改善になる

各エージェントの指摘は統合評価で攻撃可能性を軸に再評価される。 実コードを読んで検証するので、「理論上は危険だが実際には到達不能」みたいな指摘はフィルタされる。

GitHub投稿

レビュー結果はGitHubのPR Reviewとして投稿する。

ユーザーが指摘一覧から投稿するものを選択し、各指摘に対して判断ラベルを付ける。

• 問題なし: 意図的な設計、許容範囲
• 要修正: インラインコメントとして投稿
• 保留: 既知の問題、別途対応

感想

ほとんどの人類よりも丁寧にレビューできる。

ソースコードは具体的な動作の集まりなので、コード→レビュー生成はAIには得意な気がする。

vibe codingはユーザーの指示の質に左右されるが、レビューはレビューの観点を言語化してしまえばあとは回すだけと言える。

機能の過不足のコードレビューではなく実際のプロダクトの動作を確認するべきで、そのあたりもそのうちAI化できるといいかもしれない。

課題・感想

コスト

レビューあたりのトークン消費が大きい。Max x5だと15~30分くらいで規制されるのでMax x20が必要。

codexレビューがいいという噂

同じルールでcodex(GPT-5.4?)でレビューを試してみたが、Claude Codeの方が指摘の量は多い。

codexはロジカルな部分を読み込んでくれている感じはあるが、気になったところだけ深掘りする感じ。

vibe codingしてる時にcodexにレビューさせるのは良いかもしれない。

偽陽性

現在のプロダクトのフェーズにはオーバーエンジニアリングな指摘が多々発生する。

LLMは状態を持たないので、長時間の時間軸が入ってくる考慮事項のある指摘が難しい。

vibe coding同様にminifyはある程度人類の仕事と言える。

みんなAIが書いたコードをどんどん消していこう。