organize

Organization スキル

バージョン： 1.2 ソース： L1/L2/L3 認知フェーズフレームワーク

フォルダー構造は、データベースでレコードを保存する方法ではなく、脳がたどる経路に合わせるべきです。

---

北極星

目標： 自分がどこにいて、何を探しているのかを常に把握できることです。

定義： 誰でも（AI も含めて）、どのフォルダーにあるかを推測することなく、3 回以下の判断でファイルを見つけられることです。

問題の兆候： フォルダーを開いて迷ったと感じるなら、その構造は機能していません。

---

クイックスタート

必要なものがすでにわかっている場合は、ここから始めてください。

したいこと	移動先
個人用／ホームドライブを整理する	assets/home-drive-template.md — 活動領域を選び、L2 を構築し、L3 は自然に形成させます
ビジネス／チーム用ドライブを整理する	assets/work-drive-template.md — Fulfill/Maintain/Grow フレームワーク
散らかった既存ドライブを再編する	references/migration-guide.md — フェーズごとの移行
ファイルとフォルダーに適切な名前を付ける	references/naming-patterns.md — レイヤーごとの規則
構造上の問題がないかドライブを監査する	scripts/audit_structure.py <path> — 自動ヘルスチェック

フレームワークの詳しい説明は、以下をお読みください。

---

L1/L2/L3 フレームワーク

フォルダーのナビゲーションは、3 つの認知フェーズで構成されます。各フェーズは異なる問いに答えるもので、フォルダー名はそのレベルで行う思考の種類に合わせるべきです。

L1：コンテキスト（名詞／活動領域）

問い：「自分はどこで活動しているのか？」

脳のモード： 方向確認。作業に取りかかる前に、領域内で自分の位置を把握します。

フォルダー名は通常、名詞 — 活動の大まかな領域です。同じ方向確認の切り替えを促すなら、考え方に基づく動詞（例：Fulfill、Maintain、Grow）も使えます。

Drive/
├── Finance/
├── Marketing/
├── Operations/
├── Production/
├── Legal/
└── Personal/

判定基準： 領域を絞り込んでいる間は、L1 のままです。クリックするたびに「自分はどの世界にいるのか？」に答えているなら、複数のフォルダーをたどっても L1 のままである可能性があります。

成功条件： 脳が自然に「自分はどこにいるのか？」から「何をしようとしているのか？」へと切り替わります。

L2：実行（動詞／成果／主題カテゴリ）

問い：「何を達成しようとしているのか？」— または、創作系／専門領域が中心のプロジェクトでは —「どの種類のものに取り組んでいるのか？」

脳のモード： 目標設定。活動領域を選んだら、次は目的または主題を選びます。

フォルダー名は動詞、成果、または主題カテゴリ — ここで行う作業を表します。

Marketing/                    # Business example — verbs/outcomes
├── Launch/
├── Grow/
├── Campaign/
├── Brand/
└── Analyze/

Arctic/                       # Creative example — subject categories
├── Locations/                # "I'm working on PLACES"
├── Residents/                # "I'm working on CHARACTERS"
└── Lore/                     # "I'm working on STORY"

L2 で動詞名を使う必要はありません。 創作、世界構築、または専門領域が中心のプロジェクトでは、主題カテゴリ（Locations、Characters、Assets、Environments）が、脳を方向確認から意図へと切り替えるなら L2 として機能します。判定基準は、フォルダー名が動詞かどうかではなく、脳のモードが切り替わるかどうかです。

判定基準： 目的、作業モード、または主題を絞り込んでいる間は、L2 のままです。特定の成果物を探し始めた時点で、L2 は完了します。

成功条件： 脳が「何をしているのか？」から「どのものが必要なのか？」へと切り替わります。

L3：検索（オブジェクト／成果物）

問い：「具体的に何が必要なのか？」

脳のモード： 取り出し。成果を選んだら、必要なものを手に取ります。

フォルダー名は具体的なオブジェクト — 成果物そのものです。

Campaign/
├── Q1-2025-Product-Launch/
│   ├── Brief.docx
│   ├── Timeline.xlsx
│   ├── Assets/
│   └── Results.pdf
└── Q2-2025-Brand-Refresh/
    └── ...

判定基準： 特定のファイルや成果物を探しているときは、L3 です。何が必要かわかっていて、それを見つけるだけの状態です。

---

重要な原則：レイヤーは認知フェーズです

レイヤーは文字どおりのフォルダー数ではありません。ナビゲーション中の心の状態を表します。

シナリオ	クリックしたフォルダー数	実際のレイヤー
Work > Clients > Acme Corp	3 つのフォルダー	まだ L1 — 「どの世界か？」に答えている段階です
Finance > Accounts Payable	2 つのフォルダー	L1 → L2 の移行 — 領域から成果へと切り替わりました
Campaign > Q1 Launch > Brief.docx	3 つのフォルダー	L1 → L2 → L3 — 認知フェーズをすべて進みます

判定基準は「フォルダーはいくつか？」ではなく、「脳のモードが切り替わったか？」です。

---

診断ガード

構造が壊れている、またはレイヤーが欠けていると診断する前に、次の点を確認してください。

確認項目	該当する場合 →
ユーザーは迷わずに、3 回の判断でファイルにたどり着けますか？	構造は機能しています。再構成しないでください
フォルダー名がフレームワークの用語と一致していなくても、認知上の切り替えは発生しますか？	レイヤーは存在しています。動詞／名詞の規則に無理に合わせるために名前を変更しないでください
並行するブランチ間で、構造に一貫性があり、予測可能ですか？	パターンは機能しています。平坦化せず、文書化してください
ドメインは本質的に階層構造ですか（地理、物理空間、分類体系など）？	L1 での広範なナビゲーションは想定内です。L2 が欠けていると誤解しないでください

フレームワークはナビゲーションのためのものであり、その逆ではありません。 迷わずにナビゲーションできるなら、フォルダー名が動詞、名詞、または主題カテゴリのどれであっても、構造は機能しています。理論上のラベルの不一致ではなく、人々が実際に経験する問題を診断してください。

---

足場構造の評価

空のフォルダーが常に不要なものとは限りません。あらかじめ構築されたフォルダー構造は、創作系やコンテンツ中心のプロジェクトで実用的な役割を果たします。「ここは将来のコンテンツ用の枠です」と伝え、並行するブランチ間で一貫性を保てます。空の構造を問題として指摘する前に、それが意図的な足場構造なのか、散在する不要物なのかを判断してください。

意図的な足場構造（その価値を認める）

足場構造は、次の点を満たしていれば機能しています。

シグナル	状況
一貫したテンプレート	同じ構造が並行するブランチ間で均一に繰り返されています（例：すべてのバイオームに同じサブタイプの Locations と Residents がある）
ドメインモデルを反映している	フォルダーテンプレートが、いずれ内容を埋める必要がある実際の構造（分類体系、物理空間、コンテンツパイプラインなど）に対応しています
段階的に埋められている	一部のブランチには実際のコンテンツがあり、ほかはまだプレースホルダーです。テンプレート内で作業が進んでいます
プレースホルダーの規約がある	汎用的な名前（番号付きの枠、「Idea 1/2/3」など）が、コンテンツが追加されたときに名前を変更するための一時的な目印であることが明白です
深さに上限がある	コンテンツのレイヤーに到達するまで、足場構造が 2～3 階層を超える空のフォルダーを含みません

これらの確認項目を満たす足場構造を見つけた場合、削除対象として指摘するのではなく、有用な構造として評価してください。どこにコンテンツが入り、どこにまだ入っていないかを記録しますが、枠組みを取り壊すことは勧めないでください。

例 — 世界構築プロジェクトにおける優れた足場構造：

VR World/
├── Arctic/
│   ├── Locations/
│   │   ├── Commercial/
│   │   │   ├── _Ideas/
│   │   │   └── Winter Lodge Restaurant/    ← named, filling in
│   │   ├── Natural/
│   │   │   └── _Ideas/
│   │   └── Residential/
│   │       └── Dream House/                ← built out with rooms
│   └── Residents/
│       └── Alexander Borealis/             ← named character
├── Forest/                                  ← same template, different fill state
│   └── Residents/
│       ├── Big Bear/                        ← fully developed
│       └── Zebra Fox/
└── Desert/                                  ← same template, less filled
    └── ...

テンプレートに一貫性があり、世界構築のドメイン（バイオーム × コンテンツタイプ）を反映し、実際のコンテンツが段階的に追加されています。空の枠はノイズではなく、コンテンツのロードマップです。

例 — コンテンツパイプラインにおける優れた足場構造：

character-types/
├── bears/images/
│   ├── head/        (31 files)              ← filling in
│   ├── body/        (15 files)
│   └── tail/        (0 files)               ← empty but expected
├── dogs/images/
│   ├── head/        (26 files)
│   └── legs-and-feet/ (28 files)
└── foxes/images/                            ← mostly empty, work not started yet

25 種の生物に共通する体の部位のテンプレートです。クマとイヌには多くのコンテンツがあり、キツネにはまだ着手していません。空のフォルダーは、制作パイプラインにおける作業枠です。

散在する不要物（問題として指摘する）

次のような場合、足場構造は不要物になっています。

シグナル	状況
繰り返しのパターンがない	空のフォルダーが単独で存在し、テンプレートの一部ではありません
並行するブランチが非対称	同じ階層のブランチで、ドメイン上の理由がないのに構造が異なります
どこにもコンテンツがない	ツリー全体が空で、実際のコンテンツがあるブランチがありません
計画のないまま放置されている	数か月前に作成され、使われたことがなく、今後の作業も予定されていません
目的が曖昧	フォルダー名から、どのコンテンツを置く場所なのか判断できません（New Folder、Stuff、temp など）

それぞれのケースで行うこと

見つかったもの	対応
一貫したテンプレートで、現在も活用されている	維持します。 便利な足場として評価します
一貫したテンプレートだが、すべて古くなっている	要確認として挙げます。 放棄された可能性を伝え、今後も作業を続ける予定があるか確認します
パターンの一部が適用されており、適用方法に一貫性がない	パターンを完成させるよう提案します。一貫性を持たせるか、例外を削除します
パターンのない、単発の空フォルダー	削除を推奨します。 コンテンツができた時点でフォルダーを作成します

重要な判断基準

この空フォルダーを削除すると、情報が失われますか？ フォルダー名と場所から「ここは［特定の種類のコンテンツ］を置く場所だ」と分かるなら、それは足場です。削除しても、どこに何を置くのか誰も迷わないなら、それは不要なものです。

---

段階的な開示

このフレームワークでは段階的な開示を採用しており、各レベルでは現在の判断に必要な情報だけを示します。

Step 1: See 5-8 arenas          (L1 — which world?)
Step 2: See 3-6 outcomes         (L2 — which goal?)
Step 3: See the artifacts         (L3 — grab the thing)

各レベルでの理想的な数

レベル	目標	分割を検討する上限
L1 の分野	5-8	12
各分野の L2 成果	3-6	10
各成果の L3 成果物	状況による	30（超えたらサブグループ化）

いずれかのレベルが上限を超えている場合は、分割または再構成を検討する目安です。

---

命名規則

L1 の名前：広範で、安定しており、認識しやすい

パターン	例
名詞を使う	Finance、Marketing、Operations、Legal
大文字で始める	最上位の分野にはタイトルケースを使う
安定させる	これらはめったに変わりません。生活や仕事の領域を表します
日付を入れない	日付は L1 ではなく、L2 または L3 に含めます

L2 の名前：行動を表し、一覧で見つけやすい

パターン	例
動詞または成果を使う	Launch、Grow、Hire、Ship、Fulfill
または、明確なプロセス名を使う	Onboarding、Reporting、Budgeting
期間を含める	繰り返しが重要な場合は 2025-Budget、Q1-Campaign

L3 の名前：具体的で、説明的で、見つけやすい

パターン	例
具体的にする	Invoice.pdf ではなく Invoice-2025-03-Acme.pdf
時系列には日付を先頭に付ける	2025-03-15_Meeting-Notes.md
一覧で見つけやすいように種類を末尾に付ける	Logo-Primary.png、Logo-Dark.png
曖昧さをなくす	すべての名前を、検索で見つけられる程度に一意にする

すべてに共通する命名規則

規則	理由
大文字・小文字の使い方を統一する	各レベルでタイトルケース、ケバブケース、スネークケースのいずれかを選び、一貫して使います
識別に役立つ語を先頭に置く	日付順の並び替えを優先する場合を除き、2025-Budget ではなく Budget-2025 にします
特殊文字を使わない	A-Z、0-9、-、_、適切な場合はスペースを使います

コンテキストに応じた命名規則

コンテキスト	スペースを使ってよいか	ハイフン／アンダースコアが必要か	理由
個人用／クリエイティブ用ドライブ	はい	いいえ。読みやすさを優先します	Winter Lodge Restaurant は Winter-Lodge-Restaurant より読みやすく、OS はスペースを標準で扱えます
コードプロジェクトとウェブサイト	いいえ	はい。ハイフンまたはアンダースコアを使います	スペースはスクリプト、URL、CLI コマンド、バージョン管理で問題になります
共有／チームドライブ	場合によります	チームの慣例に合わせます	単一の規則より、チーム内の一貫性が重要です

個人用ドライブにコード向けの規則を適用したり、コードベースに個人用の規則を適用したりしないでください。 環境に合わせて規則を選びます。

ファイル名の意味

ファイル名を見ただけで、内容がすぐに分かるようにします。適切なファイル名なら、開かなくても「これは何か」という問いに答えられます。

意味のない名前（フラグを付ける）

パターン	例	問題点
ハッシュ／ID 文字列	50bacb7db3dbda5ba74ce3b7e51aa624.jpg	何もわかりません
一般的なデフォルト名	Untitled.png、download (1).jfif	見分けがつきません
スクリーンショットの自動生成名	Screenshot (163).png	スクリーンショットに何が写っていますか？
日時のみの名前	photo_2021-03-15_09-25-00.jpg	いつ撮ったかはわかりますが、何かはわかりません
AI プロンプトを使ったファイル名	alexandersthompson_UI_design_of_a_Forest...png	長すぎて、ハッシュが省略されています
プラットフォームのエクスポート名	IMG_20200417_180854_994.jpg	カメラロールの ID です

適切なファイル名の条件

原則	例
内容を説明する	89381.jpg ではなく ice-cave-interior.jpg
自分の語彙を使う	head-01.jpg ではなく bear-head-front-view.png
同じフォルダー内のファイルと区別できる	moraine-lake-sunrise.jpg と crater-lake-aerial.jpg
適度な長さにする	3～6 語
有用なメタデータを接尾辞として残す	desert-canyon-ref_antelope-canyon.jpg

フラグを付ける場合と無視する場合

状況	対応
厳選された最終保管先フォルダー内のファイル	フラグを付けます — 後で見返す成果物です
_Ideas/ または参照用フォルダー内のファイル	ハッシュや日時のみの名前が 10 個以上ある場合はフラグを付けます
移動用フォルダー（~）内のファイル	無視します — 移動用の内容は作業中です
仮置きのプレースホルダー内のファイル	無視します — 内容が追加されたときに名前が変更されます
見た目から内容がすぐわかる少数のファイル	優先度は低めです

より良い名前を提案する

意味のない名前にフラグを付けるときは、次の点をもとに代わりの名前を提案します。

1. フォルダーの文脈 — Arctic/Locations/Natural/_Ideas/ 内のファイルは、おそらく自然や風景に関する参照資料です
2. ファイルに表示されている内容 — 画像を確認できる場合は、見えるものを説明します
3. 同じフォルダー内のファイル — 名前の付いたファイルが隣にある場合は、その命名パターンに合わせます
4. 完璧さを求めない — 完全な説明でなくても、241076.jpg より snowy-village.jpg のほうが適切です

---

判断ガイド：このファイルはどこに置く？

自問すること…	はいの場合 →
今まさに作成している作業中のものですか？	そのプロジェクト／活動の L2 成果物フォルダー
参照するだけで編集しない資料ですか？	該当する L1 領域内の Reference/
プロジェクト間で再利用するテンプレートですか？	_Templates/（共有または領域ごと）
完成した成果物ですか？	作成元の成果物内にある L3 成果物
アクセスする必要がある他の人の成果物ですか？	コピーではなく、所有者の L2 へのショートカット／リンク
本当にわからない場合	_Unsorted/ — 週次レビューで整理します

---

アクティブと参照：意図を確かめる

フォルダーの種類	目的	思考モード	例
アクティブ（作業）	進行中の作業、プロジェクト、成果物	「何かを作成している」	Launch/、Ship/、Hire/
参照（知識）	検索用資料、ポリシー、標準、ガイド	「答えを探している」	Reference/、Policies/、Standards/

判断基準：「このフォルダーを開くのは、作業をするためですか、それとも何かを調べるためですか？」

• 両方の場合 → 2 つの L2 フォルダーに分けます。アクティブフォルダーに作業内容を置き、参照フォルダーへのリンクを設定します。
• 作業が完了したら、アクティブフォルダーはアーカイブします。参照フォルダーは保持します。

---

重複の解決

作業中のフォルダーは作業を所有します。参照用フォルダーは知識を所有します。互いにリンクし、重複は決して作りません。

状況	解決方法
ファイルを2つのL1領域のどちらにも置ける	作成者に基づいて主な所有者を選びます。もう一方の領域からはショートカットを作成します
ファイルが作業中のものでもあり、参照用でもある	現時点では作業中のフォルダーに置きます。プロジェクト完了後に参照用フォルダーへ移動します
2つのチームが同じファイルを必要としている	一方のチームが所有します。もう一方にはショートカットを作成します。どちらも所有しない場合は → _Shared/
同じデータに異なる形式がある	信頼できる唯一の情報源を設けます。正規版は所有者のフォルダーに置きます

重複は決して作らないでください。 コピーが2つあると、そのうち1つが古くなります。

---

システムフォルダー

コンテンツではなく、構造を支えるインフラストラクチャ用フォルダーです。先頭にアンダースコアを付けます。

システムフォルダー	目的	範囲
_Archive/	完了し、現在は作業対象ではないもの	各L2成果物の中
_Unsorted/	保存先が明確でないファイルの一時受け入れ場所	ドライブごとに1つ（最上位）
_Templates/	再利用可能なドキュメントテンプレート	L1領域ごと、または最上位で共有
_Shared/	単一の所有者がいない部門横断的な項目	最上位のみ

システムフォルダーのルール

ルール	理由
必ず先頭にアンダースコアを付ける	コンテンツフォルダーとは別に並べ替えられ、視覚的にも区別できます
システムフォルダーを入れ子にしない	_Archive/_Archive/ は要注意のサインです。フラットに整理してください
_Unsorted/ は一時的なもの	受け入れ場所であり、恒久的な保存先ではありません。毎週確認してください
_Shared/ には正当な理由が必要	そこに置くすべてのファイルについて、単一の領域に置けない理由があるべきです
システムフォルダーを先回りして作らない	_Archive/ が必要になったときに作成し、それ以前には作らないでください

---

移動中フォルダー

既知の保存先へ実際に移動中のコンテンツを格納するフォルダーです。先頭にチルダ（~）を付けます。保存先が不明な _Unsorted/ とは異なります。

フォルダー	目的
~Transfer/	プロジェクトへ移動するコンテンツの一時置き場
~Import/	外部ソースから受け取ったコンテンツ
~Migrate/	組織構造間を移動するコンテンツ

主なルール：必ず先頭にチルダを付け、日付の接尾辞（~Transfer 2026-02/）を含め、複数回にわたる移動には _STATUS.md を含め、空になったら削除します。

詳細（命名規則、ライフサイクル、古さを示す兆候、分析対象範囲）については、references/transit-folders.md を参照してください。

---

ファイルのライフサイクル

Created → Active → Completed → Archived → (Deleted)

ファイルは、プロジェクトの状況に応じて各段階を移行します。アーカイブはL2レベル（成果物フォルダー内の _Archive/）で行います。保管することを基本としてください。ストレージは安価ですが、後悔は高くつきます。

ライフサイクルのルール、アーカイブ戦略、メンテナンスの頻度（毎週／毎月／四半期ごと）については、references/lifecycle.md を参照してください。

---

規模に応じた適用

規模	L1の対応先	L2で重視すること	主な考慮事項
個人（1人）	生活領域：Career、Finances、Home、Media、Personal	簡易的な構成。プロジェクト名またはシンプルな成果物	ほとんどのファイルはL3に置きます
チーム（少人数グループ）	マインドセット：Fulfill、Maintain、Grow	構造化された構成。プロセス、プロジェクト、期間	各L1領域の所有者を決めます
組織（会社）	部門または事業部門	チーム間で命名規則を徹底	アクセス制御をL1の境界に合わせます

注意すべき兆候

次の兆候が見られたら、立ち止まって再編成してください。

問題の兆候	問題点	対処法
何でも入れるフォルダー	Misc/、Other/、Stuff/、New Folder/	適切な L1 の領域または L2 の成果を決めます
深すぎる階層（6 階層以上）	1 つの枝に異なる認知フェーズが混在しています	L1／L2／L3 の関心事を分けて階層を浅くします
L1 に日付だけのフォルダーがある	最上位に 2024/、2025/ がある	日付は L2 または L3 に配置し、先にドメインを置きます
同じファイル名の重複	同じファイルが 2 か所にあります	所有元を決め、ほかの場所からリンクします
すべてが 1 つのフォルダーにある	1 つのディレクトリに 100 個以上のファイルがあります	L2 の成果または L3 の成果物の種類ごとに分割します
曖昧な名前	Documents/、Files/、Data/	具体的な領域名に置き換えます
階層の混在	Finance/Invoice-2025-03.pdf（L2 を省略）	成果を追加します：Finance/Accounts-Payable/Invoice-2025-03.pdf

---

アンチパターン

アンチパターン	どのような状態か	うまくいかない理由
書類キャビネット	考え方に合わない、硬直したカテゴリー	恣意的な保存場所を暗記するよう強いられます
時系列で放り込む	すべてが日付順に並んでいます	日付ではトピック別に探しにくくなります
鏡	フォルダー構造が組織図をそのまま反映しています	組織図は変わりますが、ファイルは自動で再編成されません
完璧主義者	一貫したテンプレートも中身もない、散在した空のフォルダー	ばらばらな空フォルダーは意図を伝えず、ノイズを生みます。（注：段階的に埋めていく一貫したテンプレートは完璧主義ではなく足場づくりです。足場づくりの評価を参照）
平坦な世界	すべてが検索機能付きの巨大なフォルダーにあります	検索に失敗したり、コンテキストが失われたりするまでは機能します

---

例外：ルールを破る場合

このフレームワークのどのルールにも、正当な例外があります。大切なのは、うっかりではなく、意識してルールを破ることです。

L1 で日付を先に置く場合

例外	例	問題ない理由
税務・法令遵守	2024-Tax-Returns/、2025-Tax-Returns/	法的要件は本質的に年単位です。年そのものがドメインです
学期制の学術機関	Fall-2025/、Spring-2026/	各学期はそれぞれ独立した世界です

確認事項： 単なる習慣ではなく、その期間が本当に主要な整理原則になっていますか？

L1 の領域が 12 個を超える場合

例外	例	問題ない理由
クライアント別の事業	大口クライアントごとに L1 を 1 つ	各クライアントは実際に別々の世界です
複数物件の管理	物件ごとに L1 を 1 つ	物理的な場所は自然な領域です

確認事項： 2 つの領域を統合すると、1 つのフォルダー内で頻繁にコンテキストを切り替える必要が生じますか？

多数のファイルがあるフラットな L3

例外	例	問題ない理由
写真ライブラリ	日付付きのイベントフォルダーに 200 枚以上の写真がある	ファイル名を読むのではなく、視覚的に閲覧します
ログファイル	1 つのフォルダー内に時系列順のログがある	日付順に並び、最近のものから参照します

確認事項： サブグループに分けなくても必要なものを見つけられますか？検索や日付順の並べ替えで十分なら、無理に人工的なカテゴリーを作らないでください。

例外に関する一般ルール

ルールを破る場合は、その階層にある _README.md に理由を書き留めてください。理由を明確に説明できないなら、ルールを破るべきではありません。

---

品質チェック

ドライブの「整理」が完了したと判断する前に、これらのルールが守られていることを確認してください。

構造のチェック

チェック	合格条件
すべての L1 領域に、少なくとも 1 つのアクティブな L2 成果がある	最上位階層を空の領域で煩雑にしない
L2 フォルダーが、アクティブな作業と参照用の検索先の両方を担っていない	作業用と情報用のフォルダーに分ける
すべてのアクティブな L2 フォルダーに成果物またはサブフォルダーがあるか、一貫したテンプレートのひな形の一部になっている	散在する単発の空フォルダーを作らない
L3 の成果物が複数の領域に重複していない	所有者は 1 つにし、他の場所からはショートカットを使う
_Unsorted/ の項目が 20 個未満である	毎週の整理を続けられている

命名のチェック

チェック	合格条件
L1 の名前が名詞（領域）である	最上位階層に動詞、日付、略語がない
L2 の名前から意図（動詞、成果、または主題カテゴリ）が分かる	名前を見れば、ここで何をするのかが分かる
L3 の名前が検索で見つけられる程度に具体的である	Document.pdf や Notes.txt のような名前を使わない
各階層内で大文字・小文字の表記が一貫している	同じ階層で Title-Case と lowercase を混在させない
名前がコンテキストに合っている	個人用ドライブではスペース可、コードプロジェクトではハイフン／アンダースコアが必須

境界のチェック

チェック	合格条件
アクティブなフォルダーには作業を置き、参照資料は置かない	参照資料には専用のフォルダーがある
参照フォルダーには検索用の資料を置き、アクティブなプロジェクトは置かない	作業には専用のフォルダーがある
_Shared/ には、本当に部門横断で使う項目だけを置く	何でも放り込む場所にしない
アーカイブフォルダーを各 L1 領域の中に置く	コンテキストが失われる最上位の Archive/ を作らない

---

フレームワークの適用

ステップ 1：現在の状態を監査する

最上位のフォルダーを一覧表示します。それぞれについて、次の点を確認します。

• 明確に L1 領域（活動の分野）といえるか？
• それとも別のものか？（日付、プロジェクト、何でも入れるフォルダー）

ステップ 2：L1 領域を設計する

生活や仕事における主要な分野を 5～8 個書き出します。これらが L1 フォルダーになります。自然で安定した構成にしてください。

ステップ 3：領域ごとに L2 の成果を設計する

各領域で実際に行うことを 3～6 個書き出します。これらが L2 フォルダーになります。

ステップ 4：L3 は自然に生まれるのに任せる

L3 の構造をあらかじめ作らないでください。実際に成果物を作る中で、自然に生まれるのに任せましょう。構造は作業に沿って整えます。

ステップ 5：段階的に移行する

ファイルをまとめて移動します。最もよく使う領域から始めましょう。一度にすべてを再編成しようとしないでください。詳細な移行手順については、references/migration-guide.md を参照してください。

---

参考資料

• references/naming-patterns.md — 各階層の詳細な命名例と規則
• references/migration-guide.md — 既存の整理されていないドライブを再編成するための手順ガイド
• references/transit-folders.md — 中間フォルダーの規則、ライフサイクル、古さを示す兆候
• references/lifecycle.md — ファイルのライフサイクル規則、アーカイブ戦略、メンテナンスの頻度

アセット

• assets/home-drive-template.md — 個人用ホームドライブのスターター構成
• assets/work-drive-template.md — 業務用ドライブのスターター構成

スクリプト

• scripts/audit_structure.py — フォルダーツリーをスキャンし、L1／L2／L3 の問題（何でも入れるフォルダー、階層の深さ、命名）を報告する