はじめに：X投稿を契機とした開発プロセス
2025年5月10日、@d_1d2d さんの投稿（リンク）で紹介されたAnthropicのCPOの指摘を受け、本記事ではClaude Codeを使った自律開発プロセスを提案します。
- 70%以上のプルリクエストがClaude Codeで生成されている
- LLMにPRをレビューさせると、際限なく改善案が出続ける
コード生成AIは強力ですが、コンテキスト不在だと無駄な実装やトークン浪費を招き、品質やコストに悪影響を及ぼす可能性があります。本稿では、以下の5ステップを中心に、スコープを明確化し、永続的ループを防ぐ方法を解説します：
- エピック定義（要件定義）
- テストケース設計（テスト計画）
- 設計ドキュメント整合性評価（詳細設計）
- コード生成・テスト・レビュー自動化（実装・単体テスト）
- 人間による最終承認（統合・受け入れテスト）
対象は「ログイン機能」です。5ステップで自律化を実現しましょう。
ポイント: 各ステップはLLMによる実行と人間によるレビューを繰り返すスパイラルモデルです。一度に完結させず、段階的に検証と改善を行うことが肝要です。
プロセス概要：V字モデルによる5ステップの自律化制御
左側（要件定義・設計）から右側（検証・承認）まで、V字モデルに対応する以下の5ステップで自律開発を進めます：
-
エピック定義（要件定義）
Vモデル左上フェーズ：何を実装し、何を除外するかを明確化します。 -
テストケース設計（テスト計画）
Vモデル右上フェーズへの対応：最小限の網羅性を担保するテストプランを作成します。 -
設計ドキュメント整合性評価（詳細設計）
Vモデル左下フェーズ：API仕様とテストプランとの一貫性を評価し、設計を確定します。 -
コード生成・テスト・レビュー（実装・単体テスト）
Vモデルボトムフェーズ：自動化ツールを使って実装と単体テスト、レビューを実施します。 -
人間による最終承認（統合・受け入れテスト）
Vモデル右下フェーズ：統合テスト結果およびレビューを人間が確認し、品質を担保します。
ステップ1：エピック定義（生成AI＋人間）
-
コンテキストの提供
- 目的：何のための機能か（ビジネスゴール、ユーザー要件）を明示
- 前提条件：技術スタック、既存システムとの連携制約など
-
プロンプト設計のポイント
- 出力形式指定：マークダウン、JSON、表形式など
- ドメイン知識の注入：「金融システムのログイン機能」など業界固有要件
- スコープ外明記：SSOや多要素認証など除外項目
-
反復的リファイン
- 初期出力確認後、具体的な要件追加でギャップを埋めるフォローアッププロンプト
- 不足要素を補う問いかけ（例：「追加で入力バリデーション要件を教えて」）
-
受け入れ基準（Acceptance Criteria）含める
- DONEの定義を明文化：正常系・異常系の具体例
-
人間によるレビュー・承認
- 上記で生成されたエピックドラフトは必ずプロダクトオーナーやステークホルダーが確認し、合意を得て確定します。
🔧 プロンプト例：詳細要求付き
あなたはソフトウェアアーキテクトです。
以下の項目をJSON形式で出力してください。
1. エピックのタイトルと説明
2. 受け入れ基準（正常系・異常系・境界値）
3. 除外項目リスト
コンテキスト：
- 言語：Python
- ユーザー名とパスワードの最大長：32文字
- 既存認証サービス：OAuth2
注意点
- プロンプト内で必ずスコープ外を示す
- 出力形式が多岐にわたる場合はサンプルJSONやテンプレートを提示
- ロール指定（You are a product manager, software architect）で観点を切り替える
ステップ2：テストケース設計（QA & エンジニア）
-
テスト対象のスコープ定義
- エピック参照：
epic_login.mdまたはエピックファイルへのパスを指定 - カバレッジ範囲：正常系、異常系、境界値、例外処理
- 除外項目：パフォーマンステスト、UIテスト、外部サービス統合テスト
- エピック参照：
-
テストケース分類と優先度付け
- 正常系：期待通りの動作確認
- 異常系：無効な入力時のエラー返却
- 境界値：文字数・数値範囲の端境ケース
- 例外処理：想定外エラー発生時の挙動
-
テストデータ設計ルール
- 入力のバリエーション：最大長、最小長、空文字、特殊文字含む
- 認証パラメータ：有効／無効ユーザー、ロックアカウント
- 想定外ケース：NULL、型エラー
-
プロンプト設計のポイント
- エピックファイル参照を明記：
epic_login.md - 出力形式指定：リスト、表、unittestコード
- スコープ外明記：生成しないケースを明示
- ロール指定："あなたはQAエンジニアです"
- エピックファイル参照を明記：
-
フォーマットテンプレートの用意
- テストケース一覧用Markdown表テンプレートを定義し、プロンプトで共有
- テンプレートファイル：
test_cases_template.md
-
プロンプト例
🔧 プロンプト例1：テストケース一覧生成
あなたはQAエンジニアです。
以下のログイン機能エピック（epic_login.md）とテンプレートファイル（test_cases_template.md）に基づき、
テストケースの一覧をMarkdown表形式で出力してください。
- カバレッジ：正常系・異常系・境界値・例外処理
- 除外：パフォーマンステスト、UIテスト
ヘッダー：## Test Cases, ## Scope, ## Excluded
🔧 プロンプト例2：unittestコード生成
あなたはソフトウェアエンジニア（Python）です。
以下のルールに従い、unittest形式のテストコードを生成してください。
- スコープ：正常系・異常系・境界値・例外処理
- 除外：外部サービス呼び出しテスト
- テストデータ：空文字、最大32文字、特殊文字含む
-
フィードバックループの設計
- Step2でテストケース実行やレビュー中に不足・矛盾が見つかった場合、Step1に戻りエピックを更新します
- 更新後、再度Step2のテストケース設計を行うことで要件の一貫性を担保
-
人間によるレビュー・承認
- 生成されたテストケースおよびテストコードはQAチームや開発チームが実行・確認し、合意を得て確定します。
ステップ3：設計ドキュメントとの整合性評価
-
API仕様書（設計ドキュメント）を作成
-
LLMにエピック・テストとの整合性評価を依頼
-
指摘を反映し、仕様をブラッシュアップ
-
フォーマットテンプレートの用意
- 設計ドキュメント用Markdownテンプレート（
api_design_template.md）を作成し、LLMに提供 - テンプレートには「やらないこと（スコープ外）」セクションを必ず含める
- 設計ドキュメント用Markdownテンプレート（
-
フィードバックループの設計
- 設計段階でエピックとの齟齬や要件漏れが判明した場合、Step1へ戻りエピックを再検討・更新します。
- 更新後、再度Step3の評価を実施し、一貫性を担保します。
-
人間によるレビュー・承認
- 設計ドキュメントの最終版はアーキテクトやQAチームが確認し、承認します。
設計ドキュメント例**
**（api_design.md）
# ログイン機能 API仕様
- **関数名**: `login`
- **引数**: `username` (str, 最大32文字), `password` (str, 最大32文字)
- **戻り値**: `bool` (認証成功: True / 失敗: False)
- **例外**: `ValueError` (文字数超過時)
- **スコープ外**: SSO / パフォーマンス / セキュリティ / UI
プロンプト例：
以下のエピックとテストケースに基づき、API仕様書が整合しているか評価してください。
評価例：
- 仕様はエピック・テストと整合
- 改善案: エラーメッセージ形式を明記（例: 日本語テキスト）
ステップ4：コード生成・テスト・レビューの自動化
-
エピック／ユーザーストーリーの提供
- エピックファイル（
epic_login.md）または詳細なユーザーストーリー (user_story_login.md) をLLMに渡す
- エピックファイル（
-
プロンプト設計
- エピック／ユーザーストーリー、テストケース、API仕様、コーディング規約をまとめて提示
-
自律的レビュー出力
- 生成されたコードとテスト結果に対して、改善点やベストプラクティスの観点からレビューコメントを自動で生成させる
-
フィードバックループの実行
-
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・ビジネス担当がレビュー・承認し、以下を実施します：
-
統合テストと受け入れテスト
- システム統合後の動作確認を行い、機能が正常に動作することを検証します。
- ビジネス要件が満たされているか、ユーザー視点での受け入れテストを実施。
-
エピック（要件）の検証
- 最終成果物がStep1で定義したエピック／ユーザーストーリーに沿っているかを照合・確認します。
-
最終承認
- ステークホルダーの合意を得て、正式にリリース準備を進めます。
まとめ 🎯
自律開発プロセスの5ステップ（
- エピック定義 📌
- テストケース設計 🧪
- 設計ドキュメント整合性評価 📑
- コード生成・テスト・レビュー自動化 🤖
- 人間による最終承認 ✅
）を明確に順序立てることで、以下を実現できます：
- スコープブレの防止 🛡️：各段階でのフィードバックループにより要件漏れや誤解を早期に検出
- 品質の担保 🏆：自動化と人間レビューの組み合わせで、テスト・設計・実装の品質を向上
- コスト最適化 💰：無駄な実装や過剰なトークン消費を抑え、効率的な開発サイクルを維持
- スピード向上 🚀：LLMによる自律生成と定義済みフォーマットで手戻りを最小化
- スパイラルモデルの適用 🔄：各フェーズでLLM実行と人間レビューの反復（スパイラル）を回すことで、継続的な改善と安定した品質を達成
このプロセスを活用して、スコープが明確で一貫性のある高品質開発を実現しましょう。 🎉