AIに仕事を奪われる前に、レビュー地獄で死にそうになった話
こんにちは。AIツールの課金額を月1万円に抑えることに成功し、妻との関係が改善したエンジニアです。
前回の記事では、AIへの任せ方について書きました。今回はその続編です。
前回の記事を実践し、生産性が上がった結果、「レビュー地獄」という新たな敵」 が現れたのです。
月曜朝9時、地獄の始まり
月曜日 朝9:00
Claude: 「ログイン機能実装しました！（300行）」
Cursor: 「DBスキーマ最適化しました！（15ファイル変更）」
ChatGPT: 「リファクタリング完了です！（2000行差分）」
私: 「...朝から2300行のレビュー？」
3時間後
私: 「まだ半分も終わってない...」
Claude: 「追加で認証機能も実装しました！」
私: 「やめてくれ」
AIをうまく使えるようになった。めでたしめでたし...と思いきや。
誰がそのコードをレビューするんだ？
理想と現実のギャップがエグい
理想（2024年の妄想）：
AI「コード書きました」→ 私「ありがとう！」→ 5秒で確認 → デプロイ → 定時退社
現実（2025年の地獄）：
AI「コード書きました」（0.5秒）→ 私「このロジック正しい？」（10分）→「セキュリティ大丈夫？」（20分）→「パフォーマンスは？」（15分）→「整合性は？」（30分）
結果：1つのAI生成コードに75分。その間にAIは次の10個を生成済み。
「AIマインスイーパー問題」が想像以上にキツい
最近話題の「AIマインスイーパー」という概念を、身をもって体験しました。
AIが理詰めで解ける部分はすべて先に処理し、人間には“当てるしかない”運ゲー部分だけが残る
簡単なタスクはAIが処理し、複雑で責任の重いタスクだけが人間に残される。
Before: CRUD実装（退屈だけど楽） → アルゴリズム設計（大変だけど楽しい）
After: AIが簡単な作業を3秒で終わらせる → 人間は責任だけ負ってレビュー地獄
しかも、AIは日々賢くなり、私は日々AIに依存して能力が落ちる。この構造的な非対称性の前で、「辛くない」と感じる方が難しい。
でも、ちょっと待てよ
レビュー地獄で疲れ果てた金曜の夜。ビールを飲みながら、ふと思った。
「これって、新しいゲームのルールなだけじゃない？」
昔：自分でコードを書いて価値を生む
今：AIを使いこなして価値を生む
ルールが変わっただけで、ゲーム自体は続いている。
そして気づいた。レビューもAIにやらせればいいじゃん。
発想の大転換：実装前にAIレビューする
ある記事で、元Googleのエンジニアがこう書いていた。
「コードを書く前に設計レビューで問題の8割を潰す」
これだ、と思った。
「実装後にレビュー地獄」じゃなくて「実装前にAIレビュー」
まず、細かい粒度でissueを切る
実装前レビューを成功させる秘訣は、タスクを適切な粒度に分解することから始まります。
「ユーザー認証機能を作る」という大きなタスクをそのまま実装しようとすると、AIも人間も混乱します。だから、まずフロントエンドとバックエンドに分けてissueを作成する：
# ユーザー認証機能 → 6つのissueに分解
## バックエンド
- Issue #1: ログインAPI実装（認証・JWT生成）- 3時間
- Issue #2: 会員登録API実装（バリデーション・DB保存）- 3時間
- Issue #3: パスワードリセットAPI（メール送信含む）- 4時間
## フロントエンド
- Issue #4: ログイン画面UI実装 - 3時間
- Issue #5: 会員登録画面UI実装 - 3時間
- Issue #6: パスワードリセット画面UI実装 - 2時間
フロントエンドとバックエンドを分けることのメリット：
- 並行開発が可能：API仕様を決めれば同時に進められる
- 専門性を活かせる：それぞれの得意分野でレビューできる
- 問題の切り分けが明確：エラーの原因特定が簡単
- テストが書きやすい：単体テストの範囲が明確
半日程度で完了する粒度が理想的です。これなら、AIも全体像を把握しながら実装できます。
次に、issueごとに実装計画をmdファイルで作る
細かく切ったissueそれぞれに対して、実装計画をMarkdownで書きます（1issueあたり5分程度）：
# implementation-plan-issue-1.md
## Issue #1: ログインAPI実装
## 概要
ユーザーログインAPIの実装（認証処理・JWT生成）
## 実装ファイル
backend/
├── routes/auth.ts # 認証APIルーティング
├── controllers/authController.ts # ログインロジック
├── services/tokenService.ts # JWT生成・検証
├── middleware/validateLogin.ts # 入力検証
└── tests/auth.test.ts # テストコード
## 技術選定
- JWT vs Session → JWTを選択（理由：スケーラビリティ）
- bcrypt vs argon2 → argon2を選択（理由：より安全）
## 実装順序
1. 入力バリデーションミドルウェア
2. ユーザー認証ロジック
3. JWT生成・署名処理
4. レスポンス形式の実装
5. エラーハンドリング
6. 単体テストの作成
## リスクと対策
- リスク：ブルートフォース攻撃
- 対策：レート制限、ログイン試行回数制限
## 完了条件
- [ ] 正常ログインでJWTトークンが返される
- [ ] 不正なクレデンシャルで401エラー
- [ ] レート制限が機能する
- [ ] 単体テストがすべてパス
そして、この実装計画mdファイルをAIでレビューしてもらう。30秒もあれば、設計の問題点、セキュリティリスク、パフォーマンスの懸念点などを洗い出してくれる。
重要な機能の場合は、複数のAIでクロスレビューすることで、見落としをさらに減らせる。
AIは何をレビューしているのか
実装前のAIレビューでは、主に3つの観点をチェックしています：
設計に準拠しているか？
命名規則、コーディング規約、アーキテクチャパターンに従っているか。SOLID原則やDRY原則を守れているか。
セキュリティは問題ないか？
SQLインジェクション、XSS、CSRF対策は適切か。認証・認可の実装に穴はないか。機密情報の取り扱いは安全か。
現在のプロジェクト構成と整合性を保てているか？
既存のディレクトリ構造に合っているか。他のモジュールとの依存関係は適切か。技術スタックの統一性は保たれているか。
これらをAIが事前にチェックすることで、実装後の手戻りが激減しました。
なぜmdファイルにこだわるのか
最初は「プランモード」を使っていたけど、mdファイルの方が圧倒的に便利だった。
mdファイルの利点：
- 他のAIエージェントで再レビューできる
- Git管理でレビュー履歴を追跡できる
- 修正前後の比較が簡単
- チーム共有がスムーズ
- 人間も読みやすい
レビュー結果もmdファイルで出力させることで、修正後の再レビューや、別のAIでのセカンドオピニオンが簡単になる。
実際に使っているカスタムコマンド
Claude Codeに登録している、レビュー用のコマンドです：
/review:plan // 実装計画の妥当性を評価
/review:security // セキュリティ特化のレビュー
/review:after // 実装後の差分レビュー
他にも便利なコマンドがたくさんあります：
/review:perf // パフォーマンス問題を分析
/review:deps // 依存関係とアーキテクチャの健全性評価
/review:debt // 技術的負債の分析と改善計画
/review:patterns // デザインパターンとSOLID原則の遵守状況
/review:pr // Pull Requestの体系的レビュー
/review:smart // 状況に応じた最適なレビュー方法を自動提案
/review:fact // 情報の正誤確認
/review:prompt // AI向けプロンプトの品質評価
/refactor // 安全で段階的なリファクタリング提案
これらはすべて結果をmdファイルで出力するので、後から再利用や共有が簡単です。
実践してみて分かったこと
3ヶ月この方法を実践して、いくつか重要な発見がありました。
手戻りが激減する
実装後に「あ、これセキュリティ的にマズい」「パフォーマンス問題がある」となって作り直すことがほぼなくなりました。なぜなら、30行の実装計画の段階で問題を潰しているから。
レビュー時間が大幅に削減
2000行のコードレビューより、30行の設計レビューの方が圧倒的に速い。しかも、AIが事前にチェックしているので、人間は本当に重要な判断だけに集中できる。
チームの生産性が向上
レビュー待ちの時間がなくなり、手戻りも減ったことで、デプロイ頻度が週1回から週3回に増えました。
よくある質問
Q: 実装前レビューで本当に問題を防げるの？
完璧ではないですが、私たちのチームでは手戻りが大幅に減りました。実装前に設計の問題を見つけられるのは大きいです。
Q: AIのレビューを信頼していいの？
単独のAIレビューは60-70%の精度ですが、「セキュリティ専門家」「パフォーマンスレビュワー」「設計アーキテクト」など、異なる観点でレビューさせると90%以上の問題を検出できます。
Q: 結局人間のレビューは不要？
いいえ。ビジネスロジックの妥当性、UXの判断、倫理的な問題などは人間の領域です。ただし、時間は大幅に削減できます。
最終的な結論：楽しまないと死ぬ
この状況を辛いと考えるとエンジニアとして終わりそう。
なぜなら、この流れはもう止まらないから。来年のAIはもっと賢い。再来年はさらに。
だから、楽しむしかない。
レビュー地獄？ → 無料でコードが学べる天国
能力が落ちる？ → 新しい能力を身につけるチャンス
AIに負ける？ → AIと一緒に勝つ時代
結局、AIがどれだけ賢くなっても：
- 責任を取るのは人間
- 価値を定義するのは人間
- 意味を見出すのは人間
むしろ、つまらない実装から解放されて、本当に人間がやるべきことに集中できる。
楽しまないと死ぬ。
だから、楽しむことにした。
それが、これからのエンジニアの生き方だと思う。
最後まで読んでいただき、ありがとうございました！
この記事が役立ったら、あなたの「AI共存術」も教えてください。
みんなで新しい時代を楽しんでいきましょう。
P.S. 妻への報告：「AIのおかげで夜中まで作業することがなくなった」（これは本当。レビュー地獄から解放されたから）
📝 著者について
普段は真面目にブロックチェーン周りの記事を書いています。
現在、HivefiというLLMを使ったシステムトレード戦略ハブを開発中。
関連記事：
「いい感じに作って」→ 大炎上。AIへの丸投げで痛い目を見た話
AIとの共存の日々から学んだことを、これからも共有していきます！
Discussion