code-review

コードレビュー診断

体系的なコードレビューにより、本番環境へのリリース前に欠陥の60〜90％を発見でき、保守コストを40％削減できるほか、効果的な知識共有にも役立ちます。このスキルでは、人間のレビュアーとAI エージェントの両方に向けた、構造化されたレビューの指針を提供します。

このスキルを使用するタイミング

次の場合にこのスキルを使用します：

• マージ前にコードをレビューするとき
• コードの品質を評価するとき
• PR 提出に向けてコードを準備するとき
• レビューを依頼する前にセルフレビューするとき

次の場合はこのスキルを使用しないでください：

• 新しいコードを書くとき（実装スキルを使用します）
• アーキテクチャを設計するとき（system-design を使用します）
• 要件に取り組むとき（requirements-analysis を使用します）

基本原則

PR の規模が大きくなると、レビューの効果は急激に低下します。 400行未満では欠陥検出率が最も高くなります。400〜800行では効果が50％低下します。800行以上では効果が90％低下します。

クイックリファレンス：レビューの効果

要素	最適	低下
PR の規模	400行未満	800行超
レビュー時間	60分未満	90分超
レビュー速度	200〜400 LOC/時間	500 LOC/時間超
レビュアー	2人	4人以上（効果が逓減）

品質ピラミッド

レベル	チェック内容	検出率	頻度
1. 自動化	Lint、型、単体テスト、セキュリティスキャン	60％	コミットごと
2. 統合	統合テスト、コントラクト、パフォーマンス	25％	PR ごと
3. 人間によるレビュー	設計、ロジック、保守性、コンテキスト	15％	重要な変更時

レビューの重点領域

1. 正確性

確認事項：

• 明示された問題を解決していますか？
• エッジケースに対応していますか？
• エラー処理は完全ですか？
• 前提は妥当ですか？

検証項目： テストカバレッジ、ビジネスロジック、データ整合性、並行処理への対応

2. 保守性

確認事項：

• コードを読めば内容が分かりますか？
• 容易に変更できますか？
• 抽象化は適切ですか？
• 複雑さは妥当ですか？

指標： 明確な命名、単一責任、最小限の結合、高い凝集度

3. パフォーマンス

確認事項：

• 明らかなボトルネックはありますか？
• キャッシュは適切ですか？
• クエリは最適化されていますか？
• メモリは適切に管理されていますか？

危険信号： N+1 クエリ、上限のないループ、非同期コンテキストでの同期 I/O、メモリリーク

4. セキュリティ

確認事項：

• 入力は検証されていますか？
• シークレットは保護されていますか？
• 認証は確認されていますか？
• 権限は検証されていますか？

重要なチェック項目： ハードコードされたシークレットがないこと、SQL のパラメーター化、XSS の防止、CSRF トークン

コードの不吉な臭いチェックリスト

メソッドレベル

臭い	しきい値	対処
長いメソッド	50行超	メソッドを抽出
長いパラメーターリスト	5個超のパラメーター	パラメーターオブジェクト
重複コード	類似する行が10行超	共通部分を抽出
デッドコード	呼び出されていない	削除

クラスレベル

臭い	症状	対処
神クラス	1000行超、20個超のメソッド	クラスを分割
機能の羨望	他クラスのデータを過剰に使用	メソッドを移動
データの塊	同じパラメーター群	クラスを抽出

アーキテクチャレベル

臭い	検出方法	対処
循環依存	依存関係の循環	インターフェースを導入
不安定な依存関係	変化しやすいモジュールへの依存	依存関係逆転

コメントのガイドライン

コメントの種類

[BLOCKING] - マージ前に必ず修正

• セキュリティ上の脆弱性、データ破損のリスク、API の破壊的変更

[MAJOR] - マージ前に修正するべき

• テスト不足、パフォーマンスの問題、コードの重複

[MINOR] - 後続の対応で修正可能

• スタイルの不統一、ドキュメントの誤字、命名の改善

[QUESTION] - 明確化を求める

• 設計上の決定、ビジネスロジック、外部依存関係

効果的なコメントのパターン

Observation + Impact + Suggestion

Example:
"This method is 200 lines long [observation].
This makes it hard to understand and test [impact].
Consider extracting helper methods [suggestion]."

避けること

• 曖昧なコメント：「ここは改善できるかもしれません」
• 個人的なコメント：「これは好きではありません」
• 細かすぎるコメント：「コメントの末尾に句点がありません」
• 過剰な指摘：細かなスタイル上の問題を50件以上

レビュー準備状況のチェックリスト

レビューを依頼する前に

• 機能が完全に実装されている
• すべてのテストが作成され、合格している
• 自己レビューを実施している
• コメントアウトされたコードやデバッグ用の記述がない
• カバレッジのしきい値を満たしている
• リントエラーがない
• ビルドが成功する
• ドキュメントを更新している
• PR の説明で問題と解決策を説明している

PR の説明に含める内容

• 問題の説明（なぜこの変更が必要か）
• 解決方法（どのように解決するか）
• テスト方針（どのように検証したか）
• 破壊的変更（ある場合）
• レビューで重点的に確認する箇所（特に注意して見るべき箇所）

複雑度のしきい値

循環的複雑度

範囲	分類	対応
1-10	単純	問題なし
11-20	中程度	リファクタリングを検討
21-50	複雑	リファクタリングが必要
> 50	テスト不能	分解が必須

認知的複雑度

範囲	分類
< 7	明快
7-15	許容範囲
> 15	分かりにくい — リファクタリングが必要

アンチパターン

判を押すだけのレビュー

徹底的なレビューを行わずに承認すること。「LGTM」と 1 分未満で返信すること。 対策： 最低レビュー時間を設け、コメントを必須とし、ランダム監査を実施します。

細部への過剰な指摘

実際の問題を見落としながら、スタイルに関するコメントを 50 件以上付けること。 対策： スタイルチェックを自動化し、ロジックと設計に注目して、軽微なコメントを制限します。

一括レビュー

圧倒されるような、2000 行を超える PR。 対策： 小さな PR を積み重ね、フィーチャーフラグを使い、ドラフトの段階で早めにレビューします。

セキュリティスキャンの分類

深刻度の分類

レベル	定義	SLA
Critical	リモートコード実行が可能	直ちに修正
High	データ侵害の可能性がある	24 時間以内に修正
Medium	影響が限定的	スプリント内に修正
Low	リスクが最小限	都合のよいときに修正

レビューメトリクス

効率

メトリクス	目標
最初のレビューまでの時間	< 4 時間
レビューサイクル数	< 3
PR 作成からマージまでの時間	< 24 時間

品質

メトリクス	目標
欠陥検出率	> 80%
マージ後の欠陥	PR あたり < 0.5 件
レビューカバレッジ	100%

関連スキル

• github-agile - PR ワークフローと GitHub 連携
• task-decomposition - PR が大きすぎる場合に分解する
• requirements-analysis - 要件が不明確な場合に使用する