「フォルダ設計」でClaude Code・Codexとの仕事が変わる
迷わず渡せる5つの型

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、いまにゅのAIプログラミング塾さんの「フォルダ設計」動画から、Claude CodeやCodexとの仕事が変わる5つの型を紹介するね。

出典: 【知らなきゃ損】CodexやClaude Codeの力を最大限引き出すAIのフォルダ設計を教えます（いまにゅのAIプログラミング塾）

動画の冒頭、いまにゅさんはこう問いかけます。同じツールを使っているのに、ある人のAIは資料をすぐ見つけて仕事を進めてくれる。一方で自分のAIは毎回同じ説明を求めてくる。その差を生むものとしていまにゅさんが挙げるのが、AIにどのフォルダを見せているか、どんな名前のファイルを置いているか、成果物をどこへ戻すか、です（2:38頃〜）。モデルや頼み方が関係ないという話ではありません。この記事では、フォルダの側に絞って見ていきます。

いまにゅさん

「フォルダはファイルの整理棚であると同時に、AIに渡す仕事場でもあるということです」（2:38）

耳が痛い話でした。実は私も今、「外壁塗装リフォームの集客代行」の案件を一人で抱えています。AIチームに手放したいと思いながら、まだ渡しきれていません。

診断だと私は「ビジョンを描いて人を動かすシェフ」のはずなのに、気づくと自分でキッチンに立って鍋を振っているんですよね。いまにゅさんの「フォルダは仕事場」を聞いて、あ、そうかと思いました。渡す場所が整っていないから、任せたつもりでも結局自分で全部見返すことになる。道具を渡さずに「あとよろしく」と言っていたのと同じでした。

だから、どこに何を置くかという土台を後回しにせず、仕事場そのものを整えるところから始めたいと思います。

名前だけ変えてみる：今AIに渡しているフォルダを1つ開いて、中のファイル名を3分だけ見直してください。見るのは、名前を読んだだけで中身が分かるかどうか。「資料1」のような名前が1つでも見つかったら、それが最初に整える箱です。例えば「原稿」「判断の根拠」「成果物」のように、中身の種類を名前に入れるのも一案です。

1つ目の事例は、Claude Code開発者として紹介されていた人物の公開方針です。company-project直下の共通CLAUDE.mdを薄くし、領域ごと・作業ごとにファイルを分ける考え方でした。毎回読む薄いルールと、その場面だけで読む細かい手順を、はっきり分けているのが特徴でした（8:16頃〜）。

いまにゅさん

「全ての指示を一枚へ詰め込まないということです」（8:16）

「名前を見れば次に何を読めば良いか分かる」という説明も、まったく同感でした。うちのAIチームも、実は同じ考え方を使っています。作業フォルダの一番上に置くルールには「触っていい場所」「触ったらいけない場所」のような薄い決まりだけを書いて、プロジェクトごとの細かい作業手順は別のファイルに逃がしています。

私の記事より（2026-09-07公開：Claude 5 世代の CLAUDE.md 最適化：記事の手順をうちで実測して当てはめた結果）

で、今回実際に進んだのはこっちです。うちには、Cockpitというツール全体をまとめて動かす「司令塔役」のAI（Master Agentって呼んでる）がいて、そのAIが最初に読み込む案内書が663行。中身のほとんどは、Cockpitの各機能の使い方を並べた分厚い操作マニュアルを、毎回全部読み込ませていた状態です。

この529行分の細かい操作マニュアルを、別に置いてある専用の参考書（skillって呼んでる仕組み）へ丸ごと引っ越し。司令塔の案内書には、①必要な時だけその参考書を読みに行くこと、②このプロジェクトでは決まった操作コマンドを使うこと、③このプロジェクト特有の安全ルールを優先すること、の3つだけを残しました。結果、663行が141行に。レシピ本を丸ごと持ち歩くのをやめて、必要な料理のページだけその場で開きに行く形にした感じですね。

引用の「663行が141行に」は、司令塔役のAIが最初に読む案内書の行数が変わった記録です。速さや仕上がりの良さまで、この数字で示したわけではありません。

一番読まれるファイルを1つ薄くする：今AIに読ませている一番大きな指示ファイルを1つ選んで、次の順で小さく試してみてください。

1. まず元のファイルの控えを取る。
2. 次に、毎回要る決まりと、特定の作業の時だけ要る手順に分ける。
3. 手順を別ファイルにしたら、どの依頼の時にどこからそのファイルを読ませるかを、元の指示ファイルに書いておく。
4. そのうえで、自分が許可した小さな作業を1つ頼み、結果が指示どおりかを照らし合わせます。AIが「読みました」と答えただけでは確かめたことにならないので、結果で見てくださいね。
5. 合わなければ、控えを使って元に戻し、戻した後も前と同じように動くかを確かめてくださいね。

2026年11月4日に公式の説明で確かめた、今の仕様も添えておきます。Claude CodeのCLAUDE.mdで「@ファイルの場所」と書いて取り込んだファイルは、元のCLAUDE.mdと一緒に読み込まれます（Claude Code公式：メモリ）。分ければ整理はしやすくなりますが、読み込む量が減るとは限らないんですよね。

Codexは、作業を始める時にAGENTS.mdなど決まった名前のファイルを決まった順で探して集めます（Codex公式：AGENTS.md）。好きな名前の別ファイルを置くだけで自動で読まれるとは言えないので、使っている製品と設定の説明を見てから分けてください。

2つ目の事例は、AI研究者として紹介されていた人物が公開した「LLM Wiki」という考え方。raw(原文)とwiki(原文から作った知識)を分けるフォルダ構成でした。元の記事や論文はrawへ、そこから作った要点はwikiへ、という役割分担が徹底されていました（10:46頃〜）。

いまにゅさん

「ローは証拠です」（続けて）「ウィキはその証拠をもとに、原文をもとに作った、繰り返し使える知識です」（10:46〜10:49）

料理に例えると、これはまさに「セカンド冷蔵庫」の発想だと思いました。自分のキッチンに全部の食材を並べっぱなしにすると、身動きが取れなくなる。でも別の冷蔵庫に預けておけば、捨てていないから安心だし、必要な時に取りに行けます。私はこれを「所有権の分離」と呼んでいて、解決策は「捨てる」じゃなくて「分身AIに預ける」ことだと思っています。

といっても、rawとwikiは、よく使うかどうかで分けるものではありません。原文と、そこから作った知識という、中身の種類で分けるものです。この比喩で言いたいのは、原文を捨てずに預けておける安心のほうです。

私は1つの話題から10個くらいアイデアが湧くタイプで、基本的に全部捨てたくない人間です。だから「捨てる」を前提にした整理術は、正直これまで一度も続いたことがありません。

でもrawとwikiを分けるやり方なら、捨てずに済む。原文を残す場所と、そこから作った知識を置く場所を分ければ、欲張りな性格のままでも散らかりにくくなりそうだと感じました。

「証拠」と「まとめ」を別ファイルに分ける：今調べている資料を1つ選び、元の資料(証拠)と自分の結論(まとめ)を、別々のファイルへ分けて保存してみてください。例えば顧客ヒアリングなら、聞いた原文を1つのファイルに、要点と、その要点が原文ファイルのどの見出し・どの箇所から来たか（ファイル名と見出し名など）をもう1つのファイルに、という対にします。

図の「計画する」で人が見るのは、作り始める前に方針がずれていないかです。できあがった物が計画どおりかを照らすのは、最後の「確認する」の役目。小さな作業の一つ一つで、毎回人の承認を待つ仕組みにする話ではありません。

3つ目の事例は、開発運用の考え方として紹介されていたもの。research(調査)→plans(計画・ここで人間が確認)→成果物→prs(確認依頼)という流れでした。4つのフォルダを順番にたどるだけで、いきなり完成物へ飛びつかない仕組みになっていました（13:40頃〜）。

いまにゅさん

「悪い調査から悪い計画が生まれていき、悪い計画から大量の悪い成果物が生まれます」（13:40）

私もAIに仕事を頼む時は、いきなり成果物を作らせるんじゃなくて、まず「何を調べたか」「その上でどう進めるつもりか」を一回見せてもらうようにしています。わからないことは憶測しないで聞いてほしいし、逆に一回教えたことを2度聞かれるのはしんどい。既存の記録で分かることはAI自身が調べて、人間には調べても記録にない部分だけを聞いてほしいんですよね。Human Layerの「調査→計画→人間確認」の順番は、たぶんこの境界線を仕組みにしたものなんだと思います。

この順番を守るだけで、後から「思っていたのと違う」というやり直しがぐっと減るんじゃないかと感じました。委ねる相手が人間でもAIでも、条件は同じだと思います。委ねた先が「嘘をつく・逃げる・やらない」なら、そもそも任せられない。先に調べて、先に計画を見せてもらう仕組みがあるからこそ、安心して次の工程を渡せるようになります。

作らせる前に「計画」だけ見せてもらう：次にAIへ大きめの作業を頼む時は、いきなり本番を作らせず、先に「進め方の箇条書き」だけを1回見せてもらってから本番に進めてください。

4つ目の事例は、常駐型AIエージェントのワークスペースとして紹介されていたもの。SOUL.md・IDENTITY.md・USER.md・MEMORY.mdなど、役割ごとにファイルが並んでいました。誰なのか・どう働くのか・何を覚えるのかが、それぞれ別のファイルに書き分けられていました（25:49頃〜）。

いまにゅさん

「役割を一文で説明できるフォルダは」（続けて）「人間にもAIにも使いやすくなります」（25:49〜25:52）

私の記事より（2026-09-13公開：「AGENTS.mdを全員に読ませるな」深津貴之さんの経営論を尾原和啓さんが解説。監督と実務を分けるとAIコストは半分になる）

誰が何を読むかを役割で決めると、確認のための確認が消える。

「MEMORY.mdは魔法の記憶じゃない」という話には、グサッときました。動画の事例では、SOUL・MEMORY・TOOLSのように役割の名前でファイルが分かれていました。性格と、覚えておくことと、道具の使い方を1つのファイルに混ぜると、AIも人間も同じで、大事な部分がどんどん埋もれていきます。ただ、同じ名前のファイルを置くだけでClaude CodeやCodexが同じように動くわけではなく、どのファイルをいつ読むかは道具ごとの仕組みで決まります。深津さんの「AGENTS.mdを全員に読ませるな」の記事とも通じる話だなと思って読みました。役割を混ぜないというのは、結局「誰が・いつ・何を見るか」を先に決めておくということなんだと思います。

「全部覚えておかなきゃ」も、実は同じ構造の抱え込みだと今回気づきました。記憶を1箇所に全部詰め込もうとするから、大事な違和感まで埋もれてしまうんですよね。

人格・記憶・手順を別ファイルに分ける：今1つのファイルに書いている「性格・記憶・手順」のうち、どれか1つだけを別ファイルへ切り出してみてください。進め方は第02章の最後と同じで、控えを取る、いつどこから読ませるかを書く、小さな作業で指示どおりか照らす、合わなければ控えに戻す、の順です。

最後の事例は、いまにゅさん自身が過去に紹介したという「秘書型」の構成。inbox(依頼受信)→notebook(作業中)→outbox(完成)→archive(保管)という4つの箱でした。アンケート分析から報告書作成までの実例つきで、依頼から保管までの流れが具体的に示されていました（23:44頃〜）。

いまにゅさん

「情報を増やすことよりも、役割と読むタイミングを分けていくことが大切です」（23:44）

私の記事より（2026-09-14公開：ＡＩへの指示は、スタッフ全員に見せるべきなのか）

実務のAIには実務の指示を渡す。意図と責任は、監督である私が持つ。

依頼を受け取って、作業して、返して、しまう。この4つの流れは、うちの外壁塗装の案件にもそのまま使えそうだなと思いながら見ていました。「1本完璧に作って、仕組み化してから量産する」というのは、私がずっと言ってきたことと同じ構造です。この記事でも書きましたが、誰が何を見るかを先に決めておくと、あとが本当に楽になります。

全部盛りにする必要はなく、困った時に、困った分だけ箱を足せばいい。最初の1本で残すべきは、表面のやり方じゃなくて「なぜこの順番なのか」という判断軸のほうだと思います。その1本さえ丁寧に作れば、あとは仕組みに乗せて量産しても、想いは薄まりません。

受け取った依頼をフォルダで追いかける：今抱えている依頼を1つ選び、「受け取った」「作業中」「返した」のどの段階かを、フォルダかリストで1回だけ書き出してみてください。

27分の動画を見終わって残ったのは、「AIにどれだけ賢く指示するか」と並んで、「AIにどう仕事場を渡すか」という視点の大切さでした。5つの事例は、形がそれぞれ違います。

この記事では、それを「情報の入口・判断基準・作業中の置き場所・完成物の行き先・記憶と保管」という5つの役割で整理していきます。どの事例にも5つが全部そろっているという意味ではなく、私なりの見る視点です。

私たちがAIに仕事を渡す時も同じだと思います。名前を分かりやすくする、証拠と結論を分ける、調べてから決める、性格と記憶を混ぜない、受け取ってしまうまでを追いかける。この5つを一気に完成させる必要はありません。まずは各章の最後に書いた一手から1つだけ選んで、今日やってみてください。

うちも外壁塗装の案件を、この5つの型のどれか1つから整え直してみようと思っています。完成した仕組みを一気に真似るより、今つまずいている1箇所だけを直す方が、結局は長続きする。フォルダは地味な話に見えて、実はAIへの信頼をどう形にするかという、けっこう本質的な話なんだと、今回あらためて思いました。