日本の開発現場における最強AIプロンプトチートシート④ - 設計・実装・単体テスト・コードレビュー

## 基本設計

### システム方式設計プロンプト

```
以下の要件に基づいてシステム方式設計を提案してください：

【プロジェクト概要】
{プロジェクトの目的と概要}

【機能要件】
{実現すべき主な機能のリスト}

【非機能要件】
- パフォーマンス：{例：応答時間、同時接続数など}
- 拡張性：{将来的な拡張への対応}
- セキュリティ：{必要なセキュリティレベル}
- 可用性：{必要な稼働率など}

【技術的制約】
{予算、技術スタック、既存システムとの統合など}

【ユーザー規模】
{想定ユーザー数、トラフィック量など}

【出力形式】
- システム概要
- システム構成図（テキストで説明）
- 主要なコンポーネントとその役割
- データフロー概要
- 外部システム連携方針
- セキュリティ設計方針
- 可用性・拡張性の確保方針
- 移行方針
- 運用保守方針
```

### システム方式設計レビュープロンプト

```
以下のシステム方式設計をレビューしてください：

【システム方式設計書】
{システム方式設計書の内容}

【プロジェクト情報】
{プロジェクトの目的、要件}

【レビューの観点】
- 要件充足度
- アーキテクチャの妥当性
- 拡張性・保守性
- セキュリティ対策の十分さ
- 技術的な実現可能性

【出力形式】
- 設計の強み
- 懸念点・弱点
- アーキテクチャ上のリスク
- 非機能要件への対応不足点
- セキュリティ上の懸念点
- 改善のための具体的な提案
```

### データベース基本設計プロンプト

```
以下の要件に基づいてデータベース基本設計を行ってください：

【プロジェクト概要】
{プロジェクトの目的と概要}

【業務要件】
{主要な業務フローとデータの流れ}

【データ要件】
{主要なエンティティと属性}

【非機能要件】
- パフォーマンス要件：{トランザクション数、レスポンス要件など}
- 可用性要件：{稼働率、バックアップ要件など}
- スケーラビリティ要件：{データ増加見込みなど}

【制約条件】
{使用可能なDBMS、既存システムとの連携など}

【出力形式】
- データベース概要
- ERモデル（テキストで説明）
- 主要エンティティの定義
- リレーションシップの定義
- 正規化方針
- インデックス方針
- パーティション方針（必要な場合）
- バックアップ・リカバリ方針
- データ移行方針
```

### データベース基本設計レビュープロンプト

```
以下のデータベース基本設計をレビューしてください：

【データベース基本設計書】
{データベース基本設計書の内容}

【プロジェクト情報】
{プロジェクトの目的、データ要件}

【レビューの観点】
- エンティティの網羅性
- 正規化の適切さ
- リレーションシップの妥当性
- 拡張性・保守性
- パフォーマンス考慮点

【出力形式】
- 設計の強み
- 懸念点・弱点
- データモデルの問題点
- パフォーマンス上の潜在的な問題
- 拡張性における課題
- 改善のための具体的な提案
```

### アプリケーション基本設計プロンプト

```
以下の要件に基づいてアプリケーション基本設計を行ってください：

【プロジェクト概要】
{プロジェクトの目的と概要}

【機能要件】
{実現すべき主な機能のリスト}

【非機能要件】
{性能、セキュリティなどの要件}

【技術スタック】
{使用予定の言語、フレームワークなど}

【出力形式】
- アプリケーション構造概要
- レイヤー構成
- 主要コンポーネントとその役割
- クラス/モジュール設計方針
- 画面遷移概要
- データアクセス方式
- エラー処理方針
- ログ出力方針
- セキュリティ対策
- テスト方針
```

### アプリケーション基本設計レビュープロンプト

```
以下のアプリケーション基本設計をレビューしてください：

【アプリケーション基本設計書】
{アプリケーション基本設計書の内容}

【プロジェクト情報】
{プロジェクトの目的、要件}

【レビューの観点】
- 要件充足度
- アーキテクチャの妥当性
- コンポーネント分割の適切さ
- 拡張性・保守性
- セキュリティ対策の十分さ

【出力形式】
- 設計の強み
- 懸念点・弱点
- アーキテクチャ上のリスク
- 責務分割の問題点
- 拡張性・保守性の課題
- 改善のための具体的な提案
```

## 詳細設計

### 画面設計プロンプト

```
以下の要件に基づいて画面設計を行ってください：

【機能概要】
{この画面で実現する機能の説明}

【ユーザー層】
{この画面を利用するユーザーの特性}

【業務フロー上の位置づけ】
{業務の流れの中でのこの画面の位置づけ}

【入出力項目】
{画面で扱う主な入出力項目}

【画面遷移】
{関連する画面との遷移関係}

【非機能要件】
{レスポンス時間、対応デバイスなど}

【出力形式】
- 画面レイアウト（テキストで説明）
- UI部品（入力フィールド、ボタン等）とその配置
- 入力項目の詳細（型、桁数、入力規則など）
- 表示項目の詳細（表示形式、条件など）
- 画面アクション（ボタン押下時の動作など）
- バリデーションルール
- エラーメッセージ
- 画面遷移図
```

### 画面設計レビュープロンプト

```
以下の画面設計をレビューしてください：

【画面設計書】
{画面設計書の内容}

【機能要件】
{この画面が満たすべき機能要件}

【ユーザビリティ要件】
{使いやすさに関する要件}

【レビューの観点】
- 要件充足度
- ユーザビリティ
- 画面遷移の自然さ
- 入力検証の適切さ
- UIガイドラインとの整合性

【出力形式】
- 設計の強み
- 懸念点・弱点
- ユーザビリティ上の問題点
- 機能的な不足点
- 改善のための具体的な提案
```

### ビジネスロジック処理設計プロンプト

```
以下の要件に基づいてビジネスロジック処理設計を行ってください：

【処理概要】
{実現するビジネスロジックの概要}

【機能要件】
{処理が満たすべき機能要件}

【入出力情報】
{処理の入力と出力}

【関連する業務ルール】
{処理に関連するビジネスルール}

【技術的制約】
{実装言語、フレームワークなどの制約}

【出力形式】
- 処理フロー（テキストで説明）
- データフロー
- 主要なロジックの説明
- 入力チェック仕様
- エラーハンドリング
- パフォーマンス考慮点
- トランザクション範囲
- 外部システム連携方法
```

### ビジネスロジック処理設計レビュープロンプト

```
以下のビジネスロジック処理設計をレビューしてください：

【ビジネスロジック処理設計書】
{ビジネスロジック処理設計書の内容}

【機能要件】
{この処理が満たすべき機能要件}

【レビューの観点】
- 要件充足度
- 処理フローの論理性
- エラーハンドリングの適切さ
- パフォーマンス考慮点
- セキュリティ考慮点

【出力形式】
- 設計の強み
- 懸念点・弱点
- ロジック上の問題点
- エラーハンドリングの不足点
- パフォーマンス上の懸念
- 改善のための具体的な提案
```

### バッチ処理設計プロンプト

```
以下の要件に基づいてバッチ処理設計を行ってください：

【処理概要】
{バッチ処理の目的と概要}

【処理タイミング】
{実行タイミング、頻度}

【処理量】
{処理対象データ量の見込み}

【処理順序】
{他のバッチとの関連、順序制約}

【データソース/シンク】
{入出力データの情報}

【出力形式】
- バッチ処理の全体フロー
- 処理ステップの詳細
- データの抽出・加工・更新ロジック
- エラーハンドリング方法
- リカバリ方法
- 並列処理の可能性
- ログ出力仕様
- 性能要件と対策
- 監視・運用方法
```

### バッチ処理設計レビュープロンプト

```
以下のバッチ処理設計をレビューしてください：

【バッチ処理設計書】
{バッチ処理設計書の内容}

【処理要件】
{このバッチ処理が満たすべき要件}

【レビューの観点】
- 要件充足度
- 処理効率
- エラーハンドリングの適切さ
- リカバリの容易さ
- 運用性

【出力形式】
- 設計の強み
- 懸念点・弱点
- 処理効率上の問題点
- エラーハンドリングの不足点
- 運用上の懸念
- 改善のための具体的な提案
```

### テーブル設計プロンプト

```
以下の要件に基づいてテーブル設計を行ってください：

【データモデル】
{ER図または概念データモデルの情報}

【エンティティ情報】
{各エンティティの属性と関係性}

【データボリューム】
{想定レコード数、増加率など}

【アクセス特性】
{参照頻度、更新頻度などの特性}

【業務ルール】
{データに関する制約やルール}

【出力形式】
- テーブル一覧
- 各テーブルの定義（テーブル名、説明、物理名）
- 各カラムの定義（カラム名、データ型、桁数、NULL可否、デフォルト値、説明）
- 主キー、外部キーの定義
- インデックスの定義
- 制約の定義
- 正規化レベル
- パーティション設計（必要な場合）
```

### テーブル設計レビュープロンプト

```
以下のテーブル設計をレビューしてください：

【テーブル設計書】
{テーブル設計書の内容}

【データモデル】
{関連するER図または概念データモデル}

【レビューの観点】
- 論理データモデルとの整合性
- 正規化の適切さ
- 命名規則の一貫性
- インデックス設計の適切さ
- パフォーマンス考慮点

【出力形式】
- 設計の強み
- 懸念点・弱点
- テーブル構造上の問題点
- パフォーマンス上の潜在的な問題
- 拡張性における課題
- 改善のための具体的な提案
```

### 帳票設計プロンプト

```
以下の要件に基づいて帳票設計を行ってください：

【帳票の目的】
{この帳票の利用目的と概要}

【出力タイミング】
{帳票出力のタイミングと頻度}

【利用者】
{帳票の利用者と用途}

【掲載項目】
{帳票に掲載すべき項目}

【データソース】
{帳票データの取得元}

【出力形式】
- 帳票レイアウト（テキストで説明）
- 帳票のサイズ、向き
- 帳票ヘッダ・フッタの内容
- 掲載項目の詳細（表示形式、桁数、位置など）
- 集計項目の計算方法
- 改ページ条件
- 出力条件・抽出条件
- 出力形式（PDF、Excel、CSVなど）
- 帳票IDやバージョン管理方法
```

### 帳票設計レビュープロンプト

```
以下の帳票設計をレビューしてください：

【帳票設計書】
{帳票設計書の内容}

【帳票要件】
{この帳票が満たすべき要件}

【レビューの観点】
- 要件充足度
- レイアウトの適切さ
- 掲載情報の十分さ
- 視認性・可読性
- 法的要件の充足（該当する場合）

【出力形式】
- 設計の強み
- 懸念点・弱点
- レイアウト上の問題点
- 掲載情報の不足点
- 視認性・可読性の問題
- 改善のための具体的な提案
```

### API設計プロンプト

```
以下の要件に基づいてAPI設計を行ってください：

【API概要】
{APIの目的と概要}

【利用ケース】
{APIの主な利用シーン}

【機能要件】
{APIが提供すべき機能}

【非機能要件】
{パフォーマンス、セキュリティなどの要件}

【技術的制約】
{使用すべき技術、プロトコルなど}

【出力形式】
- API設計の基本方針（REST、GraphQLなど）
- エンドポイント一覧
- 各エンドポイントの詳細
  - リソースパス
  - HTTP メソッド
  - リクエストパラメータ
  - リクエストボディ
  - レスポンス形式
  - ステータスコード
- 認証・認可方式
- エラーハンドリング方式
- レート制限
- バージョニング方針
- API ドキュメント形式
```

### API設計レビュープロンプト

```
以下のAPI設計をレビューしてください：

【API設計書】
{API設計書の内容}

【API要件】
{このAPIが満たすべき要件}

【レビューの観点】
- 要件充足度
- REST原則との整合性（RESTの場合）
- リソース設計の適切さ
- セキュリティ対策の十分さ
- エラーハンドリングの適切さ

【出力形式】
- 設計の強み
- 懸念点・弱点
- API設計上の問題点
- セキュリティ上の懸念
- 拡張性・互換性における課題
- 改善のための具体的な提案
```

## 方式設計

### バッチ方式設計プロンプト

```
以下の要件に基づいてバッチ方式設計を行ってください：

【システム概要】
{バッチ処理を行うシステムの概要}

【バッチ処理要件】
{実行すべきバッチ処理の種類と目的}

【非機能要件】
- 処理時間要件：{処理完了までの制約}
- データ量：{処理対象データの規模}
- リソース制約：{CPUやメモリの制約}

【業務制約】
{業務上の実行タイミング制約など}

【出力形式】
- バッチ方式の概要
- バッチジョブの構成
- スケジューリング方式
- ジョブ間の依存関係制御
- リソース制御方式
- 並列処理方式
- エラーハンドリング方式
- リスタート・リカバリ方式
- ログ・監視方式
- 性能対策
- 運用方法
```

### バッチ方式設計レビュープロンプト

```
以下のバッチ方式設計をレビューしてください：

【バッチ方式設計書】
{バッチ方式設計書の内容}

【バッチ処理要件】
{このバッチ処理が満たすべき要件}

【レビューの観点】
- 要件充足度
- 処理方式の適切さ
- エラーハンドリングの十分さ
- リカバリ方式の堅牢さ
- 運用性・保守性

【出力形式】
- 設計の強み
- 懸念点・弱点
- 処理方式における課題
- エラー発生時のリスク
- 処理時間に関する懸念
- 改善のための具体的な提案
```

### インターフェース方式設計プロンプト

```
以下の要件に基づいてインターフェース方式設計を行ってください：

【システム概要】
{連携対象システムと連携目的}

【連携要件】
{連携するデータやトランザクションの内容}

【非機能要件】
- 性能要件：{レスポンス時間、スループットなど}
- 可用性要件：{連携の信頼性など}
- セキュリティ要件：{データ保護など}

【制約条件】
{既存インターフェースとの互換性、技術的制約など}

【出力形式】
- インターフェース方式の概要
- 連携方式（同期/非同期、プッシュ/プルなど）
- 通信プロトコル
- メッセージフォーマット
- エラーハンドリング方式
- リトライ・リカバリ方式
- セキュリティ対策（認証、暗号化など）
- 監視・追跡方法
- 性能対策
- インターフェース仕様書の例
```

### インターフェース方式設計レビュープロンプト

```
以下のインターフェース方式設計をレビューしてください：

【インターフェース方式設計書】
{インターフェース方式設計書の内容}

【連携要件】
{このインターフェースが満たすべき要件}

【レビューの観点】
- 要件充足度
- 連携方式の適切さ
- エラーハンドリングの十分さ
- セキュリティ対策の十分さ
- 拡張性・保守性

【出力形式】
- 設計の強み
- 懸念点・弱点
- 連携方式における課題
- エラー発生時のリスク
- セキュリティ上の懸念
- 改善のための具体的な提案
```

### ジョブ方式設計プロンプト

```
以下の要件に基づいてジョブ方式設計を行ってください：

【システム概要】
{ジョブ処理を行うシステムの概要}

【ジョブ要件】
{実行すべきジョブの種類と目的}

【非機能要件】
- 実行頻度：{定期実行、イベント駆動など}
- 優先度：{ジョブの優先順位}
- リソース要件：{必要なCPU、メモリなど}

【システム制約】
{利用可能なジョブスケジューラ、クラウドサービスなど}

【出力形式】
- ジョブ方式の概要
- ジョブの分類と構成
- ジョブスケジューリング方式
- ジョブ間の連携方式
- リソース割り当て方式
- 優先制御方式
- 障害時の挙動
- 監視・通知方式
- ログ管理方式
- 運用管理方法
```

### ジョブ方式設計レビュープロンプト

```
以下のジョブ方式設計をレビューしてください：

【ジョブ方式設計書】
{ジョブ方式設計書の内容}

【ジョブ要件】
{このジョブ処理が満たすべき要件}

【レビューの観点】
- 要件充足度
- スケジューリング方式の適切さ
- リソース制御の適切さ
- 障害対策の十分さ
- 運用性・監視性

【出力形式】
- 設計の強み
- 懸念点・弱点
- スケジューリングにおける課題
- リソース競合のリスク
- 監視・運用上の懸念
- 改善のための具体的な提案
```

## データ移行設計

### データ移行設計プロンプト

```
以下の要件に基づいてデータ移行設計を行ってください：

【プロジェクト概要】
{プロジェクトの目的と概要}

【移行元システム情報】
{現行システムのデータベース構成、データ量など}

【移行先システム情報】
{新システムのデータベース構成}

【移行要件】
{移行対象データ、データ変換要件、整合性要件など}

【制約条件】
{移行期間、システム停止可能時間など}

【出力形式】
- データ移行の全体方針
- 移行対象データの一覧と優先順位
- データマッピング（移行元→移行先）
- データクレンジング方針
- データ変換ルール
- 移行ツール・スクリプトの設計
- 移行手順と実行計画
- 検証方法
- リスクと対策
- 切り戻し計画
```

### データ移行設計レビュープロンプト

```
以下のデータ移行設計をレビューしてください：

【データ移行設計書】
{データ移行設計書の内容}

【移行要件】
{データ移行が満たすべき要件}

【レビューの観点】
- 要件充足度
- データマッピングの正確性
- データ変換ルールの妥当性
- 移行手順の実現可能性
- リスク対策の十分さ

【出力形式】
- 設計の強み
- 懸念点・弱点
- データマッピング上の問題点
- 変換ルールの不明確な点
- 検証方法の不足点
- 見落とされている可能性のあるリスク
- 改善のための具体的な提案
```

## 監視設計

### システム監視設計プロンプト

```
以下の要件に基づいてシステム監視設計を行ってください：

【システム概要】
{監視対象システムの構成と概要}

【監視要件】
{監視すべき項目や状態}

【非機能要件】
{可用性要件、性能要件など}

【運用体制】
{運用担当者の体制、スキルレベルなど}

【出力形式】
- 監視の全体方針
- 監視対象一覧（サーバー、ネットワーク、アプリケーションなど）
- 監視項目と閾値
- アラート定義（重要度、通知先など）
- 監視ツール選定方針
- 監視インフラ構成
- ログ収集・分析方針
- レポーティング方法
- インシデント対応フロー
- エスカレーションルール
```

### システム監視設計レビュープロンプト

```
以下のシステム監視設計をレビューしてください：

【システム監視設計書】
{システム監視設計書の内容}

【監視要件】
{システム監視が満たすべき要件}

【レビューの観点】
- 要件充足度
- 監視項目の網羅性
- 閾値設定の妥当性
- アラート設計の適切さ
- 運用性

【出力形式】
- 設計の強み
- 懸念点・弱点
- 監視の死角となる可能性のある領域
- 過剰な監視による運用負荷
- 閾値設定の問題点
- アラート設計の改善点
- 改善のための具体的な提案
```

## コード作成・修正

### 新規機能実装のプロンプト

```
次の要件に基づいてコードを作成してください：

【機能概要】
{機能の簡潔な説明}

【技術スタック】
- 言語：{プログラミング言語}
- フレームワーク：{使用フレームワーク}
- データベース：{使用DB}

【詳細仕様】
{詳細な仕様。入力値、出力値、処理フローなど}

【制約条件】
- {パフォーマンス要件}
- {セキュリティ要件}
- {コーディング規約}

【出力形式】
- 実装コード（コメント付き）
- 関数/メソッドの使用例
- 注意点や考慮事項
```

### 新規機能実装コードレビュープロンプト

```
以下の新規機能実装コードをレビューしてください：

【コード】
{コードを貼り付け}

【機能要件】
{このコードが実装すべき機能}

【技術スタック】
{使用言語、フレームワークなど}

【レビューの観点】
- 機能要件の充足度
- コーディング規約への準拠
- セキュリティリスク
- パフォーマンス
- テスト容易性
- 可読性・保守性

【出力形式】
- コードの強み
- 懸念点・弱点
- バグの可能性がある箇所
- セキュリティ上の問題点
- パフォーマンス上の懸念
- 改善のための具体的な提案（コード例付き）
```

### コードリファクタリングのプロンプト

```
以下のコードをリファクタリングしてください：

【現在のコード】
{コードを貼り付け}

【リファクタリングの目的】
{パフォーマンス向上、可読性向上、保守性向上など具体的な目的}

【プロジェクトのコーディング規約】
{具体的な規約があれば記載}

【制約条件】
- 既存の機能や振る舞いを変更しないこと
- {その他の制約}

【出力形式】
- リファクタリング後のコード
- 変更点の説明
- 改善された点のメリット
```

### リファクタリングコードレビュープロンプト

```
以下のリファクタリングコードをレビューしてください：

【リファクタリング前のコード】
{元のコードを貼り付け}

【リファクタリング後のコード】
{リファクタリングされたコードを貼り付け}

【リファクタリングの目的】
{パフォーマンス向上、可読性向上、保守性向上など}

【レビューの観点】
- リファクタリング目的の達成度
- 機能的同一性の維持
- コーディング規約への準拠
- 副作用のリスク
- さらなる改善の可能性

【出力形式】
- リファクタリングの強み
- 懸念点・弱点
- 機能に影響を与える可能性のある変更点
- パフォーマンスへの影響
- さらなる改善のための提案
```

## 単体テスト

### ユニットテスト作成プロンプト

```
以下のコードに対するユニットテストを作成してください：

【テスト対象コード】
{コードを貼り付け}

【テストフレームワーク】
{使用するテストフレームワーク（JUnit, pytest, Jestなど）}

【テスト要件】
- コードカバレッジ目標：{目標値}
- テストすべき特殊なケース：{エッジケースなど}
- モック化すべき外部依存：{API、DBなど}

【プロジェクト構成】
{関連するファイル構造やクラス構成}

【出力形式】
- テストコード（コメント付き）
- 各テストケースの説明
- テスト実行方法
- テストカバレッジの確認方法
```

### ユニットテストレビュープロンプト

```
以下のユニットテストコードをレビューしてください：

【テストコード】
{テストコードを貼り付け}

【テスト対象コード】
{テスト対象のコードを貼り付け}

【テスト要件】
{このテストが満たすべき要件}

【レビューの観点】
- テストケースの網羅性
- エッジケースの考慮
- テストの独立性
- モック・スタブの適切さ
- テストコードの保守性

【出力形式】
- テストの強み
- 懸念点・弱点
- 不足しているテストケース
- 誤ったテスト手法
- 改善のための具体的な提案
```

## デバッグ・エラー解決

### エラー解析プロンプト

```
以下のエラー情報を解析し、問題の原因と解決策を提案してください：

【エラーメッセージ】
{エラーメッセージの全文}

【発生状況】
{エラーが発生した状況や再現手順}

【関連コード】
{エラーに関連すると思われるコード}

【環境情報】
{OS、言語バージョン、フレームワークバージョンなど}

【これまでの調査内容】
{すでに試した対処法や調査結果}

【出力形式】
- エラーの種類と概要
- 考えられる原因（複数可能性がある場合は優先度順）
- 推奨される解決策（各原因に対応）
- 検証方法
- 今後同様のエラーを防ぐための提案
```

### パフォーマンス問題解析プロンプト

```
以下のパフォーマンス問題について解析し、改善策を提案してください：

【問題の概要】
{パフォーマンス問題の症状}

【計測結果】
{レスポンス時間、CPU使用率、メモリ使用量など}

【関連コード】
{問題箇所と思われるコード}

【システム構成】
{アーキテクチャ、インフラ構成など}

【環境情報】
{ハードウェア仕様、ミドルウェアバージョンなど}

【出力形式】
- 問題の分析
- ボトルネックの特定
- 改善のための短期的対策
- 長期的な改善案
- 効果の予測と検証方法
```

### デバッグ戦略立案プロンプト

```
以下の不具合に対するデバッグ戦略を立案してください：

【不具合の概要】
{発生している不具合の症状}

【再現性】
{再現頻度や条件}

【システム情報】
{アーキテクチャ、モジュール構成など}

【利用可能なツール】
{デバッガ、ログ分析ツールなど}

【制約条件】
{デバッグに関する制約（本番環境でのログ取得制限など）}

【出力形式】
- デバッグの進め方
- 情報収集方法
- 仮説の立て方
- ログ取得・分析の方針
- 効率的なデバッグのためのコツ
- 作業の優先順位
```

## コードレビュー

### コードレビュー実施プロンプト

```
以下のコードをレビューし、フィードバックを提供してください：

【レビュー対象コード】
{コードを貼り付け}

【コードの目的】
{このコードが実現すべき機能や目的}

【プロジェクトのコーディング規約】
{適用されるコーディング規約}

【重点レビュー項目】
{特に重点的にレビューしてほしい観点}

【出力形式】
- 全体的な印象
- 設計上の問題点
- コーディング規約違反
- セキュリティリスク
- パフォーマンス上の懸念
- テスト容易性
- 具体的な改善提案（コード例を含む）
- 良い実装部分への評価
```

### コードレビューフィードバック対応プロンプト

```
以下のコードレビューフィードバックに対する対応策を提案してください：

【レビュー対象コード】
{コードを貼り付け}

【レビューフィードバック】
{受け取ったレビューコメント}

【コンテキスト】
{プロジェクトの背景情報やコードの目的}

【制約条件】
{対応する上での制約事項}

【出力形式】
- 各フィードバック項目への対応方針
- 修正後のコード例
- 修正による影響範囲
- 検討したが採用しなかった代替案（ある場合）
- フィードバックへの質問（不明点がある場合）
```

### コードレビューチェックリスト作成プロンプト

```
以下の情報に基づいてコードレビューチェックリストを作成してください：

【プロジェクト情報】
{プロジェクトの種類、言語、フレームワークなど}

【品質基準】
{プロジェクトで重視している品質基準}

【過去の不具合傾向】
{よくある不具合や見落としがちな点}

【レビュー対象】
{新規機能、バグ修正、リファクタリングなど}

【出力形式】
- 汎用的なチェック項目
  - コード規約・スタイル
  - セキュリティ
  - パフォーマンス
  - テスト
- 言語/フレームワーク固有のチェック項目
- プロジェクト固有のチェック項目
- 対象別チェックリスト（新規機能、バグ修正など）
- 優先度の高いチェック項目
```