最近はバックエンドチームにいて、サーバ側のAPIを作る案件をメインでやっています。そのチームで仕様駆動開発（SDD）をやっています。ツールはOpenSpecで、PBIごとに要望（proposal.md）、仕様（spec.md）、対応方針（design.md）、タスク（tasks.md）の4つを作ってから実装に入る流れです。
SDDの成果物は自然言語で結構な量ができるので、レビューが重くなります。この問題をAIに調べてもらったり、壁打ちしているうちに、そもそも自分たちが何を前提にしていたのかが見えてきたので、業界の一次情報を調べ直しました。この記事は、今の問題と、調べて分かったことをまとめたものです。改善はこれからなので、結果は別の記事に書こうと思います。
tasks.mdがほぼ実装になっていて、レビューが重い
うちのtasksには、どのクラスに何を書いて、どういう動作確認をするか、まで書かれます。生成するのはAIです。分かりづらければスケルトンコードも作らせていますが...
チーム内では「もはやそれ実装と何が違うの？」という話が出ています。
物量も多いです。大きな要件をPBIに分割して小さくしているつもりですが、成果物全体で800行を超えることがあります。レビューはまず2〜3人のモブレビューで「どうしてこうしたか」を説明する場を持ち、そのあとPRレビューをします。モブレビュー自体には利点があって、一番把握している人が実装PRをapproveしなくてもマージできるパターンが出てきますし、育成の場にもなっています。ただ、モブレビューに30分〜1時間、そのあとのPRレビューに1時間はかかります。さらに実装PRのレビューが別にあります。
design.mdも結構重いので、現状は疑問点(Open Question)とリスク(Risks)だけ確認してOKにしています。
tasksまで書いたのは、シニアがAIに出す指示を誰でも再現したかったから
SDDを入れる前は、AIに渡すプロンプトをシニアが頭の中で組み立てていました。PBIと仕様をコンテキストに「Aクラスにaという関数があるからそれを使って、Bクラスにcを用意して、そこでこういう処理をさせて」という指示です。これだと筋の良いコードが一発で出ます。
問題は、メンバーが同じことをやると質が変わることでした。コードベースの全体像や既存コードの落とし穴が見えていないと、AIへの指示が大雑把になり、AIもそれなりのものを返してきます。
そこで「シニアの頭の中でやっていた組み立てを、SDDの成果物としてAIに出させれば、誰が実装しても同じ品質になるのではないか」と考えました。tasksまで具体化しておけば、実装はtasks通りになっているかを見るだけで済むので速い。動作確認項目も、実装レベルまで掘った副産物として精度よく出てきます。テストコードが書けない部分もあるので、この手動確認項目は正直ありがたいものでした。
なのでtasksには、実装手順と手動テストの項目が両方入っています。
課題:具体の実装部分は本気でレビューせずに、設計品質と生産性を両立する
導入してからしばらくして改めてチームで課題を出し合ってみると、仕様駆動開発という名前なのに、具体の実装までがタスクとして設計に含まれているのは違和感がありました。
壁打ちで出てきた整理で、納得したものがあります。AIが精度の高い動作確認項目を出すには、内部で一度「このクラスをこう直すからこの画面に影響が出る」と実装をシミュレートする必要があります。それはAIが答えを出すまでの途中経過で成果物ではない。うちはその途中経過まで全部Markdownに出させて、人間がレビューして合意する対象にしていました。そこまでをmdファイルでレビューすれば重くなります。
また、SDDを始めた2025年12月頃に比べるとLLMの性能自体が上がっており、tasks.mdのような具体の指示を人間が1行ずつ丁寧にレビューするのはやりすぎではないかとも思います。
ここで課題がはっきりしました。具体の実装部分は本気でレビューしないことで、設計品質の担保と生産性を両立する。ただ、どこまでが「具体の実装部分」で、何を残せば設計品質が担保できるのかは、この時点では分かっていませんでした。
2026年後期の一次情報を調べて分かったこと
自分たちだけの問題なのか、そうでないのかを知りたくて、一次情報を集めました。
ボトルネックは検証に移っていた
| 出典 | 分かったこと |
|---|---|
| LinearB 2026ベンチマーク（8M PR） | AI生成のPRはレビュー着手まで平均16時間以上待つ。人間が書いたPRは約200分で、5倍以上の差 |
| Faros AI「AI Productivity Paradox」（10,000人超・1,255チーム） | AI活用度の高いチームはタスク完了+21%、PRマージ+98%。しかしPRレビュー時間は+91%で、デリバリー速度や事業成果に測定できる改善は出ていない |
| DORA 2026レポート | AI導入直後に生産性が落ちるJカーブの原因のひとつを「検証税（verification tax）」と呼んでいる |
| Findy社内実験 | シニアは+30〜50%、若手は−20〜30%。若手は「AIに投げかける問いが十分に整備されていない」ため手戻りが増える |
| TimeeのSDD導入 | 仕様書作成に同期的に1〜1.5日。実装スピードとデプロイ頻度は以前と同等か微増。「仕様書を精査する工程の疲労感」が残った |
コードを書く速さは上がったが、書かれたものを確かめる速さは上がっていない、という話がどの出典にも共通しています。
Farosの数字で気になったのは、PRのマージ数が倍近く増えているのに、デリバリー速度や事業成果には測定できる改善が出ていないことです。DORAは導入直後の落ち込みを、学習コストと、AI生成コードを検証する手間で説明しています。
日本の事例は、うちに近い形をしていました。Findyの若手の生産性低下は「AIに投げかける問いが十分に整備されていない」ことが原因で、メンバーとシニアの差として見ていたものと同じだと思いました。Timeeはcc-sddを入れてレビュー時間は下がったものの、仕様書作成に同期的に1〜1.5日かかり、デプロイ頻度は以前と同等か微増にとどまったと書いています。
SDDの作者とThoughtworksが同じことを言っていた
cc-sddの作者の発表資料には、小さな機能追加でも3,590行超のSpecが生成される、Specだけで実装漏れは防げない、と書いています。
ThoughtworksのBirgitta Böckelerは3つのSDDツールを試した記事で、こう書いています。
To be honest, I’d rather review code than all these markdown files.
（正直なところ、こんなMarkdownファイルの山を読むより、コードをレビューするほうがましだ）
同じ記事で、ファイルやテンプレートやチェックリストを揃えても、エージェントは結局すべての指示には従わなかった、とも書いています。Thoughtworks RadarのSDDの項も、AIのために細かいルールを手書きするやり方は結局スケールしない、という苦い教訓を学び直しているのかもしれない、と締めています。
OpenSpecのdocsでは、designは飛ばしてよく、tasksはAIが実行するチェックリストだった
これは見落としていました。OpenSpecのdocs/concepts.mdにこうあります。
Dependencies are enablers, not gates. They show what's possible to create, not what you must create next. You can skip design if you don't need it. You can create specs before or after design — both depend only on proposal.
（依存関係は、次に何が作れるかを示すもので、次に何を作らなければならないかを示す関門ではない。designは不要なら飛ばしてよい。specsはdesignの前でも後でも作れる。どちらもproposalにしか依存しない）
同じdocsで、design.mdは「技術的アプローチとアーキテクチャ上の判断」を書くものとされていて、例にはTechnical Approach、Architecture Decisions、Data Flow、File Changesの節があります。tasks.mdは「実装チェックリスト。チェックボックス付きの具体的な手順」で、/opsx:applyはこのtasksを実装するコマンドです。
つまりOpenSpecの想定では、人間が判断を読むのはdesignで、tasksはAIが実行するための手順でした。うちはtasksを精読して、designは疑問点とリスクだけ見ていたので、読む場所が逆になっていました。
もうひとつ、OpenSpecはarchive時にspecs/のdeltaをopenspec/specs/にマージして正にしますが、tasks.mdとdesign.mdはchangeごとarchiveに移るだけで、正にはなりません。tasksは最初から、残らない前提の成果物です。
ブレを押さえる場所が、tasks以外にもあった
AIの出力が予測しづらいことも、人の練度で結果がブレることも、消えてはいません。ただ、そのブレを押さえる場所がtasks以外にもありました。
OpenSpecにはopenspec/config.yamlがあります。contextは全成果物の指示に前置される共通の文脈で、rulesは成果物ごとの個別ルールです。うちもcontextは使っていますが、中身は出力の仕方が主で、参考資料とプロジェクトの説明が少しある程度です。禁止事項や置き場所の規約は入っていません。
KDDIアジャイル開発センターの導入記事は、ここに既存ドキュメントや運用ルールを寄せることで「AIに読ませたい文脈をリポジトリ側に置ける」こと、個々のメンバーが独自にプロンプトを工夫しなくても同じ流れで進められるので「AIの活用レベルが個人のスキルに依存しにくくなること」を期待した、と書いています。
GitHub Spec Kitも同じ構造で、不変の原則をconstitutionに置き、PBIごとのspecと分けています。OpenAIのHarness Engineeringは、アーキテクチャ制約をLLMのエージェントだけでなく、決定論的なカスタムlintと構造テストでも監視する、というところまでやっています。
Microsoftの牛尾剛さんもNewbeeの動画で、LLMがどれだけ進化しても自社のドメインは学べないので、それを言語化したskillsやagent definitionがエージェントのアセットで、これだけはエージェントが作り出せない、と話しています。動画の中では皆がローカルで好き勝手にやると「俺の流派」が散らばって、Aさんの学びとBさんの学びが合体しない、という話もしてました。
うちで言う所のアセットは、成果物を出力させたあとに指示して直してもらうことと、レビューで同じ指摘をすることです。その中身は禁止事項や置き場所の規約で、リポジトリに1回書いておけば済むものだと思いました。
元の判断は間違っていなかったが、前提が変わった
「tasksまで決めれば実装が筋良くなる」は、ブレを押さえる場所がPBIごとの成果物しかなかった頃には、正しかったと思っています。実際に効いていましたし、動作確認項目が出てくる副産物もありました。
変わったのは、リポジトリに置いたcontextをモデルがちゃんと読むようになったことと、修正指示付きのlintのような仕組みがツール側に揃ってきたことです。同じことを、もっと安いところでできるようになりました。
ただ、振り切って「tasks不要」にすると逆側で事故ると思っています。Böckelerは詳細な指示を書いてもエージェントは全部には従わなかったと書いていますし、Erik Doernenburgの実験ではエージェントが型の制約を破り、重複を作り、不要なキャッシュを足しています。若手の生産性低下も実測です。牛尾さんは、エージェントの前後でエンジニアは変わらない、イケてる人はエージェントでもイケてる、エージェントは能力が10倍になるアーマーで本体の力が要る、と話しています。
ブレは実在するので、どのクラスにどう置くかは先に決めておく必要があります。designの「新設・変更するクラスと責務、触る境界」の数行は残して、「どのメソッドをどう書くか」の手順は消す、というのが今の考えです。
これから試すこと:レビューの重心をtasksからdesignへ
これらのことを試していきたいと思っています。
-
config.yamlのcontextに、いま出力後の修正指示やレビューの指摘で毎回言っている禁止事項と置き場所の規約を足す。今のcontextは出力の仕方が主なので、そこに構造の制約が加わる形です。※何でもかんでも入れ込むと肥大化してメンテできなくなる罠がありそうなので、試しつつという形になると思います。 - designの出力内容を変更する。疑問点、リスクに加えて、登場人物（クラスと責務）、触る境界と触らない境界、却下した代替案、1ページ以内。メソッドシグネチャや行番号は具体で書かない。
- 手動確認項目専用のmdを作る。※もしくはtasksはそれだけ出力させる。
- tasksの実装タスクについては、人間のレビューから外す。※designの内容でレビュアーは実装後の状態が想像つくはず。
- 直近のPBIを2〜3件選んで、この形で実装させたものと実際にマージされたPRを比べる。同じところに着地するならtasksは仕事をしていなかったことになり、違うなら差分が残すべき制約の正体として検討できる。
いまのレビューとは逆になります。今はtasksを読んで、designは疑問点(Open Question)とリスク(Risks)だけ見ています。試すのは、designを1ページに縛って読み、tasksは読まない形です。designが流し読みになっていたのは重かったからなので、そこは記載内容自体を変えます。
おわりに
Thoughtworks RadarのOpenSpecの項には、こう書いています。
Meanwhile, as models and coding agents continue to grow more powerful, we also recommend teams continue to monitor and revisit native capabilities and re-evaluate the need for SDD tooling.
（一方で、モデルとコーディングエージェントが強くなり続けるなかで、チームはネイティブ機能を継続的に見直し、SDDツールの必要性を再評価し続けることも勧める）
うちも今がその時だと思っています。OpenSpecをやめるつもりはなくて、どの部分が仕事をしているのかを見直したいです。
この記事はZennにも投稿しています。