PRセールで狙いたい 仕事の道具
スマイルSale11/4(水) 9:00〜11/12(木) 23:59
🖱️ロジクール M575SPd親指で動かすトラックボール、手首が疲れにくい私も使っていますAmazonで見る →
🖥️2台目のモニターMSI の24.5型、資料を横に開いたまま作業できる(フルHD・IPS)Amazonで見る →
🦾モニターアームエルゴトロン LX Pro、モニターを浮かせて机を広く使える(34型まで)Amazonで見る →
💾microSD 512GBAmazonベーシック、スマホやカメラの容量を一気に増やす(読み取り最大200MB/秒)Amazonで見る →
👆トラックパッドAmazonベーシック、Windows PC用のワイヤレス、2台を切り替えて使えるAmazonで見る →
Claude Code フォルダ構成は、放っておくとどんどん増えていきます
materials・research・rules・assets、見覚えのない名前が並んでいても、それが何のためにあるのかは分からないまま
このフォルダ、消してしまっていいんでしょうか？
私も気づいたら似たようなフォルダがいくつも並んでいて、どれが本物か分からなくなりました
AIは指示されればフォルダを作りますが、前回どう名付けたかまでは気にしてくれません
この記事では、AIが作るフォルダを3つの層に分けて読み解きます
層が分かると「これは触っていい」「これは触ると壊れる」がその場で判断できるはずです
ジャベ雄フォルダ名を覚えるより、層で見分けるほうが早いです
結論から言うと、プロジェクトの中にあるフォルダは「誰が決めたか」で3層に分かれます
この分け方が便利なのは、層ごとに「名前を変えたときに何が起きるか」がはっきり違うからです
| 層 | 代表例 | 名前を変えると | 決めた人 |
|---|---|---|---|
| 第1層 公式 | .claude/rules/ ・ skills/ ・ agents/ | 動かなくなる | Anthropic(公式仕様) |
| 第2層 慣習 | src ・ docs ・ tests ・ assets | 動くが読み手が混乱する | 業界の暗黙の了解 |
| 第3層 作業用 | materials ・ research ・ output | 何も起きない | 誰も決めていない |
ややこしいのは、この3層が同じ階層に並んで置かれることです
見た目はどれも同じフォルダなので、開いてみるまで区別がつきません
ちなみに冒頭で挙げた materials と rules も、実は別々の層
rules は公式仕様に載っている第1層、materials は誰も決めていない第3層です、名前の見た目が似ていても扱いはまったく別ものになります
層を見分ける質問はひとつだけ
「この名前でないと動かないのか、それとも人が読みやすいだけなのか」ここが分かれ目です
調べているとディレクトリ構成という書き方によく出会いますが、これはフォルダ構成とまったく同じ意味です
どちらか一方が正しいわけではありません
ディレクトリのほうが古くからある呼び方で、もともとは「住所録」や「目録」を指す言葉でした
Windows がフォルダという呼び方を広めたあとも、開発の現場では前からの呼び方が残っていて、いまも両方が混在しています
AIも文脈によって呼び分けます
フォルダ名の意味を調べるときは、どちらの言葉でも同じ内容にたどり着くと思っておけば十分でしょう
ジャベ雄呼び方が2つあるだけで、指しているものは同じです
第1層は Claude Code が仕様として読みに行くフォルダです
名前を変えると、その中身は読み込まれなくなります、置き場所も名前も公式ドキュメントで決まっているので、勝手に変えられません
プロジェクトのフォルダ直下に置く .claude が第1層の本体です
先頭にドットが付いているので、環境によっては隠しフォルダとして見えないこともあります
| フォルダ・ファイル | 役割 |
|---|---|
| CLAUDE.md | 毎回のセッション開始時に読まれるプロジェクトの指示書 |
| .claude/settings.json | 権限・自動実行・各種設定 |
| .claude/settings.local.json | 自分だけの上書き設定(共有しない前提) |
| .claude/rules/ | テーマ別に切り出した指示、対象ファイルを絞って効かせられる |
| .claude/skills/ | 名前を呼んで使い回すプロンプト集 |
| .claude/agents/ | 専用の作業役(サブエージェント)の定義 |
| .claude/workflows/ | 複数の作業役をまとめて動かす台本 |
| .claude/output-styles/ | 出力の見せ方の設定 |
| .claude/agent-memory/ | 作業役が自分で書き溜めていく記憶 |
| .mcp.json | 外部サービスとの接続設定(チームで共有する前提) |
この中で見落としやすいのが rules です
「AIが勝手に作った雑多なフォルダ」に見えますが、実際は公式に用意された置き場で、テーマごとに指示を分けて書いておくためのものです
もうひとつ、commands というフォルダを見かけることがあります
スラッシュコマンドを置く場所ですが、公式は skills への移行をすすめています、同じ仕組みに統合されたので新しく作るなら skills のほうです
ジャベ雄rules を「よくわからないから」で消すと、指示が丸ごと効かなくなります
プロジェクトごとの設定とは別に、パソコンのユーザーフォルダの中にも同じ名前のフォルダがもう1つ
こちらは全プロジェクト共通の設定置き場で、どのプロジェクトを開いても効きます
パスの先頭に付いている ~ は、ホームフォルダ(自分のユーザーフォルダ)を1文字で表す省略記号、読み方は「チルダ」です
この記号で始まっていたら、自分のユーザーフォルダから始まる場所を指しています
Windows なら C:\Users\(ユーザー名) がその場所にあたります
つまり ~/.claude/ と書いてあったら、それは C:\Users\(ユーザー名)\.claude\ のことだと読み替えてください
| 書き方 | 意味 | Windowsでの実際の場所 |
|---|---|---|
| ~ | ホームフォルダ | C:\Users\(ユーザー名) |
| ~/.claude/ | ホームフォルダの中の .claude | C:\Users\(ユーザー名)\.claude\ |
| ./ | いま開いているフォルダ | そのプロジェクトのフォルダ |
| ../ | ひとつ上のフォルダ | 親フォルダ |
なぜ Windows なのに / 区切りなのか、と思われたかもしれません
この書き方はもともと Mac や Linux の流儀で、開発の世界では共通語として使われているものです、Claude も説明のときはこちらで書いてきます
この ~ は半角のチルダで、日本語の波線(〜)とは別の文字
全角で打つと別物になってしまうので、実際にパスを打ち込むときだけ気をつけてください
ジャベ雄チルダを見たら「自分のユーザーフォルダのことだな」と思えば大丈夫です
| パス | 役割 |
|---|---|
| ~/.claude/CLAUDE.md | 全プロジェクト共通の個人的な決めごと |
| ~/.claude/settings.json | 全プロジェクトの既定の設定 |
| ~/.claude/keybindings.json | キーボードショートカット |
| ~/.claude/themes/ | 配色テーマ |
| ~/.claude/projects/ | プロジェクトごとの記録・自動メモ |
| ~/.claude.json | アプリの状態と画面まわりの設定 |
実際に開いてみると、この一覧に載っていないフォルダもいくつか並んでいます
cache・sessions・shell-snapshots のような、アプリが動くために自分で作って自分で使う置き場です
この手のフォルダは説明書に載っていないほうが普通だと考えてください
公開されている仕様は「人が触る前提のもの」だけで、動作の裏側で使う置き場までは案内されません
公式ドキュメントに説明がないフォルダは、役割を推測して触らないほうが安全でしょう
.claude の中は、意味が分からないものは触らない、これを原則にしておくと事故が減ります
なお第1層の「ファイル」のほうを詳しく知りたい場合は、設定ファイルだけを一覧にした記事があります
どのファイルがどこに効くのか、継承のルールまで整理してあるのでこちらもどうぞ
第2層は、仕様ではないけれどほとんどの開発者が同じ意味で使っているフォルダです
名前を変えても動きますが、読む人が混乱します、いわば共通語のようなものだと思ってください
AIがプロジェクトを組み立てるとき、まず作るのがこの層です
学習したコードの大半がこの慣習に従っているので、指示しなくても自然にこの名前が出てきます
| フォルダ | 由来 | 入っているもの |
|---|---|---|
| src | source(source code) | プログラム本体、いちばん大事な中身 |
| docs | documents | 説明書・仕様書などの文書 |
| tests | そのまま | 動作を確かめるためのコード |
| assets | 資産 | 画像・CSS・JSなどの素材一式 |
| scripts | そのまま | 補助的な小さいプログラム |
| data | そのまま | 読み込むデータファイル |
| config | configuration | 設定ファイル |
| dist | distribution(配布) | 完成品、そのまま配れる状態のもの |
| build | そのまま | 組み立てた結果、dist とほぼ同じ意味 |
| bin | binary | 実行ファイル・コマンド |
| lib | library | 部品として使うコードのまとまり |
| vendor | 取引先・供給元 | 他人が作ったライブラリ |
| public / static | そのまま | そのまま公開されるファイル |
| examples | そのまま | 使い方の見本 |
| templates | そのまま | 雛形 |
| logs | そのまま | 動作の記録 |
| tmp | temporary(一時的) | 使い捨ての作業ファイル |
この中でいちばん質問されるのが src です
読み方は「ソース」で、source の母音を抜いた省略形になります、コンパイルが必要な言語で古くから使われてきた作法がそのまま各言語に広がりました
dist と build が両方あって混乱することもあります
どちらも「完成品の置き場」でほぼ同じ意味です、片方しか使わないのが普通なので、両方あるなら片方は使われていない可能性があります
もうひとつ覚えておくと役に立つのが vendor です
「取引先」という意味そのままで、自分で書いていないコードが入っています、ここを直しても更新のたびに上書きされるので触らないのが原則です
名前そのものだけでなく、書き方のほうにもゆるい決まり
自分でフォルダを追加するときも、この形に合わせておくと後々あつかいやすくなります
ジャベ雄最後の「揃える」が、あとで一番効いてくる決まりです
第3層が、この記事でいちばん伝えたいところです
公式仕様でもなく業界の慣習でもない、その場の話の流れでAIが名付けたフォルダがここに入ります
「調べた内容をまとめておいて」と頼めば、AIはどこかに置き場を作ります
そのときの名前は materials かもしれないし research かもしれません、どちらでも間違いではないぶん、決まりようがないわけです
| フォルダ | だいたいの意味 | ぶつかりやすい相手 |
|---|---|---|
| materials | 素材・下調べの置き場 | research |
| research | 調査結果のまとめ | materials |
| reference | 参照用の資料 | docs |
| notes | メモ書き | docs |
| output | 作業の成果物 | dist |
| reports | 出力したレポート | output |
| archive | 使い終わった過去ぶん | (なし) |
| inbox | まだ整理していない投入先 | tmp |
| draft | 下書き | (なし) |
| scratchpad | 使い捨ての作業領域 | tmp |
右端の列に注目してください
第3層のフォルダは、ほぼすべてが第2層の誰かと役割が重なっています、output と dist、reference と docs といった具合です
ここが散らかりの発生源になります
慣習の名前を使えば済むところに、AIがその場の言葉で別の名前を作ってしまうからです
とはいえ第3層そのものが悪いわけではありません
コードを書かない使い方だと src も tests も出番がないので、第3層の名前でプロジェクトの大半が構成されることすらあります、問題は名前が揺れることだけです
materials は分野によって意味がまるで変わる名前でもあります
ゲーム開発のUnityでは「マテリアル(材質)」を指すので、検索しても素材フォルダの話にたどり着けないことも
ジャベ雄第3層は自由なぶん、放っておくと一番散らかります
AI鬼管理｜Claude Code活用の業務自動化トレーニング
Claude Code を業務の自動化に使うためのトレーニングです
いきなり申し込む形ではなく、まずは無料の業務効率化診断(オンライン面談)から始められます
いくつかのプロジェクトをAIに任せて育ててきた結果、私の手元では同じ役割のフォルダが違う名前で並ぶ状態があちこちにできていました
散らかり方には、はっきりした型があります
| 症状 | 実際に並んでいたフォルダ名 |
|---|---|
| 単数形と複数形のゆれ | test と tests が同じプロジェクトの中に両方ある |
| 画像置き場の分裂 | figures ・ images ・ img-temp ・ screenshots ・ thumbnail ・ thumbnails |
| 調査置き場の分裂 | materials と research が並立、どちらに何を置くか決まっていない |
| プロジェクト間の不一致 | 片方は thumbnail、もう片方は thumbnails |
test と tests が両方あるのは、我ながらなかなかの散らかり具合でした
どちらにテストを書けばいいのか、開いた瞬間に手が止まりました
画像置き場にいたっては6種類に分かれていました
作業の内容が少しずつ違うので当時はそれぞれ理由があったはずですが、あとから見るとどれを開けばいいのか自分でも分からないありさま
AIの不注意というより、仕組みから見て起きるべくして起きています
理由は主に4つです
3つめが特に厄介です
test も tests も英語として自然なので、AIには直すべき対象として見えていません、つまり待っていても勝手には揃いません
対策はシンプルで、フォルダ名の正本を1か所に書いておくことです
プロジェクト直下の CLAUDE.md か、第1層で紹介した .claude/rules/ の中に書きます
## フォルダの決まり
- テストは tests/(複数形)に置く、test/ は作らない
- 画像は images/ に集約する、figures/ や screenshots/ は作らない
- 調べものは research/ に置く、materials/ は作らない
- 一時ファイルは tmp/ に置く、使い終わったら消してよい
新しいフォルダが必要になったら、勝手に作らず先に相談することポイントは「使う名前」だけでなく「使わない名前」も書くこと
使わないほうを明記しておかないと、別の言い回しで頼んだときにまた作られます
そもそも .claude/rules/ という置き場が公式に用意されているのは、こういう決まりごとを書いておくためです
指示を一度書いておけば毎回読まれるので、同じ注意を繰り返さずに済みます
すでに散らかってしまった場合も、片付け自体を頼めます
「同じ役割のフォルダが複数ないか調べて、統合案を出して」と伝えると一覧にしてくれます、移動や削除は案を見てから自分で判断するのが安全です
ただし CLAUDE.md に書いた文章に強制力はありません
あくまで「読んでもらう指示」なので、書いたとおりに動かないこともあります、大事な決まりは定期的に見直すのが原則です
ジャベ雄使わない名前まで書く、これに気づくまで結構かかりました
ここまでの整理をふまえて、そのままコピーして使える形にしました
おすすめは最初から凝った構成にしないこと
公式ドキュメントも同じ立場で、まずは 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 側に寄せてもかまいません、大事なのはどちらかに決めて書いておくことのほうです
フォルダを作る作業そのものも Claude に頼めます
「この構成で空のフォルダを作って、CLAUDE.md にフォルダの決まりも書いて」と伝えれば、中身まで含めて用意してくれます
ジャベ雄迷ったら少なめに作る、足りなくなってから足せば十分です
散らかったフォルダを片付けたくなったときの判断基準です
層ごとに扱いが違うので、まずはどの層かを見てから決めます
| 状態 | 判断 | 理由 |
|---|---|---|
| .claude/ の中で公式に説明があるもの | 消さない | 指示や設定が読まれなくなる |
| .git ・ node_modules ・ __pycache__ ・ .venv | 消さない | ツールが自分で管理している領域 |
| dist ・ build | 消してよい | 組み立て直せば再生成される |
| tmp ・ cache ・ img-temp | 消してよい | もともと一時的な置き場 |
| 中身が空 | 消してよい | 作ったまま使われなかった可能性が高い |
| 同義のフォルダが並んでいる | 片方に寄せる | 中身を移してから消す |
| 役割が分からない | いったん残す | 中身を見てから判断する |
いちばん多いのは最後の「役割が分からない」です
この場合はフォルダを開いて、中に入っているファイルの拡張子と日付を見るのが早道
そのフォルダ、最後に更新されたのはいつでしょうか？
日付が古いまま止まっていれば、途中で使わなくなった置き場の可能性が高いでしょう
逆にここ数日の日付が並んでいるならいまも動いているということなので、消さずに残します
もうひとつ注意したいのが、同じ名前でも層が違うケースです
たとえば rules は .claude/ の中にあれば第1層ですが、プロジェクト直下に置かれていれば誰かが作った第3層かもしれません
判断の決め手は名前ではなく置かれている場所です
同じ名前を見つけたら、どの階層にあるのかを先に確認してください
templates や agents も同じように取り違えやすい名前です
.claude/ の外に出ていれば公式仕様とは無関係なので、消しても動作には響きません
そのプロジェクトを Git で管理しているなら、消す前にひと手間かけておくと安心です
Claude に「このフォルダは Git で管理されているか調べて」と頼めば、裏で確認して教えてくれます
消す前に中身を確認する、これだけは省かないでください
フォルダ名から想像したものと中身が違うことは普通にあります、名前だけで判断すると必要なものまで消えます
ジャベ雄迷ったら消さずに archive へ移す、これでたいてい間に合います
AIが作ったフォルダは、名前をひとつずつ覚えなくても大丈夫です
「誰が決めたのか」で3層に分ければ、初めて見るフォルダでも扱い方の見当が付くはずです
最初の一歩としておすすめなのは、いま開いているプロジェクトのフォルダを眺めて、それぞれがどの層かを言ってみることです
言えなかったものが、そのまま整理すべき対象です
ちなみに CLAUDE.md も .claude/rules/ の中身も、すべてマークダウンという形式で書かれています
AIが書いた文書を読んだり直したりする機会は増える一方なので、記法を押さえておくとこのあたりの作業がぐっと楽になるはずです
第1層で触れた skills や agents が実際に何をするものなのかは、Claude Codeの拡張機構をまとめた記事で解説しています
用語そのものが分からないときはClaude用語集もあわせてどうぞ
ジャンルごとに私のおすすめからランダムで5冊を表示しています
WORK
ツール作成のご依頼を受けています
クラウドワークス・ココナラで受注200件以上
会社員の副業なので、対応は平日夜と土日です
ココナラが初めての方は、紹介コード 78E62K で1,000円分のポイントがもらえます
コメント