Expert AX Level 1 Claude編 / 全4回研修第2回

精度を上げる、
精度を上げ続ける

仕様駆動開発とマルチモーダル / 継続改善サイクル

講師: 村田篤郎

受講のヒント

リアクション

✅ わかった／進んで OK

❌ わからない／詳しく説明して

✋（挙手）質問あり

メモ・振り返り

講義・実習中に 気になったこと をメモ

例: 理解できたこと／引っかかった箇所／試したいこと

Part 末で 3 分振り返り
→ Claude Code に要約
→ 共有場所へ投稿

Claude Code + ターミナル 2 つ

① Claude Code (claude 起動)

② 開発サーバ用 (npm run dev など)

③ コマンドを単発で打つ用

横に分割: ターミナル右上の Split ボタン
または ⌘+Shift+P →「Split Terminal」

上下に並べる: タブを上のエディタ枠へドラッグ

💡 リアクションの場所 : Zoom 画面下部の リアクション ボタン (ハート / 顔アイコン) から ✅ / ❌ / 挙手をクリック。下部メニューが見えない場合は Zoom ウィンドウ内をクリックすると表示される（左の画像クリックで拡大）

1分30秒、ここまで2.5分（初回フル版）

「受講のヒントを 3 つ確認します」

「1 つ目、リアクション。✅ わかった、❌ わからない／詳しく説明して、✋ 挙手で質問あり。遠慮なく ❌ を押してください。チャットでも質問 OK です。Zoom 画面下部のリアクションボタンから操作できます」

「2 つ目、Claude Code + ターミナル 2 つで計 3 ペイン。Codespace の VS Code で claude を起動するペイン、開発サーバ用、コマンド単発用、と役割分担で開いておくと、いちいち止めずに済みます。横分割はターミナル右上の Split アイコンをクリックするか、コマンドパレット（⌘+Shift+P）から『Split Terminal』を実行が確実です。⌘+\ は日本語キーボードだと効かない場合があるので注意。上下に並べたいときはターミナルタブを上のエディタ枠にドラッグでも OK」

「3 つ目、メモと振り返り。講義中・実習中に気になったこと、理解できたこと、引っかかった箇所、業務で試したいことを自由にメモしておいてください。Part の最後に 3 分の振り返りタイムを用意するので、そこで Claude Code にメモを要約・まとめてもらって、共有場所に投稿します。書き方は完全自由、Claude への頼み方も自由です。プロンプトの工夫自体が練習になります」

Part 3: 「とりあえず作って」が破綻する理由

01

講義 — 仕様駆動開発とマルチモーダル

02

実習 — マルチモーダルで仕様駆動開発を体験する

03

まとめ

Part 3 のゴール

仕様駆動開発の一連の流れを体験し、
Plan を立ててから実装することの重要性を理解する

1

仕様駆動開発

コードを書く前に
実装計画を確定させる

2

マルチモーダル開発

画像を仕様として
AI に渡す

3

Plan → 実装 → 検証

Playwright MCP で
見た目を自動検証

3分、ここまで6.5分

「Part 3 のゴールです。仕様駆動開発の一連の流れを実際に体験して、Plan を立ててから実装することの重要性を理解してもらうのがゴールです」

「そのために3つのことを体験します。1つ目が仕様駆動開発 — コードを書く前に実装計画を確定させる考え方。2つ目がマルチモーダル開発 — 画像を仕様として AI に渡す方法。3つ目が Plan → 実装 → Playwright MCP で見た目の自動検証。この3つを通じて、なぜ先に計画を立てるべきかを体感してもらいます」

📂 講師実演: VS Code エクスプローラーで apps/InsightLog/docs/training/required-annotation.md を開く。L16-20（ゴール）を読み上げる。バイブコーディング vs 仕様駆動開発の差を Phase 1-3 で体感する設計（cat ではなく必ずエディタで開く）

Part 3 のスコープ

Part 3: 「とりあえず作って」が破綻する理由

01

講義 — 仕様駆動開発とマルチモーダル

02

実習 — マルチモーダルで仕様駆動開発を体験する

03

まとめ

実装計画なしで作り始めると起きる問題

ある程度大きなタスクで設計を飛ばすと起きる典型的な問題

問題1

手戻りの連鎖

「思ってたのと違う」が
実装後に発覚する

問題2

トークンの浪費

試行錯誤のたびに
APIコストが積み上がる

速く作れる = 手戻りとコストが膨らむからこそ、
「何を」「どう作るか」の定義が結果を分ける

2分、ここまで9分

「簡単なタスクならいきなり実装でもいいんです。でも、ある程度複雑な機能や大きなタスクになると、設計を飛ばすと2つの問題が起きます」

「1つ目、手戻りの連鎖。『思ってたのと違う』が実装後に発覚して、やり直しが何度も発生します。2つ目、トークンの浪費。試行錯誤のたびに API コストが積み上がります」

「AI が速く作れるようになったからこそ、"何を、どう作るか" の定義が重要になった。何を作るか — 仕様の定義。どう作るか — タスク分解や依存関係の整理、ステップを踏んだ実装計画。この両方を事前に固めるのが仕様駆動開発です」

【補足トーク】「もう一つ大きな副次効果があって、Plan を作る過程で仕様への理解が深まるんです。タスクを頼まれたときに、いきなりコードを書き始めると "なんとなくの理解" のまま進みますよね。でも Plan を立てさせると、AI に説明するために自分の頭の中が整理される。事前にバグや不具合の種に気づけることもあります。壁打ち相手として AI を使う — これが SDD の隠れた価値です」

📂 講師実演: VS Code エクスプローラーで apps/InsightLog/.claude/skills/planner-team/SKILL.md を開く。L31-45（Phase 2: 計画草案）を読み上げる。PM が plan 草案を起案し、各ロールがレビューする（cat ではなく必ずエディタで開く）

参考 — モデル使い分けでコスト最適化

タスクの重さでモデルを選ぶと、コストは 1/25 まで圧縮できる (MTok = 100 万トークン)

x0.04 倍 (最安)

Haiku 4.5

入力 $1 / 出力 $5 MTok
探索 / 軽量読み取り / 大量処理

x0.2 倍 (デフォルト)

Sonnet 4.6

入力 $3 / 出力 $15 MTok
通常の実装 / レビュー / テスト

x1 倍 (基準)

Opus 4.7

入力 $5 / 出力 $25 MTok
複雑設計 / Plan / 大規模理解

出典: Anthropic Pricing 公式／詳細な使い分け方針: arkatom/claude-plugins — subagent-policy.md

1分30秒、ここまで 10分30秒

「参考までに、モデル使い分けでコストが大きく変わる話を 1 枚だけ」

「Anthropic は 3 段階のモデルを出していて、Haiku が一番安い、Opus が一番高い。Haiku は Opus の 1/25 ぐらいのコストです」

「使い分けの基本 ─ 探索や軽量タスクは Haiku、通常の実装は Sonnet (これがデフォルト)、複雑な設計や大規模なコード理解だけ Opus」

「特に大事なのが Plan = Opus / 実装 = Sonnet パターン。SDD で Plan を立てるフェーズは Opus に任せて、実装フェーズは Sonnet に任せる。これでコスト効率が一番良い」

「詳しい使い分け方針は私 (講師) のカスタムインストラクションに書いてあります。slide 下のリンクから GitHub の subagent-policy.md を見てください。Haiku を使うべき場面、Sonnet を使うべき場面、Opus を 25 倍のコストかけて使うべきかどうかの判断軸が詳しく書いてあります」

【講師ノート】受講者から「Opus と Sonnet どっちを普段使うべきですか?」と質問された場合: 「迷ったら Sonnet です。Opus は 25 倍コストがかかるので、計画フェーズや大規模理解だけに限定して使うのが効率いい」と回答

【補足】FAQ.md にも「Haiku / Sonnet / Opus 使い分け + コスト比較」Q&A あり、受講者向けに案内

SDD（仕様駆動開発）とは

コードを書く前に、AI に実装計画を立てさせて確定する

01

仕様（What）

何を作るかを言語化する
仕様書や Issue など

02

実装計画（How）

技術設計とタスク分解を
AI に立てさせ人間がレビュー

03

実装（Do）

確定した計画に基づき
コードを書く

3分、ここまで12分

「SDD — Specification-Driven Development、仕様駆動開発です。考え方はシンプルで、コードを書く前に AI に実装計画を立てさせて確定する」

「3層構造です。仕様 — 何を作るかを言語化する。Issue でもメモでもいい、とにかく文字にする。後段 (実装計画と実装) の品質はここで決まります。実装計画 — 技術設計とタスク分解を AI に立てさせ、人間がレビュー。実装 — 確定した計画に基づいてコードを書く」

「『何を作るか』が曖昧なまま進めると、実装計画も実装も全部ブレます。コードを書く前に仕様をはっきりさせる — この単純なルールが修正地獄を防ぎます」

【用語: SDD = Specification-Driven Development。コードを書く前に AI に実装計画を立てさせて確定する手法】

📂 講師実演: VS Code エクスプローラーで apps/InsightLog/.claude/skills/planner-team/SKILL.md を開く。L46-58（Phase 3: Devil's Advocate）を読み上げる。Devil ロールが計画の弱点を critical / warning で指摘する（cat ではなく必ずエディタで開く）

SDD は開発の前提になりつつある

仕様駆動開発を前提にしたツールが標準化されている

Kiro（AWS）

Spec-driven IDE

AWS が提供する仕様駆動の AI IDE。
EARS 記法で要件を構造化し、
仕様から実装まで一貫して管理

Spec Kit（GitHub）

オープンソース SDD ツール

GitHub が公開した SDD ツールキット。
PRD を起点に計画を自動生成

Claude Code では Plan モードが計画段階を担う

仕様 (Issue / PRD / 受け入れ条件) は組織側で別途作る

5分、ここまで17分

「SDD は "注目されている" というより、もう開発の前提になりつつあります。仕様駆動を前提にしたツールが次々と標準化されています」

「1つ目、Kiro。AWS が提供する SDD 内蔵の AI IDE です。EARS 記法で要件を構造化し、仕様から実装まで一貫管理します。2025年に発表され、すでに多くのチームが採用しています」

「2つ目、Spec Kit。GitHub がオープンソースで公開した SDD ツールキットです。PRD を起点に計画を自動生成します」

「Kiro / Spec Kit は仕様→計画→実装の3層を1つのツールで管理しますが、Claude Code は専用 SDD ツールではありません。仕様は PM やディレクターが Issue や PRD で作って、それを受け取って計画を立てる段階で Plan モードを使う — ここが Claude Code の SDD 的な使い方の核心です。次のスライドで詳しく見ます」

【用語: EARS 記法 = Easy Approach to Requirements Syntax。When/While/If/Where + shall で要件を構造化する記法。航空宇宙（Rolls-Royce）発祥。例: 「When ユーザーがログインボタンを押したとき、the system shall 認証画面を表示する」のように、トリガー条件+動作を定型文で書く。曖昧さを排除して、テスト可能な要件にするのが目的】

【用語: PRD = Product Requirements Document（製品要件書）。「何を作るか」「誰のために」「なぜ必要か」「受け入れ基準」を自然言語でまとめた文書。Spec Kit ではこの PRD をマークダウンで書き、AI がタスク分解と実装計画を自動生成する。PRD の粒度が荒いと計画も荒くなるので、書き方が品質を左右する】

【用語: Kiro = AWS が2025年に発表した Spec-driven IDE。EARS 記法で要件を書くと、仕様→設計→タスクの3層を自動生成し、実装までトレーサビリティを保つ。無料プランあり。深掘りは不要、名前と概念だけ紹介すれば十分】

【用語: Spec Kit = GitHub が公開したオープンソースの SDD ツールキット。PRD を `.speckit/` ディレクトリに配置し、CLI でタスク分解・実装計画を自動生成する。Claude Code の Plan モードと思想は同じだが、ツールとして独立している点が異なる】

📂 講師実演: VS Code エクスプローラーで apps/InsightLog/.claude/skills/planner-team/SKILL.md を開く。L59-68（Phase 4: 出力）を読み上げる。最終 plan を docs/plan/ に保存し、各 Phase の議事録も残す（cat ではなく必ずエディタで開く）

Plan モード — AI に実装計画を出させて人間がレビュー

Plan モードで
要件を入力

▶

AI が
実装計画を出力

▶

人間が
レビュー・承認

▶

承認後
自動で実装開始

AI の提案を鵜呑みにしない — Plan をレビューして修正指示を出す体験が核心

3分、ここまで20分

「Plan モードの使い方です。まず Plan モードで要件を入力すると、AI が実装計画を出力します。ここで人間がレビューして、問題なければ承認。承認すると自動で実装が始まります」

「大事なのは、AI の提案を鵜呑みにしないこと。Plan をレビューして修正指示を出す体験 — これがこの Part の核心です。この後の実習で実際に体験してもらいます」

「Plan モードへの切り替えは /plan コマンドか Shift+Tab です」

📂 講師実演: VS Code エクスプローラーで apps/InsightLog/.claude/skills/planner-team/SKILL.md を開く。ファイルを再度参照しながら、Plan モード（Claude Code の Shift+Tab 起動）で計画立案だけを進める手順を実演する（cat ではなく必ずエディタで開く）

マルチモーダル開発 — 画像を仕様として扱う

テキストだけでは伝えきれないもの = デザイン

入力

画像を仕様として渡す

デザイン画像を Claude Code に
直接読み込ませる。
Figma MCP でも画像ファイルでも可

検証

Playwright MCP で自動検証

実装後のスクリーンショットを
自動撮影し、見た目が
画像通りか確認

今日の実習: リポジトリ内の見本画像を使う（Figma なしでも同じフローを体験できる）

3分、ここまで23分

「テキストだけでは伝えきれないものがあります。デザインです。マルチモーダル開発では、画像を仕様として AI に渡します」

「入力側 — デザイン画像を Claude Code に直接読み込ませます。Figma MCP 経由でも、画像ファイルでも OK です。検証側 — 実装後に Playwright MCP でスクリーンショットを自動撮影して、見た目が画像通りか確認します」

「今日の実習では Figma の代わりにリポジトリ内の見本画像を使います。Figma がなくても同じワークフローを体験できます。実務では Figma MCP を使うと、デザインデータを直接取得できます」

【用語: マルチモーダル入力 = テキストだけでなく画像などの複数の入力形式を扱えること】

【用語: Figma MCP = Figma 上のデザインを Claude Code が直接読み取れる仕組み】

📂 講師実演: VS Code エクスプローラーで apps/InsightLog/docs/training/required-annotation.md を開く。L70-83（マルチモーダル開発）を読み上げる。Plan モード + 画像 + Issue ファイルの 3 入力を組み合わせる例（cat ではなく必ずエディタで開く）

Part 3: 「とりあえず作って」が破綻する理由

01

講義 — 仕様駆動開発とマルチモーダル

02

実習 — マルチモーダルで仕様駆動開発を体験する

03

まとめ

実習 — バイブコーディング vs SDD を比べる（目安 30 分）

お題 (= プロンプト)

タスク記録フォームの必須フィールドに「※必須」の赤文字を付与してください。サイズはラベルの半分くらいで。

Phase 1 バイブコーディング

お題をそのまま Claude にコピペ
ブラウザで結果を確認

Phase 2 SDD で作り直す

変更を戻す: !git restore .
Plan モード切替 (Shift + Tab)
お題 + Issue + 画像 (docs/plans/) を渡して実装計画立案
実装計画 をレビュー → 承認
VS Code に開いたスクリーンショットで結果を確認

📂 Phase 2 ステップ 3 詳細: 下の 2 ファイルを VS Code エクスプローラーから Shift + ドラッグ で Claude 入力欄に投下 → お題プロンプトを続けて貼る

docs/plans/必須フィールドにバリデーション表示を追加.issue.md
docs/plans/必須デザイン期待値_デザイナーコメントあり.png

30分 (Phase 1 = 約 10 分 / Phase 2 = 約 20 分)、ここまで 53 分

「実習に入ります。同じお題を Phase 1 (バイブコーディング) と Phase 2 (SDD) の 2 通りで作って、結果を比べるのが目的です。1 枚の画面に全手順がまとまっているので、これを参照しながら手を動かしてください」

【お題説明】「お題はこれ。タスク記録フォームの必須フィールドに『※必須』の赤文字を付与する。期待値は右の画像で確認できます」

【Phase 1 ステップ 1-2】「上のお題をそのまま Claude にコピペ。プロンプトは考えなくて OK、雑に投げて大丈夫です。Codespace で npm run dev を起動済の前提なので、ブラウザで開いて、※必須のフォントサイズが全フィールドで同じか確認」

【Phase 1 結果リアクション】「期待通りなら ✅、バラついたら ❌ で反応してください」

【❌ が多い場合】「『ラベルの半分のサイズ』というプロンプトの曖昧さで、フィールドごとに違うサイズになります。この種の隠れた前提を Plan の段階で炙り出すのが SDD の核心」

【Phase 2 ステップ 3-4】「変更を戻す → Plan モード切替 (Shift+Tab で画面下が Plan になるまで)」

【Phase 2 ステップ 5】「docs/plans/ ディレクトリに .issue.md (お題) と .png (期待値画像) が置いてあります。両方を Shift キー押しながらドラッグ&ドロップで Claude の入力欄へ。プロンプトは下のボックスをコピペ」

【Phase 2 ステップ 6】「Plan の中身 = 実装計画を読みます。ここが実習の核心です。Plan の中で ※必須のフォントサイズがどう決められているか、全フィールドで同じ指定になっているか確認。バイブでバラバラになった問題が、この段階で見つかるはず。問題なければ承認」

【Phase 2 ステップ 7】「Plan モードでの実装計画レビュー → 承認後、自動で実装が始まります。完了したら Playwright MCP がブラウザを開いてスクショを screenshots/result.png に保存します。プロンプトで filename を明示指定しているので、PostToolUse hook (.claude/hooks/open-screenshot.sh) が VS Code エディタに自動表示してくれます。受講者は表示されたスクショを見て、画像通りか確認」

【Phase 2 ステップ 8】「Phase 1 と Phase 2 の違い・気づきを InsightLog (insightlog.pages.dev) に記録」

【進行ノート】各 Phase 区切りで「全員終わりましたか？」とスタンプで確認。詰まっている人がいたらブレイクアウトルームへ誘導し、CS チームがフォロー

【進行ノート】ファイル実在確認 (2026-04-17): docs/plans/必須フィールドにバリデーション表示を追加.issue.md (お題)、docs/plans/必須デザイン期待値_デザイナーコメントあり.png (画像)。両方 docs/plans/ 配下に同居

【進行ノート】Plan レビュー時のチェックポイントを口頭でガイド: (1) どのフィールドが必須と判定されているか (2) ※必須のフォントサイズはどう決められているか (3) ラベルなしフィールドの配置方法

【進行ノート】Phase 3 (旧 5 分、結果記録専用 slide) は廃止済。InsightLog 記入はステップ 8 として統合 1 枚に組み込み。slide 12 (旧「全体の流れ」) も廃止し本 slide 1 枚で完結

📂 講師実演: VS Code エクスプローラーで apps/InsightLog/docs/training/required-annotation.md を開く。L51-94 (Phase 1 + Phase 2 全体) を読み上げる。バイブ vs SDD で結果がどれだけ変わるか実体験する設計 (cat ではなく必ずエディタで開く)

Part 3: 「とりあえず作って」が破綻する理由

01

講義 — 仕様駆動開発とマルチモーダル

02

実習 — マルチモーダルで仕様駆動開発を体験する

03

まとめ

Part 3 まとめ — SDD で何が変わるか

01

手戻りが減る

Plan の段階で問題を潰すから
「思ってたのと違う」がなくなる

02

AI が確実に
実装できる

計画が明確なら AI は迷わない
結果が予測可能になる

03

画像で
認識のズレを防ぐ

マルチモーダル入力で
デザインの意図を正確に伝える

Plan を確定させてから実装する — たったこれだけで手戻りとコストが劇的に減る

3分、ここまで56分

「Part 3 のまとめです。覚えてほしいのは3つ」

「1つ目、手戻りが減る。Plan の段階で問題を潰すから、実装後の『思ってたのと違う』がなくなります」

「2つ目、AI が確実に実装できる。計画が明確なら AI は迷いません。結果が予測可能になります」

「3つ目、画像で認識のズレを防ぐ。マルチモーダル入力でデザインの意図を正確に伝えられます」

「Plan を確定させてから実装する。たったこれだけで手戻りとコストが劇的に減ります。SDD の本質はこれです」

📂 講師実演: VS Code エクスプローラーで apps/InsightLog/.claude/settings.json を開く。L39-41（MCP playwright）を読み上げる。Playwright MCP サーバーの設定で E2E 検証が可能になっている（cat ではなく必ずエディタで開く）

3分振り返りタイム（目安 3 分）

これまでの メモ・感想 を Claude Code に要約・まとめ させて記録する。

発見や気づきなどがあれば追記

Part 3

質疑応答

挙手 or チャットで
気軽にどうぞ

（10 分）

Part 3 で扱ったトピック

セクション	内容
講義	SDD（仕様駆動開発） / マルチモーダル開発 / Plan モード
実習	バイブコーディング vs SDD で同じお題を 2 通り作って比較
まとめ	SDD で何が変わるか — 手戻り削減 / 実装精度 / 認識ズレ防止

休憩 ☕ 10 分

後半開始まで席を立って構いません

10:00

Expert AX Level 1 Claude編 / 全4回研修第2回 Part 4

部下を「育てる」
仕組みを作る

Claude Code を育てる PDCA

講師: 村田篤郎

受講のヒント

リアクション

✅ わかった／進んで OK

❌ わからない／詳しく説明して

✋（挙手）質問あり

メモ・振り返り

講義・実習中に 気になったこと をメモ

例: 理解できたこと／引っかかった箇所／試したいこと

Part 末で 3 分振り返り
→ Claude Code に要約
→ 共有場所へ投稿

Claude Code + ターミナル 2 つ

① Claude Code (claude 起動)

② 開発サーバ用 (npm run dev など)

③ コマンドを単発で打つ用

横に分割: ターミナル右上の Split ボタン
または ⌘+Shift+P →「Split Terminal」

上下に並べる: タブを上のエディタ枠へドラッグ

💡 リアクションの場所 : Zoom 画面下部の リアクション ボタン (ハート / 顔アイコン) から ✅ / ❌ / 挙手をクリック。下部メニューが見えない場合は Zoom ウィンドウ内をクリックすると表示される（左の画像クリックで拡大）

Part 4: 部下を「育てる」仕組みを作る

01

講義 — なぜ継続改善が必要か

02

講義 — 継続改善サイクルの設計

03

実習 — 振り返りと改善サイクルを体験

04

講義 — エコシステムの追いかけ方

05

まとめ

Part 4 のゴール

Claude Code を育て続ける仕組みを手に入れ、
改善サイクルを自分で回せるようになる

1

継続改善の必要性

設定は全て
改善し続けるもの

2

改善サイクルの体験

observe → evolve スキルで
改善提案を自動生成・適用

3

エコシステムの把握

公式情報の追いかけ方と
コミュニティリソース

2分、ここまで83.5分

「Part 4 のゴールです。Claude Code を育て続ける仕組みを手に入れて、改善サイクルを自分で回せるようになることが目標です」

「3つのポイント。1つ目、継続改善の必要性 — CLAUDE.md や Skills は全て改善し続けるもの。2つ目、改善サイクルの体験 — observe と evolve で改善提案を自動生成・適用する流れを実習で体験します。3つ目、エコシステムの把握 — 公式情報の追いかけ方とコミュニティリソースを紹介します」

📂 講師実演: VS Code エクスプローラーで apps/InsightLog/.claude/skills/evolve/SKILL.md を開く。L1-110 を読み上げる。低リスク自動適用 / 高リスク人間判断の Hard rule + サイクル健全性チェックの仕組み（cat ではなく必ずエディタで開く）

Part 4 のスコープ

Part 4: 部下を「育てる」仕組みを作る

01

講義 — なぜ継続改善が必要か

02

講義 — 継続改善サイクルの設計

03

実習 — 振り返りと改善サイクルを体験

04

講義 — エコシステムの追いかけ方

05

まとめ

なぜ継続改善が必要か

育てることで使いやすくなり、
自分や自分の組織に 1 番適した形へ
設定とワークフローが最適化されていく

3分、ここまで87分

「なぜ Claude Code を継続改善する必要があるのか。一言で言うと、育てることで自分や自分の組織に1番適した形に最適化されていくからです」

「使うだけでは良くなりません。CLAUDE.md、Skills、Hooks、Permission — これらは全て改善し続けるもので、一度設定したら終わりではない」

「使い込みながら改善を重ねていくと、汎用的な設定が自分の業務スタイル・組織の文脈に合わせて研ぎ澄まされていく。これがまさに『部下を育てる』感覚です」

「具体的にどう育てるか、何を改善するかは、このあと /insights と継続改善サイクルで詳しく扱います」

📂 講師実演: VS Code エクスプローラーで apps/InsightLog/.claude/hooks/observe-check-commit.sh を開く。L1-127 全体を読み上げる。冒頭 1-48 行のコメントが「なぜ PostToolUse か」「なぜ JSON additionalContext か」「なぜ exit 0 固定か」を公式 URL 引用付きで解説している（cat ではなく必ずエディタで開く）

/insights — 出力をどう使うか

セッション履歴を自動分析し、摩擦と改善提案をレポート化。
受け取った後の育て方がメイン

① 読む

摩擦と
改善提案を確認

▶

② 判断

採用するもの／
しないものを選別

▶

③ 反映

CLAUDE.md / Skills /
Hooks に落とす

分析 → 判断 → 反映で設定とワークフローが育つ

※ /insights は Claude Code の 組み込みスラッシュコマンド

5分、ここまで92分

「改善の出発点になるのが /insights コマンドです。セッション履歴を自動で分析して、摩擦と改善提案をレポートとしてまとめてくれます。ここでのメインメッセージは『出力をどう使うか』です」

「3 ステップで使います。① 読む — 摩擦と改善提案を確認する。② 判断 — 全部適用ではなく、自分の業務文脈に合うものを採用するか / しないか選別する。③ 反映 — 採用したものを CLAUDE.md / Skills / Hooks / settings.json に実際に落とし込む」

「分析 → 判断 → 反映のサイクルを回すことで、設定とワークフローが自分や組織に最適化されていきます。これが直前の『育てる』というメッセージの中身です」

「念のため補足、/insights は Claude Code の組み込みスラッシュコマンドです。追加で何かをインストールする必要はありません」

「受講者に /insights を実行してもらいます」

📂 講師実演: VS Code エクスプローラーで apps/InsightLog/.claude/settings.json を開く。L20-22（Permission の Bash claude /observe）を読み上げる。/observe をワンタッチで呼べる設定（cat ではなく必ずエディタで開く）

/insights の出力イメージ

過去約一ヶ月間のセッションを自動分析し、改善アクションまで提案するレポート

レポート全文を別タブで開く →

2分、ここまで94分

「これが /insights の実際の出力です。スライド上では一部しか見えないので、リンクをクリックしてレポート全文を別タブで開いてください。セッション中に使ったツールの統計、摩擦の検出、設定・スキルの改善提案まで、1つのレポートにまとまっています」

「特に注目してほしいのは改善提案のセクション。CLAUDE.md だけでなく、スキルや hooks、settings.json まで含めて改善を提案してくれます」

【講師ノート】時間があればライブで /insights を実行して見せる。スクショとHTMLレポートはバックアップ用

📂 講師実演: VS Code エクスプローラーで apps/InsightLog/docs/memory/heartbeat/ を開く。ディレクトリの improvements.md / rubric-log.md / decisions.md を順に開いて見せる。/observe の蓄積データが何処に出るかを示す（cat ではなく必ずエディタで開く）

Part 4: 部下を「育てる」仕組みを作る

01

講義 — なぜ継続改善が必要か

02

講義 — 継続改善サイクルの設計

03

実習 — 振り返りと改善サイクルを体験

04

講義 — エコシステムの追いかけ方

05

まとめ

継続改善サイクル — Claude Code を育てる仕組み

/observe スキル

セッションを振り返り
品質スコアリング
改善点を自動検出・提案

▶

/evolve スキル

低リスクは自動適用
高リスクは人間が判断
効果を検証

低リスクは自動適用、高リスクはあなたが判断する

この仕組みは OpenClaw（OSS）の継続改善フレームワークの思想を模倣

13分、ここまで107分

「Claude Code を継続的に育てる仕組みが、observe → evolve のサイクルです」

「observe はセッションの振り返り、品質スコアリング、改善点の自動検出・提案をまとめて行います。evolve はその提案を適用する。低リスクな改善（ドキュメントへの追記など）は自動で適用し、高リスクな改善（コードやルールの変更）は人間が判断します」

「この仕組みは OpenClaw というオープンソースの継続改善フレームワークの思想を参考にしています」

「低リスクは自動適用、高リスクはあなたが判断する。この原則を継続改善サイクルの中で徹底します。自動化するのは検出・提案・低リスクの適用まで、重要な判断は人間が下します」

【研修時（手動）の流れ】「この後の実習では手動で体験します。流れはこうです。まず /observe を実行すると、3つのファイルが作られます。docs/memory/reflection/ に振り返りファイル、rubric-log.md に品質スコア、improvements.md に改善提案。次に /evolve を実行すると、improvements.md の提案を1件ずつ確認して、採用なら対象ファイルに変更を適用し decisions.md に記録、却下なら rejected としてログに残します」

【自動化した場合】「実際の運用では、observe はセッション終了時に自動実行されます。settings.json の SessionEnd フックで設定できます。evolve は /loop コマンドで30分おきに定期実行。低リスクな改善は自動適用、高リスクのみ人間に確認を求めます。自動化しても『高リスクな判断は人間がやる』という原則は変わりません。自動化の設定方法は別途用意してある計画ファイルに記載されています」

【OpenClaw とは（質問されたら回答）】OpenClaw はオープンソースのパーソナル AI アシスタントフレームワーク（GitHub: https://github.com/openclaw/openclaw 、★35万超）。Windows / macOS / Linux などあらゆる OS で動作し、Slack や Discord などのチャットプラットフォームと接続してアシスタントとして動かせる。スキルを追加して機能を拡張でき、継続改善の仕組みとして self-improving-agent スキル（https://github.com/peterskoett/self-improving-agent）があり、エラーや修正を .learnings/ ディレクトリに自動記録し、次のセッションで改善情報を注入する。この「セッション間で学習を引き継ぐ」思想を observe/evolve スキルに取り入れた

📂 講師実演: VS Code エクスプローラーで apps/InsightLog/.claude/skills/evolve/SKILL.md を開く。L20-103（Phase 1-5）を読み上げる。スキャン → 分類 → 適用 → 検証 → 健全性の 5 フェーズが evolve の本体（cat ではなく必ずエディタで開く）

Part 4: 部下を「育てる」仕組みを作る

01

講義 — なぜ継続改善が必要か

02

講義 — 継続改善サイクルの設計

03

実習 — 振り返りと改善サイクルを体験

04

講義 — エコシステムの追いかけ方

05

まとめ

実習 — 振り返りと改善サイクルを体験（目安 20 分）

デモ用の振り返りデータと改善提案が事前に配置されています

/observe 実行

振り返りデータを分析
品質採点 + 改善提案を生成

▶

提案を確認

3件の改善提案
採用すべきか判断

▶

/evolve 実行

採否を決定
設定に反映

📄 手元で手順を開く: /training observe-evolve

2分、ここまで109分

「ここからは改善サイクルを実際に体験してもらいます。今回は、事前にデモ用の振り返りデータと改善提案を配置してあります。実際の運用では、セッション終了時に自動で生成されるものです」

「3ステップです。まず /observe を実行して振り返りデータを分析。次に3件の改善提案を確認して採用すべきか判断。最後に /evolve を実行して採否を決定し、設定に反映します」

📂 講師実演: VS Code エクスプローラーで apps/InsightLog/docs/training/observe-evolve.md を開く。L27-71（Step 1-3）を読み上げる。/observe → 提案確認 → /evolve の流れを実演（cat ではなく必ずエディタで開く）

実習 — 手順（目安 20 分）

/observe を実行 → デモ用の振り返りデータを分析し、改善提案を生成
improvements.md に 3件の proposed を確認
/evolve を実行 → 各提案の 採用・却下を判断
変更内容の差分を確認 → InsightLog に記録

3件の提案

① CLAUDE.md にコンポーネント配置ルール追記 / ② npm run dev 自動実行フック追加 / ③ ユーザー制約ヒアリング強化

判断のポイント: リスクに見合う効果があるか？ / 過剰な自動化になっていないか？

18分、ここまで127分

「手順です。まず /observe を実行してください。事前に配置したデモ用の振り返りデータを分析して、改善提案を生成します」

「improvements.md に3件の改善提案が溜まっているはずです。1件目はCLAUDE.mdへの配置ルール追記 — これは低リスクで効果が高い。2件目はEdit/Write後にnpm run devを自動実行するフック — これは毎回再起動が走るので過剰かもしれない。3件目はヒアリング不足の改善 — 判断が分かれるところです」

「次に /evolve を実行すると、各提案について採用・却下を聞かれます。全部採用する必要はありません。リスクに見合う効果があるかどうか、あなたが判断してください。AI の提案を鵜呑みにせず、最終判断はあなたが握ります」

【進行ノート】実習は18分。受講者が迷ったら「2件目のフック追加は過剰だから却下、という判断も正解です」とヒントを出す

【進行ノート】振り返りデータはデモ用であることを実習前に必ず説明する。「実際の運用では、セッション終了時に /observe が自動実行されて振り返りが生成されます。今回はデモ用データで体験してもらいます」

📂 講師実演: VS Code エクスプローラーで apps/InsightLog/docs/training/observe-evolve.md を開く。L44-70（3 件の判断ポイント）を読み上げる。低リスク自動適用 / 高リスク人間判定の判断基準を実例で示す（cat ではなく必ずエディタで開く）

Part 4: 部下を「育てる」仕組みを作る

01

講義 — なぜ継続改善が必要か

02

講義 — 継続改善サイクルの設計

03

実習 — 振り返りと改善サイクルを体験

04

講義 — エコシステムの追いかけ方

05

まとめ

Claude Code エコシステムの追いかけ方

最重要公式

常時チェック ✅

Claude Code Docs

機能 + 仕様の公式 docs

Changelog

リリースノート（週次）

@AnthropicAI

公式 X / 中の人 follow を辿る

日本語コミュニティ

事例 + 解説記事

Qiita

タグ claudecode の記事一覧

Zenn

Topic claudecode の記事一覧

note

エッセイ・導入記が多め

skill / plugin 配布元

1 つ試してみる

Plugin Marketplace

公式 install ルート

skills.sh

Vercel 運営 / SKILL.md オープン標準

aitmpl.com

skill / template 事例集

⚠️ コミュニティは身構える　ファクトチェック／情報商材注意／ skill・plugin はインストール前にセキュリティ監査

8 分、ここまで 146 分

「Claude Code のエコシステムを継続キャッチアップする情報源を 3 階層でまとめます。下に行くほど信頼性の取り扱いは慎重に」

「1 階層目、公式。これが一番大事です。Claude Code Docs、GitHub の Changelog、それと公式 X の @AnthropicAI から中の人 (Anthropic engineer 個人 X) を follow するのが一次情報源。ここは常時チェックの習慣を付けてください — Claude Code は週単位で機能追加されるので、月 1 では追いつかない」

「2 階層目、日本語コミュニティ。Qiita、Zenn、note にそれぞれ Claude Code 関連の記事が集中しています。事例や解説が早く、実務での使い方が見えやすい」

「3 階層目、skill / plugin の配布マーケット。Anthropic 公式の Plugin Marketplace が install の正規ルート、Vercel の skills.sh は SKILL.md オープン標準採用で Codex / ChatGPT 等でも使える skill が並ぶ、aitmpl.com はテンプレート集です」

「ただしコミュニティ情報は必ず身構えてください。3 つの注意点 — ① 数字や技術仕様はファクトチェック（公式 docs と突き合わせる）、② 情報商材（有料の即解決系）には騙されない、③ skill / plugin をインストールする前は『リポジトリのスター数 / 最終更新日 / Issue 数』を確認、可能なら 1 プロンプトで Claude に 6 観点監査させる（次回 Part 5 で詳しくやります）」

「大事なメッセージ。全部追いかけるのは無理。でも "知らない" と "知ってるけど使わない" は全然違います。気になるものを 1 つ試すことから始めてください」

【補足: 旧スライドに載せていた OpenClaw について】OpenClaw は OSS の AI アシスタントフレームワーク（GitHub: openclaw/openclaw）。コミュニティではなくプロダクト名。observe / evolve スキルの設計思想元ネタとして deck 02 別スライドで紹介済み。本スライドの「コミュニティ」枠からは除外

Part 4: 部下を「育てる」仕組みを作る

01

講義 — なぜ継続改善が必要か

02

講義 — 継続改善サイクルの設計

03

実習 — 振り返りと改善サイクルを体験

04

講義 — エコシステムの追いかけ方

05

まとめ

Part 4 まとめ — Claude Code を育てる

01

観察する

/insights で
ワークフローの現状を可視化

02

改善を
回し続ける

observe → evolve の
サイクルで
Claude Code を育て続ける

03

人間が
判断を握る

自動化する範囲と
判断を残す範囲を切り分ける

観察 → 改善 → 判断のサイクルで — Claude Code は使うほど賢くなる

5分、ここまで140分

「Part 4 のまとめです。覚えてほしいのは3つ」

「1つ目、観察する。/insights でワークフローの現状を可視化します」

「2つ目、改善を回し続ける。observe と evolve のサイクルで Claude Code を育て続けます」

「3つ目、人間が判断を握る。自動化する範囲と、判断を残す範囲を切り分ける。最終判断はあなたが下します」

「観察、改善、判断のサイクルで Claude Code は使うほど賢くなります。これが継続改善の本質です」

📂 講師実演: VS Code エクスプローラーで apps/InsightLog/.claude/skills/evolve/SKILL.md を開く。L1-110 全体を再度スクロールしながら、観察 / 改善 / 人間判断の 3 本柱を総合的に振り返る（cat ではなく必ずエディタで開く）

3分振り返りタイム（目安 3 分）

これまでの メモ・感想 を Claude Code に要約・まとめ させて記録する。

発見や気づきなどがあれば追記

Part 4

質疑応答

挙手 or チャットで
気軽にどうぞ

（10 分）

Part 4 で扱ったトピック

セクション	内容
講義	なぜ継続改善が必要か
講義	継続改善サイクルの設計（observe / evolve）
実習	/observe と /evolve を実行して振り返り → 改善を体験
講義	エコシステムの追いかけ方

精度を上げる、精度を上げ続ける

受講のヒント

リアクション

メモ・振り返り

Claude Code + ターミナル 2 つ

Part 3: 「とりあえず作って」が破綻する理由

講義 — 仕様駆動開発とマルチモーダル

実習 — マルチモーダルで仕様駆動開発を体験する

まとめ

Part 3 の ゴール

仕様駆動開発

マルチモーダル開発

Plan → 実装 → 検証

Part 3 のスコープ

Part 3: 「とりあえず作って」が破綻する理由

講義 — 仕様駆動開発とマルチモーダル

実習 — マルチモーダルで仕様駆動開発を体験する

まとめ

実装計画なしで作り始めると 起きる問題

手戻りの連鎖

トークンの浪費

参考 — モデル使い分けで コスト最適化

Haiku 4.5

Sonnet 4.6

Opus 4.7

SDD（仕様駆動開発）とは

仕様（What）

実装計画（How）

実装（Do）

SDD は 開発の前提 になりつつある

Spec-driven IDE

オープンソース SDD ツール

Plan モード — AI に 実装計画 を出させて 人間がレビュー

Plan モードで要件を入力

AI が実装計画を出力

人間がレビュー・承認

承認後自動で実装開始

マルチモーダル開発 — 画像を仕様として扱う

画像を仕様として渡す

Playwright MCP で自動検証

Part 3: 「とりあえず作って」が破綻する理由

講義 — 仕様駆動開発とマルチモーダル

実習 — マルチモーダルで仕様駆動開発を体験する

まとめ

実習 — バイブコーディング vs SDD を比べる （目安 30 分）

Phase 1 バイブコーディング

Phase 2 SDD で作り直す

Part 3: 「とりあえず作って」が破綻する理由

講義 — 仕様駆動開発とマルチモーダル

実習 — マルチモーダルで仕様駆動開発を体験する

まとめ

Part 3 まとめ — SDD で何が変わるか

手戻りが減る

AI が確実に実装できる

画像で認識のズレを防ぐ

3分振り返りタイム （目安 3 分）

質疑応答

Part 3 で扱ったトピック

休憩 ☕ 10 分

部下を「育てる」仕組みを作る

受講のヒント

リアクション

メモ・振り返り

Claude Code + ターミナル 2 つ

Part 4: 部下を「育てる」仕組みを作る

講義 — なぜ継続改善が必要か

講義 — 継続改善サイクルの設計

実習 — 振り返りと改善サイクルを体験

講義 — エコシステムの追いかけ方

まとめ

Part 4 の ゴール

継続改善の必要性

改善サイクルの体験

エコシステムの把握

Part 4 のスコープ

Part 4: 部下を「育てる」仕組みを作る

講義 — なぜ継続改善が必要か

講義 — 継続改善サイクルの設計

実習 — 振り返りと改善サイクルを体験

講義 — エコシステムの追いかけ方

精度を上げる、
精度を上げ続ける

Part 3 のゴール

実装計画なしで作り始めると起きる問題

参考 — モデル使い分けでコスト最適化

SDD は開発の前提になりつつある

Plan モード — AI に実装計画を出させて人間がレビュー

Plan モードで
要件を入力

AI が
実装計画を出力

人間が
レビュー・承認

承認後
自動で実装開始

実習 — バイブコーディング vs SDD を比べる（目安 30 分）

AI が確実に
実装できる

画像で
認識のズレを防ぐ

3分振り返りタイム（目安 3 分）

部下を「育てる」
仕組みを作る

Part 4 のゴール

なぜ継続改善が必要か

継続改善サイクル — Claude Code を育てる仕組み

実習 — 振り返りと改善サイクルを体験（目安 20 分）

実習 — 手順（目安 20 分）

Claude Code エコシステムの追いかけ方

改善を
回し続ける

人間が
判断を握る

3分振り返りタイム（目安 3 分）