GBrainは検索結果を引用付きの回答へ変えるエージェント記憶層

検索ページを読む回答へ変える発想

GBrainの中心的な考え方は、検索が生のページを返すだけでは足りないというものです。READMEでは、会議前にある人物について何を思い出すべきかを尋ねる例を使い、普通の検索なら開いて読むべきページの一覧が返り、GBrainなら要点、未解決の約束、各主張の出典、記録が更新されていないという注意をまとめた回答が返ると説明しています。

この回答は、保存されたページを読み直す作業の一部を合成層へ移します。主張の背後にソースページを残し、ブレインにない情報や古い情報を知らせる点が設計上の焦点です。ただし、回答が自然な文章になっていることは事実の正しさを保証しません。引用先を開いて元の記録と照合するという使い方が前提になります。

thinkとsearchが分ける取得と解釈

gbrain searchは、ベクトル、キーワード、RRF、ソース階層のブースト、リランカーを組み合わせたハイブリッド順位付けで上位ページを返します。利用者が元データを自分で読みたいときの入口です。gbrain thinkは同じ検索を行った後、ソースページへの明示的な引用と、まだ分からないことを示す合成回答を作ります。

ギャップ分析は、ページが古い、主張に引用が付いていない、二つのページが矛盾している、情報を埋める必要がある、といった状態を知らせる機能として説明されています。これは記憶の量を増やす機能ではなく、記憶の穴を回答の中に出す仕組みです。Minionsキューを介してサブエージェントへ同じ面を公開し、gbrain agent runではクラッシュに備えた二段階の永続化を使うとREADMEは述べています。

ページを保存しながら関係を作る

データの取り込みはgbrain captureで行います。引数、ファイル、標準入力を受け取り、ページをデータベースとディスクへ置く経路です。Zapier、IFTTT、Apple Shortcutsから使えるWebhookエンドポイントもREADMEに記載されています。定期的に入ってくる記録を同じ保存面へ集め、後のsearchやthinkから再利用する形です。

ページを書き込むと、エンティティ参照が抽出され、attended、works_at、invested_in、founded、advisesなどの型付きエッジが作られます。READMEはこの処理をLLM呼び出しなしの自己配線ナレッジグラフと説明しています。人物、会社、会議の関係をベクトルの近さだけではなく辿れる点が、単純な全文検索との違いです。グラフの抽出結果が自分の記録で正しいかは、個別のページと関係を確認する必要があります。

ベンチマークは条件付きの自己報告として読む

READMEには、240ページのOpus生成リッチプローズコーパスでP@5が49.1%、R@5が97.9%、グラフを無効にした構成に対してP@5が31.4ポイント高かったというベンチマークが記載されています。ripgrep-BM25とベクトルだけのRAGに対しても同程度の差があるとされています。詳しいBrainBenchのスコアカードは、別のgbrain-evalsリポジトリへ案内されています。

これらはデータセット、生成方法、評価実装、比較構成に依存する数値です。READMEに書かれた結果を、そのまま自分の業務記録や日本語データでの性能と置き換えることはできません。GBrainの差別化を検討するなら、検索上位が本当に必要なページを含むか、エッジが誤っていないか、引用付き回答が元記録を歪めないかを自分の小さなコーパスで確認するのが先です。

npmではなくBunかGitHubから導入する

READMEは、GBrainがnpmで配布されていないことを強く警告しています。npmにある同名のパッケージは無関係で、npm install -g gbrainやbun add -g gbrainを実行すると別のものがPATH上で本物のバイナリを隠す可能性があります。文書化された導入経路は、bun install -g github:garrytan/gbrain、またはgit cloneの後にbun installとbun linkを実行する方法です。

GBrainはAIエージェントから導入と運用を行う想定を持ちます。CodexとClaude Codeではgbrain init --pgliteの後にclaude mcp addまたはcodex mcp addで接続します。OpenClawとHermesでは常時稼働するブレインとして使い、取り込み、人物や会社の補完、記憶の統合を繰り返す構成です。npmの同名パッケージを誤って入れた場合は削除し、GitHub由来の経路から再導入してからdoctorでPATHの衝突を確認します。

個人記憶からチームの閲覧範囲へ

GBrainは個人用の長期記憶だけでなく、チームの共有ブレインも想定しています。READMEは、ログインした人ごとにブレインの一部分を割り当て、検索時には許可された内容だけを返し、別の人のメモや別チームのデータは見えないと説明しています。検索、一覧、単一参照、複数ソースの読み取りを対象にファズテストを行い、漏えいがゼロだったという自己報告もあります。

この主張はアクセス制御の設計方針と検査結果を示しますが、利用者側の設定ミス、保存領域の権限、認証基盤、バックアップのコピーまで安全にするものではありません。会社の記録を入れる場合は、ログインとチームスコープの対応、誰がページを書けるか、検索回答に引用がどこまで含まれるかを確認すべきです。個人用と共有用を同じブレインへ混ぜる前に、gbrainのドキュメントにあるスコープ設定とデータパスを読んで境界を決める必要があります。

スキーマパックとドキュメントの分割

スキーマパックは、ブレイン内でどの種類のページを扱うかを定義します。READMEの説明では、既定のgbrain-base-v2は14の標準タイプとnoteの受け皿を含む15タイプで、旧来のgbrain-baseは24タイプです。既存のファイルシステムから候補を提案するgbrain schema detect、suggest、review-candidatesもあります。

公式の案内は、インストールとアーキテクチャのdocs、通常のエージェント向けAGENTS.md、Claude Code向けCLAUDE.md、セキュリティ用SECURITY.mdに分かれています。LLM向けにはllms.txtとllms-full.txtがあり、前者は文書地図、後者は主要文書を埋め込んだ地図です。用途によって読む入口が違うため、コマンドだけをREADMEから抜き出して運用を始めるより、接続するエージェントとスキーマパックに対応する文書を先に固定する方がよいでしょう。

READMEの主張と導入判断を切り分ける

READMEには、作者が自分のOpenClawとHermesの展開で使っていること、15万ページを超える記録や多数の人物、会社、cronジョブを扱っていることが示されています。これらはプロジェクト側が説明する運用例です。利用者のデータ量で同じ処理時間、費用、回答品質になることを意味しません。常時稼働するエージェントを選ぶ場合は、サーバー、データベース、外部APIキーの費用も自分の構成で見積もる必要があります。

ライセンスはMITで、利用、複製、変更、結合、公開、配布、サブライセンス、販売を許可しますが、ソフトウェアは保証なしで提供されます。READMEはSECURITY.mdを案内するものの、ここで性能保証やサポート契約を約束してはいません。GBrainを採用するかは、検索の便利さだけでなく、データを平文に近い形で扱う範囲、引用を検証できる作業、チームの権限設計、GitHubからの更新を追える体制を具体的に確認して決めるべきです。

編集部の結論

GBrainは、過去の会議、メール、アイデア、作業記録を後続のエージェントセッションで再利用し、検索結果の一覧ではなく引用付きの要約を得たい人に向きます。導入経路はnpmではなくBunまたはGitHubで、CodexとClaude CodeはPGLiteを使う初期化、OpenClawとHermesは常時稼働する構成を想定します。READMEの性能値、運用規模、リーク検査はプロジェクト側の記載であり、利用者の環境で再現した結果ではありません。実際に使う前にデータの保存先、APIキー、チームの閲覧範囲、取り込み元の削除方法を確認してください。

公式情報源

1. Official README
2. Project repository
3. Release notes