はじめに
Claude Codeのような強力なAIエージェントが登場し、私達のソフトウェア開発に大きな変革がありました。AIエージェントを導入しはじめたものの、最初に直面する課題は「思ったよりも生産性向上に繋がらない」と感じる方はいるのではないでしょうか。
簡単な関数や定型コードの生成には大いに役立ってはいるが、難解なビジネスロジックや、複雑なビジネスフローをいざ実装しようとすると、求めていた品質よりも、やや劣るようなものが生成されることもあります。
結局、AIが生成したコードを理解し、手直ししてしまうこともあると思います。しかし、今はもはや手でコードを書くことは贅沢な時代になってきています！
優秀なAIエージェントをうまく使いこなす
なぜ、優秀なAIエージェントをうまく使いこなすことができないのでしょうか。
一つの原因としては、AIエージェントを使うときに、どうしてもAIのことを十分に高機能であると感じられないと思ってしまっていることが、プロンプト(命令)を書くうえで、一番の障壁になっているのだと思います。
AIエージェントへのプロンプトに慣れていないと、この指示をコード生成作業に限定してしまい、いきなり「この機能のコードを書いて」と指示してしまいがちです。
このアプローチは、AIに必要なコンテキストが与えられないまま実装が開始されてしまうため、仕様の解釈違いや、バグの多いコードの生成といった手戻りの多いアプリケーションになってしまう原因になりがちです。
そこで本記事では、この課題に対する一つの解決策として、AIの活用方法を単なるコード生成から、より開発プロセスの上位工程へとシフトさせるアプローチを行います。
具体的には、Claude Codeにいきなりコードを実装させるのではなく、その前工程である ラフな要件の作成、テスト実行計画の作成、実行計画の作成といった本来人間が時間をかけて行う開発プロセスそのものを、AIとの対話を介してエミュレートさせるのです。
この手法は、AIと対話を通じて要件定義やテスト計画の精度を高め、チーム内での合意形成を促し、最終的に生成されるコードの品質と一貫性を劇的に向上させるポテンシャルを秘めています。
本記事はこの、Claude Codeによる開発プロセスのエミュレーションを、すぐにでも実践的に試せるように具体的なプロンプト例を紹介しながら、解説する実践ガイドです。この記事がプロダクト開発における生産性をもう一度引き上げるための手助けとなれば幸いです。
Claude Codeによる開発プロセスのエミュレーション
それでは、具体的な手法を実践していきます！
この「開発プロセスのエミュレーション」は、大きく分けて4つのフェーズで構成されます。重要なのは、各フェーズの成果物(AIのアウトプット)を、次のフェーズのインプットとして活用していくことです。
ここでは例として、複数人で使える日記アプリを開発するケースを実践していきます。
対話で要件を"具体化"する ～ラフな定義から始める～
最初の一歩は、完璧な仕様書ではなくラフな箇条書きです。このフェーズの目的は、AIとの対話を通じてこのラフな要件を、誰が読んでもわかる具体的な機能要件一覧に落とし込むことです。
今回、以下のようなラフな要件を用意してみました。
- 特定のグループ内で共有できる日記アプリが欲しい。
- グループのメンバーは日記を投稿できる。
- グループのメンバーは、同じグループの他のメンバーの日記を読める。
このラフな要件をClaude Codeに送信し、仕様を明確にするための質問をさせます。
プロンプト例
### カスタムプロンプト
あなたは、非常に優秀で経験豊富なタスク管理 AI アシスタントです。あなたの主な役割は、ユーザーが提供する会議の議事録、アイデアメモ、プロジェクトの概要といった構造化されていないテキスト情報から、実行可能で抜け漏れのない、完璧に優先順位付けされたタスクリストを生成することです。あなたは単なるリスト作成者ではなく、プロジェクトを成功に導くための戦略的パートナーとして振る舞います。
#### # 目的と目標
- **最優先目標:** - ユーザーが貼り付けたテキスト情報の内容を深く理解し、その情報に基づいて具体的なアクションアイテムを特定し、優先順位の高い順に並べ替えたタスクリストをマークダウン形式で出力します。
- **副次目標:** - プロジェクトの隠れた前提条件や暗黙のタスクを洗い出し、計画の解像度を飛躍的に向上させる。
- ユーザーの作業効率と生産性を最大化するための、実用的で具体的な行動計画を提供する。
- テスト駆動開発や文書化といった、ソフトウェア開発におけるベストプラクティスを自然にタスクに組み込む。
- プロジェクトの開始から完了までを見通した、一貫性のあるロードマップを作成する。
#### # 行動とルール
1. **初期対応:** - ユーザーがコンテンツを貼り付けたら、即座にタスクリストの分析と生成を開始します。
- ユーザーからの確認や追加情報を待つことなく、提供されたテキストから最適なタスクリストを自動的に生成し、直ちに出力します。特別な要求がある場合は、ユーザーが後から修正依頼を出すものとして、まずは標準的な解釈で最高品質のタスクリストを作成します。
2. **タスクの抽出と超・具体化:**
- 提供されたテキストの表面的なキーワードだけでなく、その背景や意図を深く読み取り、明確な行動を伴うタスクを抽出します。
- 「〜を確認する」といった曖昧なタスクではなく、「（誰が）」「（何を）」「（どうする）」が明確な、具体的なタスクに落とし込みます。
- **隠れた前提タスクの明示化:** ユーザーが明記していない、しかし実行上必須となるタスクをプロアクティブに特定し、リストに含めます。
- 例: 要件定義書の作成、システム設計書の準備、開発環境構築（必要なツールのセットアップ）、機能仕様の明確化、データモデルの設計、API 仕様の定義など。
3. **優先順位付けの論理:**
- 抽出したタスクを、以下の標準的なプロジェクトフローに基づいて、論理的に優先順位付けします。依存関係を考慮し、手戻りが発生しないような順序を意識してください。
1. **調査・学習フェーズ:** プロジェクトに必要な知識や技術のインプット。
2. **計画フェーズ:** テスト計画、実装方針の策定。
3. **環境構築フェーズ:** インフラ、開発環境の準備。
4. **テスト実装フェーズ:** テストコードの先行実装。
5. **主要機能の実装・検証フェーズ:** メインとなるロジックの実装と動作確認。
6. **文書化・結論フェーズ:** 結果のまとめ、レポート作成。
4. **知識習得タスクの具体化:**
- 「〜を調査する」といった曖昧な学習タスクは生成しません。
- 代わりに、具体的な成果物を伴うタスクを生成します。
- 例 1: 「Claude Code に対し『（特定の技術）の役割を説明してください』と依頼し、プロジェクト用の用語集を作成する」
- 例 2: 「AI ツールに対し『（特定の概念）を説明する最小限のコード例を生成してください』と依頼し、レビューする」
- 学習タスクには、信頼できる情報源（公式ドキュメントなど）の URL を積極的に探し、参考情報としてタスクに付与します。
5. **テスト計画の恒久的な組み込み:**
- 成果物がソースコードである場合、テスト関連のタスクは**必須項目**です。
- 「テストを書く」という抽象的なタスクではなく、具体的なテスト手法や観点を含むタスクを複数生成します。
- 例 1: 「テストフレームワークとモックライブラリを選定し、プロジェクトに設定する」
- 例 2: 「（特定機能）に関する単体テストを、正常系・異常系の観点で実装する」
- 例 3: 「（外部サービス）との連携部分について、モックを使ったテストを実装する」
- ユーザーが特定のテストフレームワークを指示した場合、関連するタスク全体をそのフレームワークに合わせた内容（言語、ライブラリ等）に修正し、一貫性を保ちます。
6. **AI 活用の具体的提案:**
- あなたは他の AI（Gemini, Cursor, Claude Code 等）の活用を促す、メタ的なアシスタントでもあります。
- タスクリストの中に、「他の AI をどのように活用できるか」を具体的に示すタスクを自然に組み込みます。
- その際、**ユーザーが AI に質問すべき具体的なプロンプト（質問文）の例**をタスクに含める必要があります。
- 例: 「AI ツールに『ユーザー認証機能の実装に必要なコンポーネントと API エンドポイントのコード例を生成してください』と依頼し、実装の雛形を作成する」
7. **反復的な改善:**
- ユーザーからのフィードバック（タスクの追加、変更、フォーマットの修正依頼など）を正確に反映します。
- タスクリストを修正する際は、一部だけを変更するのではなく、全体の優先順位や依存関係を再評価し、常に最適化された完全なリストを再生成します。
#### # 出力形式
- 生成するタスクリストは、必ず以下のマークダウン形式で出力します。
- 各タスクの前に、必ずチェックボックス `[ ]` をつけ、ハイフンとスペースで始めます (`- [ ] `)。
- **禁止事項:**
- タスクリストの項目間に、**絶対に空行を入れないでください**。リストは一つの連続したブロックである必要があります。
- タスクリストの内部に、見出し (`#`, `##`など) を含めないでください。
- タスクの説明文に、太字 (`**`) やイタリック (`*`) を使用しないでください。
#### # 全体的なトーン-
- 親切で、協力的かつ専門的な態度を保ちます。
- 明確で簡潔な言葉を使用し、ユーザーがすぐに行動に移せるように支援します。
- 常にユーザーの生産性向上を第一に考え、最高のタスク管理パートナーとして振る舞います。
このプロンプトを先に貼り付けて実行してから、ラフな要件を次に貼り付けましょう。
プロンプトを貼り付ける前に /clear を実行することを忘れないようにしましょう。
- 特定のグループ内で共有できる日記アプリが欲しい。
- グループのメンバーは日記を投稿できる。
- グループのメンバーは、同じグループの他のメンバーの日記を読める。
このプロンプトに対し、Claude Codeは以下のように返してきます。
このようにして、ラフな要件は具体的な機能要件一覧へと変わっていきます。
- [ ] AI ツールに『グループ共有型日記アプリの要件定義書のテンプレートと必要な機能一覧を生成してください』と依頼し、プロジェクトの全体像を明確化する
- [ ] 技術スタック（フロントエンド、バックエンド、データベース、認証システム）を選定し、それぞれの選択理由を含む技術選定書を作成する
- [ ] データモデル設計書を作成し、ユーザー、グループ、日記投稿、グループメンバーシップの各エンティティとリレーションを定義する
- [ ] API 仕様書を作成し、日記投稿、日記取得、グループ作成、メンバー招待の各エンドポイントのリクエスト/レスポンス形式を定義する
- [ ] AI ツールに『マルチテナント型アプリケーションにおけるセキュリティベストプラクティスを説明してください』と依頼し、セキュリティ要件をまとめる
- [ ] 開発環境をセットアップし、選定した技術スタックに必要なツール、ライブラリ、開発サーバーを構築する
- [ ] テストフレームワーク（Jest/Vitest 等）と E2E テストツール（Playwright/Cypress 等）を選定し、プロジェクトに組み込む
- [ ] 認証・認可システムのテストコードを実装し、ユーザー登録、ログイン、グループアクセス権限の検証を含む単体テストを作成する
- [ ] グループ管理機能のテストコードを実装し、グループ作成、メンバー招待、メンバー削除の正常系・異常系テストを作成する
- [ ] 日記投稿機能のテストコードを実装し、投稿作成、更新、削除、グループ内閲覧権限の検証テストを作成する
- [ ] データベーススキーマを実装し、マイグレーションファイルを作成してユーザー、グループ、日記、メンバーシップのテーブルを構築する
- [ ] ユーザー認証システムを実装し、JWT/セッションベースの認証機構とパスワードハッシュ化処理を構築する
- [ ] グループ管理 API を実装し、グループ CRUD 操作とメンバー招待・削除のエンドポイントを作成する
- [ ] 日記投稿 API を実装し、日記の CRUD 操作とグループ内のみ閲覧可能な権限制御を実装する
- [ ] AI ツールに『React/Vue/Angular でグループ共有型日記アプリの UI コンポーネント構成を提案してください』と依頼し、フロントエンド設計を行う
- [ ] フロントエンドの基本レイアウトとルーティングを実装し、ログイン画面、グループ一覧、日記一覧、日記詳細の各画面を構築する
- [ ] 日記投稿フォームコンポーネントを実装し、リッチテキストエディタ、画像アップロード、下書き保存機能を組み込む
- [ ] グループ管理 UI を実装し、グループ作成、メンバー招待、メンバー一覧表示の各機能を構築する
- [ ] E2E テストシナリオを作成し、ユーザー登録からグループ作成、日記投稿、他メンバーの日記閲覧までの一連のフローをテストする
- [ ] API ドキュメント（OpenAPI/Swagger）を作成し、全エンドポイントの仕様と使用例を記載する
- [ ] デプロイメント設定を作成し、Docker 構成、CI/CD パイプライン、本番環境の環境変数管理を構築する
- [ ] パフォーマンステストを実施し、同時接続ユーザー数、データベースクエリ最適化、キャッシュ戦略を検証・改善する
- [ ] セキュリティ監査を実施し、SQL インジェクション、XSS、CSRF 対策、適切な CORS 設定を確認・実装する
- [ ] ユーザーマニュアルを作成し、アプリの使い方、グループ作成方法、日記投稿方法をスクリーンショット付きで文書化する
細かなタスクリストが生成されたら、このタスクリストに対して微調整を行っていきます。
まず、こちらの文章が気になりました。
AI ツールに『React/Vue/Angular でグループ共有型日記アプリの UI コンポーネント構成を提案してください』と依頼し、フロントエンド設計を行う
ここでは、Reactを使ってほしいので、 Reactを使ってください と送りましょう。
AI ツールに『React でグループ共有型日記アプリの UI コンポーネント構成を提案してください』と依頼し、フロントエンド設計を行う
これでReactのみで実装されることが確定しました。
テストフレームワーク（Jest/Vitest 等）と E2E テストツール（Playwright/Cypress 等）を選定し、プロジェクトに組み込む
こちらも気になります。テストフレームワークは Vitestにしましょう。 E2Eテストツールは、Playwrightにしたいので以下のようにプロンプトを送りましょう。
テストフレームワークはVitest、E2Eテストツールは、Playwrightを使ってください
これでだいぶ良くなりました！
タスクリストを確認して、もう少しエンジニア目線でどうしていきたいか考えてみましょう。見たところまだ使用するフレームワークが決まっていないので、ここではNextJSを使うことにしましょう。
NextJSを使ってください
ラフに作っていきたいので送信するプロンプトはこれだけでOKです。
人間が疲れないように作っていくのも重要だとおもいます。
これによって、最終的な要件一覧は以下のようになりました。
- [ ] AI ツールに『グループ共有型日記アプリの要件定義書のテンプレートと必要な機能一覧を生成してください』と依頼し、プロジェクトの全体像を明確化する
- [ ] 技術スタック（フロントエンド：Next.js/React、バックエンド、データベース、認証システム）を選定し、それぞれの選択理由を含む技術選定書を作成する
- [ ] データモデル設計書を作成し、ユーザー、グループ、日記投稿、グループメンバーシップの各エンティティとリレーションを定義する
- [ ] API 仕様書を作成し、日記投稿、日記取得、グループ作成、メンバー招待の各エンドポイントのリクエスト/レスポンス形式を定義する
- [ ] AI ツールに『マルチテナント型アプリケーションにおけるセキュリティベストプラクティスを説明してください』と依頼し、セキュリティ要件をまとめる
- [ ] 開発環境をセットアップし、選定した技術スタックに必要なツール、ライブラリ、開発サーバーを構築する
- [ ] テストフレームワーク（Vitest）と E2E テストツール（Playwright）を選定し、プロジェクトに組み込む
- [ ] 認証・認可システムのテストコードを実装し、ユーザー登録、ログイン、グループアクセス権限の検証を含む単体テストを作成する
- [ ] グループ管理機能のテストコードを実装し、グループ作成、メンバー招待、メンバー削除の正常系・異常系テストを作成する
- [ ] 日記投稿機能のテストコードを実装し、投稿作成、更新、削除、グループ内閲覧権限の検証テストを作成する
- [ ] データベーススキーマを実装し、マイグレーションファイルを作成してユーザー、グループ、日記、メンバーシップのテーブルを構築する
- [ ] ユーザー認証システムを実装し、JWT/セッションベースの認証機構とパスワードハッシュ化処理を構築する
- [ ] グループ管理 API を実装し、グループ CRUD 操作とメンバー招待・削除のエンドポイントを作成する
- [ ] 日記投稿 API を実装し、日記の CRUD 操作とグループ内のみ閲覧可能な権限制御を実装する
- [ ] AI ツールに『Next.js (React) でグループ共有型日記アプリの UI コンポーネント構成を提案してください』と依頼し、フロントエンド設計を行う
- [ ] Next.jsのApp Routerを使用してフロントエンドの基本レイアウトとルーティングを実装し、ログイン画面、グループ一覧、日記一覧、日記詳細の各画面を構築する
- [ ] 日記投稿フォームコンポーネントを実装し、リッチテキストエディタ、画像アップロード、下書き保存機能を組み込む
- [ ] グループ管理 UI を実装し、グループ作成、メンバー招待、メンバー一覧表示の各機能を構築する
- [ ] E2E テストシナリオを作成し、ユーザー登録からグループ作成、日記投稿、他メンバーの日記閲覧までの一連のフローをテストする
- [ ] API ドキュメント（OpenAPI/Swagger）を作成し、全エンドポイントの仕様と使用例を記載する
- [ ] デプロイメント設定を作成し、Next.js向けのデプロイ構成（Vercel等）、Docker構成、CI/CDパイプライン、本番環境の環境変数管理を構築する
- [ ] パフォーマンステストを実施し、Next.jsのSSR/SSG/ISR最適化、同時接続ユーザー数、データベースクエリ最適化、キャッシュ戦略を検証・改善する
- [ ] セキュリティ監査を実施し、SQL インジェクション、XSS、CSRF 対策、適切な CORS 設定を確認・実装する
- [ ] ユーザーマニュアルを作成し、アプリの使い方、グループ作成方法、日記投稿方法をスクリーンショット付きで文書化する
たった3行の要件がより具体的に実現可能性の高い機能要件一覧になりました。
テスト実行計画の策定
本来テストといえば、テストケースとして記述し、「どのような状況で（前提条件）、どのような操作をしたら（テスト手順）、何がどうなっているべきか（期待結果）」という、システムの振る舞いを確認するための具体的なシナリオを記述します。
TDDというアプローチでは、テストケースを書いてからそのテストを満たせるようにプロダクト開発を行っていきますが、この手法ではそのフェーズは含めていません。テストケース自体、単体テストは結合テストなど多岐にわたるテストがあり全てを洗い出すと人間が目で終えなくなるほど膨大になってしまうからです。
AIがテストケースを生成してくれたとしても、その全てを人間が目視で確認するのはなかなかに大変ですし、個々のテストケース自体に意味があるものなのかも簡単に把握することはできません。
そのため、テスト実行計画という形式でまずは人間が読みやすい形で、どのようにテストを行うのかを考えてもらいたいと思います。
機能要件が固まったら、次はそれをどのように品質保証するかを定義する「テスト実行計画」をAIに策定させます。
ここでの目的は、具体的なテストケースをリストアップすることではなく、「何を、なぜ、どのようにテストするのか」というテスト全体の戦略と方針を文章で明確にすることが重要です。
テストストラテジストのプロンプト例
あなたは経験豊富なテストストラテジストです。
以下の機能要求リストに基づき、品質を保証するためのハイレベルな「テスト実行計画」を文章で記述してください。
この計画書は、エンジニアやプロダクトマネージャーが読んで、テスト全体の目的とアプローチを理解できるような、プロフェッショナルなドキュメントの形式で作成してください。
以下の構成要素を必ず含めてください。
1. **はじめに (目的)**: このテスト計画が目指すゴールは何か。
2. **テスト対象範囲**: 何をテストし、何をテストしないのか。
3. **テスト戦略とアプローチ**:
* **機能テスト**: 主要な機能ごとに、どのような観点でテストが必要か、その理由と共に説明してください。（例：グループ管理機能、日記投稿機能など）
* **認可テスト**: なぜ権限周りのテストが重要なのか、どのようなパターンを検証すべきかを説明してください。
* **バリデーションテスト**: ユーザー入力の検証について、どのような方針でテストするかを説明してください。
4. **テストレベル**: ユニットテスト、APIテスト、E2Eテストをどのように組み合わせるかの基本方針を述べてください。
# 機能要求リスト
- （Phase 1で固まった「複数人日記アプリ」の機能要求リストをここに貼り付ける）
/clear してからこのプロンプトを貼り付けて、先ほどの箇条書きのタスクリストを貼り付けてみましょう。
また、テストストラテジスト のプロンプト と 機能要件一覧 をそれぞれ別ファイルに保存し、ひとつのプロンプトとして呼び出しても構いません。
@テストストラテジスト.md を元に @タスクリスト.md からテスト実行計画書を作成してください
ちょっと長いですが以下のようなテスト実行計画が作成されます。
# 複数人日記アプリ テスト実行計画書
## 1. はじめに（目的）
本テスト計画は、複数人で共有可能な日記アプリケーションの品質保証を目的としています。本計画の主要なゴールは以下の通りです：
- グループ内でのみ日記を共有する機能が正確に動作することを保証する
- 認証・認可機能により、適切なユーザーのみがコンテンツにアクセスできることを確認する
- システムの信頼性、セキュリティ、使いやすさを総合的に検証する
- 本番環境でのユーザー体験を想定した包括的な品質保証を実現する
## 2. テスト対象範囲
### テスト対象
- **認証システム**: ユーザー登録、ログイン、ログアウト、JWT/セッションベース認証
- **グループ管理機能**: グループCRUD操作、メンバー招待・削除
- **日記投稿機能**: 日記CRUD操作、リッチテキストエディタ、画像アップロード、下書き保存
- **閲覧権限制御**: グループ内のみの日記閲覧、他グループの日記へのアクセス制限
- **API層**: 日記投稿、日記取得、グループ作成、メンバー招待の各エンドポイント
- **フロントエンド**: Next.js App Router、レスポンシブデザイン、画面遷移
- **パフォーマンス**: SSR/SSG/ISR最適化、同時接続処理、データベースクエリ効率
- **セキュリティ**: SQLインジェクション、XSS、CSRF対策、CORS設定
### テスト対象外
- サードパーティサービスの内部動作
- ブラウザ固有のバグ（ただし主要ブラウザでの基本動作は確認）
- インフラストラクチャー層の障害対応
## 3. テスト戦略とアプローチ
### 3.1 機能テスト
#### グループ管理機能
グループ管理は本アプリケーションの中核機能であり、以下の観点で徹底的にテストを実施します：
- **グループCRUD操作**: 作成・読取・更新・削除の全操作における正常系・異常系
- **メンバー招待機能**: 招待リンクの生成、有効期限管理、重複招待の防止
- **メンバー削除**: 権限チェック、削除後のデータ整合性、最後の管理者削除の防止
- **グループ設定**: 名称変更、説明文更新、プライバシー設定
これらのテストが重要な理由は、グループ機能が日記の共有範囲を決定する最重要機能であり、不具合は情報漏洩に直結するためです。
#### 日記投稿機能
日記投稿は日常的に使用される機能であり、以下の観点でテストします：
- **CRUD操作**: 作成・読取・更新・削除の基本動作、同時編集の制御
- **リッチテキストエディタ**: 書式設定、特殊文字処理、HTMLサニタイズ
- **画像アップロード**: ファイルサイズ制限、形式チェック、ストレージ管理
- **下書き保存**: 自動保存タイミング、復元機能、下書きと公開の状態管理
### 3.2 認可テスト
権限管理は本アプリケーションのセキュリティの要であり、以下のパターンを網羅的に検証します：
#### 検証すべきパターン
1. **グループアクセス権限**
- グループメンバーのみが日記を閲覧可能
- 非メンバーによるアクセス試行の完全ブロック
- 削除されたメンバーの即時アクセス無効化
2. **API認証・認可**
- JWTトークンの有効性検証
- APIエンドポイントごとの権限チェック
- トークン期限切れ時の適切な処理
3. **マルチテナント分離**
- グループ間のデータ完全分離
- 検索結果やAPIレスポンスでの情報漏洩防止
### 3.3 バリデーションテスト
ユーザー入力の検証は、セキュリティと使いやすさの両面から重要です：
#### テスト方針
1. **入力値検証**
- 文字数制限（最小・最大）の動作確認
- 特殊文字、絵文字、マルチバイト文字の処理
- 必須項目の空値チェック
2. **セキュリティ検証**
- スクリプトインジェクションの防御確認
- SQLインジェクション対策の検証
- ファイルアップロードの悪用防止
3. **エラーハンドリング**
- 適切なエラーメッセージの表示
- 入力データの保持と復元
- ユーザーフレンドリーなガイダンス
## 4. テストレベル
### ユニットテスト（Vitest使用）
- **対象**: ビジネスロジック、データ変換、バリデーション関数、認証処理
- **重点項目**:
- ユーザー登録、ログイン、グループアクセス権限の検証
- グループ作成、メンバー招待、メンバー削除の正常系・異常系
- 投稿作成、更新、削除、グループ内閲覧権限の検証
- **カバレッジ目標**: コアロジック80%以上
### APIテスト
- **対象**: 全APIエンドポイント
- **検証項目**:
- リクエスト/レスポンス形式の妥当性
- 認証・認可の動作確認
- エラーレスポンスの適切性
- **重点エンドポイント**: 日記投稿、日記取得、グループ作成、メンバー招待
### E2Eテスト（Playwright使用）
- **対象**: ユーザーシナリオ全体
- **主要シナリオ**:
- ユーザー登録→グループ作成→日記投稿→他メンバーの日記閲覧
- ログイン画面→グループ一覧→日記一覧→日記詳細の画面遷移
- モバイル/タブレット/デスクトップでの動作確認
- **Next.js固有の検証**: App Routerの動作、クライアント/サーバーコンポーネントの連携
### パフォーマンステスト
- **検証項目**:
- Next.jsのSSR/SSG/ISR最適化効果
- 同時接続ユーザー数の上限確認
- データベースクエリの実行時間
- キャッシュ戦略の有効性
### セキュリティ監査
- **検証項目**:
- SQLインジェクション対策
- XSS対策
- CSRF対策
- 適切なCORS設定
- セキュアなセッション管理
## まとめ
本テスト計画は、複数人日記アプリケーションの品質を多角的に保証することを目的としています。特に、プライバシーとセキュリティに関わる機能については、Vitest/Playwrightを活用した自動化テストにより、継続的かつ徹底的な検証を行います。開発チーム全体で本計画を共有し、テスト駆動開発のアプローチを取ることで、高品質なプロダクトの実現を目指します。
なんとなく、このプロダクトがどういったものなのかが、テスト実行計画を通してイメージが湧いてこないでしょうか。
認証・認可といったこれまで触れられてこなかった部分にもしっかりと検証が必要な部分であると明記され、安心して使用できるアプリケーションである印象があります。
テスト実行計画の見直し
それでは、こちらのテスト実行計画を見直しする部分はないでしょうか。
セキュリティ観点は非常に素晴らしいですが、日記投稿や日記取得、グループ作成、メンバーの招待などしかなく、機能としてありきたりな感じがしますね。
しかし、機能要件一覧の生成していた際にそういった観点をあらかじめ追加しても良かった所ではありますが、重要なことは テスト実行計画書に落とし込むこと で、より具体的に解像度が上がることで「もっとこうしたらいいんじゃないか？」というように気付けることだと思っています。
いきなり「実行計画」を作るのではなく、ラフな要件から少しずつ具体化していくことが大事です。
また、このテスト実行計画書ではデータベースに何を使うのかの指示がありませんので、データベースにはPostgreSQLを使うことを指示しましょう。
データベースにはPostgreSQLを使ってください
そして、日記削除ができないようなので、日記削除できるようにしましょう。しかし、勝手に日記を削除されたら他の方が困るので、グループの全員が同意したら削除する観点を追加しましょう。
日記を削除できるようにしてください(ただしメンバーの全員が同意すること)
これによってこちらの行が追加されました。
削除承認機能: 全メンバーの同意による削除フロー、承認状態の管理、期限切れ処理
あわせて検証すべきパターンにも同様の手続きが追加されていますね。
このように、どのようにしてテストをしていくかというテスト実行計画を作ることによって、権限管理もしっかりとしたアプリケーションを開発することが出来ます。
いきなりテストケースを書かなくても、テスト観点から文章として読みつつ見直ししていくことでより具体的に落としこんで解像度を上げて設計していくことが出来ます。
その他のユースケース
Claude Codeに命令をしてどんどんブラッシュアップしていきたいと思います。
新たな観点として同じグループの他の人の日記に、自分の名前が含まれていた場合は、その日記を非表示にしたいケースを考えます。
他の人の日記に自分の名前やニックネームが含まれていたらその記事を非表示(本人しか見えない)にすることができる機能(メニューから機能を選択)を追加してください
これで、日記非表示機能を実装するためのテスト実行計画が追加されました。
これだけでも、だいぶ使い勝手のいい日記サービスに見えますが、まだ物足りないと感じたので、他の人の日記に絵文字でリアクションできる機能をつけることにしましょう。
他の人の日記に絵文字でリアクションできる機能をつけて
これで、テスト実行計画には絵文字リアクションの機能の要件が追加され、あわせて検証されるようになりました。
本来の開発プロセスでは、要件が後から追加になったとしたら、最初の要件定義に戻ってこのテスト実行計画の作成まで戻ってこないといけないのですが、Claude Codeを活用することで、直接テスト実行計画に追記することが出来ます。
本来の開発プロセスをエミュレートして命令をしていますが、こういったことはAIでなければなかなかできることではありません。
現実的な開発プロセスをエミュレートする場合は、最初の3つの要件ファイルが変更されたら、ファイルの変更監視を行い、各AIが連鎖的に動作してテスト実行計画に反映されたほうがいいのかもしれませんが、トークンを浪費してしまうので、要件が増えた場合は、直接AIにテスト実行計画を修正してもらったほうが良いと思います。
最終的なテスト実行計画
最終的に以下のようなテスト実行計画になりました！
これを元に、ソフトウェア設計をしていきましょう！
# 複数人日記アプリ テスト実行計画書
## 1. はじめに（目的）
本テスト計画は、複数人で共有可能な日記アプリケーションの品質保証を目的としています。本計画の主要なゴールは以下の通りです：
- グループ内でのみ日記を共有する機能が正確に動作することを保証する
- 認証・認可機能により、適切なユーザーのみがコンテンツにアクセスできることを確認する
- システムの信頼性、セキュリティ、使いやすさを総合的に検証する
- 本番環境でのユーザー体験を想定した包括的な品質保証を実現する
## 2. テスト対象範囲
### テスト対象
- **認証システム**: ユーザー登録、ログイン、ログアウト、JWT/セッションベース認証
- **グループ管理機能**: グループ CRUD 操作、メンバー招待・削除
- **日記投稿機能**: 日記 CRUD 操作、リッチテキストエディタ、画像アップロード、下書き保存
- **日記削除承認機能**: 削除リクエスト作成、メンバー全員の同意確認、承認状態管理
- **日記非表示機能**: 自分の名前/ニックネームを含む日記の検出、非表示設定（本人限定表示）
- **リアクション機能**: 絵文字によるリアクション追加・削除、リアクション数の集計
- **閲覧権限制御**: グループ内のみの日記閲覧、他グループの日記へのアクセス制限、非表示設定の適用
- **API 層**: 日記投稿、日記取得、グループ作成、メンバー招待、削除承認の各エンドポイント
- **データベース層**: PostgreSQL でのデータ整合性、トランザクション処理、インデックス効率
- **フロントエンド**: Next.js App Router、レスポンシブデザイン、画面遷移
- **パフォーマンス**: SSR/SSG/ISR 最適化、同時接続処理、PostgreSQL クエリ効率
- **セキュリティ**: SQL インジェクション、XSS、CSRF 対策、CORS 設定
### テスト対象外
- サードパーティサービスの内部動作
- ブラウザ固有のバグ（ただし主要ブラウザでの基本動作は確認）
- インフラストラクチャー層の障害対応
## 3. テスト戦略とアプローチ
### 3.1 機能テスト
#### グループ管理機能
グループ管理は本アプリケーションの中核機能であり、以下の観点で徹底的にテストを実施します：
- **グループ CRUD 操作**: 作成・読取・更新・削除の全操作における正常系・異常系
- **メンバー招待機能**: 招待リンクの生成、有効期限管理、重複招待の防止
- **メンバー削除**: 権限チェック、削除後のデータ整合性、最後の管理者削除の防止
- **グループ設定**: 名称変更、説明文更新、プライバシー設定
これらのテストが重要な理由は、グループ機能が日記の共有範囲を決定する最重要機能であり、不具合は情報漏洩に直結するためです。
#### 日記投稿機能
日記投稿は日常的に使用される機能であり、以下の観点でテストします：
- **CRUD 操作**: 作成・読取・更新の基本動作、同時編集の制御
- **リッチテキストエディタ**: 書式設定、特殊文字処理、HTML サニタイズ
- **画像アップロード**: ファイルサイズ制限、形式チェック、ストレージ管理
- **下書き保存**: 自動保存タイミング、復元機能、下書きと公開の状態管理
#### 日記削除承認機能
日記の削除は重要な操作であり、全メンバーの同意が必要なため、以下の観点で詳細にテストします：
- **削除リクエスト**: 削除申請の作成、理由の記載、通知送信
- **承認フロー**: 各メンバーの承認/却下操作、承認状態の追跡、未承認メンバーへのリマインダー
- **全員同意判定**: 全メンバーの承認確認、一人でも却下した場合の処理、期限切れ時の自動却下
- **削除実行**: 全員承認後の削除実行、関連データ（画像等）の削除、削除履歴の保存
- **権限制御**: 削除リクエスト作成者の権限、承認可能メンバーの制限、非メンバーのアクセス防止
#### 日記非表示機能
プライバシー保護の観点から、自分の名前やニックネームが含まれる日記を非表示にできる機能について、以下の観点でテストします：
- **名前検出機能**: ユーザー名、ニックネーム、部分一致の検出精度
- **非表示設定**: メニューからの非表示設定操作、設定の保存と永続化
- **表示制御**: 非表示設定された日記の作成者のみ閲覧可能、他メンバーへの非表示
- **通知機能**: 非表示設定時の作成者への通知（オプション）
- **設定管理**: 非表示設定の一覧表示、解除操作、バッチ処理
#### リアクション機能
グループメンバー間のコミュニケーションを活性化するリアクション機能について、以下の観点でテストします：
- **リアクション追加**: 絵文字選択 UI、同一ユーザーの重複リアクション防止、リアルタイム反映
- **リアクション削除**: 自分のリアクションのみ削除可能、削除時のアニメーション
- **リアクション集計**: リアクション種別ごとの集計、ユーザーリスト表示
- **権限制御**: グループメンバーのみリアクション可能、非表示日記へのリアクション制限
- **パフォーマンス**: 大量リアクション時の表示速度、データベース最適化
### 3.2 認可テスト
権限管理は本アプリケーションのセキュリティの要であり、以下のパターンを網羅的に検証します：
#### 検証すべきパターン
1. **グループアクセス権限**
- グループメンバーのみが日記を閲覧可能
- 非メンバーによるアクセス試行の完全ブロック
- 削除されたメンバーの即時アクセス無効化
- 日記削除承認へのアクセス権限（メンバーのみ承認可能）
- 非表示設定された日記への他メンバーのアクセス制限
2. **API 認証・認可**
- JWT トークンの有効性検証
- API エンドポイントごとの権限チェック
- トークン期限切れ時の適切な処理
3. **マルチテナント分離**
- グループ間のデータ完全分離
- 検索結果や API レスポンスでの情報漏洩防止
### 3.3 バリデーションテスト
ユーザー入力の検証は、セキュリティと使いやすさの両面から重要です：
#### テスト方針
1. **入力値検証**
- 文字数制限（最小・最大）の動作確認
- 特殊文字、絵文字、マルチバイト文字の処理
- 必須項目の空値チェック
2. **セキュリティ検証**
- スクリプトインジェクションの防御確認
- SQL インジェクション対策の検証
- ファイルアップロードの悪用防止
3. **エラーハンドリング**
- 適切なエラーメッセージの表示
- 入力データの保持と復元
- ユーザーフレンドリーなガイダンス
## 4. テストレベル
### ユニットテスト（Vitest 使用）
- **対象**: ビジネスロジック、データ変換、バリデーション関数、認証処理
- **重点項目**:
- ユーザー登録、ログイン、グループアクセス権限の検証
- グループ作成、メンバー招待、メンバー削除の正常系・異常系
- 投稿作成、更新、グループ内閲覧権限の検証
- 日記削除承認機能（承認リクエスト作成、承認/却下、全員同意判定）
- 日記非表示機能（名前検出、非表示設定、表示制御）
- リアクション機能（追加・削除、重複防止、集計ロジック）
- PostgreSQL 固有機能（JSONB、配列型）の処理ロジック
- **カバレッジ目標**: コアロジック 80%以上
### API テスト
- **対象**: 全 API エンドポイント
- **検証項目**:
- リクエスト/レスポンス形式の妥当性
- 認証・認可の動作確認
- エラーレスポンスの適切性
- **重点エンドポイント**: 日記投稿、日記取得、グループ作成、メンバー招待、削除承認、非表示設定、リアクション
### E2E テスト（Playwright 使用）
- **対象**: ユーザーシナリオ全体
- **主要シナリオ**:
- ユーザー登録 → グループ作成 → 日記投稿 → 他メンバーの日記閲覧
- 日記削除フロー（削除リクエスト → メンバー通知 → 全員承認 → 削除実行）
- 日記非表示フロー（名前を含む日記の検出 → 非表示設定 → 他メンバーからの非表示確認）
- リアクションフロー（日記閲覧 → 絵文字選択 → リアクション追加 → 集計表示）
- ログイン画面 → グループ一覧 → 日記一覧 → 日記詳細の画面遷移
- モバイル/タブレット/デスクトップでの動作確認
- **Next.js 固有の検証**: App Router の動作、クライアント/サーバーコンポーネントの連携
### パフォーマンステスト
- **検証項目**:
- Next.js の SSR/SSG/ISR 最適化効果
- 同時接続ユーザー数の上限確認
- PostgreSQL クエリの実行時間とインデックス効率
- コネクションプーリングの最適化
- キャッシュ戦略の有効性
### セキュリティ監査
- **検証項目**:
- SQL インジェクション対策
- XSS 対策
- CSRF 対策
- 適切な CORS 設定
- セキュアなセッション管理
## まとめ
本テスト計画は、複数人日記アプリケーションの品質を多角的に保証することを目的としています。特に、プライバシーとセキュリティに関わる機能については、Vitest/Playwright を活用した自動化テストにより、継続的かつ徹底的な検証を行います。開発チーム全体で本計画を共有し、テスト駆動開発のアプローチを取ることで、高品質なプロダクトの実現を目指します。
こちらのテスト実行計画書は長いので、ファイルに保存するプロンプトを実行し保存しましょう。ここではファイル名は テスト実行計画書.md とします。
実行計画の作成
これまでのアウトプットから以下の2つのファイルが出来ていることを確認してください。
- 機能要件一覧.md -- 具体化された機能要件一覧
- テスト実行計画書.md -- テストをどのように実行するか
ファイルが同じディレクトリにあることを確認したら、さっそく実行計画の作成を行っていきます。
以下のプロンプトを実行しましょう。
/clear を実行してから実行します。
# 役割
あなたは、フルスタック開発の深い知識を持つ、経験豊富なテックリードです。
あなたの今回の任務は、提示された「機能要件一覧」と「テスト実行計画書」を基に、ジュニア開発者やAIコーディングアシスタントが、一字一句その通りに実行すればアプリケーションが完成するレベルの、**網羅的かつ具体的な「実装手順書」**を作成することです。抽象的な方針や設計思想は最小限にし、具体的なコマンド、ファイルパス、コードスニペットを中心に記述してください。
# 入力情報
## 1. 機能要件一覧.md
[ここに、アプリケーションが実現すべき機能の一覧を記述した「機能要件一覧.md」を貼り付けてください。]
## 2. テスト実行計画書.md
[ここに、アプリケーションが遵守すべき非機能要件やセキュリティ要件などを記述した「テスト実行計画書.md」を貼り付けてください。]
# 指示
上記の入力情報を基に、以下の構造化されたステップで構成される、網羅的な「実装手順書」を作成してください。これは、思考のプロセスではなく、**実行すべきタスクの連続**です。
1. **分析と技術選定:**
* まず、要件全体を分析し、実装に使用する具体的な技術スタック（言語、フレームワーク、データベース、ライブラリ等）を明記してください。
2. **実装ステップの分解:**
* アプリケーションを構築するための全工程を、論理的な順序でステップに分解してください。（例：環境構築→DB設計→認証実装→機能A実装...）
3. **各ステップの具体化:**
* 分解した各ステップについて、実行すべき具体的なタスクを詳細に記述してください。
* 各タスクには、以下の要素を可能な限り具体的に含めてください。
* **実行するシェルコマンド:** プロジェクトの初期化、ライブラリのインストール、マイグレーションの実行など。
* **作成・編集するファイルパス:** 絶対パスではなく、プロジェクトルートからの相対パスで記述。
* **ファイルに書き込む具体的なコードスニペット:** 新規作成するファイルの内容や、追記・修正するコードの断片。コードブロックには言語名を明記してください（例: ```javascript, ```sql）。
# 出力形式
上記「指示」に基づき、以下のフォーマットで「実行計画書.md」を出力してください。
---
(ここから出力イメージ)
# アプリケーション実装手順書
## Step 0: 技術スタック
- **言語:** Node.js (v20.x)
- **フレームワーク:** Express.js
- **データベース:** PostgreSQL
- **認証:** JWT (jsonwebtokenライブラリ)
- **ORM/クエリビルダ:** Knex.js
## Step 1: プロジェクトのセットアップと環境構築
### タスク 1.1: プロジェクトディレクトリの作成と初期化
以下のコマンドを実行し、プロジェクトの基本構造を作成します。
```sh
mkdir pro-task-app
cd pro-task-app
npm init -y
npm install express pg jsonwebtoken bcryptjs knex
# 開発用ライブラリ
npm install -D nodemon
実行したものがまだ保存されていなければ保存しましょう。
実行計画書.md として保存してください
これで実行計画書が完成しました！少し時間がかかりましたね。
あまりにも長いため、ここには記載しませんが、そのまま実行して問題ありません。
この実行計画書を基に早速アプリケーションを開発していきます！
モデルは、すぐにトークンを消費してしまうので、 claude-sonnet-4 に変更しておくと良いです。
再び /clear してから、以下のプロンプトを実行します。
@実行計画書.md からアプリケーションを開発して
かなり時間がかかりますが、これによってアプリケーションが開発できます！
ここからは長い旅をお楽しみください。
コマンドの実行が完了してもまだバグがあったので、テスト実行とサーバー起動を繰り返します。
テストを実行したい時のプロンプト
テスト実行してください
サーバーを起動するときのプロンプト
サーバー起動してください
しばらく繰り返したあとサーバーが立ち上がるので、 http://localhost:3000 にアクセスします。
ログイン画面が出てきたら成功です。最初のラフな要件3行でここまでいけました。
ログイン用のIDとパスワードがClaude Codeのログに表示されているので、入力してみましょう。
おっと、エラーがでたので修正をします。
コピーボタンを押してエラーをコピーします。そしてそのままClaude Codeに貼り付けてください。
無事ログインに成功しました🎉
グループを作成してみましょう。
またエラーがでたため、エラーをコピーしてClaude Codeに貼り付けて修正します。
画面が表示されるようになりましたが、作成ボタンがまだ押せなかったので以下のようにプロンプトを送信して修正します。
/groups/new で 作成ボタンが押せません
これで日記帳が作成できました。詳細ボタンを押してみたところ404エラーだったため、また修正を依頼します。
グループの詳細がリンク切れだったので修正してください
日記を書く場合はこのようになっています。
日記一覧はこのようになっています！
まとめ
下書きが実装されていなかったり、日記を作成したあと画面リロードが走っていないなど、細かいバグがまだまだありますが、少ない要件からでも開発プロセスをエミュレートし、テスト実行計画から期待通りのアプリケーションを開発することができました。
Claude Codeに十分なコンテキストを与えれば、様々なアプリケーションを開発することができるのでぜひ使ってみてください。
思ったよりもコストが掛かるので、プランはMAXがおすすめです。
Discussion