1
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

生成AIを活用したコードレビューのプロンプト例

Posted at

はじめに

エンジニアが嫌いなイベントの1つであるコードレビューで受けるダメージを減らすために、事前に生成AIにコードレビューをしてもらうことで指摘件数を減らし、HPを高く保とうというモットーの元、生成AIを活用してコードレビューをしてもらうプロンプトをご紹介します。

GitHub Copilot Chatを使用することを想定していますが、他のcursorなどでも応用可能です。

GitHub Copilot Chatの使い方についてはこちらを参照してください。

なぜ事前AI レビューが必要なのか?

コードレビューあるある

  • 「ここのロジック、もう少し整理できそうですね」← わかる
  • 「エラーハンドリングが不十分では?」← 確かに...
  • 「このパフォーマンス、大丈夫ですか?」← うっ...

こんな指摘を受ける前に、AIに先回りして教えてもらえたら最高ですよね。

生成AI活用のメリット

24時間365日、いつでもレビュー可能
一貫した観点でチェックしてくれる
複数の視点から同時に確認
ビジネス要件も考慮した包括的なレビュー

効果的なプロンプトの3要素

良いレビューを得るためには、AIに「何を」「なぜ」「どの観点で」見てほしいかを明確に伝える必要があります。

1. 📝 システム概要・背景情報

【システム概要】
Djangoで構築した在庫管理システム

【技術スタック】
- Python 3.13
- Django 5.0
- PostgreSQL

2. 🎯 ビジネス要件の明確化

【ビジネス要件】
- 商品の入出庫管理
- 在庫数がしきい値を下回った場合のアラート機能
- 複数倉庫間の在庫移動
- 月次・年次の在庫レポート生成

3. 🔍 具体的なレビュー観点

【レビュー観点】
1. ビジネスロジックの正確性
2. Django 5機能の活用
3. エラーハンドリング
4. 拡張性

実戦で使えるプロンプト集

🆕 パターン1: 新機能追加時

新機能を追加する際は、既存システムとの整合性やビジネスロジックの実装が重要になります。

【システム概要】
Django 5系で構築した在庫管理システム

【ビジネス要件】
- 商品の入出庫管理
- 在庫数がしきい値を下回った場合のアラート機能
- 複数倉庫間の在庫移動
- 月次・年次の在庫レポート生成

【今回の機能追加】
在庫自動発注機能の実装
- 在庫数が最小在庫数を下回った場合に自動発注
- 発注数は最大在庫数との差分
- 発注先は優先度順で選択
- 発注履歴の記録

【レビュー観点】
1. ビジネスロジックの正確性
   - 在庫計算の正確性
   - 発注タイミングと数量の妥当性
   - 優先度ロジックの実装
2. Django 5機能の活用
   - Field.db_commentでのビジネスルール文書化
   - 新しいConstraintsの活用
3. エラーハンドリング
   - 発注失敗時の処理
   - 在庫データの整合性保持
4. 拡張性
   - 新しい発注ルール追加時の影響

このプロンプトの良いところ:

  • ビジネス要件が具体的で理解しやすい 📋
  • Django 5固有の機能にも言及 ⚡
  • エラーケースまでしっかり考慮 🛡️

🔄 パターン2: 既存機能の仕様変更

仕様変更は特に注意が必要。既存の動作を壊さないか、新旧の要件が矛盾しないかをチェックしてもらいましょう。

【プロジェクト】Django 5系 ECサイト

【既存機能】
- 商品カタログ
- ショッピングカート
- 注文処理
- 決済処理

【今回の仕様変更】
注文処理の複雑化対応
1. 複数配送先への分割配送
2. 配送日時指定機能
3. ギフト包装オプション
4. 配送料計算の複雑化(重量・地域・時間帯別)

【ビジネスルール】
- 同一注文で最大3つの配送先
- 配送日は注文日から3営業日後以降
- ギフト包装は商品単位で選択可能
- 配送料は以下で計算:
  基本料金 + 重量料金 + 地域料金 + 時間指定料金

【確認したい点】
1. 複雑なビジネスロジックの実装
   - 配送料計算の正確性
   - 分割配送の処理ロジック
   - 営業日計算の実装
2. データ整合性
   - 注文分割時のデータ一貫性
   - 決済金額と配送料の整合性
3. Django 5のパフォーマンス機能活用
   - 複雑なクエリの最適化
   - バッチ処理の効率化
4. 例外処理
   - 配送先不正時の処理
   - 決済失敗時のロールバック

⚖️ パターン3: 法規制・コンプライアンスが絡む場合

金融系やヘルスケア系など、規制が厳しい分野では特に重要です。

【システム】Django 5系 個人向け資産管理システム

【既存機能】
- 口座管理
- 取引履歴管理
- 資産評価

【新機能要件】
自動投資アドバイス機能
1. ユーザーのリスク許容度評価
2. 年齢・収入に基づく投資比率提案
3. 市場動向を考慮した銘柄推奨
4. 定期的なポートフォリオリバランス提案

【ビジネスルール】
- リスク許容度:保守的(30%)、中程度(50%)、積極的(20%)
- 年齢別株式比率:(100 - 年齢)%を上限
- リバランス:四半期ごと、乖離5%以上で提案
- 金融商品取引法への準拠必須

【規制要件】
- 投資助言の記録保持(5年間)
- 顧客説明義務の履行
- 利益相反の開示

【レビュー観点】
1. 金融ロジックの正確性
   - リスク計算アルゴリズム
   - 投資比率計算の妥当性
   - リバランス判定ロジック
2. 規制準拠
   - ログ記録の完全性
   - データ保持期間の管理
   - 監査証跡の適切性
3. Django 5セキュリティ機能
   - 個人情報の暗号化
   - アクセス制御の実装
4. パフォーマンス
   - 大量データ処理の効率性
   - レスポンス時間の要件達成

Djangoユーザー必見!固有機能のチェックポイント

Djangoを使っているなら、新機能も活用していきたいですよね。

新機能の活用確認

【Django 5固有の確認点】
1. Field.db_comment属性の活用
2. 新しいFormField validationの使用
3. Simplified syntaxの活用({% load %}等)
4. psycopg 3対応の確認
5. セキュリティ強化機能の適用

パフォーマンス最適化

【パフォーマンス確認】
- 新しいQuerySet最適化機能の活用
- バッチ処理の効率化
- データベースクエリの最適化

段階的開発プロジェクトでの活用法

アジャイル開発では段階的にリリースすることが多いですよね。将来の拡張も考慮したレビューをしてもらいましょう。

【製品】Django 5系 プロジェクト管理SaaS

【現在の機能】
- プロジェクト作成・管理
- タスク管理
- チームメンバー管理
- 基本的なレポート機能

【機能拡張要件】
エンタープライズプラン向け高度機能
1. 複数プロジェクト横断ダッシュボード
2. 高度な工数管理・予実管理
3. カスタムワークフロー機能
4. 外部システム連携API

【段階的リリース計画】
Phase 1: ダッシュボード機能(今回)
Phase 2: 工数管理機能
Phase 3: ワークフロー機能
Phase 4: 外部連携機能

【レビュー観点】
1. スケーラビリティ
   - 大量データ処理への対応
   - マルチテナント設計
   - 将来拡張への配慮
2. ビジネスロジック
   - 複雑な権限制御の実装
   - 集計処理の正確性
3. Django 5最適化
   - クエリパフォーマンス
   - 新機能による効率化
4. 段階的展開への配慮
   - 機能フラグの実装
   - 後方互換性の維持
   - デプロイメント戦略

プロンプト作成の5つのコツ

1. 📊 具体的な数値で勝負

👍 良い例:

- 月間処理件数:100万件
- レスポンス時間:3秒以内
- 同時接続数:1,000ユーザー

👎 悪い例:

- 大量のデータ処理
- 高速なレスポンス
- 多数のユーザー

AIも人間と同じで、抽象的な表現より具体的な数値の方が理解しやすそうです。

2. 🚨 例外パターンもお忘れなく

【例外パターン】
- 通常時:1日1,000件の処理
- 繁忙期:1日10,000件の処理
- 障害時:手動切り替え機能の動作確認

3. 🔧 運用・保守の視点も重要

【運用面の確認】
- ログ出力の適切性
- 監視項目の設定
- トラブルシューティングのしやすさ
- 管理者向け機能の使いやすさ

4. 📋 法規制・コンプライアンス要件

【コンプライアンス要件】
- 個人情報保護法への準拠
- データ保存期間の管理
- 監査証跡の記録
- アクセスログの保持

5. 🔮 将来拡張を見越した設計

現在の要件だけでなく、将来の拡張計画も共有すると、より良い設計提案を得られます。

よくあるNG例と改善パターン

❌ 失敗パターン1: 抽象的すぎる要件

悪い例:

このコードをレビューしてください。品質を向上させたいです。

✅ 改善例:

【システム】在庫管理システム
【要件】在庫自動発注機能
【ビジネスルール】最小在庫数を下回った場合に自動発注
【確認点】計算ロジックの正確性、エラーハンドリング

❌ 失敗パターン2: 技術要件のみに特化

悪い例:

パフォーマンスとセキュリティをチェックしてください。

✅ 改善例:

【ビジネス要件】金融取引システム
【規制要件】金融商品取引法準拠
【パフォーマンス要件】1秒以内のレスポンス
【セキュリティ要件】個人情報の暗号化

❌ 失敗パターン3: 将来拡張の考慮不足

悪い例:

現在の機能だけをレビューしてください。

✅ 改善例:

【現在の要件】基本的なユーザー管理
【将来の拡張予定】多要素認証、SSO連携
【確認点】拡張時のコード変更量最小化

GitHub Copilot Chatでの実際の使い方

  1. VS Codeでファイルを開く
  2. Copilot Chatを開く
  3. プロンプトをコピペして、コンテキストに対象のコードを追加
  4. 送信して結果を確認
  5. フィードバックに基づいてコード修正

チーム内でプロンプトのテンプレートを共有しておくと、みんなで品質の高いレビューを受けられますよ!

まとめ

プロンプト設計の5つのポイント:

  1. システム概要を具体的に説明 📝
  2. ビジネス要件を詳細に記述 🎯
  3. 技術的制約を明示 ⚙️
  4. 例外パターンも考慮 🚨
  5. 将来拡張の視点を含める 🔮

継続的な改善も大切:

  • レビュー結果を分析してプロンプトを改善 🔄
  • チーム内でベストプラクティスを共有 🤝
  • プロジェクト特性に応じてテンプレート化 📋

あとがき

生成AIで提案していたいた記事のタイトルは生成AIでコードレビューの指摘を激減させるプロンプト術【GitHub Copilot Chat対応】 です

参考文献

1
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?