AIにコードを書かせるな。まず計画を書かせろ。
この一見矛盾した主張が、Hacker Newsのフロントページを席巻した。2025年2月22日、開発者Boris Tane（boristane.com）が公開した「Claude Codeを9ヶ月間メイン開発ツールとして使い続けたワークフロー」は、AI活用の常識を根底から覆す内容だった。
結論から言う。Claude Codeの組み込みプランモードはダメだ。Boris Taneは9ヶ月の試行錯誤の末、そう言い切った。
なぜ「まずコードを書かせる」が失敗するのか
多くの開発者がClaude Codeを使う時、こうする。「この機能を実装して」と指示を出し、AIにコードを書かせる。動かなければ修正を指示する。動くまで繰り返す。
Boris Taneも最初はそうだった。そして3ヶ月目に気づいた。
「AIが書いたコードの修正に、AIが書いたコードを書かせている。これは無限ループだ」
問題の本質は、AIが「全体像」を理解しないままコードを書き始めることにある。人間の開発者なら、コードを書く前にアーキテクチャを考え、既存コードとの整合性を確認し、テスト方針を決める。しかしAIにいきなり「書いて」と言えば、目の前のタスクだけを見て局所最適なコードを生成する。
その結果、動くけれど保守できないコードが量産される。技術的負債が指数関数的に膨らむ。9ヶ月間の最初の3ヶ月で、Boris Taneはこの罠にはまった。
LINE登録でAI活用情報を受け取る
最新のAI活用Tips、限定セミナー情報、無料テンプレートをLINEでお届け。
6フェーズ・ワークフローの全貌
試行錯誤の末にBoris Taneが確立したのが、以下の6フェーズだ。
Phase 1: Research（調査）
まずClaude Codeに「コードを書くな、調べろ」と指示する。既存のコードベースを読ませ、関連するファイル、関数、依存関係をリストアップさせる。この段階でAIに1行もコードを書かせない。
具体的なプロンプト例：
「この機能に関連するファイルを全て列挙し、それぞれの役割を説明しろ。コードは一切書くな。」
Phase 2: Plan（計画）
調査結果を元に、実装計画を書かせる。ここでもコードは書かせない。自然言語で、どのファイルをどう変更するか、どの順番で作業するか、どんなテストが必要かを書かせる。
ここが最も重要なフェーズだ。Boris Taneはこう言う。
「計画を人間がレビューして承認する。このステップを省略した瞬間、全てが崩壊する」
計画が悪ければ、ここでやり直す。コードを書いてから「やっぱり違う」となるより、100倍効率的だ。
Phase 3: Annotate（注釈）
承認された計画に基づき、変更対象のファイルにコメントやTODOを追加させる。まだコードは書かない。「ここにバリデーションを追加」「この関数を分割」といった注釈を既存コードに埋め込む。
これにより、AIが次のフェーズで実際にコードを書く時、文脈を失わない。注釈が「地図」の役割を果たす。
Phase 4: Todo（タスク分解）
計画と注釈を元に、具体的なタスクリストを作成する。1タスクは「1つのファイルの1つの変更」レベルまで分解する。大きなタスクをAIに渡すと失敗率が跳ね上がるからだ。
Phase 5: Implement（実装）
ここでようやくコードを書かせる。ただし、1タスクずつ。Phase 4で分解した小さなタスクを1つずつAIに渡し、完了を確認してから次に進む。
Boris Taneの計測によると、この方法だと1タスクあたりの成功率は92%。一方、計画なしで大きなタスクを丸投げした場合の成功率は34%だった。
Phase 6: Feedback（フィードバック）
実装後にAIに自分のコードをレビューさせる。テストを実行させ、型チェックをさせ、リントをかける。問題があればPhase 5に戻る。
「組み込みプランモードはダメ」の真意
Claude Codeには標準で「プランモード」が搭載されている。AIが自動的に計画を立ててから実装に入る機能だ。一見、Boris Taneのワークフローと似ている。しかし彼はこれを明確に否定する。
理由は3つ。
1. 計画の粒度が粗い
組み込みプランモードの計画は概要レベルで止まる。Boris Taneのワークフローでは、ファイル単位、関数単位まで踏み込んだ計画を要求する。この差が最終的なコード品質に直結する。
2. 人間のレビューポイントがない
組み込みプランモードは計画から実装まで一気通貫で進む。人間が計画を確認し、修正する余地がほとんどない。Boris Taneのワークフローでは、Phase 2の計画を人間が必ず承認する。
3. 失敗時の切り戻しが困難
一気通貫で進んだ結果が期待と違った場合、どこからやり直せばいいかわからない。6フェーズに分かれていれば、問題のあるフェーズだけをやり直せる。
9ヶ月の数字
Boris Taneが公開した具体的な数値は衝撃的だ。
- 9ヶ月間のAPI費用：約$4,200（約63万円）
- 開発速度の向上：従来比3.2倍
- バグ発生率の低下：従来比67%減
- リファクタリング頻度：従来比45%減
月額約7万円のAPI費用で、開発速度が3倍以上になり、バグが7割近く減る。これはジュニアエンジニア1人分の人件費以下だ。
「Claude Codeは魔法の杖ではない。しかし正しいワークフローで使えば、1人の開発者を3人分の戦力に変える」 – Boris Tane
日本の開発現場への応用
このワークフローは、日本の開発現場でこそ威力を発揮する。理由は明確だ。
日本の開発現場は「計画」を重視する文化がある。
設計書、仕様書、レビュー会議。日本のSIer文化で培われたこれらのプロセスは、しばしば「非効率」と批判される。しかしBoris Taneのワークフローは、まさにこの「計画を先に書く」文化と親和性が高い。
違いは、その計画を人間が書くのではなく、AIに書かせて人間がレビューする点だ。これにより、計画の作成速度は10倍になり、人間は「判断」に集中できる。
具体的な導入ステップを提案する：
- まず1つの小さなプロジェクトで6フェーズを試す
- 各フェーズのプロンプトテンプレートを整備する
- チーム内でPhase 2のレビュー基準を標準化する
- 成功パターンをドキュメント化して横展開する
AIコーディングの「第2章」
2024年は「AIにコードを書かせる元年」だった。GitHub Copilot、Cursor、Claude Code。ツールは揃った。
しかし多くの開発者が気づき始めている。ツールを入れただけでは生産性は上がらない。むしろ、AIが生成した低品質なコードの修正に追われて、生産性が下がるケースすらある。
Boris Taneの9ヶ月間の記録は、この問題に対する明確な回答だ。AIにコードを書かせる前に、AIに計画を書かせろ。そしてその計画を人間が承認しろ。
これがAIコーディングの「第2章」だ。ツールの使い方ではなく、ワークフローの設計が勝敗を分ける時代に入った。
9ヶ月という時間をかけて実証されたこのワークフロー。今すぐ取り入れない理由はない。
