仕様駆動開発(Spec-driven Development)は「作る側」の目線で何が変わるか

AI開発・生成AI活用公開日:2026年6月14日最終更新日:2026年8月2日
徐 聖博
徐 聖博

株式会社シンシア 代表取締役社長

Share
目次開く
  1. 仕様駆動開発(Spec-driven Development)は「作る側」の目線で何が変わるか
  2. 仕様の粒度をどう決めるか
  3. チームに導入するときの順番
  4. よくある質問

シンシアへのご相談

自社のAI活用・開発体制について相談する

AIをどこまで内製するか、どの業務から着手するか、体制をどう組むか。開発会社・SIer・事業会社の開発部門の方からのご相談を無料で承っています。同じ問題を自社でも解いている立場としてお話しします。

AI活用の進め方を相談する

まだ検討段階の方は 質問だけでもOK(電話番号は任意)

仕様駆動開発(Spec-driven Development)は「作る側」の目線で何が変わるか

コーディングエージェントに「雰囲気でコードを書かせる」時代が終わりに向かい、仕様を先に固める流れが主流になってきた。この変化は開発の表層ではなく、「誰が何を決める責任を持つか」という根の部分に触れている。

出典: 仕様駆動開発への期待と誤解 ~「仕様」とは、結局何なのか~

要点 (事実のみ)

  • 2025年にAIエージェントへ曖昧な指示でコードを生成させる「Vibe Coding」の限界が顕在化し、2026年現在は要件を整理・分解してからAIに渡す手法が主流になっている
  • 仕様駆動開発」(Spec-driven Development)はその代表例で、要件定義書・機能設計書・実施計画書などのドキュメントを順に作成し、実施計画に従って実装に移るワークフローを指す
  • Planモード」はClineのPlan/Actをはじめ多くのCoding Agentに実装されており、実装前に計画をユーザーに提示・承認してから実装に移ることで「実装したがるAI」にブレーキをかける機能として位置づけられる
  • 仕様駆動開発は「仕様を実装のインプットとして後に手放すのか、仕様そのものを本質として扱うのか」によって意味合いが大きく変わり、その解釈の差がSNS上の論戦を生んでいる
  • 著者の渡邉洋平氏はNTTテクノクロス株式会社に所属し、AWS CDK・Hono等のOSS活動やCoding Agentに関する活動を精力的に行っている

徐 聖博の見解

私が注目するのは、「仕様を書く」という行為がAIエージェント文脈で再評価されている点だ。これは決して新しい発明ではない。ウォーターフォールでもアジャイルでも、「何を作るかを言語化する」ステップは常に存在した。ただ、AIエージェントがコードを大量に生成できる環境では、その言語化の精度がアウトプットの品質に直結する度合いが桁違いに大きくなる。根拠はシンプルで、エージェントが曖昧さを補完する際に使う「文脈の補完ロジック」は必ずしも発注者の業務知識と一致しないからだ。

私自身がコーディングエージェントを実務に使う中で感じるのは、「仕様の粒度」の問題がいちばん難しいということだ。詳細すぎる仕様は更新コストが高く、抽象的すぎる仕様はエージェントが補完に失敗する。Planモードのような「承認ゲート」は、この粒度の問題を人間が介在することで吸収するアプローチだ。一方、仕様駆動開発が目指すのは、承認ゲートを事後ではなく前倒しに設けることで、実装のやり直しを構造的に減らすことだ。

受託開発を主軸に置く立場からも一言添えると、この議論が「ウォーターフォールへの先祖返りか」という論点を呼ぶのは理解できるが、本質的には違う。ウォーターフォールの問題は「仕様を書いたこと」ではなく「仕様が現実から乖離しても修正しなかったこと」にある。仕様をLiving Documentとして扱い、実装と双方向に更新し続けるなら、むしろアジャイルの精神と整合する。AIエージェント時代の「仕様」は、一度書いて終わりの成果物ではなく、エージェントとの対話を通じて継続的に精緻化される素材として捉えるほうが実態に近い。

(編集レンズ: 実装・運用視点 / AIを「作る側」の目線)

仕様の粒度をどう決めるか

見解として「粒度が難しい」と書いたが、実務では判断基準が要る。私が使っている線引きは単純で、エージェントが間違えたときに、その間違いを人間が見つけられるかである。

仕様に書く仕様に書かない
入出力の形(型・必須項目・エラー時の振る舞い)変数名・関数分割の粒度
業務ルール(判定条件、例外、権限)実装アルゴリズムの選択
既存コードのどの層に載せるかライブラリの細かい使い方
やらないこと(スコープ外の明示)コメントの書き方

左側は、間違っていてもレビューで気づけない類のものだ。業務ルールの取り違えは、コードを読んでも「そう書いてある」としか分からない。だから先に書く。右側は間違っていてもコードを見れば分かるので、エージェントに任せてよい。

もう1つ実務的なコツは、「やらないこと」を書くことである。エージェントは指示されていない領域を善意で補完する。「今回は認証周りは触らない」「既存のAPIレスポンス形式は変えない」と明記するだけで、レビュー対象が大幅に減る。

チームに導入するときの順番

仕様駆動を個人の作業スタイルで終わらせず、チームの運用に載せる場合は、次の順で入れるのが失敗が少ない。

  1. プロジェクト設定ファイルに規約を書く。 コーディング規約・ディレクトリ構成・命名規則をエージェントが毎回読む場所に置く。これだけで生成物の手直し量が変わる
  2. 実装前の計画を1機能ずつ残す。 設計方針・影響範囲・テスト方針を書いてから着手する。ドキュメントは後から読む人のために残す
  3. レビュー単位を小さく保つルールを決める。 仕様を先に書いても、1回の指示で数百行出せば結局レビューが破綻する(AIがPRを壊す——ヘッドレスエージェント時代のSDLC再設計
  4. セキュリティ要件を仕様に含める。 指示していない非機能要件は満たされない(バイブコーディングの「動く≠安全」問題

実際にこの進め方で回している事例として、稼働を止めずにデータ基盤を刷新したBPマッチングプラットフォームの開発では、1機能ごとの実装計画ドキュメントを162本積み上げ、担当者が入れ替わっても設計判断が引き継がれる状態を作っている。仕様を書くコストは、引き継ぎコストの前払いだと考えるとつじつまが合う。

よくある質問

Q. 仕様駆動開発はウォーターフォールへの先祖返りではないか。

A. 違う。ウォーターフォールの問題は仕様を書いたことではなく、仕様が現実から乖離しても更新しなかったことにある。仕様を実装と双方向に更新し続けるなら、アジャイルの精神と矛盾しない。

Q. どこまでドキュメントを書けばよいか。

A. 「間違いをレビューで見つけられない部分」だけでよい。全部書こうとすると更新が止まり、更新が止まった仕様は現実と乖離して害になる。

Q. コーディングエージェントの選定基準は。

A. 生成速度や無料枠ではなく、既存コードの規約を読ませられるか、レビュー可能な単位で止められるかで選ぶ。詳しくはコード生成AIの選び方と実務での使い方にまとめた。

Share

シンシアへのご相談

自社のAI活用・開発体制について相談する

AIをどこまで内製するか、どの業務から着手するか、体制をどう組むか。開発会社・SIer・事業会社の開発部門の方からのご相談を無料で承っています。同じ問題を自社でも解いている立場としてお話しします。

AI活用の進め方を相談する

まだ検討段階の方は 質問だけでもOK(電話番号は任意)

徐 聖博のプロフィール写真

この記事の書き手に直接相談する

徐 聖博株式会社シンシア 代表取締役社長

記事の内容について、より具体的に自社のケースで聞きたいことがあれば、徐 聖博を指名してご相談いただけます。営業担当ではなく、 実際に手を動かしている本人が回答します。

シンシアの開発事例

株式会社Atsumell様|サービスを止めずにデータ基盤を刷新したBPマッチングプラットフォームの開発事例

**約11ヶ月・のべ4名のリレーで、機能開発を止めることなく基盤の刷新を完了しました。** 参画時期の重なりは最大2〜3名で、メンバーは1ヶ月の短期集中から5ヶ月の継続稼働までさまざまです。それでも積み上げが効いたのは、**先に入ったメンバーが構造を残していたから**でした。2025年7月に導入された Repository 層の上で、半年後に別のメンバーが移行作業を進めています。認可条件はコード上の仕様コメントとして、スナップショット方式はアーキテクチャドキュメントとして残り、いずれも「引き継いだ人が読んで分かる」形になっています。 この期間に手掛けた業務機能は、協力会社のラベル分類機能、パートナー企業管理画面、CSV による一括招待とデータ出力、案件辞退フロー、ステータス変更通知メールなど多岐にわたります。基盤刷新と機能開発は、どちらかを止めて行ったものではありません。 > 大規模な基盤刷新は「一度止めて作り直す」以外にも方法があります。呼び出し側を壊さない層を挟み、テーブル単位で少しずつ移し、移行と改善を混ぜない。この3つを守れば、リリースを止めずに土台は入れ替えられます。事業を止められないプロダクトほど、この進め方の価値が出ます。 ### この事例からの示唆 **稼働中のサービスでも基盤は入れ替えられる。** 前提は、呼び出し側の契約(戻り値の形)を保つ中間層を挟むこと、移行単位をテーブルや画面まで小さく割ること、そして移行と機能改善を同じコミットに混ぜないことの3点です。この3つが崩れると、不具合が出たときに原因が移行なのか改善なのか切り分けられなくなり、結果として一度止めるしかなくなります。 **メンバーが入れ替わる前提の体制では、成果物より「残る構造」が価値になる。** 短期参画のエンジニアを増やしても積み上がらないプロジェクトは、設計判断が個人の記憶に閉じていることが原因であるケースが多いです。この事例では、認可条件をコード上の仕様コメントとして、データ設計をアーキテクチャドキュメントとして残す運用を徹底しました。開発体制の失敗パターンについては[システム開発の失敗から立て直す方法](https://blog.xincere.jp/articles/system-development-failure-patterns)でも整理しています。 **要件が固まりきらない領域ほど、データ設計で制約を表現する。** 「協力会社が人材情報を編集したら応募内容が変わってしまう」といった問題は、運用ルールやUIの注意書きでは再発します。スキーマとトリガーで表現すれば、アプリ側の実装漏れがあっても壊れません。要件を仕様に落とす工程そのものについては[要件定義の進め方](https://blog.xincere.jp/articles/requirements-definition-process)を参照してください。 ### よくある質問 **Q. 稼働中のサービスを止めずに基盤刷新はできますか。** A. できます。この事例では約11ヶ月にわたり、機能リリースを継続しながらデータアクセス基盤の移行と主キー変更まで実施しました。ただし「一斉に切り替える」やり方では現実的に困難で、呼び出し側を壊さない中間層を用意して段階移行する設計が前提になります。 **Q. 途中でメンバーが入れ替わる体制でも品質は保てますか。** A. 設計判断がドキュメントとコードに残っていれば保てます。この事例では参画時期の重なりが最大2〜3名、1ヶ月だけの参画者もいる体制で、前任の導入した層の上に後任が半年後の移行作業を積み上げています。 **Q. どのくらいの規模・期間の支援ですか。** A. 約11ヶ月、のべ4名(同時稼働は最大2〜3名)です。プロジェクトの規模や費用感の考え方は[システム開発とは](https://blog.xincere.jp/articles/what-is-system-development)で解説しています。 ### 関連する支援領域 - [システム刷新の進め方|検討・計画から移行までの方法](https://blog.xincere.jp/articles/core-system-renewal-guide) — 稼働中システムを止めずに刷新する判断基準 - [業務システム開発の要件定義とは?進め方・手順を7ステップで解説](https://blog.xincere.jp/articles/business-system-development-requirements-definition-steps) — 要件を仕様に落とす工程 - [システム開発の失敗から立て直す方法](https://blog.xincere.jp/articles/system-development-failure-patterns) — 体制・引き継ぎで詰まったときの選択肢 同じように「稼働を止められないプロダクトの基盤を作り替えたい」という課題をお持ちでしたら、[開発のご相談](https://blog.xincere.jp/contacts)からお問い合わせください。現状のコードとデータ構造を確認したうえで、段階移行の設計からご一緒します。

株式会社Atsumellの事例を読む →

この記事が役に立ったら、Google で優先表示を

Google 検索の「優先するソース」に blog.xincere.jp を追加すると、シンシアの新着記事がトップニュースなどで見つけやすくなります。

Google で優先ソースに追加

著者について

徐 聖博のプロフィール写真
徐 聖博
株式会社シンシア 代表取締役社長

株式会社シンシア(Xincere, Inc.)代表取締役。中国生まれ・3歳から日本で育ち、日本語・中国語・英語を操るトリリンガル。大学院でコンピュータサイエンス(進化型ニューラルネットワーク)を研究し、GREE・メドレー・カウンティア・Indeed Japan などで検索エンジン開発やスタートアップの立ち上げ・グロースを経験。2020年に「人の価値をテクノロジーで最大化する」という想いでシンシアを創業した。エンジニア歴15年以上、代表でありながらほぼ毎日コードを書く現役エンジニアとして、基幹システム開発からAIエージェント活用まで顧客の事業成長に並走している。創業に込めた思いはnoteの創業ストーリーに綴っている。

人気記事

    お問い合わせ

    システム開発やAI推進についてのご相談はこちらから

    無料相談を予約する