AIと一緒に作る個人開発のレビュー手順

はじめに

Claude Code で実装が完了したら、次は確認と判断です。「テストが通ったから大丈夫」ではなく、複数の視点からコードを確認する必要があります。

Claude Codeの基本ガイドでは安全なプロンプトの作り方を、危険性ではスコープ管理を、Git運用では変更追跡を、ファイル境界では編集許可を、タスク分解では段階的実装を解説しました。

本記事では、その最後のレイヤー——AI実装後のレビューワークフロー——を詳しく解説します。

なぜAI実装のレビューが特に重要か

AI の「得意」と「苦手」

AI は以下が得意です：

✅ 規模が大きい、繰り返しが多いコード
✅ 既存パターンに似た実装
✅ テストの自動化

しかし、以下は苦手または見落としやすいです：

❌ ビジネスロジックの正確さ
❌ エッジケース (boundary conditions)
❌ セキュリティの細部
❌ パフォーマンス最適化
❌ 既存コードとの整合性

つまり、テストが通っても、上記の項目に問題がある可能性があります。

人間とAIのレビューの役割分担

AI実装
  ↓
テスト確認（自動化で十分）
  ↓
コード構造確認（人間）
  ↓
ビジネスロジック確認（人間）
  ↓
セキュリティ / パフォーマンス確認（人間）
  ↓
コミット決定（人間）

人間が確認すべき項目は、自動テストだけでは検出できません。

AI実装後のレビュー7段階ワークフロー

ステップ1: git diff で変更内容を全体確認

# 変更されたファイル名のみ確認
git diff --name-only

# ファイル別統計
git diff --stat

# 全体の詳しい変更内容
git diff

確認項目：

□ 指示した範囲のファイルだけが変更されているか？
□ 禁止ファイル (.env, migrations など) が含まれていないか？
□ 削除されたコードは意図的か、誤削除か？
□ 行数の増減は納得できるか？

ステップ2: コード構造と可読性

□ 命名規約が統一されているか？
□ 関数の長さは適切か？（50行以上は疑う）
□ コメントが必要な複雑な部分にはコメントがあるか？
□ インデント、括弧の配置は一貫しているか？

ステップ3: ビジネスロジックの正確さ

これが最も重要です。コードが正しい仕様を実装しているか確認します。

例：「ユーザーのクレジット上限を超えないようにする」という要件

❌ AI が書いたコード：
   if (user.credit > limit) { reject(); }

✅ 正しい実装：
   if (user.credit + charge > limit) { reject(); }

AI は指示を字面で実装することがあります。要件の細部を理解しているか確認します。

ステップ4: エッジケースの処理

想定例：ユーザー入力の処理

□ 空文字列は処理されているか？
□ 非常に長い入力 (10000文字) は処理されているか？
□ 特殊文字 <, >, ", ' などは適切にエスケープされているか？
□ null/undefined は処理されているか？
□ 数値の場合、マイナス値はどう扱っているか？

ステップ5: セキュリティ確認

□ ユーザー入力は検証・サニタイズされているか？
□ SQL インジェクションの危険性はないか？
  └─ ORM や prepared statement を使用しているか？
□ 認可チェックは実装されているか？
  └─ ユーザーA が ユーザーB のデータにアクセスできないか？
□ ハードコードされた秘密情報（API キー、パスワード）がないか？
□ 外部 API 呼び出しはタイムアウト処理があるか？

ステップ6: パフォーマンス

□ ループ内で不要な DB クエリが走っていないか？
  └─ N+1 問題
□ ループ内で不要な文字列連結・配列コピーがないか？
□ 無限ループの危険性はないか？
□ キャッシュ機会はあるか？

ステップ7: テスト実行と動作確認

# テスト実行
npm test

# 実装した機能の手動確認
# ブラウザ / CLI で実際に試す

確認項目：

□ テストが全て成功しているか？
□ 指示した機能が動いているか？
□ 関連機能が壊れていないか？（回帰テスト）

確認でNG が見つかった場合

軽微な問題（スタイル、可読性）

❌ インデントが不揃い
❌ 変数名が不明確
❌ コメント不足

→ Claude Code に「直してください」と指示

中程度の問題（ロジック、エッジケース）

❌ ビジネスロジックが要件と合致していない
❌ 入力値が 100 以上のときに失敗する
❌ エラーハンドリングが不完全

→ 原因を説明して修正させる
→ git diff でもう一度確認

重大な問題（セキュリティ、データ損失リスク）

❌ ユーザー入力がそのまま DB に格納される
❌ 全ユーザーのデータを削除する権限チェックがない
❌ 本番 API キーがコードに埋まっている

→ コミットを進めずに、AI に原因を説明させて修正
→ 場合によっては git reset で全取り消し

Git コマンドでの確認方法

特定ファイルだけ確認

# src/payment-logic.py だけを詳しく確認
git diff src/payment-logic.py

# 追加された行だけを見る
git diff src/payment-logic.py | grep '^+'

削除されたコードだけを確認

git diff | grep '^-'

個人開発でのおすすめレビュー手順

タイパーに最適な 5 段階短縮版

1. git diff --stat で全体サイズ確認
   └─ 行数の増減が納得できるか？

2. git diff でコード内容確認
   └─ 禁止ファイルが入っていないか？
   └─ 意図しないコード削除がないか？

3. npm test でテスト実行
   └─ テストが通るか？

4. 手動で機能確認
   └─ 実装した機能が動くか？
   └─ 関連機能が壊れていないか？

5. git commit
   └─ 問題がなければコミット

このシンプルなワークフローでも、大半の問題は捕捉できます。

AI レビュー vs 人間レビューの活用

AI にレビューさせる場合

Claude Code に「このコードはセキュリティ問題がないか確認してください」と指示し、AI の指摘を参考にする方法もあります。

ただし、AI のレビューも完璧ではないので、人間の確認の代替にはなりません。

AI レビュー → 参考情報
人間確認 → 最終判断

チェックリスト

コピペして、各実装後に確認します：

□ git diff --name-only で対象ファイル確認
□ 禁止ファイル確認
□ テスト実行
□ 手動動作確認
□ ビジネスロジック確認
□ セキュリティ確認 (入力検証、認可)
□ パフォーマンス確認 (N+1 問題など)
□ git commit 決定

まとめ

AI で実装したコードは、テストが通っても完璧ではありません。

重要なのは：

• テスト確認（自動）+ 人間による複数視点の確認
• ビジネスロジック、セキュリティ、パフォーマンスを人間が確認
• 問題が見つかったら、修正 → 再確認のループ
• 確認なしのコミット・デプロイはしない

基本ガイドから始まり、危険性、Git運用、ファイル境界、タスク分解を経て、最後はこのレビュー手順で、安全で効率的なAI支援開発が完成します。