ほとんどの人は、AI を答えを出す自動販売機のように使っています。
書類をアップロードする。質問をする。回答を得る。タブを閉じる。翌日、また同じ書類をアップロードする。少し違う質問をする。昨日のことはなかったかのように、モデルがまたゼロから始まるのを眺める。
これが、今日における「AI 生産性」のデフォルトのパターンです。最初の数回は、システムが投げかけるほとんどすべてのものに対して要約、説明、洞察の抽出ができるので、魔法のように感じられます。しかし、数週間もすると、その魔法は不思議なくらい使い捨てに感じられ始めます。知識を構築しているのではなく、知性の短いバーストをレンタルしているだけなのです。
問題は、モデルが弱すぎることではありません。問題は、ワークフローに複合的に積み上がる記憶がないことです。
Andrej Karpathy は、より良いパターン、すなわち LLM を使って個人の知識ベースを構築し維持する方法を説明しました。アップロードした PDF のフォルダだけではありません。書類に対するチャットボットだけでもありません。LLM が時間の経過とともに更新する、永続的で構造化され、相互にリンクされた Wiki です。
重要なのは Wiki そのものではありません。Wiki は何十年も前からあります。
重要なのはメンテナンスです。
それが、AI 以前にほとんどすべての「セカンドブレイン」システムを頓挫させた欠けていたピースです。人々は個人の知識ベースというアイデアを愛します。Obsidian のグラフ、Zettelkasten の図式、PARA フォルダ、タグ付きノート、バックリンク、エバーグリーンノート、ダッシュボード、その他すべてを愛します。しかし、最初の熱意が冷めた後、たいてい同じことが起こります。そのシステムは、メンテナンスすべき別のシステムになってしまうのです。
記事をクリップしても要約しない。ノートを作っても関連付けない。タグ付けに一貫性がない。新しい情報が入っても古い主張を更新するのを忘れる。美しい構造を作り、そして、すべての操作がさらなる簿記作業を生み出すので、徐々にそれを避けるようになる。
セカンドブレインが失敗するのは、その後の後片付けにまだファーストブレインが必要だからです。
Karpathy の LLM Wiki パターンは、この経済性を変えます。知識ベースを個人のノートというよりは、コードベースのように扱います。生のソースが入力されます。LLM がそれを読み、重要な部分を抽出し、Markdown ページを作成または更新し、相互参照を維持し、矛盾を追跡し、インデックスを最新に保ちます。人間は手作業で Wiki を書きません。人間はソースを厳選し、質問をし、出力をレビューし、何が重要かを決定します。
Andrej Karpathy の投稿
https://x.com/karpathy/status/2039805659525644595
これは、はるかに興味深い役割分担です。
検索から複合的知識へ
今日のほとんどの AI ドキュメントワークフローは、検索に基づいています。ファイルをアップロードすると、システムはそれをチャンクに分割し、チャンクを埋め込み、質問があったときに関連する箇所を検索します。これは多くの RAG システムの背後にある基本的なアイデアであり、有用です。これにより、モデルはトレーニングデータに含まれていない資料に関する質問に答えることができます。
しかし、検索には上限があります。
質問をすると、システムは検索し、いくつかの断片をコンテキストに引き込み、回答を生成します。回答は良いかもしれませんが、会話が終わるとその作業は通常消えてしまいます。その統合は、自動的に永続的な構造の一部にはなりません。次の質問は、別の検索サイクルを開始します。
これは一回限りの質問には問題ありません。しかし、理解が蓄積されるべき学習、研究、執筆、戦略には弱いです。
LLM が管理する Wiki は、異なる動作をします。クエリのたびにすべてをゼロから合成するのを待ちません。事前に知識をコンパイルします。
新しいソースを追加すると、LLM はそれを読み、既存のシステムに統合します。論文がコンセプトページを更新するかもしれません。会社のプロフィールが競合他社のページを改訂するかもしれません。トランスクリプトが顧客のペインポイントに証拠を追加するかもしれません。新しい記事が古い要約と矛盾する場合、Wiki はそれを文書の山に静かに埋もれさせるのではなく、その緊張関係をフラグ付けします。
質問は「適切な段落を検索できるか？」から「このソースを追加したことで、私の知識ベースはより賢くなったか？」へと変わります。
これこそが本当のシフトです。知識が累積的になるのです。
三つの層
アーキテクチャは非常にシンプルなので、そのシンプルさを見逃しがちです。
最初の層は、生のソースです。これらは元の資料です。記事、PDF、ノート、トランスクリプト、論文、Web クリップ、画像、リポジトリ、データセット、そしてシステムに認識させたいその他すべてのものです。この層は不変として扱われるべきです。AI はそれを読み、引用し、要約することはできますが、証拠を書き換えるべきではありません。
二番目の層は Wiki です。これは LLM によって管理される Markdown ファイルのディレクトリです。ソースの要約、コンセプトページ、エンティティページ、タイムライン、比較、未解決の質問、インデックス、研究概要を含めることができます。これがコンパイルされた層です。ここで生の素材が使える知識になります。
三番目の層はスキーマです。これは、LLM にメンテナーとしてどのように振る舞うかを指示する一連の指示です。どのフォルダが存在するか？ ソースの要約とは何か？ 引用はどのように機能すべきか？ いつ古いコンセプトページを更新する代わりに新しいものを作成すべきか？ 矛盾はどのように記録されるべきか？ ヘルスチェックは何を探すべきか？
スキーマは、チャットボットをオペレーターに変えるものです。
それがなければ、即興で動くモデルがいるだけです。それがれば、ハウススタイル、ファイリングシステム、メンテナンスの儀式を知っている、ジュニアリサーチャーに近いものが手に入ります。
Obsidian は、すでにバックリンク、グラフビュー、高速ナビゲーションを備えたローカルの Markdown 環境であるため、このワークフローに自然に適合します。Karpathy のフレーミングは有用です。Obsidian は IDE、LLM はプログラマー、Wiki はコードベースです。
この比喩は重要です。コードベースはファイルが含まれているから価値があるのではありません。ファイルが規則に従い、相互に参照し、リファクタリングでき、リントでき、やり直さずに改善できるから価値があるのです。真剣な知識ベースも同じように機能するべきです。
人間は事務員であるべきではない
個人知識管理の古いモデルは、暗黙のうちに人間がすべてを行うことを前提としていました。
ソースを読む。ハイライトする。要約する。フォルダを選ぶ。タグを追加する。リンクを作成する。古いノートを更新する必要があることを覚えておく。二つのソースが矛盾していることに気づく。インデックスをきれいに保つ。孤立したノートを削除、マージ、または接続すべきか判断する。
これはまさに、一週目は生産的に感じられ、三ヶ月目には耐え難くなる種類の作業です。
そして、それはまさに LLM が得意とする種類の作業でもあります。
LLM は反復的な構造に飽きることがありません。一度に 15 のファイルを更新することを厭いません。古くなった主張、欠落したバックリンク、重複したコンセプト、一貫性のない命名、未解決の矛盾をスキャンできます。乱雑なソースを、要約、主張のリスト、エンティティページの更新、コンセプトページの更新、後で調査する価値のある質問という、五つの有用なアーティファクトに変えることができます。
人間は判断に近いところに留まるべきです。
どのソースをシステムに含めるべきか？ どの主張が実際に重要か？ 次にどの質問をする価値があるか？ どの統合が真実で、有用で、驚きで、または間違っていると感じられるか？ 何を記事、メモ、デッキ、決定、製品アイデア、研究の方向性に変えるべきか？
それがセンスの問われる部分です。
LLM は知識の事務作業を行うべきです。人間は意味の編集作業を行うべきです。
実際の様子
あなたが市場を調査していると想像してください。いくつかのアナリストレポート、競合他社のブログ記事、顧客インタビュー、製品ページ、営業電話のトランスクリプトから始めます。古いワークフローでは、これらは書類の山になっていました。おそらくチャットボットに質問するかもしれません。おそらくスプレッドシートを維持するかもしれません。おそらく、新しい情報が入るとすぐに古くなるメモを最終的に書くかもしれません。
LLM Wiki ワークフローでは、すべての新しいソースが生きた地図を更新します。
競合他社の発表は、競合他社のページを更新します。顧客との通話は、異議、ペインポイント、購入のきっかけ、顧客が実際に使う言葉に関するページを更新します。市場レポートは、価格設定、規制、採用、流通に関するコンセプトページを更新します。新しい矛盾は無視される代わりに記録されます。有用なクエリは、将来のクエリが基盤とできる保存されたブリーフィングになります。
数週間後、システムはもはや単なるドキュメントストアではありません。研究環境です。
同じパターンはライターにも有効です。過去のエッセイ、ノート、インタビュー、保存した記事、下書きを取り込みます。Wiki は、繰り返し登場する議論、例、主張、参考文献、未完成のアイデアを追跡できます。執筆のために腰を据えるとき、あるトピックについてこれまで何を言ってきたか、どの例が最も強力か、考えがどこで変わったか、まだ探求していない角度は何かを尋ねることができます。
自己学習にも有効です。講義、読書課題、演習、論文を取り込みます。Wiki は、コースが難しくなるにつれて進化するコンセプトページを維持できます。第 7 週が第 2 週をどのように修正するかを説明できます。復習シートを生成し、弱点を特定し、混乱を学習計画に変えることができます。
チームにも有効です。会議の議事録、Slack スレッド、顧客との通話、計画書、戦略メモ、サポートチケット、事後分析を取り込みます。Wiki は、プロジェクトページ、顧客ページ、製品決定ログ、競合他社ページ、繰り返し発生するリスクテーマを維持できます。メリットは検索だけではありません。メリットは、組織がツールの隙間でコンテキストを失わなくなることです。
どのケースでも、パターンは同じです。ソースが収集され、知識がコンパイルされ、質問が出力を生み出し、有用な出力がシステムにフィードバックされます。
探求は積み重なっていきます。
ヘルスチェックこそがプロダクト
Karpathy のパターンで最も過小評価されている部分の一つが、リンティングです。
通常のノートシステムは、静かに劣化していきます。リンクが切れる。ページが重複する。要約が古くなる。主張が互いに矛盾する。重要なソースが未処理のまま残る。実際の作業でシステムが必要になり、もはや信用できなくなって初めて、その劣化に気づきます。
LLM が管理する Wiki はチェック可能です。
孤立したページを見つけるように依頼できます。重複したコンセプトを特定するように依頼できます。どの主張に引用が必要かを尋ねることができます。新しいソースが古いソースとどこで矛盾しているかを尋ねることができます。どのページが曖昧すぎるか、長すぎるか、薄すぎるか、明らかな相互参照が欠けているかを尋ねることができます。
これは小さなことに聞こえますが、ノートの山と機能する知識ベースの違いです。
ヘルスチェックは副次的な機能ではありません。それは信頼を維持するメカニズムです。
信頼できない知識ベースは、単なるアーカイブに過ぎません。自己検査し、自分の弱点を説明し、修復を提案できる知識ベースは、インフラのように感じられ始めます。
Markdown が重要な理由
控えめな Markdown の選択は、見た目以上に重要です。
Markdown ファイルはポータブルです。通常のフォルダに置くことができます。Obsidian で開いたり、任意のテキストエディタで編集したり、git でバージョン管理したり、コマンドラインツールで検索したり、Web サイトにレンダリングしたり、スライドに変換したり、スクリプトで処理したりできます。
これにより、システムがブラックボックスになるのを防ぎます。
多くの AI 製品は、あなたの知識を独自のインターフェースに吸収しようとします。それは便利かもしれませんが、同時に、あなたの理解を誰か他の人のデータベース、価格設定、ロードマップ、エクスポートボタンに依存させることになります。
ローカルの Markdown Wiki は、可能な限り最も退屈な方法で優れています。それは検査可能です。耐久性があります。バックアップできます。差分を確認できます。モデルが何を変更したかを見ることができます。悪い編集をロールバックできます。その周りに小さなツールを構築できます。
真剣な知識作業には、退屈なインフラが勝ります。
存在を欲するプロダクト
Karpathy はこれをハック的なスクリプト集として説明しましたが、それははるかに大きなプロダクトカテゴリーを指し示しています。
次の偉大な知識ツールは、おそらくアップロードボタン付きのチャットボットのようには見えないでしょう。それはむしろ、AI ネイティブな研究環境のように見えるでしょう。ローカルファーストのストレージ、構造化された取り込み、引用を認識した統合、自動メンテナンス、視覚的な出力、ヘルスチェック、バージョン履歴、そして知識ベース全体にわたって動作できるエージェンティックワークフローを備えています。
それは単に質問に答えるだけではありません。より良い質問を可能にするコンテキストを維持します。
その区別は重要です。チャットボットは反応的です。維持された知識ベースは累積的です。チャットボットは応答を返します。Wiki は、未来の自分により良い出発点を与えます。
これこそが、「セカンドブレイン」という言葉がついにそれほど気恥ずかしくなくなるかもしれない理由でもあります。長年にわたり、それはしばしば願望的なファイリングキャビネットを意味していました。未来の自分が整理してくれることを期待して物を入れる場所。しかし、本当のセカンドブレインは単に記憶を保存するだけではありません。構造を維持し、信念を更新し、繋がりを表面化させ、蓄積された思考を再利用しやすくするべきです。
これまで、それにはあまりにも多くの人間の規律が必要でした。
今や、メンテナンスは委任できるのです。
実際のワークフロー
実際のワークフローは、ほとんど残念なほどシンプルです。
生のソースを収集する。LLM にそれらを構造化された Markdown Wiki にコンパイルさせる。Obsidian または別の Markdown インターフェースを使用して結果を閲覧する。Wiki に対して質問をする。実質的な回答を Wiki に保存する。定期的にヘルスチェックを実行する。繰り返す。
重要なのは、その勢い（フライホイール）です。
すべてのソースが Wiki をより良くします。すべての良い質問がアーティファクトを生み出します。すべてのアーティファクトが将来のコンテキストになります。すべてのヘルスチェックが信頼性を向上させます。時間の経過とともに、システムはあなたが実際に研究し、書き、構築し、決定するものを反映した形を発展させます。
これは、AI に PDF を要約させるのとは大きく異なります。
それは、最終的な答えを出すことではなく、あなたの知的作業空間を首尾一貫した状態に保つことを主な仕事とするリサーチアシスタントを持つことに近いです。
それは、現在の LLM の最もレバレッジの効いた使い方の一つかもしれません。あなたの思考を置き換えるのではなく。すべてを知っているふりをするのでもなく。無限の使い捨て可能なテキストを生成するのでもなく。ただ、真剣な思考を複合的に成長させるためのメンテナンス作業を行うことです。
まとめ
古いセカンドブレインは、規律の問題を抱えたストレージシステムでした。すべてを置く場所を与えてくれましたが、それでも未来の自分が整理し、接続し、更新し、掃除することに依存していました。それが、非常に多くのノートシステムが美しい地図として始まり、静かなアーカイブとして終わる理由です。
LLM Wiki はそのモデルを反転させます。生のソースは証拠の層として残ります。Markdown Wiki はコンパイルされた層になります。スキーマは、AI にそれを維持するためのルールを与えます。ヘルスチェックはシステムの信頼性を保ちます。Obsidian または他の Markdown インターフェースは、あなたが作業を検査し、質問し、再利用する場所になります。
RAG は、書類の山から質問への答えを見つけるのに役立ちます。LLM が管理する Wiki は、将来のすべての質問の出発点を変えます。
それが核となるアイデアです。価値は、より速い要約、よりきれいなノート、またはより美しいグラフだけではありません。価値は、蓄積されたコンテキストです。すべてのソース、すべてのクエリ、すべての矛盾、すべての有用な出力が、別のチャットスレッドに消える代わりに、システムを強化することができます。
人間の役割はより狭く、より価値のあるものになります。より良い入力を選択し、より鋭い質問をし、弱い統合に挑戦し、何が重要かを決定すること。AI の役割は反復的で構造的なものになります。要約し、リンクし、改訂し、引用し、リントし、維持すること。
そうやって知識作業は複合的に成長し始めます。
あなたのセカンドブレインに必要なのは、もっとフォルダではありません。
それを維持してくれる誰かです。
そして、初めて、その誰かはあなた自身である必要はありません。
この記事が気に入ったら、AI と Obsidian に関するさらなるアドバイスのためにフォローしてください: @Degen_calls_sol
