Author

claudecodejp

案件ごとにディレクトリを分けて後から探しやすくする

同じ場所に全部ぶち込んで、あとから「どれがどの案件の資料だっけ」と探し回る。これ、かなり雑に見えて、実は一番コストが高い整理不足だ。Claude Code を使うなら、案件フォルダを切る、整理用の置き場を分ける、という発想に早めに寄せたほうがいい。そうしておくと、後から資料を拾いやすいし、生成した文書の差し替えや見直しも楽になる。

特に、文章作成や書類整理で Claude Code を使う人は、「ひとつの作業にひとつの場所」を作るだけで手戻りが減る。フォルダ名を見れば中身の当たりがつく状態にしておく、ただそれだけで探す時間が消える。雑に見えるけれど、効く。

Claude Code でやることは単純だ。案件ごとのディレクトリを先に作り、その中で入力資料、下書き、出力を分ける。散らかった作業場を毎回片づけるより、最初から箱を分けたほうが早い。

たとえば、こんな形にしておく。

projects/
  2026-01_契約書見直し/
    00_inbox/
    01_materials/
    02_drafts/
    03_output/
    notes.md
  2026-01_請求書整理/
    00_inbox/
    01_materials/
    02_drafts/
    03_output/

この形のいいところは、Claude Code に渡すコンテキストが自然にまとまることだ。案件フォルダの中だけを見せればいいので、関係ないファイルをうっかり読ませにくい。大量の資料があるときほど、この差が出る。最初は「どこに置いても同じだろ」と思いがちだが、あとでファイル名を頼りに掘り返す羽目になる。筆者も昔、同じような名前の下書きを散らしすぎて、差分の確認だけで無駄に時間を食った。フォルダを分けていなかったせいで、Claude Code に頼む前の整理で疲れる。あれはだるい。

Claude Code に指示するときは、曖昧に「整理して」ではなく、置き場の役割まで言うといい。たとえばこうだ。

この案件用のディレクトリを作ってください。
中は 00_inbox, 01_materials, 02_drafts, 03_output に分けてください。
既存ファイルは内容を見て、適切な場所へ移してください。
ファイル名は変えすぎず、何の資料か分かる程度に整えてください。

文章作成中心なら、もう少し踏み込んでこう頼める。

このフォルダを案件単位で整理してください。
- 入力資料は 01_materials に入れる
- 下書きは 02_drafts に入れる
- 提出用の完成版は 03_output に入れる
- 作業メモは notes.md にまとめる

見つからなくなる名前は避けて、後から人間が追える構成にしてください。

ここで大事なのは、Claude Code に「全部おまかせ」しないことだ。整理のルールがないと、本人はきれいに整えたつもりでも、後で見るとどこに何があるのか分からない構造になる。フォルダ名が抽象的すぎるのが一番まずい。misc、tmp、new みたいな名前は、最初だけ便利で、その後はただの墓場になる。

それと、案件フォルダは増える前提で作るほうがいい。案件名だけで揃えると、似た名前が出た瞬間に崩れる。2026-01_契約見直し_取引先A のように、日付と相手や目的を軽く入れておくと見つけやすい。ファイル名も同じだ。final で終わらせず、2026-01-15_契約書修正版.md のように、あとから意味が読める名前にする。ここをサボると、ディレクトリを分けたのに探せない、という間抜けな状態になる。

Claude Code による整理で気をつけたいのは、移動したあとに参照先が壊れることだ。特に、文書内で相対パスを使っていたり、他の資料からリンクしていたりすると、動かしただけで辻褄がずれる。だから、最初から「どこを正とするか」を決めておくのが先だ。私は一度、下書きをきれいに移したあとで、古い場所を前提にしたメモを全部見失った。整理したつもりが、逆に迷子を増やしたわけだ。やるなら、移動後に notes.md か一覧ファイルを更新しておくべきだ。

移動したファイルの一覧も残してください。
どのファイルをどこへ移したか、あとから追えるようにしてください。

非エンジニアが使うなら、難しいことは要らない。案件ごとに箱を分けて、箱の中を「受け取った資料」「作業中」「出せる状態」に分ける。それだけで十分に効く。たとえば弁護士なら案件ごと、ライターなら記事ごと、事務作業なら依頼ごとに箱を切る。書類整理でも、不要ファイルを消す前に「残す」「見直す」「削除候補」に分けておくと、後で事故りにくい。

Claude Code は、雑多な置き場を魔法みたいに勝手に理解してくれる道具ではない。むしろ、置き場が整っているほど使いやすくなる。案件ごとにディレクトリを分けるのは、気分の問題ではなく、あとから探す時間を削るための実務だ。最初の一手間で、後半の手戻りがかなり減る。

もし次にやるなら、同じ発想で「作業用メモを1ファイルに集める」「出力だけ別フォルダに逃がす」「不要な一時ファイルを案件ごとに掃除する」まで進めるといい。フォルダの切り方が決まると、Claude Code への頼み方も急に具体的になる。そこからが本番だ。

関連 TIPS

• Claude Code に触らせる場所を先に決める
• 本番用の作業と試作品を分ける
• 同じリポジトリで複数案を並走させる
• 別作業の成果を混ぜない
• コンフリクトを増やさない進め方
• ブランチを切る前に整理する
• 試し書きは別場所で済ませる
• 終わった作業を片付ける
• 別作業場所を切って本流を汚さず試す

同じ著者の記事

前提が変わったら古い指示を捨てて、言い直す

Claude Code に同じ話を延々と持ち込んでいると、だいたい一回はズレる。古い前提を残したまま「ちょっとだけ追加で」と積み上げるからだ。方針変更の再指示、古い前提を残さない、というのは派手なテクニックではないが、実務ではこれが効く。 たとえば、最初は「このフォルダの重複画像を整理して」と頼んでいたのに、途中で「やっぱり削除は怖いから一覧だけにして」と方針が変わったとする。ここで前の指示を引きずったまま会話を続けると、Claude Code は「削除前提の整理」と「一覧化だけ」を両方気にして、中途半端な出力を返しやすい。これは開発でも文書作成でも同じで、前提が変わったのに古い条件を残すと、やり直しが増える。 やることは単純だ。方針が変わったら、差分だけを足すのではなく、いったん前提を切り替えて言い直す。Claude Code は会話の流れを見て動くので、「さっきの続き」より「今の前提」を明確に渡したほうが強い。 たとえば、こう書き直す。 ```text ここからは前の指示をいったん忘れてください。 前提を変更します。 目的: 重複ファイルの削除ではなく、一覧化だけを行う 禁止事項:

papoo.work

節目で要約を挟ませると、長い会話でも前提が崩れにくい

長いやり取りほど、Claude Code は勝手に賢くなった気になって崩れる。実際には、途中で前提が抜ける、対象ファイルを取り違える、同じ修正を別名で繰り返す、こういう地味な事故が起きやすい。そこで効くのが途中要約だ。会話を区切って要約させる。節目で一度整理を挟むだけで、どこまで進んだか、何を決めたか、何を残したかが見えやすくなる。 Claude Code は、長い会話を続けるほど文脈をたくさん抱える。便利ではあるが、文脈が増えれば増えるほど「今なにを前提に話しているか」がぼやける。ファイル整理でも、ディスク削減でも、文書作成でも同じだ。最初は「不要ファイルの洗い出し」だったのに、いつの間にか「命名規則の話」へ飛び、最後には「手順書の整形」に話が化ける。人間が手綱を握っていないと、会話は平気で迷子になる。 だから、節目を作る。たとえば、ひとつの大きな作業を終えたら、次の指示を出す前に要約を挟む。途中要約でもいいし、会話を区切って要約させる、でもいい。要は「今までの議論を、後で読んでも使える形で短く固めておけ」ということだ。 実際の頼み方は、こんな形で十分だ。 ```text ここまでの

papoo.work

途中報告の頻度を指定して、黙って進みすぎるのを防ぐ

Claude Code に任せると、気づいたら最後まで走り切っていて、途中の判断材料が消えることがある。これが地味に痛い。途中報告を入れさせる、中間報告を入れさせる、進捗の粒度を決める。この3つをちゃんと使うだけで、勝手に突き進んで戻れなくなる事故をかなり減らせる。 特に、ファイル整理や文書作成みたいな「正解はあるが、途中で見たい」作業では効く。全部終わってから見せられても、そこまでの流れが雑だと手戻りがだるい。最初に報告の頻度を決めておけば、Claude Code は勝手に走る道具ではなく、区切って確認しながら進む相棒になる。 まず押さえるべきなのは、指示は「こまめに見せて」だけでは弱いという点だ。Claude Code は、曖昧な指示だと節目の定義を自分で決めがちだし、その節目があなたの感覚とズレる。だから、何回ごとに、どの単位で、何を報告するのかまで決める。 たとえば、文書のたたき台を作らせるなら、こう書く。 ```text まず作業計画を短く出してから、3段階ごとに途中報告してください。 各途中報告では、今やったこと、次にやること、迷っている点を3行で示してください。 勝手に最

papoo.work

返答の形を先に固定する：Markdown か表かを決めてから頼む

Claude Code に雑に「これを整理して」と投げると、返ってくるものが妙に長い説明文になって、あとで自分が切り貼りする羽目になる。ここで先にやるべきなのは、出力形式を先に決めることだ。Markdown でほしいのか、表でほしいのか、成果物の形を固定してから頼む。これだけで手戻りがかなり減る。 たとえば、ファイル整理でも文書作成でも、欲しいのは「考え方」より「そのまま使える形」だろう。Markdown なら見出しや箇条書きをそのまま草案にできるし、表なら項目ごとの比較や一覧にそのまま流し込める。Claude Code は指示が曖昧だと、親切に見えて実は中途半端な出力を返しがちだ。そこを最初に縛るのが、このTIPSの肝である。 実務では、依頼文の冒頭に形式を明記するだけでいい。たとえばこうだ。 ```text 次の内容を、Markdown の見出し付きで整理してください。本文はそのまま貼れる形にしてください。 ``` Markdown にしたいなら、どこまで機械的に整えてよいかも添えると強い。 ```text 次のメモを Markdown で整形してください。 見出しは h2 相当

papoo.work

長い資料は章ごとに渡して、一気読み前提をやめる

長い資料をそのまま全部投げるのは、だいたい雑だ。Claude Code は長文でも扱えるが、だからといって「最初から最後まで一気に読んで、全部を一発で直してくれ」で済ませると、要点がぼける。途中で重要な条件を落としたり、修正の軸がぶれたりして、あとで手戻りになる。 ここで効くのが、章分けして渡す、あるいは分割投入だ。資料を見出し単位、章単位、用途単位で切り、順番に渡していく。これだけで、Claude Code が今どこを見ているのかがはっきりする。長い議事録、仕様書、契約書の下書き、マニュアル、散らかった手順書。全部に効く。非エンジニアでも同じだ。ファイル整理のルール文書や、社内向けの手順書を整えるときにもかなり使える。 筆者は最初、長文を丸ごと貼って「要約して、ついでに直して」と頼んでいた。結果は悪くないのに、肝心の制約が抜ける。後から「いや、そこは残すべきだった」と気づいて、もう一回やり直しになる。あれはだるい。章ごとに渡し始めてから、話が戻りにくくなった。 やり方は単純だ。まず資料を人間が読んで、章や役割で切る。次に、各章を別々に扱わせる。たとえば、先に全体方針を固め、その後で各

papoo.work

終わった作業を片付ける

終わった仕事をそのまま残す人は多い。しかも「あとで見るから」と言いながら、数日後には同じブランチ、同じ作業フォルダ、同じ不要ファイルの山にまた足を取られる。Claude Code はそこを雑に流さず、使い終わった作業場所を整理する、ブランチやフォルダの後片付けまで含めて片づけ役にできる。 ここでやりたいのは大げさな自動化ではない。作業が終わったら、残すものと捨てるものを切り分けて、コンテキストもディスクも空けることだ。これをやらないと、次の依頼で Claude Code が余計なファイルを拾ったり、古い差分に引っ張られたりして、地味に手戻りが増える。 「片付ける」と言っても、全部消せばいいわけではない。残すのは、あとで参照する必要があるものだけだ。たとえば、作業メモ、最終成果物、再利用したいテンプレート、あるいは案件の証跡になる書面だ。消すのは、途中で作った一時ファイル、古い出力、使い捨ての検証フォルダ、役目を終えたブランチだ。 Claude Code には、最初からこの判断を言葉で渡しておくといい。たとえばこんな依頼で十分だ。 ```text この作業が終わったら、後片付けまでやって

papoo.work

試し書きは別場所で済ませる

本番のファイルにいきなり書き始める人は、だいたいあとで自分の差分に泣く。Claude Code でも同じで、思いついた指示を確定版に直書きすると、途中の試し書きまで履歴に残って、あとから何が本筋だったのか分からなくなる。 やることは単純だ。下書き専用の場所を作る。確定版に直書きしない。これだけで、Claude Code に考えさせる内容と、最終的に残す内容を分けられる。結果として、コンテキストの無駄遣いが減り、差分も読みやすくなる。ファイル整理でも文書作成でも効く、地味だが効き目の大きい癖だ。 たとえば、案件ごとにこんな構成にしておくと扱いやすい。 ```text project/ draft/ 2026-08-21-notes.md final/ report.md ``` Claude Code には、まず下書き側だけ触らせる。 ```bash claude ``` 依頼文はこんな具合でいい。 ```text draft/2026-08-21-notes.md に、報告書の材料を箇条書きで整理して。 このファイルは下書き専用。本文の確定版には触らないで。 まだ文章は整えなくていい。

papoo.work

ブランチを切る前に整理する

ブランチを切ってから考える人は、だいたいあとで自分の差分に殴られる。 変更を小さく始める準備、作業開始前の下ごしらえを飛ばすと、Claude Code に渡す文脈が散らかる。すると指示は長くなるし、余計なファイルまで触るし、diff もでかくなる。手戻りの回数が増えるのは、たいていここだ。 Claude Code は、雑な状態でもそれなりに進めてしまう。そこが便利でもあり、危ないところでもある。 だからブランチを切る前に、作業対象を絞り、不要物を片づけ、今から何をやるかを一度だけ言葉にしておく。これだけで、生成される提案の精度がかなり変わる。非エンジニアのファイル整理でも同じだ。案件フォルダ、請求書、原稿、重複画像がごちゃついたまま頼むと、まず整理にコンテキストを食われる。先に片づけるほうが早い。 ブランチ名を考える前に、Claude Code に見せる範囲を狭める。これが一番効く。 巨大なリポジトリ全体を相手にすると、文脈が薄まる。人間でも、机の上に関係ない紙が山ほどあると集中できない。それと同じだ。 作業前にやるのは、この三つで足りる。 1. 今回の目的を一文で書く 2. 触るファ

papoo.work

コンフリクトを増やさない進め方

同じファイルを同時に触らせると、だいたい面倒になる。Claude Code でもそこは変わらない。 「同時に走らせれば速いはず」と思って並列に投げると、diff がぶつかる、指示が食い違う、片方の修正をもう片方が上書きする、で手戻りが増える。やるべきことは単純で、同じファイルを同時に触らせない、衝突しにくい分担にすることだ。 筆者も最初は、複数の作業をまとめて投げてしまっていた。たとえば README と設定ファイルとメモ類を一気に直させる。見た目は速いが、あとで差分を見たら、同じ導入文を別の依頼で微妙に書き換えていたり、設定の文言だけ先祖返りしていたりする。人間が手で整える時間が増えるだけだった。Claude Code は魔法の共有フォルダではない。分担設計が雑だと、普通に詰まる。 一番効くのは、最初に「どの作業がどのファイル群を触るか」を切ることだ。Claude Code に渡す依頼も、ここを先に固定する。たとえば文書整理なら、章の並べ替え担当と誤字修正担当を分けない。どちらも同じ本文を触るからだ。先に構成を固め、そのあとで表記や体裁を直す順番にする。 ```text この作業では

papoo.work

別作業の成果を混ぜない

Claude Code を使っているのに、あとで「このファイル、誰の仕事の途中だっけ」となるなら、だいたい混ぜすぎだ。 一時ファイルと成果物を分離する。作業途中のゴミを残さない。ここを雑にすると、ディスクはじわじわ減るし、差分は読みにくくなるし、別件の作業まで巻き込む。筆者も最初はよくやった。資料を整えてほしいだけなのに、途中生成したメモ、抽出結果、古い版が同じ場所に積もって、どれが納品物か分からなくなった。Claude Code は賢いが、置き場が曖昧だと平気で曖昧なまま積む。そこを人間が締める必要がある。 この話は開発だけの話ではない。文書作成、議事録整理、案件ごとのファイル整頓、画像やCSVの一時処理でも同じだ。成果物は成果物、一時物は一時物。まずこの線を引く。 一番やりやすいのは、作業ディレクトリを最初から分けることだ。案件単位、目的単位でフォルダを切り、途中の派生物はその中の一時置き場に閉じ込める。たとえば、原稿を磨くなら入力、作業中、完成版を分ける。不要なら一時置き場ごと消せる。これだけで後始末がかなり楽になる。 ```text project/ input/

papoo.work