GBrain：AIエージェントに自分で管理できる記憶を

背景と概要

AI エージェントを長く使っていると、同じ壁に当たります。自分のことを覚えてくれない。あるいは覚えていても、その情報がどこから来たのか説明できない。多くの製品は記憶を自社のブラックボックスの中に置いているため、ツールを変えるたびに一から教え直すことになります。記憶が間違っていても、利用者が直す手段はほとんどありません。GBrain は、すでに使っているエージェントに「自分で管理できる記憶」を持たせることを狙ったプロジェクトです。

GBrain は、Y Combinator 社長兼 CEO の Garry Tan 氏が公開したオープンソースです。主に TypeScript で書かれ、MIT ライセンスで、無料でセルフホストできます。任意の有料ホスティングサービスとして gbrain.io も用意されています。リポジトリの説明は「Garry の主張の強い OpenClaw/Hermes Agent 用の頭脳」というものです。チャットボットではなく、エージェントの横に置く記憶レイヤーで、エージェントのフレームワークと個人用ナレッジベースの中間に位置します。GitHub のスターは 3 万 2 千を超えており、この問題への関心の高さがうかがえます。

作者は自身の運用規模も明かしています。OpenClaw と Hermes の本番環境で使う頭脳であり、155,795 ページ、24,589 人、5,340 社を保持し、66 件の定期ジョブが自律的に動いているといいます。ただし、これらは作者の自己申告で、第三者による評価ではありません。規模の目安として受け取るのが妥当です。

深掘り分析

GBrain の最も特徴的な設計は、記憶を「明示的な事実」として扱う点です。個々の事実は出典とともに保存され、訂正や撤回もできます。会話を黙ってベクトルに圧縮し、中身を読めなくする方式とは対照的です。記憶が今の形になった理由を、利用者がいつでも遡って確認できます。この監査可能性が、プロジェクトの中心にあります。 複数のエージェントは、どうやって同じ記憶を共有するのでしょうか。GBrain では記憶を一か所に保存し、共通の窓口から参照します。Codex や Claude Code のような別のエージェントも、先に書き込まれた事実をそのまま読めます。クライアントを替えても、自分が何者かを説明し直す必要はありません。専用ガイドのない環境は、MCP 経由で接続します。

機能は段階的に足せます。最初は API キー不要のキーワード検索だけで始められます。その後、セマンティック検索、統合、バックグラウンドでの拡充を加えられます。スキルも同じ体系に入ります。新しいローカル brain には、コンテンツのルートに記憶用スキルが付きます。エージェントは認可されたディレクトリに参加でき、公開できるのは承認された編集者だけです。ホスト型のコーディングエージェントの導入では独自のネイティブ経路が加わり、再起動と実利用での検証は別の手順として明記されています。移行は段階的に進み、共有の選択や個人の変更は保持されます。 作者は日々の動きも説明しています。自分が眠っている間に、エージェントが会議、メール、ツイート、音声通話、自分の着想を取り込みます。出会った人物や企業のプロフィールを補い、自分の引用を修正し、夜間に記憶を整理するそうです。

業界への影響

導入経路は三つあり、文書は推奨順を示しています。第一は公式推奨の方法で、すでに動かしているエージェントに GBrain を足します。エージェントは元の身元を保ったまま、自分の環境に記憶を置きます。新しい個人エージェントの身元も、プライベートリポジトリも不要です。Grok Bot、Muse、Codex、Claude Code には専用ガイドがあります。 第二は自分のコンピューターで使う方法です。gbrain mcp expose という一つのコマンドで、brain を MCP 経由で Tailscale の tailnet に公開し、動かし続けられます。Grok Bot、Muse、ChatGPT のようなクラウド上のエージェント向けには、--funnel を加えます。文書は、エージェントに「use my brain over mcp」と伝えればよいとまで書いています。第三は既存のホスト型 brain への接続で、ネイティブ OAuth か私設マシン接続を選べます。管理側には別の owner 認証情報を使い、委任は意図して行う選択として書かれています。

文書の中には評価できる点があります。Grok Bot と Grok Build、Muse の個人エージェントと Muse Code は別の製品だと区別しています。また Muse には編集可能なネイティブ記憶がすでにあり、GBrain が加えるのは明示的で持ち運べ、出典があり、共有できる記録だと説明します。各ガイドには日付付きの根拠と未完了の検証手順も載っています。この率直さは、自分の環境で使えるかを判断する助けになります。 エンジニアリングチームにとって本質的なのは、記憶の所有者は誰かという問いです。エージェントが長期の同僚に近づくほど、特定ベンダーの裏側にしかない記憶は、移行コストと監査の難しさを増やします。GBrain は記憶を、利用者が持ち、出典があり、直せる資産として扱います。会社共有の brain としても使え、リモートのクライアントは出典と操作の許可、可視性フィルタで制限されます。

今後の展望

プロジェクト自身が限界を明記しています。導入前に必ず読むべき部分です。ローカルファイルと共有データベースの認証情報は、別の信頼境界にあたります。出典の区分だけでは、これらの呼び出し元を隔離できません。認可テストが対象とするのは具体的なアクセス経路で、情報が漏れないことの一般的な保証ではありません。チームは本番投入の前に、認証情報の管理と権限の範囲を自分で評価する必要があります。

もう一つのリスクは根拠です。規模や日々の成果は、主に作者の自己申告に基づきます。自分のデータとワークフローでどう動くかは、実際に試すまで分かりません。小規模チームなら、キーワード検索から始めて既存のエージェントを一つ接続し、出典付きの事実と訂正が文書どおりに働くかを確かめるのが現実的です。

今後の注目点は三つあります。各ハーネスのガイドで未了の検証手順がいつ埋まるか。複数のエージェントが記憶を共有するとき、訂正と撤回が実際にどう反映されるか。無料のセルフホストと有料の gbrain.io の境界が、どう変わっていくか。この答えによって、GBrain が持ち運べて監査できるエージェント記憶の定番になるのか、強力な個人環境にとどまるのかが見えてきそうです。