はじめに
「第二の脳」という言葉が広まって、もう何年か経ちました。Tiago Forte が同名の書籍で体系化したのが起点です。それ以来、Obsidian（ローカルの Markdown ノートアプリ）や Notion で実装する人が一気に増えた印象です。
ところが、私の周りで本当に続いている人は意外と少ないのです。
理由ははっきりしています。多くの場合、分類体系が重すぎるからです。フォルダを 5 階層も切り、タグを 30 個も用意し、最初の 1 週間で力尽きる。私自身、過去に何度も同じ轍を踏みました。
設計に 3 日かけて、運用が 1 週間で止まる、というやつです。
第二の脳を続ける鍵は、思想の格好良さではなく実装の軽さにあると気づきました。重い構造は、それを維持するための認知コストを要求するからです。
本記事では、人間が理解できる最も軽量なフレームワークとして PARA メソッドを取り上げます。Projects / Areas / Resources / Archives の 4 区分。それだけです。
そして PARA は、単なる分類ルールではありません。情報が 4 区分の間を動くライフサイクルが、自然に流れるように設計されています。だからこそ複数ツール横断の運用にも耐えます。たとえば Obsidian で書いて、Cursor（AI 連携を内蔵した IDE）で編集して、Claude（Anthropic の AI アシスタント）に読ませる、という流れです。
この記事を貫くテーマは、次の二つです。
- 第二の脳という思想：脳の外側に、検索可能で更新可能な記憶層を置く考え方
- PARA という最軽量な実装：4 区分でライフサイクルが自然に回るフレームワーク
肩の力を抜いて読んでいただければ嬉しいです。
1. 第二の脳という思想
第二の脳という概念は、Tiago Forte が著書『Building a Second Brain』で広めました。簡単に言えば、自分の脳の外側に「検索可能な記憶層」を置く考え方です。
ポイントは「外側」にあります。
脳の中だけで覚えておこうとすると、忘却と再想起のコストが膨大です。アイデアを思いついた瞬間に、外側の記憶層へ書き出してしまいます。あとで検索すれば、いつでも引き出せます。
これだけで、脳は「覚えておく仕事」から解放されます。
比喩で言えば、PC の RAM と SSD の関係に似ています。RAM（脳）は速くて高価ですが、容量が小さいです。SSD（第二の脳）は遅いけれど安く、容量も大きいです。RAM に貯めすぎると動作が重くなるので、こまめに SSD に書き出すわけです。
入力 → 加工 → 出力 の三層モデル
Forte は、第二の脳の運用を CODE という 4 段階で表現しています。Capture / Organize / Distill / Express の頭文字です。
- Capture（捕捉）：思いついたこと、読んだ記事、会話のメモを、その場で書き留める
- Organize（整理）：書き留めたものを「いつ使うか」で分類する
- Distill（蒸留）：何度か読み返して、本当に役立つ要点を抽出する
- Express（表現）：要点を組み合わせて、記事・コード・意思決定として外に出す
この 4 段階を見ると、第二の脳が「収集ツール」ではなく「出力装置」であることが分かります。
入力したものを、いずれ別の形で外に出すこと。それが目的です。集めて満足するための仕組みではありません。
具体例で言うと、この記事自体が CODE を一周しています。
- Capture：「PARA は AI 時代に効くフレームワークだ」というアイデアを Pool にメモ
- Organize：Qiita 記事化が決まった時点で、Pool から Projects フォルダへ移動
- Distill：outline.md で章ごとに「主張・感情・具体」を一行に削り出す
- Express：draft.md で本文化して、publish.md で Qiita 公開形式に整える
入口の 1 行メモが、最終的にあなたが今読んでいる記事になるまでの道筋です。第二の脳は、こうした小さな一周を何度も繰り返す装置だと考えてください。
入力と出力の間に「第二の脳」を挟む。この単純な構図さえ保てれば、形式はなんでも構いません。
Zettelkasten との違い
似た思想として、Niklas Luhmann の Zettelkasten（ツェッテルカステン、メモカードの整理術）が有名です。Luhmann はカード式メモを使い、9 万枚を超えるノートを互いにリンクさせ、論文や本を量産しました。
Zettelkasten と第二の脳は、似ているようで力点が違います。
- Zettelkasten は アイデア同士をリンクで結ぶこと に主眼があります
- 第二の脳は 入力から出力までのパイプラインを作ること に主眼があります
Obsidian の双方向リンク機能は Zettelkasten 的な発想です。ただし第二の脳としては、フォルダ階層と検索があれば最低限事足ります。リンクは「あれば便利」程度に位置づけても構いません。
最初からリンクを張り巡らせようとすると、また分類設計と同じ罠にハマります。書く量より考える量のほうが増えるからです。
ツールは「窓口」、本体は Vault
ここで強調したいことがあります。Obsidian も Cursor も Claude も、第二の脳の 窓口 にすぎません。本体は、ローカルに置かれた Markdown ファイル群、つまり Vault（保管庫）そのものです。
- Obsidian は、人間が閲覧・編集するための GUI 窓口
- Cursor は、ファイルをコード文脈で編集する IDE（統合開発環境）窓口
- Claude は、ファイルを読んで推論・生成する AI 窓口
3 つのツールは、同じ Vault を別の角度から覗いているだけです。だから、ツールを乗り換えても第二の脳の中身は失われません。
データがプレーンテキストである限り、窓口はいつでも差し替えられます。
これは AI 時代において、特に重要な性質です。明日新しい AI ツールが出ても、Markdown のままなら即座に取り込めます。SaaS（クラウド経由で提供されるソフト）の独自フォーマットに閉じ込められていたら、こうはいきません。
第二の脳は思想として軽くあるべき、というのは、こういう実用的な理由からも言えるのです。
2. PARA という最軽量な実装
PARA メソッドは、Tiago Forte 自身が提唱した分類体系です。Projects / Areas / Resources / Archives の 4 区分で、すべての情報をどれかに振り分けます。
ポイントは、分類軸が「テーマ」ではなく「アクションの距離」だという点です。
テーマで分けると、たとえば「AI」というフォルダにあらゆる AI 情報が集まります。その中には、今やる仕事も、いつか読む論文も、もう終わった案件も混ざります。これでは、見るたびに「これは何だっけ」と判断コストがかかります。
PARA は逆です。「今アクションが発生しているか?」という距離で分けます。だから、フォルダを開けば、自分が次に何をすべきかが一目で分かります。
比喩で言えば、自分のデスクと棚と倉庫の関係に似ています。Projects がデスクの上で、Areas が手の届く棚です。Resources は部屋の本棚で、Archives は地下の倉庫、という具合です。距離が遠いほど、毎日見る必要が減ります。
4 区分の定義
それぞれの区分を、もう少し具体的に見ていきます。
Projects（プロジェクト） は、明確なゴールと締切のある、今動いている仕事です。
- 例：この Qiita 記事の執筆、新サービスの設計、来週の登壇資料
ポイントは「終わりがある」という性質です。終わったら Archives に移すのが前提になります。
Areas（領域） は、継続的に責任を持って維持する関心領域です。
- 例：自分の健康、AWS の運用、家計、フリーランスの売上管理
こちらは「終わりがない」のが特徴です。健康も家計も、生きている限り続きます。だから「観測対象」と捉えるのが近いです。
Resources（資源） は、将来役立つかもしれない参考情報です。
- 例：気になった記事のクリップ、技術スタックの調査メモ、書評
ここでは「自分の責任ではない」のが特徴です。読まなくても誰にも迷惑をかけません。だから優先度は最も低くなります。
Archives（保管庫） は、終わった Project、観測しなくなった Area、見なくなった Resource を放り込む場所です。
捨てるのではなく、Archives に下ろすのがコツです。後で「あの案件、どうやったっけ」と参照したくなる時に救命ロープになります。
実例：同じ情報でも、人によって入れる場所が変わる
PARA の面白いところは、同じ情報でも「誰がどう関わっているか」で入れる場所が変わることです。
たとえば「AWS Lambda の料金体系まとめ」という記事をクリップしたとします。
- A さん（仕事で Lambda を本番運用中）：
Areas/aws_operations/に入る。コスト最適化の継続テーマだから - B さん（来月 Lambda 移行プロジェクトを担当）：
Projects/2026Q2_lambda_migration/に入る。期限と完了条件がある仕事だから - C さん（趣味で Lambda を触っている学習者）：
Resources/serverless_clips/に入る。いつか使うかも、の参考情報だから
3 人とも、扱う情報は全く同じです。違うのは、その情報に対する自分のスタンスだけです。
PARA は「情報の属性」ではなく「自分との関係性」で分類するフレームワークなのです。だから、他人のフォルダ構成をそのまま真似しても機能しません。同じツールを使っていても、フォルダ構成は人それぞれです。
判定木：1 つの情報がどこに入るか
ある情報を受け取ったとき、PARA のどこに置くかは次の判定木で決まります。
たった 3 つの問いに順番に答えるだけです。慣れれば 3 秒で判断できます。
3 秒で判断できる、というのが PARA の最大の効能です。判断に時間がかかると、結局フォルダ分けが面倒になって、デスクトップに散らかすことになります。
よくある詰まりどころ
実際に運用してみると、いくつか迷う場面があります。代表的なものを 3 つ紹介します。
Areas と Resources の境目が曖昧 という相談をよく受けます。例えば「AWS の運用ノウハウ」は Areas でしょうか、Resources でしょうか。
判別の基準は「自分が当事者として責任を持っているか」です。仕事で AWS を運用しているなら Areas、興味で勉強しているだけなら Resources です。同じ AWS 関連情報でも、人によって入れる場所は変わります。
Project が肥大化する問題 もあります。長期化したプロジェクトに、なんでも放り込んでしまうケースです。
これは、終わりが見えなくなった時点で Project ではなく Area に格上げすべきです。Project は「いつか終わるもの」だからこそ Project なのです。半年経っても終わらない Project は、もう Area と呼ぶほうが正確です。
フォルダ階層をどこまで深くするか という質問もあります。原則として、PARA 直下は 4 区分、その下は 1〜2 階層までに抑えます。深すぎると、PARA を採用した意味が消えるからです。
階層が深くなった時点で、フォルダを切るのをやめて、ファイル名の prefix で代用するのも手です。例えば Projects/2026Q2_qiita_para.md のように、メタ情報をファイル名に持たせる方法です。
画像や PDF などのバイナリをどこに置くか という問題もよく出ます。図版・スクショ・参考 PDF などです。
これは、それを参照する記事と同じ Project / Area / Resource フォルダの下に assets/ を切るのが楽です。例えば Projects/qiita_para/assets/diagram01.png のように、関連ファイルと物理的に近くに置く。
PARA の中で「メディア種別」で切ると（例：Resources/images/、Resources/pdfs/）、結局テーマ別検索が破綻するので避けます。素材は使う文脈の近くに置くのが原則です。
タグや MOC との関係
Obsidian ユーザーから「タグや MOC（Map of Content、目次ノート）との関係はどうなるのか」と聞かれることがあります。
結論から言えば、PARA は 置き場所 の話、タグや MOC は 検索性 の話です。役割が違うので、両立させるのが正解です。
PARA でフォルダを切ったうえで、横断的に引きたい情報にはタグを付ける、関連を辿りたければ MOC を作る、という二段構えになります。
PARA がなければ、すべてをタグで管理することになり、タグが何百個にも増えて破綻します。PARA があれば、タグは検索性を上げるための補助に専念できます。
なぜ PARA は軽いのか
ここまで読んで、「結局フォルダを切る話じゃないか」と感じた方もいるかもしれません。その通りです。新しい技術は何も使いません。
PARA の本質は、新規性ではなく 判断回数の少なさ にあります。
情報を受け取るたびに「3 秒の判定」で済むこと。設計を一度決めれば、運用中は判定木をなぞるだけで済むこと。これが、第二の脳を続けるための最小コストになります。
軽いから続く。続くから育つ。育つから出力が増える。PARA が静かに効いてくるのは、このループが回り始めた後です。
3. ライフサイクル：4 区分の間で情報が動く
PARA の本当の価値は、4 区分を作って終わりではなく、その間を情報が流れる ライフサイクル にあります。
一度入れたら不動、ではなく、状況が変われば動かす。これが回るからこそ、第二の脳は腐らずに育ちます。
比喩で言えば、川の流れに似ています。Resources が源流、Projects が本流、Archives が河口です。流れが止まれば淀みますが、流れている限り水は澄んでいます。
情報の遷移パターン
情報は、4 区分の間を次のように動きます。
ざっくり見ると、Resources が入口、Archives が出口、間に Projects と Areas がある、という構図です。
主な遷移を順に見ていきます。
- Resources → Projects への昇格：いつか読もうとクリップしていた記事が、具体的な仕事に結びついた瞬間、Projects に上げます
- Projects → Archives への着地：仕事が完了したら、Projects フォルダから出して Archives に移します
- Projects → Areas への移行：完了せずに「継続観測」になった案件は、Areas に下ろします
- Archives → Resources への復活：過去の案件が、新しい文脈で参考になる場合は引き戻します
この遷移は、頭の中の暗黙のものでは続きません。フォルダ間で実際にファイルを動かす、という物理的な動作が伴うことが大事です。
Areas の役割：観測と維持
Areas はライフサイクルの中で、独特の役割を担っています。Projects のように動いているわけでも、Resources のように静止しているわけでもありません。
Areas は「定期的に見る場所」です。週次レビューで全 Areas をざっと眺め、何か Project に昇格させるべき兆候がないか、何か Archives に下ろせる Area がないかをチェックします。
たとえば「AWS の運用」という Area の中で、特定のサービスのコストが急に上がったとします。それは Project に昇格させる兆候です。「コスト最適化プロジェクト」として Projects に切り出し、終わったら Archives に戻します。
Areas は、Projects 化すべき変化を 早期に検知するセンサー の役割を担っています。
複数ツールに耐える理由
ここが、本記事で一番伝えたい点です。
PARA のライフサイクルが回るからこそ、複数のツール（Obsidian / Cursor / Claude）が同じ Vault を触っても破綻しません。
理由は単純で、PARA の 4 区分が アクションの距離 という共通の意味を持つからです。どのツールから情報を入れても、置き場所の判定基準は同じです。
- 人間が Obsidian で新しいメモを書く時も、PARA の 4 区分から選びます
- Cursor で .md ファイルを編集する時も、保存先のフォルダは PARA に従います
- Claude が新しいファイルを作成する時も、PARA の意味に従ってフォルダを選びます
逆に、もし PARA がなく、各ツールが勝手なフォルダ構造を作ったらどうなるでしょうか。
Obsidian で書いたメモはどこに行ったか分からなくなります。Cursor が新規ファイルを作ると別の場所に散らばります。Claude は「どこに保存すべきか」を毎回聞いてきます。第二の脳というより、第二のゴミ屋敷です。
PARA は、複数の「書き手」が共通言語として参照できる 意味的なプロトコル になります。書き手が人間でも AI でも IDE でも、判定基準が同じだから整理が破綻しません。
CLAUDE.md や .cursorrules（それぞれ Claude / Cursor が自動で読み込むルールファイル）に「新しいファイルは PARA に従って配置すること」と書いておくだけで、AI も IDE も同じルールで動きます。たとえば、こんな具合です。
# このVaultの保存ルール（CLAUDE.md / .cursorrules 共通）
新規ファイルを作る時は、必ず以下の PARA 4 区分のどれかに置くこと。
- `10_Projects/`：締切と完了条件のある仕事。例：執筆中のQiita記事
- `20_Areas/`：継続観測する責任領域。例：自分の運用ノウハウ
- `30_Resources/`：いつか役立つ参考。例：他人のブログクリップ
- `40_Archives/`：完了済み・観測終了。手動で移動するだけ
迷ったら Resources に置き、後で人間がレビューする。
このルールが共有されていれば、私が Obsidian で書き始めたメモを、後日 Claude が Cursor 経由で編集してくれます。途中で Claude が新しいファイルを作る時も、迷わず Projects に保存します。
書き手が変わっても、置き場所のルールが共通だから、戻ってきた時にどこにあるか分かる。これが「複数ツール横断に耐える」の中身です。
逆に言えば、PARA という共通プロトコルがない Vault では、AI と人間の協業は破綻しがちです。AI が作ったファイルを後から人間が探せません。人間が書いたメモを AI が見つけられません。こうした事態が頻発します。
参考：Pool という個人的な拡張
本流の PARA は 4 区分ですが、私は個人的に「Pool」という 0 番目を足しています。書きかけ未満の、まだ判定できないメモを置く場所です。
これは PARA 本流の Forte 流ではなく、私のローカル拡張です。なぜ足したかというと、AI 時代の特殊事情があります。
従来は、判定できないメモは「いずれ判定するか、捨てるか」の二択でした。判定できないまま積んでおく価値は限定的でした。
ところが、AI に読ませる前提だと話が変わります。
Pool に雑多なメモを溜めておくと、Claude に「ここから次の記事ネタを 3 つ出して」と頼めます。判定を AI が手伝ってくれるなら、判定前のメモも資産になります。
なので、AI を活用する方は Pool 相当のフォルダを 0 番目に置く運用を検討する価値があります。本流の PARA を理解した上での、個人最適化として。
実例：1 つの情報が PARA を旅する
抽象論だけだと分かりにくいので、私の実例を 1 つ紹介します。この記事自体が PARA をどう旅したか、という話です。
最初は、Pool に 1 行のメモがありました。
00_Pool/2026-05-25_para_idea.md
「PARA は人間が理解できる最軽量フレームワーク。AI 時代にも効く」
数日後、これを Qiita 記事にすると決めました。締切と完了条件が生まれた瞬間、Projects に昇格します。
10_Projects/02_para_second_brain/
├── README.md
├── outline.md
├── draft.md ← 今読んでいる、この記事
├── publish.md
└── assets/
執筆中は、Resources にある参考クリップを引き出して材料に使います。たとえば Tiago Forte の解説記事や、Zettelkasten 関連のメモです。Resources が Projects を裏から支える形になります。
Qiita に投稿したら、フォルダごと Archives に下ろします。
40_Archives/02_para_second_brain/
（URL とステータスを README に記録済み）
これで Projects フォルダはまた空きが増え、次の記事案件のために使えます。
もし半年後、誰かに「PARA の運用ってどうやってるんですか」と聞かれたとします。そのときは、Archives から README を引っ張り出して見せます。Archives は墓場ではなく、参照可能な記録庫として機能するのです。
PARA の遷移は、こうした「1 ファイルの物語」の積み重ねです。1 ファイルごとの旅が破綻なく回るからこそ、第二の脳全体が腐らずに育ちます。
週次レビュー：ライフサイクルを回す仕組み
ライフサイクルを意識的に回すために、週に一度のレビュー時間を取ります。15 分で十分です。
- Projects フォルダを開き、終わったものを Archives に移す
- Areas をざっと眺め、Project 化すべきものがないか確認する
- Resources の最近追加分を見て、Project に上げるべきものを拾う
これだけで、4 区分の境目が常にメンテナンスされます。
レビューを 1 ヶ月サボると、Projects が肥大化して 30 個になります。15 分のレビューが、第二の脳を腐らせない投資です。
逆に言えば、第二の脳の運用コストはこの 15 分だけです。設計に何時間もかけるより、軽い構造を週 15 分で回すほうが、結果として続きます。
おわりに
ここまで、第二の脳と PARA メソッドの話をしてきました。最後に二本柱を振り返ります。
- 第二の脳という思想：脳の外側に、検索可能で更新可能な記憶層を置く考え方
- PARA という最軽量な実装：4 区分でライフサイクルが自然に回るフレームワーク
第二の脳は、思想として語ると哲学的に響きます。でも実装としては、フォルダを 4 つ切るだけです。複雑な分類より、シンプルなループのほうが、結果として長く回ります。
もし今、Obsidian の階層構造に消耗している方がいたら、いったん全部をフラットにしてみてください。そのうえで PARA 4 区分から始め直すのです。最初の 1 ファイルを Projects に置く。それが第二の脳の最初の一歩です。
AI を使うなら、Pool フォルダを 0 番目に足してみてください。判定できないメモが、AI 経由で価値を持ち始めます。
ループが回り始めたら、毎週 15 分のレビュー時間だけ確保すれば、第二の脳は勝手に育っていきます。