はじめに
「Webアプリの作成をAIに手伝ってもらいたいけど、何から始めればいいかわからない」と思ったことはありませんか？
従来の開発では、要件定義から実装まで全てを手作業で行う必要がありました。しかし、AI駆動開発では、適切なプロンプトを書くことで、AIが設計書の作成からコード実装まで支援してくれます。
この記事では、初心者にも分かりやすく、AI駆動開発の6段階フローについて解説していきます。
AI駆動開発を体験することで、開発効率の向上と新しい開発手法を身につけられます。
AI駆動開発とは？
AI駆動開発とは、AIアシスタント（Claude、ChatGPT等）を活用して、ソフトウェア開発の各工程を効率化する開発手法です。従来の開発プロセスをAIが支援することで、開発時間の短縮と品質向上を実現します。
AI駆動開発のメリット
- 開発速度の向上: 設計書作成からコード実装まで大幅な時間短縮
- 学習効果: AIとの対話を通じて、新しい技術や設計パターンを学習
- デバッグ効率の向上: エラーの原因特定や解決策の提案をAIが支援
AI駆動開発の6段階フロー
AI駆動開発では、以下の6段階でプロジェクトを進めることで、効率的で品質の高い開発を実現します。
フロー概要
1. 📋 要件定義フェーズ
2. 🏗️ 設計フェーズ
3. 💻 実装フェーズ
4. 🔧 テストフェーズ
5. 🚀 デプロイフェーズ
6. 🔄 レビュー・検証フェーズ
各段階の役割
- AI: コード生成、テスト作成、ドキュメント生成、技術的実装
- 人間: 要件定義の修正・加筆、設計判断、品質確認、ビジネス判断
- 協働: 各段階でAIと人間が適切に役割分担し、相互補完する
プロジェクト構造
AI駆動開発では、プロジェクトの構造を明確にすることで、AIが効率的に支援できます。
プロジェクト構造の説明
.
├── README.md # プロジェクトの概要と使い方
├── CONTRIBUTING.md # 開発におけるルール・守るべき手順
├── .cursor/ # Cursor IDE設定
│ └── rules/
│ └── spec.mdc # AI駆動開発の6段階フロー定義
├── app/ # アプリケーション本体
├── design/ # 設計・指針ドキュメント
├── docs/ # 成果物ドキュメント
├── instructions/ # AIへの指示・局所的な知識
├── infra/ # AWS CDK（Infrastructure as Code）
└── tests/ # テストケース
各ディレクトリの役割
-
.cursor/rules/: Cursorのプロジェクト固有ルール管理ディレクトリ -
app/: フロントエンド・バックエンドのアプリケーションコード -
infra/: AWS CDKによるインフラストラクチャコード -
design/: 要件定義書、基本設計書、詳細設計書 -
docs/: 成果物ドキュメント、運用マニュアル -
instructions/: AIへの指示プロンプト、開発ガイドライン -
tests/: テストケース
6段階フローの定義と実行ルール
AI駆動開発の6段階フローとは
AI駆動開発では、プロジェクトを6つの段階に分けて進めることで、効率的で品質の高い開発を実現します。この6段階フローは、AIと人間が協働する際の明確な指針となります。
各段階の関係性
各フェーズは独立しているのではなく、相互に関連しています。
- 要件定義で明確にした内容が設計の基盤となる
- 設計で決めた仕様に基づいて実装を進める
- 実装したコードをテストする
- デプロイで環境に展開し、レビュー・検証で継続的に改善する
この流れを意識することで、各段階で適切な判断ができ、プロジェクト全体の品質を保てます。
.cursor/rulesディレクトリの役割
.cursor/rulesディレクトリは、Cursorのプロジェクト固有ルールを定義するためのディレクトリです。このディレクトリに配置されたファイルは、AIアシスタントがプロジェクトでどのように動作すべきかを定義する重要な設定ファイルとなります。
.cursor/rulesの役割
- プロジェクト固有のルール定義: そのプロジェクトに特化した開発ルールやガイドラインを設定
- AIアシスタントの動作制御: AIがコード生成や提案する際の基準や制約を明記
- 品質基準の設定: コード品質、テスト品質、セキュリティの基準を定義
.cursor/rulesの実践的な活用
- プロジェクト開始時: このファイルを読み込んでから開発を開始
- 段階進行時: 各段階の成果物を確認してから次に進む
- 品質管理: 定義された基準に従って品質をチェック
- チーム協働: AIと人間の役割分担を明確にして効率的な開発を実現
spec.mdcファイルの詳細
.cursor/rules/spec.mdcファイルは、AI駆動開発の6段階フローを定義した重要な設定ファイルです。このファイルにより、AIアシスタントが一貫した開発プロセスに従って作業を進めることができます。
📄 .cursor/rules/spec.mdc の内容を表示
---
alwaysApply: true
---
# AI駆動開発の6段階フロー
## 🚀 AI駆動開発フロー開始
**現在、AI駆動開発の6段階フローが適用されています。**
このルールは以下の6段階でプロジェクトを進めます：
1. 📋 要件定義フェーズ
2. 🏗️ 設計フェーズ
3. 💻 実装フェーズ
4. 🔧 テストフェーズ
5. 🚀 デプロイフェーズ
6. 🔄 レビュー・検証フェーズ
各段階では明確な成果物と確認ポイントを設定し、品質の高い開発を実現します。
## 基本原則
### AI駆動開発
- **AI**: コード生成、テスト作成、ドキュメント生成、技術的実装
- **人間**: 要件定義の修正・加筆、設計判断、品質確認、ビジネス判断
- **協働**: 各段階でAIと人間が適切に役割分担し、相互補完する
### Everything as Code
- すべてをコードとして管理し、Gitリポジトリを唯一の信頼できる情報源とする
- インフラ、設定、ドキュメントも含めてコード化する
## 実行ルール
### 必須事前準備
- **必ず`CONTRIBUTING.md`を読み込んでから開始すること**
- プロジェクト固有の開発ガイドラインを理解してから作業を開始する
### ファイル操作
- ファイル編集前に必ず現在の内容を確認
- 重要な変更前は必ずバックアップを作成
### フェーズ管理
- 各段階開始時: 「前段階の成果物を確認しました」と報告
- 各段階の最後に、期待通りの結果になっているか確認
- エラーが発生した場合は、報告してから次へ進む
- ユーザからの指示に無い機能を勝手に追加しない
### 実行方針
- 段階的に進める: 一度に全てを変更せず、小さな変更を積み重ねること
- 複数のタスクを同時並行で進めないこと
- 各段階で明確な成果物を作成すること
- 品質を優先し、速度は二の次とすること
## 6段階フロー
### 1. 📋 要件定義フェーズ
**状態**: 🔄 進行中 / ✅ 完了 / ⏳ 待機中
**目的**: ユーザからの指示に対して「何を作るのか」を明確に定める
**実行内容**:
- **必ず`instructions/requirements_definition_prompt.md`を読み込んでから開始すること**
- 目的の明確化
- 現状分析
- 機能要件の定義
- 非機能要件の定義
- 制約条件の定義
- 成功基準の設定
**成果物**: `design/requirements.md`
**必須確認**: 「✅ 要件定義フェーズが完了しました。設計フェーズに進んでよろしいですか？」
### 2. 🏗️ 設計フェーズ
**状態**: 🔄 進行中 / ✅ 完了 / ⏳ 待機中
**目的**: 要件定義で決定したことをもとに「どのようにつくるか」「内部でどのように処理するか」を設計する
**実行内容**:
- **必ず`design/requirements.md`を読み込んでから開始すること**
- **必ず`instructions/app_basic_design_prompt.md`を読み込んでから開始すること**
- **必ず`instructions/infra_basic_design_prompt.md`を読み込んでから開始すること**
- システム全体設計
- アーキテクチャ設計
- データベース設計（必要に応じて）
- API設計（必要に応じて）
- UI/UX設計（必要に応じて）
- セキュリティ設計
- パフォーマンス設計
- 設計整合性の確認
**成果物**: `design/app_basic_design.md`、`design/infra_basic_design.md`
**必須確認**: 「✅ 設計フェーズが完了しました。実装フェーズに進んでよろしいですか？」
### 3. 💻 実装フェーズ
**状態**: 🔄 進行中 / ✅ 完了 / ⏳ 待機中
**目的**: 設計に基づいてコードを実装し、テストを作成する
**実行内容**:
- **必ず`design/`配下の設計書を読み込んでから開始すること**
- **必ず`instructions/app_implementation_prompt.md`を読み込んでから開始すること**
- **必ず`instructions/cdk_creation_prompt.md`を読み込んでから開始すること**
- **AWS構成図の作成**: AWS構成図を作成し、`design/infra_basic_design.md`に反映すること
- `CONTRIBUTING.md`のコードスタイルに従ったコード実装
- 単体テストの作成
- 統合テストの作成
- コードレビュー
- リファクタリング
- ドキュメント更新
**成果物**: 実装されたコード、テストコード、更新されたドキュメント
**必須確認**: 「✅ 実装フェーズが完了しました。テストフェーズに進んでよろしいですか？」
### 4. 🔧 テストフェーズ
**状態**: 🔄 進行中 / ✅ 完了 / ⏳ 待機中
**目的**: 全体を統合し、動作確認と品質検証を行う
**実行内容**:
- **必ず`instructions/test-definition-prompt.md`を読み込んでから開始すること**
- **必ず`instructions/unit-test-implementation-prompt.md`を読み込んでから開始すること**
- システム統合
- エンドツーエンドテスト
- パフォーマンステスト
- セキュリティテスト
- ユーザビリティテスト
- バグ修正
**成果物**: 統合されたシステム、テスト結果、バグレポート
**必須確認**: 「✅ テストフェーズが完了しました。デプロイフェーズに進んでよろしいですか？」
### 5. 🚀 デプロイフェーズ
**状態**: 🔄 進行中 / ✅ 完了 / ⏳ 待機中
**目的**: 本番環境への安全な展開を行う
**実行内容**:
- **必ず`instructions/github-actions-workflow-prompt.md`を読み込んでから開始すること**
- デプロイ環境の準備
- デプロイスクリプトの作成
- 本番環境への展開
- 動作確認
- ロールバック計画の準備
- 監視設定
**成果物**: 本番環境で動作するシステム、デプロイドキュメント
**必須確認**: 「✅ デプロイフェーズが完了しました。レビュー・検証フェーズに進んでよろしいですか？」
### 6. 🔄 レビュー・検証フェーズ
**状態**: 🔄 進行中 / ✅ 完了 / ⏳ 待機中
**目的**: 継続的な改善と保守を行う
**実行内容**:
- **必ず`instructions/review-check-list.md`を読み込んでから開始すること**
- 監視・ログ分析
- パフォーマンス監視
- セキュリティ監視
- ユーザーフィードバック収集
- 継続的改善
- ドキュメント更新
**成果物**: レビュー結果
## 品質保証
### コード品質
- `CONTRIBUTING.md`のコードスタイルに従った実装
- 命名規則の統一
- 適切なコメント・ドキュメント
- エラーハンドリングの実装
- ログ出力の適切な設定
### テスト品質
- 十分なテストカバレッジ（80%以上を目標）
- 単体テスト、統合テスト、E2Eテストの適切な配置
- テストの自動化
### セキュリティ
- セキュリティ要件の確認
- 脆弱性スキャンの実施
- 機密情報の適切な管理
## エラーハンドリング
### 段階でのエラー
- エラー発生時は即座に報告
- エラーの原因を特定
- 解決策を提案
- 解決後に次の段階へ進む
### 技術的エラー
- ログの確認
- デバッグ情報の収集
- 段階的な問題解決
- 必要に応じて設計の見直し
## ドキュメント管理
### 必須ドキュメント
- 要件定義書
- 設計書
- 実装計画書
- API仕様書（必要に応じて）
- テスト計画書
- デプロイ手順書
- 運用マニュアル
### ドキュメント更新
- 各段階でドキュメントを更新
- 変更履歴の記録
- バージョン管理
## プロジェクト管理
### 進捗管理
- 各段階の完了確認
- マイルストーンの設定
- リスクの特定と対策
### コミュニケーション
- 定期的な進捗報告
- 課題の早期共有
- 意思決定の記録
spec.mdcファイルの解説
1. ファイル構造
-
フロントマター:
alwaysApply: trueにより、すべてのAIアシスタントとの会話で自動適用 - 6段階フロー: 明確な段階分けと各段階の目的・成果物を定義
- 実行ルール: AIと人間の協働方法を具体的に規定
2. 重要な特徴
- 状態管理: 各段階に「進行中/完了/待機中」の状態を設定
- 必須確認: 各段階の完了時に明確な確認メッセージを要求
- 品質保証: コード品質、テスト品質、セキュリティの基準を設定
- エラーハンドリング: 段階的な問題解決方法を定義
3. 実践的な活用方法
- プロジェクト開始時: このファイルを読み込んでから開発を開始
- 段階進行時: 各段階の成果物を確認してから次に進む
- 品質管理: 定義された基準に従って品質をチェック
- チーム協働: AIと人間の役割分担を明確にして効率的な開発を実現
CONTRIBUTING.mdの解説
CONTRIBUTING.mdとは？
CONTRIBUTING.mdは、プロジェクトに参加する開発者が守るべきルールや手順を記載したドキュメントです。AI駆動開発では、このファイルがAIアシスタントと人間の協働における重要な指針となります。
CONTRIBUTING.mdの役割
- 開発ガイドラインの定義: コードスタイル、命名規則、コミット規約などを明記
- AIとの協働ルール: AIアシスタントが従うべき開発方針を設定
- 品質基準の設定: テスト、ドキュメント、セキュリティの基準を定義
- プロジェクト固有のルール: そのプロジェクト特有の開発ルールを記載
CONTRIBUTING.mdの内容
以下が実際のプロジェクトで使用されているCONTRIBUTING.mdの内容です。
📄 CONTRIBUTING.md の内容を表示
# 開発ガイドライン
## 開発原則
### Everything as Code
すべてをコードとして管理し、Gitリポジトリを唯一の信頼できる情報源とします。
### AI駆動開発
AIと人間の協働により、効率的で一貫性のある開発を目指します。
## 開発ルール
### コードスタイル
- 命名規則を統一すること
- コードをクリーンで理解しやすく保つこと
- 適切なドキュメントを記述すること
- PythonコードではPEP 8に従うこと
- CDKコードではAWS CDKのベストプラクティスに従うこと
#### 命名規則
- **ファイル名**: スネークケース（例: `website_stack.py`）
- **クラス名**: パスカルケース（例: `WebsiteStack`）
- **関数・変数名**: スネークケース（例: `create_bucket`）
- **定数名**: 大文字スネークケース（例: `MAX_RETRY_COUNT`）
- **CDKリソース**: AWSリソース名に準拠（例: `s3_bucket`）
#### コメント・ドキュメント
- **関数・クラス**: docstringで説明を記述
- **複雑なロジック**: 行コメントで理由を説明
- **TODO/FIXME**: 期限と担当者を明記
- **README**: 各ディレクトリにREADME.mdを配置
#### コード構造
- **関数の長さ**: 20行以内を推奨
- **クラスの責任**: 単一責任の原則に従う
- **インポート**: 標準ライブラリ → サードパーティ → ローカルの順
- **設定値**: 定数として分離、環境変数で管理
### エラー処理・ロギング
- アプリケーション全体で一貫したエラー処理を実装すること
- 適切なロギングを行うこと
- インフラコードではCloudWatchログの設定を適切に行うこと
#### エラー処理
- **例外処理**: 具体的な例外をキャッチする
- **エラーメッセージ**: ユーザーに分かりやすいメッセージ
- **ロールバック**: 失敗時の適切な復旧処理
- **リトライ**: 一時的なエラーに対する再試行ロジック
#### ロギング
- **ログレベル**: DEBUG, INFO, WARNING, ERROR, CRITICALを適切に使用
- **構造化ログ**: JSON形式で構造化されたログ出力
- **機密情報**: パスワードやトークンはログに出力しない
- **ログローテーション**: 適切なサイズと期間でローテーション
### テスト
- `instructions/test-aspects.md`の考慮事項に従うこと
- 十分なテストカバレッジを保つこと
- インフラコードのテストは`infra/tests/`に配置すること
#### テストカバレッジ
- **アプリケーション**: 80%以上のカバレッジを目標
- **インフラコード**: 主要なリソース作成・設定のテスト
- **統合テスト**: エンドツーエンドの動作確認
- **セキュリティテスト**: 脆弱性スキャンの実施
#### テスト命名
- **テスト関数**: `test_`プレフィックス + テスト対象 + 期待結果
- **テストクラス**: `Test`プレフィックス + テスト対象クラス名
- **テストファイル**: `test_`プレフィックス + テスト対象ファイル名
### コードレビュー
- `instructions/review-check-list.md`に従ってレビューを実施すること
- インフラコードのレビューではセキュリティ設定を重点的に確認すること
#### レビューポイント
- **機能性**: 要件を満たしているか
- **セキュリティ**: 適切なセキュリティ設定か
- **パフォーマンス**: 効率的な実装か
- **保守性**: 理解しやすく保守しやすいか
- **テスト**: 十分なテストが含まれているか
#### レビューコメント
- **建設的**: 改善提案を含む建設的なコメント
- **具体的**: 具体的な修正方法を示す
- **一貫性**: チーム全体で一貫した基準を適用
## ディレクトリ構造の管理
新しいモジュールや機能を追加する際は、以下の原則に従ってください：
### アプリケーション開発
1. `apps/`配下に適切なサブディレクトリを作成
2. 関連ドキュメントを`docs/`または`design/`に配置
### インフラ開発（CDK）
1. `infra/stacks/`配下に新しいスタックファイルを作成
2. 再利用可能な機能は`infra/constructs/`に配置
3. 環境別設定は`infra/config/`に追加
4. デプロイスクリプトは`infra/scripts/`に配置
5. インフラ関連ドキュメントは`design/`に配置
6段階フローの詳細解説
1. 📋 要件定義フェーズ
要件定義の重要性
要件定義は、プロジェクトの成功を左右する最も重要な段階です。「何を作るのか」を明確にすることで、その後の設計や実装がスムーズに進みます。AI駆動開発では、この段階でAIと人間が協働して、曖昧な要求を具体的で実装可能な要件に落とし込んでいきます。
従来の開発では、要件定義に多くの時間を費やし、後から「実はこうしたかった」ということがよくありました。AIとの協働では、多角的な視点から要件を検討し、見落としを防げます。
AIとの協働で効率化できること
AIは要件定義において、以下のような強みを発揮します。
- 多角的な分析: 様々な角度から要件を検討し、見落としを防ぐ
- 非機能要件の提案: パフォーマンス、セキュリティ、使いやすさなどの観点を自動的に提案
- 技術的制約の考慮: 実装時の技術的な制約を事前に考慮した要件を提案
一方、人間は以下の役割を担います。
- ビジネス要件の定義: なぜその機能が必要なのか、ビジネス的な価値を明確にする
- ユーザー体験の考慮: 実際のユーザーがどのように使うかを想像し、要件に反映
- 優先順位の決定: 複数の機能要件の中から、何を優先すべきかを判断
- 最終的な承認: AIが提案した要件を検討し、最終的な判断する
要件定義フェーズでは、instructions/requirements_definition_prompt.mdのプロンプトを使用します。このプロンプトは、AIを要件定義支援エキスパートとして機能させ、曖昧な要求を具体的で実装可能な要件に落とし込むためのものです。
📄 instructions/requirements_definition_prompt.md の内容を表示
下記のプロンプトで要件定義書を作成する。
---
あなたはAIを活用したプログラミングプログラムの要件定義支援エキスパートとして、開発案件の要求分析を行います。利用者から共有された要件内容を体系的に整理し、必要に応じて追加の情報を求めながら、最終的には明瞭かつ簡潔な日本語の指示書を作成します。UIの仕様も含めた包括的な要件定義を目指します。
あなたの役割は以下のステップで進めていきます：
1. 要件の分析・整理プロセス：
- 提示された要件を注意深く精査し、主要な構成要素を抽出
- 各要件を体系的なグループに分類（例：技術スタック、想定ユーザー層、核となる機能など）
- クライアント要望から重要なキーワードを抽出・リスト化
2. 情報ギャップの特定：
- 現状の要件における情報不足点を洗い出し
- プロジェクト成功のために検討すべき追加観点を把握
- 要件に基づく潜在的な技術的制約や課題の予測
3. 確認質問の構成：
- 不足情報を埋めるための的確な質問を作成
- 回答しやすい具体的かつ簡潔な質問形式を心がける
4. 要件分析結果の提示：
- 分析内容と質問事項を「要件分析と確認事項」セクションに記載
- 追加情報取得のための質問一覧を提示
5. ユーザーインターフェース設計：
- プロジェクトに最適なUIデザイン案を作成
- HTML+CSSを用いたアーティファクトでUI案を提示
- 必要となるUI要素の具体的なリストアップ
- 「UI設計分析」セクションで作成したUIの検証と改善提案を行う
6. 追加情報の統合：
- 利用者からのフィードバックを既存要件と統合
- 全体的な一貫性と完全性を検証
7. 最終指示書の作成：
- 整理された要件情報をもとに総合的な指示書を作成
- わかりやすい日本語で記述し、リスト形式などで重要ポイントを強調
- UI仕様を明確に記載
- すぐに利用できるマークダウン形式でアーティファクトとして出力
- AIの特性を考慮し、段階的な実装ステップを設定（一度に全機能ではなく順次実装）
全プロセスにおいて以下の点に留意します：
- 要件の明確化と具体化に重点を置き、開発精度の向上を図る
- 利用者との確認プロセスを十分に行う
- 確認フェーズ中は出力を最小限に抑える
- 以下の構成で指示書フォーマットを作成する
指示書は基本機能から始まり徐々に高度な機能を追加する構成とし、AIが効率的に実装できる順序を考慮します：
作成した要件定義書はdesign/requirements.mdで作成して
\`\`\`
# システム目的・概要（全体像）
# 実装ステップ（個別指示）
## ステップ1
（ステップ1で実装する具体的機能・内容）
## ステップ2
（ステップ2で実装する具体的機能・内容）
## ステップ3
（ステップ3で実装する具体的機能・内容）
...
\`\`\`
成果物: design/requirements.md
2. 🏗️ 設計フェーズ
設計の重要性とアプローチ
設計フェーズでは、要件定義で明確になった「何を作るか」を基に、「どのように作るか」を具体的に決めていきます。これは、実装を始める前に全体像を把握し、効率的な開発を可能にする重要な段階です。
AI駆動開発では、設計をアプリケーション設計とインフラ設計に分けて進めます。これにより、それぞれの専門性を活かしながら、全体として一貫した設計を行えます。
アプリケーション設計とインフラ設計の違い
アプリケーション設計では、以下のことを決定します。
- 技術スタックの選択: フロントエンド、バックエンドで使用する言語やフレームワーク
- アーキテクチャパターン: MVC、マイクロサービス、サーバーレスなどの設計パターン
- データ構造の設計: データベースの設計やAPIの仕様
- ユーザーインターフェース: 画面構成や操作フローの設計
インフラ設計では、以下のことを決定します。
- ネットワーク構成: VPC、セキュリティグループ、ロードバランサーの設定
- ストレージ設計: データベース、ファイルストレージの構成
- セキュリティ設計: 認証、認可、データ暗号化の仕組み
- 運用設計: 監視、ログ、バックアップの仕組み
AIを活用した設計の進め方
AIは設計において、以下のような価値を提供します。
- 技術選択の提案: 要件に適した技術スタックを自動的に提案
- ベストプラクティスの適用: 業界標準の設計パターンを適用した設計を提案
- セキュリティ考慮: セキュリティの観点を考慮した設計を自動的に提案
- スケーラビリティの考慮: 将来の拡張性を考慮した設計を提案
- コスト最適化: 効率的なリソース利用を考慮した設計を提案
人間は以下の役割を担います。
- ビジネス要件の考慮: 技術的な制約とビジネス要件のバランスを取る
- ユーザー体験の最適化: 技術的な実現可能性とユーザビリティのバランスを取る
- チームのスキル考慮: チームの技術スキルに適した技術選択を行う
- 将来の拡張性判断: プロジェクトの成長に合わせた設計判断を行う
設計フェーズでは、以下の2つのプロンプトを使用します。
-
instructions/app_basic_design_prompt.md: アプリケーションの基本設計書を作成するためのプロンプト -
instructions/infra_basic_design_prompt.md: インフラストラクチャの基本設計書を作成するためのプロンプト
これらのプロンプトにより、AIが要件定義書をもとに、実装可能な設計書を自動生成します。
📄 instructions/app_basic_design_prompt.md の内容を表示
下記のプロンプトで要件定義書を作成する。
---
あなたはAIを活用したプログラミングプロジェクトの**基本設計書作成エキスパート**です。
要件定義（requirements definition）をもとに、AIが効率的かつ段階的に実装できるよう、システム全体の設計方針・構造・主要仕様を明確に整理してください。
## あなたの役割・進め方
1. **全体設計方針の明示**
- システムの目的・全体像を簡潔にまとめる
- アーキテクチャ（例：サーバーレス、マイクロサービス等）や主要技術スタックを明記
2. **機能構成・モジュール設計**
- 要件定義をもとに、主要な機能・モジュールをリストアップ
- 各機能の責任範囲・入出力・依存関係を明確化
- 機能ごとに「AIが自律的に実装しやすい粒度」で分割
3. **データ設計**
- 主要なデータ構造・エンティティ・スキーマを定義
- テーブル設計やAPIスキーマ（例：OpenAPI/JSON Schema）をマークダウンで記述
4. **UI設計**
- 画面構成・主要UI要素をリストアップ
- 必要に応じてHTML+CSSのサンプルやワイヤーフレームを提示
- ユーザー操作フローを簡潔に記述
5. **非機能要件・運用設計**
- セキュリティ、パフォーマンス、スケーラビリティ、監視・ロギング等の観点を整理
- AWS等クラウドサービス利用時は、IaCやCI/CDの設計方針も明記
6. **段階的実装ステップの提案**
- AIが順次実装できるよう、実装順序・優先度を明示
- 各ステップで「何を作るか」「何を検証するか」を具体的に記載
7. **確認・追加質問**
- 情報が不足している場合は、明確な質問をリストアップ
**重要：作成した基本設計書はdesign配下に作成し、アプリケーションコードはapp配下に作成してください。**
## 出力フォーマット例
````markdown
# 基本設計書
## 1. システム全体像・設計方針
## 2. 機能構成・モジュール設計
- 機能A
- 概要
- 入力/出力
- 依存関係
- 機能B
...
## 3. データ設計
### エンティティ一覧
| エンティティ名 | 属性 | 型 | 説明 |
|---|---|---|---|
| User | id | string | ユーザーID |
...
### APIスキーマ例
```yaml
openapi: 3.0.0
...
```
## 4. UI設計
- 画面一覧
- 主要UI要素
- HTML/CSSサンプル
## 5. 非機能要件・運用設計
- セキュリティ
- パフォーマンス
- 監視・ロギング
...
## 6. 実装ステップ
### ステップ1
- 実装内容
- 検証ポイント
### ステップ2
...
## 7. 確認事項・追加質問
- 質問1
- 質問2
...
## 8. フォルダ構成
```plaintext
app/
├── web/ # フロントエンドアプリケーション
│ ├── index.html # メインHTMLファイル
│ ├── styles/ # CSSファイル
│ │ ├── main.css
│ │ └── components.css
│ ├── scripts/ # JavaScriptファイル
│ │ ├── app.js # メインアプリケーション
│ │ ├── todo.js # TODO機能
│ │ └── storage.js # データ永続化
│ ├── assets/ # 静的アセット
│ │ ├── images/
│ │ └── icons/
│ └── service-worker.js # Service Worker
├── api/ # バックエンドAPI（必要に応じて）
│ ├── src/
│ ├── tests/
│ └── package.json
└── shared/ # 共有リソース
├── types/ # 型定義
└── utils/ # ユーティリティ
```
````plaintext
---
**注意点：**
- 各セクションはAIが自律的に分割・実装しやすいよう、粒度・順序を意識する
- 可能な限りマークダウンや表形式で明示
- 不明点は必ず「確認事項」としてリストアップ
- **アプリケーションコードは必ずapp配下に作成し、言語やフレームワークに応じて適切なフォルダ構成を提案する**
---
このプロンプトを使えば、AIが効率的に「基本設計書」を作成・実装できます。
必要に応じてカスタマイズも可能です。
📄 instructions/infra_basic_design_prompt.md の内容を表示
下記のプロンプトで要件定義書を作成する。
---
あなたはAIを活用したプログラミングプロジェクトの**インフラ基本設計書作成エキスパート**です。
要件定義（requirements definition）をもとに、AIが効率的かつ段階的にインフラ環境を構築できるよう、システム全体のインフラ設計方針・アーキテクチャ・運用仕様を明確に整理してください。
## あなたの役割・進め方
1. **インフラ全体設計方針の明示**
- システムのインフラ目的・全体像を簡潔にまとめる
- クラウドアーキテクチャ（AWS、GCP、Azure等）や基盤技術スタックを明記
- オンプレミス/ハイブリッド/マルチクラウド戦略の選択理由
2. **インフラ構成・リソース設計**
- 要件定義をもとに、主要なインフラコンポーネントをリストアップ
- ネットワーク、コンピューティング、ストレージ、データベース等の責任範囲・仕様を明確化
- 各リソースの「AIが自律的に構築しやすい粒度」で分割
3. **ネットワーク・セキュリティ設計**
- VPC/サブネット設計
- セキュリティグループ/NACLの設計
- ロードバランサー・DNS設定
- SSL/TLS証明書管理
- IAM/権限管理の設計
4. **データ基盤設計**
- データベース（RDS、NoSQL等）の設計
- データストレージ（S3、EBS等）の設計
- バックアップ・災害復旧戦略
- データパイプライン設計
5. **運用・監視・デプロイ設計**
- CI/CDパイプライン設計
- 監視・ロギング・アラート設計（CloudWatch、Datadog等）
- 自動スケーリング設計
- 障害対応・インシデント管理
- コスト最適化戦略
6. **IaC（Infrastructure as Code）設計**
- Terraform、CloudFormation、Pulumi等の選定理由
- モジュール構成・ディレクトリ構造
- 環境分離戦略（dev/stg/prd）
- 状態管理・バージョン管理
7. **段階的構築ステップの提案**
- AIが順次構築できるよう、構築順序・優先度を明示
- 各ステップで「何を構築するか」「何を検証するか」を具体的に記載
8. **確認・追加質問**
- 情報が不足している場合は、明確な質問をリストアップ
作成したインフラ基本設計書はdesign配下に作成して
## 出力フォーマット例
````markdown
# インフラ基本設計書
## 1. インフラ全体像・設計方針
- システム目的
- アーキテクチャ選定理由
- 技術スタック
## 2. インフラ構成・リソース設計
### コンピューティング
- EC2/Container/Serverless設計
- 性能要件・スケーリング設計
### ネットワーク
- VPC設計
- サブネット設計
- ルーティング設計
### ストレージ・データベース
- RDS/NoSQL設計
- S3/EBS設計
- バックアップ戦略
## 3. セキュリティ設計
### ネットワークセキュリティ
- セキュリティグループ設計
- WAF/Shield設定
### アクセス制御
- IAM設計
- 認証・認可設計
## 4. 運用・監視設計
### 監視・ロギング
- CloudWatch/監視ツール設計
- ログ収集・分析設計
### CI/CD
- パイプライン設計
- デプロイ戦略
## 5. IaC設計
### ツール選定
- Terraform/CloudFormation選定理由
- モジュール構成（infra/）
### 環境管理
- 環境分離戦略
- 状態管理
## 6. 構築ステップ
### ステップ1: 基盤ネットワーク
- VPC/サブネット構築
- セキュリティグループ設定
- 検証ポイント
### ステップ2: コンピューティング環境
- EC2/ECS/Lambda構築
- ロードバランサー設定
- 検証ポイント
### ステップ3: データ基盤
- RDS/DynamoDB構築
- S3設定
- 検証ポイント
...
## 7. 非機能要件・運用設計
### 可用性・信頼性
- SLA目標
- 冗長化設計
- 災害復旧設計
### 性能・スケーラビリティ
- 性能要件
- 自動スケーリング設計
- 負荷分散設計
### コスト最適化
- リソース最適化戦略
- 予算管理・アラート設定
## 8. 確認事項・追加質問
### 技術要件
- 既存システムとの連携要件は？
- 特定のコンプライアンス要件は？
- 災害復旧の目標復旧時間は？
### 運用要件
- 24時間運用の必要性は？
- 運用チームの技術レベルは？
- 予算制約・制限は？
### セキュリティ要件
- 特定のセキュリティ基準準拠は？
- 個人情報保護の要件は？
- 外部監査の必要性は？
````
---
**注意点：**
- インフラ構築の依存関係を考慮した段階的アプローチ
- 各リソースの設定値・仕様を具体的に記載
- 運用・保守性を重視した設計
- コスト効率と性能のバランスを考慮
- セキュリティファーストの設計思想
---
このプロンプトを使えば、AIが効率的に「インフラ基本設計書」を作成・構築できます。
アプリケーション要件に応じてインフラ設計をカスタマイズ可能です。
成果物: design/app_basic_design.md、design/infra_basic_design.md
3. 💻 実装フェーズ
実装の重要性
実装フェーズは、設計書を実際のコードに変換する段階です。この段階で高品質なコードを書くことで、後の保守性や拡張性が大きく左右されます。
AIとの協働で効率化できること
- ベストプラクティスの提案: コーディング規約や設計パターンから最適な提案をAIが行い、人間が判断・適用
- エラーハンドリングの設計支援: AIが一般的なエラーパターンを提案し、人間が具体的な処理を実装
実装フェーズでは、以下の2つのプロンプトを使用します。
-
instructions/app_implementation_prompt.md: アプリケーションの実装のためのプロンプト -
instructions/cdk_creation_prompt.md: AWS CDKコードを作成するためのプロンプト
これらのプロンプトにより、AIが設計書をもとに、高品質なコードを自動生成します。
📄 instructions/app_implementation_prompt.md の内容を表示
# アプリケーション実装プロンプト
## 役割定義
あなたは「アプリケーション実装エキスパート」です。設計書をもとに、高品質で保守性の高いアプリケーションを実装する専門家として活動してください。
## 実装方針
### 基本原則
1. **設計書準拠**: 提供された設計書の仕様を厳密に遵守する
2. **段階的実装**: 機能を段階的に実装し、各段階で動作確認を行う
3. **品質重視**: コードの可読性、保守性、拡張性を重視する
4. **テスト駆動**: 実装と並行してテストコードを作成する
5. **ドキュメント**: 適切なコメントとドキュメントを記述する
### 技術スタック（設計書に基づく）
- **フロントエンド**: 設計書で指定されたフロントエンド技術
- **バックエンド**: 設計書で指定されたバックエンド技術（必要な場合）
- **データ層**: 設計書で指定されたデータストレージ技術
- **アーキテクチャ**: 設計書で指定されたアーキテクチャパターン
- **デプロイ**: 設計書で指定されたデプロイ方式
## 実装手順
### ステップ1: プロジェクト構造の作成
1. **ディレクトリ構造**: 設計書に基づいた適切なディレクトリ構造を作成
2. **基本ファイル**: 設計書で指定された技術スタックの基本ファイルを作成
3. **設定ファイル**: 必要な設定ファイル（package.json、.gitignore、Dockerfile等）を作成
4. **環境設定**: 開発・テスト・本番環境の設定ファイルを作成
### ステップ2: 基本機能の実装
1. **コア機能**: 設計書で定義された主要機能の実装
2. **データ層連携**: 指定されたデータストレージとの連携
3. **基本的なUI**: 入力フォーム、表示、基本的なスタイリング
4. **認証・認可**: 設計書で指定された認証・認可機能（必要な場合）
### ステップ3: 高度な機能の実装
1. **ビジネスロジック**: 設計書で定義された複雑なビジネスロジック
2. **外部連携**: API連携、サードパーティサービス連携（必要な場合）
3. **リアルタイム機能**: WebSocket、Server-Sent Events等（必要な場合）
4. **ファイル処理**: アップロード・ダウンロード機能（必要な場合）
5. **通知機能**: プッシュ通知、メール通知等（必要な場合）
### ステップ4: 品質向上
1. **エラー処理**: 適切な例外処理とユーザーフレンドリーなエラーメッセージ
2. **ロギング**: 構造化ログの実装
3. **テスト**: 単体テスト、統合テスト、E2Eテストの作成
4. **パフォーマンス**: 最適化とパフォーマンス改善
5. **セキュリティ**: セキュリティ要件の実装
6. **アクセシビリティ**: アクセシビリティ要件の実装
### ステップ5: 最終調整
1. **コードレビュー**: 設計書との整合性確認
2. **ドキュメント**: README、API仕様書、デプロイ手順書の作成
3. **デプロイ準備**: 本番環境用の設定調整
4. **監視・ログ**: 監視設定、ログ設定の実装
## 実装時の注意事項
### コード品質
- **命名規則**: 設計書で定義された命名規則に従う
- **コメント**: 関数・クラスにはdocstring、複雑なロジックには行コメント
- **構造**: 関数は20行以内、クラスは単一責任の原則に従う
- **インポート**: 標準ライブラリ → サードパーティ → ローカルの順
- **コードスタイル**: 設計書で指定されたコーディング規約に従う
### セキュリティ
- **入力検証**: ユーザー入力の適切な検証
- **XSS対策**: 出力エスケープの実装
- **CSRF対策**: CSRFトークンの実装（必要な場合）
- **SQLインジェクション対策**: プリペアドステートメントの使用（必要な場合）
- **機密情報**: パスワードやトークンをログに出力しない
- **CSP**: Content Security Policyの設定（Webアプリの場合）
### パフォーマンス
- **初期読み込み**: 設計書で指定された読み込み時間要件
- **静的リソース**: 設計書で指定された静的リソース読み込み時間
- **TTFB**: 設計書で指定されたTime to First Byte
- **キャッシュ**: 適切なキャッシュ戦略の実装
- **データベース**: クエリ最適化、インデックス設定（必要な場合）
### ブラウザ・プラットフォーム対応
- **対応環境**: 設計書で指定されたブラウザ・プラットフォーム
- **プログレッシブエンハンスメント**: 基本機能は全環境で動作
- **レスポンシブデザイン**: モバイル・タブレット・デスクトップ対応（Webアプリの場合）
## 出力形式
### ファイル構成（設計書に基づく）
```
apps/{app-name}/
├── フロントエンドファイル（設計書で指定）
├── バックエンドファイル（設計書で指定）
├── 設定ファイル
├── テストファイル
├── ドキュメント
└── デプロイファイル
```
### 各ファイルの要件
#### フロントエンドファイル（Webアプリの場合）
- **セマンティックHTML**: 適切なHTML5要素の使用
- **アクセシビリティ**: ARIA属性の適切な設定
- **SEO対応**: メタタグ、構造化データの設定
- **PWA対応**: Service Worker、マニフェストファイル（必要な場合）
#### CSSファイル（Webアプリの場合）
- **モジュラー設計**: 機能別・コンポーネント別の分離
- **レスポンシブ**: モバイルファーストの設計
- **パフォーマンス**: 効率的なセレクタ、最小限のCSS
- **保守性**: 変数、ミックスインの活用
#### JavaScriptファイル（Webアプリの場合）
- **アーキテクチャパターン**: 設計書で指定されたパターンの実装
- **モジュラー設計**: ES6モジュールの活用
- **エラー処理**: 適切な例外処理
- **テスト可能**: 単体テストしやすい構造
#### バックエンドファイル（必要な場合）
- **API設計**: RESTful APIまたはGraphQLの実装
- **データベース**: ORM/ODMの適切な使用
- **認証・認可**: JWT、OAuth等の実装
- **バリデーション**: 入力データの検証
- **エラーハンドリング**: 適切なエラー処理
## 実装開始時の確認事項
実装を開始する前に、以下の情報を確認してください：
### 必須情報
1. **設計書**: 要件定義書、基本設計書、インフラ設計書
2. **技術要件**: 使用技術、環境対応、パフォーマンス要件
3. **機能要件**: 実装する機能の詳細仕様
4. **非機能要件**: セキュリティ、可用性、保守性要件
### 確認事項
- 設計書の内容は最新版ですか？
- 追加の要件や制約はありますか？
- 優先度の高い機能はどれですか？
- 実装の順序に指定はありますか？
- 使用する技術スタックは設計書と一致していますか？
## 実装完了後の確認
実装完了後、以下の項目を確認してください：
### 機能確認
- [ ] 設計書の全機能が実装されている
- [ ] 各機能が正常に動作する
- [ ] エラー処理が適切に実装されている
- [ ] パフォーマンス要件を満たしている
### 品質確認
- [ ] コードが設計書の仕様に準拠している
- [ ] テストカバレッジが設計書で指定された目標を満たしている
- [ ] セキュリティ要件を満たしている
- [ ] アクセシビリティ要件を満たしている（Webアプリの場合）
### ドキュメント確認
- [ ] READMEが適切に記述されている
- [ ] API仕様書が作成されている（必要な場合）
- [ ] デプロイ手順が記載されている
- [ ] コードコメントが適切に記述されている
### デプロイ確認
- [ ] 本番環境へのデプロイが成功する
- [ ] 監視・ログが正常に動作する
- [ ] バックアップ・復旧手順が確認できる
## 注意事項
- **設計書優先**: 設計書の内容を最優先とし、勝手な変更は避ける
- **段階的実装**: 一度に全てを実装せず、段階的に進める
- **品質重視**: 機能実装と並行して品質向上を図る
- **テスト駆動**: 実装と並行してテストを作成する
- **ドキュメント**: 適切なドキュメントを継続的に更新する
- **セキュリティ**: セキュリティ要件を最初から考慮する
- **スケーラビリティ**: 将来の拡張を考慮した設計
このプロンプトに従って、設計書をもとに高品質なアプリケーションを実装してください。
📄 instructions/cdk_creation_prompt.md の内容を表示
# CDK作成プロンプト
## 役割定義
あなたは「AWS CDK作成エキスパート」です。設計書をもとに、高品質で保守性の高いAWS CDKコードを作成する専門家として活動してください。
## 作成方針
### 基本原則
1. **設計書準拠**: 提供された設計書の仕様を厳密に遵守する
2. **段階的作成**: リソースを段階的に作成し、各段階で動作確認を行う
3. **品質重視**: コードの可読性、保守性、再利用性を重視する
4. **テスト駆動**: 作成と並行してCDKテストコードを作成する
5. **ドキュメント**: 適切なコメントとドキュメントを記述する
6. **セキュリティ**: セキュリティベストプラクティスを最優先とする
### 技術スタック
- **CDK言語**: 設計書で指定された言語（Python/TypeScript/JavaScript/Java/C#）
- **CDKバージョン**: 最新の安定版を使用
- **AWS SDK**: CDKに含まれるAWS SDKを使用
- **テストフレームワーク**: CDKのテストフレームワーク（pytest等）
- **CI/CD**: GitHub Actions、AWS CodePipeline等
## 作成手順
### ステップ1: プロジェクト構造の作成
1. **ディレクトリ構造**: 設計書に基づいた適切なCDKディレクトリ構造を作成
2. **基本ファイル**: CDKアプリケーションの基本ファイルを作成
3. **設定ファイル**: cdk.json、requirements.txt、package.json等の設定ファイルを作成
4. **環境設定**: 開発・ステージング・本番環境の設定ファイルを作成
### ステップ2: 基本リソースの作成
1. **VPC・ネットワーク**: 設計書で指定されたネットワーク構成
2. **セキュリティグループ**: 適切なセキュリティグループ設定
3. **IAMロール・ポリシー**: 最小権限の原則に基づくIAM設定
4. **基本ストレージ**: S3バケット、EBSボリューム等
### ステップ3: アプリケーションリソースの作成
1. **コンピューティング**: EC2、ECS、Lambda等のコンピューティングリソース
2. **データベース**: RDS、DynamoDB、ElastiCache等のデータベースリソース
3. **ロードバランサー**: ALB、NLB、CLB等のロードバランサー
4. **CDN・配信**: CloudFront、S3等のコンテンツ配信リソース
### ステップ4: 高度な機能の作成
1. **監視・ログ**: CloudWatch、CloudTrail、X-Ray等の監視リソース
2. **セキュリティ**: WAF、Shield、GuardDuty等のセキュリティリソース
3. **CI/CD**: CodeBuild、CodeDeploy、CodePipeline等のCI/CDリソース
4. **通知**: SNS、SES等の通知リソース
### ステップ5: 品質向上
1. **エラー処理**: 適切な例外処理とロールバック機能
2. **ロギング**: 構造化ログの実装
3. **テスト**: 単体テスト、統合テストの作成
4. **パフォーマンス**: リソース最適化とコスト効率化
5. **セキュリティ**: セキュリティ要件の実装と監査
### ステップ6: 最終調整
1. **コードレビュー**: 設計書との整合性確認
2. **ドキュメント**: README、デプロイ手順書の作成
3. **デプロイ準備**: 本番環境用の設定調整
4. **監視・アラート**: 監視設定、アラート設定の実装
## 作成時の注意事項
### コード品質
- **命名規則**: 設計書で定義された命名規則に従う（snake_case、PascalCase等）
- **コメント**: クラス・メソッドにはdocstring、複雑なロジックには行コメント
- **構造**: メソッドは20行以内、クラスは単一責任の原則に従う
- **インポート**: 標準ライブラリ → AWS CDK → サードパーティ → ローカルの順
- **コードスタイル**: PEP 8（Python）、ESLint（TypeScript）等の規約に従う
### セキュリティ
- **最小権限**: IAMロール・ポリシーは最小権限の原則に従う
- **暗号化**: データの暗号化（保存時・転送時）を適切に設定
- **ネットワーク**: セキュリティグループ、NACLの適切な設定
- **シークレット管理**: Secrets Manager、Parameter Storeの適切な使用
- **監査**: CloudTrail、Config等の監査機能を有効化
### パフォーマンス
- **リソース最適化**: 適切なインスタンスタイプ、ストレージタイプの選択
- **スケーリング**: Auto Scaling、Application Auto Scalingの設定
- **キャッシュ**: ElastiCache、CloudFront等のキャッシュ戦略
- **コスト最適化**: リザーブドインスタンス、Spot インスタンスの活用
### 可用性・耐障害性
- **マルチAZ**: 重要なリソースはマルチAZ配置
- **バックアップ**: 適切なバックアップ戦略の実装
- **ディザスタリカバリ**: RTO、RPO要件に基づくDR戦略
- **ヘルスチェック**: ロードバランサー、Auto Scalingのヘルスチェック
## 出力形式
### ファイル構成（設計書に基づく）
```
infra/
├── app.py # CDKアプリケーションのエントリーポイント
├── requirements.txt # Python依存関係（Pythonの場合）
├── package.json # Node.js依存関係（TypeScript/JavaScriptの場合）
├── cdk.json # CDK設定ファイル
├── stacks/
│ ├── __init__.py
│ ├── network_stack.py # ネットワークスタック
│ ├── compute_stack.py # コンピューティングスタック
│ ├── storage_stack.py # ストレージスタック
│ ├── security_stack.py # セキュリティスタック
│ ├── monitoring_stack.py # 監視スタック
│ └── cicd_stack.py # CI/CDスタック
├── constructs/
│ ├── __init__.py
│ ├── network_construct.py # 再利用可能なネットワークコンストラクト
│ ├── compute_construct.py # 再利用可能なコンピューティングコンストラクト
│ ├── storage_construct.py # 再利用可能なストレージコンストラクト
│ └── monitoring_construct.py # 再利用可能な監視コンストラクト
├── config/
│ ├── __init__.py
│ ├── dev.py # 開発環境設定
│ ├── stg.py # ステージング環境設定
│ └── prd.py # 本番環境設定
├── tests/
│ ├── __init__.py
│ ├── test_network_stack.py # ネットワークスタックテスト
│ ├── test_compute_stack.py # コンピューティングスタックテスト
│ └── test_constructs.py # コンストラクトテスト
├── scripts/
│ ├── deploy.sh # デプロイスクリプト
│ ├── destroy.sh # 削除スクリプト
│ ├── diff.sh # 変更差分確認スクリプト
│ └── test.sh # テスト実行スクリプト
```
### 各ファイルの要件
#### CDKアプリケーションファイル
- **エントリーポイント**: 適切なスタックの初期化とデプロイ
- **環境管理**: 環境別の設定管理
- **エラーハンドリング**: 適切な例外処理
- **ログ出力**: デプロイ状況の適切なログ出力
#### スタックファイル
- **責任分離**: 機能別・環境別の適切なスタック分割
- **依存関係**: スタック間の依存関係の適切な管理
- **リソース管理**: リソースの適切なライフサイクル管理
- **タグ付け**: リソースの適切なタグ付け
#### コンストラクトファイル
- **再利用性**: 複数のスタックで再利用可能な設計
- **パラメータ化**: 適切なパラメータ化とデフォルト値設定
- **バリデーション**: 入力パラメータの適切な検証
- **ドキュメント**: 使用方法の適切なドキュメント
#### 設定ファイル
- **環境分離**: 環境別の設定値管理
- **機密情報**: 機密情報の適切な管理（Parameter Store等）
- **バリデーション**: 設定値の適切な検証
- **ドキュメント**: 設定項目の説明
#### テストファイル
- **カバレッジ**: 重要なリソースのテストカバレッジ
- **モック**: 外部依存の適切なモック
- **アサーション**: 期待される結果の適切な検証
- **統合テスト**: スタック全体の統合テスト
## 作成開始時の確認事項
作成を開始する前に、以下の情報を確認してください：
### 必須情報
1. **設計書**: 要件定義書、基本設計書、インフラ設計書
2. **技術要件**: 使用するAWSサービス、CDK言語、バージョン要件
3. **環境要件**: 開発・ステージング・本番環境の要件
4. **非機能要件**: セキュリティ、可用性、パフォーマンス、コスト要件
### 確認事項
- 設計書の内容は最新版ですか？
- 追加の要件や制約はありますか？
- 優先度の高いリソースはどれですか？
- 作成の順序に指定はありますか？
- 使用するCDK言語は設計書と一致していますか？
- 環境別の設定値は定義されていますか？
## 作成完了後の確認
作成完了後、以下の項目を確認してください：
### 機能確認
- [ ] 設計書の全リソースが作成されている
- [ ] 各リソースが正常にデプロイされる
- [ ] リソース間の依存関係が適切に設定されている
- [ ] 環境別の設定が適切に動作する
### 品質確認
- [ ] コードが設計書の仕様に準拠している
- [ ] テストカバレッジが設計書で指定された目標を満たしている
- [ ] セキュリティ要件を満たしている
- [ ] コスト要件を満たしている
### ドキュメント確認
- [ ] READMEが適切に記述されている
- [ ] デプロイ手順が記載されている
- [ ] アーキテクチャ説明が記載されている
- [ ] コードコメントが適切に記述されている
### デプロイ確認
- [ ] 開発環境へのデプロイが成功する
- [ ] ステージング環境へのデプロイが成功する
- [ ] 本番環境へのデプロイが成功する
- [ ] 監視・アラートが正常に動作する
## 注意事項
- **設計書優先**: 設計書の内容を最優先とし、勝手な変更は避ける
- **段階的作成**: 一度に全てを作成せず、段階的に進める
- **品質重視**: リソース作成と並行して品質向上を図る
- **テスト駆動**: 作成と並行してテストを作成する
- **ドキュメント**: 適切なドキュメントを継続的に更新する
- **セキュリティ**: セキュリティ要件を最初から考慮する
- **コスト管理**: コスト最適化を継続的に実施する
- **バックアップ**: 重要なリソースのバックアップ戦略を実装する
このプロンプトに従って、設計書をもとに高品質なAWS CDKコードを作成してください。
成果物: app/とinfra/に実装されたコード
4. 🔧 テストフェーズ
テストの重要性
テストフェーズは、個別に実装された機能が連携して正しく動作することを確認する重要な段階です。この段階で問題を発見し修正することで、環境でのトラブルを防げます。また、品質を客観的に評価することで、システムの信頼性を確保できます。
AIとの協働で効率化できること
- 包括的なテストケース生成: AIが要件と設計を分析し、見落としがちなテストケースを自動生成
- 自動テストコード作成: テストケースに基づいて、実行可能なテストコードを自動生成
- バグの事前検出: コードを分析し、潜在的なバグを実装前に発見
- パフォーマンステストの自動化: システムの性能を自動的に測定し、問題を特定
- テスト結果の分析: テストの失敗から根本原因を特定し、修正方法を提案
テストフェーズでは、以下の2つのプロンプトを使用します。
-
instructions/test-definition-prompt.md: テストケースを生成するためのプロンプト -
instructions/unit-test-implementation-prompt.md: 単体テストを実装するためのプロンプト
これらのプロンプトにより、AIが要件定義書と設計書をもとに、包括的なテストケースとテストコードを自動生成します。
📄 instructions/test-definition-prompt.md の内容を表示
# テストケース生成プロンプト
## 🎯 目的
要件定義書と基本設計書を基に、アプリケーションとインフラストラクチャの観点で別々のファイルにテストケースを生成します。
## 📋 プロンプトテンプレート
### 基本プロンプト
```
あなたは経験豊富なテストエンジニアです。以下の要件定義書と基本設計書を基に、アプリケーションとインフラストラクチャの観点で別々のファイルにテストケースを生成してください。
## プロジェクト情報
- プロジェクト名: [プロジェクト名]
- プロジェクト概要: [プロジェクトの目的、主要機能、技術スタック]
- 技術スタック: [使用技術の詳細]
- アーキテクチャ: [MVC/マイクロサービス/モノリス等]
## 入力資料
### 要件定義書
[要件定義書の内容を貼り付け]
### 基本設計書
[基本設計書の内容を貼り付け]
## 要求事項
1. アプリケーションテストケース（tests/app-test-cases.md）
2. インフラストラクチャテストケース（tests/infra-test-cases.md）
3. 統合テストケース（tests/integration-test-cases.md）
## 出力形式
### アプリケーションテストケース（tests/app-test-cases.md）
#### 1. フロントエンド機能テストケース
| テストケースID | 機能名 | テストケース名 | 前提条件 | 入力 | 期待結果 | 優先度 | テスト種別 |
|---------------|--------|---------------|----------|------|----------|--------|------------|
| [ID] | [機能名] | [テストケース名] | [前提条件] | [入力] | [期待結果] | [優先度] | [種別] |
#### 2. データ層テストケース
| テストケースID | データエンティティ | テストケース名 | 前提条件 | 入力データ | 期待結果 | 優先度 |
|---------------|-------------------|---------------|----------|-----------|----------|--------|
| [ID] | [エンティティ名] | [テストケース名] | [前提条件] | [入力データ] | [期待結果] | [優先度] |
#### 3. UI/UXテストケース
| テストケースID | 画面名 | テストケース名 | 前提条件 | 操作手順 | 期待結果 | 優先度 |
|---------------|--------|---------------|----------|----------|----------|--------|
| [ID] | [画面名] | [テストケース名] | [前提条件] | [操作手順] | [期待結果] | [優先度] |
### インフラストラクチャテストケース（tests/infra-test-cases.md）
#### 1. AWSリソーステストケース
| テストケースID | AWSリソース | テストケース名 | 前提条件 | テスト条件 | 期待結果 | 優先度 |
|---------------|-------------|---------------|----------|-----------|----------|--------|
| [ID] | [リソース名] | [テストケース名] | [前提条件] | [テスト条件] | [期待結果] | [優先度] |
#### 2. CDKスタックテストケース
| テストケースID | スタック名 | テストケース名 | 前提条件 | テスト条件 | 期待結果 | 優先度 |
|---------------|------------|---------------|----------|-----------|----------|--------|
| [ID] | [スタック名] | [テストケース名] | [前提条件] | [テスト条件] | [期待結果] | [優先度] |
#### 3. デプロイメントテストケース
| テストケースID | デプロイメント | テストケース名 | 前提条件 | テスト条件 | 期待結果 | 優先度 |
|---------------|---------------|---------------|----------|-----------|----------|--------|
| [ID] | [デプロイメント名] | [テストケース名] | [前提条件] | [テスト条件] | [期待結果] | [優先度] |
### 統合テストケース（tests/integration-test-cases.md）
#### 1. エンドツーエンドテストケース
| テストケースID | シナリオ名 | テストケース名 | 前提条件 | 操作手順 | 期待結果 | 優先度 |
|---------------|------------|---------------|----------|----------|----------|--------|
| [ID] | [シナリオ名] | [テストケース名] | [前提条件] | [操作手順] | [期待結果] | [優先度] |
#### 2. パフォーマンステストケース
| テストケースID | パフォーマンス要件 | テストケース名 | 前提条件 | テスト条件 | 期待結果 | 優先度 |
|---------------|-------------------|---------------|----------|-----------|----------|--------|
| [ID] | [要件名] | [テストケース名] | [前提条件] | [テスト条件] | [期待結果] | [優先度] |
## 品質基準
- **網羅性**: 要件定義書の全機能をカバー
- **実用性**: 実際に実装可能なテストケース
- **保守性**: 長期的に管理しやすい構造
- **拡張性**: 将来の機能追加に対応
- **一貫性**: テストケースIDと命名規則の統一
```
### 詳細プロンプト（段階的生成）
#### ステップ1: アプリケーションテストケース生成
```
以下のアプリケーション要件を分析し、アプリケーションテストケースを生成してください：
**アプリケーション要件**
[要件定義書のアプリケーション機能要件を貼り付け]
**分析要求**
1. フロントエンド機能の正常系テストケース
2. フロントエンド機能の異常系テストケース
3. データ層のCRUDテストケース
4. UI/UXの表示・操作テストケース
5. ブラウザ互換性テストケース
**出力ファイル**: tests/app-test-cases.md
**出力形式**
| テストケースID | 機能名 | テストケース名 | 前提条件 | 入力 | 期待結果 | 優先度 | テスト種別 |
|---------------|--------|---------------|----------|------|----------|--------|------------|
| [ID] | [機能名] | [テストケース名] | [前提条件] | [入力] | [期待結果] | [優先度] | [種別] |
```
#### ステップ2: インフラストラクチャテストケース生成
```
以下のインフラストラクチャ要件を分析し、インフラストラクチャテストケースを生成してください：
**インフラストラクチャ要件**
[基本設計書のインフラストラクチャ設計を貼り付け]
**分析要求**
1. AWSリソースの作成・設定テストケース
2. CDKスタックのデプロイテストケース
3. セキュリティ設定テストケース
4. パフォーマンス・スケーラビリティテストケース
5. 監視・ログテストケース
**出力ファイル**: tests/infra-test-cases.md
**出力形式**
| テストケースID | AWSリソース | テストケース名 | 前提条件 | テスト条件 | 期待結果 | 優先度 |
|---------------|-------------|---------------|----------|-----------|----------|--------|
| [ID] | [リソース名] | [テストケース名] | [前提条件] | [テスト条件] | [期待結果] | [優先度] |
```
#### ステップ3: 統合テストケース生成
```
以下の統合要件を分析し、統合テストケースを生成してください：
**統合要件**
[アプリケーションとインフラストラクチャの統合要件を貼り付け]
**分析要求**
1. エンドツーエンドシナリオテストケース
2. デプロイメント統合テストケース
3. パフォーマンス統合テストケース
4. 障害復旧テストケース
5. セキュリティ統合テストケース
**出力ファイル**: tests/integration-test-cases.md
**出力形式**
| テストケースID | シナリオ名 | テストケース名 | 前提条件 | 操作手順 | 期待結果 | 優先度 |
|---------------|------------|---------------|----------|----------|----------|--------|
| [ID] | [シナリオ名] | [テストケース名] | [前提条件] | [操作手順] | [期待結果] | [優先度] |
```
## 🛠️ プロンプト使用ガイド
### 1. プロジェクト情報の準備（例）
```markdown
## プロジェクト情報（例）
- プロジェクト名: TODO App
- プロジェクト概要: 日時指定機能付きTODOアプリケーション
- 技術スタック:
- フロントエンド: HTML5, CSS3, JavaScript (ES6+)
- データ層: LocalStorage/IndexedDB
- インフラ: AWS CDK, S3, CloudFront, Route53
- アーキテクチャ: MVC + AWS
- 主要機能:
- タスク管理（CRUD）
- カテゴリ管理
- 日時指定
- リピートタスク
- テーマ切り替え
```
### 2. 段階的実行
1. **基本プロンプト**で全体概要を生成
2. **ステップ1**でアプリケーションテストケースを生成（tests/app-test-cases.md）
3. **ステップ2**でインフラストラクチャテストケースを生成（tests/infra-test-cases.md）
4. **ステップ3**で統合テストケースを生成（tests/integration-test-cases.md）
### 3. 品質チェック
```markdown
## 品質チェック項目
### アプリケーションテストケース
- [ ] フロントエンド機能の全機能をカバー
- [ ] データ層の全パターンをカバー
- [ ] UI/UX要件の全画面をカバー
- [ ] ブラウザ互換性をカバー
### インフラストラクチャテストケース
- [ ] AWSリソースの全設定をカバー
- [ ] CDKスタックの全デプロイをカバー
- [ ] セキュリティ要件をカバー
- [ ] パフォーマンス要件をカバー
### 統合テストケース
- [ ] エンドツーエンドシナリオをカバー
- [ ] デプロイメント統合をカバー
- [ ] 障害復旧シナリオをカバー
- [ ] セキュリティ統合をカバー
### 共通
- [ ] テストケースの実装可能性
- [ ] テストケースIDの一貫性
- [ ] 優先度の適切な設定
- [ ] ファイル間の整合性
```
## 📊 プロンプト最適化
### 効果的なプロンプトの特徴
1. **具体的な指示**: 要件定義書と基本設計書の内容を具体的に指定
2. **構造化された出力**: 一貫性のあるテストケース形式
3. **段階的な生成**: 複雑な内容をアプリ・インフラ・統合に分割
4. **品質基準の明示**: 網羅性、実用性、保守性の基準
5. **フィードバックループ**: 生成結果に基づくプロンプト調整
### プロンプト改善のポイント
- **コンテキストの充実**: 要件定義書と基本設計書の詳細情報
- **制約条件の明確化**: 技術的制約と非機能要件の明示
- **出力例の提供**: 期待するテストケース形式の具体例
- **反復改善**: 生成結果に基づくプロンプト調整
## 🔄 継続的改善
### プロンプト改善サイクル
1. **生成**: プロンプトによるテストケース生成
2. **評価**: 生成結果の品質評価
3. **分析**: 改善点の特定
4. **改善**: プロンプトの調整
5. **再生成**: 改善されたプロンプトでの再生成
### 改善メトリクス
- **網羅性**: 要件定義書と基本設計書のカバー率
- **実用性**: 実装可能なテストケースの割合
- **一貫性**: テストケース全体の整合性
- **保守性**: 長期的な管理のしやすさ
- **分離性**: アプリ・インフラ・統合の適切な分離
📄 instructions/unit-test-implementation-prompt.md の内容を表示
# 単体テスト実装プロンプト
## 🎯 目的
テストケースをもとに、汎用的で実用的な単体テストを実装し、テスト実行方法をREADME.mdで作成します。
## 📁 既存ディレクトリ構造
```
general-ai-driven/
├── tests/
│ ├── app-test-cases.md # アプリケーションテストケース
│ ├── infra-test-cases.md # インフラストラクチャテストケース
│ └── integration-test-cases.md # 統合テストケース
├── app/
│ └── tests/ # アプリケーション単体テスト（作成予定）
└── infra/
└── tests/
└── unit/ # インフラストラクチャ単体テスト
└── test_infra_stack.py
```
## 📋 プロンプトテンプレート
### アプリケーション単体テスト実装プロンプト
```
あなたは経験豊富なQAエキスパートです。以下のテストケースをもとに、アプリケーションの単体テストを実装してください。
## プロジェクト情報
- プロジェクト名: [プロジェクト名]
- 技術スタック: [フロントエンド技術]
- テストフレームワーク: [Jest/Vitest/Mocha等]
- アーキテクチャ: [MVC/コンポーネント等]
## 入力資料
### テストケース
[`tests/app-test-cases.md` または `tests/infra-test-cases.md` の内容を貼り付け]
### 実装対象
- テスト対象ファイル: [ファイルパス]
- テスト対象関数/クラス: [関数名/クラス名]
- テスト種別: [正常系/異常系/境界値等]
- 参照テストケース: [TC-XXX-XXX]
## 要求事項
1. テストケースの全シナリオをカバーする単体テスト
2. 適切なモックとスタブの使用
3. テストデータの準備
4. エラーハンドリングのテスト
5. 境界値テストの実装
6. テストファイルは `app/tests/` ディレクトリに格納
7. `tests/app-test-cases.md` のテストケースIDと対応させる
8. テスト実行方法を `app/tests/README.md` で作成する
9. **Node.js**: pnpmを使用した仮想環境的な管理
10. **Python**: pipenvを使用した仮想環境管理
## 出力形式
### テストファイル構造
```javascript
// app/tests/[テスト対象ファイル名].test.js
import { [テスト対象関数/クラス] } from '../[テスト対象ファイル]';
describe('[テスト対象名]', () => {
// テストケースID: [TC-XXX-XXX]
describe('[テストケース名]', () => {
beforeEach(() => {
// セットアップ
});
afterEach(() => {
// クリーンアップ
});
it('[テストケース名] - [前提条件]', () => {
// Arrange
const input = [入力値];
// Act
const result = [テスト対象関数](input);
// Assert
expect(result).toBe([期待結果]);
});
});
});
```
### テストケース実装例
```javascript
// TC-APP-001: 正常なタスク作成
it('正常なタスク作成 - アプリが起動済み', () => {
// Arrange
const taskData = {
title: '買い物',
dueDate: '2024-01-15'
};
// Act
const result = createTask(taskData);
// Assert
expect(result).toBeDefined();
expect(result.title).toBe('買い物');
expect(result.dueDate).toBe('2024-01-15');
});
```
## 品質基準
- **網羅性**: テストケースの全シナリオをカバー
- **可読性**: テストコードが理解しやすい
- **保守性**: テストケースの変更に追従しやすい
- **実行速度**: 高速で安定したテスト実行
## テスト実行方法ドキュメント
- **アプリケーション**: `app/tests/README.md` でテスト実行方法を記載（pnpm使用）
- **インフラストラクチャ**: `infra/tests/README.md` でテスト実行方法を記載（pipenv使用）
```
### インフラストラクチャ単体テスト実装プロンプト
```
あなたは経験豊富なQAエキスパートです。以下のテストケースをもとに、インフラストラクチャの単体テストを実装してください。
## プロジェクト情報
- プロジェクト名: [プロジェクト名]
- 技術スタック: [AWS CDK/Python/TypeScript等]
- テストフレームワーク: [pytest/Jest等]
- アーキテクチャ: [CDKスタック/インフラコード]
## 入力資料
### テストケース
[`tests/infra-test-cases.md` の内容を貼り付け]
### 実装対象
- テスト対象ファイル: [ファイルパス]
- テスト対象スタック/コンストラクト: [スタック名/コンストラクト名]
- テスト種別: [リソース作成/設定確認/エラーハンドリング等]
- 参照テストケース: [TC-XXX-XXX]
## 要求事項
1. CDKスタックの単体テスト実装
2. AWSリソースの設定確認テスト
3. エラーケースのテスト
4. モックとスタブの適切な使用
5. インフラコードの品質テスト
6. テストファイルは `infra/tests/unit/` ディレクトリに格納
7. `tests/infra-test-cases.md` のテストケースIDと対応させる
8. 既存の `infra/tests/unit/test_infra_stack.py` の構造を参考にする
9. テスト実行方法を `infra/tests/README.md` で作成する
10. **Python**: pipenvを使用した仮想環境管理
## 出力形式
### テストファイル構造
```python
# infra/tests/unit/test_[テスト対象ファイル名].py
import pytest
import aws_cdk as core
import aws_cdk.assertions as assertions
from [テスト対象モジュール] import [テスト対象クラス]
class Test[テスト対象クラス]:
def setup_method(self):
# セットアップ
self.app = App()
self.stack = [テスト対象クラス](self.app, "TestStack")
def teardown_method(self):
# クリーンアップ
pass
# テストケースID: [TC-XXX-XXX]
def test_[テストケース名]_[前提条件](self):
# Arrange
[テストデータ準備]
# Act
[テスト対象メソッド実行]
# Assert
[期待結果の確認]
```
### テストケース実装例
```python
# TC-CDK-001: スタックデプロイ
def test_website_stack_deploy_cdk_initialized():
# Arrange
app = core.App()
stack = WebsiteStack(app, "TestWebsiteStack")
template = assertions.Template.from_stack(stack)
# Act & Assert
template.has_resource_properties("AWS::S3::Bucket", {
"BucketName": "todo-app-dev-website"
})
template.has_resource_properties("AWS::CloudFront::Distribution", {
"DistributionConfig": {
"Enabled": True
}
})
```
## 品質基準
- **網羅性**: テストケースの全シナリオをカバー
- **可読性**: テストコードが理解しやすい
- **保守性**: テストケースの変更に追従しやすい
- **実行速度**: 高速で安定したテスト実行
## テスト実行方法ドキュメント
- **アプリケーション**: `app/tests/README.md` でテスト実行方法を記載（pnpm使用）
- **インフラストラクチャ**: `infra/tests/README.md` でテスト実行方法を記載（pipenv使用）
## 🛠️ 詳細プロンプト（段階的生成）
### ステップ1: テストケース分析
```
以下のテストケースを分析し、単体テストの実装方針を決定してください：
**テストケース**
[`tests/app-test-cases.md` または `tests/infra-test-cases.md` の内容を貼り付け]
**分析要求**
1. テスト対象の特定
2. テストケースの分類（正常系/異常系/境界値）
3. モックが必要な依存関係の特定
4. テストデータの設計
5. テスト実行順序の決定
6. 既存のテストファイル構造との整合性確認
**出力**
- テスト対象のリスト
- テストケースの分類結果
- モック対象の依存関係
- テストデータ仕様
- 実装優先度
- ディレクトリ構造の提案
```
### ステップ2: テストファイル構造設計
```
以下の分析結果を基に、テストファイルの構造を設計してください：
**分析結果**
[ステップ1の出力結果]
**設計要求**
1. テストファイルの命名規則（app/tests/ または infra/tests/unit/ に格納）
2. テストスイートの構成
3. セットアップ・クリーンアップの設計
4. テストデータの管理方法
5. モック・スタブの設計
6. 既存のディレクトリ構造との整合性確認
**出力**
- テストファイル構造（app/tests/ または infra/tests/unit/ のパスを含む）
- テストスイート構成
- セットアップ・クリーンアップコード
- テストデータ管理方法
- モック・スタブ設計
- ディレクトリ構造の提案
```
### ステップ3: 個別テストケース実装
```
以下のテストケースを基に、具体的な単体テストを実装してください：
**テストケース**
[個別のテストケース]
**実装要求**
1. テストケースIDに基づく命名
2. 前提条件の適切なセットアップ
3. 入力値の準備
4. 期待結果の明確な定義
5. エラーハンドリングのテスト
**出力**
- 完全なテストコード（app/tests/ または infra/tests/unit/ のパスを含む）
- テストデータ
- モック・スタブ実装
- アサーション
- ファイルパスとディレクトリ構造
- 既存のテストファイルとの整合性確認
- テスト実行方法のREADME.mdファイル
```
## 📊 プロンプト使用ガイド
### 1. アプリケーション単体テスト実装
#### 1.0 テスト実行方法README.md
```markdown
# アプリケーションテスト実行ガイド
## 概要
TODO Appのアプリケーション単体テストの実行方法を説明します。
## 前提条件
- Node.js 18.0以上
- pnpm（推奨）または npm
- Jest テストフレームワーク
## セットアップ
```bash
# pnpmのインストール（初回のみ）
npm install -g pnpm
# 依存関係のインストール
pnpm install
# Jestのインストール
pnpm add --save-dev jest @testing-library/jest-dom
```
## テスト実行
```bash
# 全テストの実行
pnpm test
# 特定のテストファイルの実行
pnpm test TodoManager.test.js
# カバレッジ付きでテスト実行
pnpm test -- --coverage
# ウォッチモードでテスト実行
pnpm test -- --watch
```
## テストファイル構成
- `TodoManager.test.js`: タスク管理機能のテスト
- `StorageService.test.js`: データ層のテスト
- `jest.config.js`: Jest設定ファイル
- `setup.js`: テストセットアップファイル
## テストケース対応
- TC-APP-001 ~ TC-APP-020: フロントエンド機能テスト
- TC-DATA-001 ~ TC-DATA-012: データ層テスト
```
### 2. インフラストラクチャ単体テスト実装
#### 2.0 テスト実行方法README.md
```markdown
# インフラストラクチャテスト実行ガイド
## 概要
TODO Appのインフラストラクチャ単体テストの実行方法を説明します。
## 前提条件
- Python 3.12以上
- pipenv（仮想環境管理）
- AWS CDK
- pytest
## セットアップ
```bash
# 仮想環境の作成とアクティベート
cd infra
pipenv install
# テスト依存関係のインストール
pipenv install --dev pytest pytest-cov aws-cdk-lib
# 仮想環境の有効化
pipenv shell
```
## テスト実行
```bash
# 仮想環境内でテスト実行
pipenv run pytest
# 特定のテストファイルの実行
pipenv run pytest test_website_stack.py
# カバレッジ付きでテスト実行
pipenv run pytest --cov=stacks --cov=cdk_constructs
# 詳細出力でテスト実行
pipenv run pytest -v
# 仮想環境の終了
exit
```
## テストファイル構成
- `test_website_stack.py`: CDKスタックのテスト
- `test_website_construct.py`: AWSリソースのテスト
- `pytest.ini`: pytest設定ファイル
## テストケース対応
- TC-CDK-001 ~ TC-CDK-006: CDKスタックテスト
- TC-AWS-001 ~ TC-AWS-020: AWSリソーステスト
```
### 1. アプリケーション単体テスト実装
#### 1.1 フロントエンド機能テスト
```javascript
// app/tests/TodoManager.test.js
// テスト対象: TodoManager.js
// テストケース: TC-APP-001 ~ TC-APP-020
import { TodoManager } from '../scripts/models/TodoManager';
describe('TodoManager', () => {
let todoManager;
beforeEach(() => {
todoManager = new TodoManager();
// LocalStorage のモック
global.localStorage = {
getItem: jest.fn(),
setItem: jest.fn(),
removeItem: jest.fn()
};
});
describe('createTask', () => {
it('TC-APP-001: 正常なタスク作成 - アプリが起動済み', () => {
// Arrange
const taskData = { title: '買い物', dueDate: '2024-01-15' };
// Act
const result = todoManager.createTask(taskData);
// Assert
expect(result).toBeDefined();
expect(result.title).toBe('買い物');
expect(localStorage.setItem).toHaveBeenCalled();
});
});
});
```
#### 1.2 データ層テスト
```javascript
// app/tests/StorageService.test.js
// テスト対象: StorageService.js
// テストケース: TC-DATA-001 ~ TC-DATA-012
import { StorageService } from '../scripts/services/StorageService';
describe('StorageService', () => {
let storageService;
beforeEach(() => {
storageService = new StorageService();
// LocalStorage のモック
global.localStorage = {
getItem: jest.fn(),
setItem: jest.fn(),
removeItem: jest.fn()
};
});
describe('saveData', () => {
it('TC-DATA-001: タスクデータの保存 - LocalStorageが利用可能', () => {
// Arrange
const taskData = { id: '1', title: 'テストタスク' };
// Act
storageService.saveData('todos', taskData);
// Assert
expect(localStorage.setItem).toHaveBeenCalledWith(
'todos',
JSON.stringify(taskData)
);
});
});
});
```
### 2. インフラストラクチャ単体テスト実装
#### 2.1 CDKスタックテスト
```python
# infra/tests/unit/test_website_stack.py
# テスト対象: website_stack.py
# テストケース: TC-CDK-001 ~ TC-CDK-006
import aws_cdk as core
import aws_cdk.assertions as assertions
from stacks.website_stack import WebsiteStack
def test_tc_cdk_001_website_stack_deploy_cdk_initialized():
# Arrange
app = core.App()
stack = WebsiteStack(app, "TestWebsiteStack")
template = assertions.Template.from_stack(stack)
# Act & Assert
template.has_resource_properties("AWS::S3::Bucket", {
"BucketName": "todo-app-dev-website"
})
template.has_resource_properties("AWS::CloudFront::Distribution", {
"DistributionConfig": {
"Enabled": True
}
})
```
#### 2.2 AWSリソーステスト
```python
# infra/tests/unit/test_website_construct.py
# テスト対象: cdk_constructs/website_construct.py
# テストケース: TC-AWS-001 ~ TC-AWS-020
import aws_cdk as core
import aws_cdk.assertions as assertions
from cdk_constructs.website_construct import WebsiteConstruct
def test_tc_aws_001_s3_bucket_creation():
# Arrange
app = core.App()
construct = WebsiteConstruct(
app, "TestWebsite",
domain_name="test.example.com"
)
template = assertions.Template.from_stack(construct)
# Act & Assert
template.has_resource_properties("AWS::S3::Bucket", {
"WebsiteConfiguration": {
"IndexDocument": "index.html"
}
})
```
## 📋 品質チェックリスト
### アプリケーションテスト
- [ ] テストケースIDとの対応
- [ ] 正常系・異常系・境界値のカバー
- [ ] モック・スタブの適切な使用
- [ ] テストデータの準備
- [ ] エラーハンドリングのテスト
### インフラストラクチャテスト
- [ ] CDKスタックの設定確認
- [ ] AWSリソースの設定確認
- [ ] エラーケースのテスト
- [ ] モックの適切な使用
- [ ] テンプレート生成の確認
### 共通
- [ ] テストコードの可読性
- [ ] テスト実行速度
- [ ] テストの保守性
- [ ] カバレッジの確認
## 🔄 継続的改善
### プロンプト改善サイクル
1. **実装**: プロンプトによるテスト実装
2. **評価**: 実装結果の品質評価
3. **分析**: 改善点の特定
4. **改善**: プロンプトの調整
5. **再実装**: 改善されたプロンプトでの再実装
### 改善メトリクス
- **網羅性**: テストケースのカバー率
- **実用性**: 実際に実行可能なテスト
- **保守性**: テストコードの管理しやすさ
- **実行速度**: テスト実行の効率性
- **ドキュメント品質**: README.mdの分かりやすさと実用性
成果物: テストケースとテストコード
5. 🚀 デプロイフェーズ
デプロイの重要性
デプロイフェーズは、開発したシステムを環境に安全に展開する重要な段階です。適切なデプロイプロセスにより、システムの可用性と安定性を保ちながら、ユーザーに価値を提供できます。また、自動化されたデプロイプロセスにより、人的ミスを防ぎ、一貫性のある展開が可能になります。
AIとの協働で効率化できること
- 自動化されたCI/CDパイプライン: AIが最適なワークフローを設計し、自動化されたデプロイプロセスを構築
- デプロイ前の品質保証: コードの構文チェック、セキュリティスキャン、テスト実行を自動化
- ファイルの構文チェック: 設定ファイルやコードの構文エラーを事前に検出し、修正提案
- デプロイ前の自動チェック: 環境への影響を事前に分析し、問題を早期発見
デプロイフェーズでは、instructions/github-actions-workflow-prompt.mdのプロンプトを使用します。このプロンプトは、GitHub Actions CI/CDエキスパートとして、高品質で保守性の高いGitHub Actionsワークフローを作成するためのものです。
📄 instructions/github-actions-workflow-prompt.md の内容を表示
# GitHub Actions ワークフロー作成プロンプト
## 役割定義
あなたは「GitHub Actions CI/CDエキスパート」です。設計書とテストケースをもとに、高品質で保守性の高いGitHub Actionsワークフローを作成する専門家として活動してください。
## 作成方針
### 基本原則
1. **設計書準拠**: インフラ設計書とテストケースの仕様を厳密に遵守する
2. **段階的作成**: CI、CD、CDK Diffを段階的に作成し、各段階で動作確認を行う
3. **セキュリティ重視**: OIDC認証、最小権限の原則を徹底する
4. **効率性**: ジョブの並列化、キャッシュ活用で実行時間を最適化
5. **可視性**: わかりやすいログ出力、ステータス表示
6. **保守性**: 環境変数、シークレット管理の一元化
### 技術スタック
- **ワークフロー言語**: YAML
- **認証方式**: OIDC（OpenID Connect）
- **デプロイツール**: AWS CDK
- **テストツール**: pytest（Infra）、Vitest（App）
- **リンター**: flake8, black（Python）、ESLint（JavaScript）
---
## 作成手順
### ステップ1: CI ワークフロー作成（`.github/workflows/ci.yml`）
#### 目的
Pull Request時に自動テスト・Lintを実行し、コード品質を保証
#### 実装内容
**1.1 トリガー設定**
```yaml
on:
pull_request:
branches: [main, develop]
push:
branches: [main]
```
**1.2 アプリケーションテストジョブ**
```yaml
test-app:
name: Test Application
runs-on: ubuntu-latest
steps:
- Checkout
- Node.js セットアップ
- pnpm セットアップ
- 依存関係インストール
- ユニットテスト実行
- カバレッジ生成
- Codecov アップロード
```
**1.3 インフラテストジョブ**
```yaml
test-infra:
name: Test Infrastructure
runs-on: ubuntu-latest
steps:
- Checkout
- Python セットアップ
- 依存関係インストール
- pytest実行
- カバレッジ生成
- Codecov アップロード
```
**1.4 Lintジョブ**
```yaml
lint:
name: Lint Code
runs-on: ubuntu-latest
steps:
- Checkout
- Python lint (flake8, black)
- JavaScript lint (ESLint)
```
#### 検証ポイント
- [ ] 全ジョブが並列実行される
- [ ] テスト失敗時にPRがブロックされる
- [ ] カバレッジレポートが生成される
- [ ] 実行時間が5分以内
---
### ステップ2: CD ワークフロー - Dev環境（`.github/workflows/deploy-dev.yml`）
#### 目的
main ブランチマージ時に開発環境へ自動デプロイ
#### 実装内容
**2.1 トリガー設定**
```yaml
on:
push:
branches: [main]
permissions:
id-token: write
contents: read
```
**2.2 インフラデプロイジョブ**
```yaml
deploy-infra:
name: Deploy Infrastructure (Dev)
runs-on: ubuntu-latest
environment: dev
steps:
- Checkout
- Python/Node.js セットアップ
- AWS CDK インストール
- AWS認証（OIDC）
- CDK Synth
- CDK Deploy
- スタックOutput取得
```
**2.3 アプリデプロイジョブ**
```yaml
deploy-app:
name: Deploy Application (Dev)
needs: deploy-infra
runs-on: ubuntu-latest
environment: dev
steps:
- Checkout
- AWS認証（OIDC）
- S3 Sync（キャッシュ制御付き）
* HTML: max-age=300
* CSS/JS: max-age=31536000
* JSON: max-age=86400
- CloudFront Invalidation
- デプロイサマリー出力
```
#### 検証ポイント
- [ ] インフラ→アプリの順でデプロイされる
- [ ] 各ファイルタイプで適切なCache-Controlが設定される
- [ ] CloudFrontキャッシュが無効化される
- [ ] スタックOutputが正しく取得される
---
### ステップ3: CD ワークフロー - Prod環境（`.github/workflows/deploy-prod.yml`）
#### 目的
タグ作成時に本番環境へ手動承認後デプロイ
#### 実装内容
**3.1 トリガー設定**
```yaml
on:
push:
tags: ['v*.*.*']
permissions:
id-token: write
contents: read
```
**3.2 手動承認ジョブ**
```yaml
approval:
name: Manual Approval
runs-on: ubuntu-latest
environment: prod-approval
steps:
- 承認待機メッセージ
```
**3.3 インフラデプロイジョブ**
```yaml
deploy-infra:
needs: approval
environment: prod
steps:
- CDK Deploy (prod環境)
```
**3.4 アプリデプロイジョブ**
```yaml
deploy-app:
needs: deploy-infra
environment: prod
steps:
- S3 Sync
- CloudFront Invalidation
```
#### 検証ポイント
- [ ] 承認なしではデプロイされない
- [ ] タグ名が正しく取得される
- [ ] prod環境にのみデプロイされる
- [ ] デプロイログに環境情報が表示される
---
### ステップ4: CDK Diff ワークフロー（`.github/workflows/cdk-diff.yml`）
#### 目的
インフラ変更時にCDK差分をPRコメントとして投稿
#### 実装内容
**4.1 トリガー設定**
```yaml
on:
pull_request:
paths: ['infra/**']
branches: [main]
permissions:
id-token: write
contents: read
pull-requests: write
```
**4.2 CDK Diffジョブ**
```yaml
cdk-diff:
name: CDK Diff
runs-on: ubuntu-latest
steps:
- Checkout
- CDK セットアップ
- AWS認証（OIDC）
- cdk diff 実行
- 差分取得・保存
- PRコメント投稿（github-script）
* 既存コメントは更新
* なければ新規作成
```
#### 検証ポイント
- [ ] インフラ変更時のみ実行される
- [ ] CDK diffが正しく実行される
- [ ] PRコメントが投稿される
- [ ] 既存コメントが更新される
---
## 環境設定ガイド
### GitHub Environments 設定
**1. dev環境**
```yaml
Environment: dev
保護ルール: なし
Required reviewers: -
Secrets:
- AWS_ROLE_ARN_DEV
```
**2. prod-approval環境**
```yaml
Environment: prod-approval
保護ルール: 承認必須
Required reviewers: 1名以上
Secrets: なし
```
**3. prod環境**
```yaml
Environment: prod
保護ルール: 承認必須
Required reviewers: 1名以上
Secrets:
- AWS_ROLE_ARN_PROD
```
### GitHub Secrets 設定
| シークレット名 | 説明 | 値の例 |
|--------------|------|--------|
| AWS_ROLE_ARN_DEV | Dev環境デプロイ用IAMロール | arn:aws:iam::123456789012:role/GitHubActionsDev |
| AWS_ROLE_ARN_PROD | Prod環境デプロイ用IAMロール | arn:aws:iam::123456789012:role/GitHubActionsProd |
---
## AWS設定ガイド
### OIDC プロバイダー作成
```bash
aws iam create-open-id-connect-provider \
--url https://token.actions.githubusercontent.com \
--client-id-list sts.amazonaws.com \
--thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1
```
### IAM ロール作成
**信頼ポリシー（Trust Policy）**
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:OWNER/REPO:*"
}
}
}
]
}
```
**権限ポリシー（Permission Policy）**
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:*",
"s3:*",
"cloudfront:*",
"cloudwatch:*",
"sns:*",
"iam:PassRole",
"iam:GetRole",
"iam:CreateRole",
"iam:DeleteRole",
"iam:AttachRolePolicy",
"iam:DetachRolePolicy"
],
"Resource": "*"
}
]
}
```
---
## ワークフロー設計パターン
### パターン1: 基本CI（テスト + Lint）
**用途**: Pull Request時の品質チェック
**構成**:
- test-app（並列）
- test-infra（並列）
- lint（並列）
**所要時間**: 3-5分
### パターン2: 段階的CD（インフラ → アプリ）
**用途**: デプロイメント
**構成**:
- deploy-infra（直列）
- deploy-app（直列、infraの後）
**所要時間**: 10-20分
### パターン3: 承認付きCD（承認 → デプロイ）
**用途**: 本番環境デプロイ
**構成**:
- approval（手動承認）
- deploy-infra（承認後）
- deploy-app（infraの後）
**所要時間**: 承認時間 + 15-25分
---
## ベストプラクティス
### セキュリティ
1. **OIDC認証を使用**
- 長期的なアクセスキーを使わない
- 一時的な認証情報のみ使用
2. **最小権限の原則**
- 必要最小限の権限のみ付与
- 環境ごとに異なるロール
3. **シークレット管理**
- GitHub Secretsで機密情報管理
- コードにハードコードしない
### パフォーマンス
1. **並列実行**
- 独立したジョブは並列化
- test-app と test-infra を並列実行
2. **キャッシュ活用**
- Node.js: pnpm キャッシュ
- Python: pip キャッシュ
- CDK: cdk.out キャッシュ
3. **条件付き実行**
- `paths` フィルターで不要な実行を回避
- `if` 条件で動的制御
### 可視性
1. **わかりやすい名前**
- ジョブ名、ステップ名を明確に
2. **サマリー出力**
- デプロイ結果をサマリーに表示
- エラー時は詳細ログ
3. **ステータスバッジ**
- README.mdにバッジ追加
---
## ファイル構成
```
.github/
└── workflows/
├── ci.yml # CI: テスト + Lint
├── deploy-dev.yml # CD: Dev環境デプロイ
├── deploy-prod.yml # CD: Prod環境デプロイ
└── cdk-diff.yml # CDK差分表示
```
---
## テンプレート
### CI ワークフローテンプレート
```yaml
name: CI - Test & Lint
on:
pull_request:
branches: [main, develop]
push:
branches: [main]
jobs:
test-app:
name: Test Application
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '18'
- uses: pnpm/action-setup@v2
with:
version: 8
- run: cd app && pnpm install
- run: cd app && pnpm test
- run: cd app && pnpm test:coverage
- uses: codecov/codecov-action@v3
with:
files: ./app/coverage/coverage-final.json
test-infra:
name: Test Infrastructure
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v4
with:
python-version: '3.11'
- run: cd infra && pip install -r requirements.txt
- run: cd infra && pytest -v --cov=stacks --cov=cdk_constructs
```
### CD ワークフローテンプレート
```yaml
name: CD - Deploy to Dev
on:
push:
branches: [main]
permissions:
id-token: write
contents: read
jobs:
deploy-infra:
name: Deploy Infrastructure
runs-on: ubuntu-latest
environment: dev
steps:
- uses: actions/checkout@v4
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN_DEV }}
aws-region: ap-northeast-1
- run: cd infra && cdk deploy --require-approval never
deploy-app:
name: Deploy Application
needs: deploy-infra
runs-on: ubuntu-latest
environment: dev
steps:
- uses: actions/checkout@v4
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN_DEV }}
aws-region: ap-northeast-1
- run: aws s3 sync app/web/ s3://BUCKET_NAME/ --delete
- run: aws cloudfront create-invalidation --distribution-id DIST_ID --paths "/*"
```
### CDK Diff ワークフローテンプレート
```yaml
name: CDK Diff on PR
on:
pull_request:
paths: ['infra/**']
branches: [main]
permissions:
id-token: write
contents: read
pull-requests: write
jobs:
cdk-diff:
name: CDK Diff
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN_DEV }}
aws-region: ap-northeast-1
- run: cd infra && cdk diff > diff_output.txt
- uses: actions/github-script@v7
with:
script: |
// PRにコメント投稿
```
---
## プロジェクト情報
- プロジェクト名: [プロジェクト名]
- 技術スタック: [AWS CDK, S3, CloudFront等]
- リポジトリ: [owner/repo]
- 環境: dev, prod
## 入力資料
### インフラ設計書
[infra_basic_design.md の内容]
### テストケース
[tests/infra-test-cases.md の内容]
## 要求事項
1. CI ワークフロー作成（.github/workflows/ci.yml）
2. CD ワークフロー作成（dev環境、prod環境）
3. CDK Diff ワークフロー作成
4. AWS OIDC設定手順のドキュメント
5. README.mdへのバッジ追加
## 出力
- .github/workflows/*.yml（4ファイル）
- docs/CICD.md（CI/CDガイド）
- 環境設定手順書
## チェックリスト
### CI ワークフロー
- [ ] 全テストが実行される
- [ ] Lintが実行される
- [ ] カバレッジレポートが生成される
- [ ] PRステータスチェックが設定される
- [ ] 並列実行が適切に設定されている
### CD ワークフロー（Dev）
- [ ] OIDC認証が設定されている
- [ ] インフラ→アプリの順でデプロイされる
- [ ] 環境変数が正しく設定されている
- [ ] エラーハンドリングが実装されている
- [ ] デプロイサマリーが出力される
### CD ワークフロー（Prod）
- [ ] 手動承認が設定されている
- [ ] タグトリガーが設定されている
- [ ] 本番環境のシークレットを使用
- [ ] ロールバック手順が文書化されている
### CDK Diff ワークフロー
- [ ] インフラ変更時のみ実行される
- [ ] CDK diffが正しく実行される
- [ ] PRコメントが投稿される
- [ ] 既存コメントが更新される
- [ ] 差分が読みやすく整形されている
### セキュリティ
- [ ] 長期アクセスキーを使用していない
- [ ] OIDC認証を使用
- [ ] 最小権限の原則に従っている
- [ ] シークレットがハードコードされていない
- [ ] 環境ごとに異なるロールを使用
### ドキュメント
- [ ] ワークフロー図がある
- [ ] 環境設定手順がある
- [ ] トラブルシューティングがある
- [ ] ベストプラクティスが記載されている
成果物: .github/workflows/にGithub Actionsのワークフロー
6. 🔄 レビュー・検証フェーズ
レビュー・検証の重要性
レビュー・検証フェーズは、プロジェクトの完了ではなく、継続的改善の始まりです。環境で動作しているシステムを監視し、ユーザーフィードバックを収集し、継続的に改善していくことが重要です。この段階での適切なレビューにより、システムの品質向上と長期的な保守性を確保できます。
AIとの協働で効率化できること
- 包括的なコードレビュー支援: AIが180点満点のチェックリストに基づいてコードを評価し、人間が具体的な改善点を検討
- 品質指標の客観的評価: 可読性、セキュリティ、パフォーマンス等の品質指標をAIが分析し、人間が優先順位を決定
- 継続的改善の提案: システムの現状分析から具体的な改善提案をAIが生成し、人間が実装方針を判断
レビュー・検証フェーズでは、instructions/review-check-list.mdのチェックリストを使用します。このチェックリストは、コードレビューを体系的に行い、10点満点で評価するためのものです。
📄 instructions/review-check-list.md の内容を表示
# コードレビューチェックリスト（10点満点評価）
## 使用方法
### 1. レビュー実施手順
**重要**: 各項目を1つずつ丁寧に確認し、具体的な根拠とともに評価してください。
#### ステップ1: 事前準備
- [ ] レビュー対象のコードを完全に理解する
- [ ] 要件定義書・設計書を確認する
- [ ] 関連するテストケースを確認する
#### ステップ2: 項目別レビュー
各項目について以下を実施：
1. **コードの該当箇所を特定**
2. **具体的な確認内容を記録**
3. **問題点があれば具体的な例を記載**
4. **改善案があれば具体的に提案**
5. **10点満点で評価**
#### ステップ3: 総合評価
- [ ] 各カテゴリの点数を集計
- [ ] 総合スコア（180点満点）を算出
- [ ] 10点満点スコアに換算
- [ ] 評価グレードを決定
- [ ] 主要な改善点を整理
### 2. 結果の保存
レビュー完了後、以下の手順で結果を保存してください：
```bash
# レビュー結果をdocsディレクトリに保存
cp instructions/review-check-list.md docs/review-results-YYYY-MM-DD-PR番号.md
```
### 3. ファイル命名規則
- `review-results-2024-01-15-PR123.md`
- `review-results-2024-01-15-feature-password-generator.md`
### 4. 結果の共有
- レビュー結果は`docs/`ディレクトリに保存
- PRコメントやSlack等で結果を共有
- 改善が必要な項目はIssue化を検討
### 5. 使用例
```bash
# 1. レビューチェックリストをコピー
cp instructions/review-check-list.md docs/review-results-2024-01-15-PR123.md
# 2. レビュー結果を記入
# 各項目の点数を記入し、総合評価を算出
# 3. 結果をコミット
git add docs/review-results-2024-01-15-PR123.md
git commit -m "docs: コードレビュー結果を追加 (PR123)"
```
### 6. レビュー実施のベストプラクティス
#### 時間配分の目安
- **事前準備**: 15分（コード理解、設計書確認）
- **項目別レビュー**: 各項目5-10分（合計60-90分）
- **総合評価**: 15分（点数集計、改善点整理）
- **結果記録**: 15分（ドキュメント作成）
#### レビュー時の注意点
- **1項目ずつ集中**: 一度に複数項目を確認しない
- **具体的な記録**: 問題箇所は行番号とコード例を記載
- **改善案の提示**: 問題点だけでなく解決策も提案
- **優先度の明確化**: 重要度に応じて改善順序を整理
#### レビュー結果の活用
- **PRコメント**: 重要な問題点をPRコメントで共有
- **Issue化**: 大きな改善点はIssueとして管理
- **チーム共有**: 学習ポイントをチーム内で共有
## 評価方法
### 評価基準
各項目を以下の基準で10点満点で評価してください：
- **10点**: 完璧に実装されている
- **8-9点**: ほぼ完璧、軽微な改善点がある
- **6-7点**: 良好、いくつかの改善点がある
- **4-5点**: 普通、重要な改善点がある
- **1-3点**: 不十分、大幅な改善が必要
- **0点**: 未実装または重大な問題がある
### レビュー時の注意事項
- **具体的な根拠**: 評価理由を必ず記載する
- **コード例**: 問題箇所があれば具体的なコード例を示す
- **改善案**: 低評価の場合は具体的な改善案を提案する
- **一貫性**: 同じ問題が複数箇所にある場合は全て指摘する
- **優先度**: 重要な問題と軽微な問題を区別する
### レビュー記録テンプレート
各項目のレビュー時は以下の形式で記録してください：
```
## [項目名] レビュー結果
### 確認内容
- 確認したファイル: `path/to/file.js`
- 確認した行数: 10-25行目
- 確認した関数: `functionName()`
### 発見事項
- ✅ 良好な点: [具体的な内容]
- ⚠️ 改善点: [具体的な問題と改善案]
- ❌ 問題点: [具体的な問題と修正案]
### 評価根拠
[なぜこの点数なのか、具体的な理由を記載]
**評価: X/10点**
```
## アプリケーション層（フロントエンド）
### 可読性 (10点満点)
#### レビューポイント
- [ ] **変数名・関数名**: 意味が明確で、用途が分かりやすいか
- 例: `userData` vs `data`, `calculateTotalPrice()` vs `calc()`
- [ ] **コメント**: 複雑なロジックに適切な説明があるか
- 例: アルゴリズムの説明、ビジネスロジックの説明
- [ ] **コード構造**: 関数の長さ、ネストの深さが適切か
- 例: 1関数50行以内、ネスト3階層以内
- [ ] **不要コード**: デッドコード、コメントアウトが残っていないか
#### 確認すべきファイル
- 主要なアプリケーションファイル
- 複雑なロジックを含む関数
- 新規追加・変更されたファイル
**評価: ___/10点**
### 一貫性 (10点満点)
#### レビューポイント
- [ ] **コーディング規約**: インデント、セミコロン、クォート等が統一されているか
- 例: スペース2個 vs 4個、シングルクォート vs ダブルクォート
- [ ] **命名規則**: camelCase、PascalCase等が適切に使い分けられているか
- 例: `userName` (変数), `UserService` (クラス), `CONSTANT_VALUE` (定数)
- [ ] **ファイル構造**: ディレクトリ構成、ファイル名がプロジェクト標準に従っているか
- 例: `scripts/`, `styles/`, `data/` の配置
#### 確認すべきファイル
- 全アプリケーションファイル
- スタイルファイル
- テンプレートファイル
- 設定ファイル
**評価: ___/10点**
### 機能・ロジック (10点満点)
#### レビューポイント
- [ ] **要件実装**: 設計書通りの機能が実装されているか
- 例: 要件定義書に記載された全機能が実装されているか
- [ ] **エッジケース**: 異常な入力値や特殊な状況に対応しているか
- 例: 空文字列、null、undefined、非常に長い文字列
- [ ] **境界値**: 最小値・最大値での動作が正しいか
- 例: 最小値・最大値での動作確認
#### 確認すべきファイル
- 主要な機能実装ファイル
- バリデーション処理
- ビジネスロジック
**評価: ___/10点**
### エラーハンドリング (10点満点)
#### レビューポイント
- [ ] **例外処理**: try-catch文が適切に使用されているか
- 例: 非同期処理、外部API呼び出し、ファイル操作
- [ ] **エラーメッセージ**: ユーザーにとって分かりやすいメッセージか
- 例: 「エラーが発生しました」→「具体的な改善案を提示」
- [ ] **ユーザーフィードバック**: エラー時に適切なUI表示があるか
- 例: エラーメッセージの表示、ローディング状態の管理
#### 確認すべきファイル
- エラーハンドリングを含む関数
- ユーザー入力処理
- 非同期処理
**評価: ___/10点**
### セキュリティ (10点満点)
#### レビューポイント
- [ ] **機密情報保護**: パスワード等の機密情報がログに出力されていないか
- 例: 機密情報をログ出力する危険なコードがないか
- [ ] **入力値検証**: ユーザー入力が適切にサニタイズされているか
- 例: HTMLエスケープ、文字数制限、文字種制限
- [ ] **XSS対策**: 動的コンテンツ生成時のXSS対策が実装されているか
- 例: `innerHTML` の代わりに `textContent` を使用
- [ ] **CSP設定**: Content Security Policyが適切に設定されているか
- 例: `default-src 'self'` 等の適切なポリシー
#### 確認すべきファイル
- ユーザー入力処理
- DOM操作処理
- テンプレートファイル（セキュリティ設定）
**評価: ___/10点**
### パフォーマンス (10点満点)
#### レビューポイント
- [ ] **不要な処理**: 無駄な計算、冗長なループがないか
- 例: ループ内でのDOM操作、重複する計算
- [ ] **メモリ使用量**: 大規模データ処理時のメモリリークがないか、効率的か
- 例: 大規模データの遅延ロード、不要なオブジェクトの解放
- [ ] **バンドルサイズ**: JavaScript/CSSのバンドルサイズが最適化されているか
- 例: Tree Shaking、Code Splittingの適用
- [ ] **画像・アセット**: 画像やその他のアセットが適切に圧縮・最適化されているか
- 例: WebP形式の利用、SVGの最適化
#### 確認すべきファイル
- 主要なアプリケーションファイル
- スタイルファイル
- アセットファイル
- ビルド設定ファイル
**評価: ___/10点**
### テスト (10点満点)
#### レビューポイント
- [ ] **単体テスト**: 主要な関数やモジュールに単体テストが記述されているか
- 例: 主要なモジュール、クラス、関数
- [ ] **統合テスト**: 複数のモジュール連携やUI操作のテストが実装されているか
- 例: ユーザー操作からUI更新までの一連の流れ
- [ ] **テストケース**: 要件定義書に基づき、十分なテストケースがカバーされているか
- 例: 正常系、異常系、境界値、エッジケース
#### 確認すべきファイル
- テストディレクトリ内の全テストファイル
- 要件定義書
- 設計書
**評価: ___/10点**
### ユーザビリティ・アクセシビリティ (10点満点)
#### レビューポイント
- [ ] **UIの直感性**: ユーザーインターフェースが直感的で使いやすいか
- 例: ボタンの配置、入力フィールドの分かりやすさ
- [ ] **エラーメッセージ**: ユーザーに分かりやすいエラーメッセージが表示されるか
- 例: 具体的な改善提案、操作ガイド
- [ ] **レスポンシブデザイン**: 様々なデバイス（PC, タブレット, スマホ）で適切に表示・操作できるか
- 例: メディアクエリの適用、Flexbox/Gridレイアウト
- [ ] **ブラウザ互換性**: 主要なモダンブラウザで問題なく動作するか
- 例: Chrome, Firefox, Safari, Edgeでの動作確認
- [ ] **WCAG準拠**: WCAG 2.1 AAレベルのガイドラインに準拠した実装がされているか
- 例: `alt`属性、`aria-label`、適切なセマンティックHTML
- [ ] **キーボード操作**: 全ての機能がマウスなしでキーボード操作可能か
- 例: Tabキーでのフォーカス移動、Enterキーでのボタン操作
- [ ] **スクリーンリーダー対応**: スクリーンリーダーでコンテンツが正しく読み上げられるか
- 例: ARIAロール、状態属性の利用
- [ ] **色のコントラスト**: テキストと背景の色のコントラスト比がWCAG基準を満たしているか
- 例: コントラスト比チェッカーでの確認
#### 確認すべきファイル
- メインテンプレートファイル
- スタイルファイル
- UI操作関連ファイル
**評価: ___/10点**
### ドキュメント (10点満点)
#### レビューポイント
- [ ] **Docstring/JSDoc**: 関数、クラス、モジュールに適切なDocstring/JSDocが記述されているか
- 例: 引数、戻り値、概要の説明
- [ ] **複雑なロジック**: 複雑なアルゴリズムやビジネスロジックにコメントが記述されているか
- 例: 複雑なアルゴリズムの詳細説明
- [ ] **APIドキュメント**: 外部公開されるAPI（もしあれば）のドキュメントが更新されているか
- 例: 主要な関数のドキュメント
#### 確認すべきファイル
- 全アプリケーションファイル
- READMEファイル
- 設計書
**評価: ___/10点**
---
## インフラ層（AWS CDK）
### インフラ設計 (10点満点)
#### レビューポイント
- [ ] **アーキテクチャ設計**: 要件に適合したインフラアーキテクチャが設計されているか
- 例: S3 + CloudFrontの静的Webサイト構成、適切なリソース配置
- [ ] **セキュリティ設計**: セキュリティ要件を満たす設計がされているか
- 例: HTTPS強制、セキュリティヘッダー、OAC（Origin Access Control）
- [ ] **スケーラビリティ**: 将来の拡張性を考慮した設計がされているか
- 例: 環境別設定、モジュール化されたコンストラクト
#### 確認すべきファイル
- メインスタックファイル
- コンストラクトディレクトリ内の全ファイル
- インフラ設計書
**評価: ___/10点**
### CDKコード品質 (10点満点)
#### レビューポイント
- [ ] **コード構造**: CDKコードが適切にモジュール化されているか
- 例: スタック、コンストラクト、設定の分離
- [ ] **命名規則**: リソース名が一貫性があり、分かりやすいか
- 例: `${ProjectName}-${env}-ResourceName`
- [ ] **設定管理**: 環境別設定が適切に管理されているか
- 例: 環境別設定ファイルの活用
- [ ] **エラーハンドリング**: 適切なエラーハンドリングが実装されているか
- 例: バリデーション、例外処理
#### 確認すべきファイル
- インフラディレクトリ内の全ファイル
- 設定ディレクトリ内の設定ファイル
**評価: ___/10点**
### セキュリティ (10点満点)
#### レビューポイント
- [ ] **HTTPS強制**: CloudFrontでHTTPSが強制されているか
- 例: `ViewerProtocolPolicy.HTTPS_ONLY`
- [ ] **セキュリティヘッダー**: 適切なセキュリティヘッダーが設定されているか
- 例: CSP, HSTS, X-Frame-Options
- [ ] **アクセス制御**: S3バケットへの直接アクセスが適切に制限されているか
- 例: OAC（Origin Access Control）の設定
- [ ] **ログ設定**: セキュリティ監査に必要なログが設定されているか
- 例: CloudFrontアクセスログ、S3アクセスログ
#### 確認すべきファイル
- CDN配信設定ファイル
- 静的Webサイト設定ファイル
**評価: ___/10点**
### 監視・運用 (10点満点)
#### レビューポイント
- [ ] **CloudWatch監視**: 適切なメトリクス監視が設定されているか
- 例: 4xx/5xxエラー率、リクエスト数、レスポンス時間
- [ ] **アラーム設定**: 異常検知のためのアラームが設定されているか
- 例: エラー率閾値、レスポンス時間閾値
- [ ] **通知設定**: アラーム発生時の通知が設定されているか
- 例: SNSトピック、メール通知
- [ ] **ダッシュボード**: 運用に必要なダッシュボードが作成されているか
- 例: 主要メトリクスの可視化
#### 確認すべきファイル
- 監視設定ファイル
**評価: ___/10点**
### テスト (10点満点)
#### レビューポイント
- [ ] **単体テスト**: CDKコンストラクトに単体テストが実装されているか
- 例: リソース数の確認、プロパティの検証
- [ ] **統合テスト**: スタック全体の統合テストが実装されているか
- 例: デプロイテスト、リソース間の依存関係確認
- [ ] **テストカバレッジ**: 主要なリソースがテストでカバーされているか
- 例: 主要なAWSリソース
#### 確認すべきファイル
- インフラテストディレクトリ内の全テストファイル
**評価: ___/10点**
---
## AI駆動開発固有
### AIコード品質 (10点満点)
#### レビューポイント
- [ ] **要件適合性**: AIが生成したコードが要件定義書の内容を正確に満たしているか
- 例: 全機能が実装されているか、非機能要件が考慮されているか
- [ ] **アーキテクチャ適合性**: AIコードが既存のアーキテクチャ設計（モジュール構成、技術スタック）に適合しているか
- 例: 技術スタックの原則、モジュール間の依存関係
- [ ] **プロンプト設計**: プロンプトが明確で、意図通りのコードが生成されているか
- 例: プロンプトの具体性、制約条件の明確さ
#### 確認すべきファイル
- 全コードファイル
- プロンプトディレクトリ内のファイル
**評価: ___/10点**
### 可観測性 (10点満点)
#### レビューポイント
- [ ] **ログレベル**: 適切なログレベル（info, warn, error）で出力されているか
- 例: 開発環境での詳細ログ、本番環境でのエラーログ
- [ ] **メトリクス**: 主要なパフォーマンス指標（例: 処理時間、エラー数）が記録されているか
- 例: Google Analytics、カスタムイベント
- [ ] **トレーシング**: 処理の流れを追跡できるトレーシングが有効になっているか
- 例: OpenTelemetry、カスタムトレースID
- [ ] **デバッグ情報**: 開発・デバッグに必要な情報が適切に管理・出力されているか
- 例: Source Map、開発者ツールの活用
#### 確認すべきファイル
- メインアプリケーションファイル
- 各モジュールファイル
**評価: ___/10点**
---
## 最終確認
### デプロイ前 (10点満点)
#### レビューポイント
- [ ] **テスト通過**: 全ての単体テスト、統合テストが成功しているか
- 例: テストコマンドの実行結果
- [ ] **ビルドエラー**: ビルドプロセスでエラーが発生しないか
- 例: ビルドコマンドの実行結果
- [ ] **環境設定**: 開発環境、本番環境固有の設定が正しく適用されているか
- 例: APIエンドポイント、環境変数
#### 確認すべきファイル
- パッケージ設定ファイル
- テスト結果レポート
- ビルドログ
**評価: ___/10点**
### 文書化 (10点満点)
#### レビューポイント
- [ ] **CHANGELOG**: 変更内容がCHANGELOGに記録されているか
- 例: 新機能、バグ修正、パフォーマンス改善
- [ ] **README更新**: 必要に応じてREADMEが最新の状態に更新されているか
- 例: 新機能の追加、セットアップ手順の変更
#### 確認すべきファイル
- CHANGELOGファイル（もしあれば）
- READMEファイル
**評価: ___/10点**
---
## 総合評価
### 各カテゴリの点数
#### アプリケーション層（フロントエンド）
- **可読性**: ___/10点
- **一貫性**: ___/10点
- **機能・ロジック**: ___/10点
- **エラーハンドリング**: ___/10点
- **セキュリティ**: ___/10点
- **パフォーマンス**: ___/10点
- **テスト**: ___/10点
- **ユーザビリティ・アクセシビリティ**: ___/10点
- **ドキュメント**: ___/10点
**アプリケーション層小計: ___/90点**
#### インフラ層（AWS CDK）
- **インフラ設計**: ___/10点
- **CDKコード品質**: ___/10点
- **セキュリティ**: ___/10点
- **監視・運用**: ___/10点
- **テスト**: ___/10点
**インフラ層小計: ___/50点**
#### AI駆動開発・最終確認
- **AIコード品質**: ___/10点
- **可観測性**: ___/10点
- **デプロイ前**: ___/10点
- **文書化**: ___/10点
**AI駆動開発・最終確認小計: ___/40点**
### 総合スコア
**合計: ___/180点**
### 10点満点換算
**10点満点スコア: ___/10点**
*計算式: (総合スコア ÷ 180) × 10 = 10点満点スコア*
### 総合評価（180点満点）
- **162-180点**: 優秀 (A+)
- **144-161点**: 良好 (A)
- **126-143点**: 普通 (B)
- **108-125点**: 改善必要 (C)
- **90-107点**: 大幅改善必要 (D)
- **90点未満**: 不合格 (F)
### 総合評価（10点満点）
- **9.0-10.0点**: 優秀 (A+)
- **8.0-8.9点**: 良好 (A)
- **7.0-7.9点**: 普通 (B)
- **6.0-6.9点**: 改善必要 (C)
- **5.0-5.9点**: 大幅改善必要 (D)
- **5.0点未満**: 不合格 (F)
### 改善提案
（低得点の項目について具体的な改善案を記述）
### レビュー担当者
- 名前: _______________
- 日付: _______________
- 署名: _______________
---
## レビュー結果保存用テンプレート
### レビュー情報
- **レビュー対象**: _______________ (PR番号や機能名)
- **レビュー実施日**: _______________
- **レビュー担当者**: _______________
- **対象ブランチ**: _______________
### 総合評価結果
**総合スコア: ___/180点**
**10点満点スコア: ___/10点 (評価: _____)**
### 主要な改善点
1. _______________
2. _______________
3. _______________
### 承認可否
- [ ] 承認 (A+ または A評価)
- [ ] 条件付き承認 (B評価、改善後承認)
- [ ] 要修正 (C評価以下、再レビュー必要)
### 次回レビュー予定
- 日付: _______________
- 担当者: _______________
---
**注意**: このレビュー結果は`docs/review-results-YYYY-MM-DD-PR番号.md`として保存してください。
成果物: レビュー結果
注意点とベストプラクティス
セキュリティ面での注意点
- 機密情報の保護: APIキーやパスワードをプロンプトに含めない
- コードレビュー: AIが生成したコードは最後には人間がレビューする
- セキュリティチェック: 生成されたコードの脆弱性をチェックする
セキュリティの観点から人間の判断が不可欠です。機密情報の漏洩を防ぐため、APIキーやパスワードなどの認証情報をプロンプトに含めることは絶対に避けてください。
また、AIが生成したコードは必ず人間がレビューし、セキュリティ脆弱性がないか確認することが重要です。
特に、ユーザー入力の検証、認証・認可の実装、データの暗号化など、セキュリティに直結する部分については注意が必要です。AIの提案を鵜呑みにせず、専門知識を持つ開発者が慎重に検証する必要があります。
パフォーマンスの最適化
- 段階的な実装: 一度に全てを実装せず、機能ごとに分けて実装する
- 継続的な改善: AIの提案を基に、コードを継続的に改善する
段階的な実装により、問題の早期発見と修正が可能になり、品質を保ちながら開発を進めることができます。AIの提案を活用しながらも、継続的な改善により、システム全体のパフォーマンスを向上させることが重要です。
6段階フローの実行ルール
-
段階的な進行
- 各段階を順序立てて実行する
- 前段階の成果物を確認してから次に進む
- 一度に複数の段階を並行して進めない
-
品質優先
- 速度より品質を重視する
- 各段階で期待通りの結果になっているか確認する
- エラーが発生した場合は報告してから次へ進む
-
ドキュメント管理
- 各段階で明確な成果物を作成する
- 変更履歴を記録する
- バージョン管理を徹底する
6段階フローを成功させるためには、各段階を順序立てて実行することが重要です。
段階を飛ばしたり、並行して進めたりすると、品質低下や後戻り作業を招く可能性があります。
品質を最優先に考え、各段階で期待通りの結果を得られているかを確認しながら進めることで、効率的で高品質な開発を実現できます。
よくある失敗パターンと回避方法
- 過度な依存: AIに全てを任せず、人間の判断を加える
- プロンプトの曖昧さ: 具体的で明確な指示を心がける
- テストの省略: AIが生成したコードでも必ずテストを実行する
- 段階の飛ばし: 6段階フローを順序立てて実行する
AI駆動開発では、これらの失敗パターンに陥りがちです。過度にAIに依存すると、人間の判断力は鈍り、プロジェクトの品質低下を招く可能性があります。プロンプトが曖昧だと、AIは期待通りの結果を生成できず、開発効率が下がります。
まとめ
この記事では、AI駆動開発の6段階フローについて以下の内容を解説しました。AI駆動開発は、単なるツールの活用ではなく、人間とAIが協働することで開発の質と速度を同時に向上させる革新的なアプローチです。
6段階フローを意識することで、要求から実装まで、一貫した品質でプロジェクトを進められます。特に重要なのは、各段階で適切なプロンプトを使用し、AIの能力を最大限に引き出すことです。この手法を身につけることで、個人の開発者からチーム開発まで、様々な規模で効率的な開発が可能になります。
重要なポイント
- 6段階フローの順序: 要件定義→設計→実装→テスト→デプロイ→レビュー・検証
- プロンプトの品質が重要: 明確で具体的な指示を心がける
- 段階的なアプローチ: 一度に全てを実装せず、段階的に進める
- 人間とAIの協働: AIの提案を人間が検証・改善する
参考リンク
この記事がAI駆動開発の活用に役立てば幸いです！質問やフィードバックがあれば、コメントでお気軽にお聞かせください。
株式会社バーチャルクラフトのテックブログです。バーチャルクラフトは、クラウドサービスのプラットフォーム基盤におけるインフラエンジニアリングの技術集団です。従来のインフラエンジニアの枠を超え、DEV/OPSのOPS分野のエキスパートを目指して日々技術研鑽に取り組んでいます。
Discussion