本番のファイルにいきなり書き始める人は、だいたいあとで自分の差分に泣く。Claude Code でも同じで、思いついた指示を確定版に直書きすると、途中の試し書きまで履歴に残って、あとから何が本筋だったのか分からなくなる。
やることは単純だ。下書き専用の場所を作る。確定版に直書きしない。これだけで、Claude Code に考えさせる内容と、最終的に残す内容を分けられる。結果として、コンテキストの無駄遣いが減り、差分も読みやすくなる。ファイル整理でも文書作成でも効く、地味だが効き目の大きい癖だ。
たとえば、案件ごとにこんな構成にしておくと扱いやすい。
project/
draft/
2026-08-21-notes.md
final/
report.md
Claude Code には、まず下書き側だけ触らせる。
claude
依頼文はこんな具合でいい。
draft/2026-08-21-notes.md に、報告書の材料を箇条書きで整理して。
このファイルは下書き専用。本文の確定版には触らないで。
まだ文章は整えなくていい。論点、未確認点、使えそうな言い回しだけを拾って。
次に、下書きが固まってから確定版へ反映する。
draft/2026-08-21-notes.md をもとに final/report.md を整えて。
下書きのメモは残さず、確定版だけを更新して。
この分け方が効くのは、Claude Code が「どこを直してよくて、どこに触るべきでないか」を迷わなくなるからだ。ひとつのファイルに試行錯誤と完成品を混ぜると、会話の中でもファイル差分の中でもノイズが増える。筆者は昔、同じ markdown に試し書きを重ねて、後から本筋の段落を探すだけで時間を溶かしたことがある。AI に限らず、人間もかなりの確率で同じ事故を起こす。
非エンジニアの用途でもこれは強い。たとえば、契約書のたたき台、議事録の整形、請求書まわりの説明文、不要ファイルの洗い出しメモ、そういうものは最初から完成形にしないほうがいい。まず下書き専用の場所で材料を集める。そこで「重複しているファイル名」「古そうなメモ」「残すべき文面候補」だけを出させる。最後に確定版の場所へ移す。これだけで、あとから見返したときの疲れ方がかなり違う。
注意したいのは、下書き専用の場所を作ったのに、そこを本番の代わりに放置することだ。下書きは下書きなので、いつまでも散らかったままにしないほうがいい。使い終わったら、要点だけ確定版へ移して、下書きは捨てるか、次の作業用に空に戻す。中途半端なメモが増えると、結局また探し物になる。
もうひとつ、Claude Code に「いい感じにまとめて」とだけ投げるのもやめたほうがいい。下書き専用の場所を作る意味は、雑な試行を隔離することにある。指示も雑だと、下書きがただのゴミ箱になる。たとえば、下書きでは「候補を3案」「不明点を別枠で列挙」「本文には入れない」と明示しておくと、後工程がかなり楽になる。
実務では、下書きフォルダや下書きファイルの命名を少し雑にしておくと続けやすい。きれいすぎる名前にすると、逆に「本番っぽく見える」からだ。draft/、scratch/、tmp/ みたいに、見ただけで一時置き場と分かる名前がちょうどいい。反対に、final2_reallyfinal.md みたいな名前が出てきたら、その時点で運用が崩れている。そこは素直に区切り直したほうが早い。
試し書きは別場所で済ませる。これは遠回りに見えて、いちばん手戻りが少ない。Claude Code を使うならなおさらだ。考える場所と、残す場所を分ける。たったそれだけで、文書も整理もずっと安定する。