本動画は、Andrej Karpathyが提唱したAIによるWiki構築アプローチと、構造化データベースを用いるOpenBrainアプローチの根本的な違いについて解説している。WikiアプローチはAIが情報の入力時に思考と要約を行い、継続的に進化する研究ノートを作成するのに適している一方、拡張性や複数エージェントの同時アクセスに課題を抱える。対照的に、OpenBrainアプローチは情報を構造化してそのまま保存し、検索時にAIが思考を行うため、大規模なデータやチームでの運用、精緻なクエリに強い。最終的に、OpenBrainを基盤としつつWikiの利点を享受できるハイブリッドなアーキテクチャの構築方法と、AIを単なる回答エンジンから「思考システムのメンテナ」へと昇華させるためのコンテキスト層の重要性について論じている。
KarpathyのWikiアプローチへの反響と本動画の目的
数日前にAndrej Karpathyが投稿したWikiのアイデアに、誰もが熱狂しています。4万1000人もの人がブックマークしました。そして表面上は、それは馬鹿げているほどシンプルに聞こえます。AIを使って個人のWikiを構築し、維持するというものです。
OpenBrainでいくらか似たようなものを立ち上げた者として、私は何百通ものDMやメールを受け取りました。ネイト、これは同じものですか？ ネイト、これは違うものですか？ ネイト、これでOpenBrainは時代遅れになりますか？ ネイト、Wikiの方が優れているんですか？と。私は少し立ち止まって、皆さんが予想していたのとは違う答えをお返ししたいと思います。
これから、Wikiのアプローチが何を正しく捉えているのか、なぜAndrejがそれを構築したのか、そしてOpenBrainのアプローチと比較した際のWikiアプローチの根底にある原則についてお話ししていきます。そして、私たちがなぜそれをやっているのかについて、正直にお話ししたいと思います。私たちはただのお遊びでやっているわけではありません。私たちがそれを行っているのは、自分のコンテキスト層をどう整理するかを決めることが、2026年においてできる最も重要なことの一つだからです。これは本当に非常に重要なことなのです。
そして、KarpathyのアプローチはOpenBrainとは大きく異なります。全く同じものではありません。彼がその決定を下したのには明確な理由があり、私がOpenBrainを構築するために下した決定にも明確な理由があります。そして、私はその両方について本当にオープンにお話しします。どちらか一方を無理に擁護するつもりはありませんし、一方が他方より優れていると言うつもりもありません。ですから、そういった考えは頭から追い出してください。それぞれのシステムがどこで破綻するのか、それぞれが抱えるスケールの問題、そしてそれぞれがどこに強みを持っているのかについてお話しします。
そして約束しますが、皆さんがこの問題を解決する手助けをします。なぜなら、皆さんの多くが両方のいいとこ取りをしたいと言うだろうと分かっているからです。私たちはそこに到達します。OpenBrainに、両方のいいとこ取りを助けてくれるプラグインを導入しました。これにより、OpenBrainがもたらす構造化データと共に、Karpathyが採用しているWikiのアプローチを手に入れることができます。そしてこの動画の終わりまでには、両方ができることがなぜ重要なのかを理解し、その決定を下すための知識が身についたと感じていただけるはずです。
Wikiアプローチの背景：AIの記憶喪失問題
それでは、一見しただけでは分からない、もう少し複雑な水面下の仕組みについて説明させてください。なぜなら表面上は、Karpathyの実装は非常にシンプルだからです。それは単なるフォルダとテキストファイルです。それが彼にとっての大きなアイデアなのです。なぜ彼がそこまでシンプルにしたのか、疑問に思うかもしれません。
彼の洞察は、誰もが今日、一日中AIと自分のドキュメントを使って仕事をしているという考えに基づいています。ChatGPTにファイルをアップロードし、NotebookLMを使い、Claudeを使いますよね。そして常に、あちこちに大量のドキュメントが散らばっている状態になり、そこであなたが質問をすると、AIは関連するドキュメントのチャンクを探しに行き、過去のチャットを読み、答えを出さなければなりません。すべてが至る所で極度に断片化されているのです。
これはまあまあ機能しますが、実際には理想的ではありません。なぜなら水面下で起こっているのは、あなたが質問をするたびに、AIが実質的にゼロからあなたの知識を再発見しているということだからです。したがって、もしあなたが6つの異なるチャットにまたがる5つの異なるドキュメントを関連付ける必要がある質問をした場合、AIはその5つすべてを見つけ、6つのチャットを読み、それらがどのように関連しているかを把握し、何らかの合成結果を生み出さなければなりません。明日似たような質問をしたら、また同じことを最初からやり直します。その合成については何も保存されませんでした。たとえ同じチャットアプリケーション内にいたとしても、ドキュメント間のつながりを本質的に保持することはありません。ましてや、私たちの多くがそうしているように、2つか3つの異なるAIを使っている場合はなおさらです。
言い換えれば、AIは本格的な認知作業を行った上で、それをすべて捨ててしまったのです。そしてそれこそが、Karpathyが別の解決策をまとめるほどに気になった点でした。彼が問いかけたのは、単に関連するチャンクを見つけて質問に答えるのではなく、AIが学んだことを実際に書き留めたらどうなるか、ということでした。
新しい情報源を追加するたびに、AIがその情報源を読み、何が重要かを把握し、以前の情報源から学んだすべてをすでに含んでいる整理されたノートのセットを更新したらどうなるでしょうか。言い換えれば、AI自身の合成に基づいて自動更新を開始したらどうなるか、ということです。もしそのノートにすでに相互参照が含まれており、矛盾にフラグが立てられ、あなたの理解がどのように進化したかが追跡されていたらどうでしょうか。もしあなたが、時間とともに自分がどのように考え、進化していくのかを学ぼうとしているなら、それこそがこのWikiのアイデアの目的です。それは単なる気の利いたファイル整理システムになるのではなく、実際には全体として永続的な成果物となり、あなたの思考に対するAIの進化する理解を長期的に捉えるものになります。
つまり、AIは月曜日にあなたが渡した論文を読み、学んだことを書き留め、そして先週あなたが取り組んでいた別のスレッドから学んだこととリンクさせるかもしれません。次の金曜日にあなたが質問したとき、AIはすべてをゼロから読み直す必要はありません。代わりに、すでにそこにある合成結果、すでに構築されている相互参照、フラグが立てられた矛盾に目を向けます。そしてKarpathy自身の言葉を借りれば、知識は一度コンパイルされ、その後は最新の状態に保たれます。クエリのたびに再導出されることはありません。
そしてそれこそが、ここでの真の鍵なのです。ほとんどのAI知識ツールは、再導出するために計算能力とトークンを消費しますが、彼のWikiはコンパイルを行います。これはAIとあなたの情報との間の根本的に異なる関係であり、OpenBrainを含む他の多くの主流な記憶パラダイムとは異なる強みと弱みを持っています。
彼は自身の作業環境を、片側にAIエージェント、もう片側に単なるノート閲覧アプリであるObsidianを置く構成だと説明しました。これにより、AIは会話に基づいて編集を行うことができ、彼はその結果をリアルタイムで閲覧し、リンクをたどり、グラフビューをチェックし、更新されたページを読み、エージェントと進化する会話のようなものを持つことができます。そしてもちろん、プログラマーである彼の語り口によれば、LLMはWikiのコードベースのプログラマーのようなものだということです。これを平易な言葉に直すと、ノートアプリは彼が実際に読む場所であり、収集された一連の構築済みドキュメントに基づいてノートアプリに書き込みを行うのはAIだということです。
それらのいくつかは、彼が過去のチャットから入力した生のソースです。いくつかはドキュメントです。いくつかはAIがまとめた合成結果です。こう考えてみてください。ほとんどのAIツールは、あなたが質問するたびにあなたのファイリングキャビネット全体を読み、本当に素晴らしい答えを出してくれて、そして見つけ出したすべてをすぐに忘れてしまう優秀なリサーチアシスタントを雇っているようなものです。Andrej KarpathyのWikiは、その同じアシスタントが、質問のたびにゼロから始めるのではなく、直前の質問の上に構築できるように整理され、相互参照され、更新された一連のノートを継続的に保持しているようなものです。
Wikiアプローチの利点と限界：編集と要約の落とし穴
学んだことを積み重ねていけるというこのアイデアこそが、4万1000人もの人が飛びつき、その投稿をブックマークした理由だと思います。フォルダやテキストファイル自体がワクワクするからではありません。ゼロから始めるのではなく、時間とともに理解を構築していくAIこそが、今私たち全員が渇望しているものだからです。それは誰もが待っていたものです。それが人々をOpenBrainに熱狂させた理由でもあります。
しかし、この4万1000のブックマークのうち、まだほとんど誰も考えていない落とし穴があります。AIが生のソースをWikiページに変えるたびに、AIは編集上の決定を下しているのです。正しいかもしれないし間違っているかもしれないアイデア間のつながりをどう構築するかについて、決定を下しています。しかしそれはAIの選択ですよね。人間の選択ではありません。あなたがどう思うかに関わらず、ある程度独立して合成の選択を行っているのです。
そのため、数ヶ月後には重要になるかもしれない重要なニュアンスが抜け落ちてしまう可能性があり、あなたはそれに文字通り決して気づかないでしょう。Wikiがあまりにもきれいに読めるため、何が欠けているのか分からないのです。これは、ダッシュボードやアナリティクスと同じような罠です。ダッシュボードはスプレッドシートよりもはるかに読みやすいですが、それはデータの凝縮ですよね。あなたがその瞬間に見たいとAIが判断したものだけを表示するため、あなたが本当に見るべきまさにそのものを隠してしまう可能性があります。
そして彼を称えるべき点として、Andrej Karpathyはこのことについて非常に正直でした。彼のアーキテクチャは、すべての生のソースを手つかずのまま独自のフォルダに保持します。そのため、彼はいつでもオリジナルに戻ることができ、これは非常にスマートな設計です。しかし正直なところ、彼のパターンに基づいて構築するほとんどの人は、生のソースに戻るという規律を維持しないでしょう。
現実には、このオープンソースプロジェクトが展開されるにつれて、Wikiが信頼されるものになると思います。そして真実の源泉は、静かに生の素材から、その素材のAIによる要約へとシフトしていくでしょう。それは80％の確率で、あるいは90％の確率で正しいかもしれませんが、何かを見落としたり、何かの枠組みをわずかに間違えたりした場合、問題が発生し、私たちが記憶にアプローチする唯一の方法がそれであるならば、そのエラーは私たちの理解の中に組み込まれることになります。
そして、あなたはこの動画の冒頭で私が述べたように、私たちは怠惰な人間であるという大前提があるため、それを疑う習慣を身につけることはないでしょう。ただ放り込んでおけば自動的に整理され、学習し、書かれた成果物とともに戻ってくるWikiがあるのは本当に素晴らしいことです。そしてここでOpenBrainが登場し、事態は本当に、本当に面白くなります。
OpenBrainのアプローチ：クエリ時の思考と構造化データ
コアにAIを持つすべての知識システムは、ある一つの質問に答えなければなりません。AIはいつハードな思考を行うのでしょうか。情報が入ってきたときですか、それともあなたがその情報について質問したときですか。それを選ばなければなりません。それが分岐点であり、他のすべてはそこから続きます。
KarpathyのWikiは書き込み時のシステムです。つまり、記事や論文、一連のノートのような新しい情報源が到着したとき、AIはただそれを保存するだけではありません。AIは実際にそれに対して能動的に働きます。情報源を読みます。重要なものを抽出し、その理解をWikiに書き込みます。あなたのためにトピックページを更新します。関連する要約を書いてくれます。お分かりですよね。関連するアイデア間にリンクを追加し、概念を発展させ、新しいデータが先週ファイリングされた何かと矛盾する箇所を書き留めるために、能動的に働きます。
入力時にその思考の多くを行うのです。つまり、情報がドアから入ってきた瞬間に、ハードワークが最初に1回行われます。その後は、AIにほとんど何も作業させることなくWikiを閲覧し、事前に構築された理解を得ることができます。それは単なる検索です。
OpenBrainは違います。これはクエリ時のシステムです。新しい情報が到着したとき、OpenBrainはそれを忠実に保存するように設計されています。タグ付けします。分類します。検索可能にします。しかし、私たちはあなたがまだその情報を合成する必要があるとは想定していません。誰も合成しません。誰も作業しません。データは構造化されたテーブルの中に座って待っています。
あなたやあなたのAIエージェントが質問をしたとき、その時にAIは作業を始めます。AIは関連するエントリを読みます。そのクエリの時点で、です。AIは新鮮な状態で思考を行い、その場で答えを生み出します。つまり、ハードワークはあなたが必要とする前ではなく、あなたが必要とした瞬間に起こるのです。
ですから、このように考えてみてください。KarpathyのWikiは、あなたがそのテーマを学ぶにつれて本当に優秀な家庭教師が書いてくれる学習ガイドのようなものです。あなたが新しい教材をカバーするたびに、家庭教師はあなたが途中で迷子にならないようにガイドを更新してくれます。家庭教師は新しいセクションを追加し、古いセクションを修正し、章をまたいでアイデアを結びつけ、あなたが本当に深く掘り下げるのを助けてくれるので、試験の日が来たら、あなたはただガイドを読むだけで準備万端です。
それはまさに、そのWikiが機能するはずの理想的な方法です。理想的には、思考はあなたに代わって行われています。家庭教師はすべてを完璧に準備してくれているので、あなたは失敗するはずがありません。
OpenBrainは、優秀な司書が横に立っている、完璧に整理されたファイリングキャビネットのようなものです。すべてのドキュメントがファイリングされています。インデックス化されています。検索可能です。そのため、あなたが答えを必要としたとき、司書は非常の素早く関連するファイルを取り出し、あなたのためにその関連ファイルを読み通し、そしてあなたがそのファイルの中で見つける必要があるものを正確にピンポイントで示してくれます。探しているものを教えてくれます。ファイリングは本当にきれいで手つかずの状態であり、これにより、比喩的な意味での司書は、あなたが質問するたびに非常に効率的な方法で新鮮な思考を行うことができ、あなたはまさに求めている合成結果を得ることができます。
正直に言うと、私は比較対照して分かりやすい勝者を示すためにここにいるわけではありません。学習ガイドもファイリングキャビネットも両方とも役立ちますが、それぞれ得意なことが異なるため、不正確に比較してほしくありません。そしてそれは本当に重要なことです。では、なぜこれがあなたにとって重要なのでしょうか。アーキテクチャの話抜きで考える方法は次の通りです。
もしあなたがただ物を保存するだけなら、あなたのAIはあなたが質問するたびに、それがすべて何を意味するのかを把握しなければなりません。あなたは何ヶ月も何ヶ月も何ヶ月も、記事や会議のメモ、調査結果をAIに与え続けてきました。あなたは、一連の異なる情報源を互いに結びつける必要がある質問をします。するとAIは、トークンを消費して探しに行かなければなりません。それらの情報源を見つけなければなりません。それらを理解しなければなりません。それらを読まなければなりません。それらを通じて考えなければなりません。何が起こっているのかを理解し、それらがどのように関連し合っているのかを把握しなければなりません。そして最終的に、ゼロから実際に機能する合成結果を生み出さなければなりません。そして、それを毎回、毎回やらなければならないのです。事前には何も構築されていません。
さて、ここからがもう一つの側面です。もしあなたがWikiだけを構築した場合、あなたのAIは要約を読むことはできますが、その下にある生のデータを使って正確なことを行うことはできません。前四半期の5万ドル以上のすべての取引を引き出したい。すべての会議をクライアント名でフィルタリングしたい。同時に3つの異なるAIツールに知識ベースをクエリさせたい。テキストファイルのフォルダでは、そのような複雑な質問には答えられません。合成された形で理解はそこにありますが、意味のある決定を下すための詳細な構造化データはただそこにはないのです。そして、設計上そこにないように作られています。ただそこには存在しないのです。
さらに、3つ以上のエージェントがある場合、それらがすべて同時にマークダウンファイルを書き換えようとすると、システムは単に破綻します。Wikiの構造は、一箇所で書き込みを行う単一のエージェントがあなたのために働いていることを前提としています。一方、OpenBrainの構造は、構造化データベースに貢献したり、そこから引き出したりするために、複数のポイントで複数のエージェントを接続したいと考えるかもしれないことを想定しています。
チームでの利用とスケールの壁：Wikiとデータベースの違い
構造化データの話から進んで、AIに関する別の種類の課題について話しましょう。システムの下に記憶のアーキテクチャがない場合、現在、AIが時間とともにどのように学習し改善していくのかを追跡することは困難です。そして私は、OpenBrainが設計されている詳細な事実を記憶することと、Wikiが設計されている物語や合成を記憶することの違いについてお話ししたいと思います。
そして、それがチームにとってどのように機能するのかを理解していただきたいのです。なぜなら、私たちのストレージアーキテクチャが、私たちがチームのために解き放とうとしている未来を形作っているということを理解することが非常に重要だからです。私たちは事実上、意味を理解し、使用し、情報を入力し、信じ、信頼し、意思決定のために依存する必要があるコンテキスト層を選んでいるのです。これ以上に重要なことはありません。
現在、ほとんどの組織はAIが関与した膨大な量の知識を生み出しています。私たちは会議の要約を生成しています。AIが関与した戦略文書を生成しています。リサーチ結果を生成しています。Slackのスレッドを生成しています。そしてそのほぼすべてが、一度書かれたら二度と読まれません。誰もそれを維持していないからです。誰もそれらのドキュメントを横断して合成していません。第2四半期の戦略資料が、先週の全体会議でCEOが言ったことと矛盾していることに誰もフラグを立てていません。
今、あなたの会社のAIが生成した知識は、複利で増える資産になっているか、あるいはただ増大し続けるノイズの山のどちらかです。ですから、ここでの2つの記憶構造の選択は、単なるデザインの決定以上のものです。実際には、製品の意思決定における北極星のコンパスがどれだけ信頼できるものになるかを決定する、ほとんどのチームが偶然に下してしまっている選択なのです。
そしてここで重要になる微妙なニュアンスは、知識ベースの中で矛盾が最も価値のあるものになる場合があるということです。そしてあなたが懸念することの一つは、良い意思決定を下すために必要な区別を、Wikiフォーマットでは失ってしまうのではないかということです。
例えば、エンジニアリングチームはビルドのタイムラインを12週間だと考えているのに対し、営業チームはクライアントに8週間と約束したとします。スマートなWikiのようなものは、根本的なズレがあるというフラグを立てるのではなく、その矛盾を一つの首尾一貫した物語に解決してしまうかもしれません。しかしそれは、10週間という見積もりで全体を合成してほしくないような、システムにおける戦略的なシグナルなのです。エンジニアリングが知っていることと営業が約束したことのギャップこそ、まさにあなたの経営陣がその状況で見る必要がある問題なのです。
解決せずに両方の見解を保存するデータベースは、その緊張感を維持しますが、善意のWikiはそれらをすべてスムーズにならし、消し去ってしまうかもしれません。
AIの役割の違い：ライターとしてのWiki、リーダーとしてのOpenBrain
これらがいくつかの構造的な違いです。しかし、これら2つの記憶システム、OpenBrainシステムとWikiシステムの構造的な違いを超えて、それぞれのシステムでAIが行う仕事と、AIの職務記述書を明確に定義することがなぜ重要なのかについて少しお話ししたいと思います。
これらのアプローチの最も鋭い実用的な違いの一つは、AIが何に時間を費やすかということです。そして、あなたは自分のAIのどこに投資したいのかを決める必要があります。Karpathyのシステムでは、AIは主にライターです。仕事はドキュメントを維持することです。新しいソースを追加したとき、それに対して書き込みをしなければなりませんよね。生の素材を読み、合成し、それについてどう考えるかを書かなければなりません。Wikiページを更新し、新しいリンクをつなぎ、意味を理解し、概念の解説を追加し、相互参照を行い、インデックスを作成します。やるべきことが山ほどあります。
事実上、AIは編集作業を行っています。何が重要か、何が何とつながっているか、そしてそれらの矛盾がどこにあるのかについて、判断を下しているのです。一方、OpenBrainでは、AIを主にリーダーと考えています。その仕事は構造化データから引き出して質問に答えることであり、あなたやエージェントが何かを尋ねたとき、AIは慎重に読み取られ、慎重に整理されたデータベースをただ検索し、関連するエントリを読み、利用可能なすべてのデータに基づいて正確で新鮮な合成結果を返します。
つまり実質的に、AIはその場で分析作業を行っているのですが、すべての詳細がデータベース内ですぐに利用できるため、より詳細な結果を生み出すことができるのです。
ですから、それらの異なる職務記述書には現実的な結果が伴います。AIがライターである場合、新しい情報が入ってきたときに、あなたはAIと集中的にやり取りをします。それはあなたがやりたい仕事ですか。新しい情報が入ってきたときに、AIとたくさんやり取りしたいですか。たった一つの研究論文を追加することで、10のWikiページにまたがる更新が引き起こされます。そしてそれは、あなたが考えを巡らせ、つながりを見つけ出す中で、快適に行えることでしょうか。
それはフロントエンドでのやや重い操作ですが、その後は、すべての思考がそのWikiに捉えられているため、非常に低コストで答えを得ることができます。思考はすでに完了しているのです。
AIがOpenBrainのようにリーダーに近い場合、あなたが得られるのは、新しい情報の追加が怠惰で安上がりになるということです。私が怠け者で、自分のデータを可能な限り安く簡単に自動分類したかったので、私はそうしました。私たちはただ行を書き、タグ付けし、それで終わりです。
重い操作は、あなたが質問をするときです。なぜなら、AIは毎回データから理解を再構築しなければならないからです。単純な検索は高速にできますが、複雑な検索は、AIが実際に生のデータを尋問し、深い合成を行うため、時間がかかります。もしあなたが似たような質問をすれば、そのコストは毎回発生します。しかしその反面、現場に入り込んで何が起こっているのかを本当に理解する必要がある場合、詳細を失うことはありません。
これらのアプローチの違いは、私たちのほとんどがまだ問いかけていない一つの疑問を提起します。ここで重要視されているのは誰の理解なのか、ということです。あなたのAIがWikiを維持しているとき、あなたが事実上言っているのは、同僚がトピックについて尋ねてきたとき、あなたはWikiをチェックし、答える前にAIが言うことを信頼する意思があるということです。そしてあなたは、あなたの理解やあなたの思考、あるいはあなたが与えた記事に対するAIの捉え方が、あなた自身のものとして同僚と共有するのに十分なレベルであると信頼しているのです。
一方、OpenBrainスタイルのデータベースを持っている場合、出所は非常に明確です。これらは、タイムスタンプ付きの特定されたソースからの事実です。あらゆる主張をその出所までさかのぼって追跡することができます。あなたが知っていることは、あなたが知っていることであり、なぜそれを知っているのかも分かります。そしてあなたは、かなりの権威を持ってこう言って戻ってくることができます。私はただAIの情報を合成する能力を信頼しているだけではありません。私は実際に、これが私が得た生の素材だと言っているのです。これが私がこれに基づいている事実であり、これは過去数ヶ月、あるいは過去数週間、あるいはあなたにとってそれがどれくらいの期間であれ、私が集めたすべてのデータ全体に対するクエリに基づいた、熟慮された意見なのですと。
それはより深く、より結果に直結する種類の信頼です。それはまた、あなたのWikiをどのように整理するかを指示するAIへの命令文が、システム全体の中で最もレバレッジの高いドキュメントになるということも意味します。もしあなたがWikiを構築しているなら、このことを少し考えてみてください。もしあなたがWikiを構築しているなら、あなたは基本的に一つのマークダウンファイルの中で、あなたにとって極めて有用で、極めて正確な方法で整理し、合成するようAIに指示しているのです。そしてあなたは、AIがそれを正しくやってくれることに自分のキャリアを賭けているか、あるいはすべての入力データに時間を投資して、それが正しいことを確認し、二重チェックを行うことになるでしょう。
ほとんどの人はその投資を怠り、結果としてWikiは本来あるべき姿よりも悪いものになるでしょう。それが良くならないからではなく、私たちが怠惰だからです。
双方の弱点とその克服
もしそれぞれのアプローチが得意とすることや、どこに利点があるかについて話すなら、KarpathyのWikiが勝つのは、あなたがディープなリサーチモードにいるとき、数週間にわたってあるトピックについて10本の論文を読んでいるときだと言えるでしょう。これはAndrejがやっていることにとてもよく似ていますよね。まるで彼のために書かれたかのようです。見て分かりますよね。そしてそれぞれが前に積み重なっていくかもしれませんし、前のものと矛盾するかもしれません。それは考える人のためのツールなのです。
そういった状況では、Wikiのアプローチが劇的に優れています。なぜなら5本目の論文の時点で、あなたはまだそれと格闘し続けているからです。あなたは読み続けています。入力を与え続けています。Wikiには最初の4本の合成が含まれています。あなたはすべての一次資料を読んでいます。あなたの頭の中にもそれらが入っています。そして5本目の論文がその既存の全体像に統合され、あなたの思考をさらに進化させるのを助けてくれます。取り込んだ瞬間に矛盾にフラグが立てられ、すぐにそれを見ることができます。相互参照は自動的に構築されます。これは基本的に学術研究者の夢です。ですから10本目の論文の時点では、あなたは非常に難しい主題に対するあなたの現在の理解の状態を表す、ナビゲート可能で本当に豊かな成果物を手にしていることになります。
それは言ってみれば、ステロイドを打ったNotebookLMのようなものです。単なるファイルの現在の状態ではありません。数ヶ月にわたって個人の知識が進化し、実際にそれが成長していくのを見ることができるから勝つのです。ですから、数ヶ月にわたる自分の健康について考えている場合や、自己啓発について、あるいは競合分析など、単一の情報源そのものではなく、情報源間のつながりに価値があるような分野では、Karpathyのアプローチが勝つでしょう。なぜなら、複雑な合成問題を理解する上で、それがどれほど役立つかに本当に着目しているからです。
しかし、OpenBrainが勝つのは、知識ベース全体にまたがる正確で構造化された操作が必要な場合です。もしあなたが第1四半期から、価格設定が議論されたすべての会議のメモを見せてと頼みたいなら、それはOpenBrainタイプの質問です。最も最近の3つの競合のアップデートを引き出して比較したいなら、それはOpenBrainの質問です。あるいは、過去2週間に自分に割り当てられた実行可能なすべてのアクションアイテムを見つける、これもOpenBrainです。
繰り返しになりますが、これらはデータベースクエリですよね。あなたは特定の事実を深く掘り下げています。それらは正確でフィルタリング可能な結果を返します。テキストファイルのフォルダでも、いくつかのキーワード検索である程度似たようなことはできますが、完璧にはなりません。見落としがあるでしょうし、すぐに破綻しますし、何よりそれはあのWikiシステム全体が設計された目的ではありません。複数のフィルタを組み合わせたり、日付で並べ替えたり、何百ものエントリを横断して作業する必要がある場合は特にそうです。
OpenBrainはまた、マルチエージェントアクセスでも勝ちます。Claude CodeとChatGPT、Cursor、スケジュールされた自動化がすべて同時に同じデータソースに対して作業し、すべてが同時に同じ知識ストアに読み書きする必要がある場合です。まあ、そのような状況では、同時に複数のエージェントが同じページを編集して完全な混乱を引き起こすファイルのディレクトリではなく、同時アクセスを処理できるデータベースが必要です。
そしてOpenBrainは容量の面でも勝ちます。OpenBrainは、検索、メタデータ、リレーショナルクエリを使って、何十ものカテゴリにまたがる何千ものエントリを処理できます。そしてKarpathyもこのことを完全に認めています。それは約100から1万のシグナル性の高いドキュメントで最もよく機能します。それは企業レベルの記憶ではありません。そして企業がこれを会社レベルのコンテキスト層に使うべきだと言っているのを耳にしますが、それは機能しません。上限である1万ドキュメントに達すると、管理可能な状態を維持するだけで追加の検索ツールが必要になります。
ですから、何千もの連絡先やトランザクション、イベント、タスク、そしてその上にドキュメントを扱う場合、構造化されたストレージがスケールする唯一の正気な選択肢なのです。
しかし公平を期すために、両方のシステムがどこで破綻するかも見ておくべきです。すべてのシステムには、破綻し始める負荷があります。ただ、異なる形で破綻する傾向があるだけです。私がすでに指摘したように、Wikiのアプローチはスケールで破綻する傾向があります。チームでそれを使用しており、そのWiki構造に複数の方向からアクセスし始めると、Wikiはどう自動最適化すればいいか分からなくなります。
もし人物Aが人物Bとは異なる形で進化する理解を持っていたり、エージェントAとエージェントBが全く異なるアプローチを持っていて、同じWikiページを更新しようとしたりした場合。一つには、競合が発生し、それは問題になります。しかし二つ目には、Wikiは深い個人の理解を反映していない、これらの異なるアプローチの奇妙な統合のように見えてしまうでしょう。
根本的に、あなたがWikiと共に進化させている意味論的な理解は、彼が研究者であり、問題について深く考えており、それが彼のためのものであり、エージェントとの彼の進化する理解であるという、Andrejの世界のような世界のために設計されています。ですから、単独の実務者にとっては、ここで問題は発生しません。しかしチームにとっては、これは本当に深刻な問題になります。
もしあなたの知識が毎日変化するなら。もしあなたがプロジェクトのステータス、競争上のポジショニング、ライブの案件フローを抱えるオペレーションであるなら。情報が入ってくるたびにWikiを再合成するコストは、非常に痛烈なものになります。なぜなら、一つの変更が制御できない形で複数のページに波及する可能性があるからです。そしてそうなるべきではありません。それはただ行にあるもう一つのデータポイントであるべきです。
ですから、Wikiシステムは論文や記事のスピードに最適化されていると考えてください。Slackメッセージやチケットの更新スピードではありません。そして私が最も心配しているのは、人々が特定の知識システムが特定のビジネススピードで機能するように設計されているということを認識していないことです。もしそのように考えなければ、間違ったものを実装してしまうかもしれません。
放置されたデータベースには隙間がありますが、古い事実は依然として真実です。Wikiとは対照的です。放置されたWikiは漂流する傾向があります。新しい情報が統合されないため、古い合成はますます間違ったものになりますが、それでもよく書かれた散文から来る自信に満ちた文章として読めてしまうからです。
そのため、データベースの陳腐化は無知のように見えます。何かを見落としているようだ、OpenBrainに入れるのを忘れた、というように見えます。しかし、Wikiの陳腐化は違って見えます。それは実際に能動的な誤情報のように見えます。なぜなら、ページは自分が何について話しているのかを知っているかのように読めるため、自分が間違っていることに気づかないからです。それがそのシステム全体の目的だからです。物事を合成し、自信に満ちた散文を書き、あなたが状況を理解するのを助けるためのものです。そのため、あなたには見えないギャップを疑うことがないかもしれません。
さて、OpenBrainのスケールにおけるブレークポイントのいくつかに触れてみましょう。ちなみに、はい、私はこれらの修正プログラムを公開する予定です。AIを使えば物事はそういうふうに進むからです。私たちは時間とともに物事を良くしていきます。
過去において、OpenBrainは深い合成の品質に関して本当に亀裂が入っていました。もしあなたが同時に15の異なる事実を合成しようとした場合、AIはそれを実行できますが、過去にそれをうまく行うためのマップを持たないため、わずかに予測不可能な方法で実行する傾向があります。基本的には、毎回ゼロからデータベースの棚を検索しているのです。AIが優れているため、答えは通常良いものですが、最初から意図的にすべてを統合する時間があった事前構築済みの合成ほど良くなることは稀です。そしてそれは私たちが取り組んでいる課題です。
ブラウズ可能性は、ここで考えられるもう一つの領域です。OpenBrainは意図的にヘッドレスになっています。開いて中を歩き回るような成果物はありません。そして私がそのように構築したのは、あなたがどのようにアクセスしたいかを決定する柔軟性を与えるためです。
素晴らしいのは、その上に適切な頭を構築するのが非常に、非常に簡単だということです。OpenBrainにObsidianを追加した人もいます。そのためのプラグインはすでに存在します。ですから、もしあなたがデータベースをブラウズできないのがどうしても嫌だと思っているなら、あなたは完全に正しいです。お好みのプラグインを選んでください。そうすればブラウズできます。それがObsidianであれ何であれ。
Wikiにおいて私たちが改善するために構築しているもう一つのものがあります。最初のマークダウンファイルに矛盾を探せと意図的に記載している限り、新しい情報が入ってきたときに矛盾が表面化します。なぜなら、AIはあなたのプロンプトに従って既存のページに対して能動的に統合を行っているからです。しかしデータベース環境では、その矛盾を明らかにするためにあなたが特別な質問をしない限り、矛盾はただ隣接する行に静かに座っているだけかもしれません。
私はそれを助けるプラグインを構築しています。もしあなたが基本的にデータセット内の矛盾をチェックする監査を実行することに興味があるなら、OpenBrainを矛盾表面化ツールとして使用するのを助けるプラグインを立ち上げます。これを使えば、チームや組織のデータセット内の矛盾のマップを実際に構築し、理解することが非常に、非常に簡単になります。なぜなら生の素材を見通して、すぐにそれを見つけることができるからです。
はい、データベースは事実を保存します。デフォルトでは矛盾を認識しませんが、AIの時代において、OpenBrainのようなものを拡張し、それらの矛盾を認識できるようにすることは比較的簡単です。それが私のやったことです。
共通の原則：コンテキスト層の所有権と人間の役割
そして、違いについて多くの時間を費やして話してきましたが、私が指摘したいことの一つは、これらのシステムが共有する多くの共通原則があるということです。実装の詳細については意見が分かれるかもしれませんが、AIやデータに関する基礎となるテーゼや原則の多くについて、彼らは意見が一致しています。
彼らは、あなたが所有するのはツールではなく成果物であるということに同意しています。Karpathyのファイルは、あなたが管理するフォルダ内のテキストです。OpenBrainのデータは、あなたが所有するデータベースの中にあります。同じ原則です。どちらのシステムも、あなたを価格改定したりロックインしたりする可能性のあるプラットフォームにあなたの知識を渡すことはありません。Karpathyはこれをアプリよりファイルと呼んでいます。私はこれをSaaSの仲介者なしで構築すると呼んできました。非常に似た考え方です。根本的には同じ信念です。AIの時代において、私たちは自身のコンテキスト層を所有するべきなのです。私たちのコンテキスト層を所有するためだけにお金を払っているような誰かが存在するべきではありません。
また、どちらのシステムでも、人間の仕事はキュレーションと質問です。私たちはどの情報源を入れるかを尋ねなければなりません。私たちはどんな質問をするかを考え出さなければなりません。人間は両方のケースで大きな役割を保持しています。個人のコンテキスト層をどう整理するかについて慎重に考えることの代わりになるものはありません。
そしてはい、AIにはたくさんの仕事があります。OpenBrainに入れた事実を理解しなければなりません。Wikiの側では効果的に合成できなければなりません。事実上、これは似たような分業なのです。単にその作業のタイミングが異なるだけです。KarpathyのWikiアプローチではそのすべてを前もって行い、OpenBrainアプローチではあなたが質問したクエリ時にそのすべてを行うからです。
どちらのケースでも、記憶はランダムな蓄積を通じてではなく、意図的な構造を通じて複利で増えていきます。唯一の違いは、その構造がどのように配置され、どこに存在するかです。KarpathyのケースではWikiの中に存在するかもしれませんし、OpenBrainのケースではSQLデータベースの中に存在します。しかしどちらのケースでも、構造はある種のつながりが発生することを可能にするために意図的に枠組み化されています。
ですから、ドキュメント間のつながりを必要とするかもしれないWikiの作業にとっては、それは非常に理にかなっていますよね。すべてのドキュメントがそこにあることを望みます。AIにそれを通して考えてほしいのです。そしてそれは意図的な構造です。一方OpenBrainにとっての意図的な構造は、スケールできると分かっているSQLデータベースであり、運用上の事実を保持し、推論を行い、初日から監査に対応できる結果を得られるようなきちんとした場所にあることを確認するように設計されています。
両方のシステムとも、知識ベースの主なユーザーはブラウザで読んでいるあなたではなく、あなたに代わって働くAIエージェントであると想定しています。そしてますます、それがこれらすべての記憶システムの前提になっていくと思います。人間が読めることはボーナスです。エージェントがアクセスできることが、実際の要件なのです。
究極の解決策：OpenBrainとWikiのハイブリッド
さて、私が構築したものに話を移しましょう。正直に言って、私たちは両方のアプローチの強みを与えてくれる成熟したシステムを求めているからです。どちらか一つだけではありません。ですから、私が組み立てて提案している特定のアーキテクチャは、次の主要なOpenBrainの拡張機能です。
OpenBrainは永続的なストアとして維持したいですよね。それは変えないでください。事実を保存するのに最適な場所です。すべてがそこに入ります。それは素晴らしいことです。すべての会議のメモ、すべての記事のクリップ、すべての調査結果、すべてのタスク、すべての連絡先、すべてがタグ付けされます。すべてが検索可能です。すべてがクエリ可能です。それは理にかなっています。それがあなたの耐久性のある記憶層なのです。それは大量のボリュームを処理できます。正確なクエリを処理できます。あなたの人生の複数の領域にまたがって思い出すことができます。真実の源泉となることができます。
そしてWiki層は、オンデマンドでコンパイルされたビューとして機能することができます。そこで私は、コンパイルエージェントが毎日、毎週、あるいはオンデマンドのスケジュールで実行できる新しいプロセス、新しいプラグインを立ち上げます。そのエージェントはOpenBrainの構造化データから読み取ることができます。
実質的に、それはOpenBrainグラフになります。エントリ間で合成を行うことができます。オンデマンドでWikiページを作成できます。トピックの要約を作成できます。これらはすべて、知識ベースのグラフを形成すれば、OpenBrainのSQLデータベースから来る堅牢性と事実性を保ちながら、Wikiアプローチの利点を得ることができるというアイデアによって推進されています。
ですから、これらのページはあなたのために生成された成果物にすることができます。あなたのファイルにあるすべてのものを読み、あなたがブラウズできるものに蒸留して、本当に優秀なチーフ・オブ・スタッフが書いてくれる毎日のブリーフィングのようなものだと考えてください。
グラフアプローチにより、相互参照、関連トピックのリンク、矛盾のフラグ付け、進化する合成の維持といったKarpathyの合成パターンに従うことができますが、それは生のファイルではなく構造化データから機能します。そしてそれは、合成の前にエントリを日付やカテゴリでフィルタリングするなど、Karpathyの入力処理ではできないことができることを意味します。信頼度によって重み付けをすることができます。時代遅れのアイテムを除外することができます。言い換えれば、基になるデータがより詳細であるため、合成はより豊かなものになります。
Wikiページは読みやすい層であり、Obsidianやノートアプリで閲覧することができますが、それらはすべて、あなたの構造化データの上に存在する、事前構築されたコンテキストグラフを原動力としています。あなたの構造化データなしでは存在しないものです。
これらは、あなたがそのトピックについてアクティブに取り組んでいるときのホットな参照用になります。そして構造化データは、Karpathyが自分のWikiの生の素材を見たいときに使用する生のファイルのようなものになります。しかし生のファイルとは異なり、これらは簡単にクエリ可能であり、SQLデータベースに整理されています。そのため、生のファイルでは不可能な方法でスケールすることができます。同じようにOpenBrainで1万ファイルの制限に引っかかることはありません。
ですから、データベースは依然として唯一の真実の源泉です。新しい情報は常にコアとなるSQLのOpenBrainに最初に入ります。Wikiが直接編集されることは決してありません。そしてこれにより、Karpathyの投稿の何人かのコメンテーターが指摘したエラー複利問題を防ぐことができます。
もしAIが少し間違ったことをWikiに書き込み、それがそこに留まれば、次の答えはその間違ったものの上に構築され、漂流が始まり、エラーが蓄積し始めます。一方、私がOpenBrainで提案しているハイブリッドモデルでは、データベースが常に権威を持っています。Wikiはそのデータベースから構築されたグラフから生成されます。
ですから、もしWikiにエラーがあれば、ソースデータを修正し、再生成すればいいのです。真実の源泉としてWikiに依存しているわけではありません。WikiはSQLデータベース内の地上の現実から常に再構築されるため、決して現実から漂流することはありません。
OpenBrainの用語で言えば、これはレシピのようなものです。データベースから読み取り、グラフに基づいて出力を生成する、構成可能なワークフローです。Wikiコンパイラレシピは関連するテーブルにクエリを実行し、AIを通じてページを合成し、実質的に関係のネットワークを構築し、その出力をWikiディレクトリに書き込むことができます。
そしてもし疑問に思っているなら、はい、これは自動化されたスケジュールで実行できます。基になるデータが、もしあなたがコミットしていれば、前回から成長しているはずですので、サイクルのたびにより良くなることができます。あなたがデータを入力するのが得意である限り、それは複利のループになります。
そして最終的にあなたが得るのは、構造化されたストレージとエージェントアクセスのためのOpenBrainと、コンパイルされた理解と人間による閲覧可能性のためのKarpathyスタイルのWikiを重ねたものです。データベースがWikiを養い、Wikiが決してデータベースと矛盾することはありません。
正確な事実であれ、合成された物語であれ、必要なものに応じてどちらかにクエリを実行することができ、解決しようとしている問題の種類に応じてどちらに進むかを決定することができます。
どちらを選ぶべきか：ユースケース別の推奨
本当に、本当に率直に言って、どちらを構築すべきかという質問をされると分かっているのでお答えします。もしあなたが単一の調査トピックを深く掘り下げていて、個人のユーザーであり、正確なクエリを必要とせず、マルチエージェントアクセスを必要とせず、読みながらブラウズしながら考えたいと思っていて、インフラ構築なしで30分で動くものを求めているなら。
そのような状況であれば、KarpathyがGitHubに投稿したWikiをそのまま使うのが絶対に理にかなっています。なぜならAIがあなたのためにシステム全体を構築してくれますし、それはまさにそのような個人でのユースケースのために設計されているからです。
しかし、複数のAIツールが同じ記憶にアクセスする必要があるなら、OpenBrainで構築すべきです。チームがこの情報を扱うことを想定している場合、多くのカテゴリにわたって大量の情報をキャプチャしている場合、その情報が必ずしも物語ベースではなく数値ベースである場合、構造化されたクエリが必要な場合、これに基づいて自動化されたエージェントワークフローを構築している場合、単一のプロジェクトのためだけでなく、長期間持続しスケールする必要のあるインフラストラクチャとしてこれを考えている場合です。
ある意味、Wikiが感じさせるものの多くは、より優れた、よりクールなバージョンのNotebookLMです。それは素晴らしいツールですが、チーム全体で使えるツールではありません。ですから、現時点で私は両方を手に入れようと言う傾向があります。OpenBrainを稼働させ、もしブラウズ可能で事前合成された理解層が欲しいなら、グラフプラグインを取得して、その上に追加するだけです。そうすれば、一方が他方を置き換えることはなく、両方の利点を得ることができます。
これまでの話のどれも、Andrej Karpathyが構築したものについて彼が間違っていると言っているわけではありません。彼は彼自身と、似たような立場にいる他の研究者のために、驚異的なツールを構築しました。
まとめ：思考システムのメンテナとしてのAI
そして、最終的にどちらのシステムを選ぶかに関わらず、Karpathyの投稿からすぐに採用する価値のあるアイデアが2つあります。出版フォーマットとしてのアイデアファイルという考え方がその一つです。そしてそれは本当にシンプルです。それは彼がシェアした方法です。アイデアファイルは彼の出版フォーマットです。Karpathyはツールを出荷したのではありません。彼は、あなたと一緒に詳細を構築してくれるAIエージェントに貼り付けるように設計された、アイデアの高レベルな説明を公開したのです。
これこそ、私がYouTubeのトランスクリプトを取ってAIに食べさせるようにと言ったときに、私が言ってきたことです。これは技術的な知識を共有するための純粋に新しい方法です。AIが実行するための素晴らしい設計図です。そして、人間が従わなければならない網羅的なステップバイステップを与えるよりもはるかにシンプルであるため、今後さらにこれを目にするようになると思います。
それは最終的に読者の主体性を尊重することになります。なぜなら、彼らはそのアイデアについて独自の解説を加えることができ、証明された開始パターンを与えられながら、彼らとエージェントが一緒になって詳細を決定できるからです。そしてはい、もし疑問に思っているなら、私たちがこの動画を一緒に進めてきたように、あなたはこのYouTube動画のトランスクリプトを絶対に受け取り、あなた自身のメモリプロジェクトを始めることができます。ただあなたのエージェントに接続して、進めてください。
しかしここでの最も深い洞察は、KarpathyがAIをオラクルからメンテナへと移行させているということです。AIが果たす役割が変わり始めています。私たちのほとんどは、AIを質問をする対象として扱ってきました。一方、KarpathyはAIを時間とともにより良くなる知識の成果物を維持するという継続的な仕事を持つものとして正しく扱っています。
AIは、雲の上から魔法のような絵に描いた餅の一回限りの答えを出すためにここにいるわけではありません。複利で増える持続的な作業を構築するためにここにいるのです。そして私たち全員が直面している問題は、これがそのメンテナンスの役割のための正しいインターフェースなのかどうか、ということです。その底流には、回答エンジンのマインドセットから、AIがあなたが意図的に考え、より良い仕事をするのを可能にする思考システムのメンテナであるというマインドセットへの移行についての深い洞察があるという事実を見失いたくありません。
それは深い洞察だと思います。なぜなら、それによって私たちはキュレーションし、考え、選択し、探求する存在になることができ、AIは私たちをサポートすることができるからです。私たちが正しい質問をするとき、AIは多くの単純作業をこなすことで私たちを助けてくれます。そもそも私たちが望んでいたのはそういうことではないでしょうか。AIの夢の世界における分業は、AIがより多くの単純作業を行い、人間の判断が重要になることだったのではないでしょうか。それが夢です。
Andrej Karpathyが説明しているのは、そこへ到達するための一つの方法です。特にあなたが深い個人のリサーチプロジェクトに取り組んでいる場合には。そしてOpenBrainは、同じことをするための別の方法を説明しています。ただ、よりスケーラブルな構造化データに焦点を当てているだけです。
そしてはい、私たちは両方のいいとこ取りをすることができます。なぜなら、OpenBrainの上にグラフを構築できるからです。これこそまさに、私がそれを拡張可能に構築した理由です。2026年にはメモリに関してもっと多くのものが出てくるだろうと分かっていましたし、その上に構築できる基盤を作りたかったのです。そして今、私たちはここにいます。これが最初の大きなテストであり、私たちはこのWikiアプローチの最高の部分と、OpenBrainが提供する構造化データの最高の部分の両方を持てるものを、その上に構築することができるのです。
最終的に、KarpathyのWikiから私たちが学ぶべき教訓は、私たちがエージェントの効果的な構築者となり、2026年後半から2027年にかけてのAIとの効果的なパートナーとなるためには、記憶やコンテキスト層をどのように機能させたいかについて考える人になる必要があるということです。
私が説明していることのどれ一つとして、その思考を行うことから私たちを免除するものではありません。実際にはその逆です。私がこの動画で時間を割いて皆さんにお伝えしてきたのは、自分の知識をどのように構築したいかについて、本当に明確な区別と明確な決定を下すことの代わりになるものは何もないということです。
それがラップトップを持っている部屋にいるあなた一人だけであり、あなたの個人的な知識ベースであるか、あるいはあなたのチームのためであるか、あるいはあなたの組織のためであるかに関わらずです。1万以上の成果物を超えて、構造化データに対してクエリを実行し、信頼できる結果を得る必要があると分かっているから、構造化データが欲しいと言うのはあなた次第です。
あるいは、両方のいいとこ取りがしたい。複数のエージェントでクエリを実行し、同時に3つの異なるレポートの構造化された結果を取得したいものもある。しかしその上に、素材間のつながりについて考えさせてくれるグラフデータベースが欲しい。構造化データだけをクエリしているだけでは少し難しかっただろうと言うのもあなた次第です。
それはあなた次第なのです。私ではありません。私たちは皆、これと格闘しなければなりません。そしてもしあなたが組織でこれを考えているエンジニアであったり、プロダクトマネージャーであったりするなら、そのレベルの思慮深さに代わるものはありません。申し訳ありませんが、あなたは考えなければならないのです。
この動画が、その決定を明確に下すためのツールを提供できたことを願っています。
コメント