同じClaude Code、フェーズで意味が反転する — 探索/実装/運用/保守の使い分け

Claude Codeをずっと同じ使い方で回し続けていませんか。Plan Modeはいつも「実装計画を立てる」ため、Auto Modeは「手を動かしたくないとき」に使う——そういう固定的なイメージがあると、フェーズが変わったときに逆効果になることがあります。

私がblog-agentsプロジェクトを4月から運用してきてわかったのは、同じ機能でも「いまどのフェーズにいるか」によって使う意味がまったく変わるということです。Plan Modeは探索期には選択肢を広げるために使い、保守期には変更範囲を封じ込めるために使う。同じコマンドなのに、目的が正反対になります。

この記事では探索 → 実装 → 運用 → 保守の4フェーズを縦軸に、各フェーズで Claude Code の主戦力となる機能とその使い方の逆転を整理します。

同じPlan Mode、フェーズで使う理由が真逆になる

全体像を表にまとめました。

注目してほしいのは「Plan Mode」の列です。探索期には「発散」、実装期には「収束」、保守期には「影響評価」と、すべてのフェーズで登場するにもかかわらず、目的がまったく違います。「Plan Modeを使えばいい」という発想では、このズレに気づけません。

Auto Modeも同様です。探索期には極力避け、実装期には積極的に使う。次のセクションから各フェーズの詳細を見ていきます。

探索期 — 発散としてのClaude

探索期にやるべきことは「正解を決めること」ではなく「選択肢を増やすこと」です。アーキテクチャの候補を並べ、競合を比較し、PoCコードで仮説を素早く検証する。

このフェーズで Plan Mode（Shift+Tab）を使うときの目的は「実装計画を立てる」ではありません。「この設計にはどんな選択肢があるか」を Claude に問い、思考を横に広げることが目的です。出てきた計画に「これしかない」という論調が混じっていたら、まだ問いが粗い合図です。

重要な設計分岐では ultrathink キーワードをプロンプトに添えると、そのターンだけ深い推論を引き出すin-context指示が追加されます（公式に認識されているキーワードです。セッション全体のエフォートレベル設定自体は変わりません）。また、調査やPoC実行を Subagent に任せると、メインのコンテキストウィンドウを汚さずに探索を並走させられます。

このフェーズで避けるべきは Hooks と Auto Mode の早期導入です。自動化は制約になります。「なんとなく動いた」PoCコードを自動フォーマットや自動コミットで固めてしまうと、捨てにくくなる。探索期のコードは捨てる前提で書く、という姿勢が崩れます。

実装期 — 収束としてのClaude

探索期で選択肢を絞ったら、実装期は「決めたことを精度よく実現する」フェーズです。ここで Plan Mode の役割が変わります。探索期の発散を受け取り、1つの実装計画に収束させる。「選択肢の比較」ではなく「作業工程の具体化」が目的です。

実装期から Auto Mode を積極的に使えるようになります。スコープが定まっているということは、Claude の判断が外れても修正可能な範囲が限られているということ。承認疲れを減らし、細かい実装タスクを流すのに向いています。Auto Mode の使い方の詳細はこちらの記事を参照してください。

Hooks の PostToolUse も実装期から導入します。ファイル編集後に自動でフォーマッターやlintを走らせる設定を入れておくと、「動いてはいるけどコードが汚い」状態を防げます。具体的な Hooks の設定例はこの記事にまとめています。

実装期の罠は探索をスキップして直行することです。Plan Mode で計画を立てずに Auto Mode を動かすと「とりあえず動く」コードが量産されます。後から読み返すと誰が書いたか分からないコードの山、という状況は珍しくありません。

運用期 — 監視・自動化としてのClaude

サービスが動き出した運用期では、Claude の使い方が「作る」から「守る」へ反転します。コードを書く場面より、アラートに対応したり定期ジョブを確認したりする場面が増えます。

このフェーズで中心になるのが /goal コマンドです。「すべてのアラートが解消されるまで継続して対応する」という完了条件をセットすることで、Claude がゴールに向かって自律的に処理を続けます。/goal の詳しい使い方はこちらを参照してください。

Channels（Discord / Telegram連携）を組み合わせると、外出先からスマートフォンで状況確認や指示出しができます。私自身、夜間のアラート対応をDiscordから操作する運用を入れてから、PCを開かずに対応できるケースが増えました。設定方法はDiscord連携記事にまとめています。

運用期の注意点は、障害対応に Auto Mode を使わないことです。想定外のリカバリ操作が走るリスクがあります。また Hooks の Stop フックで監査ログを残す設定がないと、「何が実行されたか」を後追いできません。/goal を回すときは Hooks とセットにしてほしい。

保守期 — 影響評価としてのClaude

レガシーコードの読解、依存ライブラリの更新、段階的なリファクタリング。保守期の最大のリスクは「直した部分以外が壊れる」ことです。ここで Plan Mode の役割がもう一度変わります。

探索期は「選択肢を広げる」、実装期は「計画を立てる」でした。保守期の Plan Mode は「この変更で何が壊れるか」を先に計算することが目的です。変えない範囲を確認し、影響範囲を絞り込む。発散ではなく封じ込めです。

コードベースが大きい場合は 1M Context（Opus 4.7）でモノレポ全体を一括読み込みし、依存関係を俯瞰してから変更箇所を絞ります。ただし、コンテキストウィンドウを満杯にすると精度が落ちるため、使用率は70〜80%を意識するのが安全です。1M Context の使い方はこちらの記事で詳しく扱っています。

並行して複数のリファクタタスクを進めるなら Worktree と Subagent の組み合わせが有効です。ファイルの競合を防ぎながら並列で作業を進められます。複数セッションの管理はAgent View記事を参照してください。

4フェーズ共通の鉄則 — blog-agents実例マッピング

フェーズ別の使い分けを踏まえて、どのフェーズにも共通する考え方を2点書いておきます。

フェーズが変わったタイミングで、設定を一度見直す。探索期に組んだ Hooks が実装期に邪魔になるケースは実際にある。「なぜこの設定を入れているのか」を定期的に確認する癖をつけておくと、後で詰まりにくい。

knowledge/ ディレクトリはフェーズをまたいで効いてくる。探索期の設計検討メモは、保守期にリファクタの背景を読み返すときに役立つ。判断の文脈を残す場所として意識的に使ってほしい。

blog-agents プロジェクト自体も、この4フェーズをたどってきました。4月上旬の探索期では「マルチエージェントで記事自動生成できるか」のPoCを Plan Mode で設計案を広げながら進めました。4月中旬〜下旬の実装期では各エージェント・スキル・CLAUDE.mdの実装に集中し、Hooks はまだ入れていませんでした。5月に入って運用期になると21本の記事を公開しながら、Hooks（permission-loggerなど）と Discord Channels を導入しました。そして直近の保守期では knowledge/ が3,000行を超え、CLAUDE.md の整理やスキル設計判断の言語化に取り組んでいます。

こうして書き出してみると、自分でも「フェーズごとに使い方がここまで変わっていたか」と気づく。

Claude Code を使い始めたときの設定やスタイルのまま走り続けると、どこかでズレが生じる。「いま自分はどのフェーズにいるか」を意識して、使い方を切り替えてみてほしい。機能の数を増やすより、フェーズに合った使い方をする方が、手戻りは少なくなる。