頭の中にある知識は知識ではありません。あなたのものです——つまり、プロジェクトがアクティブな“いまこの状況”において。ドメインを切り替えたり、新しいプロジェクトを追加したり、数か月が経ったりすると、劣化し始めます。記憶が悪いからではありません。人間の脳が線形かつ確実に扱える量を、情報量が超えているからです。
人々はこれをずっと解決しようとしてきました：インデックスカード、ゼットルカステン、GTD、ウィキ、セカンド・ブレイン。どれも——思考の構造を失わずに、それを外部化しようとする試みです。
しかしLLMがゲームを変えました。いま必要なのは、機械が読めるように知識を外部化することです。そして正しく読めるように。幻覚を起こさずに。さらに、同じ事実に関する矛盾する2つのバージョンのどちらかを、黙って選んでしまわないように。
この記事は方法についての投稿です。ツールではありません。ツールは変数です——Markdown、Obsidian、Notion、プレーンテキストファイルなど、あなたに合うもので構いません。原則は一定です。
RAGとNotebookLMではこれが解決できない理由
どちらも検索問題を解決します。RAG——チャンク間のベクトル類似度。NotebookLM——300ファイルを読み、自分自身で理解を組み立てて、質問に答えます。
鍵になるのはその“自身の”ものです。NotebookLMはあなたのシステムのモデルを構築します——あなたのではありません。あなたの頭の中のモデルが、LLMにとっての“明らか”なものと違っていれば、分かりません。LLMは自信満々に、流暢に、もっともらしく答えます。そして間違ったままです。
RAG — 解決：関連チャンクの発見 · 解決しない：著者の整合性、あなたの構造
NotebookLM — 解決：要約とQ&A · 解決しない：あなたの解釈を保持すること、出力を制御すること
この方法 — 解決：歪みなくあなたのモデルを外部化する · 解決しない：それは検索ツールではない；構造化のための作業が必要
RAGは検索を解決します。この方法は別の問題を解決します——知識を機械に移す際に、著者の“認識論”を保持することです。
原則1：書かれていなければ、それは存在しない
LLMは推測しません。文脈から欠けた部分を埋めません。そこにないものを再構成しません。
技術的には——埋めますが、それはあなたの論理ではなく、自分自身の重みからです。あなたの頭の中にしかルールがないなら、そのシステムにとっては存在しません。クリティカルな詳細が20個のうち1つのファイルにしかないなら、残り19個のファイルを読むエージェントにとってはそこにありません。
これはバグではありません。彼らの性質です。そして、プロンプトで対処するのではなく、設計上（アーキテクチャ的に）それと向き合わなければなりません。
原則2：山積みではなく層
あらゆる知識システムに共通する最もよくある病——入口への引力です。情報は最初に開かれた場所に蓄積します。ウィキならメインページ。Notionなら最初のダッシュボードのブロック。個人の知識ベースなら、最も閲覧されたノート。
解決策：明示的な“層のピラミッド”。各層は、その上の層を拡張します——決して繰り返しません。
Layer 1 — Navigation
One paragraph per topic + a link down.
Rule: if something takes more than 7 lines — it belongs in the next layer.
Layer 2 — Meaning
Why, for whom, by what rules. No technical details.
Readable by someone without specialized knowledge.
Layer 3 — Structure
Components, architecture, interaction map.
All specifications grow from here.
Layer 4 — Scenarios
Step-by-step flows with real data.
Read like a test case: trigger → step 1 → step 2 → outcome.
Layer 5 — Specs
Exact fields, types, formats. Facts only —
explanations already live above.
もしエージェントが最上位の層だけを読めば、浅いモデルを構築し、100%の確信を持ちます。明示的な層は、エージェントに深掘りするためにどこへ行けばよいかを教えます。そして、下位の層が空なら、それは「不要な詳細」ではなく「書かれていない詳細」です。この違いは重要です。
原則3：幻覚の罠は予測可能
幻覚は、テキスト中の曖昧さに対する予測可能な応答です。ランダムではありません。特定のモデルの“バグ”でもありません。特定の書き方パターンにおける構造的な必然性です。
つまり：LLMに読ませると決定論的に誤った出力を生むパターンのカタログを作ることができます。
浮遊する代名詞 — 重要。「システムはリクエストを受け取る。処理のためにそれを渡す。次にコンポーネントが権限を確認する。」2つ以上の主語があると、LLMは重み（自身の評価）に基づいてどれを指すかを選びます。幻覚は保証されます。対策：どこでも明示的に名前を付けること。
見出しと本文が矛盾 — 重要。トランスフォーマでは見出しのほうが重みを持ちます。セクションが「同期処理」と題されているのに、本文がキューを説明しているなら、LLMは見出しを取ります。人間の読者なら気づくでしょう。LLMは気づきません。
未定義の法助動詞 — リスクが高い。「コンポーネントは外部サービスを呼び出すかもしれない。」いつ？どんな条件で？対策：常に条件を明記すること——「Xの場合に限る」「Yのとき」。
取り違え（ソースのない事実）— confabulation — 重要で、いちばん厄介です。エージェントがシステムについて具体的なことを述べる——もっともらしく、文脈と整合しているが、どこにも書かれていない。幻覚と違って、取り違えは説得力があるように聞こえます。確認しない限り捕まえられません——この事実は実際にソースに書かれているのか？
行為者のない受動態 — リスクが高い。「メッセージは正規化され、処理のために転送される。」誰が正規化する？誰が転送する？LLMは決めてしまいます。複雑なシステムなら、ほぼ確実に間違っています。
このカタログを、すべてのファイルに対するチェックリストとして実行してください。スタイルの編集ではありません。エンジニアリングとしての検証です——LLMが読んだとき、この文章は決定論的に（同じ解釈で）読めるのか？
原則4：無言の選択を可視化する
LLMが、同じ事実に関する2つの異なる説明に遭遇したとき、止まりません。矛盾を指摘しません。黙って収束させます：どちらかのバージョンを選び、そのまま100%の確信で継続します。痕跡もありません。目印もありません。
通常の幻覚よりなぜ悪いのか？ 収束したバージョンは現実のものだからです。それはあなたのソースの1つから来ています。「メモにあるか？」と確認すれば、答えはYESです。ただし、正しいバージョンではないだけです。
StanfordとUC Berkeleyの研究者は、ACE論文（Zhang et al., arXiv:2510.04618, 2025）でこれを名付けました：context collapse（コンテキストの崩壊）——反復的なコンテキストの書き換えによって、蓄積された詳細が消えてしまうときの現象です。彼らは測定しました：ステップ60でコンテキストが18,282トークンを保持していたときの精度は66.7%でしたが、その後122トークンに崩壊し、精度は57.1%へ低下し、ベースラインを下回りました。
解決策：すべての選択を、マーカーで可視化すること。
[COLLAPSE:RED]
CHOSEN: ""decision at execution time" — source: note from March 15
ALTERNATIVE: "decision at planning stage" — source: note from February 2
REASON: newer source, but contradiction requires human resolution
重大度に応じて4つのレベル：
- RED — 基本となる意思決定を変更する。止まるべきです。人間が解決するまで、続行しないでください。 返却形式: {"translated": "翻訳されたHTML"}
- YELLOW — 実装の詳細が分岐しています。続けて、明示的に印を付けてください。
- GRAY — 用語の不一致です。続けて、統一のためにフラグを立ててください。
- UNRESOLVED — 論理の矛盾が見つかりました。出どころは不明です。沈黙よりも最小限のマーカーがましです。
同じ事実について2つの版のどちらを選ぶか = マーカーです。例外はありません。
Principle 5: You are the API gateway
これを自動化のように考えたくなる誘惑があります。「エージェントを用意して動かせばいい。私は手を引く。」
それは違う見方です。
価値は、エージェントがあなたなしで働くことではありません。価値は、あなたが制御することです。何が、誰に渡されるのか、どの形式で渡されるのか、どの粒度で渡されるのか。次のエージェントに必要な理解を、あなたが決めます。深さも、あなたが決めます。
ソフトウェアアーキテクチャには API gateway という役割があります。自動化ではなく、フローの制御です。バックエンドはデータを保存します。ゲートウェイは、何を、どう公開するかを決めます。あなたは、外部化した世界モデルと、それを次に扱う相手との間の gateway です。
これは、思考を委譲したい人のためのツールではありません。思考をスケールさせたい人のためのものです — ただし著者であり続けるために。
Where this sits in the landscape
近くで機能している3つの研究の方向性があります — しかし、同じ地点を占有しているものはありません。
Context engineering（コンテキスト・エンジニアリング） は、2025年に名付けられた分野になりました。Andrej Karpathy は、それを「コンテキストウィンドウを、ちょうど適切な情報で満たすという繊細な技術と科学」と定義しました。ですが、答えているのは どのように情報をモデルに提示するかであって、あなたのメンタルモデルが転送の間に生き残るように どう整理するかではありません。
Agent memory management（エージェントのメモリ管理） — ACE（Zhang et al., 2025）と MemOS（Li et al., arXiv:2507.03724, 2025）— はインフラ層で取り組みます。増分更新、メモリのバージョニング、完全なライフサイクルです。この手法は、その1つ上の層で機能します。つまり、エージェントのインフラに到達する前の段階で、知識そのものを整理することです。
PKM + AI — Obsidian/Notion コミュニティです。彼らの核心的な洞察は次のとおりです。AIのところへ行くのではなく、AIをあなたのシステムの中に入れる。コンテキストはモデルのメモリではなく、ファイルの中にあります。精神としては近いものの、統合で止まっています。決定性、ハルシネーションの罠をカタログ化すること、矛盾をフラグ付けするための明示的なプロトコルのようなところまでは、誰も踏み込んでいません。
埋まっていない地点は、3つすべての交点にあります。コンテキスト・エンジニアリングでもありません。エージェントのメモリでもありません。PKM+AIでもありません。
どのエージェントが、どんな順番で読んでも、あなたのモデルを再現するように知識を整理することです。平均化されたものではありません。「自明な」ものでもありません。あなたのものです。
This is not a product
これは手法です。誰もが、自分自身の実装を組み立てるための一連の原則です — 自分の領域、自分のボリューム、自分のツール、自分の作業スタイルに合わせて。
Luhmann は社会学のために自らの Zettelkasten を作りました — そして誰のものも、それぞれ別物です。Forte は生産性のために Second Brain を作りました — そして誰もが、それを異なるやり方で適応させます。この手法は LLM を扱うために作られており、あなたの実装はあなたのものになります。
共通する糸は次の通りです。情報を外部化することで、著者のモデルが著者のままでいられること。ツールによって単純化されないこと。モデルによって完成されないこと。最初の矛盾で、黙って崩れ落ちないこと。
これが、すべての原則です。答えは1つ。実装は無限にあります。
実際に動いているシステムから発展した手法です。挙げているツール — Markdown、Obsidian、オープンソース Copilot — は必須ではありません。この原則は、どんなスタックでも機能します。
参考文献: Luhmann（1981）、Zhang et al. arXiv:2510.04618、Li et al. arXiv:2507.03724、Forte（2022）。
