
AI 時代の第二の脳はどんな姿か
数年使ってきた wolai は半年更新が止まり、Notion は Claude に繋がらない——そこで Claude Code に頼んで Obsidian の知識体系をゼロから組み上げた。半月後にハッキリ分かった:Notion が目指しているのは OS で、私が欲しいのはファイルシステム。2026 年の今、この 2 つはもう同じ製品ではない。
2026年において、あなたのメモは AI のどれだけの能力を引き出せるかを決める——もはや自分のための備忘ではなく、AI の長期記憶であり、あなたとモデルの間の"コンテキスト層"だ。メモの形は、Claude をそばに置いて読み・書き・検索・分類させられるかを決め、毎日数十回の AI 協働の密度に耐えられるかを決め、年を跨ぎ、ツールを跨いで蓄積し続けられるかを決める。
ところが、多くの人が使っているメモ製品はこの時代のために設計されていない——テンポについていけなかったり、データを SaaS のブラックボックスに閉じ込めていたり、逆に独自 AI を売りつけてくるようになったり。だから「AI 時代の第二の脳はどんな姿であるべきか」は、AI ヘビーユーザーなら誰もが一度問い直す価値のあるテーマだ。
以下は、半月前に Claude Code にゼロから組ませた私の答えだ。まずは結果——半月使ったあと、姿はこうなった:
00-受信箱/ triage 待ちの一時置き場
10-プロジェクト/ PARA:手元の活動中の仕事
20-領域/ PARA:長期的な関心領域
30-リソース/ PARA:参照資料庫
40-原子メモ/ Zettelkasten:知識の細胞(RAG/Agent 等の主題サブディレクトリを含む)
50-トピックマップ/ LYT/MOC:ディレクトリ横断のトピック入口
60-創作/ 創作パイプライン:idea → outline → draft → ready → published
70-ログ/ Periodic Notes:日記 / 週記 / 月記
90-アーカイブ/ 読み取り専用
99-システム/ CLAUDE.md / テンプレート / 用語集骨組みは複雑ではないが、その中にいくつかの目立たない設計が仕込まれている:
- 3 つの方法論の接合:PARA が時間を、LYT/MOC が空間を、Zettelkasten が原子粒度を管理する——3 つは衝突せず、重ね合わせて初めて完成する
- 自作は最小限:1 CLAUDE.md + 2 skill + 5 slash command + 6 テンプレ、残り 95% はコミュニティプラグインに任せる
- AI 階層化協働:AI は「知識層」(事実、整理)を書き、人は「判断層」(立場、反例)を書く。各原子メモの
論拠強度フィールドが、その分業の契約書 - 状態遷移 = mv ファイル:一言の閃きから WeChat / 知乎 / 小紅書での公開まで、全プロセスは
60-創作/の 5 つのサブディレクトリ間でファイルを動かすことで駆動する - bottom-up な創発:上のルールは初日に Claude が与えてくれたものではなく——
#分類/名前空間、論拠強度フィールド、Auto Note Mover の境界はすべて、半月使うなかで生えてきたもの
それぞれの一行がなぜこの形なのか、なぜ wolai も Notion も受け止めきれなかったのか、AI 時代のメモはどうあるべきか——その話は、4 月中旬のある夜、私が継続課金ボタンの前で固まっていた瞬間から始まる。
物語の起点:4 月のあの夜
4 月中旬のある夜、私は wolai を開いた——数年使い、何十万字も貯め込んできた国内版 Notion だ——その日の考えをひとくだり書こうとして。カーソルが空白ページで数回点滅したが、入力する前に、無意識にサイドバーを最下部までスクロールして更新履歴をめくっていた:
死んだとは言わない——「2,148 日連続で安全に稼働」は事実だ。ただ、最新の更新は 2025 年 10 月で止まり、すでに半年動いていない。さらにさかのぼると、2024 年 5 月以降は丸 1 年以上ほぼ散発的なリリースしかない。プロダクト全体から「メンテナンスモード」の匂いが漂っていた。
ついでに個人ホームをのぞいた——

赤い警告が上に貼り付いていた——「個人無料プランの空間がブロック上限(1000)を超えています」。私のメモ規模はとっくに無料プランの天井を突破していたが、もっと刺さったのはこのページがもとは「全公開」だったことだ——半年前は友達にリンクをそのまま送れていたが、いまでは「公開ページを共有する」という最も基本的な機能まで有料の壁の中に閉じ込められていた。
更新がどんどん遅くなり、もともと無料だった中核機能が有料化される——これは並行する 2 つの「離れろ」というサインだ。
マウスを継続課金ボタンの上に乗せ、また外した。
お金の問題じゃない。でもその夜、すぐに踏ん切りはつかなかった——マウスを外し、ブラウザを閉じ、いつもどおりシャワーを浴びて寝た。
本気で乗り換えを考え始めたのは、その後 1〜2 週間でじわじわ浮かんできた発見のせいだ:
AI 時代に入ってから、自分が記録するものがどんどん減っている。
以前はコードを書いていて技術的な細部にぶつかったり、ハマったり、非自明な解法を見つけたりすると、未来の自分のためにササッと書き残していた。wolai に貯まった何十万字のかなりの部分は、そうやって積み上がったものだ。
しかし Claude Code を使い始めてから、この種のメモはほとんど生まれなくなった——AI がすでに問題を解いていて、次に似た問題が来てもまた解いてくれる。「バグの解き方をメモに頼って覚えておく」必要はもうない。記録するものの性質がそっと変わっていた:「マニュアル的な細部」から、体系的な思考、決断の理由、論文を一本読み終わって整理した 1〜2 個の洞察へ。
そこで初めて気づいた——メモの性質が変わったなら、メモの容器ももう一度選び直すべきではないか?
私は wolai を期限で更新しないことに決め、10 年もつメモ基盤を探すことにした。そして今回は、Claude にこの作業を任せることにした——もう一度自分で 1 マスずつ体系を組む気力はないし、こういうことは AI のほうが速くて上手いとすでに分かっていた。
あの夜のためらいと、続く 1〜2 週間で浮かんだ気づきが、私を意外な道に押し出した——Claude Code に新体系をゼロから組ませた半月、そして避けて通れなくなった一連の問いだ。
Notion では受け止めきれない
wolai を離れる決断のあと、自然に次の駅として思い浮かぶのは Notion だった。同じブロック単位の編集、同じマルチプラットフォーム、中国のエンジニア界隈でも定評がある。新しいワークスペースを作って引っ越しを始めた。
最初の壁にすぐぶつかった。今の私のメモの 70% は Claude が書いている——主題を体系的に整理させたり、動画文字起こしを構造化されたメモに変換させたり、論文を数本の原子的な洞察に圧縮させたり。このワークフローは、AI がファイルを書くのと同じくらい自然にメモへ書き込めることを要求する。Notion には MCP がある。期待に満ちて接続した。
接続後、3 層の壁に立て続けに突き当たった。
第 1 層:遅くて、しかも何度も再認可が要る。
Notion MCP は直接ファイルを読み書きしているのではなく、操作ごとに API リクエストにくるんで Notion のサーバーに送り、レスポンスを待つ。Claude が少し複雑な構造のメモを書くと、十数回の block append 呼び出しに分割され、それぞれにネットワーク往復が発生する——メモ本体の書き込み時間の大半がサーバー待ちに消える。さらに我慢ならないのは、これが一度認可すれば終わりではないこと。数操作おきに、こんな確認ダイアログがポップアップし、手で「OK」を押さないと続行できない:

「Claude にこの主題を整理させる」一回の作業が 3〜4 区切りに分かれ、各区切りで画面の前で「うん、OK」を押さなければならない——もともと遅い API 往復と合わせて、ワークフロー全体が粘度の高い泥のように引き伸ばされる。Obsidian にはこの 2 層の摩擦が一切ない:ローカルファイル、Claude が直接 .md を Write するだけ。ローカルディスク IO、ミリ秒単位、間に頷きを求める者はいない。私は 1 日に十数ファイル Claude に触らせる可能性があり、その差は無限に拡大される。
第 2 層:AI サブスクの孤島。
Notion の直近 2 年の進化は明らかに AI 重心だ——内蔵 AI 執筆、Q&A、agent 系の機能が次々と追加されている。notion.com を開けば一目瞭然:
しかし私にとってこれらは全部冗長だ。私のメインの AI サブスクはすでに Claude 側にある——Claude Code の 200 ドルプランは毎日上限まで燃やしており、能力、コンテキスト、記憶どれも十分。私が欲しいのは、すでに持っている Claude の能力をメモの中に延長することであり、メモアプリのために独立した AI に追加で課金して、新しい agent スタイルに合わせ直すことではない。ワークフローは自分でコントロールできるべきで、どこかの SaaS の AI 生態系に逆に取り込まれてはならない。
第 3 層:ブロック単位編集はもう時代遅れ。
Notion が誇る「ブロック単位編集」——ドラッグ、埋め込み、双方向データベース、各段落を組み替え可能なレゴブロックとして扱う——このパラダイムは「人が書いて人が読む」時代には先進的だった。だが、私のメモが主に AI が書き、私が読み、さらに AI が検索して振り返るものになると、ブロックは逆に枷になる。具体的には、Notion の内部はブロック JSON で、markdown → block の変換は完全ではなく、入れ子リスト、callout、コードブロックの言語マーカーは落とし込み後に変形する——AI は書きにくく、私は読みにくく、検索も透明ではない。
しかし本当に私にこれを閉じる決心をさせたのは、上の画像の背後にあるより大きな事実だ——Notion 自身がもうかつての「第二の脳」ではなくなっている。彼らは 企業向け AI ワークプラットフォーム へ進化しつつあり、Forbes Cloud 100 のような顧客には合うかもしれないが、私の目的とはもう離れすぎている:
Notion がやりたいのは OS、私が欲しいのはファイルシステム。 2026 年において、この 2 つはもう同じ製品ではない。
2 年間敬遠していた Obsidian
Obsidian はじつはずっと前にインストールしていた。2 年前にインストールして、アイコンは Dock に置きっぱなしだった:

でも一度も本気で開いたことがなかった——理由は「十分にブロック的でない」、ファイルが markdown 一枚一枚で、「原始的すぎる」と思っていたからだ。
この瞬間になってようやく気づいた:私が以前敬遠していたすべての点は、ちょうど AI 時代のメモにとって長所だった。
The best file format for the future is the one you can read without the app that created it.
kepano は Obsidian の CEO だ。彼は File over app の中で、ほとんど反直感に思えるほど素朴な原理を語っている——ソフトは消える、ファイルは消えない。Notion が死ぬかもしれない、Obsidian も死ぬかもしれない、しかしあなたのディスクに残った .md ファイルの山は、どんなアプリの死にも引きずられて開けなくなったりはしない。AI 時代に本当に再利用可能なメモとは、ある SaaS の内部構造ではなく、plain text + 自分が制御できるディレクトリ構造だ。
これが、私が wolai と Notion から撤退した根本理由だ——データ主権。
ただし、Obsidian だけでは足りない。Obsidian は空の markdown エディタにすぎず、「知識をどう組織すべきか」は教えてくれない。だから私は、後から幸運だったと思える決定をした——「どう組織するか」を丸ごと Claude に外注したのだ。
一文の要求、一份の方案
Claude Code を開いて、こう打ち込んだ——後にこのまま方案ドキュメントの Context にコピーされる:
いまから自分の Obsidian システムを組みたい。関連プロジェクトを見て回ってほしい、GitHub に何かいい仓库があるか見て。要するに、AI を使って体系全体をうまく管理できる仕組みが欲しい。
ディレクトリ構造の指定もなければ、入れるプラグインの指定もない、方法論の指定もない。言ったのは 3 点だけ——体系が欲しい、できればゼロから作らない、できれば AI がスムーズに参加できるように。
数時間後、Claude が方案ドキュメントを返してきた。読んで承認した。中核は 5 つの原則で、その後の私が繰り返し引用するくらい簡潔だ:
- プラグインで済むならコードを書かない——日記、テンプレ、双方向リンク、クリッピング、自動分類、すでに成熟したコミュニティプラグインがあるので全部インストールする
- clone で済むならゼロから作らない——kepano/kepano-obsidian(Obsidian CEO が公開している個人 vault)をディレクトリ骨格の参考サンプルにする
- 自作 Skill より MCP——既製の
MarkusPfundstein/mcp-obsidianを Claude Code に接続する。「メモを読み書きする」程度の基礎能力を再発明しない - 既存の yux-* skill チェーンを再利用——成稿の磨き上げ + 多プラットフォーム公開のスキルチェーン(公衆号 / 知乎 / 小紅書)は既にあるので、新システムは「閃き → 草稿」前半を担当し、後半はそのまま引き継がせる
- 自作は「既製では解けない意味的判断と接着層」だけ——CLAUDE.md 規約、AI トリガーの triage プロンプト、つなぎの糊
最終的に自作の工数は次に圧縮された:1 CLAUDE.md + 2 skill + 5 slash command + 6 Templater テンプレ。最初に自分で考えた版より 60% 少ない。
方案を読んで最初に思ったのは——「この AI は私より節制を知っている」だった。
多くの人が vault 構築で失敗するのは、努力が足りないからではなく、一行ごとのルールを自分で書きたがるからだ。3 か月後、自分が書いた山ほどの hook と skill を維持できなくなり、新鮮さが切れた瞬間に体系まるごと放置される。Claude は最初から教えてくれた:能力の 95% は生態系に外注し、自作は AI でしか解けない 5%——意味レベルの判断だけにしろ。これ自体が今回の実験における最大の収穫の 1 つだった。
Claude が組んでくれた姿
Claude の中核成果物は、vault ルートに置かれた CLAUDE.md だ——このファイルが**体系全体の「憲法」**だ。vault の言語、方法論、双シナリオの境界、AI の役割、ディレクトリの硬いルール、frontmatter、タグ名前空間…をすべて定義しており、新しい Claude Code セッションを開いた時、これ一枚を読むだけで vault 全体の協働を引き継げる。冒頭はこんな感じ:

骨格は冒頭ですでに見せた。ここで再掲はしない——私が話したいのはディレクトリそのものではなく、骨格の背後で 3 つの方法論がどう噛み合うか、そして体系が使えるかどうかを決める 2 つの境界だ。
骨格の背後には3 つの方法論の混合がある——それぞれが 1 つの次元を担当する:
| 方法論 | 出典 | vault での体現 | 解決するもの |
|---|---|---|---|
| PARA | Tiago Forte『Building a Second Brain』 | 10/20/30/90 トップ階層 | 「いま私は何をしているか」——時間次元 |
| LYT / MOC | Nick Milo Linking Your Thinking | 50-トピックマップ/ | 「アイデア同士の横断連想」——空間次元 |
| Zettelkasten | Sönke Ahrens『How to Take Smart Notes』 | 40-原子メモ/ | 「知識細胞」——原子粒度 |
PARA は「手元のものを実行可能性でどう分けるか」を、LYT は「アイデア同士がどう呼び合うか」を、Zettelkasten は「各洞察を独立したブロックにどう立てるか」を担当する。3 つは衝突せず、重ね合わせて初めて完全になる——大半の人は 1 つしか学ばず、結果いつまでも体系がどこか欠ける。
伝聞だけにせず、3 人の著者から最も鋭い 1 文を引いておく——
Tiago Forte の PARA、「なぜ主題で分類しないのか」についての中核判断:
Instead of organizing information according to broad subjects like in school, I advise you to organize it according to the projects and goals you are committed to right now.
これが、私の 10-プロジェクト / 20-領域 / 30-リソース / 90-アーカイブ をトップ階層にした理由だ——それらは行動状態であり、トピックではない。「AI / 執筆 / プロダクト」のような主題分類は二次的な #主題/ タグでしかない。
Sönke Ahrens、『How to Take Smart Notes』の Zettelkasten で最も引用される一文は:
A note is only as valuable as the network it's embedded in.
一つのメモの価値は、それが埋め込まれているネットワークの価値に等しい。
原子メモ 1 枚だけでは意味がない。その価値はほかのメモとの連結密度から生まれる。だから 40-原子メモ/ では密な双方向リンクを推奨している——リンクを 1 本足すごとに vault 全体の資産価値が上がる。
Nick Milo の LYT は上の理屈をよりエンジニアリング寄りに落とし込む——彼はハードコードされた「完璧な分類」を否定し、MOC(Map of Content)を生きた目次として使い、構造を使用の中で生えさせることを主張する。これがまさに 50-トピックマップ/ の底にあるロジックだ:MOC はフォルダの代替ではなく、あるトピックの入口から、関連するばらばらのメモすべてを見渡せる——フォルダより緩く、タグより構造化されている。
そして体系が使えるか使えないかを本当に決めるのは、混同してはいけない 2 つの境界だ:
第 1 条:40-原子メモ/ ≠ 60-創作/素材庫/。 前者は永久的な知識資産——1 つの原子メモ = 1 つの独立した、どこからでも引用される想定の考えや洞察で、繰り返し逆方向にリンクされることが期待される。後者は使い捨ての素材——ある具体的な公衆号原稿で使う名文、ケース、引用断片で、ライフサイクルはその原稿そのものに等しい。この境界を混同すると、知識ベースはいずれ使い捨てコンテンツに飲み込まれる。
第 2 条:知識ベース ≠ 創作。 10/20/30/40/50/70 は知識層、60-創作/ は創作層。両層は片方向の埋め込みで繋がる——原稿は ![[原子メモ#章節]] で原子メモの内容を引用できるが、原子メモは原稿に逆リンクしない。この片方向バルブが知識層の純度を守り、ブログ記事がバズろうがコケようが、その背後の原子メモの安定性に影響しない。
タグ体系は名前空間で厳密に 4 種類に分かれる:
#類型/原子— 構造的タイプ、AI が frontmatter フィールドに基づいて自動付与#主題/ai— 主題分類、人が手で付与#状態/未読— 一時的なステータス、使い終わったら削除#分類/RAG— サブディレクトリ分類(40-原子メモ/でのみ使用)、AI が主題に基づいて自動付与
最後の #分類/ 名前空間は、構築初日には存在しなかった——2 週間使ったあと、原子メモが増えてサブディレクトリに分けたくなったが、Auto Note Mover に全体の分類ロジックを書き直されたくなかったので、「原子メモの二次分類」を専門に扱う名前空間として独立させたのだ。
この細部は後でわざわざ取り上げる——今回の実験で最も意外だった経験の 1 つだ。
私の毎日の使い方

ブラウザからワンクリックで定位置へ
このフローはもう筋肉記憶だ。Chrome に公式の Obsidian Web Clipper を入れていて、良記事を見たらボタンを押す——先週 Anthropic の『Building effective agents』もこの操作だった——本文 + ソース URL + 自分でつけたハイライトが、自動で埋まった frontmatter とともに 00-受信箱/ に落ちる。
ターミナルに戻って /inbox:
$ claude
> /inboxClaude が記事を読み終えて返してくる:「この内容は Anthropic 公式の agent 設計パターンの総括で、構造性が強く個人的意見ではない——『記事クリップ』タイプと判定、30-リソース/記事クリップ/ への配置を提案。同時に 3〜5 本の原子メモを 40-原子メモ/Agent/ に切り出しますか?」
私は「まずクリッピングに置いて、原子メモは自分で読み終えてから切り出す」と答える——Claude がファイルを mv し、類型: 記事クリップ の frontmatter を補い、#類型/記事クリップ #主題/ai のタグを足し、30 秒で片付く。私がやったのは Clipper ボタンを 1 回押す、ひと言入力する、それだけ。
このフローは半月前まで全部手動だった——ダウンロード → リネーム → どのフォルダか判断 → frontmatter 記入——1 本最低 5 分、迷うと 1 週間放置するものまであった。今は受信箱に 10 本あっても 5 分で片付く。
一言の閃きから成稿まで
これが私のシステムで最も長いパイプライン。一言の閃きから 3 プラットフォーム(公衆号、知乎、小紅書)への公開完了まで、すべてファイル移動で駆動する:
/idea Claude Code Skill が MCP より柔軟な理由
↓ 60-創作/01-アイデアプール/20260502-...md(Templater が frontmatter 自動記入)
/draft <アイデアファイル>
↓ Claude が 40-原子メモ/ から関連原子を、素材庫から過去素材を引いて
↓ アウトライン + 初稿を組む
↓ 60-創作/03-初稿/ に落とす
/publish
↓ yux-blog-writer が磨き → yux-publish-* が多プラットフォーム公開
↓ ファイルが 05-公開済み/2026/05/ に mv、frontmatter に各プラットフォーム URL を書き戻しこのパイプラインには私が特に気に入っている設計がある:状態遷移は mv ファイル。ファイルがどのディレクトリにあるかが、その状態だ。Kanban プラグインは 60-創作/ の 5 サブディレクトリから直接 5 列のボードを生成する、コード 0 行——カードをドラッグするだけでファイルが動く。ワークフローと呼ぶのが憚られるほど単純だ。
AI が書き、私はただ読む
このシーンが、wolai 時代の何十万字「人が書き人が読む」モードから、AI 時代の「AI が書き人が読む」モードへの本物の切り替えだ。
私は Claude に「ある主題を体系的に整理して」と頼む——例えば RAG。Claude は 40-原子メモ/RAG/ 配下に直接書き、各メモが独立した原子メモになり、#類型/原子 #分類/RAG #主題/ai タグと正しい frontmatter が付く。書き終えると報告してくる:「このバッチは 12 本書きました、暇なときに読んでください。論拠強度はすべて『検証待ち』にしてあります、読み終えたら『検証済み』に変えてください。」
私がやることは:読む、判断する、『検証待ち』を『検証済み』か『推測』に変えるだけ。wolai に貯めた何十万字のかなりの部分はこの種の整理作業——本来 AI がやるべきだった。いま私が執筆の 70% を AI に任せられるのは、私の役割そのものが変わったからだ。
セッションを跨いでも一貫している
このシステムが本当に「生きている」と感じた瞬間は、新たに開いた Claude Code セッションだった——プロンプトを何も与えず、いきなり一段落投げた:「これを適切な場所に貼って」。
Claude は CLAUDE.md を読み、私のその文章の意味を解析し、こう返してきた:「これは原子メモには見えません(結論が十分に独立していない)、創作素材に近いです——どの原稿向けの素材ですか?」
Claude が私のルールで逆に私を問い詰めている。
これは構築初日には予期しなかった副産物だった——ルールを十分明確に書くと、AI はルールを実行する過程で、あなたに「自分が本当は何をしているのか」を考え直させる。
半月後にやっと分かったこと
AI 時代に知識体系を組むときに最もハマる落とし穴は、AI に「完璧な分類」を最初から設計させ、自分が予定に追いつけなくなること。
構築初日、Claude が出してくれたディレクトリ構造は試験答案のように整っていた。しかし 15 日目に本当に使えているのは、その整った答案 + 「使ってみて初めて分かる」一連の修繕だ。例えば:
- 原子メモが溜まりすぎてルートが混乱 →
#分類/名前空間と主題サブディレクトリを追加 - AI が書いたメモと自分で考えて書いたメモが混ざって区別できない →
論拠強度frontmatter フィールドで層分け
これらのルールは Claude が初日に予知して出したものではなく、半月使い、いくつか踏んでから生えてきたものだ。
初日の方案で kepano をそのままコピーしていたら、今日の #分類/ は永遠に存在しなかっただろう——それは kepano のニーズではなかったからだ。本当に使える体系は、使って生まれるものであり、考えて生まれるものではない。
AI 時代のメモを考え直す

ここまで来て、断言できる判断が 3 つある——できるだけシンプルに:
1:メモの相手が、私から AI に変わった。
以前のメモは未来の自分向けに書くものだった——だから記録量が多く、整理が美しいほど良かった。だが今は、大半の時間 AI が書き、AI が読み、AI が探す。メモの本当の相手は変わった:いまや AI が必要なときに呼び出す「長期記憶」であり、自分はついでに読むだけだ。
これがそのままメモツールの選択基準を決める。私が wolai と Notion から撤退した根本理由は、更新停止や重さではなく、それらのコンテンツが AI から使えないこと——SaaS のブラックボックスでは AI が手元から呼べないので、どんなに綺麗なノートでも救えない。だから今の私のメモツール評価における第 1 の問いは「私のコンテンツは AI から自然に読み書きされ得るか?」。Yes なら使う、No なら手放す。
2:AI が知識を書き、人が判断を書く。
事実、整理、技術原理は AI が私より速く正確に書ける——手で書くのは二人分の時間の浪費だ。しかし立場、評価、反例は自分で書かなければならない。AI に書けないからではなく、ここまで外注し始めたら、自分の判断への自信を徐々に失っていくからだ。今年 3 月の HN 高評価記事はこれを最も鋭く言っている:
The risk isn't that AI replaces our thinking. It's that we lose confidence in our own judgments — even in domains where AI cannot meaningfully contribute.
私の対策は、各メモに「検証待ち / 検証済み / 推測」の印をつけること——AI が書いたものは全部「検証待ち」、自分が読み終えたら「検証済み」または「推測」に変える。このキーを押す手は、自分でなければならない。
3:体系は使って生えるもの、考えて作るものではない。
これは前節ですでに言い切った——AI に初日から完璧な目次を描かせるな。2 週間動かせば、自分にだけ必要なルールが自然と数本顔を出す。
これは始まりにすぎない
この体系は組んでまだ半月、定型化にはほど遠い——だがすでに私の用には足り、この記事を書き出すには十分だ。
もし自分のも組みたいなら——私のディレクトリを真似るな、方法を真似ろ。この記事を Claude Code に丸ごと投げて、こう伝えてほしい:
この記事の体系を参考に、自分用の体系を組んでほしい。
ディレクトリを直接コピーせず、まず 10 個質問してくれ。例えば:
- 毎日どれくらい新規コンテンツを読む?動画、論文、ブログ?
- 執筆や公開のニーズはあるか?どこに公開する?
- メモの中で AI にどんな役割を期待する——
読むだけ、整理、それとも直接書かせる?
- 一度きりの素材として使うメモと、長期蓄積する資産は?
- 旧メモはどこに?全部移したいか、ゆっくり消化させたいか?
- …残りはあなたが聞いて。
私の回答を CLAUDE.md の Context に書き留めてから、方案を出してくれ。Claude は私のとは違う、あなたのための体系を渡してくれるはずだ。
wolai に貯まった何十万字のメモは、全部は移さなかった——AI にゆっくり消化させる予定だ。これは体系の第二段階の仕事になる。いつか『AI に何十万字の旧メモを読み切らせた』という記事がこのブログに上がったら、それは体系が成長したという証だ。
その瞬間、それはただの Obsidian vault ではなくなる——私のものになり、10 年もつ第二の脳になる。
関連リーディング
この記事で引用した方法論とツールを掘りたい人向けに、重要度順に:
- File over app — kepano が「データはなぜファイルであるべきか」を語り切った千字短文、5 分で読めて 10 年効く
- How I use Obsidian — kepano 自身の vault がどう見えるか、bottom-up なノートテイキングの代表サンプル
- The PARA Method + Introducing The AI Second Brain — Forte の PARA 原論 + AI 時代の拡張
- How to Take Smart Notes(Ahrens)+ Linking Your Thinking(Milo)— Zettelkasten と LYT の方法論古典
- AI-Augmented Zettelkasten Forum スレッド — 「AI に直接カードを書かせる」ことへの反対派の代表的声
- MarkusPfundstein/mcp-obsidian — Claude Code が vault 全体を自然に読み書きできるようにする MCP server
関連記事
Claude Skills でWeChat公式アカウントにワンクリック公開
baoyu-post-to-wechat Skill を使って Markdown からWeChat公式アカウントへの自動公開を実現する方法を、インストール・設定・公開の全プロセスにわたって解説します
Eclipse から Zed へ:ある開発者のエディタ進化史
バックエンド開発からフルスタック開発へ、200以上のプラグインを持つ VS Code からターミナルファーストのワークフローへ。AI時代とともに変わってきた私のエディタ選びの記録
私の Claude Code ベストプラクティス
Claude Code でコードを書く際の知見を共有します。10の核心テクニック、スラッシュコマンド詳解、カスタムコマンド設定で、AIプログラミングの効率を向上させましょう

