AI コード Review
OpenClaw があなたの Senior Engineer —— 24 時間在線、すべてのコード行を真摯に確認
Code Review の現実
Review 待ちで花が散る
PR を送ったけど、Senior はほかのプロジェクトで忙しい。2 日後やっと Review された。「LGTM」とだけ書かれた。長く待つか、本当に真面目に見てくれないか —— この Review に何の意味があるのか?
もっと厄介なのはチーム内のルール基準がバラバラなこと。太郎はこんな書き方で大丈夫と言い、花子は必ず変更しろと言う。結局誰の言う通りにする?ルール統一?3 回会議しても決まらない。
OpenClaw:24 時間在線の Senior Engineer
コードを OpenClaw に渡すと、業界ベストプラクティスに従い行ごとに Review してくれます:セキュリティ脆弱性、パフォーマンスボトルネック、保守性、エッジケース、全部カバー。
順番待ちなし、顔色うかがわなくていい、「忙しい」で手抜きしない。毎回の Review 基準は完全に一致 —— もうグループチャットで「これはバグかどうか」について争う必要ありません。
3 つの Review プロンプト、コピーして使う
セキュリティ Review からデザイン原則まで、必要に応じて選ぶ。
PR Review:セキュリティ + パフォーマンス専門 Review
ゴールデン指令
以下のコード変更(PR diff)を Review してください。重点は:
1. セキュリティ脆弱性:SQL インジェクション、XSS、CSRF、機密情報漏洩、安全でない逆シリアル化
2. パフォーマンス問題:N+1 クエリ、不要なメモリ割当、インデックスなしの検索、ブロッキング操作
3. エッジケース:空値処理、並行競合、大容量データシナリオ
各問題について以下を提供:
- 重大度(Critical / Warning / Suggestion)
- 具体的な位置(ファイル名 + 行番号)
- 修正提案とコード例
最後に全体評価と、マージ推奨かどうかを記入。
このプロンプトは PR 提出前に自分で先に走らせるのに適しており、ほとんどの一般的なセキュリティ問題を見つけられます。Claude Opus 4.6 を使うことをお勧めします。ファイル間のセキュリティリスク理解が更に深い。
SOLID 原則適合性チェック
高度なテクニック
以下のコードが SOLID 原則に適合しているかをチェックしてください:
- S(単一責任):このクラス / 関数はやることが多すぎないか?
- O(オープン・クローズド原則):新機能追加に既存コード修正が必要か?
- L(リスコフ置換原則):サブクラスは親クラスを安全に置き換えられるか?
- I(インターフェース分離原則):インターフェースが大きすぎないか?
- D(依存関係反転):高層モジュールが低層実装を直接依存していないか?
各違反原則について:
1. 具体的に何を違反し、どこで違反してるかを説明
2. なぜこれが問題か
3. リファクタリング案とコード例を提供
これはコア業務ロジックまたはインフラストラクチャコードの Review に適しています。毎日の CRUD 小さい API には必要ありません。
データベースクエリ N+1 問題排査
ゴールデン指令
以下のコード内のデータベースクエリを分析してください:
1. すべての N+1 クエリ問題を見つけて:
- ループ内のトリガークエリを示す
- 最悪ケースのクエリ回数を計算
2. 最適化案を提供:
- どれが JOIN で統合可能か
- どれが eager loading / preload で可能か
- どれがキャッシュが必要か
3. 最適化後のコードを書く
4. 最適化前後のパフォーマンス差を推定
ORM フレームワークは [あなたのフレームワーク、例:SQLAlchemy / Prisma / ActiveRecord]。
N+1 は最も一般的なパフォーマンスの杀手の 1 つです。リスト頁が遅い場合はまずこれを確認。ORM フレームワーク名を実際に使用されているものに置き換えることを忘れずに。
Code Review:OpenClaw vs GitHub Copilot
両方ともコード Review ができますが、方式は完全に異なります。
OpenClaw
- プロジェクト全体のコンテキストを見て、ファイル間で業務ロジック理解
- プロンプト完全カスタマイズ、チームのルール基準で Review
- モデル切り替え可能:簡単な Review は GPT-4o、複雑なアーキテクチャは Opus 4.6
- Review 結果をエクスポート、保存、チーム知識ベース化
VS
GitHub Copilot Code Review
- GitHub PR インターフェースに統合、トリガー簡単
- Review 範囲は主に diff 内容で、ファイル間理解に限界
- モデル固定、カスタム Review ルールなし
- 中国語コメントと変数名の理解は時々失敗
実例
スタートアップ:バックエンド 2 人で全コード対応
チームは後端 2 人だけで、相互 Review だけど問題見漏らしが多く、本番環境リリース後にバグ発見。
OpenClaw スキーム
PR 提出前に OpenClaw でセキュリティ + パフォーマンス Review 1 回。明らかな問題をフィルタリングしたら、人工 Review は業務ロジックだけ確認。本番環境事故率が半分に低下、Review 時間が平均 2 日から 半日に短縮。
純人工スキーム
2 人で相互 Review、忙しい時だけ LGTM。コード基準は口約束だけ、新人来たらまた一から教える必要。
いくつかの実用アドバイス
プロジェクト全体を一度に AI Review に出さないでください。モジュール単位でバッチで、毎回 1 つの注目点(例:セキュリティ、パフォーマンス、可読性)に焦点を当て、効果更に良好。
AI Review は人工 Review の代替ではなく、人工の前に先に走らせる。機械は形式と一般的問題を捕捉、人は設計と業務ロジックに焦点を。