Obsidian 情報整理のディレクトリ構成をどうすべきか

はじめに

この記事はObsidian等、ディレクトリの構成を決められるメモアプリで、どのように情報を保存していくかについてのメモです。

ノート遍歴

私はあまりこだわりがなく情報をまばらに散らかしていました。

Google Keep, Evernote, Notion, iOS 純正のメモ, 紙のメモ帳

様々なアプリを試してきましたが、最近では主戦力のメモをアナログな紙とMacのメモ帳という貧弱な装備に戻ってし待っていました。

しかし結局デバイスや場所を跨ぐとなると、統一されたフォーマットでデータを保管したいと思いたち、せっかくなのできちんと整理しようとなったわけです。

情報整理フレームワーク 5選

有名なフレームワークを調べてまとめてみました。

PARA Methodby Tiago Forte

https://paramethod.com

情報を「行動との距離」で4つに分類するフレームワーク。
最もシンプルで始めやすそうな印象があります。

vault/ 
├── 1_Projects/ # 進行中のプロジェクト（期限あり） 
├── 2_Areas/ # 継続的に管理する領域（健康、財務、キャリアなど） 
├── 3_Resources/ # 興味・関心のあるトピック（参考情報） 
└── 4_Archive/ # 完了・非アクティブなもの

向いている人：GTD的にタスクを進めたい人、仕事とプライベートを横断して管理したい人

Zettelkastenツェッテルカステン

↓この記事めっちゃ良いのでこんなブログ読むよりこれ読んでください。

https://zettelkasten.de/introduction

ドイツの社会学者ニクラス・ルーマンが実践した手法。フォルダ分類に頼らず、ノート同士をリンクで繋いでいくことで知識のネットワークを構築します。Obsidianのグラフビューとの相性は抜群です。

vault/ 
├── Inbox/ # とりあえず放り込む場所 
├── Zettel/ # すべてのノート（フラットに配置） 
└── Templates/

ノートは1つにつき1アイデア（Atomic Note）を原則とし、[[リンク]]でノート同士を結びます。フォルダは最小限に留めるのがポイントです。

向いている人：研究者、ライター、知識を長期的に蓄積・発展させたい人

Johnny Decimal

https://johnnydecimal.com

引用：「10 以下」というコンセプトが Johnny.Decimal の中心にあります。

10単位のカテゴリ番号で情報を厳密に管理するシステム。「あのファイルどこだっけ？」がなくなります。

vault/ 
├── 10-19_Admin/ 
│ ├── 11_Finance/ 
│ └── 12_Legal/ 
├── 20-29_Projects/ 
│ ├── 21_ProjectA/ 
│ └── 22_ProjectB/ 
└── 30-39_Learning/ 
├── 31_Programming/ 
└── 32_Languages/

向いている人：整理整頓が好き、大量のノートを厳密に分類したい人

ACCESSby Nick Milo（Linking Your Thinking）

バランス型MOC活用

PARAとZettelkastenの良いとこ取りをしたフレームワーク。MOC（Map of Content）という索引ノートを中心に、フォルダとリンクの両方を活用します。

vault/ 
├── Atlas/# MOC（Map of Content）、索引ノート 
├── Calendar/# デイリーノート、会議メモ 
├── Cards/# 個別のアトミックノート 
├── Extra/# 添付ファイル、テンプレート 
├── Sources/# 書籍・記事などの参照元 
└── Spaces/# プロジェクトや領域ごとのスペース

向いている人：フォルダもリンクもバランスよく使いたい人

PARA × Zettelkasten ハイブリッド

実用的おすすめ

PARAのフォルダ構造で大枠を整理しつつ、Zettelkastenのリンク思想で知識を繋ぐ。迷ったらこれがおすすめです。

vault/ 
├── 00_Inbox/# 未整理のメモをとりあえず入れる 
├── 01_Projects/# 進行中プロジェクト 
├── 02_Areas/# 継続管理（仕事、健康、家計など） 
├── 03_Resources/# 参考情報・学習ノート 
├── 04_Archive/# 完了したもの 
├── Daily/# デイリーノート 
├── Templates/# テンプレート 
└── Attachments/# 画像・PDFなど

フォルダ分類に悩んだらリンクとタグで繋ぐ。完璧な分類を目指すより、まずInboxに書いて後から整理するのがコツです。

GTD（Getting Things Done）とは

GTDは生産性コンサルタントのデビッド・アレンが提唱したタスク管理手法です。「頭の中のすべてを外に出し、信頼できるシステムに預ける」ことで、脳のワーキングメモリを解放し、目の前の作業に集中できるようにします。

私は数年前に本で読んだのですが、めんどくさくて途中で放棄していました、、
これを機会にまた始めようかな、、、

GTDの5つのステップ

STEP 1Capture収集する

STEP 2Clarify明確にする

STEP 3Organize整理する

STEP 4Reflect振り返る

STEP 5Engage実行する

Capture（収集）

頭の中にある気になることを、すべて書き出します。タスク、アイデア、メモ、何でも構いません。大事なのは「ゼロ」にすること。

Clarify（明確化）

集めた項目を一つずつ処理します。「これは何か？」「次にとるべきアクションは？」「2分以内にできるか？」を判断し、行動可能な形にします。

Organize（整理）

明確にした項目を適切な場所に振り分けます。次のアクションリスト、プロジェクトリスト、待機リスト、カレンダー、いつかやるリストなどに分類します。

Reflect（振り返り）

週次レビューでシステム全体を見直します。完了タスクの確認、リストの更新、次の1週間の計画を立てます。GTDが機能し続けるための最重要ステップです。

Engage（実行）

整理されたリストを元に、今の状況（場所、時間、エネルギー、優先度）に合った最適なタスクに取り組みます。

ObsidianでGTDを実践する

ディレクトリ構成例

vault/
├── 00_Inbox/# Capture: 何でもここに放り込む 
├── 01_Projects/# 複数ステップが必要な目標 
├── 02_Areas/# 継続的な責任領域 
├── 03_Resources/# 参考資料・ナレッジ 
├── 04_Archive/# 完了したプロジェクト 
├── 05_GTD/ 
│ ├── Next-Actions.md # 次にやること一覧 
│ ├── Waiting-For.md # 誰かの返事待ち 
│ ├── Someday-Maybe.md # いつかやりたいこと 
│ └── Weekly-Review.md # 週次レビューテンプレート 
├── Daily/# デイリーノート 
├── Templates/ 
└── Attachments/

おすすめのObsidianプラグイン

GTDをObsidianで効率的に回すには、以下のコミュニティプラグインが役立ちます。

プラグイン	GTDでの用途
Tasks	タスクの期限・優先度管理、タスク検索クエリ
Dataview	vault全体のタスクを自動集計、Next Actionsリストの自動生成
Templater	デイリーノートや週次レビューのテンプレート自動展開
QuickAdd	Inboxへの素早いキャプチャ（ホットキー1つで入力）
Periodic Notes	日次・週次・月次ノートの自動作成
Kanban	プロジェクトの進捗をボード形式で可視化

この記事をシェア

投稿日: 2026年2月19日

カテゴリ: 未分類

タグ:

coiai

この記事もおすすめ

【WSL入門】Ubuntu on WSL2 に開発ツールを一式そろえる — Git / nvm / pnpm / AWS CLI / Terraform

前回の記事では、Windows に WSL2 を導入して Ubuntu が動くところまでを扱いました。ただ、素の Ubuntu はあくまで「まっさらな Linux」です。ここから実際に開発を始めるには、バージョン管理・ランタイム・クラウド操作のツールを自分で入れていく必要があります。この記事では、すべて公式ドキュメントに載っている手順だけを使って、次のツールを順番にセットアップします。各セクションの末尾に出典 URL を置いてあるので、手順が古くなったと感じたらそこを見に行ってください。記事末尾には出典一覧もまとめています。検証環境Windows 11 / WSL2 / Ubuntu 24.04 LTS（x86_64）確認日：2026年7月28日バージョン番号は執筆時点のものです。インストールコマンド自体は基本的に「常に最新を取ってくる」形になっているので、そのまま実行して問題ありません。はじめに：WSL開発の大原則コマンドに入る前に、ひとつだけ。Microsoft の公式ドキュメントが繰り返し書いている重要な原則があります。使う予定のツールと同じ OS 側にファイルを置く。Linux ツールで Linux コマンドラインから作業しているなら、最速のパフォーマンスを出すためにファイルは WSL ファイルシステムに格納します。具体的には、プロジェクトは次の場所に置きます。 /mnt/c/ 配下はファイルシステムをまたぐため、npm install や git status が体感でわかるほど遅くなります。第2弾でこれから入れるツールも、すべて Linux 側のホームディレクトリを前提に使ってください。出典：WSL 開発環境を設定する — Microsoft Learn 1. まずは基本ツール Ubuntu を起動したら、最初にやることはパッケージの更新です。Microsoft の公式ドキュメントにもこう書かれています。ディストリビューションの優先パッケージマネージャーを使用して、パッケージを定期的に更新およびアップグレードすることをお勧めします。Windows […]

WindowsでWSL2をセットアップしてUbuntuを使えるようにする

TerraformやAWS CLI、Dockerを快適に使うために、WindowsにWSL2を導入しました。この記事では、実際に行ったセットアップ手順と、途中で遭遇したエラーへの対処方法をまとめます。なぜWSLを使うのか？ WSL（Windows Subsystem for Linux）は、Windows上でLinux環境を動かすための仕組みです。 AWSやTerraform、Dockerなど、多くの開発ツールはLinux環境との相性が良いため、Windowsで開発する場合でもWSL2を利用するのが一般的です。今回の開発環境では以下のような構成を想定しています。 1. WSLをインストール PowerShell（管理者）を開き、以下を実行します。 2. Ubuntuの初回セットアップ Ubuntuを起動すると、Linuxユーザー名とパスワードの設定を求められます。例好きなユーザー名を入力します。続いてパスワードを設定します。 ※入力中は文字が表示されませんが正常な動作です。 3. パッケージを更新 Ubuntuを起動したら、まず最新状態へ更新します。 4. エラーが表示されたアップグレード中に次のようなメッセージが表示されました。一見エラーに見えますが、今回は最後までと表示され、更新自体は正常に完了していました。 WSLではsystemd関連の処理で、このような警告が表示されることがあります。 5. WSLの状態を確認 PowerShellで以下を実行します。今回はとなっていました。 6. Docker DesktopとUbuntuの違いここで少し混乱しやすいポイントがあります。 Docker Desktopをインストールすると、docker-desktopというWSLディストリビューションが作成されます。しかし、これはDockerが内部で利用するためのもので、普段の開発を行う場所ではありません。おすすめの構成は次の通りです。開発はUbuntuで行い、Docker Desktopはコンテナ実行基盤として利用します。 7. Ubuntuを既定のディストリビューションに変更現在登録されているWSLを確認します。 Ubuntuがインストールされていることを確認したら、を実行します。これでだけでUbuntuが起動するようになります。今後インストール予定 WSL環境では今後以下を導入していきます。この環境をベースに、AWS Organizations、IAM […]

AWS CLIでIAM Identity Center（AWS SSO）を設定する

これまでの記事で、まで構築しました。今回は、ローカルPCからAWSを操作するために、AWS CLIをIAM Identity Center（AWS SSO）へ接続します。これにより、長期アクセスキーを発行せず、安全にAWS CLIやTerraformを利用できるようになります。なぜアクセスキーを使わないのか以前はAWS CLIを利用する際、IAM Userを作成し、を発行していました。しかし、この方法にはいくつかの課題があります。現在AWSでは、人によるAWSへのアクセスには**IAM Identity Center（旧AWS SSO）**を利用することが推奨されています。 IAM Identity CenterとAWS CLIの仕組み AWS CLIは、IAM Identity Centerへログインし、一時的な認証情報（Temporary Credentials）を取得します。つまり、という、安全性の高い認証方式になります。 aws configure sso を実行まずAWS CLI v2をインストールします。インストール後、次のコマンドを実行します。すると、対話形式で設定が始まります。 SSO Session Name ここはローカルPC上だけで利用する設定名です。今回はとしました。好きな名前で問題ありません。 SSO Start URL IAM Identity CenterのアクセスポータルURLを入力します。例このURLは IAM […]

AWS IAM Identity Centerとは？IAM Userを使わないAWS認証・権限管理のベストプラクティス

AWS Organizationsによるマルチアカウント環境を構築した後、次に設定したのがAWS IAM Identity Centerです。以前はAWSへログインするためにIAM Userを作成することが一般的でしたが、現在AWSでは、人がAWSへログインする場合はIAM Identity Centerの利用を推奨しています。今回は、IAM Identity Centerを導入した理由と、実際の設定内容についてまとめます。 IAM Identity Centerとは IAM Identity Center（旧 AWS Single Sign-On）は、複数のAWSアカウントやAWSアプリケーションへの認証・認可を一元管理するサービスです。従来のように各AWSアカウントへIAM Userを作成する必要はなく、というメリットがあります。 AWS Organizationsと組み合わせることで、マルチアカウント環境の運用が大幅に容易になります。なぜIAM UserではなくIdentity Centerなのか以前は、このような構成が一般的でした。しかし、この方法ではといった課題があります。 Identity Centerを利用すると、ユーザー情報は一元管理され、各AWSアカウントには必要な権限だけを割り当てる運用になります。 AWS Well-Architected Frameworkでも、人によるアクセスにはフェデレーション認証を利用し、長期認証情報（IAM Userのアクセスキーなど）をできる限り利用しないことが推奨されています。今回の構成今回は次のようなシンプルな構成にしました。グループ Administrators AWS環境全体を管理するメンバーです。現在はを所属させる予定です。 Developers アプリケーションやインフラ開発を行うメンバー向けです。今回はまだ利用していませんが、開発メンバーが増えた際に使用します。将来的にはなどを割り当てる予定です。 ReadOnly 閲覧専用グループです。監査やレビュー、外部アドバイザー向けとして利用します。今回は技術メンターにReadOnly権限を付与することを想定しています。 Permission […]