こんなフォルダ構成を見たことがあるだろう。
顧客管理/
├── A社/
│ ├── 提案書/
│ ├── 議事録/
│ └── 報告書/
├── B社/
│ ├── 提案書/
│ ├── 議事録/
│ └── 報告書/
└── C社/
├── 提案書/
├── 議事録/
└── 報告書/一見すると、非常に整理されている。顧客名をクリックすれば、その顧客に関するすべてのファイルがある。新入社員でもすぐにたどり着ける。
これが、よくある勘違いの正体だ。
この構造は「人間がブラウザやExplorerで目視して探す」ことに最適化されている。つまり、設計の前提が「人がフォルダを開いて、ファイルを見つける」という行為にある。
問題は、この前提が3つの致命的な弱点を生むことだ。
弱点1：運用が「わかっている人」に依存する
顧客別フォルダの構造を正しく維持できるのは、その顧客を担当している人間だけだ。A社の提案書をA社フォルダに入れるのは、A社を担当している人間にしかできない。担当が変われば、ファイルは迷子になる。
しかも現実の業務は、こんなにきれいに「顧客単位」では割り切れない。たとえば——
- 社内横断プロジェクトの議事録：A社・B社の両方が絡む共同案件の議事録は、A社フォルダに入れるのか、B社フォルダに入れるのか。判断は担当者次第になり、後から探す人は両方のフォルダを開くハメになる。
- 部門をまたぐ提案書：営業が作った提案書を開発チームがレビューする。開発側は「技術レビュー/」フォルダに置き、営業側は「A社/提案書/」に置く。同じファイルが2箇所に存在し、どちらが最新かわからなくなる。
- 退職・異動時の引き継ぎ：前任者が独自のサブフォルダ（「重要/」「一時保管/」「古い/」）を作っていて、何がどこにあるか本人以外には解読不能。結局、後任者は自分流の構造を一から作り直す。
- 経費精算や契約書の管理：「A社/契約書/」にあるのか、「管理部/契約書/A社/」にあるのか。管理部と営業部がそれぞれ別の場所にコピーを持ち、片方だけ更新される。
共通しているのは、「正しい場所に入れる」という判断自体が属人的なスキルになっていることだ。ルールを決めても、例外が発生するたびに「この場合はどこに入れるんだっけ？」とSlackで聞くことになる。フォルダ構造の維持が、それ自体ひとつの業務になってしまう。
弱点2：横串が効かない
「今月、全顧客に出した提案書を一覧で見たい」。この当たり前の要求に、上記の構造は応えられない。A社/提案書、B社/提案書、C社/提案書……と、すべてのフォルダを巡回する必要がある。人が管理する構造は、人が探索する前提でしか機能しない。
弱点3：SaaS化すると形骸化する
最も深刻な問題がこれだ。
このフォルダ構造を「そのまま」SaaSの管理画面に載せ替えるとどうなるか。入力フォームが増え、分類項目が増え、「正しいフォルダに正しく入れる」ことが義務になる。最初は使われる。しかし半年後、入力されないフィールドが増え、形骸化したデータベースだけが残る。
なぜか？ フォルダの維持を人間に依存しているからだ。
「見やすいフォルダ」は「人間が正しく入れ続ける」ことを前提にしている。その前提が崩れた瞬間、構造全体が意味を失う。
AIネイティブな構造：「誰が見るか」ではなく「何が実行するか」
では、どう設計すべきか。
Company as a Filesystem（CaaF）の考え方では、ディレクトリは「人が見つけやすい場所」ではなく、「エージェント（役割）の責務境界」として設計する。
proposal/ ← 提案書エージェントの管轄
├── A社_2026Q1.md
├── B社_2026Q1.md
└── C社_2026Q1.md
meeting_notes/ ← 議事録エージェントの管轄
├── A社_20260310.md
├── B社_20260312.md
└── weekly_20260311.md
reports/ ← 報告書エージェントの管轄
├── A社_月次_202603.md
└── B社_月次_202603.md一見すると「顧客軸がなくなって不便じゃないか？」と思うかもしれない。しかし、ここが発想の転換点だ。
顧客軸の横断検索は、エージェントが一瞬でやる。 人間がフォルダをクリックして探す必要がない。
一方で、「今月の全提案書を見たい」「議事録のフォーマットを統一したい」「報告書の提出漏れをチェックしたい」——これらは同じ種類のファイルが一箇所にあるからこそ、自動化できる。
つまり、こういうことだ。
| 設計の前提 | フォルダの軸 | 維持する主体 | 弱点 |
|---|---|---|---|
| 人が探す | 顧客別 | 担当者（人間） | 属人化・形骸化 |
| エージェントが管理する | 役割別 | エージェント（AI） | 人が直接探すには不向き |
AIネイティブな組織は、後者を選ぶ。 そして「人が探す」部分は、エージェントに聞けばいい。
OpenClawが流行る理由もここにある——かもしれない
ここからは推測だが、オープンソースのAIエージェント「OpenClaw」が爆発的に広まっている理由も、この文脈で説明できるのではないか。
OpenClawの特徴はブラウザ操作だ。Chrome DevTools Protocolを使い、AIエージェントが直接ブラウザを操作する。ウェブサイトを開き、フォームに入力し、情報を取得する。
これは裏を返せば、「人間がブラウザで管理画面を開いてデータを入力する」という行為そのものを、エージェントが代替しているということだ。
多くのSaaSは「人が画面を見て、入力する」前提で設計されている。だから入力が滞れば形骸化する。OpenClawはその前提をひっくり返した。人がブラウザを操作するのではなく、エージェントがブラウザを操作する。 既存のSaaSの画面構造を変えることなく、「入力する主体」だけを人間からAIに置き換えた。
OpenClawがウケているのは、技術的にすごいからだけではない。「人間がフォルダを整理する」「人間がフォームに入力する」という、組織の形骸化の根本原因を、アーキテクチャのレイヤーで解決しているからだ。
まとめ：フォルダは「住所」ではなく「責務」で切る
- 「見やすいフォルダ」は人間の目視検索に最適化されているだけ
- 人間に依存する構造は、SaaS化しても形骸化する
- AIネイティブな設計は、フォルダを「エージェントの責務境界」として構造化する
- 横断検索はエージェントに任せる。人間はフォルダを開かない
- OpenClawの流行は、「人がブラウザで管理する」というボトルネック自体をエージェントが代替した結果
「きれいに整理されたフォルダ」を作ることが目的ではない。「整理しなくても回る仕組み」を設計することが、Company as a Filesystemの本質だ。
