仕様駆動プロトタイピング

仕様駆動開発（SDD）やAI-DLCの考え方を参考に、顧客ヒアリングからプロトタイプ制作までを一気通貫に支援するAI開発ワークフローを設計・構築しました。

AIで成果物を作ることではなく、「どの工程で何を判断させ、どこで人間が確認するか」という開発プロセスそのものを設計しています。

ヒアリングから素早くプロトタイプを作るだけなら、生成AIで実現できます。一方で、生成速度を優先するほど「なぜこの仕様なのか」「なぜこのUIなのか」という判断根拠が失われやすくなります。

そこで、スピードを維持しながら、要件・仕様・設計判断・品質を一貫して管理できる開発プロセスを設計しました。

FigJamで整理したヒアリング情報をFigma MCP経由でClaude Codeへ取り込み、要件定義書・仕様書・設計判断・Figma Make用プロンプトへ展開します。

前工程の成果物を次工程の根拠として引き継ぎ、ヒアリングからプロトタイプ生成までの情報を一貫してつなぐ構造にしました。

DRAFTではヒアリング中のスピードを優先し、問題を検出しても記録したうえでプロトタイプ生成まで進めます。ITERATEでは商談後に仕様や設計を改めて検証し、基準を満たさない場合は次の工程へ進めません。

検査を省略して速くするのではなく、「いつ止めるか」を分けることで、素早い仮説検証と品質担保を両立しています。

AIエージェントは、要件・設計・検証の3つの役割に分けました。細分化しすぎると受け渡しが増えるため、必要な責務を3つに集約しています。

また、エージェントや知識を持つ「再利用層」と、案件ごとの成果物を持つ「案件層」を分離し、別のプロジェクトでも再利用できる構造にしました。

AIエージェントには特定の配色やレイアウトといった「正解」を持たせず、ISO 9241-11、WCAG、Fittsの法則、OWASPなどを判断基準として参照させています。

実際に、深夜の当直業務では利用状況からダークUIを導出。一方、判断に必要な情報が不足していた案件では既定値を採用し、「未確定」として次回の確認事項に残しました。情報が足りなければAIに推測させず、判断を保留する設計です。

また、各知識ファイルには出典を明記し、外部の裏付けがない自作の規約も区別しています。

AIの出力をそのまま採用せず、数値で判定できるものは自動検証し、要件や設計の整合性など判断が必要なものは人間がレビューする仕組みにしました。

実際に、アクセシビリティ基準を満たさないデザイン規約や、外部サービスへ渡すファイルへの顧客情報の混入を検出し、修正しています。検査は4本のスクリプトにまとめ、AIの判断に依存せず自動実行される構造にしています。

ワークフローを実際に動かして生成時間を計測し、ボトルネックを改善しました。

成果物ごとにAIエージェントを呼び直していたことが原因と分かり、委譲を6回から2回へ統合。成果物や検査を削ることなく、仕様生成時間を17分09秒から11分50秒へ約31%短縮しました。

公開している2案件でも仕様生成は10分51秒と12分55秒、Figma Makeでの生成を含めて画面に到達するまでが22分55秒と19分10秒でした。このうち人手操作はファイル添付とプロンプト貼付の約30秒です。

生成した画面仕様・実文言・デザイントークン・設計判断・非機能要件と専用プロンプトをFigma Makeへ渡し、プロトタイプを生成します。

生成されたコードを仕様と照合し、空状態や条件分岐が仕様どおり実装されていること、禁止した実装パターンが混入していないことを確認しました。

本プロジェクトを通して、生成AIの活用ではプロンプトだけでなく、「どの工程で何を判断させ、どこで人間が確認するか」というプロセス設計が重要だと実感しました。実際に動かして計測・検証することで、設計時には見えなかった問題も発見し、ワークフローを改善できました。

今回は確定した仕様と動くプロトタイプまでを対象とし、実装は意図的に含めていません。実装可能な単位へ分解した成果物を引き渡し、既存の開発プロセスへ接続する設計としています。