私たちはラベルを変えただけではありません。Norfolkが何であるかそのものを変えました。

---

しばらくのあいだ、Norfolkは説明しやすいものでした。ノートアプリ。何かを保存して、整理して、後で見つける。シンプルでした。

その説明は役に立ちました。ですが不完全でした。

というのも、私たちが作っているあいだに、Norfolkは静かに別のものになっていたからです。エージェントが provenance、scope、structure を持つメモリを読み、recallし、書き込める場所へ。

「ノートとチャットする」ことではありません。フォルダの上に載せたRAGでもありません。

一つの memory surface です。

昔の問いは間違っていた

Norfolkがただの「ノートアプリ」だったころ、当然の問いはこうでした。なぜObsidianではなく、なぜNotionではないのか。

もっともな問いです。でも、その framing が違っていました。

Norfolkは、より良いエディタになることで勝とうとしているわけではありません。Norfolkの優位は captureの後に 起きることにあります。

スクリーンショット、PDF、粗いメモ、リンク、まだ形になっていない思考を放り込みます。その感触はどのノートアプリとも似ています。ですが、その素材はただそこに置かれるのではありません。recallできるコンテキストになります。エージェントがそれを見つけ、引用し、その上に積み上げられるようになります。

ノートが working memory になるのです。

それが違いです。そして私たちはそれをもっと早く言うべきでした。

実際に何が変わったのか

今では二つのユーザーパスが明確になっています。

Personal Norfolk — あなたのエージェントはNorfolk空間を直接読み書きできます。ノートがAIワークフローから切り離された孤島ではなくなります。コーディングエージェント、リサーチエージェント、仕事アシスタントがNorfolkをコンテキストとして使えます。

ただし cross-recall はオフです。個人プランでは、NorfolkとNexusが一つの検索面に統合されるわけではありません。エージェントはNorfolkと一緒に動きますが、ストア自体は別々のままです。どちらと話すかはあなたが選びます。

これは意図的です。直接接続であって、完全共有インフラではありません。

Nunchi Team ($29/month) — 面白くなるのはここからです。

NorfolkとNexusが一つの recall surface になります。人間がNorfolkに残したものと、エージェントがNexusに記憶したものを一緒に検索できます。クオータも共有。recallも共有。両方合わせて120,000 MUです。

なぜ重要なのでしょうか。チームは、より良いモデルがないから失敗するのではありません。人もエージェントも、毎回同じコンテキストをゼロから作り直しているから失敗するのです。PMはNorfolkに意思決定を書いた。開発者のコーディングエージェントはその存在を知らない。だから開発者はSlackで聞き直します。あるいはもっと悪いことに、エージェントが推測します。

Team memory はそこを直します。一回の recall call で両方のストアを見に行き、provenance も保たれます。

その背後にあるアーキテクチャ

考え方はこうです。

Nexus は agent memory layer です。セッション、意思決定、作業履歴、実行コンテキスト。エージェントが 覚えているもの です。

Norfolk は human knowledge layer です。ノート、文書、リサーチ、アップロード、残しておく価値のあるエージェント出力。チームが 知っているもの です。

AMCP は、どのエージェントでも同じインターフェース、recall, remember, sessions, export でどちらのストアともやり取りできるようにするプロトコルです。

Claude Code / Cowork / Your Agent
              ↓
       AMCP-MCP Server
              ↓
        Policy Layer
         ├── Nexus   (remembering)
         └── Norfolk (knowing)

エージェントは保存の詳細を知る必要がありません。target付きで recall を呼ぶだけです。サーバーが routing、scope、access control を処理します。チームプランでは target=auto が両方のストアを検索し、source タグ付きで結果を返します。

すべての結果には provenance が付きます。誰が作ったのか（人間かエージェントか）、どのストアから来たのか、どのセッションに属しているのか。何が人間の意思決定で、何がエージェントの作業メモなのか曖昧になりません。

なぜ単なるウィキではだめなのか。なぜ単なるファイルではだめなのか

今人気のある発想があります。AIにmarkdownファイルのフォルダを渡し、ウィキを保守させる。ソースを読み、ページを更新し、相互参照させるというものです。

その洞察自体は正しいです。知識は毎セッションで再起動するのではなく、複利のように積み上がるべきです。RAGは元本を戻してくれます。ウィキは利息を生みます。

ですが、ファイルベースのウィキはすぐに天井に当たります。

ファイルが何百にもなると、エージェントは どの ファイルを読むべきか知るために index file を必要とします。その index も保守が必要です。index がずれ始めると、ウィキ全体が信頼できなくなります。保守コストを減らすために仕組みを作ったのに、返ってきたのは……もう一つの保守問題です。

しかも、その前にもっと難しい問いがあります。二つのエージェントは同じ知識を共有できるか。チームメンバーのノートは、別のメンバーのエージェントからrecall可能になるか。その知識が人間によって書かれたのか、エージェントによって生成されたのかを区別できるか。

ファイルはそうした問いに答えられません。プロトコルなら答えられます。

だからこそ、メモリはフォルダではなくインフラであるべきなのです。

私たちのメモリ観

多くのAI製品はメモリを曖昧に語ります。チャット履歴。フォルダとタグ。ハーネスの中に貼りつけられた隠れたretrieval。あるいはモデルそのものの機能として。

私たちは、メモリにはもっとはっきりした性質が必要だと考えています。

メモリはセッションより長生きしなければならない。 タブを閉じるか、ランタイムを再起動した瞬間に消えるなら、それはメモリではなく一時コンテキストです。

メモリは provenance を持たなければならない。 エージェントは 何が 記憶されたかだけでなく、それがどこから来たのか、誰が作ったのか、どの scope に属するのかを知るべきです。

メモリは複数の actor に使われるべきだ。 人間のノートが人間専用UIの中に閉じ込められてはいけません。エージェントのメモリも一社のベンダーランタイムの中にロックされてはいけません。

メモリは portable でなければならない。 モデルは進化します。ハーネスは変わります。ベンダーも変わります。メモリはそのすべてを越えて生き残るべきです。だからこそ AMCP はオープンプロトコルとして存在します。メモリが単一ツールに結びつかないようにするためです。

Norfolkはそれでもノートアプリです

だからといって、Norfolkが使いやすさをやめるという意味ではありません。

むしろ逆です。人間側のメモリが自然であり続けなければならないので、capture体験は より 重要になりました。

人は schema から始めません。スクリーンショットから始めます。粗い思いつきから始めます。分類するには早すぎるタイミングで保存したリンクから始めます。

ただ入れる。構造を強制しない。人間を database admin にしない。

Norfolkはフロントではシンプルなままです。ですが capture された素材のバックエンド上の意味は、ずっと大きくなりました。ノートとして始まったものが、recall可能なコンテキストになれる。個人の記録として始まったものが、のちにエージェントワークフローに参加できる。

私たちはノートから離れているのではありません。ノートにもっと大きな仕事を与えているのです。

それがユーザー側ではどう見えるか

ユーザーから見ると、物語は今の方がずっときれいです。

業界はどのモデルが勝つかを問い続けています。私たちは、その問い自体がよく間違っていると思っています。

モデルは進化し続けるでしょう。もっと長く重要なのは、その変化を越えてメモリが生き残るかどうかです。

それが、私たちが作っているものです。

---

NorfolkはNunchi AIのメモリインフラの一部です。nunchiai.com で試せます。