■ 1. 「無くても成り立つもの」との向き合い方
- うまい棒納豆味とからし:
- からしの風味が美味しい商品として成立している
- 納豆にカラシを入れる本来の大きな目的は、きつい臭いを打ち消すことだった
- そのルーツは納豆が庶民の食べ物として定着した江戸時代まで遡る
- カラシが臭い消しとして必要だった背景:
- 当時は納豆菌の発酵管理が難しく、主に気温の低い冬場に作られていた
- 冷蔵保存の手段が乏しく、再発酵によってアンモニア臭が発生することが大きな問題だった
- 安価で入手しやすいカラシが庶民の間で広まっていった
- カラシの役割変化:
- タレやカラシが添付された商品が売られるようになったのは1970年代前半
- 冷蔵保存技術や物流網の発達によって臭いの問題も軽減された
- カラシの役割は臭い消しから風味付けへ比重が移った
- 本講演の問い:
- 「無くても成り立つもの」とどう向き合うか
■ 2. 仕様駆動開発の定義
- 仕様書の位置づけ(Kiro):
- 仕様書とは、一種のバージョン管理され人間が読めるスーパープロンプト
- 仕様書の位置づけ(GitHub):
- 仕様書を静的な文書ではなく、プロジェクトと共に進化する生きた実行可能な成果物として捉え直す
- 仕様駆動開発(SDD)の登場:
- 2025年7月にAWSがIDE「Kiro」の発表と共に提唱した
- レトロニムとしてのSDD:
- 「実装前に仕様(書)を作る」というVibe Coding以後のレトロニム
- レトロニムとは、新しい事物の誕生後に既存の事物を区別するため後から作られた言葉
- 例として固定電話、オンプレミスが挙げられる
- SDDの2つの実用的側面:
- フレームワークとしてのAIワークフロー
- エージェント用のドキュメント管理(長期記憶)
- 定義が拡張されているケース:
- 書籍『仕様駆動開発 実践入門』はGitHubの4プロセスに3工程を足し、7工程へ拡張している
- 追加分は原則決定(Constitution)、検証・受入(Verify / Accept)、移行・運用(Migration / Operation)
- 英語圏が「速く作る」ための4工程であるのに対し、合意形成・契約・品質という日本の開発現場の現実に着地させる意図がある
■ 3. 側面1: フレームワークとしてのAIワークフロー
- AIワークフローの定義:
- エージェントにステップを伝えること
- Agentはエージェント自身が停止時点を決めるループである点で対比される
- 各ツールのワークフロー:
- Kiro: Requirements → Design → Tasks
- Spec-Kit: Specify → Plan → Tasks
- OpenSpec: Proposal → Specs → Design → Tasks
- 共通点:
- 仕様駆動開発は実態として「仕様→設計→タスク化」のワークフローを核にしている
■ 4. 側面2: エージェント用のドキュメント管理
- spec実装の3パターン:
- spec-first: まずspecを書いて開発し、タスク完了後にspecを破棄する
- spec-anchored: タスク完了後もspecを保持し、将来の変更・保守でもspecを更新し続ける
- spec-as-source: specを原本としてコードは生成され、人は直接編集しない
- 実用の実態:
- 事実上、実用されているのはspec-firstとspec-anchoredの2種類
■ 5. 仕様駆動開発が生まれた時期
- ワークフロー検討の時期:
- 前述の「仕様駆動開発のワークフロー」は2025年7月〜2025年9月頃に検討されたもの
- 本登壇(2026年8月6日)の約一年前にあたる
- 当時の主流モデル:
- Claude Sonnet 4、Opus 4.1
- GPT-4o、GPT-4.1、o3、そしてGPT-5
- DeepSeek V3.1、Qwen3-Coder、gpt-oss
- LLMモデルの転換点:
- Simon Willisonは、2025年11月のGPT-5.2とOpus 4.5が本当に転換点を表しているように感じると述べる
- モデルが漸進的に良くなり、突然多くの難しいコーディング問題が解けるようになる不可視の能力ラインを越えた瞬間である
- 仕様駆動開発(2025年9月)以後、自走性能が向上した
■ 6. Spec-firstとPlanモードの合流
- Spec-firstは「いつものPlanモード」に見える:
- 仕様駆動開発のうちSpec-firstのスタイルはPlanモードに合流している
- Coding Agentの多くの実装に含まれる当たり前のものになりつつある
- 両者の対応関係:
- spec-firstはまずspecを書いて開発し、タスク完了後にspecを破棄する
- Plan Modeは計画・設計から作成したタスクリストの通りに実装する
- Plan Modeは初期こそReadOnly(Ask)だったが、spec-first化が主流となった
- Planモード不要論:
- Peter Steinbergerは自身がPlanモードを使わないと述べる
- PlanモードがCodexに追加された理由は「Claude脳」の利用者に向けた機能だから
- ただエージェントと普通に会話すればよい
■ 7. Spec以外の記録手法
- 考えて保存するだけならPlanやSpecは必要ない
- Skills: mattpocock/grill-with-docs:
- Agentが利用者に一問ずつ質問する
- 決まった用語を用語集(CONTEXT.md)に記録する
- 重要な設計判断をdocs/adr/に記録する
- LLM Wiki(LLM Knowledge Base):
- Andrej Karpathy提唱のナレッジベース管理手法
- Open Knowledge Format(OKF):
- Google提唱のナレッジ標準化フォーマット
■ 8. 仕様駆動開発の消費期限
- AIワークフローとしての側面の消費:
- 「事前に作成したタスクリストの実装」はエージェントハーネスに一般化されている
- ドキュメント管理としての側面の消費:
- 代替のプラクティスが発見され、唯一無二ではない
■ 9. チーム開発で見える別の景色
- ソロプレイとチームプレイの差:
- チームで開発すると別のものが見えてくる
- 実際にあった依頼(2026年4月):
- Agent(CLI)を使うが、AI駆動開発の進め方をチームで決めたいので提案してほしいという依頼があった
- 仕様駆動開発を想定しているが、もっといい手法があったらそれを採用したいという要望も伴っていた
■ 10. AI駆動開発の「守」の不在
- 守るべき型が無い状況:
- AI駆動開発について「守破離」以前に守るべき型が無い
- 「エンジニアたるもの月3000円〜30000円を負担し、余暇で慣れる」という特殊なムードが前提に置かれている
- 自著では可能な限り「型」のベースを体系化したが、チーム全員に定着させるには難しさがある
- 守破離の3ステップ:
- 型を守る
- 型を破る
- 型を離れる
- 立てるべき問い:
- AI駆動開発の「型」とは何を指しているか
■ 11. 既存フレームワークの検討
- AI-DLCの構成:
- 理論としてAI-DLC Whitepaperが存在する
- 実践としてAI-DLC Workflowsが存在する
- AI-DLC見送りの経緯:
- 理念を浸透させワークフローを導入するのは期間的にも厳しかった
- 部分的な導入に関してもメリットを説明できず見送った
- AI-DLCが難しかった理由:
- 開発プロセス全体に大幅な見直しを強いるものである
- 単にルールを導入するだけではなく、既存プロセスとの対応や会社標準との適合性の検討が必要だった
- 一言でいうと「重たかった」
- ベスプラSkills系の例:
- obra/superpowersはブレインストーミング、Git Worktrees、実装計画作成、サブエージェント駆動開発で構成される
- grilling(実装前の明確化)、Ponytail(実装中の過剰防止)、babysit-pr(PR後の追従)を組み合わせるガードレール構成もある
- ベスプラSkills系の評価:
- 個別の推奨プロセスとしては良いが、ワークフローの型としては不足するように感じた
- 標準化目的のハーネスに足りていないものは、人間のためのコンテキストエンジニアリング
■ 12. 人間のためのコンテキストエンジニアリング
- Context Engineering:
- コンテキストを書く/選ぶ/縮める/分けるための技術
- LLMが参照できる範囲:
- Contextはプロンプトと外部情報からなる
- Context WindowはLLMの理解できるトークンの総容量
- LLMとの「会話」において、総トークン数がContext Window以内である必要がある
- 人間が参照できる範囲:
- Thoughtworks Technology Radarが「codebase cognitive debt(認知負債)」を注意対象として採用した
- コードベースの認知的負債とは、システムの実装と、そのシステムがどのようになぜそのように動作するのかというチーム内の共通理解との間の隔たりが徐々に拡大していく状態
■ 13. 理解負債と認知負荷
- Comprehension Debtの研究:
- 2026年の研究では、207人の学生が8週間にわたり記録した日誌からGenAIによる「Comprehension Debt」が分析された
- ブラックボックスとしてコードを受け入れる
- プロジェクト文脈と合わないコードを採用する
- AI依存により自力で扱う能力が低下する
- 検証を省略する
- 認知負荷は開発のブレーキ:
- 人間の理解する速度はAgentにとってのブレーキになり、開発が滞留する
- Agentの速度は500PR/dayに達する
- チームのレビュー能力は10PR/dayにとどまる
- 「儀式」の見直し案:
- レビューをコード生成の一部とする
- Agentが自身の作業を検証する
- 敵対的なAgentにレビューさせる
- 負債と負荷の整理:
- エージェントの生成物を理解できていないと負債になる
- エージェントの生成速度で理解すると開発速度が遅れ、レビュワーに負荷がかかる
- 理解するためのフォーマット、及びそれを扱うワークフローが欲しかった
■ 14. 辿り着いた先としての仕様駆動開発
- 「AI駆動開発の進め方」として欲しかったもの:
- 開発のための規律
- 理解のための形式
- レビューのためのワークフロー、生成物
- 「破りやすい」型の必要性:
- AI-DLCは重厚長大な「型」なので、導入後のサンクコストやロックインの影響が気になった
- Skillsの寄せ集めの「型なし」では不安があった
■ 15. 仕様駆動開発ツールの選定
- KiroのSpec機能の除外:
- エージェント選定の自由を考慮してスコープから外した
- モデル性能やトークンコストなどの考慮が必要となる
- Spec-Kit vs OpenSpec:
- Spec-Kitの生成するドキュメントは重厚長大になりやすい
- 認知負荷が高すぎると判断し、OpenSpecを選択した
- OpenSpecの良いコマンド:
- /opsx:verifyは仕様と実装の一次チェックを行う
- /opsx:archiveは実装完了後のSpecをarchiveし、メインの仕様ファイルへ同期する
■ 16. 自然言語の「仕様」の限界
- 自然言語を仕様のマスターとする限界:
- 機械的に検査できない自然言語をマスターとして接地させようとする限り仕様駆動は失敗する
- LLMは形式手法とドメインの翻訳機として使うべきである
- 人間側は自然言語で問い合わせるが、自然言語そのものを仕様として使うべきではない
- プロジェクトのSpecファイルを剥がす例:
- 詳細な設計書からコードはいつでも再生成という実験は上手くいかなかった
- 文書の整合性を保つのはコードの整合性を保つより難しい
- 文書が不要なくらい綺麗なコードを書かせ、コードに書けないこと(Why, Why not)を文書に残し、全てをバージョン管理するスタイルに戻した
■ 17. 消費期限は型を破るタイミング
- 仕様駆動開発の既知の課題:
- コーディングからレビューへ移行するボトルネック
- 仕様ファイル群の整合性チェック(ドリフト管理)
- 仕様という言語に拘束され、LLMの性能を発揮できない例
- 最新LLMのベストプラクティスは「プロンプトを減らす」ことである
- 課題に突き当たるまでの有効性:
- 課題に突き当たるまでは仕様駆動開発は理解しやすい
- メンバの作業を適宜見ながら意識合わせするという、チーム仕事の基本にあたる
- 次へ進む判断基準:
- チーム全員が消費期限切れと感じたら、仕様駆動開発の次へ進めばよい