Zenn
🐕

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

に公開
GPT
LLM
生成 AI
Claude Code
Vibe Coding
tech

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

2025年5月10日、@d_1d2d さんの投稿（リンク）で紹介された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. 人間によるレビュー・承認

    • 上記で生成されたエピックドラフトは必ずプロダクトオーナーやステークホルダーが確認し、合意を得て確定します。

🔧 プロンプト例：詳細要求付き

あなたはソフトウェアアーキテクトです。
以下の項目を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：テストケース一覧生成

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

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

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

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

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

  2. 人間によるレビュー・承認

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

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

  1. API仕様書（設計ドキュメント）を作成

  2. LLMにエピック・テストとの整合性評価を依頼

  3. 指摘を反映し、仕様をブラッシュアップ

  4. フォーマットテンプレートの用意

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

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

    • 設計段階でエピックとの齟齬や要件漏れが判明した場合、Step1へ戻りエピックを再検討・更新します。
    • 更新後、再度Step3の評価を実施し、一貫性を担保します。

  6. 人間によるレビュー・承認

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

設計ドキュメント例**
**（api_design.md）

# ログイン機能 API仕様

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

プロンプト例：

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

評価例：

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

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

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

    • エピックファイル（epic_login.md）または詳細なユーザーストーリー (user_story_login.md) をLLMに渡す

  2. プロンプト設計

    • エピック／ユーザーストーリー、テストケース、API仕様、コーディング規約をまとめて提示

  3. 自律的レビュー出力

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

  4. フィードバックループの実行

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

      • エピックやユーザーストーリーの不足：Step1へ
      • テストケースの抜け・誤り：Step2へ
      • API仕様の齟齬：Step3へ

    • フィードバック後、各ステップを再実行し、一貫性と品質を担保

プロンプト例：

以下を踏まえ、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）

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

生成コード例（login.py）

"""ログイン関数"""
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実行と人間レビューの反復（スパイラル）を回すことで、継続的な改善と安定した品質を達成

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

Discussion