Claude Codeで成果を出すカギは「すぐにコードを書かせない」ことです。
結論: Claude Codeの生産性を最大化するカギは「プランニングと実行の分離」であり、research.md → plan.md → アノテーション → 実装の4フェーズワークフローが最も効果的である。
- リサーチ→プラン→アノテーション→実装の4フェーズに分離することで、手戻りが激減する
- Hacker Newsで717ポイント・454コメントを獲得した話題のワークフローを完全解説
- Cursor・GitHub Copilotとの使い分けも含め、日本企業がすぐ実践できるアクションを提示
対象読者：Claude Codeを導入済み／検討中のエンジニア・開発マネージャー・CTO
今日やること → Claude Codeで次のタスクに取り組む前に、まず「research.md」を作成させてみてください。
リード文
「AIに任せたのに、結局やり直し」――そんな経験、ありませんか？
2026年2月、CloudflareのエンジニアリングリードであるBoris Tane氏が公開したブログ記事「How I Use Claude Code」がHacker Newsで717ポイントを獲得し、454件ものコメントが寄せられる大きな話題になっています。
記事の核心はシンプルです。「Claude Codeにコードを書かせる前に、必ず書面のプランをレビュー・承認する」というもの。計画（プランニング）と実行（コーディング）を明確に分離するこのワークフローが、AI支援開発の生産性を劇的に変えるというんですね。
今回は、この話題の手法を徹底的に解説します。Claude Codeの使い方を模索している方、AIコーディングツールの効果を最大化したい方は、ぜひ最後まで読んでみてください。
何が起きたのか ― Boris Tane氏の「3フェーズ+アノテーション」ワークフロー
Tane氏が提唱するワークフローの根幹は、「計画と実行の分離」です。彼はこう述べています。
「Claude Codeにコードを書かせるのは、書面のプランをレビューして承認してからだけ。この計画と実行の分離が、私がやっている中で最も重要なことです」
具体的には、以下の4つのフェーズに分かれています。
フェーズ1：リサーチ（Research）
すべてのプロジェクトは、まずコードベースの深い分析からスタートします。ここがポイントなんですが、Tane氏はClaude Codeに対して「deeply」「in great details」「intricacies」といった強調語を意図的に使っています。
なぜかというと、AIは指示が曖昧だと表面的なスキミングで済ませてしまうからなんですね。「詳しく調べて」ではなく「深く、細部まで、複雑な部分も含めて調べて」と指示することで、調査の質が段違いに変わります。
さらに重要なのが、調査結果を口頭の要約ではなく、`research.md`というマークダウンファイルに書き出させること。なぜファイルにするかというと、後からレビューできる「成果物」になるからです。チャットの中に埋もれた説明は見返しにくいですが、ファイルならエディタで開いて確認できますよね。
このフェーズが防ぐのは、AI支援開発における最もコストの高い失敗パターン――「単独では動くけど、既存のキャッシュ層やORM規約、既存ロジックを無視した実装」です。
フェーズ2：プランニング（Planning）
リサーチの内容を検証した後、Tane氏は詳細な実装プランの作成を依頼します。このプランには以下が含まれます。
- 各ステップの説明とコードスニペット
- 対象ファイルのパス
- トレードオフの考察
- 代替案の検討
ここで注目すべきは、Tane氏がClaude Codeの組み込みプランモード（Shift+Tab×2で切り替え）を使わず、カスタムのマークダウンファイルで管理している点です。理由は、エディタで自由に編集できる方が「完全な編集権」を持てるから。組み込みモードだと、Claude側の判断でプランが変更されてしまう可能性がありますが、マークダウンファイルなら人間が完全にコントロールできます。
もうひとつの効果的なテクニックとして、類似機能を持つオープンソースプロジェクトのリファレンス実装を提供する方法があります。「こんな感じで実装してほしい」と具体的なパターンを見せることで、AIの出力品質が大きく向上するんですね。
フェーズ2.5：アノテーションサイクル（最大の独自貢献）
Tane氏のワークフローで最も革新的な部分がこのアノテーションサイクルです。通常のAI開発では「指示→出力→修正」のチャットベースのやり取りになりますが、Tane氏は全く異なるアプローチを取っています。
- Claude Codeが
plan.mdを生成する - Tane氏がエディタで開き、インラインでアノテーション（注釈）を追記する
- 注釈で前提の訂正、アプローチの却下、ドメイン制約の追加などを行う
- 修正したドキュメントをClaude Codeに戻す（「まだ実装するな」と明記）
- このサイクルを1〜6回繰り返す
具体的なアノテーションの例を挙げると、こんな感じです。
- 「マイグレーションはdrizzle:generateを使え、生SQLは不可」
- 「このセクションは丸ごと削除、キャッシュは不要」
- 「このインターフェースは変更するな、既存のAPI契約を壊す」
この「共有ドキュメントへのインライン編集」というアプローチは、チャットベースの指示よりもはるかに精密で、文脈を保ったフィードバックを可能にします。チャットだと「3つ目の項目の代わりに…」と参照が曖昧になりがちですが、ドキュメント上なら該当箇所に直接コメントを書けますよね。
そして特に重要なのが、「don’t implement yet（まだ実装するな）」というガードレールです。これを明記しないと、Claude Codeはプランが「十分良い」と判断した瞬間にコードを書き始めてしまいます。
フェーズ3：実装（Implementation）
プランが完成したら、Tane氏は以下のような標準化されたプロンプトで実装を開始します。
「すべて実装しろ。タスクやフェーズが完了したら、プランドキュメント上で完了マークをつけろ。すべてのタスクとフェーズが完了するまで止まるな。不要なコメントやJSDocを追加するな、any型やunknown型を使うな。継続的にtypecheckを実行して、新しい問題を導入していないことを確認しろ」
このプロンプトには、いくつもの重要な指示が凝縮されています。
- 中断するな ― 「ここまでで一旦確認しますか？」と聞かせない
- プランを進捗表として使え ― どこまで終わったかが一目でわかる
- 余計なものを追加するな ― 勝手にJSDocやコメントを生成させない
- 型安全を保て ― any型の逃げを許さない
- 継続的に検証しろ ― 壊れたまま先に進ませない
実装中の修正指示は、計画フェーズとは打って変わって短い一文で済みます。Claude Codeがセッション全体のコンテキストを保持しているため、「ここのバリデーションを修正して」だけで伝わるんですね。ビジュアルの問題ならスクリーンショットを添付するだけ。
もし実装が完全に間違った方向に進んだ場合は、部分的な修正を試みるのではなく、リバートしてスコープを再定義するのがTane氏のポリシーです。中途半端な修正の積み重ねは、技術的負債の温床になりますからね。
なぜ重要か ― AI支援開発の「使い方問題」が本質になった時代
2026年現在、AIコーディングツールの性能競争は一段落し、「どう使うか」が差別化の本質になってきました。ここが非常に重要なポイントなんです。
AIコーディングツールの現在地
主要3ツールの立ち位置を整理しておきましょう。
| ツール | 強み | 最適な用途 | 月額 |
|---|---|---|---|
| GitHub Copilot | 最速のインライン補完、GitHub統合 | 日常的なコーディング高速化 | $19/月〜 |
| Cursor | プロジェクト全体のコンテキスト理解 | 大規模プロジェクトのマルチファイル編集 | $20/月〜 |
| Claude Code | 自律的な長時間タスク、複雑なリファクタリング | アーキテクチャレベルの変更、ゼロからの実装 | Pro $20/月、Max $100/月〜 |
GitHub Copilotがインラインの「コード補完」に強く、Cursorが「IDE内でのマルチファイル編集」に優れるのに対し、Claude Codeは「ターミナルベースで複雑な自律タスクを実行する」という独自のポジションを確立しています。
つまり、3つのツールは競合というより、異なるレイヤーの課題を解決しているんですね。朝のコーディングにはCursorのマルチファイル認識を、ちょっとした修正にはCopilotのインライン補完を、そして本格的なリファクタリングやアーキテクチャ変更にはClaude Codeを――という使い分けが理にかなっています。
「プランニングと実行の分離」が重要な3つの理由
1. トークンの無駄遣いを防ぐ
Claude Codeの使用量はトークン消費に直結します。計画なしにいきなりコードを生成させると、方向が間違っていた場合のやり直しコストが膨大になります。事前に計画を固めることで、「一発で正しい方向に進む」確率が大幅に上がるんです。
2. AIの「見えない前提」を事前に炙り出す
Hacker Newsのコメントでも指摘されていましたが、このワークフローの本質的な価値は「AIがコードに固める前に、見えない前提や思い込みを表面化させる」ことにあります。アーキテクチャの制約、既存のコーディング規約、パフォーマンス要件――これらをリサーチフェーズで事前に把握させることで、「動くけど使えない」コードの発生を防げます。
3. 人間の判断をスケーラブルに注入する
チャットベースの微修正を何十回も繰り返す代わりに、計画段階で数回のアノテーションサイクルを回すだけで、人間の判断を効率的にAIの実装に反映できます。フェーズゲートでのレビューは、数百のマイクロ判断を数回の意味あるレビューに集約するアプローチなんです。
Claude Codeの最新機能がワークフローを後押し
2026年に入ってからのClaude Codeのアップデートも、このワークフローとの相性が抜群です。
- サブエージェント ― 最大7つの同時操作が可能になり、リサーチフェーズの並列調査が高速化
- フック（Hooks） ― 設定変更時にイベント発火する仕組みが追加され、プラン文書の自動管理に活用可能
- CLAUDE.md ― プロジェクトルートに置く設定ファイルで、コーディング規約やアーキテクチャ決定を永続的に記録できる
- MCP（Model Context Protocol） ― 外部ツールとの統合が進み、型チェッカーやリンターとの連携が容易に
- ワークツリー分離 ―
--worktreeフラグで隔離されたgitワークツリーでの作業が可能に
特にCLAUDE.mdファイルは、Tane氏のワークフローとの相乗効果が高いです。プロジェクトごとのルールを一度設定しておけば、毎セッション冒頭で読み込まれるため、リサーチフェーズの精度が最初から高くなります。
賛否両論 ― Hacker Newsコミュニティの反応
717ポイント・454コメントという数字が示すとおり、この記事は大きな議論を巻き起こしました。肯定的な意見と懐疑的な意見を整理してみましょう。
肯定的な意見
1. 「実際にビジネス価値を生んでいる」
複数のエンジニアが、このワークフローを実践することで、以前はチームで数週間かかっていた複雑なプロジェクトを一人で数日で完了できたと報告しています。計画フェーズへの投資が、実装フェーズの高速化として何倍にもなって返ってくるということですね。
2. 「初心者のガイドとして価値がある」
あるコメンターは、「新しさがあるかどうかは別として、構造化されたワークフローを文書化してくれることは、AIコーディングツールを使い始める人の試行錯誤を大幅に減らす」と評価しています。
3. 「プランモードの組み込み機能より優れている」
Claude Codeの組み込みプランモード（Shift+Tab）ではなく、カスタムのマークダウンファイルを使う点が高く評価されています。人間が完全な編集権を持つことで、AIに振り回されない開発が可能になるからです。
4. 「コンテキスト圧縮に強い」
Claude Codeのコンテキストウィンドウが埋まってくると、古い会話が「圧縮」されます。しかし、プランをマークダウンファイルに保存しておけば、圧縮の影響を受けません。ToDo項目も持続するため、長時間の自律セッションでも進捗が失われないんです。
5. 「マルチエージェント構成への拡張性がある」
計画・実装・レビューをそれぞれ別のエージェントに割り当てるマルチエージェント構成への応用が示唆されています。計画と実行の分離は、そのまま「エージェントの責務分離」に発展できるというわけです。
懐疑的な意見
1. 「革新的ではない。経験あるエンジニアなら当然のこと」
最も多かった反論がこれです。Hacker Newsユーザーのchaboud氏は「これは基本的なソフトウェアマネジメントのプラクティスであって、LLMを『信頼できない新人』として扱っているだけ」と指摘しています。つまり、明確なドキュメンテーションとグラウンディングを要求するのは、新人エンジニアへの指導と同じだ、と。
2. 「計画ドキュメントのオーバーヘッドが大きすぎる」
あるコメンターは「3万行のコードに対して10万行の計画ドキュメント」という事例を懸念として挙げています。ただし、これに対しては「イテレーティブに進めるもので、一度に全部読むわけではない」という反論もありました。
3. 「プロンプトエンジニアリングは迷信かもしれない」
「deeply」「in great details」といった強調語がLLMの出力を改善するという主張に対して、「統計的な裏付けがない」という批判があります。学術研究では「emotion prompting」に一定の効果が認められていますが、再現性のある検証は不十分だという立場です。
4. 「記事自体がAI生成の可能性がある」
複数のコメンターが、記事の文体に「AI生成特有のパターン」を指摘しています。「計画と実行の分離を説くのに、記事執筆はAIに丸投げしていないか」という皮肉ですね。
5. 「実験先行のアプローチの方が有効な場面もある」
すべてのタスクで詳細な計画が必要なわけではなく、プロトタイプを先に作って前提を検証するアプローチの方が適している場面もあるという指摘です。特にUI開発や探索的なプログラミングでは、「まず動かしてみる」方が効率的なことがありますよね。
バランスの取れた見解
結局のところ、このワークフローは「万能な銀の弾丸」ではなく、「複雑なタスクに対する有効なフレームワーク」と理解するのが適切でしょう。
小さなバグ修正に6回のアノテーションサイクルを回す必要はありませんし、アーキテクチャレベルの変更にいきなりコード生成を始めるのも危険です。タスクの複雑さに応じて計画の深さを調整するのが、実践的なアプローチだと思います。
日本企業への影響 ― 「AI導入」から「AI活用の高度化」へ
日本でもAIコーディングツールの導入は急速に進んでいます。しかし、「導入した」と「成果を出している」の間には大きなギャップがあるのが現状です。
先行事例：エムスリーの全社導入
医療系テック企業のエムスリーでは、Claude Codeの業務における無制限使用をエンジニアに解禁しています。ほぼすべてのエンジニアが日常的にClaude Codeを利用し、AIレビューやチーム内でのスキル（プラグイン）共有が進んでいるとのことです。
こうした先進的な企業が実践しているのは、まさにTane氏が提唱するような「構造化されたワークフロー」なんですね。ツールを入れるだけでなく、使い方のベストプラクティスを組織として確立する段階に入っています。
日本企業が直面する3つの課題
1. 「AI=自動化」という誤解
多くの日本企業では、AIコーディングツールを「人手を減らすための自動化ツール」と捉えがちです。しかし実際には、「人間の判断をスケールさせるための増幅器」です。Tane氏のワークフローが示すように、人間の関与は減るどころか、より高レベルな判断（アーキテクチャ設計、トレードオフの選択）に集中する形で重要度が増しています。
2. ワークフローの属人化
Claude Codeの使い方が個人の「暗黙知」にとどまっているケースが多いです。「あの人は上手く使えているけど、他のメンバーは…」という状況ですね。CLAUDE.mdファイルを活用してプロジェクトごとのルールを明文化し、チーム全体で共有する仕組みが必要です。
3. コスト管理
Claude Code Maxプラン（$100/月〜）をチーム全体に展開するとなると、コストは無視できません。プランニングと実行の分離は、トークンの無駄遣いを減らす効果もあるため、コスト最適化の観点からも合理的です。計画なしの試行錯誤でトークンを浪費するより、計画に投資して一発で正しい実装を得る方が、結果的に安上がりになります。
日本の開発文化との親和性
実は、Tane氏のワークフローは日本の開発文化と相性が良い面があります。
日本のソフトウェア開発では「設計書を書いてからコーディングする」という文化が根付いている企業が多いですよね。ウォーターフォール開発の弊害はさておき、「計画を重視する」マインドセット自体は、AI支援開発でもそのまま活かせます。
ただし、従来の「設計書」と違うのは、アノテーションサイクルという高速フィードバックループがある点です。半年かけて設計書を作るのではなく、数分〜数十分のサイクルを数回回すだけ。このスピード感を組織に浸透させることが、日本企業にとってのチャレンジであり、チャンスでもあります。
企業がとるべきアクション ― 明日から始められる5つの施策
アクション1：CLAUDE.mdファイルを全プロジェクトに導入する
所要時間：10分/プロジェクト
CLAUDE.mdは、Claude Codeがセッション開始時に自動で読み込むプロジェクト設定ファイルです。以下の内容を記載しておきましょう。
- コーディング規約（命名規則、ファイル構成）
- アーキテクチャ上の重要な決定事項
- 使用しているORM、フレームワーク、ライブラリのバージョン
- 「やってはいけないこと」リスト
- テストの実行方法
ただし、150行を超えないよう注意してください。あまり長いと毎セッションのトークン消費が増えて逆効果です。
アクション2：リサーチ→プラン→実装の3段階プロンプトテンプレートを作成する
チーム全体で使える標準テンプレートを用意しましょう。以下は一例です。
リサーチプロンプト例：
この機能に関連するコードベースの部分を深く、詳細に調査してください。
キャッシュ層、バリデーション、既存のAPI契約、テストカバレッジを含めて、
research.md に調査結果を書き出してください。口頭での要約は不要です。プランニングプロンプト例：
research.md の内容を踏まえて、実装プランを plan.md に作成してください。
各ステップのコードスニペット、対象ファイルパス、トレードオフを含めてください。
まだ実装はしないでください。実装プロンプト例：
plan.md に基づいてすべて実装してください。完了したタスクはプラン上で完了マークをつけてください。
すべて完了するまで止まらないでください。不要なコメントは追加しないでください。
継続的にテストを実行して、新しい問題を導入していないか確認してください。アクション3：アノテーションサイクルをコードレビュープロセスに組み込む
既存のプルリクエストレビューに加えて、「計画レビュー」というステップを導入しましょう。大きな機能変更を行う前に、plan.mdをチームメンバーがレビューする仕組みです。
これは従来の「設計レビュー」と似ていますが、以下の点で異なります。
- ドキュメントの作成コストが極めて低い（AIが書くため）
- レビューのターンアラウンドが速い（数時間ではなく数分）
- フィードバックが具体的（ファイルパスとコードスニペット付き）
アクション4：ツールの使い分けガイドラインを策定する
チーム内で以下のような使い分けルールを明文化しておきましょう。
| タスクの種類 | 推奨ツール | 理由 |
|---|---|---|
| 1-2行のコード補完 | GitHub Copilot | 最速のインライン補完 |
| 複数ファイルの軽微な修正 | Cursor | プロジェクト全体のコンテキスト理解 |
| 新機能の実装・大規模リファクタ | Claude Code | 自律的な長時間タスク実行 |
| アーキテクチャ設計・技術調査 | Claude Code（プランモード） | 深い分析と構造化された出力 |
| 緊急のバグ修正 | Cursor or Copilot | 即座のコンテキスト理解と修正 |
アクション5：AI活用スキルの組織的な底上げ
Claude Codeの効果は、使う人のスキルによって大きく変わります。AI導入戦略の一環として、以下のような取り組みを検討してみてください。
- 週次の「プロンプト共有会」 ― 効果的だったプロンプトや失敗例をチーム内で共有する
- CLAUDE.mdのテンプレートライブラリ ― 社内のプロジェクト種別ごとにテンプレートを整備する
- ペアプログラミング×Claude Code ― 経験者と初心者がClaude Codeを使いながらペアプロを行い、暗黙知を伝承する
- 成果メトリクスの計測 ― プルリクエストの作成時間、レビュー指摘数、デプロイ頻度などでAI活用の効果を可視化する
まとめ ― 「AIを使いこなす力」が開発者の新しい必須スキルに
Boris Tane氏の「プランニングと実行の分離」ワークフローは、Claude Codeの使い方を根本的に見直すきっかけになる提案です。
要点をまとめると、以下の通りです。
- リサーチ→プラン→アノテーション→実装の4フェーズで、AIの出力品質が劇的に向上する
- アノテーションサイクル（インラインでの注釈追記と反復）が、チャットベースの修正指示よりもはるかに精密なフィードバックを可能にする
- 計画をマークダウンファイルに永続化することで、コンテキスト圧縮の影響を受けず、長時間セッションでも進捗が失われない
- Claude Code、Cursor、GitHub Copilotは競合ではなく補完関係にあり、タスクに応じた使い分けが最適解
- 日本企業は「AIを導入する」段階から「AIの使い方を組織として最適化する」段階へ進む必要がある
AIコーディングツールの性能は月単位で向上しています。しかし、ツールの性能が上がれば上がるほど、「何を」「どう」指示するかという人間側のスキルが成果を左右するようになります。
Tane氏の言葉を借りれば、「計画と実行の分離は、私がやっている中で最も重要なこと」。まずは次のタスクで、コードを書かせる前にresearch.mdを作成させるところから始めてみてはいかがでしょうか。その一手間が、AI支援開発の体験を大きく変えるはずです。
参考・出典
- Boris Tane, “How I Use Claude Code,” boristane.com, 2026年2月（参照日: 2026-02-23）
- Hacker News, “How I use Claude Code: Separation of planning and execution,” 717 points, 454 comments, 2026年2月（参照日: 2026-02-23）
- Anthropic, “Best Practices for Claude Code,” Claude Code Documentation, 2026年（参照日: 2026-02-23）
- Anthropic, “Common workflows – Claude Code Docs,” Claude Code Documentation, 2026年（参照日: 2026-02-23）
- ClaudeLog, “Claude Code Best Practices: Plan Mode,” 2026年（参照日: 2026-02-23）
- エムスリーテックブログ, “突撃！隣のClaude Code！！,” 2026年（参照日: 2026-02-23）
- Kanerika, “GitHub Copilot vs Claude Code vs Cursor vs Windsurf: Enterprise AI Coding Tool Comparison,” 2026年（参照日: 2026-02-23）
生成AIの研修・導入支援について詳しくは サービス紹介ページ をご覧ください。
