AIコーディングアシスタントを導入したチームが最初に実感するのは、個人の開発速度が上がることです。ところがチーム全体のデリバリー品質が上がるかというと、話は別です。Thoughtworksの社内IT部門が実務から生み出した「SPDD（Structured-Prompt-Driven Development）」は、プロンプトをコードと同じ規律で管理し、AIコード生成を組織レベルの能力に引き上げる手法です。
この記事でわかること：
- SPDDが解決するAIコード生成の課題
- REASONSキャンバスの7つの構成要素
- openspddを使ったワークフローの流れ
- SPDDが向いているプロジェクトと向いていないプロジェクト
AIコード生成が速くなっても品質が上がらない理由
AIコーディングアシスタントを使えば、1人の開発者がコードを書く速度は確かに上がります。しかしデリバリー全体を見ると、別の摩擦が生まれます。曖昧な要件がそのままコードになり、誤解がスケールします。レビューの負担が増え、一貫性が失われやすくなります。生成されたコードが既存設計と噛み合わず、統合テストで問題が噴出します。
Martin Fowlerはこの状態を「フェラーリを泥道で走らせるようなもの」と表現しています。エンジンは強力でも、到着時間は道路状況で決まるという指摘です。Thoughtworksの社内IT部門（Global IT Services）は、この課題に対して「プロンプトをファーストクラスのデリバリー成果物として扱う」というアプローチを採りました。それがSPDDです。2026年4月28日にMartin Fowlerのブログで公開されました。
SPDDの中核 REASONSキャンバス
SPDDの核は「REASONSキャンバス」という7つの構造を持つプロンプト設計フレームワークです。名前はそれぞれの頭文字から取られています。
抽象レベル（意図と設計）では、R（Requirements） が解決する問題と完了条件、E（Entities） がドメインエンティティとその関係、A（Approach） が要件を満たす戦略、S（Structure） が変更のシステム上の位置づけを定義します。
具体レベル（実行）では、O（Operations） が抽象的な戦略をテスト可能な実装ステップに分解します。
標準化レベル（ガバナンス）では、N（Norms） が命名規則や可観測性などのエンジニアリング基準、S（Safeguards） が不変条件やセキュリティルールなど絶対に超えてはならない境界を定めます。
コードを生成する前に意図と制約を構造化するため、AIの出力が予測可能になります。レビュー対象も「散在するチャットログと部分的なdiff」から「1つの構造化されたプロンプト」に変わります。
openspddによるワークフロー
SPDDの実践を支えるCLIツールがopenspddです。Go製でMITライセンスのもと公開されており、Cursor、Claude Code、GitHub Copilotに対応しています。
ワークフローは段階的に進みます。まず/spdd-storyで大きな要件をINVEST原則に基づく独立したユーザーストーリーに分割します。次に/spdd-analysisでドメインキーワードを抽出し、コードベースの関連部分だけをスキャンして戦略的な分析を生成します。続く/spdd-reasons-canvasで分析結果をREASONSキャンバスに変換し、メソッドシグネチャやパラメータ型まで落とし込んだ実行可能な設計図を作ります。最後に/spdd-generateでキャンバスに従ってタスクごとにコードを生成します。
ここで重要なルールがあります。「現実が設計と乖離したら、まずプロンプトを修正してからコードを更新する」という原則です。ロジックの修正には/spdd-prompt-updateでプロンプトを先に直し、リファクタリングにはコードを先に直してから/spdd-syncでプロンプトに反映します。この双方向の同期ループにより、プロンプトとコードが常に一致した状態を保てます。
Spec-Driven Developmentとの違い
SPDDは「仕様を先に書いてからAIに実装させる」という点で、Spec-Driven Development（SDD）と出発点を共有しています。違いは、SPDDが構造化プロンプトをバージョン管理・レビュー・再利用が可能なチーム資産として扱う点です。
SDDでは仕様書が一方通行になりがちで、コードが進むにつれて仕様と実装が乖離します。SPDDでは双方向の同期ループが回り続けるため、プロンプトが「過去の記録」ではなく「現在のコードの正確な設計文書」として機能し続けます。Birgitta Böckelerの分類では「spec-anchored」アプローチに位置づけられています。
SPDDが効果を発揮する場面
Thoughtworksの実践から、SPDDの適性が整理されています。
高い効果が見込めるのは、同種のビジネスロジックを繰り返し開発する場面です。API構築や業務ワークフロー自動化のように、長期的な保守性が求められるプロジェクトが該当します。規制やセキュリティ基準への厳密な準拠が求められる金融系システムや、複数人での開発で変更の追跡可能性が必要な場合にも適しています。
一方、本番障害の緊急対応や探索的なプロトタイピング、使い捨てスクリプトには向いていません。SPDDの事前設計コストが成果に見合わないためです。ドメインが未定義で業務ルールが曖昧な段階でも、AIに有効な境界を設定できないため効果は薄くなります。
開発者に求められるスキルの変化
SPDDを使いこなすには、従来のコーディングスキルとは異なる能力が必要です。
Thoughtworksが挙げる第一のスキルは「抽象化ファースト」です。コードを生成する前に、どのオブジェクトが存在し、どう連携し、境界がどこにあるかを明確にします。これが不明確なまま生成を始めると、責務の重複や一貫性のないインターフェースが生まれます。
第二は「アラインメント」です。「何をやるか」と「何をやらないか」を事前に言語化し、基準と制約を合意してから実装に入ります。コードの前にプロンプトで意図を固める工程が、手戻りを減らします。
第三は「反復レビュー」です。AI支援をワンショットのドラフト生成ではなく、制御された反復ループとして運用する能力です。レビューの観点も「バグを見つける」から「意図を確認する」に変わります。
個人の速度からチームの品質へ
SPDDは「コードをもっと速く生成する」ための手法ではありません。AIが生成した変更を統制可能・レビュー可能・再利用可能にすることで、チーム全体のデリバリー品質を底上げする仕組みです。openspddはMITライセンスで公開されており、Cursor・Claude Code・GitHub Copilotにそのまま組み込めます。AIコード生成が個人の便利ツールから先に進めていないチームにとって、検討する価値のあるアプローチです。