🤖

LLMはなぜ『批判』が得意なのか?設計・実装品質を高めるAIレビューファースト開発術

に公開

なぜ大規模言語モデルは 「批判」 を得意とし、どう活用すれば設計・実装品質を高められるのか

「モデルに“自分の出力をレビューして”と頼むと、突然シニアエンジニアみたいになる」

なぜこの記事を書くのか?

  • 「LLMの初回生成より、その出力への批判的レビューの方が有用」 という現象を分析
  • その仕組みを理解し、AI を“シニアレビュアー”として組み込む開発フローを提案する

1. はじめに

  1. ChatGPT / Gemini / Claude に コードやアーキテクチャを生成 させる → 品質にばらつきがある
  2. その出力を 批判(レビュー)させる → より一貫して有用な指摘が得られる

なぜ LLM は 創造 よりも 批判 が得意なのでしょうか?
そして、この“偏り”を 開発ワークフローにどう組み込めば最大の価値を生む のでしょうか?


2. 「批判」が「創造」より簡単になる理由

観点 生成(設計・実装) 批判(レビュー)
2.1 学習データの偏り 完成済みの設計文書は Web 上に少ない PR コメント/Stack Overflow の指摘/Lint 警告など、膨大なレビュー文 が学習コーパスに含まれている [1]
2.2 探索空間の大きさ “ほぼ無限”の設計候補から 1 つを選ぶ必要 具体物に対して局所的な欠点を探すだけでよい
2.3 RLHF の報酬設計 RLHF では「回答をレビューして改善」が多用されるため、良い批判に高報酬が与えられている [2]
2.4 “リフレクション”研究の流行 Self‑Refine [3] や Reflexion [4] など「生成→批判→再生成」を回す手法が発展 批判→修正という能力が強化され続けている
2.5 言語能力との親和性 長いコードや図はコンテキストが圧迫される 理由を説明する自然言語こそ LLM の得意領域

3. AI ファースト・エンジニアリングループ

  1. Just Enough Design Up Front [5]
    • リスクの高い箇所(公開 API、DB スキーマ、スケーリング制約)だけをスケッチ。
  2. Walking Skeleton を LLM に生成させる。
  3. クリティカルレビュー用プロンプト(§4)を実行。
  4. 指摘を 採用/却下 し、影響部分を再生成。
  5. レビューで合格したら ADR として決定を記録。

補足: この手法では 初回プロンプトを過度に作り込む必要はありません。目的・制約・期待するアウトプット形式の3点だけを簡潔に伝え、あとの精度は「生成 → 批判 → 再生成」のループで段階的に磨き上げればよい、という前提です。

1 ループ 5〜10 分ならコンテキストを肥大させず、フィードバックも鮮度を保てます。


4. 使い回せるクリティカルレビュー用テンプレート

カスタムスラッシュコマンドとして作成してあります。

# ⏩ クリティカルレビュー指示

以下のレビュー対象を指定してください:
- **$ARGUMENTS** が指定された場合: その内容をレビュー
- 引数なしの場合: 現在のブランチで行った変更(`git diff main...HEAD` または `git diff develop...HEAD`)をレビュー

## レビュー対象の例
- 特定のファイル: `critical-review src/main.ts`
- ブランチ間の差分: `critical-review main..feature/new-api`
- 最新コミット: `critical-review HEAD~1..HEAD`
- ディレクトリ全体: `critical-review src/`
- PRの変更: `critical-review #123`(PR番号)

## レビュー対象の決定手順
1. 引数が指定されている場合: その引数をレビュー対象とする
2. 引数なしの場合:
   - 現在のブランチ名を取得(`git branch --show-current`)
   - ベースブランチを特定(main, master, develop の優先順位で存在確認)
   - 現在のブランチとベースブランチの差分をレビュー(`git diff <base>...HEAD`)
   - ステージングされていない変更も含める

プロジェクトコンテキストを考慮した批判的レビューを実施してください。

## 🎯 レビューコンテキスト(最初に判定)
- **プロジェクトフェーズ**: MVP/開発中/本番/リファクタリング
- **重要度**: パフォーマンス重視/保守性重視/拡張性重視
- **技術スタック**: 使用言語・フレームワーク・パラダイム

## 1️⃣ レビュー基準(優先順位付き)

**注意**: 以下は代表的な問題カテゴリです。これらに当てはまらない重要な問題を発見した場合は、
必ず「🔵その他」として報告してください。

### 🔴 優先度:高(致命的問題)
1. **セキュリティ**: SQL/XSS注入、認証・認可の欠陥、機密情報露出
2. **データ整合性**: トランザクション、同時実行制御、データ破損リスク
3. **エラー処理**: 未処理例外、リソースリーク、障害伝播

### 🟡 優先度:中(設計品質)
4. **SOLID原則違反**
   - 単一責任: 1クラス/関数が複数の変更理由を持つ
   - 開放閉鎖: 拡張困難な設計
   - リスコフ置換: 継承の誤用
   - インターフェース分離: 不要な依存
   - 依存性逆転: 具象への直接依存
5. **ドメインモデル整合性**: ビジネスルールの誤表現、境界の曖昧さ
6. **テスト可能性**: モック困難、副作用の多い設計、ハードコードされたテスト

### 🟢 優先度:低(改善提案)
7. **パフォーマンス**: N+1問題、不要な計算、メモリ効率
8. **再利用性**: DRY違反、過度な抽象化(YAGNI違反)
9. **慣用法準拠**: 言語/FW固有のベストプラクティス逸脱

### 🔵 その他の重要な問題
10. **上記カテゴリに含まれない問題**: アクセシビリティ、国際化、ログ/監視、
    ドキュメント不足、技術的負債、その他プロジェクト固有の懸念事項

## 2️⃣ 出力フォーマット

````markdown
### 🔴/🟡/🟢 [基準名]
**問題**: 
- 具体的な問題箇所(file:line)
- 問題の詳細説明

**影響**:
- 技術的影響: バグ/性能劣化/保守困難性
- ビジネス影響: ユーザー体験/開発速度/コスト

**修正案**:
```language
// 修正前
問題のあるコード

// 修正後
改善されたコード
```
````

## 3️⃣ 制約とガイドライン

- **問題数**: 優先度高から順に最大5つ(🔴最大2、🟡最大2、🟢最大1)
  - 🔵その他カテゴリは、既存カテゴリで捕捉できない重要問題がある場合のみ使用
- **文字数**: 日本語1200文字以内(コード例除く)
- **具体性**: 必ず行番号/ファイル名を明記
- **建設的**: 批判だけでなく実装可能な改善案を提示

効く理由

  • 観点を明示 → 脱線が減る
  • フォーマット固定 → 次プロンプトでパースしやすい
  • 「7. Other」 → 想定外の重大問題も拾える

5. 運用のベストプラクティスと注意点

何度か行う

3から4回レビューを繰り返すと、問題がなくなってきます。
カスタムスラッシュコマンドとして作成しておくと簡単に実行できます。

実践上のつまずきと対策

つまずき 対策
指摘が無限に増える High/Med/Low でランク付けさせ、Low は後回し
古い API を推奨してくる バージョン番号 + 公式ガイド URL を必ず添付
長文で読みにくい 400語以内など文字数制限を設ける
人間レビューが追いつかない チェックポイント(例: 1 日 1 回)でまとめて確認

⚠️ 適用限界とリスク

手法の限界:

  • 複雑なシステム設計: 1000行超のコードや多階層アーキテクチャではコンテキスト制約により効果が低下
  • ドメイン固有知識: 医療・金融など専門領域では不正確な指摘のリスクが高い
  • リアルタイム性: 最新のフレームワーク更新やセキュリティ情報は反映されない

リスク管理:

  • LLMの指摘を盲信せず、必ず人間による最終確認を実施
  • 重要な設計決定では従来の設計レビュープロセスと併用

6. まとめ

LLM は 完璧な設計 より 他人のコードレビュー を多く学習しています。
だからこそ、彼らを 「ジュニア設計者」ではなく「シニアレビュアー」 として使うと最大の成果を得られます。

小さく下書き → 激しく批判 → 再生成 → リリース


7. 参考文献


脚注
  1. Allamanis, M. et al.A Survey of Machine Learning for Big Code and Naturalness.” ACM Computing Surveys 51 (4), 2018. ↩︎

  2. Ouyang, L. et al.Training language models to follow instructions with human feedback.” arXiv:2203.02155, 2022. ↩︎

  3. Chen, A. et al.Self‑Refine: Iteratively Improving Answers With Self‑Feedback.” arXiv:2303.17651, 2023. ↩︎

  4. Shinn, N. et al.Reflexion: Language Agents with Advanced Learning Abilities.” arXiv:2303.11366, 2023. ↩︎

  5. Brown, S. “Just Enough Software Architecture & the C4 Model.” Leanpub, 2021. ↩︎

合同会社CAPH TECH

Discussion