AIの作業フォルダ、全部入りにするか、分けるか — 3つの型と、自分に合う選び方

Claude Code や Codex は、指定したフォルダの中身を読み書きしながら作業します。
Codex は OpenAI のAIコーディングツールで、使い勝手は Claude Code と近いものです。
そのフォルダの一番上の階層へ CLAUDE.md や AGENTS.md という名前のファイルを置いておくと、AIが作業を始めるたび、最初に読んでくれます。
言ってみれば、毎回渡す申し送りの常設版です。

ここで最初の分岐が来ます。
案件ごとにフォルダを分けて、それぞれに指示ファイルを置くのか。
それとも1つの大きなフォルダに何でも集めて、1枚の指示書でまとめて管理するのか。

フォルダ構成の切り方や置き方を書いた記事は、日本語でもたくさんあります。
ただ、どの型を選ぶかの基準を書いたものが見当たりません。
なんとなく最初に作ったフォルダを使い続けて、半年後に散らかっている。
心当たりがあるかもしれません。

調べてみると、実践者のフォルダ構成は3つの型に分かれていました。
この記事は2部構成にします。
前半は3つの型と、自分に合うものを選ぶための4つの質問だけを書きます。
コマンドは出てきません。
後半は、公開されているデータとその落とし穴、実際に組んでいる人たちの構成、それに「作り込むな」という反対側の声を扱います。
前半だけ読んで閉じてもらって構いません。

フォルダは、AIに見せる範囲そのもの

型の話へ入る前に、なぜフォルダの切り方が出来に効くのかを書いておきます。

Claude Code や Codex は、起動したフォルダの中だけを世界として働きます。
その中にあるファイルと、指示書に書かれていることだけを見て考える。
外にあるものは、こちらが場所を教えない限り存在しないのと同じです。
先週まったく別のフォルダで話した内容も、当然のように知りません。

つまり、フォルダをどう切るかは、AIに何を見せて何を見せないかを決める作業です。
設定というより、範囲の設計に近い。

ここで綱引きが起きます。
1つのフォルダに全部入れておけば、何でも相談できます。
過去の資料も別テーマの記録も同じ世界の中にあるので、横断した答えが返ってきます。
その代わり、いま関係のない情報まで一緒に見えてしまう。
関係ない資料に引きずられた提案が出てくるのは、たいていこの見えすぎが原因です。

分ければ逆になり、見える範囲が狭いぶん的は絞れますが、他のテーマで得た知見は届きません。
見せる量を増やすことと、的を絞ることは同時に成り立たず、どこかで折り合いをつけることになります。
つけ方の正解は1つでなく、何を扱っているかで変わります。
だからこの記事では、代表的な3つの型と、自分の使い方から選ぶ手順を渡します。

迷っているならテーマ特化型から

先に結論を書きます。
どれにするか決めきれないなら、テーマ特化型から始めるのが無難です。

理由は3つあります。
中に何があるか見通しがきくこと、そのまま人に渡せること、そして失敗したときの被害が小さいことです。
うまくいかなかったらフォルダごと捨てて作り直せばよく、他のテーマに影響しません。
公式の設計も、日本語と英語の解説記事の推奨も、この形に寄っています（後半で詳しく見ます）。

残る2つは、向いている人がはっきりしています。
全部入りの汎用ワークスペース型は、フォルダの手入れに時間を使う気がある人向けです。
第2の脳型は、資料とメモを貯めること自体が目的の人向けです。

テーマごとに分ける「テーマ特化型」

1つのテーマにつき1つのフォルダを作る型です。
案件ごと、リポジトリ（コードやファイルをまとめて置いておく保管場所）ごと、用途ごとに分けます。
それぞれのフォルダの一番上の階層に、そのテーマ専用の CLAUDE.md を1枚置く。
設定やスキルも、そのテーマで実際に要るものだけを入れます。

Anthropic が公式ドキュメントで示している構成も、この形に寄っています。
共有したい指示ファイルはリポジトリに入れ、個人用の設定は共有対象から外す、という仕組みです。
共有対象から外す指定は gitignore と呼ばれ、そこに書いたファイルは他の人へ配られません。

向いているのは、扱うテーマの境界がはっきりしている人です。
複数の案件を並行している人やコードを書く人、成果物を誰かへ渡す予定のある人が当てはまります。
非エンジニアでも同じです。
技術記事の執筆だけを専用フォルダに切り出して回している事例が、日本語でも公開されています。

弱点は、テーマをまたぐ作業に弱いところです。
前の案件で書いたルールを新しい案件でも使いたくなったとき、コピーして回るか、共通の置き場を別に作るしかありません。
フォルダが10、20と増えてくると、どこに何を書いたか自分で分からなくなります。
中身の薄いフォルダが量産されるのも、この型でよくある状態です。

1つに全部集める「汎用ワークスペース型」

大きなフォルダを1つ作って、そこに何でも入れる型です。
中はテーマごとのサブフォルダに分け、全体の運用ルールは一番上の階層に置いた1枚の指示書で管理します。
決めたことや失敗の記録は、会話に流さずファイルへ落としていく。
そういう作りになります。

私はこの型を長く運用しています。
利点は、テーマをまたいだ知識が自然に効くことです。
あるテーマで踏んだ失敗をルールに書いておくと、別のテーマの作業でも同じルールが読まれます。
分けている限り、この横断は起きません。

弱点も書いておきます。
私の運用では、放っておくと確実に肥大しました。
使わなくなった資料や伸びた指示書がたまり、AIの毎回読む量を押し上げていきます。
そのため定期的に整理する時間と、増やしすぎないための上限ルールが要ります。
ちなみに私の場合、作業メモは50行前後、全体の指示書は100行前後を上限にして、超えたら古いものから削っています。
管理の手間は実際にかかっていて、そこを引き受ける気がないなら、この型は選ばないほうがいいと思います。
それでも私が続けているのは、テーマをまたいだ知識の利得が、その手間を上回っているからです。

向いているのは、扱う対象が流動的で、フォルダの手入れそのものを苦にしない人です。
逆に「作った後は触りたくない」タイプの人には、まず勧めません。

資料と記憶が主役の「第2の脳型」

Obsidian のようなノートアプリ、あるいはただのテキストファイルの集まりに、資料とメモと過去の経緯を貯めていく型です。
Obsidian は、メモを1枚ずつのファイルとして手元に残していくノートアプリで、AIから中身を読ませやすい形式になっています。
その置き場をAIに参照させます。

前の2つと違うのは、主役が作業ではないところです。
作業場というより、記憶の置き場にAIをつないでいる形になります。
公開されている構成を見ると、フォルダの切り方も独特です。
テーマではなく情報の寿命で分けていて、受信箱・進行中・書庫といったフォルダ名が並びます。

向いているのは、調査や執筆が中心の人、過去に書いたものを何度も引き直す人です。
2026年に入ってから、この型の記事が目に見えて増えました。
書き手は非エンジニア寄りの人が多い印象です。

弱点は、貯めること自体が楽しくなって作業が進まなくなる点です。
それと、資料が増えるほどAIが読む量も増えます。
参照させる範囲を絞る工夫がないと、関係ない情報に引きずられた答えが返ってきます。

自分に合う型を決める4つの質問

3つの説明を読んでも、たぶんまだ決まりません。
質問の形にしたほうが早いので、4つ用意しました。
順に答えてみてください。

1. 主に扱うのはコードですか、それとも文書や調査ですか

2. 中身を誰かに見せたり、共有したりする予定はありますか

3. フォルダの整理に、定期的に時間を使う気はありますか（この1ヶ月で実際に整理したか、で答えると正直です）

4. 資料やメモを貯めること自体が、目的になっていますか（読み返す予定がなくても保存していますか）

4つ全部に答えてから、質問4→2→3→1の順に上から見て、最初に当てはまったところで確定です。

質問4が Yes なら、第2の脳型です。
他の答えを待つまでもありません。
貯めることが目的なら、貯める場所を主役に据えたほうが素直です。

質問2が Yes なら、テーマ特化型です。
人に渡す前提があると、渡す単位でフォルダが切れている必要があります。
全部入りのフォルダから該当部分だけ抜き出す作業は、思っているより面倒です。

質問3が No なら、テーマ特化型です。
手入れをしない前提で全部入りを選ぶと、半年で使いものにならなくなります。
分けてあれば、散らかっても被害はそのフォルダの中で止まります。

ここまでで決まらなかった人だけ、質問1を見てください。
主に扱うのがコードなら、テーマ特化型です。
文書や調査が中心なら、汎用ワークスペース型です。
テーマをまたいだ横断が効くのはこの型だからです。
扱うテーマがはっきり分かれず流動的な使い方の人も、汎用ワークスペース型です。

この4つは、公開データの裏付けがあるものではありません。
実践者の構成と、その人たちが何を理由に選んだかを突き合わせた、この記事なりの整理です。
実際、型ごとの利用者数を調べた統計は、探した範囲では見つかりませんでした。

3つは排他ではない

型を1つ選べ、という書き方をしてきましたが、実際には混ぜられます。
チームで共有する設定と自分だけが使う設定を別々に置ける仕組みが、公式に用意されているからです。
指示ファイルにも同じ使い分けがあります。

一人で使うものと人に見せるものを分ける運用は、実際に機能します。
私も公開する予定があるものと手元だけのものは置き場から分けていて、この線引きは今のところ破綻していません。
ファイル名まで含む具体的な話は、後半にまとめて置きます。

だから最初の判断は「どの型で始めるか」だけで足ります。
テーマ特化型で始めて、共通で使いたいものが溜まってきたら共通の置き場を1つ足す。
気づいたら汎用ワークスペース型に近づいていた、という進み方でも問題ありません。

設計ごとAIに聞き取ってもらう

自分で決めるのが面倒なら、聞き取りから任せられます。
この手順は、手元に Claude Code か Codex がある前提で書いています。

貼る前に、置き場所だけ決めてください。
新しく空のフォルダを1つ作ります。
置き場所はどこでも構いませんが、名前は日本語やスペースを含まないものが無難です。
そのフォルダで Claude Code（または Codex）を起動してから、次の文を貼ります。
すでに使っている作業フォルダで貼ると、そこにファイルが作られてしまうので避けてください。

Codex を使っている場合は、文中の CLAUDE.md を AGENTS.md に読み替えてください。

起動したあとのチャット欄に、次の文をそのまま貼ります。

私のAIの使い方を聞き取って、作業フォルダの構成を提案してほしいです。
候補は3つあります。

1. テーマごとにフォルダを分ける型
2. 1つの大きなフォルダに全部集めて、指示ファイル1枚で管理する型
3. 資料とメモの置き場を主役にして、AIにそこを参照させる型

次の4点を1問ずつ質問してください。
まとめて聞かず、1つ答えたら次に進んでください。

1. 私が主に扱うのはコードか、文書や調査か
2. 中身を誰かに見せたり共有したりする予定があるか
3. フォルダの整理に定期的に時間を使う気があるか
4. 資料やメモを貯めること自体が目的か

聞き終わったら、3つのうちどれが合うかを理由つきで1つ選んでください。
そのうえで、初期のフォルダ構成と、最初の CLAUDE.md（Codex なら AGENTS.md）の中身を作ってください。
作る前に、どういう構成にするつもりかを一覧で見せてください。

貼ると質問が順に来て、答え終わるとおすすめの型が1つ返ってきます。
そのままフォルダと指示ファイルの作成まで進みます。

末尾の「作る前に、どういう構成にするつもりかを一覧で見せてください」は消さないでください。
フォルダを作る作業は後から直しにくく、最初の一覧を見た時点で違和感に気づけることが多いからです。

指示ファイルの中身は、最初は短くて構いません。
むしろ短いほうがよく、理由は毎回すべて読まれる点にあります。
長いほど、毎回の負担がそのぶん増えます。

前半はここまでです。
4つの質問に答えて、出てきた型でフォルダを1つ作るところまでやれば、実用上は足ります。

ここから先は、データと実例

なぜその判断でいいのか、公開されている数字と実例で裏を取っていきます。

84.9% という数字と、そこに映らないもの

海外の開発者サイトが「State of Claude Code 2026」として公開している、公開リポジトリ2,500件を調べた2026年6月の集計があります。
そのうち CLAUDE.md を持っていたのが84.9%、.claude/ という隠しフォルダを持っていたのが62.1%でした。
個人による単一の集計で第三者の追試はないため、傾向をつかむ参考値として読んでください。
先頭がドットで始まる名前のフォルダは、通常の表示では出てきません。
スキル（AIに手順を覚えさせる仕組み）が28.1%、サブエージェント（本体とは別に立てる作業用のAI）が24.6%、MCP（外部サービスとAIをつなぐ仕組み）が17.0%でした。

数字だけ見ると、分ける型が主流に見えます。
ただ、この集計が数えているのは公開リポジトリだけです。

汎用ワークスペース型のフォルダは、まず公開されません。
仕事の資料も個人のメモも過去の経緯も同じ場所で混ざっているので、そのまま人に見せられる状態ではないからです。
第2の脳型も同じ理由で表に出てきません。
手元にしかないものは、この種の集計では0件として扱われます。

だから84.9%という数字から言えるのは「公開されている構成の中では、指示ファイルはほぼ標準装備になっている」までです。
どの型が多いかは、前半で書いたとおり、この数字からも他の統計からも分かりません。

全部入りを組んでいる人たちの構成

汎用ワークスペース型の実例は、探した範囲では7件ほどしか見つかりませんでした。
そのうち具体的な構成まで書かれているものを挙げます。

開発者の Simon Willison は、AI専用の独立したリポジトリを持つほうがずっと自由だと書いています。
research と名付けたリポジトリの中に13個のフォルダがあり、一番上の階層に置く指示ファイルは1枚だけです。
公開用と非公開用の2つのリポジトリを使い分ける運用になっています。

日本語では、雑務をまとめた1リポジトリで回している例が Qiita に出ています。
tasks/ の下に日付とテーマを組み合わせたフォルダを作り、各作業に計画・仕様・やること・分かったことの4点セットを置く形です。
ただし、コードの案件だけは別リポジトリに分けています。
実質はハイブリッドです。

テキスト業務向けには、受信箱・参照資料・下書き・完成品・書庫という並びのフォルダを1つのワークスペースに置いた構成が note で公開されています。

ここまでが汎用ワークスペース型で、ここから1件だけ第2の脳型の実例を挙げます。
記憶を性質ごとに分けた構成が、英語圏で紹介されました。
出来事の記録・知識・手順の3つへ分け、その横に進行中の案件・受信箱・書庫を置く形です。
トピックではなくライフサイクルで分ける、という考え方になります。

共通しているのは、フォルダの意味づけを自分で決めている点です。
そして、破綻したときの条件や維持コストを書いている人は1人も見つかりませんでした。
新しいカテゴリなので、失敗事例がまだ表に出ていないのだと思います。

混ぜるための仕組みと、1つの落とし穴

前半で触れた共有用と個人用の分離は、具体的にはこうなっています。

設定ファイルは settings.json と settings.local.json の2枚立てです。
前者をチームで共有し、後者は個人用として共有対象から外します。
MCP の設定も同じ考え方で、作業フォルダの一番上の階層に置く .mcp.json がチーム共有にあたります。
利用者ごとの設定置き場（ホームディレクトリ）にあるほうが個人用です。
指示ファイルにも CLAUDE.md と CLAUDE.local.md の使い分けがあります。

もう1つ、置き場所の階層にも定石があります。
指示ファイルは、ホームディレクトリ側（~/.claude の中）にも置けます。
そこに書いた内容は全プロジェクトに効くので、増やしすぎると無関係な作業まで影響を受けます。
公式の設計も、日本語と英語の解説記事も、全体側は薄く保ってプロジェクト側に具体を書く、という二層をすすめています。
最初に全体側へ大量のルールを書き込むと、あとから妙な挙動の原因を特定できなくなります。

一方、もっと大胆に分ける方法もあります。
設定フォルダの場所を指す環境変数（OS側に置いておく設定値で、起動したツールがそれを読みます）を切り替えて、仕事用と個人用を丸ごと別立てにするやり方です。
実際に試した記録が Qiita にあり、結果は思っていたほどきれいに分かれませんでした。
分離しきれずにルールが二重に読み込まれ、毎ターン100KBを超える量が渡っていたという報告です。
100KBは、UTF-8 の日本語なら1文字がおよそ3バイトなので、3万字強にあたります。
毎回それを読ませてから作業が始まる、と考えると重さが想像できると思います。

使い分けの仕組みは公式に揃っています。
一方で、どういう基準で使い分けるかを言語化した記事は、探した範囲では日英どちらにも見つかりませんでした。
前半の4つの質問を作ったのは、その空白を自分で埋めるためです。

「半年ごとに全部消せ」と、10KB超が33.8%

型の話とは別に、量の話があります。

Claude Code の開発を率いた Boris Cherny の発言として、こんな趣旨が伝えられています。
半年ごとに指示ファイル・スキル・自動化の仕掛けを全部消して、モデルが素の状態で何をするか見たほうがいい、という内容です。
一次の原典は確認できていないので、そういう発言が流通している、という水準で受け取ってください。
主張の中身は分かります。
モデルが賢くなれば、去年の工夫の多くは要らなくなる。

現実の数字はどうかというと、先ほどの集計で CLAUDE.md のサイズの中央値（真ん中の値）は6.2KBでした。
行数にすると100行から150行くらいです。
公開されているものの真ん中の値であって、推奨値ではありません。
短く保つ話は別の記事に書いています。
10KBを超えるものが33.8%あり、最大は341KBでした。
消すどころか、積み上がっています。

反発の声もあります。
Hacker News では、半年ごとにワークフローを作り直せというのは乱暴だ、という指摘が出ていました。
なお、この記事で参照したコミュニティの反応は Hacker News と Zenn、note、Qiita、それに実践者の個人ブログの範囲です。
Reddit と X は今回取得できていません。

削る側の実践も出てきています。
使用ログを解析したら、用意した40個のスキルのうち35個が一度も使われていなかったという報告が Zenn にあり、85%を削除しています。
作った時点では全部要ると思っていたはずです。

どの型を選んでも、増えたら削る作業からは逃げられません。
テーマ特化型なら使わなくなったフォルダごと、汎用ワークスペース型なら指示書の行数と資料の総量、第2の脳型なら参照させる範囲が対象になります。
削り方については書きたいことが溜まってきたので、次回そこだけを扱います。

まとめ

• 作業フォルダの型は3つに分かれる（テーマ特化型、汎用ワークスペース型、第2の脳型）

• 迷っているならテーマ特化型から始めるのが無難で、見通し・共有のしやすさ・失敗時の被害の小ささで有利

• 全部入りの汎用型は横断が効く代わりに肥大するので、整理の時間を確保できる人向け

• 第2の脳型は資料と記憶を貯めること自体が目的の人向けで、参照範囲を絞る工夫が要る

• 公開リポの84.9%という数字は分離型しか観測できておらず、どの型が多数派かの根拠にはならない

• 型を1つに決める必要はなく、共有用と個人用を分ける公式の仕組みで混ぜられる

次の一手は1つだけです。
4つの質問に答えて、出てきた型でフォルダを1つ作ってください。
自分で決めきれないなら、上のプロンプトを貼って聞き取りから任せてしまえば済みます。

宣伝：デスクトップを「壁紙だけ」にする猫ランチャーを作りました

最後にひとつだけ宣伝です。

散らかったデスクトップのアイコンをまるごとあずけて、画面を壁紙だけにするWindows用ランチャー「NyanDeck」をBOOTHで公開しています。
配信や画面共有でデスクトップが映る事故を防ぎたい人向けに作ったもので、ワンクリックで中身を隠す目隠しモードや、画面の端に格納してホバーで呼び出す機能があります。

無料版だけでも普通に使えるので、デスクトップが散らかっている自覚のある方はどうぞ。

どういうツールかは紹介記事にまとめています。

ダウンロードはこちらから。

この記事が参考になったら、ぜひ「スキ」をお願いします。

あわせて読みたい

フォルダと指示ファイルを整えるのは、AIの周辺環境を整える作業の一部です。
その全体像はこちらに書きました。

決めごとを会話でなくファイルに置く理由は、こちらで詳しく扱っています。

フォルダの中でAIをどう分業させるかは、こちらです。