SDD （仕様書駆動開発）を やってみて

AIを使った「行き当たりばったり」開発の落とし穴——仕様の見落としや1500行超の「魔物」コードを経験した上で辿り着いた、SDD（仕様書駆動開発）の実践レポートです。
実装前にAIと共に仕様書を定義し、要件定義・設計・タスク分割・レビューまでをカスタムコマンドで型化するフローを業務・個人開発の両方で試した結果、「思考の整理」「タスク分割の自動化」「考慮漏れの防止」という恩恵がある一方で、確認コストの増大や柔軟性とのジレンマにも正直に向き合っています。
結論は「厳格にやりすぎず、仕様書を手段として割り切る」こと。AI開発の理想と現実を等身大でまとめたLTです。

Transcript

1. AI Development Insights SDD （仕様書駆動開発）を やってみて AI開発の理想と現実 2026.01.29 | 開発定例LT
2. 自己紹介 Photo / Icon 坂本 知聡（Sakamoto Chisato） メディアディベロップメント A1チーム所属 現在の主業務: ITトレンドのリプレイス開発 経歴: 小学校教員→インフラ→フルスタック 趣味: ゲーム🎮、ダンス🕺、TRPG、マーダーミステリー 今年の目標: 小説を読んで語彙力を手に入れること
3. AI開発の「行き当たりばったり」が招く悲劇 リプレイス開発の罠 既存システムの仕様を人間で確認し実装した結果、裏側 の処理の画面には見えない部分等、細かいところでの仕 様の見落としが頻発。 「動いてはいるが、実は要件を満たしていない」状態に気 づくのが遅れ、修正に膨大な時間を費やすことに。 AIが生んだ「魔物」 プロンプトだけで機能を詰め込み続けた結果、1500行を超える 巨大なファイルが誕生。 AI自身も全体像を把握できなくなり、一箇所の修正が予期せ ぬバグを誘発する保守不能なコードへ。
4. SDD（仕様書駆動開発）とは何か？ 実装コードを書く前に、 AIと共に詳細な「仕様書」を定義する開発手法。 AIが「何をすべきか」 を明確に理解した状態で開発をスタートさせます。
5. 業務への導入：カスタムコマンドによるフロー確立 フローの自動化と標準化 SDDのプロセスを迷わず実行できるよう、独自のカスタムコマンドを作成。 誰が担当しても一定の品質で仕様書が作成される環境を構築しました。 チームへの展開 リプレイス開発メンバーが活用できるフローとして確立。AIとの対話方法を 型化することで、導入のハードルを大幅に下げました。 属人化の解消 「AIへの指示の出し方」という暗黙知をコマンド化。チーム全体での開発品 質の底上げと、効率的なナレッジ共有を推進しています。 図：標準化された開発ワークフローのイメージ
6. 個人開発への導入： cc-sddで挑む新規開発 開発プロダクト ・ダンスの立ち位置作成アプリ（開発途中） ・TRPGのGM援助Bot（育成途中） 導入の背景 業務で確立した SDDのフローが非常に効果的だったため、個人開 発のスピードアップと品質向上のために cc-sddを逆輸入。 期待する効果 一人での開発はどうしても「行き当たりばったり」になりがち。仕様 書を介することで、冷静な設計と確実なタスク遂行を目指す。
7. cc-sddの実践 1：導入とプロジェクト定義 1. インストールと初期化 $ npx cc-sdd@latest --codex --lang ja プロジェクトへ cc-sddを導入。実行後、プロジェクトの「脳」となる .kiro ディレ クトリが作成されます。 2. プロジェクトの基本方針策定 /prompts:kiro-steering プロダクトの目的、主要機能、技術スタック、設計方針、命名規則などを定 義。AIが開発の「羅針盤」を持つ工程です。
8. cc-sddの実践 2：要件定義と承認フロー 3. 実装機能の要件定義開始 /prompts:kiro-spec-init 特定の機能開発に向けた仕様策定をスタート。 AIが現在のプロジェクト状 況を把握し、対話の準備を整えます。 4. 要件の内容記載と承認 /prompts:kiro-spec-requirements 具体的な要件を記載。 AIがそれを構造化し、人間が内容を確認・承認する ことで次の工程へ進みます。
9. cc-sddの実践 3：設計とタスク分割の自動化 5. 設計書の作成 /prompts:kiro-spec-design {id} -y 要件を承認し、具体的な設計書の作成に取り掛かります。プロジェクト構成 や命名規則に基づいた詳細な設計が生成されます。 6. タスク分割の実行 /prompts:kiro-spec-tasks {id} -y 設計を承認し、実装可能な最小単位のタスクへ分割。 AIが「一度に確実に 実装できるサイズ」にタスクを切り出します。
10. cc-sddの実践 4：実装の実行とレビューフロー 7. タスクごとの実装実行 /prompts:kiro-spec-impl {id} {task_no} -y 分割されたタスクを一つずつ実行。 AIが仕様と設計に基づき、実際のコード を生成・配置します。 8. バリデーションとレビュー /prompts:kiro-validate:* 実装されたコードが仕様を満たしているか、設計方針に沿っているかを AI がセルフレビュー。品質の最終確認を行います。
11. 直面した壁：仕様書駆動の「しんどさ」 確認コストの増大 AIが生成した詳細な仕様書を隅々まで確認するのは非常に時間がかかる。その 上、結局コードの確認は必要。この確認作業自体が新たなボトルネックに。 「やってみないとわからない」の壁 詳細な仕様まで書ききれないため、実装後に細かい修正点に気づくことが多い。し かし、SDDの原則では「仕様書を直してから実装」が必要。 修正のオーバーヘッド 細かな修正のために仕様書をメンテナンスし直すのは手間。その場で指示して直 す方が圧倒的に早いという現実。 厳格な仕様書管理 ↓ VS ↓ 開発スピード・柔軟性 ※ 理想を追い求めすぎると、かえって開発効率を損なうジレンマに陥 る。
12. 結論：目的を明確にした「ほどよい」 SDD SDDを取り入れる真のメリット 思考の整理 行き当たりばったりを防ぎ、やるべきことを構造的 に整理できる。 タスク分割の自動化 少ないキーワードから、AIが実装可能な粒度まで 分解してくれる。 考慮漏れの防止 自分では気づかなかったエッジケースや非機能要 件をAIが洗い出す。 持続可能な運用のための提案 「何が目的か」を明確にし、 仕様書を「手段」として柔軟に活用する 厳格にやりすぎず、細かな修正はその場で指示。整理の道具として割り切ることで導入のハードルを下げる。
13. まとめ：AI時代の開発スタイルを模索し続ける 整理の重要性 行き当たりばったりの指示よりも、仕 様書としてまとまることで「やるべきこ と」が整理されるメリットは非常に大き い。 柔軟性の維持 厳格すぎる仕様書駆動は、 AI開発の スピード感や柔軟性を損なう可能性が ある。細かな修正はその場で行う等の 柔軟さはあっても良い。 最適な距離感 目的を明確にし、自分のプロジェクト やチームに合った「ほどよい」 SDDの取 り入れ方を見つけることが成功の鍵。 AIを使いこなし、理想のバランスを追求する