コードレビュー

適切なレビューなしにクライアントへコードを出荷することは、信頼を損なう最も早い方法です。しかし、アウトソーシングの締め切り下では、レビューすべき上級エンジニアがコードを書いた本人であることがしばしばあります。Sun Agent Kit のコードレビューエージェントは常時利用可能な上級レビュアーとして機能し、ロジック・セキュリティ・パフォーマンス・スタイルをチェックします。チームが手薄なときでも、安心してマージできます。

概要

目的: クライアントの本番ブランチに到達する前に、バグ・セキュリティ問題・パフォーマンス問題を検出する
所要時間: 5〜15分（手動レビューの場合は30〜60分）
使用エージェント: reviewer、scout、debugger
コマンド: /sk:code-review、/sk:code-review #47、/sk:code-review --pending、/sk:code-review codebase

前提条件

• Sun Agent Kit がインストール・認証済みであること（インストールガイド）
• 少なくとも1つのコミットがある git リポジトリ（レビューは差分に対して動作します）
• PR レビューの場合: GitHub、GitLab、または Bitbucket のリモートが設定されてアクセス可能であること

ステップ別ワークフロー

ステップ 1: 現在の作業差分をレビューする

コミット前に、直前のコミット以降に変更したすべての内容に対して即座のフィードバックを取得します。

/sk:code-review --pending

実行内容: エージェントが以下を実行します：

1. ステージ済みおよびステージ未済みの変更から差分スコープを解決
2. ロジックエラー、null安全性の問題、デッドコードを確認する静的解析を実行
3. スタイル規約をチェックし、テストカバレッジが欠けている関数を特定
4. ファイルと行の参照を含むインラインレビューコメントを生成
5. レビューレポートを plans/reports/ に保存

ステップ 2: プルリクエストをレビューする

オープンな PR をエージェントに指定し、構造化されたレビューを取得します。

/sk:code-review #47

実行内容: エージェントが以下を実行します：

1. リモートリポジトリから PR の差分を取得
2. ビジネスロジックの問題、エラーハンドリングのギャップ、セキュリティパターンについてコード変更を分析
3. 新しいコードに対するテストカバレッジのデルタを確認
4. コミットメッセージと PR 説明の品質をレビュー
5. 分類された指摘事項を含むレポートを生成

ステップ 3: セキュリティとパフォーマンスにフォーカスする

時間が限られているときは、プロンプトでレビューのスコープを絞り込みます。

/sk:code-review "focus on security and performance patterns in the checkout feature branch"

実行内容: エージェントが以下を実行します：

1. セキュリティとパフォーマンスの懸念にレビューをスコープ
2. OWASP Top 10 パターン、N+1クエリ、ブロッキングI/O、メモリリークを確認
3. コード提案を含む優先度付きの修正リストを生成

ステップ 4: コードベース全体のスキャンを実行する

リリース前の監査には、コードベース全体のレビューを実行します。

/sk:code-review codebase

実行内容: エージェントが以下を実行します：

1. コード品質、セキュリティ、パフォーマンスの問題についてコードベース全体をスキャン
2. 重大度別に指摘事項を分類
3. 納品ドキュメントに適した包括的なレポートを生成

ステップ 5: クライアント記録用のレビューサマリーを生成する

チームの QA プロセスを示すクリーンなサマリードキュメントを作成します。納品チェックリストを必要とする日本のクライアントに特に有用です。

/sk:code-review "generate delivery checklist summary for the current branch"

実行内容: エージェントがブランチをレビューし、解決済みの指摘事項、テストカバレッジのステータス、セキュリティレビューのステータスをカバーする構造化されたサマリーを生成します。

完全な例: 本番ブランチへのマージ前に PR をレビューする

シナリオ

木曜日の午後5時です。チームは2週間、あるフィーチャーブランチ（ベトナムの EC クライアント向けチェックアウトフローの完全な書き直し）に取り組んできました。クライアントの CTO は金曜日の朝に本番稼働を望んでいます。上級エンジニアは別の案件に入っています。コードの大半を書いたジュニアは動作すると確信していますが、「自分のマシンでは動く」でこのチームは以前も痛い目にあっています。

連鎖コマンド

# 1. リスクの全体像を把握するための完全な PR レビュー
/sk:code-review #112

# 2. セキュリティフォーカスのパス — チェックアウト = 決済データ = 妥協不可
/sk:code-review "security-focused review of PR #112 — check for input validation and injection issues in checkout flow"

# 3. レビューでフラグされたものを修正
/sk:fix "apply fixes from the code review findings"

# 4. 最終レビューパス
/sk:code-review --pending

結果

レビューで2件の HIGH 指摘事項が浮上します。決済ゲートウェイ呼び出しを囲む try/catch が欠落していてエラーをサイレントに飲み込む問題と、検証なしに res.redirect() に渡されるユーザー提供の redirect_url パラメーター（オープンリダイレクト脆弱性）です。エージェントの提案パッチを使用して両方とも20分で修正されます。CTO は金曜日の朝、レビュー記録を確認した上でマージします。

時間比較

ベストプラクティス

1. 大きな PR だけでなく、すべての PR で /sk:code-review を実行する ✅

小さな PR こそロジックのバグが潜みやすい場所です。「明らかに動作する」2ファイルの変更こそ、未検証の入力や欠落したエラーハンドラーが忍び込む場所です。レビューを特別なイベントではなく習慣にしてください。

2. 認証・決済・ユーザーデータに触れる PR ではセキュリティフォーカスのプロンプトを使用する ✅

すべての PR に完全な処理が必要なわけではありません。機密性の高いコードパスに変更が触れる場合、フォーカスされたセキュリティレビューはわずかな時間で完了し、データ侵害を防げます。ROI は非対称です。ほぼコストがかからず、スキップした場合の損害は甚大です。

3. クリーンなレビューをテストの代替と見なさない ❌

静的解析はランタイムの動作を検証できません。クリーンな /sk:code-review はコードが構造的に健全であることを意味します。すべての条件下でフィーチャーが正しく動作することを意味するわけではありません。テストスイートは継続して実行してください。レビューは補完であり、代替ではありません。

4. HIGH 重大度の指摘事項は内容を読まずに適用しない ❌

HIGH 指摘事項にはビジネスロジックの判断が絡むことが多く、エージェントが修正案を提案しても、その提案がドメイン要件に合わない場合があります。HIGH 指摘事項は適用前に必ず内容を確認してください。

トラブルシューティング

問題: レビューが大量のスタイル指摘を生成し、本物のバグが埋もれる

解決策: スタイルを除外するフォーカスプロンプトを使用してください: /sk:code-review "focus on logic errors, security, and performance — skip style and formatting"。これにより、スタイルのノイズなしに重要な指摘事項を明確に確認できます。

問題: PR レビューが「cannot fetch diff — authentication error」で失敗する

解決策: Git 認証情報を確認してください。GitHub の場合は gh auth status を実行するか、SSH キーを確認してください。トークンベースのアクセスは期限切れになります。エージェントがプライベートリポジトリから PR の差分を取得するには有効な認証情報が必要です。

問題: エージェントが意図的なパターンをフォールスポジティブとしてフラグする

解決策: プロンプトでコンテキストを説明してください: /sk:code-review "this raw query in the admin route is intentional — focus on other security concerns"。エージェントはガイダンスに基づいて分析を調整します。

問題: 非常に大きなコードベースでレビューに時間がかかりすぎる

解決策: レビューを特定のディレクトリにスコープしてください: /sk:code-review "review only src/api/ and src/services/ directories"。1つの大規模なスキャンではなく、複数のターゲットを絞ったレビューを実行できます。

次のステップ

• セキュリティ監査・スキャン — 納品前の完全な品質ゲートのためにコードレビューと組み合わせる
• パフォーマンス最適化 — レビュアーが発見したパフォーマンス指摘事項を深く掘り下げる
• ドキュメント自動生成 — レビュー記録を含むハンドオフパッケージを作成する

重要なポイント: AI によるコードレビューはエンジニアリングの判断を置き換えるものではありません。時間があればレビュアーが発見できたはずの既知のバグ、セキュリティホール、パフォーマンスの地雷を含む PR がクライアントの本番ブランチに到達しないことを保証するものです。