🔍

AI時代のコードレビューはビジネスロジックに集中する - プロンプトレビューという新概念

に公開
AI
frontend
コードレビュー
プロンプトエンジニアリング
zennfes2025ai
idea

対象読者

  • AI時代のレビューに興味がある
  • フロントエンド/アプリの実装に携わっている
  • プロンプトレビューの話が気になる

1. フロントエンド/アプリPRレビューの変化

2つの観点から話したいのですが、まず1つ目はフロントエンド/アプリのPRレビューについてです。

個人的に、このAI時代においてPRレビューの着目点は大きく変わってくると考えていて、フロントエンド/アプリの実装を大まかに分けると、以下の3つの層に分類できます。

  • UI層：ユーザーインターフェースの実装
  • API接続層：バックエンドとの通信部分
  • ビジネスロジック層：ボタン押下から状態管理を経てAPI呼び出しに至るまでの処理

各層におけるAI活用とレビューの変化

UI層については、フロントエンド/アプリののUIはますますデザイナー領域に近づいていくと予想しています。

Figma Dev Mode MCPなどによって高精度な生成が可能になってきていて、実際にFlutterで試していて、Claude Codeと掛け合わせることで、UI自体(動き含む)もコードも良い精度を確認できています。(Figma側も構造化して綺麗に作り、良い出力が出るようにしてる前提)

つまり、将来的にはAIが生成したコードを実装者が確認するだけで、ある程度のレビューが完了している状態になるだろうと思っています。
※もちろん、実装者の一定の実力は必要かと思います。

API接続層は、バックエンドチームがAPI設計書を常に最新状態に保つ前提もありますが、AIでもかなりの精度で実装可能だなと最近試していて思います。

なので、こちらもある程度のレビューが完了している状態になるだろうと思っています。

しかしビジネスロジック層は違うと考えています。

例えばECアプリのカート機能を考えてみましょう。
「在庫切れ商品の扱い」「クーポン適用の優先順位」「配送料の複雑な計算」など、プロダクト固有の仕様が絡み合います。

ここはテストコードをしっかり書き、それを基にAIに実装してもらう形が良いと考えていて、この部分こそ人間の介入が不可欠です。

複雑な状態管理、条件分岐、異常系処理など、プロダクト要件に深く依存する部分はまだ人間の経験と洞察が必要だなと感じています。

したがって、今後のフロントエンド/アプリの開発では、ビジネスロジック層のテストコードを書くことに集中し、PRレビューは、ビジネスロジック層(テストコード含む)に集中していく形に変化していくだろうと考えています。

2. 「プロンプトレビュー」という新たな概念

次に、レビューといえばPRレビューを想像しがちですが、実は「プロンプトレビュー」というものも今後重要になってくるのではないかと思っています。

プロンプトレビューの課題と解決策

ただし、実装中の指示出しを他人に見られてレビューされるのは、AIとの壁打ちDMを覗かれるような感覚になってしまう人もいると思っています。
例えば、最近の#keep4oの話でもありましたが、AIでチャットする際に、感情的な拠り所にしてる人もいるかもしれないからです。

そこで、ここをAIにレビューしてもらう方が良いのではないかと考えています。
多くの人は使っていくうちに感覚的な評価でプロンプトを改善していくと思いますが、AIなら生成されたコードの品質や実行結果という事実ベースで評価できます。
これにより、個人のプロンプト力は着実に向上していくはずだと思います。

実際のプロンプト比較例

改善前のプロンプト

「ユーザー認証機能を実装してください」

改善後のプロンプト

「Firebase Authenticationを使用したメール/パスワード認証を実装。
要件：
- 入力バリデーション（メール形式、パスワード8文字以上）
- エラーハンドリング（ネットワークエラー、認証失敗）
- ローディング状態の管理（Riverpod使用）
成功基準：flutter test --coverageで80%以上のカバレッジ」

これは誰がみてもわかると思いますが、プロンプトの良い悪いはこのようなことを言います。

実験的なアプローチ

この課題に対して、現在私が構想しているアプローチを紹介します。

  1. 同じ要件に対して複数のプロンプトを作成

    • Claude Codeのカスタムコマンドに異なるアプローチのプロンプトを用意
    • 例：詳細指示型、テスト駆動型、段階的実装型など

  2. git worktreeで並列実験環境を構築

    # メインから実験用ブランチを複数作成
git worktree add ../exp-prompt-a main -b prompt-test-a
git worktree add ../exp-prompt-b main -b prompt-test-b

  3. 複数のAIセッションを同時実行

    • 各worktreeディレクトリでClaude Codeを起動
    • 同じゴール（例：「ユーザー認証機能の実装」）を異なるプロンプトで実行

  4. 評価したい観点
    理想的には、以下のような観点で客観的に評価できると良いなと考えています。

評価観点 評価内容 良いプロンプトの特徴 測定方法
🚀 効率性 実装完了までの対話ターン数 • 1-3ターンで完了
• 追加質問が最小限		 .claude配下のセッション情報から対話回数をカウント
🤖 自律性 手動修正なしでどこまで進められるか • エラーが発生しない
• 実行可能なコードを生成		 生成後の手動修正箇所数を記録
✨ 品質 生成されたコードの品質指標 • テストカバレッジ80%以上
• Lintエラー0件
• 型エラーなし		 flutter test --coverage
eslint、tsc --noEmit
🔄 再現性 同じプロンプトで安定した結果が得られるか • 3回実行して同等の結果
• 要件の逸脱がない		 同一プロンプトを複数回実行して差分を比較
📚 可読性 生成コードの保守性 • 適切なコメント
• 命名規則の遵守
• 関数の責務が明確		 コードレビューチェックリストで評価
🎯 要件充足 指定した要件の実装率 • 必須要件100%実装
• オプション要件の考慮		 要件定義書との照合

なお、.claude配下に保存されるセッション情報から対話パターンを分析し、どんなプロンプトが効果的だったか把握できれば面白そうです。

評価レベルの目安(実装するものの粒度によって変わったりします)

レベル 説明 効率性 自律性 品質 再現性
⭐⭐⭐ 優秀 そのまま本番投入可能 1-2ターン 修正不要 カバレッジ90%以上
エラー0		 差分なし
⭐⭐ 良好 軽微な修正で利用可能 3-4ターン 1-2箇所修正 カバレッジ70%以上
エラー1-2件		 軽微な差分
⭐ 要改善 大幅な修正が必要 5ターン以上 3箇所以上修正 カバレッジ50%未満
エラー3件以上		 大きな差分

プロンプト改善のヒント

改善ポイント Before（悪い例） After（良い例）
具体性 「ボタンを作って」 「Material3準拠のプライマリボタン、ローディング状態付き」
構造化 長文で要件を羅列 カテゴリ別に整理（基本要件/UI要件/品質要件）
制約明示 制約の記載なし 「既存のテーマシステム使用（lib/theme/配下参照）」
成功基準 曖昧な完了条件 「flutter analyze、flutter testをすべて成功させる」
技術スタック ライブラリ指定なし 「TypeScript、@radix-ui/react-dialog、tailwindCSS使用」

これらのヒントを実際に適用すると、どれほど違いが出るのか、具体例で見てみましょう。

プロンプトの良し悪しの例

例1: Flutterでボタンコンポーネントを作る場合

悪いプロンプト例

「ボタンを作って」

良いプロンプト例

Flutterでプライマリボタンコンポーネントを作成してください。

【基本要件】
- Material3デザインシステム準拠
- StatelessWidgetとしてクラス定義
- プロパティ：text(必須)、onPressed(必須)、isLoading(オプション)

【UI/UX要件】
- 押下時のripple effect実装
- disabled状態の考慮（onPressed == nullで判定）
- ローディング状態の表示（CircularProgressIndicator使用）
- アクセシビリティ対応（Semanticsウィジェット）

【実装要件】
- プロジェクトのテーマシステムを使用（lib/theme/配下を参照）
- 既存のカラースキームとテキストテーマを継承
- 定数コンストラクタで最適化
- エラーハンドリング（空文字のassert）

【品質保証】
- Widget testを考慮した実装
- flutter analyze、dart format、flutter testをすべて成功させる

例2: Reactでモーダルコンポーネントを作る場合

悪いプロンプト例

「モーダルを実装して」

良いプロンプト例

Reactでモーダルコンポーネントを実装してください。

【技術スタック】
- TypeScriptで型定義
- @radix-ui/react-dialogをベースに実装
- tailwindCSSでスタイリング（cn関数使用）

【Props設計】
- isOpen（必須）：表示状態
- onClose（必須）：閉じる処理
- title（必須）：モーダルタイトル
- children（必須）：コンテンツ
- size（オプション）：'sm' | 'md' | 'lg'

【機能要件】
- アニメーション：framer-motionまたはtailwindのtransition
- フォーカストラップとESCキー対応は@radix-uiに委譲
- カスタムフックuseModalで状態管理
- アクセシビリティ（aria-labelledby自動設定）

【開発環境】
- Storybookストーリー作成
- vitestとtesting-libraryでのテスト

これでも抽象的に書いていますが、それでもAIは「悪いプロンプト例」より高品質なコードを生成します。
最初は面倒に感じるかもしれませんが、結果的に開発速度は格段に向上します。

※これらをClaude Codeでいうカスタムコマンドに入れると毎回プロンプト入れなくて良くて楽なのでお勧めします

まだ構想段階ですが、プロンプトとその結果をペアで保存し、複数のアプローチを比較できる仕組みが作れたら、チーム全体のプロンプト力向上に繋がるのではないかと期待しています。

※もし既にこういった取り組みをされている方がいれば、ぜひアプローチを教えていただきたいです。

まとめ

要するに、AI時代のレビューには2つの側面があるんだろうなという話をしました。

  • コードレビュー：フロントエンド/アプリでは、ビジネスロジック層、特にテストに集中していく
  • プロンプトレビュー：AIによる客観的評価を通じてプロンプト力を向上させる新しいアプローチ

エンジニアの役割が「コードを書く人」から「AIと協働して問題を解決する人」へとシフトしていくんだろうなと考えていて、どんな未来になるかが楽しみです。

最後までお読みいただきありがとうございました。

Discussion