🧠 GBrainとは — AIエージェントに「答えを返す脳」を与えるオープンソースのナレッジランタイム

グラレコ

はじめに 🎯

GBrain は、AIエージェントに「知識の脳（brain layer）」を与えるオープンソースのナレッジランタイムです。作者は Y Combinator の President 兼 CEO である Garry Tan 氏で、ライセンスは MIT、実装は TypeScript、GitHub では 2 万を超えるスターを集めています（2026 年 6 月時点）。

GBrain の立ち位置は、リポジトリ冒頭の一文によく表れています。「Search gives you raw pages. GBrain gives you the answer.（検索は生のページを返すが、GBrain は答えを返す）」。一般的な個人ナレッジツールがキーワード一致やベクトル検索で「関連しそうなページ一覧」を返すのに対し、GBrain は複数ページを横断して合成された答えを、出典と「まだ分かっていないこと」の注記つきで返します。

この記事で分かること:

• 🔍 GBrain が「検索」と何が違うのか（ページ一覧ではなく答えを返す、という設計）
• ✨ 2 つの差別化要素 — 合成レイヤーと、自己配線するナレッジグラフ
• 🏗️ アーキテクチャ — Postgres + pgvector（WASM）と「Markdown スキル」という構成
• 🎯 ハイブリッド検索 + グラフの 4 段構えと、その実測ベンチマーク
• 🌙 データの入れ方と、夜間に賢くなる「ドリームサイクル」
• 🗂️ ブレイン / エージェントメモリ / セッションの 3 層の使い分け
• ⚙️ 導入方法（エージェントによる自動インストール / CLI / MCP）と 3 つのデプロイ構成

想定読者は、AIエージェントに永続的な知識基盤を持たせたい開発者・チームリーダーの方々です。

---

GBrain が解く課題：検索は「ページ」を返すが、脳は「答え」を返す 🔍

GBrain の出発点は、Garry Tan 氏が自身の AI エージェント（OpenClaw / Hermes）を運用する中でぶつかった 2 つの問題でした。公式の Origin ドキュメントによれば、初期版はスキルとブレインを持っていたものの、ブレインの実体は「Markdown ファイルが並んだフラットなディレクトリ」で、検索は ripgrep、記憶は雰囲気頼みだったといいます。

そこで surfaced した問題が次の 2 つです。

• エージェントが会話をまたいで物事を忘れる。新しいセッションのたびに基本的な質問を聞き直し、先週紹介された人の名前も消えてしまう。
• エージェントが作業を重複させる。同じ会社に関する 2 つのシグナルが 2 つの別人ページになり、同じ人との 3 回の会議が 3 つの無相関なタイムラインになる。

この 2 つを「許容できない」と決めたときに作られたのが GBrain です。具体例で見ると、違いがはっきりします。たとえば「明日の Alice との会議の前に何を知っておくべき？」と尋ねたとき、多くのツールは次のようなページ一覧を返します。

1. people/alice — Alice runs engineering at Acme...
2. meetings/2026-03-15-alice-q1 — Q1 product review with Alice...
3. customers/acme — Acme is a series-B fintech we work with...
...

利用者はこの 5 ページを自分で開いて読み、準備をしなければなりません。一方、GBrain は出典つきの答えそのものを返します。

Alice は Acme（シリーズ B のフィンテック）でエンジニアリングを統括。
最後に話したのは 4/22 の価格に関する短いやり取り。
そこから未解決のことが 3 つ:
  1. 新ティアのセキュリティレビュー（締切 5/1、以降更新なし）
  2. 500 席ティアの価格提示（4/25 送付、返答待ち）
  3. CISO 採用の話 — あなたは人を紹介すると言った

注意: Alice / Acme について 4/22 以降ブレインに追記がない（6 週間）。
メールや Slack DM など、ブレインが見ていない経路で返信が来ている可能性がある。

末尾の「注意」が、GBrain がほかと違う部分です。すべての主張に出典ページが紐づき、さらに「ブレインがまだ知らないこと（情報が古い、出典がない、矛盾している）」を明示します。検索エンジンはページを見つけ、脳はそれを読んで答えを書く、という違いになります。

この図のポイントは、検索ツールが「材料を見つける」ところで止まるのに対し、GBrain は同じ材料を読んで「答えを書く」ところまで進む点です。

---

2 つの差別化要素：合成レイヤーと自己配線グラフ ✨

GBrain は、多くの個人ナレッジツールが備えるキーワード一致や grep を内包したうえで、他があまり同梱しない 2 つの機能を組み合わせています。

① 合成レイヤー（gbrain think）

1 つ目は、実際の答えを返す合成レイヤーです。人・会社・案件・アイデアを横断して、出典つきの散文として答えを合成します。「クエリに言及している 10 個のチャンク」ではなく、「この答え＋出典＋まだ分かっていないことの注記」を返します。このギャップ分析こそが、ブレインの使い方を変える部分だと位置づけられています。

② 自己配線するナレッジグラフ

2 つ目は、自動で配線されていく知識グラフです。すべてのページ書き込み時にエンティティ参照を抽出し、attended（参加した）/ works_at（所属）/ invested_in（投資した）/ founded（創業した）/ advises（助言する）といった型つきエッジを、LLM 呼び出しゼロで作ります。これにより「Acme AI で誰が働いている？」「Bob は今四半期に何に投資した？」のような、ベクトル検索だけでは届かない問いに答えられます。

次の図は、ページ書き込みからグラフが育つ流れを示しています。

この図のポイントは、エッジ抽出が3 つの正規表現と 1 回の SQL だけで完結し、LLM を一切使わないことです。公式ドキュメントによれば、グラフは毎回の書き込みでほぼゼロコストに育ち、1 万 7 千ページ規模のブレインでもグラフ全体の抽出が数秒で終わるとされています。

このグラフの効果は、ベンチマークにも表れています。公式 README とドキュメントが示す BrainBench（240 ページの Opus 生成リッチ散文コーパス）の数値は次のとおりです。

戦略	P@5	R@5	補足
ripgrep BM25 のみ	約 18	約 75	字句一致のみのベースライン
ベクトルのみ RAG	約 18	約 80	標準的な RAG 実装
GBrain グラフ無効（ハイブリッド + RRF）	約 18	約 85	ハイブリッド単体
GBrain デフォルト（フルスタック）	49.1	97.9	グラフ + 抽出品質の上乗せ

公式ドキュメントは、グラフと抽出品質の作り込みで P@5 が +31.4 ポイント伸びたと説明し、「グラフは限界的な機能ではなく、荷重を支える壁（load-bearing wall）だ」と位置づけています。

---

アーキテクチャ：Postgres + pgvector（WASM）× Markdown スキル 🏗️

GBrain の構成上の特徴は、重い依存を持ち込まないことです。データベースは Postgres + pgvector ですが、WASM 上で動く PGLite を使うことで「サーバーなし・2 秒でデータベースが立ち上がる」状態を実現しています（公式によれば PGLite は個人ブレインでおおむね 5 万ページ規模まで対応し、それを超える規模や約 1,000 ファイル超では Supabase が推奨されます）。

そして、エージェントの振る舞いを決める「スキル」はコードではなく Markdown で書かれ、それらを束ねるのはルーター LLM ではなく小さなテキストファイルです。全体像は次の図のようになります。

この図のポイントは、クライアントが MCP（Model Context Protocol）経由でエンジンにつながり、エンジンの賢さの大部分が「Markdown のスキル」と「ルーティング表」に外出しされていることです。

「Thin Harness, Fat Skills」という思想

この設計の背景には、Garry Tan 氏が提唱する Thin Harness, Fat Skills（薄いハーネス、厚いスキル） という考え方があります。同氏のエッセイによれば、AI エージェントの生産性を分けるのはモデルの賢さではなく、モデルを包む「ハーネス」と「スキル」だとされます。

• スキルファイルは「何をするか（WHAT）」ではなく「どうやるか（HOW）」を教える、再利用可能な Markdown の手順書です。パラメータを取り、引数を変えて呼び出せる点で「メソッド呼び出しのように働く」と説明されます。
• ハーネスは LLM を回すプログラムで、ループ実行・ファイル読み書き・コンテキスト管理・安全性の強制だけを担う「薄い」存在に保ちます。40 個以上のツール定義でコンテキストを食いつぶす「太いハーネス」はアンチパターンとされています。
• **リゾルバ（RESOLVER）**は「文脈のためのルーティング表」です。タスク種別 X が現れたらドキュメント Y を先に読む、という対応を定義します。

GBrain は、この思想を「ブレイン」という形で具体化したものといえます。

---

ハイブリッド検索 + グラフの 4 段構え 🎯

GBrain の検索が「ページ一覧として優秀」なのは、4 つの戦略を重ねているからです。公式の Retrieval ドキュメントは、ベクトル検索だけでは実際の個人ナレッジ検索に力不足だと説明しています。

この図のポイントは、4 つの戦略が補完関係にあることです。ドキュメントは「各戦略は単体では失敗する」と整理しています。

• ベクトルのみ: 埋め込みに直接エンコードされていない事実関係を取りこぼす（「Garry のポートフォリオ企業」がポートフォリオ論のエッセイを返してしまう）。
• キーワードのみ: 言い換えに弱い（「retrieval」を探すと「search ranking」と書かれたページを逃す）。
• グラフのみ: 「Alice の隣人」は得意だが、まだリンクされていないものには無力。
• グラフ無しのハイブリッド: 「X とは？」には強いが、「Y と X の関係は？」というグラフ的な問いに弱い。

さらに上位にはリランカーが乗ります。v0.36.0.0 では ZeroEntropy の zerank-2 がデフォルトのリランカーとして搭載され、ドキュメントによれば実コーパス 20 クエリでトップ 1 の結果の 60% を入れ替えるとされています。コストは p50 で +150ms、約 $0.025/M トークンで、検索後に LLM 処理が続くエージェントループでは遅延はほぼ見えない、と説明されています。ランキングはソースにも敏感で、originals/ や concepts/ のような厳選コンテンツが daily/ や media/ のような大量コンテンツより上位に来るよう、SQL レイヤーで重みづけされます。

---

search と think の使い分け 🔎

GBrain には、性質の異なる 2 つのクエリ方法があります。

# 生の検索: ハイブリッドスコア上位のページを返す。高速・LLMコストなし
gbrain search "who's working on AI agents at portfolio companies?"

# ブレイン層: 出典つき + ギャップ分析つきの合成された答え
gbrain think "who's working on AI agents at portfolio companies?"

2 つは役割が違います。gbrain search は、ハイブリッドスコア（ベクトル + キーワード + RRF + ソースティア補正 + リランカー）で上位ページを返します。エージェントのコンテキストに材料を流し込みたいとき、引用元を探したいときに向きます。一方 gbrain think は、同じ検索を走らせたうえで結果を横断する答えを合成し、出典と「まだ分かっていないこと」の注記を付けます。

観点	gbrain search	gbrain think
返すもの	上位ページ一覧	合成された答え＋出典
LLM コスト	なし	あり（合成のため）
ギャップ分析	なし	あり（古い・無出典・矛盾を指摘）
向く用途	材料集め・引用探し	意思決定・まとめ

次の図は、gbrain think が答えを組み立てる流れです。

この図のポイントは、think が search と同じ検索を土台にしつつ、その上に「合成」と「分かっていないことの明示」を重ねる点です。

公式ドキュメントは、gbrain think を find_trajectory のようなツールと組み合わせると、「指標がどう変わったか × チームの今 × 約束したこと × 最後に会った時期 × 提供できる価値」を一発で、よくスコアリングされ・よく出典づけされた形で得られる、と説明しています。gbrain agent run "..." を使うと、同じ機能を Minions というキュー経由でサブエージェントに公開でき、クラッシュ耐性のある 2 フェーズ永続化で実行されます。

---

データの入れ方とドリームサイクル 🌙

データの取り込みは 1 コマンドで、同期的にレシートが返ります。

gbrain capture "覚えておきたい思いつき"
gbrain capture --file ./notes/today.md
echo "from a pipe" | gbrain capture --stdin

ページはデータベースとディスクに一度に着地します。デフォルトのスラッグは inbox/YYYY-MM-DD-<hash8> で、取り込んだものが予測可能なトリアージ場所に集まる作りです。Zapier / IFTTT / Apple ショートカットからは、Webhook（/ingest）への POST でも取り込めます。

そして GBrain の特徴的な仕組みが、夜間に走る ドリームサイクル（dream cycle） です。エージェントをチャットで働かせ続けるより、24 時間 365 日動くデーモンに取り込み・拡充・統合をやらせるほうが簡単だ、という発想に基づいています。

この図のポイントは、ブレインが「貯める」だけでなく、夜のあいだに自分自身を整える点です。README によれば、作者の本番ブレインは会議・メール・ツイート・音声通話・自分のアイデアを取り込みながら、出会った人と会社を逐次拡充し、引用を自分で直し、記憶を統合しています。本番ブレインの規模は 146,646 ページ / 24,585 人 / 5,339 社、66 個の cron ジョブが自律稼働（README の自己申告値）とされています。

---

ブレイン / メモリ / セッションの 3 層 🗂️

GBrain を使ううえで重要なのが、「何をどの層に置くか」という設計です。公式ガイドは、情報を 3 層に振り分けることを推奨しています。

この図のポイントは、「世界についての事実」と「エージェントの操作状態」を混ぜないことです。具体例で見ると分かりやすくなります。

情報の例	置き場所	理由
「Pedro は Brex の CEO」	GBrain	世界についての事実（人物ページ）
「Brex がシリーズ D を $12B で調達」	GBrain	世界についての事実（会社ページ）
「ユーザーは簡潔な書式を好む」	エージェントメモリ	エージェントの操作状態
「本番前にステージングへデプロイ」	エージェントメモリ	運用上の決定
「さっき話していたボード資料」	セッション	現在の会話文脈

ガイドは「人物をエージェントメモリに入れない」「ユーザーの好みを GBrain に入れない」と注意します。とくに、エージェントメモリはプラットフォームによってはリセットで消えるため、消えては困る世界知識は必ず GBrain（永続）に置く、という指針が示されています。迷ったら「これは世界についてか、操作の仕方についてか」を問えばよい、という整理です。

---

導入方法とデプロイ構成 ⚙️

GBrain は「AI エージェントによってインストール・運用される」前提で設計されています。最速の経路は、エージェント自身にインストールさせることです。

① エージェントに入れさせる（推奨）

OpenClaw や Hermes、あるいは Claude Code / Codex / Cursor などに、次の指示を貼り付けます。

Retrieve and follow the instructions at:
https://raw.githubusercontent.com/garrytan/gbrain/master/INSTALL_FOR_AGENTS.md

エージェントが GBrain をインストールし、ブレインを作成し、API キーを尋ね、43 個のスキルを読み込み、ドリームサイクルを設定し、エンドツーエンドで検証します。所要およそ 30 分、人間は質問に答えるだけ、という流れです。

② コーディングエージェントの記憶として（最短）

「まずはコーディングエージェントに記憶を持たせたい」なら、2 コマンドで済みます。

gbrain init --pglite                     # 2秒のローカルブレイン（Docker不要）
claude mcp add gbrain -- gbrain serve    # Codex なら codex mcp add ...

③ CLI スタンドアロン（エージェントなし）

bun install -g github:garrytan/gbrain
gbrain init --pglite     # 2秒。サーバーなし・Dockerなし
gbrain doctor            # ヘルスチェック
gbrain import ~/notes/   # Markdown をインデックス
gbrain query "what themes show up across my notes?"

GBrain は MCP（stdio と HTTP）で 30 以上のツールを公開します。HTTP サーバーは OAuth 2.1 + 管理ダッシュボード（/admin）を備え、DCR スタイルのクライアント登録、スコープによるアクセス制御（read / write / admin）、レート制限を含みます。

デプロイのトポロジーは 3 つ

GBrain は 3 つのデプロイ形状をサポートし、これらは組み合わせ可能です。

この図のポイントは、どの形状も最終的には「いまどの ~/.gbrain/config.json が有効か」に解決される、という統一された考え方です。thin client では、ローカル DB の代わりに remote_mcp フィールドが設定に入り、DB を触るコマンドは明確なエラーでリモートホストへ案内されます。

---

ナレッジベースブレインとセキュリティ 🔐

GBrain は個人用途だけでなく、チームの「ナレッジベースブレイン」としても動きます。チームの各人がログインでスコープされた自分用のスライスを持ち、クエリ時には自分が見てよいものだけが見えます。他人のメモや別チームのデータは見えません。

公式 README によれば、ブレインを読むあらゆる経路（検索・一覧・ルックアップ・複数ソース読み取り）に対してファズテストを行い、リークゼロを確認したとされています。これは Y Combinator が Request for Startups で挙げた「company-brain」の形に対応するもの、と位置づけられています。

💡 セキュリティの要は OAuth 2.1 とスコープ制御（read / write / admin）、レート制限です。ChatGPT 連携では PKCE つき OAuth 2.1 が必須、Perplexity 連携では最小権限の OAuth クライアントを発行する、といったクライアント別の作法が用意されています。

---

まとめ 🏁

最後に、GBrain の本質を 3 点に絞ります。

#	キーメッセージ
①	GBrain は「ページを返す検索」ではなく「出典つきの答え」を返すブレイン層。gbrain think のギャップ分析が、ブレインを"自分自身について問える存在"にする
②	差別化は 合成レイヤー × 自己配線グラフ。型つきエッジを LLM ゼロで張り、ハイブリッド + グラフ + リランカーで P@5 を大きく押し上げる
③	賢さの多くは Markdown のスキルとルーティングに外出しされている（Thin Harness, Fat Skills）。夜間のドリームサイクルがブレインを保ち続ける

導入を試すなら、まずは小さく始めるのが現実的です。gbrain init --pglite でサーバーなしのローカルブレインを 2 秒で立て、Claude Code や Codex に MCP で繋ぐところから入れます。そこから取り込み（capture）を習慣にし、search と think を使い分け、必要になったらドリームサイクルや thin client 構成へ広げていく、という順序が無理がありません。

GBrain が示しているのは、エージェントを賢くするのはモデルの大きさではなく、「正しい文脈を正しいタイミングで渡す仕組み」だという考え方です。コードを書く前の知識基盤を再現可能な形に整えることで、エージェントを「その場限りのチャット」から「組織で運用できる脳」へ引き上げられる——その設計を、オープンソースで確かめられる点に価値があります。

参考 📚

• garrytan/gbrain（GitHub リポジトリ） — GBrain 本体。README に価値提案・インストール・production 数値・ベンチマークの要約あり。
• gbrain docs/architecture/RETRIEVAL.md — ハイブリッド + グラフ + リランカーの 4 段構えと BrainBench の数値の根拠。
• gbrain docs/ethos/THIN_HARNESS_FAT_SKILLS.md — スキル / ハーネス / リゾルバの定義（Thin Harness, Fat Skills）。
• gbrain docs/guides/brain-vs-memory.md — ブレイン / エージェントメモリ / セッションの 3 層の振り分け。
• gbrain-evals（BrainBench） — 検索品質ベンチマークのコーパスとハーネス。