AI駆動開発 実践ガイド

アジャイル/スクラムの規律を、AIとの協働に適用する。

Claude Code / Agent Skills を活用したAI駆動開発（AIDD: AI-Driven Development）の方法論と実践知を体系化した実践ガイド。ツールの使い方集ではなく、進め方（プロセス）の規律を主題とする。

公開記事: clone しただけのマシンで、AI が「推測で埋めること」を自分から拒否した（Zenn・2026-07-23公開）— このガイドの入口にあたる紹介記事。
⚠️ 記事は v1.2.0 時点のこのリポジトリを題材にした記録であり、本ガイドの現在の説明ではない。 本文は以後も更新されるため、記事の記述と食い違うことがある——記事側もタグで時点を固定して書いてあるので、どちらの時点の話かは双方から辿れる。

関連記事: さくらのAI Engine を Claude Code に差して61分 — 「互換」の境界は3箇所で出た（Qiita・2026-08-25公開）— このガイドで回している作業に別のモデルを差し込み、セッションのログから機械的に集計した検証の記録。⚠️ プレビュー版のモデルで1回測ったもので、時期が変われば結果は変わる。

短時間で中身を確かめたい方へ

全部を読む前に、このガイドが何を大事にしているかを判断できる3点。

⚠️ どれも節を指しています。 docs/design-decisions.md と BACKLOG.md は全文が長いので、ここから入るなら節だけを読んでください。

1. docs/design-decisions.md の「4. 誤りの訂正記録（規律が実際に機能した例）」 — 自分の誤りを訂正した記録（裏取り済みの記述でも読み違えれば誤る、引用を自己の実証として提示していた、など）。方法論の文書が生成物と区別されるのは、こうした記録が残っているかどうかによる
2. BACKLOG.md の「C. 章ごとの裏取り状況を揃える」 — どの章がどこまで裏取り済みかの表。 実証済みと未検証の混在を隠さないことが、本ガイド自身への確度ラベルの適用にあたる
3. 01 セクション2 — 確度ラベルとクロスレビュー。「もっともらしい散文」を反証可能な状態に落とすための中核

背景・設計思想

このガイドは、AIツールの使い方集ではなく、アジャイル/スクラムの実践知を土台に、AIネイティブ開発を規律づける試みである。ここでの規律の柱は、仕様駆動開発（SDD: Spec-Driven Development、何を作るかを先に仕様として固める進め方）とテスト駆動開発（TDD: Test-Driven Development、先にテストを書いてから実装する進め方）の2つである。

著者は、経験豊富なアジャイルコーチや、「真のアジャイル」を志向して集まった認定スクラムマスター／プロダクトオーナーとのチームでの実践を通じて、メタ認知とクリティカルシンキングを鍛えられた。良いスクラムも不完全なスクラムも経験し、フルスタックエンジニアとしてチームをボトムアップで正しいスクラムへ導く役割（スクラムマスター兼開発者）も担ってきた。

この土台が、本ガイドの一貫した思想になっている。

• 人間が裁定者：AIの提案を鵜呑みにしない。スクラムの「検査と適応」を、人間の判断責任として貫く（01 セクション2）
• 曖昧さを検査可能にする：確度ラベル（[Fact] / [Judgment] 等）と受入基準（AC: Acceptance Criteria）で、「もっともらしい散文」を反証可能な状態へ落とす（01 §2 ／ 06 §5）
• 人も AI も必ず間違える前提で組む：TDD・lint・静的型は、人間が必ず間違えることを前提に組まれている。AI 駆動開発はそれを AI に掛けるが、間違える前提は人間の側にも残っている。本ガイドの規約は、AI と、それを使う人間（著者自身を含む）の両方に掛ける——どちらかを「間違えない側」に置くと、その側の誤りは検査されないまま外に出る。規律は、慣れれば外せる補助輪ではない。間違えれば取り返しがつかない領域ほど、熟練者は手順と確認を省かない。著者はこれを、外すことを前提にしない「矯正ギブス」と呼んでいる（01 前提思想・§3.7）
• WHAT と HOW の分離：作るもの（What）と作り方（How）を分ける。テクニカル PdM（プロダクトマネージャー。技術的判断まで踏み込む立場）として、要件・仕様（何を作るか）の壁打ちまでを提供範囲に収めた WHAT レイヤー（06）を持つ

そのため本ガイドは、フルスタック向けの AIネイティブ／SDD／TDD の HOW（01〜05）に加え、PdM 視点の WHAT（06）を別レイヤーとして備える。WHAT レイヤー（06）は、要件・仕様が曖昧なまま開発が進み全体像が見えなくなる実プロジェクトの経験から生まれた——「何を作るか」を検査可能な形で固める必要を痛感したことが、この章の起点である。

二層の読者 — 人間と、AIツール自体

このガイドは二層の読者を想定している。

1. 生成AIを学んで使う人間 — AIとの協働を規律づけたい開発者・PdM。
2. .md を読み込んで動く生成AIツール自体（Claude Code 等）。.md は"読む対象"であると同時に、**"ロードして走らせる対象"**でもある。

Claude Code では CLAUDE.md が毎セッション制御planeとして読み込まれ、.claude/skills/ 配下の Skill は description の意味照合で発火する（⚠️ ただし、手元の設定（skillOverrides）や一覧の予算によって、説明文が AI に届かない、または Skill が一覧から消えることがある。著者の環境では一時そうなっており、その間も review-before-* が呼ばれていたのは、CLAUDE.md の規約が名前で指しているからだと見ている [Judgment]——BACKLOG.md 項目 BF。何が入っているかは .claude/skills/ を直接見てください——ここに名前を列挙すると、増減のたびに腐ります）。⚠️ 自動ロードの挙動はツールごとに違う。 本ガイドが裏取りしているのは Claude Code の挙動である。AI読者を想定するなら「読める」より「発火する（走る）」ほうが証拠として強い——これが本ガイドの活性化（方法論を Skill として実装すること）を駆動する立脚点である（docs/design-decisions.md §6）。

ただし二層であって、AIが主目的という意味ではない。人間の判断（裁定・メタ認知）が常に上位にあり、AIツールはそれを高速に発火・検査する側にある。どの .md がどこまで実際に発火しているか（＝書いた量と活性化した量は一致しない）は BACKLOG.md の「知見の活性化」を参照。

このREADMEの役割

• README.md（本ファイル） = 初回導線・全体概略。初めて読む人はここから始める
• CLAUDE.md = 制御plane（現在モード・ファイルマップ・編集規約・再開手順・チーム共通ルール）。Claude Code が常時ロードする
• docs/design-decisions.md = 設計判断とその理由の記録 ／ BACKLOG.md = 発展課題・未解決論点・活性化状況
• setup-claude-code.md = 別マシンでの再セットアップ手順（環境の定義の正本） ／ user-memory-template.md = 個人メモリ（~/.claude/CLAUDE.md）のテンプレート。全プロジェクト共通の個人作業原則

ドキュメント構成

ファイルの番号順が推奨読み順。01 → 02 → 03 → 04 → 05 の順に読む（開発の HOW）。06 は WHAT（要件・仕様）フェーズの壁打ち方法論で、01〜05 とは別レイヤーの拡張章。

状態の読み方: 「本文完成」= 方針・方法論としての本文は確定済み。「配布中」= clone した時点で有効になる実体（読む側ではなく走る側）。各ファイルに <!-- BRAINSTORM --> タグが発展課題として残存しており、実プロジェクトでの検証を経て拡充する。残っている発展課題を一覧するには grep -rn "BRAINSTORM" *.md で本文を検索する（タグ自体が正本のため、別途の索引は持たない）。

記号の読み方: 各ファイルの本文で強調に使う記号（🔴 ⭐ ⚠️ 📌 など）は、01 の「記号凡例」で定義している。確度ラベル（[Fact] 等）とは別の軸である。

構成の順序意図: 01で全体戦略・思想を理解し、02でToken効率・ツール選定の原則を定め、03でSkillsの設計方法を学び、04で仕様駆動の重量を選び（Spec Kitは評価の上で軽量運用を主とする判断）、05で実際のテンプレートを活用する。06は開発の前段にあたる「何を作るか（WHAT）」を固める要件・仕様フェーズの方法論で、01〜05（どう作るか＝HOW）を補完する。

壁打ちの進め方

Token効率を最大化する運用ルール

1. トピック別にセッションを分ける — 区切りの候補は AI が申告し、閉じるかは人間が決める。区切ること自体にもコストがある（新しいセッションは起動と再開手順だけで文脈を使う。CLAUDE.md「チーム共通ルール」）
2. 確定した内容はMarkdownに書き戻す — Markdownが「外部記憶」として機能し、次のセッションで同じ議論を繰り返さない
3. 必要なファイルだけを読ませる — 全ファイルを同時に渡さない（@ファイル名 で渡すか、ファイル名を挙げて AI に読ませる）
4. 壁打ち済みの箇所は確定マーク — <!-- BRAINSTORM --> を消して確定内容に置き換える

セッションの始め方・終わり方

セッションはスプリントとして扱う（01 §3.6）。前セッションの終わりにレトロスペクティブを行い、次セッションの冒頭で前回 Action を検証（Check Action）してから作業に入る。この往復がないと、決めた改善が願望のまま蒸発する。

始め方（再開手順の実体は CLAUDE.md「再開手順」）

1. CLAUDE.md（現在モード）と自分の作業日誌（次にやること・現在地）を確認する
2. Check Action — 前回の Action がやれたか／結果はどうかを検証する。併せて、前回 [Assumption]（未確認の推測）で書いた箇所を再点検する
3. 着手タスクが名指すファイルだけを読む（01〜06 を一括ロードしない）

終わり方

1. 確定内容を該当ファイルへ、判断を docs/design-decisions.md、残課題を BACKLOG.md、作業の現在地を作業日誌へ書き戻す
2. 節目でレトロスペクティブを行い、次セッションの Action を作業日誌に置く

作業日誌は配布されません。 「次にやること」「作業の現在地」「稼働の記録」は書き手の生活の記録であって方法論ではないため、公開対象から外しています（理由は docs/design-decisions.md「作業日誌は公開しない」）。このガイドを使う人は、自分の作業日誌を自分で持ってください——clone した直後なら BACKLOG.md を起点にし、最初のセッションで作るのがおすすめです。

モデル選択の指針

選ぶのは製品ではなく用途の型である。 型は残り、当てはめる製品は世代交代で入れ替わる。

⚠️ 以下は 2026-07 時点の当てはめの例（時限付き）。 製品名が古くなっても、左端の「目的」と下の原則は古くなりません。

目的	当時の当てはめ	具体的ユースケース
深い概念整理・設計の壁打ち	Claude Opus 5	大規模リファクタリングの設計、ドキュメント体系の壁打ち
テンポの良い反復議論	Claude Sonnet 5	方針確定後の詳細化、.mdファイルの更新作業
クロスレビュー・再検証	まず新セッション＋@参照（同一モデルで可）／できれば別系統の高性能モデル	前提を追認させない再検証、仕様の整合性チェック
大量コンテキストの俯瞰	大容量コンテキスト特化モデル	大規模コードベースの俯瞰、長大コンテキストの一括把握

⚠️ 性能の比較表ではありません。 上表は用途への当てはめであって、モデル間の優劣を測った結果ではありません。

既定モデルと切替の原則: 判断主体の作業（設計・壁打ち・レビュー）は高性能モデルを既定にし、大量の機械的編集フェーズのときだけ高速モデルへ手動で切り替える。詳細は 01_ai-driven-dev-strategy.md セクション2「既定モデルと切り替えの原則」。

クロスレビューに複数ベンダーのアカウントは要らない: 本質は「別モデル」ではなく、推論過程を見ていない独立した目で読み直すこと。段階1（新セッション＋@参照）だけでも成立する。 段階2（レビュー用 Skill で観点を定型化）は、外に出る直前の検査については実物を配布している（.claude/skills/）が、クロスレビューそのものを発火させる Skill は未着手（BACKLOG.md 項目 H）——その観点は自分で用意する必要がある。 段階3（別系統の高性能モデル）も、無料アカウントのブラウザチャットに .md を渡すだけで成立した（2026-09-09 の実測）——有償契約や API 設定は要りません。 ⚠️ 回すかどうかは「できれば」で決めず、配布条件・入口・骨格に触れるときを合図にします。 詳細は 01_ai-driven-dev-strategy.md セクション2「クロスレビュー運用」。

現在の状態

• ナレッジ本文（01〜06）は完成済み（章ごとの状態は「ドキュメント構成」の表）
• 現在モードの正本は CLAUDE.md（常時ロードの制御plane）。ファイルマップ・編集規約・再開手順も同じ場所にある。モードは変わるため、ここには書かない（同じ情報を2箇所に置くと必ず片方が腐る）
• 設計判断とその理由は docs/design-decisions.md、発展課題・未解決論点は BACKLOG.md

別マシンでの再セットアップ

このリポジトリが Claude Code 運用設定の 正本 であり、プロジェクト共通設定はリポジトリ内（CLAUDE.md）、個人用設定は ~/.claude に置く。新しいマシンで同じ運用に戻すには以下の手順で十分。

正本は git 追跡ファイル、AIのメモリは per-machine キャッシュ: 耐久的な知識（規約・決定・プロジェクト文脈）は必ず git 追跡ファイル（本リポジトリの .md）に置く。Claude Code の自動メモリ機能はマシン単位のキャッシュで git clone に付いてこないため、メモリだけに残すと別マシンで文脈が途切れる。メモリは併用してよい（重複許容）が、正本は常に git 側に置く。

手順の正本は setup-claude-code.md。 環境の定義（どこに何を置くか）と再現手順はすべてそちらにある。ここには手順を列挙しない——README と手順書に同じ列挙を置いていた時期があり、実際に README 側が腐った（作業日誌への言及が抜け落ちた）。

⚠️ clone すべきリポジトリは1つではない。 このリポジトリだけを clone しても、CLAUDE.md の再開手順は空振りする（作業日誌が無いため）。自分の作業日誌リポジトリを並置する必要がある。詳細は setup-claude-code.md の手順 1-2。

生成AIの利用について

本ガイドは、生成AIとの壁打ち・クロスレビューを通じて作成した。具体的なプロセスは以下の通り。

• 壁打ち・初稿: 当時の高性能モデル（Claude Opus 4.8）による議論・構造化。⚠️ 以後の壁打ち・改訂も同じ「用途の型」で継続しており、当てはめる製品は世代交代で入れ替わる——「モデル選択の指針」と同じ扱いで、この行はモデル名ではなく型として読んでほしい
• クロスレビュー: 方法論としては推奨している（01 §2）。本ファイルと 01 は、別系統の生成AIによるクロスレビュー（段階3）を1回通した（2026-09-09。経緯と、そこで分かった段階3 の失敗モードは 01 §2「観測2」「観測3」）。⚠️ 02〜06 は未実施であり、全章を同じ観点で通す系統的なレビューはまだ行っていない。活性化状況は BACKLOG.md の活性化表（⬜ 未着手・項目 H）を参照。「書いた量と活性化した量は一致しない」を本ガイド自身にも適用した結果である
• 精査・裁定: 著者（人間）が全ての方針決定・取捨選択を実施
• 検証・改善: 実際の開発への適用を通じて継続中（どこまで裏取りできているかは BACKLOG.md の「章ごとの裏取り状況」を参照）

AIの出力をそのまま採用せず、人間が全ての方針を判断している。ただし、内容の正確性を完全に保証するものではない。

著者について

アジャイル/スクラムの実践を土台に、AIとの協働を規律づけることに関心があるフルスタックエンジニア。

• スクラムマスター — その役割で参画した経験と、開発者としてチームをボトムアップで正しいスクラムへ導いた経験の両方がある。良いスクラムも不完全なスクラムも経験している
• テクニカル PdM — 技術的判断まで踏み込む立場で、要件・仕様（何を作るか）を検査可能な形に固める仕事をしてきた。本ガイドの WHAT レイヤー（06）はここから生まれた
• 経験豊富なアジャイルコーチ、認定スクラムマスター／プロダクトオーナーとのチームでの実践を通じて、メタ認知とクリティカルシンキングを鍛えられた

本ガイドが「ツールの使い方集」ではなく「進め方の規律」を主題にしているのは、この経歴の反映である。

ライセンス

コンテンツの種類で分けています（LICENSE）。

なぜ分けるのか: 05 のテンプレート類はコピーされることを目的に置いてある。そこに氏名表示義務を課しても実際には守られず、守るコストが高い規律は形骸化する（本ガイド自身が繰り返し確認した原則）。一方、方法論の散文は出典を辿れることに価値があるため、著作者表示を求めている。

なぜ MIT ではなく MIT-0 か: 通常の MIT は「著作権表示を複製物に含めること」を条件に持つため、「表示は不要です」という説明と、条文が食い違う。 MIT-0 は MIT から表示の条項を外したものなので、説明と条文が一致する。⚠️ この食い違いは実際に本ガイドの LICENSE に存在し、別系統の生成AIによるクロスレビューで検出された（01 §2「観測2」）。⇒ 「守るコストが高い規律は形骸化する」を、自分のライセンス文で踏んでいた。

外部記事からの引用は引用元の著作物であり、本文中に出典を明示しています。