Part 3 の ゴール
仕様駆動開発の一連の流れを体験し、
Plan を立ててから実装することの重要性を理解する
1
仕様駆動開発
コードを書く前に
実装計画を確定させる
2
マルチモーダル開発
画像を仕様として
AI に渡す
3
Plan → 実装 → 検証
Playwright MCP で
見た目を自動検証
複雑な機能を 設計なしで作り始めると
ある程度大きなタスクで設計を飛ばすと起きる典型的な問題
問題1
手戻りの連鎖
「思ってたのと違う」が
実装後に発覚する
問題2
トークンの浪費
試行錯誤のたびに
APIコストが積み上がる
問題3
品質のばらつき
毎回違うアプローチで
一貫性がなくなる
AI が速く作れるようになったからこそ、
「何を」「どう作るか」の定義 が重要になった
SDD（仕様駆動開発）とは
コードを書く前に、AI に実装計画を立てさせて確定する
02
計画（How）
技術設計とタスク分解を
AI に立てさせ人間がレビュー
最初のステップほど重要
「何を作るか」が曖昧だと計画も実装も全部ブレる
SDD は 開発の前提 になりつつある
仕様駆動開発を前提にしたツールが標準化されている
Kiro（AWS）
Spec-driven IDE
AWS が提供する仕様駆動の AI IDE。
EARS 記法で要件を構造化し、
仕様から実装まで一貫して管理
Spec Kit（GitHub）
オープンソース SDD ツール
GitHub が公開した SDD ツールキット。
PRD を起点に計画を自動生成
Claude Code では Plan モード がこの役割を担う
Plan モード — AI に 計画を出させて 人間がレビュー
AI の提案を鵜呑みにしない — Plan をレビューして修正指示を出す体験が核心
マルチモーダル開発 — 画像を仕様として扱う
テキストだけでは伝えきれないもの = デザイン
入力
画像を仕様として渡す
デザイン画像を Claude Code に
直接読み込ませる。
Figma MCP でも画像ファイルでも可
検証
Playwright MCP で自動検証
実装後のスクリーンショットを
自動撮影し、見た目が
画像通りか確認
今日の実習: リポジトリ内の見本画像を使う（Figma なしでも同じフローを体験できる）
実習③ — 必須フィールドの 注釈表示
（バイブコーディングから）
まずはプロンプト一発で挑戦。その後、SDD で再実装して比較する
お題
タスク記録フォームの必須フィールドに「※必須」の赤文字を付与してください
Step 1: バイブコーディング
このお題を そのままコピペ して実行してください
📄 手元で手順を開く: /training required-annotation
実習③ — 必須フィールドの 注釈表示
（SDD）
- Step 2: git checkout -- . でバイブコーディングの変更を全て取り消す
- Step 3: /plan で Plan モードに切り替え
- Step 4: デザイン画像を Shift+ドラッグ&ドロップ で渡し、プロンプトを入力
この Issue と画像の通りに必須フィールドの注釈表示を実装してください。実装後、Playwright MCP でスクリーンショットを撮って外観を確認してください。
- Step 5: Plan をレビュー → 承認 → 実装 + Playwright 検証
- Step 6: npm run dev でブラウザ確認 → InsightLog に記録
InsightLog 記録: Plan でバイブコーディング時の問題に気づけたか？ / 結果は画像通りだったか？
Part 3 まとめ — SDD で何が変わるか
01
手戻りが減る
Plan の段階で問題を潰すから
「思ってたのと違う」がなくなる
02
AI が確実に
実装できる
計画が明確なら AI は迷わない
結果が予測可能になる
03
画像で
認識のズレを防ぐ
マルチモーダル入力で
デザインの意図を正確に伝える
Plan を確定させてから実装する — たったこれだけで手戻りとコストが劇的に減る
Part 4 の ゴール
Claude Code を 育て続ける仕組み を手に入れ、
改善サイクルを自分で回せるようになる
2
改善サイクルの体験
observe → evolve スキルで
改善提案を自動生成・適用
3
エコシステムの把握
公式情報の追いかけ方と
コミュニティリソース
なぜ 継続改善 が必要か
Claude Code は使うだけでは良くならない。「育てる」必要がある
改善対象
設定は全て改善し続けるもの
- CLAUDE.md
- Skills
- Hooks
- Permission
気づき
今日設定した環境にも
改善ポイントがある
今日の実習で気になった点は
すでに改善候補
/insights — ワークフロー監査
セッション履歴を自動分析し、改善アクションまで提案する
分析
摩擦（フリクション）の検出
セッション中に詰まった箇所を
具体例つきで指摘
提案
設定・スキルの改善提案
CLAUDE.md・スキル・hooks・
settings.json の改善をルールとして提案
/insights の出力イメージ
セッション中の作業を自動分析し、改善アクションまで提案するレポート
レポート全文を別タブで開く →
継続改善サイクル — Claude Code を 育てる仕組み
/observe スキル
セッションを振り返り
品質スコアリング
改善点を自動検出・提案
▶
/evolve スキル
低リスクは自動適用
高リスクは人間が判断
効果を検証
この仕組みは OpenClaw（OSS）の継続改善フレームワークの思想を模倣
何を 自動化 し、何に 人間の判断 を残すか
| フェーズ | 自動 | 人間 |
|---|
| observe | 振り返り・品質採点・改善点の検出と提案 | 振り返り内容と提案の妥当性チェック |
| evolve（低リスク） | ドキュメント追記等を自動適用 | 適用結果の確認 |
| evolve（高リスク） | diff の自動生成 | 採否の最終判断 |
低リスクは 自動適用、高リスクは あなた が判断する
Claude Code エコシステムの 追いかけ方
最重要
公式を押さえる
- Claude Code Docs
- Anthropic Blog
- Changelog
月1で見る習慣だけは付ける
コミュニティ
気になるものを1つ試す
- skills.sh — Skills ディレクトリ
- OpenClaw — 継続改善フレームワーク
- aitmpl.com — テンプレート集
全部追う必要はない。「知らない」と「知ってるけど使わない」は全然違う
第2回まとめ
Part 3
仕様駆動開発と
マルチモーダル
AI に実装計画を立てさせてから実装する。
画像を仕様として渡し、
Plan → 実装 → 検証を一気通貫
Part 4
継続改善の
仕組みづくり
observe → evolve で
Claude Code を育て続ける。
最終判断はあなたが下す
