Claude Codeのプランモードを日常的に使っている方は増えてきました。「まず計画、それから実装」というワークフローは、AIコーディングの基本として定着しつつあります。
それでも、プランを承認したあとの実装結果に「思っていたのと違う」と感じることはないでしょうか。計画はそれらしく見えたのに、出来上がったコードを見ると設計意図とずれている。プランモードを使っているのに、なぜ精度が出ないのか。
原因のひとつは、AIが最初に提示するプランをそのまま承認してしまっていることにあります。
プランは「たたき台」であって「完成品」ではない
AIが生成するプランは、あくまで初期提案です。開発者が持っているプロジェクト固有の制約や、暗黙的な設計方針、過去の経緯といった文脈を、AIは十分に把握していません。最初のプランがそのまま最適解であることは、実際にはほとんどありません。
ただ、AIとのレビューを繰り返していると、どうしても「もう十分だろう」と感じるタイミングが来ます。AIが整った文章で計画を提示してくると、なおさらそう見えてしまう。これは自然な感覚です。しかし人間同士のレビューに置き換えると、設計レビューで最初のドラフトをノーコメントで通してしまうことに近い。その先で問題が出るのは、プランの練度の問題であって、開発者の判断ミスではありません。
納得するまで、何度でも詰める
プランモードの精度を上げるアプローチは、実はシンプルです。AIの提案に納得できるまで、修正を指示し続ける。それだけです。
「エラーハンドリングの方針が抜けているから追加して」「この部分、既存のRepositoryクラスを経由するように変えて」「テストの粒度をもう少し細かくして」。こうしたフィードバックを1つずつ重ねていく。AIはフィードバックを受けるたびにプランを修正し、設計の解像度が上がっていきます。
重要なのは、この工程を「面倒な手間」ではなく「設計レビューそのもの」として捉えることです。
プランモードでのやり取りは、実質的にAIとの設計レビューです。指摘を重ねるたびにAIは文脈を吸収し、プロジェクトの制約をより深く理解したうえで提案を返してくる。1回のやり取りで終わらせるのではなく、2回、3回と往復することで、プランの品質は明確に変わります。
このプロセスを経て承認されたプランは、AIにとっても「十分に合意形成された設計方針」になります。実装フェーズでのブレが減るのは、プランの精度が上がっている以上、自然な結果です。
「詰めた設計」を資産にする
プランモードで丁寧に詰めた設計判断。しかし、セッションが切れればその文脈は失われます。次回のセッションではまた一から説明し直し、同じ議論を繰り返す…。この問題は、プランを丁寧に作り込む開発者ほど痛感しているはずです。
sqlewは、この課題に対するひとつの解です。Claude Codeのプランモードと連携し、承認されたプランに含まれる設計判断をADR（Architecture Decision Record）として自動的に蓄積します。丁寧に詰めた設計の「なぜ」が、セッションを超えて残り続けます。
sqlewはApacheライセンスのOSSで、ゼロセッティングで今すぐ始められます。
プランは1回で通すものではなく、設計を詰めるための対話の場。そして詰めた結果を揮発させず、プロジェクトの資産として積み上げていく。この2つの意識が、プランモードの本来の力を引き出します。
