Claude Code フォルダ構成 AIが作る名前の意味

Claude Code フォルダ構成は、放っておくとどんどん増えていきます
materials・research・rules・assets、見覚えのない名前が並んでいても、それが何のためにあるのかは分からないまま
このフォルダ、消してしまっていいんでしょうか？

私も気づいたら似たようなフォルダがいくつも並んでいて、どれが本物か分からなくなりました
AIは指示されればフォルダを作りますが、前回どう名付けたかまでは気にしてくれません

この記事では、AIが作るフォルダを3つの層に分けて読み解きます
層が分かると「これは触っていい」「これは触ると壊れる」がその場で判断できるはずです

ジャベ雄

フォルダ名を覚えるより、層で見分けるほうが早いです

Claude Code フォルダ構成は3つの層に分けて読む

結論から言うと、プロジェクトの中にあるフォルダは「誰が決めたか」で3層に分かれます
この分け方が便利なのは、層ごとに「名前を変えたときに何が起きるか」がはっきり違うからです

ややこしいのは、この3層が同じ階層に並んで置かれることです
見た目はどれも同じフォルダなので、開いてみるまで区別がつきません

ちなみに冒頭で挙げた materials と rules も、実は別々の層
rules は公式仕様に載っている第1層、materials は誰も決めていない第3層です、名前の見た目が似ていても扱いはまったく別ものになります

フォルダ構成とディレクトリ構成は同じ意味

調べているとディレクトリ構成という書き方によく出会いますが、これはフォルダ構成とまったく同じ意味です
どちらか一方が正しいわけではありません

ディレクトリのほうが古くからある呼び方で、もともとは「住所録」や「目録」を指す言葉でした
Windows がフォルダという呼び方を広めたあとも、開発の現場では前からの呼び方が残っていて、いまも両方が混在しています

AIも文脈によって呼び分けます
フォルダ名の意味を調べるときは、どちらの言葉でも同じ内容にたどり着くと思っておけば十分でしょう

ジャベ雄

呼び方が2つあるだけで、指しているものは同じです

第1層|公式に決まっているフォルダは名前を変えられない

第1層は Claude Code が仕様として読みに行くフォルダです
名前を変えると、その中身は読み込まれなくなります、置き場所も名前も公式ドキュメントで決まっているので、勝手に変えられません

プロジェクトの中の .claude フォルダ

プロジェクトのフォルダ直下に置く .claude が第1層の本体です
先頭にドットが付いているので、環境によっては隠しフォルダとして見えないこともあります

この中で見落としやすいのが rules です
「AIが勝手に作った雑多なフォルダ」に見えますが、実際は公式に用意された置き場で、テーマごとに指示を分けて書いておくためのものです

もうひとつ、commands というフォルダを見かけることがあります
スラッシュコマンドを置く場所ですが、公式は skills への移行をすすめています、同じ仕組みに統合されたので新しく作るなら skills のほうです

ジャベ雄

rules を「よくわからないから」で消すと、指示が丸ごと効かなくなります

パソコン全体で共通の ~/.claude フォルダ

プロジェクトごとの設定とは別に、パソコンのユーザーフォルダの中にも同じ名前のフォルダがもう1つ
こちらは全プロジェクト共通の設定置き場で、どのプロジェクトを開いても効きます

パスの先頭に付いている ~ は、ホームフォルダ(自分のユーザーフォルダ)を1文字で表す省略記号、読み方は「チルダ」です
この記号で始まっていたら、自分のユーザーフォルダから始まる場所を指しています

Windows なら C:\Users\(ユーザー名) がその場所にあたります
つまり ~/.claude/ と書いてあったら、それは C:\Users\(ユーザー名)\.claude\ のことだと読み替えてください

なぜ Windows なのに / 区切りなのか、と思われたかもしれません
この書き方はもともと Mac や Linux の流儀で、開発の世界では共通語として使われているものです、Claude も説明のときはこちらで書いてきます

ジャベ雄

チルダを見たら「自分のユーザーフォルダのことだな」と思えば大丈夫です

実際に開いてみると、この一覧に載っていないフォルダもいくつか並んでいます
cache・sessions・shell-snapshots のような、アプリが動くために自分で作って自分で使う置き場です

この手のフォルダは説明書に載っていないほうが普通だと考えてください
公開されている仕様は「人が触る前提のもの」だけで、動作の裏側で使う置き場までは案内されません

なお第1層の「ファイル」のほうを詳しく知りたい場合は、設定ファイルだけを一覧にした記事があります
どのファイルがどこに効くのか、継承のルールまで整理してあるのでこちらもどうぞ

あわせて読みたい

Claude Code 設定ファイル早見表 役割と場所 Claude Codeを触っていると次々に登場する設定ファイル(CLAUDE.md・settings.json・AGENT.md・SKILL.mdなど)を、保存場所と役割で一覧化した早見表記事です、微調整目線で抑えたい初心者〜中級者向けにまとめました

第2層|業界の慣習で決まっているフォルダ

第2層は、仕様ではないけれどほとんどの開発者が同じ意味で使っているフォルダです
名前を変えても動きますが、読む人が混乱します、いわば共通語のようなものだと思ってください

AIがプロジェクトを組み立てるとき、まず作るのがこの層です
学習したコードの大半がこの慣習に従っているので、指示しなくても自然にこの名前が出てきます

この中でいちばん質問されるのが src です
読み方は「ソース」で、source の母音を抜いた省略形になります、コンパイルが必要な言語で古くから使われてきた作法がそのまま各言語に広がりました

dist と build が両方あって混乱することもあります
どちらも「完成品の置き場」でほぼ同じ意味です、片方しか使わないのが普通なので、両方あるなら片方は使われていない可能性があります

もうひとつ覚えておくと役に立つのが vendor です
「取引先」という意味そのままで、自分で書いていないコードが入っています、ここを直しても更新のたびに上書きされるので触らないのが原則です

フォルダ名の付け方にも慣習がある

名前そのものだけでなく、書き方のほうにもゆるい決まり
自分でフォルダを追加するときも、この形に合わせておくと後々あつかいやすくなります

• すべて小文字で書く(Windows以外では大文字と小文字が別ものとして扱われるため)
• 単語の区切りはハイフンかアンダースコアにする、空白は入れない
• 日本語の名前は避ける、コマンドやツールで扱うときに事故のもとになる
• 複数形か単数形かは、プロジェクトの中で揃える

ジャベ雄

最後の「揃える」が、あとで一番効いてくる決まりです

第3層|AIがその場で作る作業フォルダ

第3層が、この記事でいちばん伝えたいところです
公式仕様でもなく業界の慣習でもない、その場の話の流れでAIが名付けたフォルダがここに入ります

「調べた内容をまとめておいて」と頼めば、AIはどこかに置き場を作ります
そのときの名前は materials かもしれないし research かもしれません、どちらでも間違いではないぶん、決まりようがないわけです

右端の列に注目してください
第3層のフォルダは、ほぼすべてが第2層の誰かと役割が重なっています、output と dist、reference と docs といった具合です

ここが散らかりの発生源になります
慣習の名前を使えば済むところに、AIがその場の言葉で別の名前を作ってしまうからです

とはいえ第3層そのものが悪いわけではありません
コードを書かない使い方だと src も tests も出番がないので、第3層の名前でプロジェクトの大半が構成されることすらあります、問題は名前が揺れることだけです

ジャベ雄

第3層は自由なぶん、放っておくと一番散らかります

📚 Claude・生成AIを学べる本PR

面倒なことはChatGPTにやらせよう

カレーちゃん・からあげ

Amazonで見る楽天で見る

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

Claude CodeによるAI駆動開発入門

平川知秀

Amazonで見る楽天で見る

私のおすすめからランダムで3冊を表示しています

AIに任せると同義フォルダが増えていく

いくつかのプロジェクトをAIに任せて育ててきた結果、私の手元では同じ役割のフォルダが違う名前で並ぶ状態があちこちにできていました
散らかり方には、はっきりした型があります

test と tests が両方あるのは、我ながらなかなかの散らかり具合でした
どちらにテストを書けばいいのか、開いた瞬間に手が止まりました

画像置き場にいたっては6種類に分かれていました
作業の内容が少しずつ違うので当時はそれぞれ理由があったはずですが、あとから見るとどれを開けばいいのか自分でも分からないありさま

なぜ増えてしまうのか

AIの不注意というより、仕組みから見て起きるべくして起きています
理由は主に4つです

• AIは前回どう名付けたかを見ていない、そのときの会話の流れだけで名前を決める
• 既存のフォルダがあっても、こちらの言い回しが違えば別のフォルダを作ってしまう
• 英語としてはどちらも正しいので、AIから見れば間違いに見えない
• 人が指摘しないかぎり、増えたことに誰も気づかない

3つめが特に厄介です
test も tests も英語として自然なので、AIには直すべき対象として見えていません、つまり待っていても勝手には揃いません

増殖を止める方法

対策はシンプルで、フォルダ名の正本を1か所に書いておくことです
プロジェクト直下の CLAUDE.md か、第1層で紹介した .claude/rules/ の中に書きます

## フォルダの決まり

- テストは tests/(複数形)に置く、test/ は作らない
- 画像は images/ に集約する、figures/ や screenshots/ は作らない
- 調べものは research/ に置く、materials/ は作らない
- 一時ファイルは tmp/ に置く、使い終わったら消してよい

新しいフォルダが必要になったら、勝手に作らず先に相談すること

ポイントは「使う名前」だけでなく「使わない名前」も書くこと
使わないほうを明記しておかないと、別の言い回しで頼んだときにまた作られます

そもそも .claude/rules/ という置き場が公式に用意されているのは、こういう決まりごとを書いておくためです
指示を一度書いておけば毎回読まれるので、同じ注意を繰り返さずに済みます

すでに散らかってしまった場合も、片付け自体を頼めます
「同じ役割のフォルダが複数ないか調べて、統合案を出して」と伝えると一覧にしてくれます、移動や削除は案を見てから自分で判断するのが安全です

ジャベ雄

使わない名前まで書く、これに気づくまで結構かかりました

そのまま使えるフォルダ構成テンプレート2種

ここまでの整理をふまえて、そのままコピーして使える形にしました
おすすめは最初から凝った構成にしないこと

公式ドキュメントも同じ立場で、まずは CLAUDE.md を1枚置くところから始めて、使いながら育てるやり方をすすめています
空のフォルダをいくつも先に作っても、結局は使われずに残るだけ

アプリ・ツールを作る場合

myapp/
├── CLAUDE.md          プロジェクトの決まりごと
├── README.md          このアプリが何なのかの説明
├── .claude/
│   ├── settings.json  権限などの設定
│   └── rules/         テーマ別の指示
├── src/               プログラム本体
├── tests/             動作確認のコード
├── docs/              仕様や手順の文書
├── assets/            画像やアイコンなどの素材
└── scripts/           補助的な小さいプログラム

第2層の慣習だけで組んだ構成
この形にしておけば、初めて見る人にも中身の見当が付きますし、AIも迷わず正しい場所に置いてくれます

dist や build をあえて入れていないのは、必要になったらツールが自動で作るからです
同じ理由で logs や tmp も先に用意しません、使う段になってから増やせば十分です

ブログや資料などを作る場合

myblog/
├── CLAUDE.md          文体や書き方の決まりごと
├── .claude/
│   ├── settings.json  権限などの設定
│   └── rules/         テーマ別の指示
├── articles/          記事の原稿
├── research/          下調べ・調査メモ
├── images/            画像
└── archive/           公開済み・使い終わったもの

コードを書かない使い方だと、src や tests は出番がありません
そのぶん第3層の名前を使うことになるので、どれを使うか先に決めておきたいところ

この構成では、調べものの置き場を research に寄せて materials は作らないことにしています
逆に materials 側に寄せてもかまいません、大事なのはどちらかに決めて書いておくことのほうです

ジャベ雄

迷ったら少なめに作る、足りなくなってから足せば十分です

消していいフォルダ・ダメなフォルダの見分け方

散らかったフォルダを片付けたくなったときの判断基準です
層ごとに扱いが違うので、まずはどの層かを見てから決めます

いちばん多いのは最後の「役割が分からない」です
この場合はフォルダを開いて、中に入っているファイルの拡張子と日付を見るのが早道
そのフォルダ、最後に更新されたのはいつでしょうか？

日付が古いまま止まっていれば、途中で使わなくなった置き場の可能性が高いでしょう
逆にここ数日の日付が並んでいるならいまも動いているということなので、消さずに残します

名前が同じでも中身が違うことがある

もうひとつ注意したいのが、同じ名前でも層が違うケースです
たとえば rules は .claude/ の中にあれば第1層ですが、プロジェクト直下に置かれていれば誰かが作った第3層かもしれません

判断の決め手は名前ではなく置かれている場所です
同じ名前を見つけたら、どの階層にあるのかを先に確認してください

templates や agents も同じように取り違えやすい名前です
.claude/ の外に出ていれば公式仕様とは無関係なので、消しても動作には響きません

消す前の安全弁

そのプロジェクトを Git で管理しているなら、消す前にひと手間かけておくと安心です
Claude に「このフォルダは Git で管理されているか調べて」と頼めば、裏で確認して教えてくれます

• Gitで管理されている → 消しても履歴から戻せる
• Gitで管理されていない → 消したら戻せない、先に別の場所へ退避する

ジャベ雄

迷ったら消さずに archive へ移す、これでたいてい間に合います

まとめ|3層に分ければフォルダ構成は読める

AIが作ったフォルダは、名前をひとつずつ覚えなくても大丈夫です
「誰が決めたのか」で3層に分ければ、初めて見るフォルダでも扱い方の見当が付くはずです

• 第1層(.claude/ の中)は公式仕様、名前を変えると効かなくなるので触らない
• 第2層(src ・ docs ・ tests など)は業界の共通語、慣習に合わせておくと読みやすい
• 第3層(materials ・ research など)は誰も決めていない、だから自分で決める
• 同義フォルダの増殖は、CLAUDE.md か .claude/rules/ に正本を書いて止める
• 消すときは層を確認してから、中身を見てから

最初の一歩としておすすめなのは、いま開いているプロジェクトのフォルダを眺めて、それぞれがどの層かを言ってみることです
言えなかったものが、そのまま整理すべき対象です

ちなみに CLAUDE.md も .claude/rules/ の中身も、すべてマークダウンという形式で書かれています
AIが書いた文書を読んだり直したりする機会は増える一方なので、記法を押さえておくとこのあたりの作業がぐっと楽になるはずです

あわせて読みたい

マークダウンの書き方入門 AIに伝わるmd記法まとめ マークダウン(Markdown)の書き方を初心者向けにまとめました チャットでよく使う基本記法から CLAUDE.md など AIが読むファイルで使う記法まで網羅し 素のMarkdownとGFM拡張の違いやよくある崩れの直し方まで解説しています

第1層で触れた skills や agents が実際に何をするものなのかは、Claude Codeの拡張機構をまとめた記事で解説しています
用語そのものが分からないときはClaude用語集もあわせてどうぞ

📚 Claude・生成AIを学べる本PR

面倒なことはChatGPTにやらせよう

カレーちゃん・からあげ

Amazonで見る楽天で見る

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

Claude CodeによるAI駆動開発入門

平川知秀

Amazonで見る楽天で見る

私のおすすめからランダムで3冊を表示しています