GBrain入門 — Garry TanがOSS化したAIエージェントの「記憶基盤」を読み解く

エージェントは毎朝、記憶を失う

優秀なAIエージェントを組んでも、セッションをまたいだ瞬間に「昨日の自分」を忘れる——この問題に正面から取り組んだのが GBrain です。Y CombinatorのCEO Garry Tan が、自身のエージェント（OpenClaw / Hermes）を動かすために作り、 2026年4月にMITライセンスでオープンソース化しました。公開直後から数千スターを集め、「エージェントの記憶基盤」をどう設計すべきかの一つの回答として注目されています。

本記事は、GBrainを「概念」と「使い方」の両面から読み解きます。 なぜ記憶が今の主戦場なのか、GBrainの設計思想（Markdown-first・自己配線グラフ・ハイブリッド検索）はどう効くのか、 そして手元でどう動かすのか。一次情報（GitHubリポジトリ・ドキュメント）と解説記事をもとに整理します。

なぜ「エージェントの記憶」が2026年の主戦場なのか

2026年、LLM活用の勝負どころは「うまいプロンプト」から「何をどう記憶させるか」へ移りました。 文脈窓は1Mトークンが標準になりましたが、長くするほど精度が落ちる context rot が全モデルで確認され、 「全部詰め込む」戦略は破綻します。だからこそ、必要な知識をモデルの外部に永続化し、 必要なときだけ引き出す設計が要になりました。

ここで多くの記憶ソリューションは「ベクトルDBに埋め込みを貯める」アプローチを取ります。 GBrainの面白さは、その出発点を「記憶はプレーンテキストの知識である」と置き直した点にあります。 記憶を不透明なDBの状態ではなく、人間が読めてdiffが取れるMarkdownとして持つ——この一点が設計全体を貫いています。

GBrainとは — 一言でいうと

GBrainは 「Markdownのメモを、エージェントが読み書き・推論できる自己配線ナレッジグラフに変換する記憶レイヤー」 です。 記憶の正本（system of record）はgitリポジトリ上のMarkdown群（=ブレインリポジトリ）で、それを検索可能にするためにPostgresへ同期します。 gitで消したページはDB上ではソフトデリートになります。

スケール感を示す数字として、Garry Tan本人の本番ブレインは 146,646ページ / 24,585人 / 5,339社 / 66の自律cronジョブを保持していると公表されています。 個人のナレッジ管理から、チーム共有の「カンパニーブレイン」まで射程に入れた設計です。

設計思想① Markdown-first — 記憶をgitで持つ

GBrainの第一の主張は「記憶をデータベースに閉じ込めない」ことです。 ブレインリポジトリはただのMarkdownのgitリポジトリなので、以下が追加コストなしで手に入ります。

• diff・バージョン管理：記憶の変化をコミット履歴で追える。「いつ・何を・どう書き換えたか」が残る。
• 公開サブセットの切り出し：一部だけを公開ブランチとして出せる。チームは共有ブランチをマウントできる。
• human-readable：エージェントが書いた記憶を、人間がそのまま読んで修正できる。ブラックボックスにならない。

ページは 「compiled truth + timeline」 という型を取ります。上部に「現時点での最良の理解（compiled）」、 下部に日付つきで証拠を追記していく「タイムライン（append-only）」を持つ構造です。 これにより「最新の結論」と「そこに至った根拠の履歴」を1ファイルで両立させます。 ページは person / company / concept などの型（schema pack gbrain-base-v2 は15種のMECEな型）で分類されます。

設計思想② 自己配線ナレッジグラフ — LLMを呼ばずに関係を張る

GBrainの核心がこれです。ページを書き込むたびに、本文中のエンティティ参照（wikilink）から 型付きエッジ（typed edge）を自動生成します。しかも特筆すべきは、 この配線にLLMコールを一切使わないこと。正規表現ベースのパターンマッチングで関係を推論します。

たとえば本文に Founder and CEO of [[companies/acme-ai]] と書けば、 そこから founded と works_at の関係が双方向に張られます。 参照は [[people/alice-chen]] のようにフルスラッグパスで書くことでグラフ解決を正確にします。 生成される関係は次の6種です。

• works_at / founded / invested_in / attended / advises / mentions

推論は FOUNDED → INVESTED → ADVISES → WORKS_AT → MENTIONS というカスケード順で適用され、 より強い関係が優先されます（例：創業者なら単なるmentionsではなくfoundedとして拾う）。

graph LR
    A["person: Alice Chen"] -->|works_at| C["company: Acme AI"]
    B["person: Bob Lee"] -->|founded| C
    B -->|invested_in| D["company: Beta Labs"]
    A -->|attended| E["event: AI Summit"]
    C -.->|mentions| D

この構造の効果は明確です。ベクトル検索は「似た文章」を返しますが、 「Acme AIに投資した人物が創業した別の会社は？」のような多段（multi-hop）の事実探索は苦手です。 グラフがあれば gbrain graph-query でエッジをたどって到達できます。検索エンジンが返せない答えに届くわけです。

設計思想③ ハイブリッド検索 — ベクトル・キーワード・グラフの合わせ技

GBrainの検索は単一手法に頼りません。複数のランキング信号を統合します。

• ベクトル検索：pgvectorのHNSWインデックスによる埋め込み類似度。
• BM25キーワード検索：Postgresの tsvector による語彙的マッチ。
• RRF（Reciprocal Rank Fusion）：両者の順位を score = Σ 1 / (60 + rank) で融合する。
• リランカー：既定の balanced モードでは ZeroEntropy のリランカーで並べ替え。
• グラフ信号：隣接ブースト・情報源間の裏取り・セッション内の重複降格など。

コスト/品質のトレードオフは conservative / balanced / tokenmax の3モードに束ねられています。 内部ベンチ（240ページのコーパス）では、グラフを無効化したベースラインに対して P@5で約+31.4ポイントの改善（P@5 49.1%、R@5 97.9%）が報告されています。 「グラフはベクトル単独に勝つ」というのがGBrainの実証的な主張です。

アーキテクチャ全体像 — 書き込みから検索まで

ここまでを1枚にまとめると、GBrainは「Markdown書き込み → 自己配線グラフ＋PG同期 → ハイブリッド検索 → search / think の2出力」という流れになります。

flowchart TB
    W["Markdown書き込み<br/>(capture / put_page)"] --> G["自己配線グラフ<br/>wikilinkから型付きエッジを正規表現で生成"]
    W --> DB[("PGLite / Postgres<br/>pgvector + tsvector")]
    G --> DB
    Q["検索クエリ"] --> H["ハイブリッド検索<br/>vector + BM25 + RRF + reranker + graph"]
    DB --> H
    H --> S["search<br/>生の検索結果（高速・LLM不要）"]
    H --> T["think<br/>合成回答＋ギャップ分析"]

ストレージは2エンジン構成です。既定は PGLite（Postgres 17をWASM化したもの）で、 サーバ不要・ゼロ設定で個人ブレイン（〜約5万ページ）に対応します。 それを超える共有/大規模用途では Postgres + pgvector（Supabaseや自己ホスト）へ移行できます。

使ってみる — CLIとMCP接続

最小構成なら数コマンドで動きます。ローカルのPGLiteで起動し、手元のMarkdownを取り込んで検索する流れです。

# インストール（bun）
bun install -g github:garrytan/gbrain

# ローカルにブレインを初期化（PGLite, サーバ不要・約2秒）
gbrain init --pglite

# 既存のMarkdownメモを取り込む
gbrain import ~/notes/

# 検索（生の結果）と思考（合成回答）
gbrain search "context engineering" --explain
gbrain think  "私のメモでcontext rotに触れているのは？"

真価はエージェントから使うときに出ます。GBrainは MCP（Model Context Protocol） サーバとして 多数のツール（get_page / put_page / search / query / add_link / get_backlinks など）を公開します。 Claude Codeなら1コマンドで接続できます。

# Claude Code に stdio MCP として登録
claude mcp add gbrain -- gbrain serve

# チーム共有・他クライアント向けには HTTP + OAuth で公開
gbrain serve --http   # OAuth 2.1 / 管理ダッシュボード / レート制限つき

gbrain serve はローカル用のstdio MCP、--http はOAuth付きのHTTP MCPです。 後者はスコープ制御（read / write / admin）やレート制限を備え、ChatGPTやCursor、Windsurfなど複数クライアントから同じブレインを叩けます。

search と think、そして「夢を見る」運用

GBrainには性格の異なる2つの問い合わせ口があります。使い分けが重要です。

• search：ハイブリッドスコアで並べた生の検索結果を返す。高速でLLMコストもかからない。引用元の確認や流し読みに向く。
• think：同じ検索層の上に合成（composition）を載せ、引用つきの回答に加えて「ブレインがまだ知らないこと」のギャップ分析まで返す。

さらにGBrainは dream cycle（メモリ統合） と呼ぶcronジョブで、いわば「寝ている間」に記憶を育てます。 人物ページの重複統合、引用の修正、重要度（salience）スコアリング、矛盾の検出、翌日のタスク準備などを自動で回す仕組みです。 非同期処理は使い捨てのPromiseではなく、クラッシュ耐性のある minionsキュー（Postgresネイティブ、二相のpending→done永続化）で実行されます。

他の記憶ソリューションとの立ち位置

「エージェントの記憶」は2026年に激戦区です。代表的な選択肢とGBrainのざっくりした立ち位置を整理します （各製品は進化が速いため、概念的な比較として読んでください）。

ひとことで言えば、GBrainは「記憶の所有権をユーザーに残し、テキストとグラフで事実を構造化する」方向に振り切った設計です。 「記憶をブラックボックスのDBに預けたくない」「履歴と根拠を残したい」というニーズに強く刺さります。

よくある誤解

まとめ

• ① 記憶はテキストとして持つ。 GBrainは記憶の正本をgit管理のMarkdownに置き、diff・バージョン管理・公開サブセットを無料で得る。所有権と可搬性がユーザーに残る。
• ② グラフはベクトルに勝つ場面がある。 wikilinkからLLMなしで型付きエッジを自己配線し、多段の事実探索を可能に。ベクトル+BM25+RRF+グラフのハイブリッドでP@5を約+31.4ポイント改善と報告。
• ③ ゼロ設定で試せてMCPで繋がる。 PGLiteでローカル即起動、claude mcp add gbrain -- gbrain serve でエージェント接続。生検索のsearchと合成＋ギャップ分析のthink、capture/dream cycleで日々ブレインを育てる。