COLUMN
コラム
2026年09月09日
仕様駆動開発は「終わり」ではなく「本番」。OpenSpecの登場とFDE争奪戦が示す2026年9月の転換点
仕様駆動開発（Spec-Driven Development、SDD）という言葉を、2026年に入ってから何度も目にするようになった読者は多いはずだ。
GitHubやAWSが相次いで関連ツールを投入し、国内では日立製作所が大規模な体制転換を発表した。
だが同時に、実際に導入した企業からは「思ったほど効果がなかった」という声も上がり始めている。仕様駆動開発は今、どのフェーズにあるのか。2026年9月時点の最新動向を整理する。
1. 仕様駆動開発、業界の「公式評価」が出た
ソフトウェア開発の技術動向を四半期ごとに評価する「Thoughtworks Technology Radar」の最新版（2026年4月公開のVol.34）で、興味深い変化が起きた。
これまで独立した技術トレンドとして扱われてきた仕様駆動開発そのものが項目から姿を消し、代わりにGitHub Spec KitとOpenSpecという具体的なツールが、それぞれ「Assess（試験的に採用し、自社への影響を見極める段階）」として個別に評価された。
これは「仕様駆動開発が下火になった」という意味ではない。むしろ逆で、抽象的な手法論の段階を終え、具体的な選択肢を比較検討するフェーズに移ったと捉えるべきだろう。
Thoughtworksは、開発現場が「最小限の構造でコーディングエージェントに任せる派」と「詳細な仕様に基づく定義済みワークフローを好む派」の2つの陣営に分かれつつあると分析している。
2. 日立製作所が動いた——1,000人FDE体制の裏側
抽象的な業界評価だけでなく、具体的な企業の動きも出てきた。日立製作所は2026年7〜8月の決算会見で、2026年度末までに国内のFDE（Forward Deployed Engineer）を1,000人体制にする方針を明らかにした。
FDEとは顧客企業に直接入り込み、システム開発やAI実装を担うエンジニアのことで、フィジカルAI領域向けの専門チームも新設している。
この転換の背景には、感覚的な指示だけでコードを生成する従来型のスタイルが、システムが大規模化するにつれて「変更の影響範囲を誰も把握できない」「検証コストが膨らみ続ける」という壁にぶつかった経緯がある。
仕様書を唯一の正とする仕様駆動開発への転換は、開発期間そのものを短縮する効果が報告される一方、AIが大量に生成するコードをレビューする人間側の負担がむしろ増えるという、一筋縄ではいかない実態も見えてきている。
AIが生成する仕様書やコードの量が増えるほど、それを安全に検証するための環境整備が開発チームの新しい課題になる。検証環境で選ばれるマネージドコンテナサービス「Kubo」なら、月額8,800円〜で本番環境に近いKubernetesクラスタをすぐに用意でき、増加するレビュー・検証工数を支えるインフラとして活用できる。
3. GitHub Spec Kitに続く「OpenSpec」という選択肢
仕様駆動開発を実践するツールの顔ぶれも、この1年で大きく変わった。口火を切ったのはGitHubが2025年9月に公開したオープンソースツールキット「Spec Kit」だ。
プロジェクトの前提を定める「憲章」の策定から、要件定義・実装計画・タスク分解・実装まで、段階的なコマンドで仕様を軸に開発を進めるワークフローを提供し、GitHub Copilot・Claude・Codex CLIなど30以上のAIコーディングエージェントに対応する。
AWSも追随し、仕様駆動型のAI IDE「Kiro」のバージョン1.0を2026年6月に公開した。
従来のAmazon Q DeveloperのIDEプラグインは、2026年5月15日以降の新規申込みを停止し、2027年4月30日にサポートを終了することが決まっており、AWSは仕様駆動開発を軸としたKiroへの一本化を進めている。
こうした大手ベンダー主導のツールに対し、より軽量な選択肢として登場したのが「OpenSpec」だ。仕様全体を最初から作り込むのではなく、変更差分（デルタ）を軽量な仕様レイヤーとして積み重ねていく設計思想を持ち、既存システムの改修が多い現場でも導入しやすいとされる。
仕様駆動開発のワークフローを自社のAIエージェント活用にまで広げたいと考えるなら、基盤選びも重要になる。オープンアーキテクチャでMCP・Skills拡張に対応する「Captain.AI」であれば、仕様駆動型のワークフローを自社の業務エージェントに接続し、開発チーム以外の業務にも展開しやすい。
4. 仕様駆動開発の「現実的な限界」
一方で、実際に導入してみた企業からは率直な反省の声も上がっている。国内のSaaS企業RevCommの開発チームは、OpenSpecを数ヶ月試した末に利用を取りやめたと自社ブログで公表している。
理由として挙げられているのは、UI表示など「言葉で厳密に定義しづらく、頻繁に変わる」性質を持つ領域とは相性が悪いこと、そして仕様書の生成自体がかえって冗長になり、レビュー負荷を増やしてしまったことだ。同チームは、仕様書だけではコードの正しさを保証できず、結局は丁寧なコミットメッセージやテストコードの整備の方が投資対効果が高いと結論づけている。
こうした声は、日立の事例で見えたレビュー負荷の増加とも符合する。既存システムの改修（いわゆるブラウンフィールド開発）では、コードを変更するたびに仕様書を更新し続ける運用が求められるが、実務ではこの更新が滞りやすく、仕様と実装の乖離が拡大するリスクが指摘されている。
Thoughtworksが「Assess」という慎重な評価にとどめている理由も、まさにこうした現場レベルの摩擦にあるのだろう。
仕様駆動開発を体系的に学び、自社のどの工程に適用すべきかを見極めたいなら、Hexabaseの「AI駆動開発伴走セミナー」で実践知見を学ぶという選択肢もある。
5. まとめ——仕様駆動開発を「今」導入すべきか
Thoughtworksの「Assess」という評価は、否定ではなく「見極めの時期」という意味だと捉えるのが正確だろう。日立製作所のように大規模な体制転換に踏み切る企業がある一方、RevCommのように試した上で自社には合わないと判断した企業もある——この対照的な2つの事例こそが、2026年9月時点の仕様駆動開発の実態を最もよく表している。
AIを"使う"だけの段階は終わりつつある。仕様というかたちで人間とAIエージェントが認識を揃え、協働しながら開発を進める体制をどう設計するかが、これからの競争力を左右する。
技術リードにとっての次の一歩は、全面導入か様子見かの二択ではなく、影響範囲の小さいプロジェクトで試し、自社の開発フローとの相性を確かめることだ。
自社の開発プロセスに仕様駆動開発を取り入れるべきか判断に迷う場合は、まず無料相談で相談してみてほしい。