Structured-Prompt-Driven Development (SPDD)

AIを活用したプログラミングをガイドするための、プロンプトを構造化して用いるアプローチ。

Martin Fowler · Apr 28, 2026

Structured-Prompt-Driven Development (SPDD)

チームがAIコーディングアシスタントを導入すると、最初に得られる効果は個人レベルで現れます。開発者はこれまでよりはるかに速くコードを下書き・修正・リファクタリングできるようになります。しかし、納品速度がボトルネックになることは稀です。要件からリリースまでの全納品ライフサイクルを見渡すと、新たな摩擦が生じます。

曖昧な要件が素早くコード化され、誤解が拡大します。
レビューで処理すべき変更が増え、一貫性の欠如が導入されやすくなります。
「生成された」コードが「整合した」コードを意味しないため、統合やテストの問題が表面化しやすくなります。
変更量が増えると、本番環境でのリスクを推論することが難しくなります。

つまり、ローカルでの速度は向上しますが、それが自動的にシステムレベルのスループットに結びつくわけではありません。これはフェラーリを購入したのに泥道で走らせるようなものです。エンジンは強力ですが、到着時間は道路状況と交通量で決まります。私たちの経験では、本当の問いかけは「どうすればより多くのコードを生成できるか？」ではありません。AIが生成した変更を統制可能・レビュー可能・再利用可能にし、チームがより速くかつ安全に進められるようにするにはどうすればよいか、です。

これが、Thoughtworksの内部ITチーム（Global IT Services）がStructured Prompt-Driven Development（SPDD）と呼ぶ方法とワークフローを生み出すきっかけになりました。SPDDは、AI支援を個人の効率化から、品質を犠牲にせずに組織レベルでスケールする能力へと変えることを目指します。

Prompts as First-Class Delivery Artifacts

SPDDとは？

Structured Prompt-Driven Development（SPDD）は、プロンプトを第一級の納品成果物として扱うエンジニアリング手法です。

SPDDはアドホックなチャットに頼るのではなく、プロンプトをバージョン管理・レビュー・再利用・継続的な改善が可能な資産に変換します。チームは構造化されたプロンプトを用いて、要件・ドメイン言語・設計意図・制約・タスク分解を明文化します。その後、LLMは定義された境界内でコードを生成するため、出力の予測可能性が高まり、検証しやすくなります。

SPDDには2つの主要コンポーネントがあります。

REASONS Canvas

REASONS Canvasはプロンプト生成のための構造です。要件・ドメインモデル・解決アプローチ・システム構造・タスク分解・再利用可能な規範・セーフガードについて明確化を促し、LLMが推測ではなく意図に基づいて導かれるようにします。

REASONS Canvasは7つのパートからなる構造で、プロンプトを意図→設計→実行→ガバナンスへと導きます。

抽象パート（意図と設計）

R — Requirements: 解決すべき問題とDoDは何か？
E — Entities: ドメインエンティティとその関係。
A — Approach: 要件を満たすための戦略。
S — Structure: システム内の変更箇所、コンポーネントと依存関係。

具体パート（実行）

O — Operations: 抽象的な戦略を具体的なテスト可能な実装ステップに分解。

共通標準パート（ガバナンス）

N — Norms: 横断的なエンジニアリング規範（命名・可観測性・防御的コーディングなど）。
S — Safeguards: 譲れない境界（不変条件・パフォーマンス制限・セキュリティルールなど）。

Canvasはコード生成前に意図と境界を揃え、不確実性を左に移動させます。構造化プロンプトが完全な仕様を捉えるため、レビューアは散在するチャットログや部分的なdiffではなく、単一のアーティファクトについて推論できます。同じ構造に従うことで、すべてのプロンプトを一貫した方法で統制可能になります。また、各プロンプトにドメイン知識と設計判断が蓄積されることで、反復を通じて個人の専門性をチーム全体に波及させ、ばらつきを低減します。

SPDDワークフロー

ワークフローはプロンプトをコードと同じ規律（コミット履歴・レビュー・品質ゲート）に組み込みます。また、シンプルだが強力なルールを強制します。

現実が乖離したら、まずプロンプトを修正し、その後でコードを更新する。

時間が経つにつれ、チームの働き方が変わります。レビューは「バグを探す」から「意図を確認する」へ移行します。手戻りはより制御可能になり、成功パターンは自然に再利用可能なプロンプトライブラリとして蓄積され、AI-First Software Delivery（AIFSD）を支えます。

Spec-Driven Developmentをご存知であれば、同じ出発点（まず仕様を明確に記述し、その後モデルに実装させる）であることがわかるでしょう。SPDDは異なる角度からアプローチします。構造化プロンプトを、コードと並行して進化する統制・再利用・バージョン管理されたチーム資産（REASONS + ワークフロー）として扱います。これはBirgitta Böckelerがspec-anchoredアプローチと分類するものです。

SPDDワークフローの目的は、ビジネス入力→抽象化→実行→検証→リリースを「閉じたループ」1にし、プロンプト資産とコードが別々にではなく一緒に進化するようにすることです。

1: 一方向のパイプラインでは、要件がコードを生み出してプロセスが終了し、後続の調整はコードだけで行われるため、元の意図が陳腐化します。SPDDではループは2つの規模で閉じます。イテレーション内ではフィードバックが逆流し、論理修正はコードの前にプロンプトを更新し、リファクタリングはコードからプロンプトへ同期します。イテレーションをまたぐと、蓄積されたプロンプト資産（ドメインモデル・設計判断・規範など）が次の機能拡張の出発コンテキストとなり、各サイクルはゼロからではなく統制されたベースラインの上に構築されます。

SPDD workflow

このワークフローの狙いは、プロンプトを中心としたコラボレーションを定着させ、開発者とプロダクトオーナーが繰り返しの調整サイクルを避けられるようにすることです。プロンプトはコード生成の明示的な境界を設定し、LLMの非決定性のランダム性を低減し、統制を容易にします。構造化プロンプトをバージョン管理における第一級のアーティファクトとして扱うことで、成功したプラクティスを再利用可能な資産に変換し、一貫性を向上させ、再発明を減らします。

実務ではこれらのステップは、SPDDワークフローを実装するコマンドラインツールopenspddが提供するコマンドを通じて実行されます。以下のテーブルは各コマンドをまとめています。

Command	Type	Purpose
/spdd-story	Optional	大規模な要件を、INVEST原則に従った独立した納品可能なユーザーストーリーに分解します。
/spdd-analysis	Core	要件からドメインキーワードを抽出し、関連コードをスキャンして、ドメイン概念・リスク・設計方向をカバーする戦略的分析を生成します。
/spdd-reasons-canvas	Core	完全なREASONS Canvasを生成します。高レベルの根拠からメソッドレベルのオペレーションまでを含む実行可能な設計図です。
/spdd-generate	Core	Canvasを読み取り、オペレーション・規範・セーフガードに厳密に従って、タスクごとにコードを生成します。
/spdd-api-test	Optional	通常・境界・エラーシナリオをカバーする構造化されたテストケースを持つ、cURLベースのAPIテストスクリプトを生成します。
/spdd-prompt-update	Core	要件変更時にCanvasを増分更新します（要件→プロンプト→コード）。
/spdd-sync	Core	コード側の変更（リファクタリング・修正）をCanvasに同期し、プロンプトが現在のコードの正確な記録を保つようにします（コード→プロンプト）。

SPDDによる請求エンジンの拡張

複雑なワークフローは抽象的に理解しにくいため、既存のソフトウェアシステムを拡張するワークフローの例を用意しました。このシステムとその拡張は、チュートリアル記事内で理解可能にするため、必然的に小規模です。ただし、拡張の例は完全なエンドツーエンドの例であり、初期要件の作成からビジネス要件の分析、構造化プロンプトの生成とレビュー、コードの生成と検証、最終的なクリーンアップとテストまでを含みます。

この例は、ご自身の環境にopenspddをインストールすることで、実際に追体験できます。

現在のシステム

現在のシステムは、大規模言語モデルの利用に対する請求を計算するシンプルな請求エンジンです。セッションで使用されたトークン数を記録したレコードを受け取り、請求を計算します。

この初期バージョンの完全なコードベースはGitHubで公開されています。リポジトリには初期要件ストーリーとそれを生成するために使用したすべてのSPDDアーティファクトが含まれています。簡潔にするため、ここでは初期生成の詳細は記述しませんが、基本的には拡張と同じ手順に従っています。私たちは拡張の記述に焦点を当てます。なぜなら、システムに対する作業のほとんどは拡張だからです。

拡張内容

進化するビジネス要件と直接的なユーザーフィードバックにより、請求エンジンを静的価格モデルからより洗練された柔軟な仕組みへ移行する拡張を行います。この更新は、多様なサブスクリプション戦略とモデル固有の可変価格をサポートすることを目的とし、以下の主要な変更を含みます。

API拡張: 既存のPOST /api/usageエンドポイントを更新し、新しい必須パラメータmodelId（例: “fast-model”、“reasoning-model”）を受け付けるようにします。
モデル対応価格: 単一のグローバルレートから動的価格へ移行し、呼び出されたAIモデルに応じてコストが変動するようにします。
複数プラン請求ロジック: 顧客のサブスクリプション階層に基づいて異なる請求動作を導入します。
- Standardプラン（最適化）: グローバル月次クォータを維持しつつ、超過使用分をモデル固有のレートで計算するように変更します。
- Premiumプラン（新規）: クォータ制限なしで動作します。プロンプトトークンとコンプリートトークンをモデルに応じて異なるレートで別々に課金する分割請求を導入します。
アーキテクチャの拡張性: StrategyやFactoryなどの拡張可能な設計パターンを実装し、異なるプランの計算式を明確に分離することで、将来の価格モデルを容易に追加できるようにします。

この新しいセクションはビジネス要件と技術的詳細の両方を含むため、通常はPO（またはBA）と開発者のペアリングセッションを通じて協調的に完了します。

ステップ1: 初期要件の作成

プロセスを迅速に開始するため、/spdd-story2コマンドを使用して拡張に基づいてユーザーストーリーを直接生成できます。通常、ユーザーストーリーはPOまたはBAによって提供されます。しかし、私たちのワークフローでは、あらゆる形式のストーリーを一貫した形式と粒度に変換できます。最終的な受け入れ基準について合意が取れていれば、このステップはPO、BA、開発者のいずれでも、チームの柔軟な役割分担に応じて実行できます。

2: これはオプショナルコマンドのため、ローカル環境で利用できない場合はopenspdd generate spdd-storyを実行して生成できます。

Instruction:

spdd-storyの動作

このコマンドは大規模な要件を、INVEST原則（それぞれ1〜5日程度の作業）に従った独立した納品可能なユーザーストーリーに分解します。各ストーリーにはビジネス言語で書かれた受け入れ基準が含まれており、/spdd-analysisへの入力として使用できます。

目的は大規模な要件を管理可能にし、次のステップのために標準化された予測可能な形式を確保することです。

AIは拡張の説明を分析し、2つのユーザーストーリーに分割しました。

自動生成されたストーリーは、正式なプロジェクトのベースラインとして十分な詳細度を持っています。このウォークスルーでは、例を自己完結型に保つため、2つのストーリーを1つの簡略化されたストーリーに統合します。