AI仕様駆動開発（AI-SDD）2026｜SDDが再注目される理由と文書がコードになる時代

こんにちは、株式会社TIMEWELLの濱本です。「AIネイティブ新規事業開発の方法論」の第3回です。私は大企業で新規事業を10年以上手がけ、大企業100社以上が参加した挑戦者支援プログラム「CHANGE by ONE JAPAN」の運営責任者を務め、いまは起業家と社内起業家向けのAI駆動開発プログラム「WARP ENTRE」を運営しています。この記事は、2026年3月に「AI仕様駆動開発（AI-SDD）」として書いた記事を、半年後の状況に合わせて全面的に書き直したものです。

シリーズ「AIネイティブ新規事業開発の方法論」 ①顧客インタビュー中にモックを作る技術 ②リーンキャンバス・7 Powers・デザインコンセプトを1日で回す ③仕様駆動開発（SDD）の再注目と、文書がコードになる時代（この記事） ④AGENTS.md・Skills・Hooks・cronで組織のコンテキストを育てる

「ECサイトを作って」と、いきなりコーディングエージェントに投げたことはあるでしょうか。私はあります。それなりのものが数分で出てきて、感動して、3日後に崩れました。エージェントが細部を想像で埋め、その想像が自分の意図とずれていて、ずれたまま積み上がったのです。設計図なしで家を建て始めたのと同じです。この経験をした人が2025年に世界中で大量に生まれ、その反動として2026年に「コードを書く前に文書を固める」という古い作法が、新しい名前で戻ってきました。仕様駆動開発、SDDです。

この記事は、新規事業開発部門の方に向けて書いています。自分ではコードを書かない方も含めてです。理由は単純で、SDDの中心にある「文書を書く」工程は、エンジニアの仕事ではなく、事業を決める人の仕事だからです。自社のチームがどの段階にあるかは、AIリテラシー診断で確認できます。

要約: 2025年9月にGitHubがSpec Kit、AWSがKiroを出し、仕様を「正」としてエージェントに実装させるSDDが主要ツールの標準になりました。Andrej Karpathyは2023年に「一番新しいプログラミング言語は英語」と書き、2025年に「Vibe Coding」と「コンテキストエンジニアリング」を、2026年に「agentic engineering」を提案し、3月のautoresearchでは「コードはエージェントが編集し、Markdownは人間が編集する」構成を示しました。要件定義書・仕様書・基本設計書・詳細設計書の4文書は抽象度が違うだけで、「作る→厳しくレビューさせる→直す」で書けます。加えて、進捗の記録とエージェントのメモリも、バージョン管理しレビューする対象、つまりコードに近い存在になりました。

当時（2026年3月）から現在（2026年9月）へ。何が変わったか

初版を書いた2026年3月の時点で、私はSDDを「Vibe Codingの反動として広まり始めた概念」と書きました。半年経って、状況は「広まり始めた」から「標準になった」に変わりました。

時系列を整理します。2025年9月2日、GitHubがオープンソースの「Spec Kit」を公開しました。公開時の記事は、失敗の原因をこう書いています。私たちはコーディングエージェントを検索エンジンのように扱っているが、本当は「文字通りにしか受け取らないペアプログラマー」として扱うべきだ。パターン認識は得意だが、曖昧さのない指示が要る。だから仕様を、静的な文書ではなく、プロジェクトとともに進化する「生きた、実行可能な成果物」として捉え直す。仕様が共有の唯一の情報源になる¹。Spec Kitのリポジトリは、2026年9月12日時点で13万5,000を超えるスターを集めています²。

同じ頃、AWSはKiroを出しました。Kiroの仕様は3つのファイルで構成されます。requirements.md（ユーザーストーリーと受け入れ基準）、design.md（技術的なアーキテクチャと図）、tasks.md（追跡できる作業単位への分解）です³。Thoughtworksは2025年11月のTechnology Radarで、SDDを「Assess（評価する価値がある）」に置きました。Kiro、Spec Kit、そして仕様そのものを保守対象にするTesslの3つを比較したうえで、こうも書いています。ワークフローは凝りすぎていて意見が強く、長い仕様ファイルはレビューしにくい。「AIのために詳細なルールを手作りすることは結局スケールしない」という苦い教訓を、私たちは再び学んでいるのかもしれない、と⁴。

この留保は正当です。私も、SDDを「文書を厚くすれば解決する」と読むのは誤りだと思っています。ただ、2026年9月の現時点では、主要なコーディングエージェントのほぼすべてが、何らかの形で「先に仕様を書く」段階を組み込んでいます。どの程度厚く書くかの議論は続いていますが、「書かない」という選択肢は、実務からは消えました。

Karpathyの3年間。「英語」から「agentic engineering」へ

なぜSDDが復権したのかを理解するには、Andrej Karpathyの発言を時系列で追うのが一番の近道です。彼はOpenAIの創業メンバーで、Teslaで自動運転のAIを率いた人物ですが、ここ数年は「AIとどう働くか」についての言葉を作り続けてきました。

2023年1月、彼はXにこう書きました。「一番新しいプログラミング言語は英語だ」⁵。当時は挑発的に聞こえましたが、いま読むと予言です。2025年2月には「Vibe Coding」という言葉を作りました。雰囲気に身を任せ、コードの存在すら忘れて、LLMに書かせる。楽しい捨てプロジェクトには最高だが、それ以上ではない、という含みがありました⁶。2025年6月には、Shopifyのトビ・リュトケが「プロンプトエンジニアリングよりコンテキストエンジニアリングという言葉のほうが、核心のスキルをよく表している。LLMがタスクを解けるように、あらゆるコンテキストを提供する技術だ」と書いたのを受けて、Karpathyは「+1」と応じ、こう続けました。人々はプロンプトを短いタスク記述だと思っているが、産業レベルのLLMアプリでは、コンテキストエンジニアリングとは「次のステップのために、コンテキストウィンドウをちょうど適切な情報で満たす繊細な芸術であり科学」だ。少なすぎても、間違った形でも、多すぎても、無関係でも性能は落ちる⁷。

そして2026年2月。Vibe Codingの1周年に、彼は振り返りを書きました。当時はLLMの能力が低かったので、Vibe Codingは楽しい捨てプロジェクトのためのものだった。1年後のいま、LLMエージェント経由のプログラミングは、専門家の標準的な働き方になりつつある。ただし、より多くの監督と精査を伴って。目標は、エージェントの利用から得られるレバレッジを取りながら、ソフトウェアの品質に一切妥協しないこと。そのための言葉として、彼は「agentic engineering」を挙げました。「agentic」は、99%の時間、自分でコードを書くのではなく、エージェントを指揮して書かせ、自分は監督役になるから。「engineering」は、そこに芸術と科学と専門性があり、学んで上達できるものだから⁸。

この一連の言葉を並べると、SDDの位置がはっきりします。英語がプログラミング言語になり、雰囲気で書かせる時代を経て、コンテキストを設計する技術が問われ、いまは「監督する」働き方に名前がついた、という流れです。監督するには、何を作るかを事前に決めておく必要があります。その「決めたこと」を書いた文書が仕様です。SDDは、agentic engineeringの中身そのものです。

4つの文書は、抽象度が違うだけ

では、何を書けばよいのか。私がプログラムで教えている型は、要件定義書、仕様書、基本設計書、詳細設計書の4つです。この4つは、書いてある内容の抽象度が違うだけです。左は経営者にも読めるレベル、右はAIがそのまま実装できるレベル。飲食店にたとえるなら、要件定義書は「企画書」、仕様書は「メニュー表と接客マニュアル」、基本設計書は「フロア図と動線設計」、詳細設計書は「厨房のレシピ」です。

文書	問い	誰が読めるか	書く内容
要件定義書	なぜ・何を	経営者、家族	背景と目的、ターゲット、解決したい課題、実現する機能、やらないこと、成功の基準
仕様書	使う人から見てどう動くか	事業担当、営業	画面の一覧、画面ごとの項目、入力チェック、操作時の振る舞い、エラー時の振る舞い、画面遷移
基本設計書	外から見てどう作るか	作り手	全体構成、画面設計、データ設計、外部サービス連携、環境の分け方
詳細設計書	中をどう作るか	AI、エンジニア	データベースの詳細、処理の流れ、検証ロジック、エラー処理、環境変数の一覧、セキュリティの考慮点

同じ「飲食店の予約フォーム」でも、文書ごとに書くことはまったく違います。要件定義書は「電話の取りこぼしを減らすために、月20件の予約がフォームから入れば成功」と書きます。仕様書は「名前、電話番号、日時、人数の入力欄と、送信後の確認メール」を書きます。基本設計書は「入力、確認、完了の3画面と、予約データの保存先」を書きます。詳細設計書は「reservationsテーブルのカラム名と型、電話番号の検証ルール」を書きます。

新規事業開発部門の方に一番大事なのは、最初の2つです。要件定義書と仕様書は、コードも技術用語も出てきません。そして、この2つが曖昧なまま後ろの2つを書いても、綺麗な設計図の上に誰も使わないものが建ちます。要件定義書で特に大事なのは「やらないこと」です。やらないことを決めるのは、やることを決めるのと同じくらい重要です。エージェントは、やらないことが書かれていないと、親切心で全部やってしまいます。

書き方は、4文書とも同じ3点セットです。作る、厳しくレビューさせる、直す。真ん中を飛ばさないでください。ここが精度を決めます。要件定義書のプロンプトの型を示します。

あなたは新規事業のプロダクト設計を支援する専門家です。これから要件定義書を作ります。
いきなり書かず、まず私に質問してください。

# 事業の前提
【リーンキャンバスの要点、顧客インタビューで分かった課題（引用付き）】

# ルール
- 質問は最大7つ。「誰が」「何に困っていて」「何ができれば成功か」「やらないこと」を必ず含める
- 私の答えが曖昧なら、選択肢を3つ出して選ばせる
- 技術用語を使わない。家族が読んで分かるレベルで書く
- 完成したら requirements.md として書き出す。項目は「背景・目的」「ターゲット」「解決したい課題」「実現する機能」「やらないこと」「成功の基準」の6つ

書き出されたら、次の指示で厳しくレビューさせます。「この要件定義書を、辛口のプロダクトマネージャーとしてレビューしてください。曖昧な語、測れない成功基準、矛盾する要件、やらないことに書くべきなのに書かれていないものを、それぞれ指摘してください。褒めなくてよいです」。指摘を反映して、仕上げます。仕様書、基本設計書、詳細設計書も、同じ3点セットで進みます。一つだけ、厳守事項があります。詳細設計書には環境変数の「名前と用途」だけを書き、実際のAPIキーやパスワードの値は絶対に書かないこと。文書はGitHubに保存される可能性があるからです。

開発ドキュメント、進捗ドキュメント、メモリドキュメントもコードである

ここからが、初版になかった話です。SDDの議論は「仕様」に集中しがちですが、実際にエージェントと働いてみると、仕様以外の文書が同じくらい効いていることに気づきます。私は三種類に分けています。

一つ目は開発ドキュメントです。コーディング規約、ディレクトリの約束、テストの回し方、デプロイの手順。エージェントが毎回読む「プロジェクトの取扱説明書」で、AGENTS.mdやCLAUDE.mdといった名前で置かれます。OpenAIのCodexやGoogleのJules、Cursorなど多くのエージェントが読むAGENTS.mdは、「エージェントのためのREADME」を標榜し、2026年9月時点で6万を超えるオープンソースのプロジェクトが採用しています⁹。

二つ目は進捗ドキュメントです。何が終わり、何が残り、何を決めて、何を先送りしたか。Kiroのtasks.mdやSpec Kitのタスク分解がこれにあたります。エージェントは、セッションをまたぐと前回の記憶を持ちません。進捗が文書にないと、翌日のエージェントは昨日と同じ検討をやり直します。

三つ目はメモリドキュメントです。エージェントが自分で書く「学んだこと」の記録で、Claude Codeの自動メモリのような仕組みが該当します。Anthropicは2025年9月のコンテキストエンジニアリングに関する技術記事で、コンテキストは「重要だが有限の資源」であり、長いタスクでは「構造化されたメモ取り」で情報をコンテキストの外に保存する手法を挙げています¹⁰。

なぜ、これらを「コードである」と言うのか。Karpathyの2026年の二つの仕事が、それを一番はっきり示しています。3月に公開したautoresearchは、AIエージェントに一晩中、言語モデルの学習実験をさせるリポジトリです。READMEにはこう書かれています。研究者として普段いじるPythonのファイルには触らない。代わりに、エージェントにコンテキストを与えるprogram.mdというMarkdownを「プログラミング」する。train.pyはエージェントが編集し、program.mdは人間が編集する。program.mdは、ごく軽量な「スキル」のようなものだ、と¹¹。人間が直接編集する対象が、コードからMarkdownへ移っています。

4月に公開した「LLM Wiki」では、さらに踏み込みました。RAGのように毎回生の文書から検索するのではなく、LLMが読んだ情報を取り込んで、相互にリンクされたMarkdownのwikiを継続的に維持する。彼はその構成を「Obsidianがエディタで、LLMがプログラマーで、wikiがコードベース」と表現しました。そして、そのwikiの構造と作法を定義するCLAUDE.mdやAGENTS.mdを「鍵となる設定ファイル」と呼び、定期的にwikiの矛盾、古くなった主張、孤立したページを点検する「Lint」の工程を勧めています¹²。Lintは、本来コードの静的検査に使う言葉です。文書に対してLintを回す。これが「文書がコードである」の具体的な意味です。

コードに求められてきたことを、文書にも求める。バージョン管理する。差分をレビューする。仕様からテストを起こして検証する。古くなったら消す。矛盾を検査する。実務としては、次の4点に集約されます。

コードでは	文書では
gitでバージョン管理し、差分をレビューする	仕様書・AGENTS.md・進捗もgitに入れ、変更はPRでレビューする
テストで正しさを検証する	仕様の受け入れ基準からテストを生成させ、仕様とコードのずれを検出する
使われないコードを消す	進捗ドキュメントの「終わったこと」、メモリの古い学びを定期的に削る
Lintで規約違反を検出する	エージェントに文書間の矛盾・古い記述・孤立を点検させる

新規事業開発部門の視点で言い直します。かつて、あなたが外部のベンダーやエンジニアに渡していた「発注書」は、担当者の頭の中と会議の議事録に散らばっていました。いま、それは要件定義書と仕様書として書かれ、エージェントに直接渡され、そのまま実装の根拠になります。書けなければ、作れない。書けば、その日のうちに動くものが出る。文書を書く力が、事業を作る力に直結した、ということです。

「厚い文書」の罠と、大企業でありがちな誤解

ここまで読むと、「では全部を厚く書けばよいのか」と思うかもしれません。違います。Thoughtworksの留保をもう一度引きます。長い仕様ファイルはレビューしにくく、AIのために詳細なルールを手作りすることはスケールしない⁴。KarpathyのコンテキストエンジニアリングのXの投稿も、「多すぎても、無関係でも性能は落ちる」と明言しています⁷。文書は、厚さではなく、抽象度の階段が正しく作られているかで価値が決まります。

大企業でよく見る誤解が二つあります。一つは、「要件定義書」を、既存の情報システム部門が使う数百ページの様式で書こうとすることです。エージェントに渡す要件定義書は、家族が読んで分かる6項目です。様式の厚さは、精度ではなく、承認プロセスの厚さを反映しているにすぎません。もう一つは、文書を「一度書いたら終わり」にすることです。コードと同じで、文書は変更が起きるたびに更新します。コードだけ直して仕様を放置すると、次にエージェントが古い仕様を読んで、逆戻りの修正をします。仕様が唯一の情報源であり続けるための最低条件は、変更を仕様から始めることです。

もう一つ、事業開発部門ならではの利点を書いておきます。4文書のうち上位2つは、そのまま社内の合意形成の道具になります。要件定義書の「やらないこと」と「成功の基準」を経営会議で見せれば、議論は「面白そうか」ではなく「この成功基準でよいか」に変わります。仕様書の画面一覧を営業に見せれば、「この画面なら顧客に説明できる」「この項目は現場で埋まらない」という具体的な反応が返ってきます。文書は、エージェントへの指示であると同時に、人への説明でもあります。

WARPでは、この4文書を参加者自身のテーマで書き、エージェントに実装させ、動くものを出すところまでを扱います。方法論の続きは、第4回のAGENTS.md・Skills・Hooks・cronで組織のコンテキストを育てるで、文書を「個人の作法」から「組織の運用」に広げます。プログラムの構成はWARPのページに載せています。

まとめ

SDDは、新しい技術ではありません。コードを書く前に何を作るかを決める、という当たり前の作法が、エージェントの時代に必須になっただけです。要件定義書、仕様書、基本設計書、詳細設計書の4文書は抽象度が違うだけで、「作る、厳しくレビューさせる、直す」の3点セットで書けます。そして、仕様に加えて、開発ドキュメント、進捗ドキュメント、メモリドキュメントもまた、バージョン管理しレビューし検査する対象、つまりコードに近い存在になりました。Karpathyの言葉を借りれば、人間が編集するのはprogram.mdであり、wikiがコードベースです。

明日やるなら、いま動いている新規事業のテーマで、要件定義書の6項目だけを書いてみてください。特に「やらないこと」と「成功の基準」を。書けない項目があるなら、それが第1回のインタビューで聞きに行くべき場所です。自社のテーマで4文書を書き、エージェントに実装させるところまで一緒にやりたい方は、個別相談でお話ししましょう。

Footnotes

1. Spec-driven development with AI: Get started with a new open source toolkit（GitHub Blog、Den Delimarsky、2025年9月2日） ↩

2. github/spec-kit（GitHub、2026年9月12日取得。スター135,839） ↩

3. Specs — Kiro Documentation（requirements.md / design.md / tasks.md の3ファイル構成） ↩

4. Spec-driven development — Technology Radar（Thoughtworks、2025年11月5日、Assess） ↩ ↩²

5. Andrej Karpathy（X、2023年1月24日）「The hottest new programming language is English」 ↩

6. Andrej Karpathy（X、2025年2月2日）「There's a new kind of coding I call "vibe coding"…」 ↩

7. Andrej Karpathy（X、2025年6月25日）「+1 for "context engineering" over "prompt engineering"…」（tobi lutke の6月19日の投稿への応答） ↩ ↩²

8. Andrej Karpathy（X、2026年2月4日）Vibe Coding 1周年の振り返りと「agentic engineering」 ↩

9. AGENTS.md — A simple, open format for guiding coding agents（「used by over 60k open-source projects」、2026年9月12日取得） ↩

10. Effective context engineering for AI agents（Anthropic Engineering、2025年9月29日） ↩

11. karpathy/autoresearch README（GitHub、2026年3月。「you are programming the program.md Markdown files」「train.py — edited by the agent / program.md — edited by the human」） ↩

12. LLM Wiki — A pattern for building personal knowledge bases using LLMs（Andrej Karpathy、GitHub Gist、2026年4月4日） ↩