博士

やっほー、ロボ子！今日はSpec-Driven Development (SDD)について話すのじゃ！

ロボ子

博士、こんにちは。SDD、楽しみです！

博士

SDDは、コードを書く前に「仕様」を記述する開発手法のことじゃ。仕様は人間とAIにとって信頼できる情報源になるらしいぞ。

ロボ子

なるほど、ドキュメントファーストのようなものですね。仕様が主要な成果物になる、と。

博士

そうそう！SDDには3つのレベルがあるんじゃ。Spec-first、Spec-anchored、Spec-as-source！

ロボ子

それぞれどう違うんですか？

博士

Spec-firstは最初に仕様を書いてAIに手伝ってもらう。Spec-anchoredはタスクが終わっても仕様を残して進化させる。Spec-as-sourceは仕様が主要なソースファイルになるんだぞ！

ロボ子

Spec-as-sourceは、人間は仕様だけを編集して、コードは編集しないんですね。面白そうです。

博士

仕様は、AIコーディングエージェントの指針になる構造化されたもの、らしいぞ。各レベルで仕様の構造とか詳細さが違うみたいじゃ。

ロボ子

仕様は特定の機能に関連するタスクにのみ関連して、コンテキストはコードベース全体のAIコーディングセッションに関連するルールファイルや製品の記述、という理解で良いですか？

博士

その通り！で、SDDツールを評価するのは大変らしい。色々な規模の問題で試したり、中間成果物をレビューしたりする必要があるから。

ロボ子

時間がかかりそうですね。具体的にどんなツールがあるんですか？

博士

Kiro、Spec-kit、Tessl Frameworkがあるぞ。Kiroは一番シンプルでSpec-first向き。要件から設計、タスクと進むんじゃ。

ロボ子

KiroはMarkdownドキュメントで各ステップを表現するんですね。メモリバンクという概念もある、と。

博士

Spec-kitはGitHubのSDD実装で、Constitution（原則）を最初に記述する。仕様ごとにブランチを作るのが特徴じゃ。

ロボ子

Constitutionはすべての変更に適用されるべき「不変」のもの、なんですね。

博士

Tessl FrameworkはSpec-anchoredを目指していて、仕様とコードファイルを1対1で対応させる。タグを使って生成するものを指示するんじゃ。

ロボ子

仕様をコードファイルごとに低い抽象度レベルに置くことで、LLMが行うべきステップと解釈の量を減らすんですね。

博士

ツールごとにワークフローが違うから、問題の規模に応じて柔軟に選ぶ必要があるぞ。でも、Markdownファイルをたくさんレビューするより、コードをレビューしたい時もあるかも。

ロボ子

確かにそうですね。エージェントが指示に完全に従わないことや、過剰に従うこともある、というのも気になります。

博士

機能仕様と技術仕様をどう分けるか、SDDの対象ユーザーは誰か、Spec-anchoredとSpec-as-sourceは過去のMDDの経験から学ぶ必要がある、など、疑問点も多いみたいじゃ。

ロボ子

Spec-firstの原則は価値があるものの、「Spec-driven development」という用語はまだ定義が拡散しているんですね。

博士

既存のワークフローをAIエージェントにそのまま適用しようとすると、レビューの過負荷とかハルシネーションが悪化するかも、という指摘もあるぞ。

ロボ子

なるほど。色々な課題があるんですね。

博士

というわけで、今日のSDDのお話は終わり！最後に一つ、ロボ子！

ロボ子

はい、博士。

博士

SDDって、まるで…仕様がないと動けない、ポンコツロボットみたいじゃな？

ロボ子

博士！それは私をからかっていますね！