【検証してみた】仕様だけでどこまで実装できる？Claude Codeを試してみた

はじめに

生成AIはどこまで開発工程を担えるのか。
今回は「実務導入」というよりも、純粋な技術検証としてClaude Codeを試してみました。
検証フローは次の通りです。
claude-code-project-structure

ChatGPTにクライアント役になってもらう
要件定義を提案してもらう
GitHub Copilotで基本設計書・詳細設計書を生成
Claude Codeでモックレベルまで実装

Claude CodeはCLI形式で動作しますが、
従来のようにコマンドだけを打ち込む無機質な操作ではありません。
対話形式で進められるため、自然言語で指示を出すことができます。
そのため、CLIに不慣れな人でも比較的手軽にチャレンジできる印象でした。

結果として感じたのは、
「設計が整理されていれば、ほとんどキーボードを打たずにモックが完成する」
という衝撃でした。

ChatGPTを“クライアント役”にしてみた

要件定義の出発点

今回、ChatGPTには開発者ではなく「クライアント役」として振る舞ってもらいました。

どんな課題を解決したいのか
想定ユーザーは誰か
必要な機能は何か

これらを対話形式でヒアリングし、要件定義を提案してもらう形です。実際のクライアントワークに近い形で進められたため、
議事録ベースでの設計生成の可能性を感じました。

GitHub Copilotで設計書を作成した理由

正直なところ、開始時点では
「Claude Codeはどこからどこまでできるのか？」
が不明でした。そのため、基本設計と詳細設計についてはGitHub Copilotに生成させました。
これは最適解だったというよりも、能力の境界を見極めるための検証工程です。

Claude Codeは設計書をどこまで理解するのか？

md形式の仕様書をそのまま投入

Copilotで生成した基本設計書・詳細設計書（md形式）を
そのままClaude Codeに読み込ませました。
結果として、設計書の意図を保ったまま、

・クラス構成を維持
・命名規則を統一
・文脈を崩さない

という実装が生成されました。

※ディレクトリ構造(.claude/ と docs/ 以外をClaude Codeが生成)
ai-driven-development-workflow

単にコードが整っているというよりも、
設計書の構造と文脈を正しく読み取り、
それを保った形で実装へ落とし込んでいる点が印象的でした。

モック実装までの体験

詳細設計を渡してからの体験は圧巻でした。
しばらく待つだけで、

ディレクトリ構成
ファイル作成
ロジック

が自動生成されます。
キーボードをほとんど触っていません。「待てば完成する」という体験は非常に大きなインパクトでした。

コード生成までの体感時間

今回はClaude Codeにコマンドの全権限を付与せずにコード生成を行いました。なので、所々でコマンドを実行して良いかを聞かれるフェーズがあります。
しかし、それらを除いて実際にコードを生成している時間を合算すると30分も掛からなかったように感じます。

Docker周りでの課題

発生した問題は主に環境依存です。

コンテナ起動エラー
環境変数設定不足
ポート競合

ロジックの重大バグはほとんどありませんでした。
つまり、実装そのものよりも「環境調整」がボトルネックという印象です。環境に関することは、アーキテクチャ的な観点で特定のルールを設けることで解決できるのか、今後検証してみたいと感じました。

今後の可能性：設計工程の自動化

今回の検証で見えてきたのは、クライアントヒアリング以降の
「要件定義 → 基本設計 → 詳細設計 → モック作成」は全てClaude Codeで実施できるという可能性です。

標準化のアイデア

CLAUDE.md

試行プロセスの標準化を可能にするドキュメントです。

挙動の固定（行動制御）
- 仕様を正とする／docs変更禁止／推測実装禁止などを明示し、Claudeの暴走や仕様逸脱を防ぐ
実装プロセスの標準化
- 「要約→計画→合意→実装」「1ユースケース＝1PR」など、作業手順を固定できる
変更範囲・責務の制限
- backendのみ変更可、特定ディレクトリ限定など、編集可能範囲を明示して影響範囲を制御できる

# CLAUDE.md
本プロジェクトでは docs/ 配下の仕様書を唯一の正とする。
docs は閲覧専用であり、変更してはならない。
実装は常に以下の順序で行う：
1. 該当仕様の要約
2. 実装計画の提示
3. 合意後にコード生成
推測による仕様拡張は禁止。
1ユースケース＝1PR単位で変更する。
変更範囲は明示されたディレクトリ内に限定する。
不整合があれば修正せず報告する。

SKILL.md

出力する仕様書フォーマットの標準化を可能にするドキュメントです。

出力フォーマットの統一
- 仕様書・設計書・API定義などの構成（目的／入力／出力／処理フロー／エラー／テスト観点など）を固定できる
記述粒度・品質の標準化
- 曖昧表現禁止、型・制約の明示、JSON例必須など、具体性と再現性のある記述を強制できる
レビュー容易性の向上
- 全ドキュメントが同一構造になるため、差分比較・CodeRabbit評価・仕様逸脱の検出がしやすくなる

# SKILL.md
仕様書は以下フォーマットで出力すること：
1. 目的
2. 対象範囲
3. 入力（型・必須・制約）
4. 出力（成功/失敗例）
5. 処理フロー（番号付き）
6. 認可条件
7. 例外・エラーコード
8. テスト観点（正常/異常/境界）
曖昧な表現は禁止。
具体的な値・条件・制約を明示する。
JSON例は必ず含める。

これらを整備すれば、