この記事を読むとわかること

• 書籍『Claude Code による AI 駆動開発入門』が示す、AI 駆動開発の全工程の流れ - 各フェーズで何を準備し、何を Claude にやらせ、何を機械（lint/CI/フック）に任せるか
• 並列タスク・サブエージェント・MCP まで含めた周辺ツールの使いどころ

書籍を読んで自分なりに整理した「Claude Code を使った開発の標準フロー」を、メモから漏らさず 1 本にまとめます。

課題・背景：AI 駆動開発の「順番」が分かりにくい

Claude Code を使い始めると、こんな迷い方をしがちです。

• 仕様書を先に作るべき？それともまず動くものを？
• Linter や CI はいつ入れる？
• 並列でタスク投げると速いの？それとも壊れる？
• サブエージェントとスラッシュコマンドの使い分けが曖昧
• そもそも「Claude にどこまで任せて、自分は何をする」のかが不明瞭

書籍はこの「順番」を明確に示してくれていました。仕様書 → ガードレール → タスク分割 → 実装 → レビュー という流れの中で、各フェーズの目的とツールを整理していきます。

全体像

以下、フェーズごとに本書のポイントを整理します。

0. 基本方針

書籍が冒頭で挙げていた「思考の前提」がこちら。

• テストは厳格なルールを作っておく（後述のガードレールに繋がる） - 設計は熟考させる— Claude に "考えさせる" 工程を端折らない - コーディングでは Context7 を使う— 最新ドキュメントを取りに行く - 簡単な仕様書を作ってから作業する— 仕様書ファースト 一気に作ると手を抜くので、フェーズを分けて TODO にチェックを入れながら作ってもらう- 終わった後で振り返って TODO ファイルにまとめさせる（拡張思考を使う） → その後実装させる

「振り返り → 拡張思考でまとめさせる → 次の実装」のループが、コンテキスト疲弊を防ぐコツとして紹介されていました。

1. 仕様書

AI 駆動開発に良い仕様書は必須、と本書は強調しています。

作るべきドキュメント:

• 要件定義書
• DB 定義書
• 画面設計
• API 定義書
• テスト仕様書

運用のコツ:

• 定義書は（忘れずに）@

マークで読み込ませる - 要約 or ディレクトリ分けでコンテキストを節約 - 仕様書作成用ライブラリ（例: claude-code-spec-workflow）も活用できる

2. ガードレール設定

要件定義とライブラリ選定が終わったら、実装前に 以下を入れます。実装が始まってからでは遅い。

プロセス系（実装前にセットアップ）

# Husky のセットアップ例
npm install --save-dev husky
npx husky init
...

ガードレールとして機能するもの（コードの中に組み込む）

• コンパイルチェック
• テスト（書き方はきちんと指示する）
• Linter の設定をプロジェクト開始時に入れておく
• データベースの型定義はPrismaで出力 - API はOpenAPIを使って型出力 - Zodでデータスキーマを定義（OpenAPI 仕様書から作るライブラリも活用） - 使用技術を書いておく — 人気の言語の方が精度が上がる

狙いは一貫しています — 「Claude が間違ったら、コンパイラかランタイムが止める」状態を作ること。

3. コンテキスト管理

長丁場の開発では、コンテキストの使い方が成否を分けます。

• 意識的に clear / compact を使う - compact で圧縮するときは何を重点的に残すか指示する（定義書に書いて永続化も可） - ガードレール設定が終わったら clear でリフレッシュし、claude.md をベースに ultrathink を使って構築タスクを定義 → GitHub Issue として記録

「重要事項は外部（定義書 / Issue）に逃がし、メモリは流す」というのがコンテキスト運用の基本姿勢でした。

4. 開発フロー（実装本体）

書籍が示す実装の標準フロー:

• 仕様書作成（要件 / DB / API / 画面 / テスト）
• ライブラリ選定
• ガードレール設定（Linter / テスト / Husky / CI/CD）
• clear

Context Refresh — ultrathink

Task Definition → gh

Create GitHub Issue via Command — Cut Branch to Implement → Submit PR for Review

Instructions for PR Review

Reviews are not only "for humans to see later" but also recommended by this book to have Claude review it.

• Specify the PR number
• Instruct to write review content as a comment on the pull request

Using Claude Code GitHub Action, you can automatically review in the PR comments section.

5. Parallel Tasks (Git Worktree)

A parallelization technique when wanting to increase throughput.

• Create subfolders using Git Worktree, set up separate branches, and submit PRs
• Also instruct on naming rules for subfolders — After merging, delete the worktrees (but keep the branches) — Because it consumes resources and makes understanding difficult
• Up to 2 parallel tasks — Only 1 branch can be integrated with IDE — Also put Linters and Husky into subdirectories

It was a realistic check that this book pointed out: "There is a practical limit where doing too much in parallel causes humans to break down."

6. Sub-agents

Sub-agents are "specialists in specific domains."

Agents do not share context with each other — Adopting a consulting / contract work approach →

• It is proper to write design documents thoroughly and assign implementation to sub-agents — When assigning tasks, for the sake of context saving
• Tag Issues beforehand

The book organized that "the design of context passed to sub-agents" is exactly the same as "the design of outsourced work", which was very convincing.

7. Useful Features

Custom Slash Commands

• If you put together instructions,
• They become reusable — It is also convenient to summarize workflows for tasks against Issues or splitting work into Worktrees into slash commands.

Hooks

Set up contents that should be executed after certain operations. Commands can be defined as .sh files.

• Launch Linters / Formatters
• Keep logs
• Notify after task completion
• Load instructions you must not forget

The consistent argument of this book was: "Write rules you want to enforce 100% into Hooks".

Skills

Something like an execution procedure manual for specific tasks (e.g., Excel operations, how to write tests, etc.).

• At places that can be used,
• Automatically use them — Slash commands are "workflows", Skills are "how-to", with a clear distinction.

8. Tools & Others

Surrounding tool groups mentioned in the book:

Summary

If I translate the standard flow of AI-driven development from this book into my own words:

• Spec-driven: Document "OK criteria" before writing —
• Guardrails before implementation: Linters / Tests / Husky / CI / Type generation —
• Externalize Context: Intentionally use compact/clear
• Tasks are GitHub Issue units: Create with gh, implement via Branch + PR —
• Parallel up to 2: Utilize Worktrees, but don't overdo it —
• Sub-agents are outsourcing: Assign by passing design documents and letting them handle it
• Repeatable tasks go to Slash Commands / Hooks / Skills —
• Screens/Designs/Security are automated with dedicated tools: Playwright / Figma MCP / Security-review

When viewed as a whole, it becomes clear that everything is connected by the thought: "Before asking Claude to write, mechanically solidify where and how it can be written."

Next Actions

• For existing projects, first check for guardrail gaps (Linters / pre-commit / CI / Type generation) — For new ones, follow the book's flow strictly in order of Spec → Guardrails → Implementation — Slash Commands / Hooks / Skills should be started sequentially as repetitive tasks arise.

Reference: 『Claude Code by AI-driven Development Introduction』 Support Page