PM的記録のススメ：メモの整理方法を作り直した
はじめに
近年、AIの発達によって、あらゆることをMarkdownで記録しておく価値が高まっています。特にClaude CodeのようにローカルのMarkdownファイルを直接読み込んでくれるツールを使い始めてから、「記録＝AIへの資産」という感覚が強くなりました。そこで色々なことを記録するようにしていたのですが、悩ましかったのが「どこに、どういう階層で置くか」です。会議メモ、思いつき、調べもの、日々のTodo…これらをどう分類するかで、いつも手が止まってしまっていました。
Obsidian は、ローカルの Markdown ファイルをそのまま管理でき、ノート間をリンクで繋いで知識のネットワークを育てられるツールです。ファイルの実体がローカルの Markdown なので、Claude Code のようなAIエディタからそのまま読ませやすいのも利点です。こうした Obsidian に Markdown を溜めてAIエディタから読ませる構成では、「単なるメモから知的資産へ：Obsidian in Cursorで構築する知的生産システム」（松濤Vimmer）がよく知られており、私も Cursor を Claude Code に置き換えたうえでこの構成をベースにしていました。ただ運用するうちに「AIが読んでくれるなら、分類の軸ごと変えられるのでは？」と思うようになりました。
本記事では、Zettelkastenベースの運用で感じた課題と、それを解消するために切り直した新しい構成「PM的ノート術」を紹介します。
Zettelkasten
Zettelkastenとは？
Zettelkastenは、ドイツ語で「メモ箱」を意味する、知識管理・メモ術のシステムです。単に情報を記録して保存するだけでなく、アイデアを育て、新しい発見を生み出すための「第二の脳」として機能します。
ドイツの社会学者であるニクラス・ルーマンが実践したことで有名で、彼はこのメモ術を活用して生涯で70冊以上の本と400本以上の論文を執筆しました。
従来のノート術が「情報をカテゴリやフォルダごとに分類して収納する」のに対し、Zettelkastenは「情報同士を脳のシナプスのようにネットワーク状に繋ぎ合わせる」のが最大の特徴です。
メモの数が増えれば増えるほどリンクが複雑に交差するため、一見無関係に思えたアイデア同士が思わぬ形で結びつき、新しい発想や文章の構成が自然と浮かび上がってくるようになります。
Zettelkastenの運用をベースに私は自分なりに以下のフォルダ構成に整理して運用していました。
raw/：会議メモ、講演メモなどの一次資料output/：raw を元に作成したプロジェクト資料permanentNote/：抽象化した知識wiki/：プロジェクト非依存の参考資料daily/：日報
メリット
何かしらのアウトプットを出すときに一番気を遣い、労力もかかるのがファクトチェックです。以前はファクトチェック用の資料管理が意外と大変で、「どこに何を書いたか」がわからなくなることがよくありました。Zettelkastenを取り入れてからは、Literature Notes に参照元を書く習慣ができて、「どこに何の情報があるか」を発見しやすくなりました。
デメリット
一方で、書く前の「判断コスト」が悩みでした。
まず、Fleeting/Literature/Permanent は「どこまで処理されたノートか」という軸です。書くたびに「これはどのノートか」を考える必要があり、日々の運用では判断が遅くなります。
私の運用で一番厄介だったのが、raw と output の分け方です。フォルダの境界は曖昧なことが多く、手が止まる原因になっていました。
また、純粋な Zettelkasten は構造がリンクから自然にできあがる考え方なので、「プロジェクト」のような明示的な単位を持ちません。フォルダで管理する運用とは、この点で相性の悪さも感じていました。
加えて、Literature Notes 自体も期待したほど活きませんでした。方法論について書籍名を残しても、具体的な根拠として求められる場面が少なく、参照元付きで残す意義が薄いからです。実運用では、参照元を残す価値があったのはファクトチェックに使う事実データくらいで、方法論のノートは出典を書く必要性がほとんどありませんでした。
PM的ノート術
この悩みを解いてくれたのが、プロジェクトマネジメントの基本でした。プロジェクトの特徴としてよく挙げられるのが「有期性（始まりと終わりがある）」と「独自性（いつもと同じではない）」です。裏を返せば、プロジェクトとは「いつもしていないこと」だと言えます。この視点で見直すと、「あらゆることがプロジェクトなのでは？」と思えてきます。プロジェクトではないのは、ふと思ったことや、毎日の習慣的なことくらいです。ここで、日々の記録は「毎日すること／毎日しないこと」で切ればよいと気づきました。この発想から、新しい構成を勝手に「PM的ノート術」と呼んでいます。
もうひとつの後押しがAIの存在です。そもそもAIに与える必要がある情報は何かと考えると、次の2つに行き着きました。
- 独自コンテキスト：会議の内容、プロジェクトの経緯、自分自身のことなど、AIが学習データやWeb検索からは知り得ない情報
- 信頼できる知識：世の中に存在はするものの、「数ある情報源の中で私はこれを信頼している」とAIに伝えたい情報
この2つを渡すことが記録の目的だとすれば、フォルダの切り方はAIにとって大きな問題ではありません。AIはフォルダを横断して読んでくれるので、raw と output を混ぜて置いても困りませんし、むしろ関連情報が近くにあるほうが扱いやすいくらいです。つまり、「何を記録するか」はAIの要件で決まり、「どこに置くか」は人間の使いやすさだけで決められます。この2つの気づきをもとに、フォルダ構成を作り直しました。
何をどう変えたのか？
フォルダ構成を次の3つに整理し直しました。
permanentNote/：信頼できる知識を置く場所です。プロジェクトや組織に依存せず、誰にとっても使える一般化された知識をここに集めます。旧構成のwiki/はここに統合し、当初検討していたAboutMe/（自分自身のコンテキスト）も permanentNote にまとめましたdaily/：独自コンテキストのうち習慣的なものを置く場所です。Todo、思いつき、一時メモ、日々の記録などが入りますproject/：独自コンテキストのうちプロジェクトに関するものを置く場所です。会議メモや検討資料などプロジェクト単位のすべてがここに入ります
分類の軸は2段になっています。まず「信頼できる知識」か「独自コンテキスト」かで分け、独自コンテキストのなかを「毎日する／毎日しない」で daily と project に分けます。
新旧の対応をまとめると次のようになります。
| 旧構成 | 新構成 | 変更内容 |
|---|---|---|
daily/ |
daily/ |
役割を拡大（日報 → Todo・思いつき・一時メモも） |
raw/ + output/ |
project/ |
統合。分類判断を廃止 |
permanentNote/ + wiki/ |
permanentNote/ |
統合。自分についてのコンテキストもここへ |
Zettelkasten からの変更点は次の4つで、先ほど挙げたデメリットにそれぞれ対応しています。
- 軸を「処理段階」から「信頼できる知識か／独自コンテキストか」、そして「毎日する／しない」に変えました。書くたびに悩みにくい軸にするためです
- raw と output を分けるのをやめました。AIが横断して読んでくれる前提なら、この判断は要りません
- project という単位を明示的に持ち込みました。フォルダを使う運用では明示的な単位があるほうが実用的です
- Literature Notes の役割は permanentNote に統合し、独立させるのをやめました。方法論では出典を残す意義が薄く、事実データ用の参照元管理も permanentNote の中で扱えば十分だからです
人間とAIの役割分担
この3つのフォルダは、人間とAIのどちらが主に触るかもおおよそ決まっています。
daily/とproject/は人間が直接触るフォルダです。Todoを書き留めたり、会議メモを走り書きしたり、日々の記録を残したりする場所なので、書くのも読むのも人間が主役になりますpermanentNote/は基本的に Claude Code などを介してAIに書いてもらう場所にしています。抽象化して長く残したい知識は、会話のなかで整理されていくものが多く、AIに任せるほうが自然にまとまります
project/ は人間が直接書くこともありますが、会議中に走り書きしたメモをAIに整形してもらってから格納する運用が多く、実際には「人間が書き始めてAIが仕上げる」フォルダになっています。逆に daily/ はほぼ人間が直接書きます。
フォルダ間のリンク
daily/・project/・permanentNote/ は互いに関連する情報を持つことがあります。たとえば project のメモを書いているうちに、他プロジェクトでも使える一般化された知見が見つかることがあります。この場合、その知見は permanentNote に切り出し、両方をリンクで繋げておきます。
Zettelkasten の「リンクで知識のネットワークを育てる」思想を、フォルダ横断の相互参照として残したかたちです。AIが横断して読んでくれるとはいえ、人間が辿るときの手がかりとしてリンクは有効です。
実際の運用方法
書くときの流れは次の通りです。
- 直接編集する場合
- ふと思いついたこと・Todo は
daily/に書きます。関連するプロジェクトが明確ならproject/に直接書きます - 1で記入したことを後でAIに整形させて
project/に格納します。この際に抽象化して残したい知識などは permanentNote に保存します。また、関連するproject/やdaily/の記述があればリンクを張っておきます
この方法は、AIに編集してもらう場合と比べて、渡す前にメモを整えられるのがメリットです。
- AIに編集してもらう場合
- Claude Code に話しかけ、適切なファイルに適切な形で記入してもらいます
読むときは次の2パターンです。
- Claude Code に聞いて、フォルダを横断して拾ってもらいます
- 直接その日の
daily/を開くか、project/から辿ります
メリット
やってみて実感しているメリットは3つあります。
- 毎日確認する場所が1つに減りました。以前は「あのTodoどこに書いたっけ」「あのメモは raw だっけ output だっけ」と複数箇所を見る必要がありましたが、今は日々開くのは
daily/だけで済みます - 記録の場所で悩まなくなりました。書き始めるまでの摩擦が減り、Google Drive などとの「どこに置く問題」も気にならなくなりました
- メモする前に「何のためのメモか」を意識するようになりました。project フォルダに入れるとなると、必然的に「これはどのプロジェクトのメモか？」を選ぶことになります。この一手間があることで、書く前に「そもそもこの記録は何のためにするのか」を意識でき、目的が曖昧なまま情報だけ溜まっていくのを防いでくれます
今後の展望
- スマホから質問しづらいので、Obsidian の拡張の設定などを検討したいです
終わりに
AIに渡すのは「独自コンテキスト」と「信頼できる知識」です。その置き場所は、人間が使いやすいように「信頼できる知識か／独自コンテキストか」「毎日する／しない」で切ります。そして人間が主に触るのは daily と project で、permanentNote は AI に書いてもらいます。これが今回たどり着いた整理です。
なお、デメリットに挙げていた Google Drive など外部ストレージとの連携は、VSCode 上の Claude Code から Anthropic 提供の MCP サーバーを使うことで実現できたため、あらためて整える必要はありませんでした。今後は、スマホからの利用まわりを整えていく予定です。
