Claude Codeで効率的な開発 💡（エピックとテストケースを固めて自律化を実現）

## はじめに：X投稿を契機とした開発プロセス

2025年5月10日、[@d\_1d2d](https://x.com/d_1d2d) さんの投稿（[リンク](https://x.com/d_1d2d/status/1921095680174497996)）で紹介されたAnthropicのCPOの指摘を受け、本記事では**Claude Code**を使った自律開発プロセスを提案します。

> * 70%以上のプルリクエストがClaude Codeで生成されている
> * LLMにPRをレビューさせると、際限なく改善案が出続ける

コード生成AIは強力ですが、コンテキスト不在だと無駄な実装やトークン浪費を招き、品質やコストに悪影響を及ぼす可能性があります。本稿では、以下の5ステップを中心に、スコープを明確化し、永続的ループを防ぐ方法を解説します：

1. エピック定義（要件定義）
2. テストケース設計（テスト計画）
3. 設計ドキュメント整合性評価（詳細設計）
4. コード生成・テスト・レビュー自動化（実装・単体テスト）
5. 人間による最終承認（統合・受け入れテスト）

対象は「ログイン機能」です。5ステップで自律化を実現しましょう。

> **ポイント**: 各ステップはLLMによる実行と人間によるレビューを繰り返すスパイラルモデルです。一度に完結させず、段階的に検証と改善を行うことが肝要です。

---

## プロセス概要：V字モデルによる5ステップの自律化制御

左側（要件定義・設計）から右側（検証・承認）まで、V字モデルに対応する以下の5ステップで自律開発を進めます：

1. **エピック定義（要件定義）**
   Vモデル左上フェーズ：何を実装し、何を除外するかを明確化します。
2. **テストケース設計（テスト計画）**
   Vモデル右上フェーズへの対応：最小限の網羅性を担保するテストプランを作成します。
3. **設計ドキュメント整合性評価（詳細設計）**
   Vモデル左下フェーズ：API仕様とテストプランとの一貫性を評価し、設計を確定します。
4. **コード生成・テスト・レビュー（実装・単体テスト）**
   Vモデルボトムフェーズ：自動化ツールを使って実装と単体テスト、レビューを実施します。
5. **人間による最終承認（統合・受け入れテスト）**
   Vモデル右下フェーズ：統合テスト結果およびレビューを人間が確認し、品質を担保します。

---

### ステップ1：エピック定義（生成AI＋人間）

1. **コンテキストの提供**

   * 目的：何のための機能か（ビジネスゴール、ユーザー要件）を明示
   * 前提条件：技術スタック、既存システムとの連携制約など
2. **プロンプト設計のポイント**

   * 出力形式指定：マークダウン、JSON、表形式など
   * ドメイン知識の注入：「金融システムのログイン機能」など業界固有要件
   * スコープ外明記：SSOや多要素認証など除外項目
3. **反復的リファイン**

   * 初期出力確認後、具体的な要件追加でギャップを埋めるフォローアッププロンプト
   * 不足要素を補う問いかけ（例：「追加で入力バリデーション要件を教えて」）
4. **受け入れ基準（Acceptance Criteria）含める**
   * DONEの定義を明文化：正常系・異常系の具体例

5. **人間によるレビュー・承認**  
   - 上記で生成されたエピックドラフトは必ずプロダクトオーナーやステークホルダーが確認し、合意を得て確定します。

#### 🔧 プロンプト例：詳細要求付き
```plaintext
あなたはソフトウェアアーキテクトです。
以下の項目をJSON形式で出力してください。
1. エピックのタイトルと説明
2. 受け入れ基準（正常系・異常系・境界値）
3. 除外項目リスト
コンテキスト：
- 言語：Python
- ユーザー名とパスワードの最大長：32文字
- 既存認証サービス：OAuth2
````

### 注意点

* プロンプト内で**必ず**スコープ外を示す
* 出力形式が多岐にわたる場合は**サンプルJSON**や**テンプレート**を提示
* **ロール指定**（You are a product manager, software architect）で観点を切り替える

---

### ステップ2：テストケース設計（QA & エンジニア）

1. **テスト対象のスコープ定義**

   * エピック参照：`epic_login.md`またはエピックファイルへのパスを指定
   * カバレッジ範囲：正常系、異常系、境界値、例外処理
   * 除外項目：パフォーマンステスト、UIテスト、外部サービス統合テスト
2. **テストケース分類と優先度付け**

   * 正常系：期待通りの動作確認
   * 異常系：無効な入力時のエラー返却
   * 境界値：文字数・数値範囲の端境ケース
   * 例外処理：想定外エラー発生時の挙動
3. **テストデータ設計ルール**

   * 入力のバリエーション：最大長、最小長、空文字、特殊文字含む
   * 認証パラメータ：有効／無効ユーザー、ロックアカウント
   * 想定外ケース：NULL、型エラー
4. **プロンプト設計のポイント**

   * エピックファイル参照を明記：`epic_login.md`
   * 出力形式指定：リスト、表、unittestコード
   * スコープ外明記：生成しないケースを明示
   * ロール指定："あなたはQAエンジニアです"
5. **フォーマットテンプレートの用意**

   * **テストケース一覧用Markdown表テンプレート**を定義し、プロンプトで共有
   * テンプレートファイル：`test_cases_template.md`
6. **プロンプト例**

#### 🔧 プロンプト例1：テストケース一覧生成

```plaintext
あなたはQAエンジニアです。
以下のログイン機能エピック（epic_login.md）とテンプレートファイル（test_cases_template.md）に基づき、
テストケースの一覧をMarkdown表形式で出力してください。
- カバレッジ：正常系・異常系・境界値・例外処理
- 除外：パフォーマンステスト、UIテスト
ヘッダー：## Test Cases, ## Scope, ## Excluded
```

#### 🔧 プロンプト例2：unittestコード生成

```plaintext
あなたはソフトウェアエンジニア（Python）です。
以下のルールに従い、unittest形式のテストコードを生成してください。
- スコープ：正常系・異常系・境界値・例外処理
- 除外：外部サービス呼び出しテスト
- テストデータ：空文字、最大32文字、特殊文字含む
```

7. **フィードバックループの設計**

   * Step2でテストケース実行やレビュー中に不足・矛盾が見つかった場合、Step1に戻りエピックを更新します
   * 更新後、再度Step2のテストケース設計を行うことで要件の一貫性を担保
8. **人間によるレビュー・承認**

   * 生成されたテストケースおよびテストコードはQAチームや開発チームが実行・確認し、合意を得て確定します。

### ステップ3：設計ドキュメントとの整合性評価

1. API仕様書（設計ドキュメント）を作成
2. LLMにエピック・テストとの整合性評価を依頼
3. 指摘を反映し、仕様をブラッシュアップ
4. **フォーマットテンプレートの用意**

   * 設計ドキュメント用Markdownテンプレート（`api_design_template.md`）を作成し、LLMに提供
   * テンプレートには「やらないこと（スコープ外）」セクションを必ず含める
5. **フィードバックループの設計**

   * 設計段階でエピックとの齟齬や要件漏れが判明した場合、Step1へ戻りエピックを再検討・更新します。
   * 更新後、再度Step3の評価を実施し、一貫性を担保します。
6. **人間によるレビュー・承認**

   * 設計ドキュメントの最終版はアーキテクトやQAチームが確認し、承認します。

**設計ドキュメント例**\*\*
\*\*（api\_design.md）

```markdown
# ログイン機能 API仕様

- **関数名**: `login`
- **引数**: `username` (str, 最大32文字), `password` (str, 最大32文字)
- **戻り値**: `bool` (認証成功: True / 失敗: False)
- **例外**: `ValueError` (文字数超過時)
- **スコープ外**: SSO / パフォーマンス / セキュリティ / UI
```

**プロンプト例**：

```plaintext
以下のエピックとテストケースに基づき、API仕様書が整合しているか評価してください。
```

**評価例**：

* 仕様はエピック・テストと整合
* 改善案: エラーメッセージ形式を明記（例: 日本語テキスト）

---

### ステップ4：コード生成・テスト・レビューの自動化

1. **エピック／ユーザーストーリーの提供**

   * エピックファイル（`epic_login.md`）または詳細なユーザーストーリー (`user_story_login.md`) をLLMに渡す
2. **プロンプト設計**

   * エピック／ユーザーストーリー、テストケース、API仕様、コーディング規約をまとめて提示
3. **自律的レビュー出力**

   * 生成されたコードとテスト結果に対して、改善点やベストプラクティスの観点からレビューコメントを自動で生成させる
4. **フィードバックループの実行**

   * Step4の実行結果（テスト失敗、レビュー指摘）で問題が見つかった場合は、該当箇所に応じて以下の階層にフィードバック：

     * エピックやユーザーストーリーの不足：Step1へ
     * テストケースの抜け・誤り：Step2へ
     * API仕様の齟齬：Step3へ
   * フィードバック後、各ステップを再実行し、一貫性と品質を担保

**プロンプト例**：

```plaintext
以下を踏まえ、Pythonでログイン機能を実装し、テストとレビューを行ってください。
- エピック／ユーザーストーリー: epic_login.md (または user_story_login.md)
- テストケース: test_login.py
- API仕様: api_design.md
- コーディング規約: coding_rules.txt

出力形式：
1. 実装コード（login.py）
2. テスト実行結果（Pass/Fail）
3. 自律的レビューコメント（改善点と推奨修正）
```

**コードルール例**（`coding_rules.txt`）

```plaintext
# coding_rules.txt
- フォルダ構成ガイドラインを定義：
  - ソースコードは`src/`、テストは`tests/`、ドキュメントは`docs/`に配置
- レイヤードアーキテクチャの遵守：
  - プレゼンテーション層、ドメイン層、インフラ層を明確に分離
  - ドメイン層はインフラ層に依存しないこと
- モジュール依存ルール：
  - 上位レイヤーから下位レイヤーへの一方向のみ依存を許可
- コードの複雑度制限：
  - 関数あたりの行数は50行以下、ネスト深度は3レベル以内
```

**生成コード例**（login.py）

```python
"""ログイン関数"""
def login(username: str, password: str) -> bool:
    if len(username) > 32 or len(password) > 32:
        raise ValueError("ユーザー名またはパスワードが長すぎます")
    return username == "admin" and password == "pass123"
```

**テスト結果**: 全テストPASS
**自律的レビューコメント例**:

* `login`関数内のエラーハンドリングをユーティリティ関数に切り出すと再利用性が向上します。
* テストケースにエラーメッセージの内容確認を追加すると品質保証が強化されます。

---

### ステップ5：人間による最終チェック

LLMの結果をエンジニア・QA・ビジネス担当がレビュー・承認し、以下を実施します：

1. **統合テストと受け入れテスト**

   * システム統合後の動作確認を行い、機能が正常に動作することを検証します。
   * ビジネス要件が満たされているか、ユーザー視点での受け入れテストを実施。
2. **エピック（要件）の検証**

   * 最終成果物がStep1で定義したエピック／ユーザーストーリーに沿っているかを照合・確認します。
3. **最終承認**

   * ステークホルダーの合意を得て、正式にリリース準備を進めます。

---

## まとめ 🎯

自律開発プロセスの5ステップ（

1. エピック定義 📌
2. テストケース設計 🧪
3. 設計ドキュメント整合性評価 📑
4. コード生成・テスト・レビュー自動化 🤖
5. 人間による最終承認 ✅
   ）を明確に順序立てることで、以下を実現できます：

* **スコープブレの防止** 🛡️：各段階でのフィードバックループにより要件漏れや誤解を早期に検出
* **品質の担保** 🏆：自動化と人間レビューの組み合わせで、テスト・設計・実装の品質を向上
* **コスト最適化** 💰：無駄な実装や過剰なトークン消費を抑え、効率的な開発サイクルを維持
* **スピード向上** 🚀：LLMによる自律生成と定義済みフォーマットで手戻りを最小化
* **スパイラルモデルの適用** 🔄：各フェーズでLLM実行と人間レビューの反復（スパイラル）を回すことで、継続的な改善と安定した品質を達成

このプロセスを活用して、スコープが明確で一貫性のある高品質開発を実現しましょう。 🎉