エージェントの性能差を生むのはモデルではなくチームメモリだ

2026年4月、同じ週に二つの話題が大きく広がりました。

Andrej KarpathyはObsidianでLLM向け知識ベースを作る方法を共有し、その投稿は急速に広まりました。同じ時期にStripe Minionsも、エージェントが週1,300件を超えるPRを書いてマージしていることで注目を集め続けました。

一見すると別の話に見えます。ですが実際には、同じ真実を指しています。

エージェントの性能を決めるのはモデルではなくコンテキストです。

Karpathyが示したこと: 知識は構造化されなければならない

Karpathyの仕組みはシンプルです。 raw/ に元データを入れ、LLMがそれをwikiのようにコンパイルします。ベクタDBもありません。複雑なRAGパイプラインもありません。 Markdownとgrepで十分だという発想です。

中心にある比喩は明快です。 ObsidianはIDE、LLMはプログラマ、wikiはコードベースです。

これが機能するのは、LLMが単に知識を検索するのではなく、自らその知識を構造化しているからです。部屋の配置を自分で整理しているので、家の構造を理解しやすいのです。

ただし限界もはっきりしています。

一人用です。AさんのwikiとBさんのwikiは自然にはつながりません。
単位がファイルです。文書の一部の洞察だけをきれいに取り出すのは難しくなります。
共有しにくいです。Markdown vaultをGitでマージしても、それは知識インフラというよりファイル同期です。
エージェント間で構造を共有できません。あるエージェントの私的wikiは、別のエージェントが問い合わせできるプロトコルではありません。

Karpathyのやり方は、個人の思考を深めるには非常に強力な道具です。ですが実際の仕事の多くはチームで進みます。

Stripe Minionsが証明したこと: コンテキストはインフラである

Stripe Minionsは同じ原理を別の角度から示しています。

Minionsが週1,300件以上のPRを生み出せる理由は、単にモデルが優れているからではありません。 Stripeが長年かけて築いた組織インフラがあるからです。 devbox、500を超える内部ツール、300万件のテスト、Blueprintアーキテクチャが、どれもエージェントに「Stripeらしく書くための文脈」を与えています。

ByteByteGoの分析も核心を突いていました。 AIコーディングツールは速く有能でも、本質的にはコンテキストに盲目です。

エージェントが高性能でも、次を知らなければ結果は不安定になります。

なぜチームがこのアーキテクチャを選んだのか
このコードパターンにどんな歴史的意味があるのか
特定の用語がこの組織で何を意味するのか

Stripeはこの問題を何年ものエンジニアリング投資で解きました。大半のチームにはそれができません。

普通のチームに本当に必要なもの

この二つを並べて見ると、必要な条件がはっきりします。

観点	Karpathy (Obsidian)	Stripe (Minions)	チームに必要なもの
知識の構造化	LLMがwikiをコンパイル	内部ツール + Blueprint	自動構造化
エージェントからのアクセス	ローカルファイル中心	内部インフラ連携	プロトコルレベルのアクセス
チーム共有	単独利用	組織全体	共有知識空間
構築コスト	低い	非常に高い	現実的なコスト
単位	文書	コードベース	Atom

要点は単純です。

エージェントにはチームの文脈を与えるインフラが必要です。ですがほとんどのチームは、Stripeのように何年もかけてそれを作れません。

NorfolkとNexusが埋めようとしているのは、まさにこのギャップです。

Norfolk + Nexus: チームに記憶を与えるインフラ

Norfolk: チーム知識が蓄積される場所

Norfolkは個人向け知識ツールとして始まりましたが、本質はもっと広いところにあります。エージェントが使える形に知識を構造化することです。

raw/ -> wiki というKarpathyの流れに似ていますが、重要な違いがあります。

1. Atom単位

Karpathyの仕組みが文書単位だとすれば、Norfolkは知識をAtomまで分解します。 Atomは検索、組み合わせ、相互参照ができる最小単位です。

エージェントにとって、文書全体ではなく特定の洞察だけを直接参照できるかどうかは大きな違いです。

2. Citation Graph

Norfolkは、どのAtomがどの結論を支えているかを追跡します。つまり出典や根拠は後付けではなく、構造の一部として扱われます。

3. Team Space

Norfolkのチームプランでは、複数メンバーのAtomが共有空間に蓄積されます。個人知識とチーム知識は分けられたまま、権限に応じてエージェントがチーム知識をrecallできます。

Norfolkのプラン構成は次の通りです。

Free: テキストとURLの収集と構造化
Paid: 画像、音声、PDFまでAtom化
Team: チーム共有知識空間の運用

Nexus: エージェントが記憶を読み書きするプロトコル層

Nexusは、Norfolkに蓄積された知識を実際のエージェントが使えるようにするレイヤーです。

AMCP、つまりAgent Memory Continuity Protocolによって、Claude Codeでもカスタムエージェントでも別ランタイムでも、チームメモリをrecallできます。 MCPがツールを与え、A2Aが協業を与えるなら、AMCPはエージェントに記憶を与えます。

Nexusのプラン構成は次の通りです。

Free Local: 埋め込み依存なしのローカルメモリ基盤
Pro Cloud: クラウド同期と高度なrecall
Team: エージェント同士で共有するチームメモリ

チームプランで可能になること

シナリオ1: 新しいエンジニアの初日

新しいエンジニアがClaude Codeを開いて、「私たちのAPI設計原則は何ですか」と尋ねます。

NexusはNorfolkのチーム空間から関連Atomをrecallします。エージェントはすぐに次のような文脈を返せます。

なぜチームはRESTよりgRPCを好むのか
エラーコード体系の経緯
直近のアーキテクチャレビューで決まったこと

Obsidianだけなら「このvaultをcloneして読んでください」になります。 Stripe級の内部システムなら「まず社内ツールを理解してください」になります。 Norfolk + Nexusなら、エージェントが最初から文脈を持って始められます。

シナリオ2: 同じチーム内のエージェント間で知識が伝播する

チームメンバーAのエージェントが本番障害をデバッグして重要な知見を見つけ、それをNexusに保存します。翌日、メンバーBのエージェントが似た問題に遭遇すると、AMCP経由でその知見をそのまま呼び出せます。

これはSlackにメッセージを残すのとは本質的に違います。 Slackメッセージは人のための伝達です。 Atomはエージェントがそのまま使える単位です。

シナリオ3: 組織知識の自動コンパイル

5人のメンバーが作業を続けると、彼らが生み出したAtomがNorfolkのチーム空間に蓄積されます。これはKarpathyの個人wikiコンパイルを、チーム規模へ拡張することです。

ファイル単位の仕組みは衝突しやすいですが、Atom単位の仕組みは合成できます。

これはObsidianとの戦いではない

NorfolkはObsidianの代替ではありません。 Obsidianは個人の思考のための優れた道具であり続けます。

違うのは出力の形です。 ObsidianのMarkdownは人が読むための形です。 NorfolkのAtomはエージェントが使うための形です。そしてNexusはAMCPを通じて、そのAtomを複数のエージェントから使えるようにするプロトコル層です。

Karpathy自身も、エージェントが知識ベースを構築し、その知識ベースが後の問題解決能力を高めるループを語っていました。私たちがやろうとしているのは、そのループをチームレベルに引き上げることです。

もうStripeを羨む必要はない

Stripeは長年の投資で、エージェントに組織コンテキストを与えました。ほとんどのチームにはそれができません。

Norfolk + Nexusのチームプランは、現実的なコストでエージェントに共有チームメモリを与えるための、より速い道です。

それによってStripeの原理を小規模チームでも実用化できます。どのモデルを使うかより、エージェントにどんな記憶を与えられるかのほうが、性能差を左右するようになります。

エージェント時代には、それ自体が競争優位になります。

始める

Norfolk: 無料で始めてチームプランへ拡張
Nexus: ローカル無料から始めてチームメモリへ拡張
AMCP Spec: Apache 2.0のオープンプロトコル

この記事は、Nunchi AIのインディーハッカー向けプロモーション実験シリーズの一部です。