Claude CodeのPLAN MODEは使ったほうがいい - じゃあ、おうちで学べる

Claude Codeを使い始めて、様々な発信をしてきました。今回は「PLAN MODE」と「パーミッションモード」について。Claude Codeには複数の動作モードがあり、これを使い分けられるかどうかで出力品質が劇的に変わります。

はじめに

「この機能を実装して」。Claude Codeにそう言って、Enter を押す。Claude は即座にファイルを読み、コードを書き始める。5分後、20ファイルが変更されている。ビルドは通る。テストも通る。しかし見返してみると、設計意図と違う。やり直し。また5分。今度は別の方向にずれている。こういう経験、ありませんか。

私自身、Rustプロジェクトの認証モジュールのリファクタリングをClaude Codeに任せたとき、まさにこの罠にはまりました。「OAuth2対応して」と言ったら、既存のセッション管理を全部書き換え始めた。後方互換性は？DBマイグレーションは？聞いてもいないのに勝手にやってくれる。やり直し。2回目も方向性がずれる。3回目でようやく「まず計画を立てよう」と思い至りました。

この問題の根本にあるのは、「考える」と「実行する」を同時にやらせていることです。人間のエンジニアだって、設計書なしにいきなりコーディングすれば事故が起きます。「え、何作ってんの？」と聞かれた経験があるのは私だけではないはずです。Claude Codeも同じです。LLMは与えられたタスクを「前に進める」ことに最適化されています。立ち止まって全体を俯瞰することは、明示的に指示しない限りやりません。

そして、もう一つの問題はパーミッションの確認地獄です。Normal Modeでは、mkdirひとつ、git statusひとつに対しても確認ダイアログが出ます。これはセキュリティ上は正しい。しかし、複雑なタスクで20回、30回と「Allow」を押し続けるのは、ワークフローの断絶そのものです。コーヒーを取りに行って戻ってきたら、ステップ2で止まっている。あるあるです。

Claude Codeはこの2つの問題に対して、段階的なパーミッションモードを用意しています。PLAN MODEで「考える」と「実行する」を分離し、CLAUDE.mdやRulesで品質の枠組みを整え、最終的に--dangerously-skip-permissionsで自律実行させる。この段階的なアプローチが、私が最近たどり着いたワークフローです。

ただし、ここで強調しておきたいことがあります。設定を1行書くたびに、Claudeの手綱が1段緩められる。 CLAUDE.mdとRulesが未整備なら、PLAN MODEで人間が計画をレビューすることが唯一の品質保証手段になる。逆に、CLAUDE.mdとRulesを丁寧に整備すればするほど、Claudeへの信頼度が上がり、最終的には--dangerously-skip-permissionsでの自律実行まで到達できる。ガードレールの精度が、委任できる範囲を決める。

前回の記事で紹介したAgent Skillsが「専門知識の注入」だとすれば、PLAN MODEは「思考プロセスの制御」、Rulesは「行動の制約」、そしてパーミッション設定は「自律性のコントロール」です。この4つは独立して機能するものではなく、掛け算で効く。 1つが欠けると、他の3つの効果も減衰します。

code.claude.com

このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。

他の設定・機能との位置づけ

今まで紹介してきた機能にPLAN MODE、Rules、パーミッションモードを加えて、改めて整理します。

機能	役割	例
CLAUDE.md	プロジェクトのグローバルな文脈	「うちはRustで、こういうアーキテクチャ」
Rules	関心事ごとのルール適用	セキュリティ、テスト、Git規約など
commands	手動で呼び出すショートカット	`/test-and-commit` で一連の作業を実行
Hooks	特定のイベントで自動実行	ファイル保存後に自動フォーマット
Subagents	専門家を自動で呼び出す	デバッグ時にdebugger subagentが起動
Agent Skills	専門知識をオンボーディング	PDF操作、独自ワークフロー
PLAN MODE	思考と実行を分離する	設計レビュー → 承認 → 実装
パーミッション設定	自律性のレベルを制御	Normal → Auto-Accept → YOLO

この表を見ていて気づくのは、上6行と下2行の性質の違いです。CLAUDE.mdからSkillsまでは「何を伝えるか」——つまり知識の問題です。PLAN MODEとパーミッション設定は違う。「どう振る舞わせるか」の問題です。 入力を整えるのと、出力を制御するのとでは、アプローチがまったく異なります。前者をいくら積み上げても、後者の代わりにはならない。

Rulesは、両者の境界に位置する存在です。「知識」として読み込まれながら、実質的には「行動制約」として機能する。CLAUDE.mdと同じ「高優先度」でロードされながら、関心事ごとにファイルを分離できる。Rulesの質がそのまま自律実行の安全性を決める。 正直に言えば、CLAUDE.mdの整備に時間をかけていた初期の私は、このRulesの重要性を完全に見落としていました。

CLAUDE.mdのリファクタリングとRulesの整備

PLAN MODEの話に入る前に、避けて通れない前提があります。CLAUDE.mdとRulesの整備です。ここが雑だと、どんなモードを使っても意味がない。道具の使い方以前に、道具を使う土台の問題です。

モノリシックなCLAUDE.mdの問題

正直に告白すると、私のCLAUDE.mdも一時期500行を超えていました。最初は「ビルドはcargo fmtから」くらいだったのが、使い込むうちにあらゆる規約を書き足していく。APIの設計指針、テストの規約、セキュリティ要件、デプロイ手順。気づけば、プロジェクトの全知識を一つのファイルに詰め込んでいた。

問題の本質は「注意の希釈」です。 CLAUDE.mdはセッション開始時に全文がロードされます。バックエンドのAPIを修正しているのにフロントエンドのCSS規約も読み込まれる。前回の記事で説明したProgressive Disclosure（段階的開示）の真逆です。人間に例えるなら、料理をしようとしている人に家中のマニュアルを全部渡すようなもの。情報が多いほど、個々の指示の「重み」が希釈される。500行の中に埋もれた「unwrap()は禁止」の1行を、Claudeが確実に拾ってくれる保証はありません。

CLAUDE.mdを50行以下にリファクタリングする

私は、CLAUDE.mdをルーティングテーブルにまで圧縮しています。具体的には、以下のプロンプトをClaude Codeに投げます。

Analyze CLAUDE.md and propose an extraction plan before making changes. Decompose into: .claude/rules/*.md for file-type or directory-scoped conventions (with paths: glob frontmatter), .claude/skills/<name>/SKILL.md for multi-step procedures and code generation patterns (with name:/description: frontmatter), .claude/commands/<name>.md for user-invoked reusable prompts, .claude/agents/<name>.md for delegatable specialist roles (with name:/description:/tools: frontmatter). After extraction, reduce CLAUDE.md to <50 lines containing only project overview, tech stack, universal commands, and @imports to extracted files. Report line count and estimated token count before and after.

このプロンプト自体がPLAN MODEの実践例です。 「まず計画を見せて」で計画を先に提示させ、確認してから実行する。これが後述するワークフローの基本パターンです。プロンプトの中に抽出先ごとのfrontmatter形式まで指定しているのは、Claudeに「どういう形式で出力すべきか」を明示するためです。曖昧に任せると、ファイル構造がプロジェクトごとにバラバラになる。

リファクタリング後のCLAUDE.mdはこうなります。

# プロジェクト概要

RustによるgRPC APIサーバー。sqlxでDB接続。

# 優先順位

正しさ > 保守性 > パフォーマンス > 簡潔さ

# ビルド・テスト

cargo fmt --check && cargo clippy -- -D warnings && cargo test --workspace

# 禁止事項

- unwrap() / expect() は本番コードで使用禁止
- unsafe ブロック追加禁止
- 既存のpublic APIシグネチャ変更禁止

# 参照

See @README.md for architecture overview

50行以下。プロジェクトの最も重要な制約だけが残ります。残りはすべて、適切な場所に分配されています。

Rulesへの抽出：関心事で分離し、パスでスコープする

CLAUDE.mdから抽出した情報のうち、特定の関心事に属するルールは.claude/rules/に配置します。セキュリティ、テスト、Git規約、パフォーマンス——それぞれ独立したファイルに分離する。さらに、各ルールファイルの先頭にpaths: frontmatterを書くことで、特定のパスのファイルを編集しているときだけルールがロードされるようにできます。

.claude/rules/
├── security.md          # セキュリティ規約（NEVER/MUST形式）
├── coding-style.md      # コーディング規約（命名規則、構造体設計）
├── testing.md           # テスト規約（命名規則、カバレッジ目標）
├── git-workflow.md      # Git規約（Conventional Commits、ブランチ戦略）
├── agents.md            # エージェント委譲ルール（いつ誰に任せるか）
└── performance.md       # パフォーマンス規約（クローン回避、ビルド最適化）

各ルールファイルは、関心事ごとに分離し、paths: frontmatterでスコープを切ります。 たとえばセキュリティルールは「NEVER（絶対禁止）」と「MUST（必須）」の2カテゴリで構成し、Rustのソースコードを触るときだけロードされるようにする。

---
paths:
  - src/**/*.rs
---

# セキュリティルール

## NEVER
- unwrap()/expect() のプロダクション使用
- 機密情報のハードコード
- 未検証の unsafe ブロック

## MUST
- 入力バリデーション
- 整数オーバーフロー対策（checked_* 使用）
- SQLパラメータ化（文字列結合禁止）
- 依存関係の定期監査

テスト規約も同様に、テストファイルを触るときだけ読み込まれるようスコープを切ります。

---
paths:
  - tests/**/*.rs
  - src/**/tests.rs
---

# テスト規約

- テスト関数名は `test_<対象>_<条件>_<期待結果>` 形式
- カバレッジ目標: ビジネスロジック90%、APIハンドラ80%、ユーティリティ70%
- ミューテーションテスト（cargo-mutants）で品質を検証
- 非同期テストは #[tokio::test] を使用

ポイントは二つあります。 一つはルールの粒度。「すべてを網羅する」のではなく、「Claudeが最も間違えやすいポイント」に絞る。私の経験では、セキュリティ（unwrap禁止、入力バリデーション）とテスト（命名規則、カバレッジ目標）の2つが、Rulesの効果が最も顕著に現れる領域です。

もう一つはpaths: frontmatterによる条件付きロード。テストファイルを書いているときにセキュリティルールは読み込まれない。必要なルールだけが、必要なときに、高優先度で読み込まれる。前回の記事で説明したSkillsの段階的開示と同じ発想です。情報を「足す」のではなく、「絞る」ことで精度を上げる。 引き算の設計思想がここにもあります。

なぜこの整備がPLAN MODEと`--dangerously-skip-permissions`に直結するのか

ここが本記事の核心的な主張です。

PLAN MODEとの関係: CLAUDE.mdが肥大化していると、PLAN MODEで立てた計画の品質も下がります。Claudeは500行のCLAUDE.mdを読んで「このプロジェクトの規約はこうだ」と理解しようとしますが、情報が多すぎると重要なルールを見落とす。結果、計画に「unwrap()を使う」ようなコードが含まれる。ルールが整備されていれば、PLAN MODEで立てる計画の精度が上がる。

--dangerously-skip-permissionsとの関係: YOLO実行中はClaude が自律的にファイルを編集しコマンドを実行します。このとき、Claudeの行動を制約するのはCLAUDE.mdとRulesだけです。人間が逐一チェックしない以上、ルールの品質＝自律実行の安全性です。Rulesが整備されていなければ、YOLO実行は文字通りギャンブルになります。

つまり、CLAUDE.mdのリファクタリングとRulesの整備は、単なる整理整頓ではなく、PLAN MODEの計画精度と--dangerously-skip-permissionsの安全性を決定する基盤なのです。

Rulesでも防げないもの：Linterという最終防衛線

ここで正直に言っておくべきことがあります。Rulesを整備しても、Claudeが100%ルールに従うとは限らない。 CLAUDE.mdに「unwrap()禁止」と書いてあっても、複雑なリファクタリングの最中にClaudeがunwrap()を使うことはある。Rulesはあくまで「指示」であって、「強制」ではないからです。

では、どうするか。Linterを作るしかない。 エージェントは「鏡のないバスルーム」では身だしなみを整えられない。自分の出力を検証するフィードバックループがなければ、ミスに気づけないまま突き進む。テスト、Linter、型チェック——これらは「鏡」です。鏡を置いてやることで、人間の監視コストが劇的に下がる。cargo clippyのカスタムルール、ESLintのプロジェクト固有設定、Ruffのルールセット。RulesがClaudeへの「お願い」だとすれば、Linterは「物理的な壁」です。unwrap()が混入しても、cargo clippy -- -D warningsがCIで弾く。人間がレビューで指摘しなくても、機械が確実に止める。

正直に告白すると、私の業務時間のかなりの部分はLinterの整備に充てられています。プロジェクト固有のLintルールを書き、CIに組み込み、Hooksで自動実行させる。地味な仕事です。しかし、この投資が「YOLO実行」の安全性を根本から支えている。 Rulesが「Claudeの行動指針」、Linterが「機械的な品質保証」、その二重構造があって初めて、自律実行は「ギャンブル」から「運用」になります。

ここで一つ、原則を明確にしておきます。「二度目の失敗」は仕組みの欠陥です。 エージェントの同じミスに二度怒るのは、ガードレールのない道路で事故を運転者のせいにするのに似ている。Claudeがunwrap()を使ったら、一度目は指摘して直す。二度目があったなら、それはClaudeの問題ではなく、ルールの問題です。ミスを観測したら即座に構造で封じる——Rulesに追記するか、Linterのルールを追加するか、Hooksで自動検出させる。これはAI固有の話ではなく、あらゆる自動化の鉄則の再発見です。私がRulesファイルを毎週のように更新しているのは、この原則を愚直に回しているからにすぎません。

後述するワークフローの「[テストコマンド]を継続的に実行して」というキーフレーズも、この思想の延長線上にあります。テストもLintも、Claudeの出力を機械的に検証する仕組みです。人間のレビューに依存しない品質保証の仕組みをどれだけ積み上げられるかが、自律実行の信頼性を決める。

Skillsやcommands、agentsへの分配

Rulesの他にも、CLAUDE.mdから抽出すべき情報はあります。

抽出先	対象	例
`.claude/rules/`	関心事ごとのルール	セキュリティ、テスト、Git、パフォーマンス
`.claude/skills/`	専門知識のリファレンス	パターン集、コーディング標準
`.claude/commands/`	ユーザーが手動で呼ぶテンプレート	`/review`、`/plan`、`/cargo-check`
`.claude/agents/`	専門的な独立タスク	コードレビュアー、プランナー、セキュリティレビュアー

この分配を行った後の変更前/変更後を比較すると、その効果は数字で見えます。

指標	変更前	変更後
CLAUDE.md行数	487行	42行
起動時ロードトークン	~8,000	~1,200
ルールファイル	0個	6個
Skill/Agent	0個	11個

起動時のトークン消費が85%削減されました。その分のコンテキストが、実際のタスクに使えるようになります。

Claude Codeのパーミッションモード全体像

では、パーミッションモードの全体像に入ります。これを理解することが、PLAN MODEと--dangerously-skip-permissionsを使いこなす前提です。

4つのモード

モード	動作	切り替え
Normal Mode（Ask）	すべての操作に承認が必要	デフォルト
Auto-Accept Mode	ファイル編集は自動承認、コマンド実行は確認	Shift+Tab × 1
Plan Mode	読み取り専用、変更操作は一切不可	Shift+Tab × 2
Bypass Permissions（YOLO）	すべての操作を自動実行	`--dangerously-skip-permissions`

Shift+Tabを押すたびにモードが切り替わります。Normal → Auto-Accept → Plan → Normal → ...のサイクルです。

Normal Mode：安全だが遅い

デフォルトのモードです。すべての操作に承認が必要。Claudeがファイルを編集するたびに差分表示、コマンドを実行するたびに確認ダイアログ。安全だが、安全なだけだ。 安全であることは目的ではない。しかし、CLAUDE.mdもRulesも整備されていない初期段階では、このモード一択です。信頼は実績の上に築くものであって、最初から与えるものではない。 これはAIに限らず、人間同士の協働でも同じことです。

Auto-Accept Mode：ファイル編集の信頼

Shift+Tabを1回押すと入るモードです。ターミナル下部に ⏵⏵ accept edits on と表示されます。ファイル編集は自動承認、Bashコマンドは確認が必要。私はこのモードを「半信半疑モード」と呼んでいます。Claudeのコード変更は信頼するが、システムに影響を与える操作はまだ自分の目で確認したい。CLAUDE.mdを整備した段階で、自然とここに移行することが多いです。

Plan Mode：読み取り専用の安全地帯

Shift+Tabを2回押すと入るモードです。ターミナル下部に ⏸ plan mode on と表示されます。次のセクションで詳しく説明します。

`--dangerously-skip-permissions`：完全自律実行

いわゆる「YOLO Mode」です。すべてのパーミッションチェックをバイパスし、Claudeが中断なく最後までタスクを実行します。

claude --dangerously-skip-permissions

名前に「dangerously」が入っているのは伊達ではありません。しかし、正しく使えば最も生産性が高いモードでもあります。PLAN MODEで計画を立て、CLAUDE.mdとRulesで品質の枠組みを整えた上で使えば、「計画通りに最後まで自動実行」が実現します。

安全に使うための前提条件:

Gitで必ずチェックポイントを作る: 実行前にgit add -A && git commit -m "checkpoint"
隔離環境で実行する: Docker コンテナやDevcontainerがベスト
CLAUDE.mdとRulesを整備済みであること: 前セクションで述べた基盤が必要
計画が承認済みであること: PLAN MODEで立てた計画に沿って実行させる

PLAN MODEとは何か

PLAN MODEは、Claude Codeを読み取り専用の調査・計画フェーズに制限するモードです。ファイルを読み、コードベースを検索し、質問をし、計画を立てることができます。しかし、ファイルの編集、コマンドの実行、外部への変更は一切できません。

Plan Mode instructs Claude to create a plan by analyzing the codebase with read-only operations, perfect for exploring codebases, planning complex changes, or reviewing code safely.

使えるToolと使えないTool

使えるTool（読み取り専用）	使えないTool（変更操作）
Read - ファイル閲覧	Edit/MultiEdit - ファイル編集
LS - ディレクトリ一覧	Write - ファイル作成
Glob - ファイルパターン検索	Bash - コマンド実行
Grep - コンテンツ検索	NotebookEdit - ノートブック編集
Task - リサーチエージェント	状態を変更するMCPツール
TodoRead/TodoWrite - タスク管理
WebFetch/WebSearch - Web調査

この制約が「安全な探索」を可能にします。 通常モードだとClaudeが「ついでにここ直しておきますね」と勝手に変更を加えることがある。PLAN MODEならそれが物理的にできない。安心してコードベースの深層を探索させられます。

なぜ「分離」が重要なのか

AIコーディングの失敗の大半は、「考えながら手を動かす」ことに起因する。 これは私の実感です。ペアプログラミングにドライバーとナビゲーターの分離があるように、思考と実行は本来別のプロセスです。一人の人間が同時にやるとミスが増える。LLMはさらに顕著で、「これ直しましょう」と「全体の整合性は大丈夫か」を同時に処理させると、ほぼ確実にどちらかが疎かになる。

私はこれを「フクロウを描け」問題と呼んでいます。ステップ1：丸を描く。ステップ2：フクロウの残りを描く。巨大で曖昧な指示は人間にとっても困難なのだから、AIにとってはなおさらです。冒頭のOAuth2の事故がまさにそうだった。「OAuth2対応して」はフクロウを描けと言っているのと同じです。構想と施工を一つの息でやらせない。設計図を引く工程と、釘を打つ工程は、別のセッションに分離する。PLAN MODEはこの分離を物理的に強制する仕組みです。

——と書いて、立ち止まる。「まだ書かないで」と自然言語で指示すればいいのでは？実はそれも試しました。結果、Claudeは3回に1回くらい従わない。計画の途中で「ここは明らかなので修正しておきますね」と手を動かし始める。PLAN MODEの価値は、この「うっかり実装を始める」を物理的に不可能にする点にあります。Tool自体が無効化されている。プロンプトの曖昧さとは次元が違う確実性です。

ガードレールが未整備な段階では、この分離がさらに重要になります。 CLAUDE.mdもRulesもない状態でClaudeに自由に実装させると、出力は制御不能になる。計画段階で人間がレビューし方向性を確認すること。それが、未整備な環境における唯一の品質保証手段です。

基本的な使い方

Shift+Tabで切り替える

Normal Mode → Auto-Accept Mode → Plan Mode → Normal Mode → ...

Shift+Tabを1回押すと「Auto-Accept Mode」（⏵⏵ accept edits on）。もう1回押すとPLAN MODE（⏸ plan mode on）。さらにもう1回でNormal Modeに戻ります。

セッション開始時からPLAN MODEで始める

claude --permission-mode plan

ヘッドレスモードでの利用

claude --permission-mode plan -p "認証システムを分析して改善点を提案して"

デフォルトをPLAN MODEに設定する

// .claude/settings.json
{
  "permissions": {
    "defaultMode": "plan"
  }
}

Ctrl+Gで計画を編集する

PLAN MODEの隠れた強力機能です。Claudeが計画を提示したあと、Ctrl+Gを押すとデフォルトのテキストエディタで計画ファイルが開きます。AIが作った計画を人間が手で修正できる。この双方向性がPLAN MODEの真価です。

推奨ワークフロー：調査 → 計画 → 実装

ここから紹介するワークフローは、Anthropicの公式ベストプラクティスをベースに、私自身がPLAN MODEを使い込む中で形になったものです。核心は単純です。コードを書く前に、必ず承認済みの計画書を用意する。 言ってしまえば当たり前のことですが、AIの実行速度が上がるほど、この「当たり前」を飛ばしたくなる。飛ばした結果が、冒頭のOAuth2の事故です。

Phase 1: 調査（Research）

PLAN MODEに入って、コードベースを徹底的に調査します。

> src/authを深く読み込んで、セッション管理とログインの仕組みを徹底的に理解して。
> 環境変数によるシークレット管理の方法も調べて。
> 調査結果をresearch.mdに書き出して。

ここでの言葉遣いが重要です。「深く」「徹底的に」「詳細に」。これはただの修飾語ではない。Claudeの調査深度を決定するパラメータです。 省略すると、Claudeは関数のシグネチャだけ見て「理解した」と判断する。人間のエンジニアでいえば、READMEだけ読んで「把握しました」と言うようなものです。表面的な理解は、無理解より危険です。 「分かったつもり」の状態で書かれたコードは、正しく見えるだけに発見が遅れる。

調査結果をresearch.mdとして永続化させるのも、私が習慣にしていることです。チャットの中の口頭説明は流れていく。ファイルに書かせれば、Claudeの理解度を可視化できる。理解が間違っていれば、計画に入る前に軌道修正できます。

AIコーディングで最もコストの高い失敗は、バグではありません。「既存システムを無視した実装」です。 既存のキャッシュレイヤーを無視した関数。ORMの規約を無視したマイグレーション。既にあるロジックの重複実装。冒頭で触れたOAuth2の事故も、根本はこれでした。既存のセッション管理を理解せずに上書きした。調査フェーズは、この種の構造的な失敗を防ぐための投資です。

Phase 2: 計画（Plan）

調査結果をもとに、詳細な実装計画を作成させます。

> Google OAuthを追加したい。調査結果をもとに、
> 実装方法を詳細にまとめたplan.mdを作成して。
> コードスニペットとファイルパスを含めること。まだ実装しないで。

「まだ実装しないで」は必須のガードレールです。 これがないと、Claudeは計画が「十分良い」と判断した瞬間にコードを書き始めます。

Phase 2.5: アノテーションサイクル（計画の研磨）

ここが本記事で最も伝えたい点です。 計画をClaudeに書かせ、それを自分のエディタで「赤入れ」する。このアノテーションサイクルが、私がClaude Codeの運用で最も効果を実感した手法です。一見すると二重作業に見えます。Claudeに計画を書かせて、自分でも同じ計画を読み込んで修正する。しかし、この「自分の仕事を写経させる」苦痛こそが、エージェントの能力境界を自分の身体感覚として刻み込むための最速のコストです。他人のブログを読んで「PLAN MODEが良いらしい」と知るのと、自分でアノテーションを3回繰り返して「ここはClaudeに任せられる、ここは任せられない」を体で覚えるのとでは、得られる知識の質がまったく違う。

Claudeがplan.mdを書いたら、自分のエディタで開いて、インラインでメモを書き込みます。

## 認証フロー

- OAuth2のコールバックURLを設定 [注: ステージングと本番で別URLにすること]
- セッショントークンを生成 [注: 既存のJWT生成ロジックを再利用。新しく作らない]
- ユーザーテーブルにOAuthプロバイダーカラムを追加 [注: PATCHマイグレーションで。テーブル再作成はNG]

メモの粒度は様々です。2語で済むこともあれば、パラグラフ丸ごと書くこともある。ドメイン固有の知識、設計判断の根拠、「これはやるな」という明示的な拒否。Claudeが知り得ない文脈を、計画書の正確な位置に注入する。 これはコードレビューのコメントに近い感覚です。ただし、レビュー対象がコードではなく計画書である、という点が決定的に違います。

> plan.mdにメモを追加した。すべてのメモに対応してドキュメントを更新して。
> まだ実装しないで。

このサイクルを1〜6回繰り返します。 毎回「まだ実装しないで」を付けるのが鉄則です。人間の同僚に「計画だけ書いて。実装はまだ」を6回繰り返したら、さすがに関係が悪化します。しかしコーディングエージェントは疲れないし、不満も持たない。納得いくまで計画を練り直させられるのは、人間相手にはない非対称な利点です。遠慮なく使い倒していい。

なぜこれが強力なのか。 plan.mdは自分とClaudeの間の「共有されたミュータブルステート」です。チャットで方針を伝えると、過去の発言は流れていく。しかし計画書なら全体を俯瞰でき、問題箇所をピンポイントで修正できる。私の経験では、3回のアノテーションサイクルで、Claudeが書いた汎用的な計画が「自分のシステムの文脈に完全にフィットする設計書」に変わります。

ここでもRulesの整備が効いてきます。セキュリティルールが読み込まれていれば、Claudeは計画段階から入力バリデーションやパラメータ化クエリの使用を考慮に入れる。ルールが未整備だと、この種の観点を人間が毎回アノテーションで指摘するしかない。Rulesの整備度は、アノテーションサイクルの回数に反比例する。 設定への投資が、ここでも回収されます。

Phase 2.75: Todoリスト化

計画の内容が固まったら、次は「実装中に迷子にならない」ための準備です。

> 計画に詳細なTodoリストを追加して。全フェーズと個別タスクを含めること。
> まだ実装しないで。

計画書とTodoリストは役割が違います。計画書は「何をどう作るか」の設計図。Todoリストは「今どこにいるか」の現在地表示です。Claudeはタスク完了時にチェックを入れるので、数時間のセッションでも進捗が可視化される。長いセッションで最も怖いのは、Claudeが途中で方向を見失うことです。 Todoリストはその防波堤になります。

Phase 3: 実装（Implement）

計画に納得したら、モードを切り替えて実装させます。ここで私が最近採用しているのが、--dangerously-skip-permissionsとの組み合わせです。

claude --dangerously-skip-permissions
> plan.mdの計画を実装して。完了したタスクは随時チェックを入れて。
> すべてのタスクが完了するまで止まらないで。
> cargo fmt && cargo clippy -- -D warnings && cargo testを継続的に実行して。

なぜここで--dangerously-skip-permissionsを使うのか。 計画フェーズですべての創造的な判断は済んでいるからです。実装は退屈であるべきだ。 これは私が最近強く実感していることです。計画書に従って機械的にコードを書くフェーズで、mkdirの確認を一つ一つ承認するのは、集中力の浪費でしかない。

もう一つ、発想の転換があります。「エージェントで時短する」——多くの人がこう考えます。私も最初はそう思っていた。しかし実際にYOLO実行を組み込んでみて気づいたのは、奪うべきは他人の時間ではなく「自分の不在時間」だということです。自分が寝ている間、コーヒーを飲んでいる間、散歩に出ている間——その「ゼロ生産性」の時間帯を正の値にする。これは「速くやる」よりも摩擦が少ない。YOLO実行が最も力を発揮するのは、人間がモニターの前に座っていない時間帯です。Gitチェックポイントを打ち、計画書を渡し、席を立つ。戻ってきたらdiffを確認する。

——と書いて、少し躊躇する。実装中に「あれ、この型だとエラーパスが3つ増えるぞ」と気づくことがある。計画段階では見えなかった問題が、コードを書く手を通じて初めて表面化する。完全な退屈は達成できない。しかし、退屈に近づくほど、実装の品質は安定する。もし実装中に「創造的な判断」が頻発しているなら、それは計画が不十分だったということです。計画に戻るべきであって、実装を続けるべきではない。

ただし、順番を間違えてはいけません。 計画を研磨し、CLAUDE.mdとRulesで品質の枠組みを整えた上で、初めてこのアプローチが成立する。計画なし・設定なしのYOLOモードは、自律実行ではなくただの放任です。

私のワークフロー全体像：整備 → Plan → YOLO

Phase 0: 環境整備（一度だけ、以後メンテナンス）
  ├── CLAUDE.md を50行以下に圧縮
  ├── .claude/rules/ に関心事ごとのルールを配置
  ├── .claude/skills/ にワークフローSkillを配置
  └── .claude/settings.json にdenyルールを設定

Phase 1: 調査（PLAN MODE）
  └── コードベースを深く調査 → research.md

Phase 2: 計画（PLAN MODE）
  └── plan.md 作成 → アノテーションサイクル × 1-6回 → Todoリスト化

Phase 3: 実装（--dangerously-skip-permissions）
  └── git checkpoint → 計画に基づいて自律実行

Phase 4: 検証
  └── diff確認 → テスト → 必要なら修正

このワークフローで見落とされがちなのは、本当のボトルネックが「エージェントの実行速度」ではないことです。「常にエージェントを回す」は手段であって目的ではない。ボトルネックは「委任可能な良質タスクの在庫管理」にあります。仕事を適切な粒度に分解し、優先順位をつけ、パイプラインとして流し続ける能力。Phase 1の調査とPhase 2の計画が重要なのは、まさにこの「タスクの仕込み」を行う工程だからです。考えてみれば、これはAI以前から優れたエンジニアの条件でした。チケットの切り方がうまい人は、昔からチームの生産性を何倍にもしていた。

Phase 0の詳細：denyルールで致命的操作を防ぐ

--dangerously-skip-permissionsを使う場合でも、.claude/settings.jsonで特定の操作を禁止できます。

{
  "permissions": {
    "allow": [
      "Read",
      "Edit",
      "Write",
      "Grep",
      "Glob",
      "Bash(cargo *)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(mkdir *)"
    ],
    "deny": ["Bash(rm -rf *)", "Bash(git push *)", "Bash(curl *)"]
  }
}

rm -rf、git push、curlを拒否。cargo系やGitの基本操作は許可。--dangerously-skip-permissionsの利便性を保ちつつ、致命的な操作を防ぐバランスです。

Phase 3の実践：安全なYOLO実行

1. Gitチェックポイントは絶対

git add -A && git commit -m "checkpoint: before YOLO implementation"

何が起きてもgit reset --hard HEADで戻せる状態にしておく。

2. 実装指示は具体的に

YOLO実行時に私が毎回含めるキーフレーズは5つです。

「plan.mdの計画を実装して」: 計画書を実装の唯一の根拠にする。計画にないことはやらせない
「すべて実装して」: 全タスクを実行させる。つまみ食いさせない
「完了したタスクにチェックを入れて」: plan.mdを進捗トラッカーとして機能させる。どこまで終わったか可視化する
「すべてのタスクが完了するまで止まらないで」: 途中で確認を求めさせない。最後まで走り切らせる
「[テストコマンド]を継続的に実行して」: 壊れたら即座に気づかせる。テストが落ちたまま次に進ませない

3. 隔離環境の推奨

docker run -it --rm -v $(pwd):/workspace -w /workspace \
  --network none \
  claude-code:latest --dangerously-skip-permissions \
  "plan.mdの計画を実装して"

--network noneで外部接続を遮断。コンテナ内なら被害が限定されます。

Phase 4: 実装中のフィードバック

実装中のフィードバックについて。ここでの指示は極めて短くていい。 計画フェーズであれほど丁寧に文脈を書き込んだのは、この瞬間のためです。共有済みの計画書があるから、「あれと同じにして」の一言でClaudeは正確に意図を汲み取れる。計画フェーズの投資が、実装フェーズのコミュニケーションコストを劇的に下げる。 この因果関係を体感すると、計画に時間をかけることへの抵抗がなくなります。

ただし、短い指示が万能かというと、そうでもない。以前、「設定ページはadminアプリに作るべき。移動して」と一言で済ませたら、Claudeはページを移動しつつルーティングの整合性を壊した。計画書には「adminアプリのルーティング構造」が書いてあったのに、短い指示がそのコンテキストを上書きしてしまった。短い指示が効くのは、計画書のコンテキストが十分に残っているときだけです。セッションが長くなってコンテキストが薄れてきたら、指示の粒度を上げるか、/clearして計画書を再読み込みさせる必要がある。

> deduplicateByTitle関数が実装されていない
> 設定ページはadminアプリに作るべき。移動して
> このテーブルはusersテーブルと同じ見た目にして

「あれと同じにして」が、ゼロから説明するより遥かに正確に伝わる。既存コードが最良のリファレンスです。

方向性が完全に間違った場合は、修正ではなくリバートします。

> 全部リバートした。リストビューをもっとシンプルにしたい。それだけ。他は触らないで。

悪い実装を段階的にパッチするのは、方向が間違った旅を微修正し続けるようなものです。git reset --hardで出発地に戻り、正しい地図を持って再出発した方が早い。「やり直す判断」は「直し続ける判断」より難しい。しかし、ほぼ常に正しい。 これはソフトウェア開発に限った話ではありません。

PLAN MODEが特に効果的な場面

1. 複数ファイルにまたがる変更

4ディレクトリに及ぶ変更を無計画に始めると、最初のファイルを変更している間に全体の整合性を見失います。これは人間のエンジニアでも起きる問題ですが、LLMは「目の前のファイル」に意識が引きずられやすい分、さらに深刻です。全体の変更計画を先に作ることで、木を見て森を見失う事態を防げます。

2. 不慣れなコードベースの調査

新しいプロジェクトにClaude Codeを投入するとき、最も怖いのは「善意の破壊」です。Claudeが「ここ直しておきますね」と既存の設計意図を無視した変更を加える。PLAN MODEなら、理解が不十分な段階で手を出すことが物理的にできない。CLAUDE.mdもRulesも未整備の段階では、このモードが事実上の必須です。

3. アーキテクチャの検討

「マイクロサービスに分割すべきか」「DBを分離すべきか」。この種の判断は、実装した後に間違いに気づいても手遅れです。取り返しのつかない判断ほど、実行前の検討に時間をかけるべきです。 当たり前のことですが、AIの実行速度が上がるほど、この当たり前を飛ばしたくなる。速く動けることと、正しい方向に動けることは、別の能力です。

4. コードレビュー

PRのレビューをClaudeに任せるとき、PLAN MODEなら「レビューコメントの生成」だけに留められます。レビューと修正を同時にやらせると、レビューの客観性が失われる。自分が書いたコードを自分でレビューしても、欠陥は見つからない。 これはClaudeも同じです。批評者と実装者は分ける。人間の組織でもそうするように。

5. CLAUDE.mdのリファクタリング自体

前述したCLAUDE.mdのリファクタリングプロンプトが、まさにPLAN MODEの実践例です。「まず計画を見せて」で計画を先に提示させ、確認してから実行する。設定の整備にPLAN MODEを使い、整備された設定がPLAN MODEの精度を上げる。好循環の入り口がここにあります。

使わないほうがいい場面

Anthropicの公式ベストプラクティスが明確に述べています。

Plan Mode is useful, but also adds overhead. For tasks where the scope is clear and the fix is small (like fixing a typo, adding a log line, or renaming a variable), ask Claude to do it directly.

ここで強調しておきたいのは、「使わない」という判断こそ最も高度なAIスキルであるということです。失敗するとわかっているタスクにエージェントを投入するのは、時間を燃やしているだけでなく、道具への信頼感を自ら毀損する行為でもある。「PLAN MODEで計画を立てたが、計画自体が意味をなさなかった」という経験は、次回以降PLAN MODEを使うモチベーションを確実に削る。道具への正確な不信は、盲目的な信頼より遥かに生産的です。

判断基準: 差分を1文で説明できるなら、計画は不要。

PLAN MODE推奨	直接実行推奨
複数ファイルのリファクタリング	タイポの修正
新機能の実装	ログ行の追加
アーキテクチャの変更	変数のリネーム
不慣れなコードの変更	単一ファイルの小修正

--dangerously-skip-permissionsの使い分けも同様に重要です。

YOLO推奨	YOLO非推奨
計画済みの機能実装	本番環境の操作
リンターの一括修正	CLAUDE.md未整備の段階
ボイラープレート生成	信頼できないコードの実行

設定の整備度と自律性の段階

ここまで読んで、一つの問いが浮かぶかもしれません。「で、結局どのモードを使えばいいのか」。答えは、今の設定の整備度による。

設定の整備度         推奨モード
──────────────────────────────────
未整備               Normal Mode（全承認）
  ↓                   + PLAN MODE で計画を人間が確認
CLAUDE.md整備済み     Auto-Accept Mode
  ↓                   + PLAN MODE で計画を立ててから
Rules整備済み         --dangerously-skip-permissions
  ↓                   + PLAN MODE → deny ルール → YOLO
Skills整備済み        完全自律実行
──────────────────────────────────

下に行くほど、Claudeへの信頼度が高くなり、任せられる範囲が広がる。 私自身の経験を振り返ると、この階段を1段ずつ登っていた。最初は毎回diffを目を皿にして確認していた。CLAUDE.mdを整備して1週間。Claudeの出力がルールを破らなくなった。その頃からAuto-Acceptが自然になった。さらにRulesを配置して2週間。plan.mdを渡せば計画通りに実装してくれることが分かった。初めて--dangerously-skip-permissionsを使ったとき、不安と解放感が同居していた。信頼は、検証の積み重ねの上にしか成立しない。 いきなりYOLOモードに飛ぶのは、初対面の人間にプロダクションのrootアクセスを渡すようなものです。

前回の記事のAgent Skillsとの関係で整理すると：

概念	Skills	PLAN MODE	Rules	パーミッション設定
制御するもの	知識	思考	行動制約	自律性
問い	何を知っているか	どう考えるか	何をしてはいけないか	どこまで任せるか
効果	出力の「質」向上	出力の「方向性」制御	出力の「安全性」確保	実行の「効率」向上

この4つが揃って初めて、信頼できる自律的な出力が得られます。 逆に言えば、どれか1つが欠けている状態でYOLOモードに突入するのは、安全装置を1つ外したまま機械を動かすのと同じです。動くかもしれない。しかし、何かが起きたとき止められない。

PLAN MODEの限界と現実

万能な道具はありません。PLAN MODEにも、使い込んで初めて見えてくる限界があります。

計画と実行の乖離

PLAN MODEで練り上げた計画でも、実装フェーズで計画通りにいかないことがある。LLMは確率的な生成モデルなので、同じ指示でも出力が揺れる。計画段階では「Aの方法で」と決めたのに、実装中に「Bの方が良さそうですね」と方針を変える。悪気はない。ただ、その時点のコンテキストで最適と判断しただけです。

対策は明確です。 plan.mdとして計画を外部化し、「plan.mdに従って実装せよ」と指示する。Todoリストに落とし込めば、さらに逸脱しにくくなる。計画が「頭の中」ではなく「ファイル」にあることが重要です。

コンテキストの消費

調査・計画フェーズ自体がコンテキストを消費する。これは避けられないトレードオフです。@でファイルを直接参照してトークンを節約する、/clearで新鮮なコンテキストから実装に入る、などの対策はあります。

ただし、私の実感では、調査・計画・実装を単一の長いセッションで通しても、50%超のコンテキスト消費でパフォーマンスが目に見えて劣化することは少ない。plan.mdがauto-compaction後も参照可能であることが大きい。計画の質が高ければ、コンテキスト消費のコストは十分にペイします。

`--dangerously-skip-permissions`の現実的なリスク

実際に踏んだ地雷を共有します。

Claudeがrmで想定外のファイルを削除した。 冷や汗が出た。→ denyルールでBash(rm -rf *)を禁止
テストが落ちているのに次のタスクに進んだ。 Claudeは「後で直します」と言って直さない。→ CLAUDE.mdに「テストが落ちたら修正してから次に進むこと」を明記
計画にない「改善」を勝手にやり始めた。 善意のリファクタリングが一番厄介。→ 「plan.mdにないタスクは実行しない」を指示に含める

すべてGitチェックポイントから回復できた。 これが唯一の救いでした。git reset --hardで戻せない環境でYOLOモードを使うべきではない。これは教訓ではなく、絶対条件です。

使い込んで見えてきたこと

重要度順に並べます。10個あるが、1番だけ覚えて帰ってくれればいい。

1. 土台を先に作る

土台のない自律は、ただの暴走だ。 PLAN MODEも--dangerously-skip-permissionsも、CLAUDE.mdとRulesという土台の上に成り立つ機能です。この順番を間違えると、すべてが裏目に出る。最初に設定を整備し、次にPLAN MODEで計画を立て、最後にYOLOで実行する。逆順は存在しません。ただし、土台を整備しても暴走は起きた。前述の「善意のリファクタリング」がそうです。土台があれば暴走しないのではなく、暴走を事後に検出できる。検出できるだけだ。止められるかどうかは、結局のところ人間がdiffを読む体力に依存している。

2. 「調査 → 計画 → 実装」を習慣にする

複数ファイルに影響する変更なら、必ず計画から始める。最初は「面倒だ、直接書いた方が早い」と感じます。私もそう思っていました。しかし手戻りの回数を数えてみると、計画を立てた方が結果的に速い。人間が何十年も前に学んだはずの教訓を、新しい道具を手にするたびに忘れる。私も忘れた。3回やり直して初めて思い出しました。

道具の価値は「不快の谷」の向こう側にしかない。 既に機能している自分のやり方を一時的に壊す覚悟がなければ、どんなツールも「微妙に不便な既存ワークフローの劣化版」で終わります。PLAN MODEも例外ではない。最初の1週間は確実に生産性が下がる。計画を書く時間がかかるし、アノテーションの勘所も分からない。しかし、この不快の谷を超えた先に、手戻りゼロの実装フェーズが待っている。習熟曲線の手前で撤退した人間の「PLAN MODEは面倒なだけ」という評価は、常に不正確です。

3. 調査では「深さ」を明示的に要求する

「深く」「徹底的に」がないと、Claudeは表面的な理解で「把握しました」と言います。人間のエンジニアに「ちゃんと読んだ？」と聞くのと同じ効果があります。

4. 「まだ実装しないで」を毎回付ける

計画フェーズのすべての指示の末尾に付ける。冗長に感じても、省略するとClaudeは実装を始めます。

5. 計画は必ず外部ファイルに残す

plan.mdとして永続化し、アノテーションサイクルでブラッシュアップする。チャットの中の計画は流れていく。ファイルに残った計画だけが、実装の羅針盤になる。

6. YOLOモードはGitチェックポイントとセットで

git add -A && git commit -m "checkpoint: before YOLO implementation"

これは「やった方がいい」ではなく「やらなければ使ってはいけない」です。

7. denyルールで取り返しのつかない操作を防ぐ

rm -rf、git push、curl。YOLOモードでも、これらだけは人間の判断を経るべきです。最近のモデルとエージェントはそういう異常行動がかなり減ったので安心してみている。

8. ルールは関心事で分離し、パスでスコープする

すべてのルールをCLAUDE.mdに詰め込まない。セキュリティ、テスト、Git規約、パフォーマンス——関心事ごとに.claude/rules/に分配する。さらに、paths: frontmatterで条件付きロードを設定すれば、Rustのソースコードを触るときだけセキュリティルールが読み込まれ、テストファイルを触るときだけテスト規約が読み込まれる。ルールが1ファイルに混在していると、Claudeにとっても人間にとっても見通しが悪くなります。

9. Extended Thinkingと組み合わせる

PLAN MODEで「セキュリティの影響について深く考えて」のように深い思考を促すと、計画の質が上がります。考える時間を与えれば、Claudeも考えます。

10. 曖昧さを意図的に使う場面も知る

「このファイルで何を改善できる？」とオープンに聞くことで、自分が見落としていた問題をClaudeが指摘してくれることがある。常に具体的な指示が最善とは限りません。

よくある失敗と対策

問題	原因	対策
計画が抽象的すぎる	調査フェーズが不十分	`@`で具体的なファイルを指定して読ませる
実装が計画から逸脱	コンテキストが薄れている	plan.mdをTodoリストに落とし込む
CLAUDE.mdが肥大化	整理していない	50行以下にリファクタリング。Rulesに分配
Rulesが効いていない	配置場所が間違っている	`/memory`でロード状況を確認
計画に時間をかけすぎ	分析麻痺	アノテーションは最大6回で打ち切る
YOLOで想定外の変更	ガードレール不足	CLAUDE.md + Rules + denyルール整備
YOLOでテスト未実行	指示が不十分	「テストを継続的に実行して」を指示に含める
YOLOでファイル削除	deny設定漏れ	`Bash(rm -rf *)`をdenyに追加
Rulesを無視した出力	Rulesは強制力がない	Linter + CIで機械的に検証する

まとめ

本記事で扱った機能を改めて並べます。

CLAUDE.md: プロジェクトのグローバルな文脈（50行以下に圧縮）
Rules: 関心事ごとのルール（.claude/rules/に分配）
commands: 手動ショートカット
Hooks: 自動実行
Subagents: 専門家の自動呼び出し
Skills: 専門知識の注入
PLAN MODE: 思考と実行の分離 ← 今回
パーミッション設定: 自律性のコントロール ← 今回

機能は増えました。しかし、核心は3つに集約されます。

1. 土台のない自律は、ただの暴走だ。 CLAUDE.mdを50行以下に圧縮し、関心事ごとのルールは.claude/rules/に分配する。ルールの品質がそのまま自律実行の安全性になる。整備が不十分なら、PLAN MODEで人間が毎回レビューするしかない。整備すれば、その手間が消える。設定への投資は、将来の自分の時間を買うことです。

2. 思考と実行は、混ぜるな。 PLAN MODEで調査し、計画を書き、アノテーションで研磨し、承認してから実装に入る。この順番を崩すと、出力が制御不能になる。実装中に「創造的な判断」が発生したら、それは計画の不備です。実装を止めて計画に戻る。実装は退屈であるべきだ。 ただし、本文で書いた通り、完全な退屈は達成できない。型を書く手が新しい問題を発見することがある。思考と実行を完全に分離することは、原理的にできない。できないが、分離しようとする努力に意味がある。

3. 信頼は、検証の積み重ねでしか成立しない。 Normal Mode → Auto-Accept → PLAN MODE → --dangerously-skip-permissions。いきなりYOLOモードに飛ぶのは、初対面の人間にプロダクションのrootアクセスを渡すのと同じです。設定を整備し、出力を確認し、また整備する。信頼は与えるものではなく、積み上げるものです。

そして、一つだけ付け加えます。委任はスキルの「局所的な萎縮」です。 手放したタスクの筋肉は確実に衰える。PLAN MODEで計画を立て、YOLO実行で実装を任せる。このワークフローを回すほど、自分の手でコードを書く時間は減る。それを許容するなら、自分が手動で残すタスクの選択は「何のエンジニアでありたいか」という自己定義の問題になります。特に基礎が未形成な段階では、楽をすることが将来の天井を決めてしまう。私はアーキテクチャの設計と、Rulesの整備と、diffの最終レビューだけは自分の手で続けると決めている。それ以外は——手放す覚悟を、毎回確認しています。

Anthropicの公式ベストプラクティスの結びの言葉が、これを的確に表現しています。

The patterns in this guide aren't set in stone. Pay attention to what works. When Claude produces great output, notice what you did. When Claude struggles, ask why.

冒頭で触れたOAuth2のリファクタリング。今なら、まずPLAN MODEで既存のセッション管理を深く調査し、plan.mdを書き、アノテーションを2回重ねてから実装に入る。あの3回のやり直しは、おそらく起きない。

Claude Codeが雑魚なんじゃない。設定してないだけです。CLAUDE.mdを整備し、Rulesを配置し、Linterで品質を機械的に担保し、計画を立て、適切なモードで動かす。そこまでやって初めて、Claudeは最後までやり切ってくれます。

ただ、どこまで設定すれば「十分」なのかは、正直まだ分からない。先週もRulesを1つ追加した。来週も何か足すだろう。この整備はいつ終わるのか。たぶん、終わらない。

今日から試せること

1. CLAUDE.mdのリファクタリング（15分）

Refactor @CLAUDE.md to minimize startup context.
Extract path-specific rules to .claude/rules/ (use paths: frontmatter for conditional loading),
multi-step workflows to .claude/skills/<skill-name>/SKILL.md (with name/description frontmatter),
reusable slash commands to .claude/commands/,
and specialized task delegation to .claude/agents/<agent>.md (with name/description/tools frontmatter).
Show extraction plan first, then create files,
reduce CLAUDE.md to <50 lines keeping only universal project context,
report before/after token metrics.

これ自体がPLAN MODEの実践例です。「まず計画を見せて」で計画を確認してから実行する。

2. Shift+Tab を2回押してPLAN MODEを体験する（30秒）

⏸ plan mode on と表示されたら成功。「このプロジェクトの全体像を教えて」と聞いてみてください。

3. 調査 → 計画 → 実装を1回通す（30分）

# Phase 1: PLAN MODEで調査
> src/[対象]を深く読み込んで。調査結果をresearch.mdに書いて。

# Phase 2: 計画
> [やりたいこと]の詳細なplan.mdを作成して。まだ実装しないで。

# Phase 3: アノテーション
> plan.mdにメモを追加した。すべてのメモに対応して。まだ実装しないで。

# Phase 4: 実装
> plan.mdの計画を実装して。完了したタスクにはチェックを入れて。

4. denyルールを設定してからYOLOモードを試す（10分）

git add -A && git commit -m "checkpoint"
claude --dangerously-skip-permissions
> plan.mdの計画を実装して