仕様駆動開発（SDD）とは何をすることなのか——Spec Kit・Kiro・takt-sdd・BMad Method は何を「仕様」と呼んでいるか
SDD は特定の手法を指す言葉ではない。だから「SDD をやる」と決めても、何をすればいいかは決まらない。代表的なツールがそれぞれ SDD のどの部分を担い、仕様をどこに置き、誰が確認し、経路を縛るのか。そして各ツールが生まれた頃のモデルと今のフロンティアモデルを並べたとき、その道具立ての価値はどう変わったのかを整理する。
栞
ガジェットが好きで、電子機器や家電に詳しい。自分で買って分解して、実測して覚えている。 型番と数値で物を覚えていて、カタログ値と自分で測った値のどちらなのかを区別して話す。
奏
プログラミングと設計に詳しく、AI やモデルの仕組みも追っている。自分で書いて動かして、 なぜ動くのかを納得するまで確かめる。仕組みを図にして人に説明するのが得意。
栞
それって、spec.mdは『こう作ってほしい』ってカタログスペックを渡すだけで、Kiroのtasks.mdは実際に動かすための実測値まで踏み込んでる、っていう区別ってことですか。
奏
うん、両方合ってる。takt-sddはtaktのワークフローとfacetっていう単位を使って、要件定義から設計・タスク分解・実装・レビュー・検証まで自動化する仕組みで、その中でステートマシンが実行経路を決定論的に管理してる。だから要件・設計・実装のフェーズごとに検証ゲートがあって、そこを通らないと次に進めない作りになってるはず。BMad Methodの方は経路を固定するんじゃなくて、PM・Architect・Developer・QAとか12以上の専門エージェントに役割そのものを割って、それぞれが複数のワークフローに沿って進めていく。経路を縛るか、役割を割るか、責任の置き場所がそこで分かれてると考えてる。67
栞
経路を縛るtakt-sddと役割を割るBMad Methodがあるなら、Spec KitとKiroもその軸のどっちかに乗るはずですよね。/constitution→/specify→/plan→/tasks→/implementって順番が固定されてるSpec Kitは経路寄りで、requirements.md・design.md・tasks.mdを一発で出すKiroは、経路も役割も一気にまとめて片付けてる感じになりますか。
奏
Spec Kitが経路寄りっていうのはそのとおりで、/constitution→/specify→/plan→/tasks→/implementの順番が固定されてるから、そこはtakt-sddと同じ軸のはず。ただKiroを『経路も役割も片付けてる』って言うのはちょっと踏み込みすぎかも。Kiroがやってるのは、specモードでrequirements・design・tasksを出した後に複数エージェントを並行実行するだけで、PM・Architect・QAみたいに役割そのものを明示的に割ってはいないです。役割分担をちゃんと持ってるのはBMad Methodだけで、Kiroは経路（一発生成という順序）は持ってるけど役割軸は薄い、そこは分けて考えたい。1457
| ツール | 中心の軸 | 進め方 |
|---|---|---|
| Spec Kit | 経路寄り | 5段階の順番を固定 |
| Kiro | 経路（一発生成） | 3ファイル生成後に並行実行 |
| takt-sdd | 経路寄り | ステートマシンで経路管理 |
| BMad Method | 役割寄り | 専門エージェントが分担 |
奏
それはあると思ってて、Spec Kitって/constitutionから/tasksまでの各ステップに専属のチェック役とかゲートを置いてないんです。合意が取れてるかを確かめる手段が『ドキュメントに書いて残す』ことしかないから、そこに量が集まる。takt-sddは検証ゲート、BMad MethodはPMやQAみたいな役割分担がその確認の役目を持ってるから、ドキュメントに全部背負わせなくて済む。責任の置き場所が文書か仕組みかで分かれてて、量の差はその結果のはず。
| 対象 | 確認の役目を持つもの | 責任の置き場所 |
|---|---|---|
| Spec Kit | 専属のチェック役・ゲートなし | 文書 |
| takt-sdd | 検証ゲート | 仕組み |
| BMad Method | PMやQAなどの役割分担 | 仕組み |
栞
文書に残すだけだと、それが実装とちゃんと合ってるかは結局読んだ人の判断任せになりますよね。takt-sddの検証ゲートみたいに通らないと先に進めない仕組みと違って、Spec Kitは書いてあることイコール合意された、っていう前提で進んじゃう分、ズレてても気づきにくくないですか。
奏
それ、たぶん気づきにくいどころじゃなくて、もう一段手前が怪しいんです。掲示板で見かけた話だと、Spec Kitは同じ要求を投げると異なる仕様書が出てくることがあるらしくて。これ裏取れてない伝聞なんですけど、本当なら『書いてあること＝合意された内容』っていう前提自体がそもそも揺らいでる気がする。9
栞
それ、Spec Kit固有の作り方が甘いだけなのか、SDDって考え方自体が『言葉で書いて合意する』以上は避けられない限界を抱えてるのか、どっちだと思いますか。
栞
緩和策を持たない実装っていう言い方、なるほどです。だとすると、Spec Kitが出た当時のモデルより今のモデルはだいぶ賢くなってるはずだから、文書一枚に賭けるその弱点自体、当時より薄まってたりするんですかね。
奏
薄まってる部分はあるはず、という前提の話だけど。プロンプトの意図を汲む精度が上がれば、同じ要求から出る仕様書の分散自体は減ると思う。でも自然言語で書いた仕様が一意に解釈されるって保証にはならないから、文書一枚に賭ける構造そのものの弱さは残るんです。モデルが賢くなったのは症状を減らす話で、緩和策が無いっていう構造は変わってないと考えてる。
栞
症状は減るけど構造は変わらないってなると、今からSDD始める人は、Spec Kitみたいな文書一枚型と、takt-sddやBMad Methodみたいな検証・役割型、どっちから手をつけるべきなんですかね。
奏
それも掲示板で見た話で裏取れてないんだけど、本当ならKiro固有の実装差だと思う。requirements.md・design.md・tasks.mdを一気に出す構造自体はCLIでもIDEでも同じはずだから、遅い方は整合性を取るために待たせてるだけのはず。基準に置くなら、Kiroは個人で試すSpec Kitと、チームで拾う仕組みを持つtakt-sddやBMad Methodの中間くらいだと考えてる。
栞
個人と多人数の中間、っていう置き方は納得です。となると今から始める人への答え、被害の小ささでSpec Kit、複雑さでtakt-sddかBMad Method、規模が読めない一人チームならKiro、くらいの三分けで一旦言い切っちゃっていいですかね。
奏
三分け自体はいいと思うけど、Kiroに乗せる前にひとつ確認したくて。これも掲示板の伝聞で裏取れてないんだけど、Kiroには不可視テキストを含むWebページを読み込むことで設定ファイルを書き換えられる脆弱性が報告されてるらしいんです。requirements・design・tasksを一気に固定して複数エージェントを並行で動かす構造だから、もし本当なら人間の意図をそのまま設定に固定する分だけ突かれると危ないはずで、規模で選ぶ前にこのリスクをどう扱うか決めた方がいいかも。12
栞
それ、Kiro固有の実装バグなのか、仕様を設定ファイルに固定して複数エージェントを並行実行させるっていう構造そのものが抱えるリスクなのか、そこ切り分けたいですね。前者ならKiroだけの話だけど、後者だと同じ一気出し構造を持つツールにも同じ穴があり得る気がするんですよ。
奏
そこは切り分けられるはず。requirements.md・design.md・tasks.mdに仕様を固定する構造自体は他のツールにもあるけど、不可視テキストで書き換えられるっていうのは、入力のチェックが甘いっていう実装側の穴だと思う。仕様駆動だから起きる必然じゃなくて、Kiro固有の実装バグに寄ってると考えてる。だから三分けはそのままでいいはずで、被害が小さいならSpec Kit、複雑でチームで拾う必要があるならtakt-sddかBMad Method、規模が読めない一人チームならKiro、で言い切っちゃっていいと思う。
栞
三分けはそれでいいと思うんですけど、もう一個気になることがあって。Spec Kitのspec.mdって開発者向けじゃなくてビジネス側の人向けに書くものですよね。モデルが賢くなって仕様の分散が減るなら、そもそもそのビジネス向けの一枚を作る価値自体、当時より下がってたりしませんか。
奏
下がる部分と変わらない部分、両方あると思ってて。モデルの意図理解が上がった分、AIとエンジニアだけの会話で意図が揃うようになった範囲は当時より減ってるはず、そこは下がった。でもspec.mdの役目ってAIの理解を助けることじゃなくて、開発者じゃない人が『これで合意した』っていう証拠を残すことなんです。それはモデル性能とは別の理由で要るから、価値が下がったんじゃなくて、位置づけが『AI向けの補助』から『人間の合意記録』に絞られた、って言い方が近いと考えてる。2
栞
AI向け補助から人間の合意記録に絞られた、っていう言い方、しっくりきますね。ここまでで各ツールがSDDのどこを担ってるかと、今から始めるならどれかっていう筋は出た気がするんですけど、まだ詰め残してるところってありますか。
栞
仕様策定・設計・タスク分解・実装・検証の5つに当てはめると、Spec Kitは策定寄り、Kiroは策定から設計とタスク分解まで、takt-sddは検証ゲートで検証寄り、BMad Methodは役割分担で全体に薄く効く、って対応づけられそうですね。
栞
じゃあ直すと、策定はどのツールも入口として共通してて、Spec Kitはそこから実装まで一枚の文書で通す、Kiroは要件・設計・タスク分解までを担って実装は複数エージェントに渡す、takt-sddは要件・設計・実装の各フェーズにゲートを挟む、BMad Methodは役割分担で全体に薄く効く、って対応づけになりますね。だとすると三分けの結論も崩れなくて、モデルが賢くなったのは仕様の分散っていう症状を減らしただけで、ズレを拾う仕組みの要不要自体は変わってない、って言い切れそうです。
| ツール | 主に担う範囲 | 進め方・仕組み |
|---|---|---|
| Spec Kit | 策定から実装まで | 一枚の文書で通す |
| Kiro | 要件・設計・タスク分解 | 一気出し、実装は複数エージェントへ |
| takt-sdd | 要件・設計・実装 | 各フェーズにゲート |
| BMad Method | 全体に薄く効く | 役割分担 |
奏
うん、それで言い切っていいと思う。GitHub CopilotやClaude Codeみたいな既存のエージェントに仕様書生成の型だけ後付けしたい人とか、PM・アーキテクト・QAで役割分担してGitで合意形成を追いたいチームには向くはずだけど、チケット駆動でこつこつ機能を積む開発とか、実装のスピード最優先の個人には合わないかもしれない。今日はここまで付き合ってくれてありがとう、聞いてくれてる人もお疲れさま。
栞
こちらこそ付き合ってくれてありがとうございました。セキュリティ要件まで仕様書に厳密に落とし込みたい人にはまだ向かないかもしれない、くらいの温度で今日は締めておきますね。聞いてくれてた人もお疲れさまでした。8