「計画」と「実行」を分ける──Claude Codeをうまく使うための考え方

Spectral Blog | AI導入支援の現場から

---

1. イントロダクション

AIを使ってコードを書いてもらう、という体験をしたことがある方は増えてきました。でも、「思ったとおりに動かない」「途中で迷子になる」「修正を頼むたびに別の場所が壊れる」──そんな経験をした方も多いのではないでしょうか。

Anthropicが提供するAIツール「Claude Code」は、コードの作成や修正をサポートしてくれる開発者向けのツールです。最近、このツールを使いこなしている人たちの間で、ひとつの考え方が注目を集めています。それが「計画フェーズ」と「実行フェーズ」を意識的に分ける、というアプローチです。

料理に例えるなら、「何を作るか考える時間」と「実際に調理する時間」をきちんと分けるようなイメージです。この小さな工夫が、AIとの作業をぐっとスムーズにしてくれます。

この記事では、専門知識がなくても理解できるよう、この考え方の背景・意味・実践方法を丁寧に解説していきます。

---

2. 基礎知識・用語解説

まず、この記事を読むうえで知っておきたい言葉をいくつか整理しておきましょう。

Claude Code とは？

Anthropicという会社が開発したAI「Claude」を、プログラミング作業に特化して使えるようにしたツールです。ターミナル（コンピューターに命令を文字で入力する画面）から直接AIに話しかけながら、コードの作成・修正・確認などを行えます。ChatGPTのようなチャット形式のAIと似ていますが、実際のファイルを読んだり書いたりする機能が備わっているのが特徴です。

「計画フェーズ」と「実行フェーズ」

この記事の核心となる概念です。

• 計画フェーズ（Planning）「何をどう作るか」を考え、設計する段階。コードはまだ書きません。
• 実行フェーズ（Execution）計画にもとづいて、実際にコードを書いたり変更したりする段階。

この2つを混ぜてしまうと、AIが「考えながら書く」状態になり、途中で方針がぶれたり、一貫性のない結果が出やすくなります。

コンテキスト（文脈）

AIは会話の流れ全体を「コンテキスト」として保持しながら動きます。会話が長くなるほど、AIが参照しなければならない情報量が増え、精度が落ちやすくなります。計画と実行を分けることは、このコンテキストを整理する意味でも有効です。

エージェントモード

AIが自分で判断しながら複数の作業を連続して行う動き方を「エージェントモード」と呼びます。Claude Codeはこのモードで動くことが多く、だからこそ最初の方針設定（計画）が重要になります。

---

3. トレンド分析

開発者コミュニティで広がる「計画先行」の考え方

Hacker NewsやRedditのプログラミング関連コミュニティでは、ここ数日、Claude Codeの使い方に関する議論が活発に行われています。特に注目されているのが、「AIに何かを作らせる前に、まず計画を立てさせる」という実践的なアプローチです。

あるエンジニアがHacker Newsに投稿した体験談が多くの共感を集めました。要約すると、「Claude Codeに直接『このアプリを作って』と頼むと、途中で方針が変わったり、最初の設計が崩れていったりする。でも、最初に『どう作るか計画を立ててください、コードは書かないで』と伝えてから始めると、結果が安定する」というものです。

なぜ「計画と実行の分離」が効くのか

これには、AIの動き方に関する理由があります。

Claude Codeのようなエージェント型AIは、与えられた指示をもとに自律的に判断しながら作業を進めます。この「自律的な判断」は便利な反面、最初の方向性が曖昧だと、作業が進むにつれて少しずつ意図からずれていくことがあります。

人間のチームで言えば、「とりあえず作り始めて、後で調整しよう」という進め方に近いです。小さな作業ならそれでもうまくいきますが、規模が大きくなると後から修正するコストが高くなります。

「PLAN モード」という実践

一部のユーザーは、Claude Codeとの会話を明示的に2つのセッションに分けています。

第1セッション（計画専用）：「コードは一切書かないで。まず、この機能をどう実装するか、考え方と手順だけを教えて」と伝える。AIが出した計画を確認し、必要であれば修正する。

第2セッション（実行専用）：確定した計画を新しい会話に貼り付け、「この計画にしたがってコードを書いてください」と依頼する。

この方法のメリットは、計画の段階でAIの思考を「見える化」できる点です。「あ、この部分の理解がずれている」と気づいたら、コードが書かれる前に修正できます。

Redditでの反応

Redditのr/ClaudeAIスレッドでも同様の議論が見られます。「AIは賢いけれど、方向性を与えないと自分で判断しすぎる」「計画を先に出してもらうと、自分もプロジェクトの全体像を把握しやすい」といったコメントが支持を集めています。

特に興味深いのは、「これはAIだけの話ではなく、人間のエンジニアに仕事を頼むときも同じだ」という指摘です。誰かに作業を依頼するとき、最初に認識を合わせることの大切さは、AIでも人間でも変わらないようです。

---

4. Spectralの見解

「ツールの使い方」より「考え方」が大切

Spectralでは、企業へのAI導入支援を行うなかで、ツールの機能よりも「どう使うか」という思考の枠組みが成果を左右することを繰り返し目にしてきました。Claude Codeにおける「計画と実行の分離」は、まさにその好例だと感じています。

Claude Codeは確かに高性能なツールです。でも、高性能であることと、使いこなせることは別の話です。車が速くても、目的地を決めずに走り出せば迷子になるように、AIも方向性が定まっていなければ、その能力を活かしきれません。

「任せすぎ」と「管理しすぎ」の間

AIを使う際によくある2つの極端があります。

ひとつは「全部任せる」。AIに丸投げして、出てきた結果をそのまま使う。これは時間の節約になるように見えて、品質が安定しません。

もうひとつは「細かく管理しすぎる」。一行一行チェックして、細かく指示を出し続ける。これはAIを使う意味が薄れてしまいます。

「計画と実行の分離」は、この2つの中間にある、ちょうどよいバランスを見つけるための方法です。計画段階でしっかり方向性を確認し、実行段階では信頼して任せる。この切り替えが、AIとの協働をうまく機能させます。

初学者にこそ有効な理由

この考え方は、実はプログラミングの知識がない方にこそ有効だとSpectralは考えています。

技術的な知識がないと、AIが出したコードの良し悪しを判断するのは難しいです。でも、「計画」の段階であれば、「この手順で合っているか」「この方向性で自分がやりたいことと合っているか」を、技術的な知識がなくても確認できます。

計画を言語化してもらうことで、AIが何をしようとしているかが「見える」状態になります。これは、AIとの作業における透明性を高める、とても実用的な工夫です。

---

5. 実践的アプローチ

ステップ1：まず「計画だけ」を依頼する

Claude Codeを使い始めるとき、最初のメッセージに一言加えるだけで大きく変わります。

通常の頼み方：

「ユーザーがログインできる機能を作ってください」

計画先行の頼み方：

「ユーザーがログインできる機能を作りたいです。まず、どのような手順で実装するか計画だけ教えてください。コードはまだ書かなくて大丈夫です」

この一言「コードはまだ書かなくて大丈夫です」が重要です。AIは指示に忠実なので、明示的に伝えることで計画フェーズに集中してくれます。

ステップ2：計画を確認・修正する

AIが計画を出してきたら、以下の点を確認してみましょう。

• やりたいことと合っているか「この手順で自分がイメージしていたものができそうか」を確認します。技術的な詳細がわからなくても、「なぜこの手順が必要ですか？」と聞けば説明してもらえます。

• 抜けている点はないか「このほかに考慮すべきことはありますか？」と聞くと、AIが見落としを自己チェックしてくれることがあります。

• 順番は適切か「この手順を先にやる理由はなんですか？」と問いかけることで、計画の根拠を確認できます。

修正が必要であれば、この段階で調整します。「3番の手順は不要です」「セキュリティに関する考慮を追加してください」など、計画レベルの修正はコードの修正より格段に簡単です。

ステップ3：計画を固定して実行を依頼する

計画に納得できたら、新しい会話（セッション）を始めることをお勧めします。理由は、計画段階の長い会話の流れをリセットすることで、AIが実行に集中しやすくなるためです。

新しい会話に計画をコピー＆ペーストして、こう伝えます。

「以下の計画にしたがって、実装を進めてください。計画から外れる場合は、先に確認してください」

「計画から外れる場合は先に確認」という一文を加えることで、AIが勝手に方針を変えることを防げます。

ステップ4：実行中の確認ポイントを決める

大きな作業の場合、実行を一気に進めるのではなく、区切りを設けると安心です。

「まず最初の2ステップだけ実装してください。確認してから続きをお願いします」

このように段階的に進めることで、途中で方向性がずれていても早めに気づけます。

よくある失敗パターンと対処法

**失敗パターン1：計画が