Claude Codeで実践するスペック駆動開発入門 / sdd-with-claude_code

Transcript

1. Claude Codeで実践するスペック駆動開発入門 実践 Claude Code 入門 第4章ほか『スペック駆動開発 (Spec-Driven Development)』 株式会社ジェネラティブエージェンツ Generative Agents, Inc.
2. 第1部 手を動かして学ぶClaude Codeの基本 第1章 Claude Codeをソフトウェアエンジニアリングと統合する 第2章 Claude Codeの基礎 第3章 MCPを使いこなせ！ 第4章 達人に学ぶスペック駆動開発 第5章 Claude Code Actionの活用 第2部 動作原理を理解して開発フローをしくみ化する 第6章 Claude Codeの動作原理を理解する 第7章 Claude Codeを意図通りに動かす 第8章 スペック駆動開発のフローをしくみ化する【設計編】 第9章 スペック駆動開発のフローをしくみ化する【実践編】 付録 各種サービスの設定手順 Anthropic社の概要・コンプライアン ス・法的な規約
3. ٢ాਅޗ +"846(ԣ඿ࢧ෦ 4FSWFSMFTT
   $PNNVOJUZ +1 -BOH$IBJO $PNNVOJUZ +1 FUDʜ コミュニティ ʙ ג
   ηΫγϣϯφΠϯ ʙ ג
   δΣωϥςΟϒΤʔδΣϯπ p "84
   4FSWFSMFTT
   )FSP p -BOH$IBJO ެࣜ &YQFSU
   
   "NCBTTBEPS エキスパート
4. 25人のAIエージェントをスモールビル（Smallville）と呼ばれる仮 想的な町に住まわせることにより、AIエージェント同士でどのよ うな創発が生まれるかを観察したプロジェクト。 住民が自発的に他の住民をパーティーに誘ったり、パーティー当 日のためのカフェの飾り付けを共同で行ったりした観察結果に基 づき、論文ではAIエージェント同士が創発的に協働し合うことの できる可能性が示された。 AIエージェントによる社会シミュレーション Generative Agents
5. ①環境 ④推論（LLM） ②知覚 ③メモリ ⑤行動 入力／実行結果 行動の実行 AIエージェントとは？ 目標に向けて環境と相互作用しながらタスクをこなす知能システムのこと 計画
6. AIエージェントの「手足」となるツール群 ツール群 Bash Glob Grep Read SlashCommand Edit MultiEdit Write NotebookRead NotebookEdit Task TodoWrite WebFetch WebSearch コンテキスト ファイル操作 Jupyter操作 タスク管理 Web検索 どれにしようかな 推論の結果として、環境に働きかける 具体的な操作のことを「行動」と言います。 例えばコーディングエージェントでは、 全ての行動が「ツール」の実行として扱われます。 ★キーポイント AIエージェントとは、知覚した情報をもとに、これらのツールを選択し続ける （次の行動を推論し続ける）システムと言えます。 ※ 掲載しているツール群は代表的なコーディングエージェントである Claude Codeのものを例示しています。
7. AIエージェントをどう駆動するか
8. AIエージェントをどう駆動するか 事前定義済みのワークフローで ルールベースに制御する エージェンティックワークフロー ステアリングファイルを使って ポリシーで制御する 適応型ワークフロー
9. ワークフロー制御のパラダイム プログラミング言語 事前定義型 ワークフロー 適応型 ワークフロー 制御 目的達成への制御・推論 実行環境フレームワーク 事前準備 作業品質の保証・改善 制御文＋関数 × アプリケーション フレームワーク ワークフロー フレームワーク エージェント フレームワーク 関数と処理を100%実装 ワークフローを事前定義 ポリシーを整備 テスト ワークフローをテスト 生成品質を評価 生成品質を評価 ▲ 一部 ◎ 制御文＋LLM判定 ステアリングポリシー （コア＋ルール集）
10. バイブコーディングとスペック駆動開発の違い
11. 「バイブコーディング」という新しい種類のコーディングがあるん です。完全にバイブに身を任せて、指数関数的なものを抱きしめ、 コードがそもそも存在することすら忘れるんです。LLM（例えば Cursor Composer with Sonnet）があまりにも上手くなってきたから こそ可能なことです。あと、SuperWhisperを使ってComposerとた だ話すだけなので、キーボードにほとんど触れません。「サイドバ ーのパディングを半分に減らして」みたいな馬鹿げたことを頼むん ですよ、探すのが面倒だから。私はいつも「すべて受け入れる」を 押して、diffを読むことすらもうしません。エラーメッセージが出た ら、コメントなしでコピペするだけです。通常それで直ります。コ ードは私の通常の理解を超えて成長してしまって、ちゃんと読むに はしばらく時間がかかります。時々LLMがバグを直せないので、回 避するか、ランダムな変更を頼み続けて消えるまでやるんです。使 い捨ての週末プロジェクトにはそれほど悪くないですが、それでも かなり面白いです。私はプロジェクトやウェブアプリを作っていま すが、本当のコーディングじゃないんです。ただものを見て、言っ て、実行して、コピペするだけで、ほとんど上手くいきます。 Verification Debt (検証負債) の蓄積 • AIがコードを生成する速度は、人間が理解・検証する速度をはるかに超える。 • 「動くけど何をしているか分からないコード」「デバッグ不能な状態」 • 使い捨てる • レビューもAIで実施する
12. 第1部 手を動かして学ぶClaude Codeの基本 第1章 Claude Codeをソフトウェアエンジニアリングと統合する 第2章 Claude Codeの基礎 第3章 MCPを使いこなせ！ 第4章 達人に学ぶスペック駆動開発 第5章 Claude Code Actionの活用 第2部 動作原理を理解して開発フローをしくみ化する 第6章 Claude Codeの動作原理を理解する 第7章 Claude Codeを意図通りに動かす 第8章 スペック駆動開発のフローをしくみ化する【設計編】 第9章 スペック駆動開発のフローをしくみ化する【実践編】 付録 各種サービスの設定手順 Anthropic社の概要・コンプライアン ス・法的な規約
13. バイブコーディング • ノリ(Vibe)で作ってみる • 無計画にコード作成をすると、ちゃんと動くアプリケーションができるかもしれないし、できないかもしれない • 想定している機能やエラー処理の考慮もしてくれていない可能性あり • ↓そこで… 1. まず仕様書、設計書をしっかり作って 2. コードを作成し 3. テストを実施する • 通常のソフトウェアエンジニアリングの工程管理を実施する必要性 > タスク管理アプリを作って。React使って、タスクの追加、削除、完了マークができるやつ。 ⏺ React を使ったタスク管理アプリを作成します。 ⏺ Update Todos ⎿ ☐ React アプリの初期セットアップ ☐ タスク管理コンポーネントの作成 ☐ タスクの追加機能の実装 ☐ タスクの削除機能の実装 ☐ タスクの完了マーク機能の実装 ☐ スタイリングの追加
14. !!ιϑτ΢ΣΞΤϯδχΞϦϯά͕͍ͨ͠ 課題感：ノリでは作れるが、セキュアでロバストなソフトウェアを安全に 本番リリース・運用できないかぎり普及しない औΓ૊Έ͔ͨɾ஌ݟ • ن໛ͷখ͍͞ιϑτ΢ΣΞͷʮ13%࡞੒ʯʮઃܭʯʮ࣮૷ʯʮ؀ڥߏ ஙʯʮςετʯʮӡ༻ʯ͔Β͸͡ΊΔ • *%&͸ͲΕΛબΜͰ΋։ൃϥΠϑαΠΫϧࣗମ͸มΘΒͳ͍ • ແྉʹͩ͜ΘΒͳ͍ˠ΍ΕΔ͜ͱ͕Ͱ͖ΔɺΛ༏ઌ
17. 仕様の種類 役割 例 要求仕様 (Requirements Spec) 何を作るか、なぜ作るかを定義 ユーザーストーリー、EARS記法 の要件文 設計書 (Design Doc) アーキテクチャと技術的設計を 記述 コンポーネント図、API仕様、デ ータモデル ユビキタス言語 (Ubiquitous Language) ドメインの用語をチーム内で統 一 用語集、ドメインモデル図 テスト仕様 (Test Spec) 期待する振る舞いを事前に定義 テストケース、受入基準 実行計画書 (Task Plan) 実装の順序と単位を規定 タスクリスト、スプリントバックロ グ 開発を支える「仕様」の構成要素 etc…
18. 『実践 Claude Code 入門』で体験するスペック駆動開発 ポリシーのメモリ化
19. $MBVEF
    $PEFͰεϖοΫۦಈ։ൃ 【スペック駆動開発のやりかた自体もClaude Codeに相談】して、ルールをメモリ(CLAUDE.md)に定義する > まずは開発標準ルールとして、開発を進めるときは必ず以下のドキュメントを参照して開発を進めることとします。 - プロダクト企画書 `product.md` - プロダクトビジョンや目的 - ターゲットユーザーと課題・ニーズ - 主要な機能や目標 - 成功の定義 - 要求仕様書を`requirements.md` - ユーザーストーリー - 受け入れ条件 - 機能設計書 `design.md` - 機能ごとのアーキテクチャ - 構成図 - 技術仕様書 `tech.md` - テクノロジースタックやフレームワーク - 開発ツールや手法 - 技術的な制約事項や要求事項 - 利用するサードパーティ製品 - アプリ構造定義書 `structure.md` - フォルダやファイルの構成 - 命名規則 - コーディング規約 - タスクリスト - 機能やインフラの実装タスク - テストや品質保証タスク 追加開発や修正開発をする際には影響ドキュメントを洗い出して当該ドキュメントを修正してから、新規のタスクリストを作成し、タスクを実行することとし、タ スクリストのファイル名は`tasklist-`+`実施内容を端的に表現した名用`+`作成日時`で作成すること。 また、ドキュメントを編集したときは、1ファイルごとにわたしに必ず確認、承認を得てから次のファイル編集をおこなってください。 これをCLAUDE.mdに整理して定義してください。
20. (整備した開発ルールを使ったスペック駆動開発デ モ)
24. 本書とAI-DLC(ワークフロー)との構成の違い
25. !!"*%SJWFO
    %FWFMPQNFOU
    -JGFDZDMF
    "*%-$ AI-Driven Development Lifecycle (AI-DLC) Method Definition https://prod.d13rzhkk8cj2z0.amplifyapp.com/ aidlc-workflows https://github.com/awslabs/aidlc-workflows
26. AI-DLCワークフローのフェーズ フェーズ 目的 焦点 INCEPTION 計画とアーキテクチャ 何を作るか、なぜ作るか CONSTRUCTION 設計・実装・テスト どうやって作るか OPERATIONS デプロイと運用 (将来拡張用) どう動かすか
27. 本書とAI-DLCワークフローの構成の違い 観点 本書のアプローチ AI-DLCのアプローチ ステアリング CLAUDE.md (制約と文脈) CLAUDE.md + core-workflow.md + ルールブック 仕様の管理 .steering/ に作業バッチ単位で保存 aidlc-docs/ にステージ単位で保存 プロセスの駆動 CLAUDE.mdのプロンプトに依存 ルールブックがステージ順序を規定 状態管理 .steering/ 内のタスクリスト aidlc-state.md (専用ファイル) 監査証跡 タスクリストの完了状態 audit.md (全やり取りをタイムスタンプ 付きで記録)
28. (AI-DLCワークフローを使ったスペック駆動開発デ モ)
29. ステアリングポリシーをCLAUDE.mdに依存する功罪
30. CLAUDE.mdをステアリングにする功罪 1. メモリファイルの肥大化 メモリファイル(CLAUDE.md)は必ず読み込まれる 2. ワークフロー適応性の低下 プロセスルールを詳細に指定しすぎると、柔軟性が下がる
31. 状態管理と監査証跡
32. 状態管理と監査証跡 1. 状態管理 - 本書：.steering/[作業毎のフォルダ]/tasklist.md でタスク進捗のみ記録 - AI-DLC：aidlc-state.md に現在のフェーズ・完了したステージ・保留中のタ スクなどの進捗状態を記録 2. 監査証跡 - 本書：「何をやったか」は残るが、「なぜその判断をしたか」「ユーザーと のやり取りの詳細」が記録として不十分 - AI-DLC：audit.md にすべてのユーザー入力とAI応答をタイムスタンプ付き で原文のまま記録