「いきなり実装」が事故を生む
Claude Code を使い始めた中小事業者の方から「途中で方向性が違うことに気づいて、何時間もかけた作業を捨てる羽目になった」というご相談を多くいただきます。
これは「いきなり実装」させているのが原因です。Anthropic は Claude Code に Plan モード という「実装前に計画だけ提示してユーザー承認を待つ」機能を公式に提供しています。本稿では、これを単なる安全弁ではなく 「壁打ち相手」として使い倒す ための実践手順を整理します。
※ 本稿は 2026 年 5 月時点の情報です。Claude Code の機能は更新されるため、最新仕様は公式ドキュメントでご確認ください。
Plan モードとは
Claude Code には パーミッションモード という概念があり、Plan モードはその一種です。Plan モードでは：
- AI は 計画だけを提示 し、ファイル編集・コマンド実行は行わない
- ユーザーが計画を承認した後、初めて実装に進む
- まずい計画なら実装前に修正できる
- トークン消費は計画提示分のみで、無駄な実装トークンを浪費しない
なぜ今これを押さえるべきか
- AI のミスは人間より速いスピードで広がる（既存ファイル上書き・git 操作・DB 操作）
- 実装後の手戻りはトークン消費 2〜3 倍
- 中小事業者は失敗できない（事業計画書・補助金申請書・本番環境）
「壁打ち」としての使い方
Plan モードは「やってもらう前の確認」だけでなく、設計の議論相手 として使うことに本質的価値があります。
仕組みの理解
| 段階 | 通常の Claude Code | Plan モード活用 |
|---|---|---|
| 指示 | 「X を実装して」 | 「X を実装する計画を立てて。論点も整理して」 |
| AI 動作 | 即座に実装開始 | 計画提示・論点提示で停止 |
| ユーザー | 結果を見て修正指示 | 計画段階で軌道修正 |
| 結果 | トークン消費大・手戻り多 | トークン消費少・1 発で精度高い |
動作の流れ
- Plan モードに切り替え: コマンドパレット or 設定で Plan モード有効化
- タスクを依頼: 「X を実装する計画を立てて」
- 計画レビュー: AI が手順・影響範囲・リスクを提示
- 議論: 「この手順だと Y が壊れない？」「Z の場合はどうする？」
- 承認: 計画 OK なら実装許可、修正必要なら計画修正
- 実装実行: 承認後に AI が実装
実装手順
Step 1: いつ Plan モードを使うかの境界線を決める
すべての作業で Plan モードを使うと作業効率が落ちます。Optiens では以下の境界線で運用しています。
Plan モード必須
- ファイル削除・
git push --force・rm系 - データベース destructive 操作（DROP / TRUNCATE / 大量 DELETE）
- 本番環境設定変更（Vercel・Supabase・Google Cloud）
- 事業計画書・補助金申請書・公開ページの修正
- 0 → 1 構築（新規ページ・新規サービス・新規コンポーネント）
Plan モード省略可
- 軽微な編集（文言修正・タイポ修正・コメント追加）
- ローカル環境の試行錯誤
- 既存テストの修正
Step 2: 効果的な Plan モード起動プロンプト
「X して」だけでなく、論点を引き出すプロンプトで質を上げます。
基本形
Plan モードで X を実装する計画を立てて。
以下を含めて：
- 実施手順（番号付き）
- 影響を受けるファイル・データ・設定
- 想定されるリスク 3 つ
- リスク回避の代替案設計議論用
Plan モードで X を設計して。
2〜3 案を比較表で提示して、それぞれの
- 工数
- 保守性
- 拡張性
- 想定リスク
を評価して。私が選んだ案で実装計画を詳細化して。既存コード改修用
Plan モードで X を改修したい。
まず現状の動作・依存関係を調査して、
どのファイルを変更すべきか・既存テストへの影響・
後方互換性の確保方針を提示して。Step 3: 計画レビュー時のチェックリスト
AI が出した計画を承認する前に、以下を確認します。
| 項目 | チェックポイント |
|---|---|
| 影響範囲 | 想定外のファイル・サービスに触れていないか |
| 不可逆性 | 元に戻せない操作（削除・上書き）が含まれないか |
| 出力形式 | 期待する形式と一致しているか |
| エラー処理 | 失敗時の挙動が定義されているか |
| 副作用 | 関連機能への影響が見落とされていないか |
Step 4: 計画修正の効果的な指示
不完全な計画を捨てて再依頼するより、部分修正で詰める 方が効率的です。
計画の Step 3 ですが、A の場合は処理が分岐するはずです。
分岐を追加して計画を更新してください。
それ以外の手順はそのままで OK です。Step 5: 実装承認とその後
承認は明示的に：「この計画で実装を進めてください」
実装中も AI が想定外の状況に遭遇した場合は、Plan モードに自動的に戻る のが理想ですが、そう動かないツールもあります。重要な操作の前に確認を求めるよう、CLAUDE.md などに記載しておくと安全です。
つまずきやすいポイント
1. Plan モードに切り替えたつもりが切り替わっていない
ツールによって切替方法が異なります。Cursor の Plan モード、Claude Code のパーミッションモード（Shift+Tab で循環切替・/plan プレフィックス・--permission-mode plan 起動オプション・.claude/settings.json の defaultMode 設定）、Cline の Plan / Act など、実装が違います。現在のモードを画面表示で必ず確認 してから依頼してください。
2. 計画の「曖昧な部分」を承認してしまう
「適切なエラー処理を追加する」「必要なテストを書く」のような曖昧な記述は危険です。具体的な処理内容・テストケースまで詰めてから 承認します。
3. 「Plan モードでお願い」と言うだけで安心してしまう
Plan モードで提示された計画が 本当に正しいか はユーザーが評価する必要があります。AI に「この計画で問題ない？」と聞いて「はい」と返ってきても、それは保証ではありません。
発展編：複雑な 0→1 構築での「Plan モード壁打ち」
新サービス・新機能の 0→1 構築では、Plan モードで 複数回の壁打ち を経て計画を熟成させます。
推奨フロー
- 概念整理: 「X というサービスを作りたい。要件・ユーザー像・成功条件を整理して」
- アーキテクチャ提案: 「上記要件で 3 つのアーキテクチャ案を比較表で」
- 詳細設計: 「選んだ案で、データモデル・API 設計・UI 構成を提案」
- 実装計画: 「実装手順を Step 1〜N で提示。各 Step の見積も含めて」
- リスク評価: 「上記計画のリスク 5 つ・代替案・回避策を整理」
- 実装承認: 計画全体が固まったら実装許可
このフローを踏むと、実装で大きな手戻りが起きません。Optiens 自社サービス（無料 AI 活用診断・小説推敲ツール等）の構築でも同フローを採用しています。
Optiens の取り組み
Optiens では CLAUDE.md で Plan モード必須の境界線を明文化し、社内エージェント体制（COO・CMO・CTO・CFO・CSO・CRO）の指示分配でも Plan モードを標準フローに組み込んでいます。重要操作前に必ず計画提示・承認を経るため、これまでファイル誤削除・本番環境への誤適用などの事故ゼロで運用できています。
御社で Claude Code の業務導入を検討されている場合、本稿の Plan モード活用ルールを 社内向け運用ガイドライン として整備する 無料 AI 活用診断 をご用意しています。具体的な CLAUDE.md テンプレート・社内研修資料の作成は 詳細レポート（¥5,500税込） でお届けします。
まとめ
- Plan モードは「実装前の安全弁」+「設計の議論相手」
- 全作業ではなく境界線を引く（削除・本番・公開資料は必須、軽微編集は省略可）
- プロンプトに「リスク 3 つ」「代替案」を含めると質が上がる
- 計画の曖昧な部分は承認前に詰める
- 0→1 構築では 5〜6 回の壁打ちで計画を熟成させる
関連記事:
出典:
- Anthropic Claude Code 公式ドキュメント（permissions / plan mode）: https://code.claude.com/docs/en/permission-modes
- Optiens 自社運用知見（CLAUDE.md での Plan モード境界線運用）