- Authors
- Name
- Youngju Kim
- @fjvbn20031
- はじめに — 読んだものは多いのに、何も残らない
- PKM古典の速習 — ZettelkastenとPARA
- AIが変えたもの — ノートの役割の再定義
- ツールの地形 — local-firstとプライバシー
- 実践システム設計 — 収集、処理、接続、活用
- デイリーノート — システムの心臓の鼓動
- AI統合レシピ
- メモ負債の防止 — 完璧主義への警戒
- 開発者特化ノート3種
- 4週間構築プラン
- アンチパターン集
- 落とし穴と批判的視点
- 最終チェックリスト
- おわりに
- 参考資料
はじめに — 読んだものは多いのに、何も残らない
HNのフロントページ、GeekNews、ニュースレター5〜6本、会社のSlackの記事共有チャンネル。私たちは史上最も多く読む世代ですが、1週間前に読んだ記事の内容を説明してみてと言われると、ほとんどの人が言葉に詰まります。Hacker News で「Obsidian にノートが4,000個あるのに何も見つけられない」という告白の投稿が話題になったのも、GeekNews でローカルLLMとノートの結合に関する記事が繰り返し上位に上がるのも、同じ渇きの表れです。
2026年ならではの背景もあります。AIコーディングエージェントの普及により、CLAUDE.md や AGENTS.md のようにエージェントにコンテキストを供給する文書を書くことが新しい慣行になりました。よく整理された個人ノートは、もはや人間だけが読むものではなく、自分のAIのコンテキストソースになります。ノートがそのまま自分専用のRAG(Retrieval-Augmented Generation)データベースになる時代です。
本記事は、古典的PKM方法論の核心だけを抽出し、AIが変えた部分を明確にした上で、収集-処理-接続-活用の実践システムと4週間構築プランを提示します。
PKM古典の速習 — ZettelkastenとPARA
方法論の本を一冊読む必要はありません。核心だけ抽出するとこうなります。
Zettelkasten — つながりが知識を作る
社会学者ニクラス・ルーマンが生涯9万枚のメモカードで70冊の本を書いたシステムです。核心原理は3つ:
- 原子性: ノート1つにアイデア1つ。そうして初めて接続が可能になります。
- 自分の言葉で: 引用のコピーではなく自分の文章で書き直します。この変換プロセスこそが理解です。
- 接続優先: 新しいノートを作るたびに「これはどの既存ノートとつながるか?」と問います。知識はノートの中ではなく、ノートの間に積み上がります。
PARA — 行動可能性で分類する
Tiago Forte の PARA はフォルダ構造論です。テーマではなく行動可能性を基準に4つだけ置きます。
P - Projects : 締め切りのある進行中の作業(例: 6月のブログリニューアル)
A - Areas : 締め切りなく継続的に責任を持つ領域(例: 健康、チーム運営)
R - Resources : いつか使う関心テーマの資料(例: Rust、料理レシピ)
A - Archives : 終わったもの、非アクティブなもの
判別の質問はひとつです。「このノートは今、何を動かすのか?」 プロジェクトを動かすならP、責任領域ならA、ただの興味ならR、何でもなければArchives。
2つの方法論の比較
| 項目 | Zettelkasten | PARA |
|---|---|---|
| 焦点 | アイデアの接続と発酵 | 実行とプロジェクトの推進 |
| 単位 | 原子的な永久ノート | フォルダとドキュメント |
| 強み | 執筆、研究、長期的思考 | 仕事の処理、資料の回収速度 |
| 弱み | 初期コストが高い、過剰設計のリスク | 深い接続構造の欠如 |
| 向いている人 | 書く人、研究する人 | プロジェクトの多い実務者 |
結論から言えば、2つは競合関係ではありません。 実務資料の管理はPARAで、思考の発酵はZettelkastenの原理で — 混ぜて使うのが現実的な答えです。
AIが変えたもの — ノートの役割の再定義
検索から対話へ
かつてノートの回収手段はキーワード検索とフォルダ探索でした。今はノート全体を埋め込み(エンベディング)しておき、自然言語で質問します。「去年読んだ分散トランザクションの記事で、サガパターンの欠点は何だったっけ?」が動くクエリになりました。
要約の自動化 — しかし罠がある
読み物をAIが要約してくれる時代に、「ハイライトを書き写す」価値は下がりました。しかし重要な反転があります。要約を読むことと理解することは別物です。 AI要約は収集段階のフィルタとしては優秀ですが、自分の言葉で書き直す処理段階を飛ばすと知識は積み上がりません。ルーマンの原理2番はAI時代でも有効です。
ノートのRAG化
最大の変化です。ノートが人間の記憶補助からAIのコンテキストソースへと拡張されました。
[従来] 自分 -> ノート作成 -> 未来の自分が検索して読む
[2026] 自分 -> ノート作成 -+-> 未来の自分が検索/質問
|
+-> AIエージェントがコンテキストとして使用
(執筆補助、コーディングエージェントの参照文書、
週次レビューの自動要約、ノート間の接続提案)
この観点から、良いノートの基準がひとつ追加されます。機械が読みやすいか? 明確なタイトル、一貫したメタデータ、自己完結した単位 — 偶然にも Zettelkasten の原子性の原則と正確に一致します。
ツールの地形 — local-firstとプライバシー
| ツール | 保存方式 | AI結合 | 強み | 注意点 |
|---|---|---|---|---|
| Obsidian | ローカルMarkdown | プラグイン + ローカルLLM | 所有権、プラグイン生態系 | プラグイン過剰インストールの誘惑 |
| Logseq | ローカルMarkdown | プラグイン | アウトライナー、デイリーノート | 開発ペースの変動 |
| Notion | クラウド | 内蔵AI | コラボレーション、DBビュー | データが企業サーバーに |
| Anytype | ローカル + P2P | 限定的 | local-first哲学 | 生態系が小さい |
| プレーンテキスト + Git | ローカル | CLIで自由 | 完全な制御、永続性 | UIの利便性なし |
2026年の核心論点はプライバシーです。ノートをAIにつなぐということは、自分の思考全体をどこかへ送ることを意味しかねません。選択肢は3つです。
- クラウドLLM + 機密ノート除外: 便利だが分類の規律が必要です。
- ローカルLLM(Ollama、llama.cpp 系): 日記や評価メモまで安心してつなげます。要約・タグ付け・質問応答のレベルならローカルモデルで十分になったのが2026年の現実です。
- ハイブリッド: 埋め込みと検索はローカル、長文生成だけクラウド。
個人的な推奨: 保存は必ずローカルMarkdown(ツールが消えてもノートは残る)、AI結合はハイブリッドから始める。
実践システム設計 — 収集、処理、接続、活用
まず全体のパイプラインを図で見ましょう。
+----------+ +----------+ +----------+ +----------+
| 収集 | --> | 処理 | --> | 接続 | --> | 活用 |
| (Inbox) | | (Process)| | (Link) | | (Output) |
+----------+ +----------+ +----------+ +----------+
RSS/HNキュレーション ハイライトを リンク/タグ 週次レビュー
read-laterアプリ 永久ノートへ MOC作成 執筆/発表
デイリーノート 自分の言葉に変換 AI接続提案 AIへの質問
ステージ1: 収集 — 読み物のインボックス
原則: 読む時間と発見する時間を分離します。発見した瞬間に読むと、一日が粉々になります。
- read-laterツール(または単純なブックマークフォルダ)をひとつ、唯一のインボックスに指定します。散らばったインボックスが2つ以上あると、両方死にます。
- HN/GeekNews キュレーションルーチンの例:
HN/GeekNewsルーチン(1日15分、朝1回)
1. フロントページを流し見するが、絶対に本文を開かない(5分)
2. タイトル+コメント数で候補を選び、インボックスに保存だけする(5分)
3. 昨日のインボックスから「今日読む1〜2本」だけ選ぶ(5分)
残りはそのまま。1週間経った項目は自動削除されても構わない。
- 核心ルール: インボックスは義務ではなく候補リストです。全部読まなければという強迫がシステムを殺します。
ステージ2: 処理 — ハイライトを永久ノートへ
読みながらハイライトしたものは、まだ知識ではありません。変換ルール:
永久ノート変換ルール(ハイライト1つにつき1〜3分)
1. ハイライトを見ずに、内容を自分の文章で一段落書く
(書けなければ理解していない -> 読み直すか捨てる)
2. タイトルは完結した主張の文にする
悪い例: 「キャッシュについて」
良い例: 「キャッシュ無効化はTTLよりイベント駆動が安全だ」
3. 出典リンクを残す
4. 最後の行で問う: 「このノートはどの既存ノートとつながるか?」
すべてのハイライトを永久ノートにする必要はありません。現実的な比率は10個中1〜2個です。残りはそのまま流しましょう。
ステージ3: 接続 — リンクとタグの戦略
- タグは少なく、リンクは多く。 タグは状態管理用に少数だけ(例: seed、growing、evergreen)。テーマ分類はタグではなくリンクとMOCで。
- MOC(Map of Content): 特定テーマのノートが10個を超えたら、それらをまとめる目次ノートを作ります。フォルダより柔軟で、ひとつのノートが複数のMOCに属せます。
- AI活用ポイント: 新しいノートを書いたら「このノートと意味的に近い既存ノート5個」を埋め込み検索で提案してもらうワークフローが効果的です。接続候補の発見はAIが、接続の判断は自分が。
ステージ4: 活用 — 出力がなければシステムは死ぬ
- 週次レビュー(30分固定): 今週作ったノートの流し読み、インボックスの整理、来週育てるノートを1つ選定。
- 執筆による出力: ノート3〜5個がつながれば、ブログ記事1本の材料になります。この記事自体がそうやって作られました。
- 出力の最小単位は大げさである必要はありません。チームのSlackにTILを一段落共有するのも立派な出力です。
デイリーノート — システムの心臓の鼓動
収集-処理-接続-活用のループを毎日回すエンジンがデイリーノート(Daily Note)です。朝に自動生成されるテンプレートひとつから始めます。
# 2026-06-12 (金)
## 今日のフォーカス
- (昨晩または今朝、一行で)
## 作業ログ
- 09:40 決済マイグレーションのPRレビュー — アダプタ境界の設計が良かった
- 11:20 HNで見たローカル埋め込みの記事、インボックスへ
- 15:00 障害振り返り会議 — アラート閾値の議論が空回りした。なぜ?
## TIL
- (3行: 学んだこと / ハマったこと / 明日の自分へ)
## インボックスに送ったもの
- リンク2つ、会議中に浮かんだアイデア1つ
## 明日へ
- アラート閾値についての考えを永久ノートに発展させること
運用原則:
- デイリーノートは捨てるノートです。うまく書こうとしないでください。ここで生き残った文章だけが永久ノートに昇格します。
- 作業ログに時刻を付けると、週次レビューのときに時間の使い方のパターンがタダで見えてきます。
- 会議中に浮かんだ雑念もまずデイリーノートに書きます。頭から出しておくこと自体が集中力を守ります。
分類に迷ったときの決定木
新しい情報をどこに置くか、3秒以内に決めるための木です。
新しい情報が入ってきた
|
+-- 進行中のプロジェクトで使うか?
| はい -> Projectsフォルダの該当プロジェクトノートへ直行
|
+-- いいえ -> 読み物か?
| はい -> インボックスへ(判断は後で)
|
+-- いいえ -> 自分の考え/アイデアか?
| はい -> ひとまずデイリーノートに記録
|
+-- いいえ -> いつか参照する資料か?
はい -> Resourcesにリンクだけ保存
いいえ -> 捨てる(捨てることもシステムの機能だ)
この木が存在する理由はただひとつ、分類の悩みでフローが途切れるのを防ぐことです。どこに置くか3秒以上迷うなら、ひとまずデイリーノートに書いて先へ進みましょう。
AI統合レシピ
レシピ1 — ノートフォルダを埋め込みして質問する
概念: ノートをチャンクに分割して埋め込みベクトルとして保存し、質問も埋め込みして近いノートを探し、LLMにコンテキストとして渡します。動作する最小例です。
# pip install chromadb ollama
# 事前準備: ollama pull nomic-embed-text && ollama pull llama3.2
import os
import glob
import chromadb
import ollama
client = chromadb.PersistentClient(path="./note_index")
col = client.get_or_create_collection("notes")
# 1) ノートフォルダのインデックス化(段落単位のチャンク)
for path in glob.glob("vault/**/*.md", recursive=True):
with open(path, encoding="utf-8") as f:
text = f.read()
chunks = [c.strip() for c in text.split("\n\n") if len(c.strip()) > 80]
for i, chunk in enumerate(chunks):
emb = ollama.embeddings(model="nomic-embed-text", prompt=chunk)
col.upsert(
ids=[f"{path}:{i}"],
embeddings=[emb["embedding"]],
documents=[chunk],
metadatas=[{"source": path}],
)
# 2) 自然言語で質問
question = "サガパターンの欠点について自分がまとめた内容は?"
q_emb = ollama.embeddings(model="nomic-embed-text", prompt=question)
hits = col.query(query_embeddings=[q_emb["embedding"]], n_results=5)
context = "\n---\n".join(hits["documents"][0])
sources = [m["source"] for m in hits["metadatas"][0]]
answer = ollama.chat(
model="llama3.2",
messages=[
{"role": "system",
"content": "以下はユーザーの個人ノートの抜粋である。ノートに基づいてのみ答え、"
"ノートにない内容は『ない』と答えること。"},
{"role": "user", "content": f"ノート:\n{context}\n\n質問: {question}"},
],
)
print(answer["message"]["content"])
print("出典:", sorted(set(sources)))
50行足らずのコードで「自分のノートに聞く」が動きます。すべてローカルで動くので、日記をインデックスしても安全です。Obsidian ユーザーなら同じことをしてくれるコミュニティプラグインもありますが、原理を一度自分で実装してみると、どのツールを使うにせよ限界と可能性が見えてきます。
レシピ2 — 要約プロンプトテンプレート
収集段階で長い記事を一次フィルタリングするときに使うテンプレートです。
次の記事を分析せよ。
1. 核心の主張(3文以内)
2. 根拠のうち最も強いものと最も弱いものを各1つ
3. 著者が扱っていない反論を1つ
4. 自分の既存の関心との接続: [分散システム、開発者生産性、LLM評価]
のうち関連するものとその理由
5. 判定: 精読の価値(高/中/低)+ 理由を一行
記事: (本文を貼り付け)
ポイントは4番です。要約に自分の関心との接続判断をさせると、単なる圧縮ではなくキュレーションの道具になります。
レシピ3 — 週次レビューの自動ドラフト
以下は今週作成されたノートの一覧と本文である。
1. 今週のノートを貫くテーマがあれば何か?
2. 互いにリンクすると良いノートのペアを最大3組提案せよ(理由付き)
3. 育てれば記事1本になりうるシードノートを1つ選べ
4. 1か月前のノートで今週のテーマとつながるものがあれば知らせよ
(ノート本文の貼り付け、またはRAGコンテキスト)
注意: AIの提案はドラフトです。接続を承認し意味を与えるのは、常に人間の仕事です。
メモ負債の防止 — 完璧主義への警戒
PKMが失敗する最も多い理由は怠惰ではなく、完璧主義です。
- フォルダ構造を先に完成させようとしないこと。 構造はノートが100個溜まった後に発見されるものです。
- すべての記事をノートにしないこと。 インボックスの70%が読まれずに捨てられるのは正常な動作です。
- ノートの形式を統一しようとして止まらないこと。 形式の崩れたノート10個は、完璧なノート0個に勝ります。
- 診断基準: この1か月でノートのおかげで良くなった意思決定や成果物がひとつでもあるか? なければ、それはシステムではなく収集の趣味を持っているだけです。
開発者特化ノート3種
コードスニペットノート
タイトル: PostgreSQLで重複行を安全に削除する
タグ: snippet, postgres
文脈: 2026-05 精算テーブル重複ロード事故の対応中に使用
注意: CTIDはVACUUM後に変わりうる — トランザクション内でのみ信頼
(コードブロック)
検証: ステージング200万行でテスト、4.2秒
核心はコードだけでなく、文脈と注意事項を一緒に書くことです。半年後の自分は文脈をすべて忘れています。
TIL (Today I Learned)
一日の終わりに3行。「今日学んだこと / ハマったこと / 明日の自分へ」。負担が低いため最も長続きする形式であり、年末の振り返りと履歴書更新の元データになります。
ポストモーテムノート
障害やミスの後に書く個人版ポストモーテムです。会社の文書とは別に、「自分の判断のどこが間違っていたか」を記録します。このノートの蓄積こそが、シニアらしさの実体です。
4週間構築プラン
| 週 | 目標 | やること | やらないこと |
|---|---|---|---|
| 1週目 | 収集ラインの稼働 | インボックスを1つ指定、HN/ニュースレターのルーチン開始、デイリーノート開始 | ツール比較動画を見る |
| 2週目 | 処理の習慣化 | 1日1つ永久ノートに変換、タイトルを主張の文に | 過去のブックマークの一括移行 |
| 3週目 | 接続の開始 | ノートごとにリンク1つ以上、最初のMOCを1つ作成 | タグ体系の精緻化 |
| 4週目 | 活用とAI | 初の週次レビュー、埋め込みインデックス構築(レシピ1)、出力1つ(TIL共有か短い記事) | プラグインを5個以上インストール |
4週間後の判定: 週次レビューが2回以上実行され、出力が1つ以上出ていればシステムは機能しています。そうでなければツールを変えるのではなく、ルーチンのサイズを半分に減らしてください。
アンチパターン集
| アンチパターン | 症状 | 処方 |
|---|---|---|
| ツールホッピング | 四半期ごとにノートアプリを移住 | Markdown固定、1年間移住禁止の誓い |
| 収集だけの病 | インボックス3,000件、永久ノート0件 | 収集を止めて処理だけを1週間 |
| 完璧な構造への強迫 | フォルダ再設計だけを繰り返す | 構造は事後の発見物として扱う |
| ハイライトコピー機 | 引用ばかりで自分の文章がない | 原文を見ずに書き直すルール |
| AIへの全委任 | 要約だけ溜まり理解はない | 処理段階は手動を維持 |
| 出力のない庭 | ノートは増えるが書く記事はない | 月1回の出力をカレンダーに固定 |
落とし穴と批判的視点
- PKM自体が生産性の演劇になりえます。 ノートシステムの手入れは、実際の仕事をしているような満足感を与える、最も精巧な先延ばしになりえます。出力を基準に自分を監査しましょう。
- **「AIが全部覚えてくれるならノートはなぜ必要か」**という反論があります。一理あります。単純な事実の回収は次第にAI検索が代替するでしょう。しかしノートの本質的価値は保存ではなく、書くという行為が強制する思考の明瞭化です。それは外注できません。
- 埋め込み検索は万能ではありません。 セマンティック検索は表現が違っても意味が近ければ見つけてくれますが、正確なキーワード・コード検索は依然としてgrep系が優れています。両者は補完関係です。
- ノートのRAG化には品質の前提があります。 ゴミノートをインデックスすればゴミコンテキストが出てきます(garbage in, garbage out)。AI統合は処理段階が定着した後の増幅器であって、壊れたシステムの救世主ではありません。
最終チェックリスト
システム
- インボックスが正確に1つか
- 保存フォーマットがローカルMarkdown(または移行可能な形式)か
- 発見の時間と読む時間が分離されているか
- 週次レビューがカレンダーに固定されているか
ノートの品質
- 永久ノートのタイトルが完結した主張の文か
- 引用ではなく自分の文章で書かれているか
- ノートごとにリンクが1つ以上あるか
- 出典が残っているか
AI統合
- 機密ノートの取り扱い方針(ローカル限定/除外)が決まっているか
- 埋め込みインデックスが定期的に更新されているか
- AIの提案(リンク、要約)を人間が承認するステップがあるか
- 処理(自分の言葉への変換)段階をAIに委任していないか
健全性
- 先月、ノートから生まれた出力(記事、意思決定、共有)が1つ以上あるか
- 1年以内にツールを乗り換えていないか
- インボックスを全部読まなければという強迫がないか
おわりに
情報の洪水は止まらず、AIはその洪水をさらに速くするでしょう。その中で差を生むのは、より多く読む能力ではなく、読んだものを自分の言葉で消化し、つなげ、出力するループです。ツールは助けるだけで、AIは増幅器にすぎません。今日やることはシンプルです。インボックスをひとつ決め、ノートをひとつ自分の文章で書くこと。セカンドブレインはそうやって、一枚ずつ作られていきます。
参考資料
- Zettelkasten Introduction — https://zettelkasten.de/introduction/
- Tiago Forte, The PARA Method — https://fortelabs.com/blog/para/
- Obsidian 公式サイト — https://obsidian.md/
- Logseq 公式サイト — https://logseq.com/
- Andy Matuschak, Evergreen notes — https://notes.andymatuschak.org/Evergreen_notes
- Ollama 公式ドキュメント — https://ollama.com/
- ChromaDB 公式ドキュメント — https://docs.trychroma.com/
- Sönke Ahrens, How to Take Smart Notes(書籍紹介)— https://takesmartnotes.com/
- Hacker News: note-taking 討論検索 — https://hn.algolia.com/?q=note-taking
- GeekNews(PKM・生産性の討論)— https://news.hada.io/