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 の代替ではなく、人工の前に先に走らせる。機械は形式と一般的問題を捕捉、人は設計と業務ロジックに焦点を。
この記事は役に立ちましたか?