GBrainは検索ではなく「答えを作る記憶層」

GBrainは、Markdownを永続的な正本として保持し、データベースへ索引を作り、AIエージェントから検索・更新できるようにするオープンソースの記憶基盤です。MCP経由でCodex、Claude Code、Hermesなどから利用できます。

特徴は、関連ページを並べるだけでなく、複数ページを統合した回答、出典、情報の古さや不足を示すgap analysisまで返すことです。また、ページ内の人物・会社・概念などの参照から知識グラフを構築し、キーワード検索やベクトル検索だけでは扱いにくい関係もたどれます。

一番重要な構造はCompiled Truth + Timeline

GBrainの推奨スキーマでは、一つのbrain pageを二層に分けます。上段のCompiled Truthは「現時点で最も妥当な理解」で、新しい情報に応じて書き換えられます。下段のTimelineは、日付・出典・出来事を持つ追記型の証拠ログです。

people/example.md

# Compiled Truth
現在の役割、重要な背景、未解決事項

---

# Timeline
2026-06-12 | Source: meeting | 組織変更を確認
2026-04-05 | Source: email   | 新しい役割への変更を確認

新しいsignalが入ると、Timelineへ証拠を追加し、その内容を踏まえてCompiled Truthを再評価します。「現在どうなっているか」なら上段を、「何が起きたか」なら下段を読むため、LLMが毎回すべての履歴から現在状態を推論し直す必要がありません。

普通のRAGより長い処理を持つ

GBrainの検索は、ベクトル検索だけではありません。READMEでは、vector・keywordを含むhybrid retrieval、typed relationship graph、検索結果のsynthesis、citations、gap analysisが中心機能として説明されています。

ページ内のentity referenceから、works_at、attended、invested_inなどのtyped edgeを構築できます。これにより「似た文章」を探すだけでなく、「ある人物が所属する会社」「ある会議へ参加した人」のような関係をたどれます。

その後のsynthesisは候補ページを横断して答えを作り、gap analysisは情報の古さ、出典不足、矛盾、brainがまだ知らない範囲を示します。検索結果を回答として見せるのではなく、回答と、その回答をどこまで信頼できるかを一緒に返す設計です。

Brain、Agent Memory、Sessionは別物

公式ガイドは、保存先を三層に分けています。外界についての知識をGBrainへ、エージェントの動作方法をAgent Memoryへ、現在の会話だけで必要な情報をSession Contextへ置きます。

この分離により、人物情報をエージェント固有の一時メモへ閉じ込めたり、回答スタイルの好みを知識グラフへ混ぜたりすることを避けられます。

CollectorとDream Cycleで「育つbrain」にする

GBrainは、メール、カレンダー、会議、文書、会話ログなどのsignalを取り込む利用を想定しています。重要なのは、APIからの取得やcheckpoint管理は決定論的なcollectorに担当させ、entityの同定、意味の判断、要約はAIエージェントに担当させる分業です。

Signal → Collector → Agent judgment → Brain Page
       → index / embedding / graph → 次の質問

さらにDream Cycleでは、日中に触れたentityの確認、薄いページの補強、Timeline更新、壊れたcitationの修復、会話から永続化すべきpatternの抽出、古いembeddingの更新などをquiet hoursに実行します。これは単なる夜間バッチではなく、brainを使うほど整理された知識へ変える保守ループです。

実際に利用できるcollectorや外部サービスとの接続方法は更新されます。導入時には公式のintegration docsとingestion source contractを確認し、取得権限・保存範囲・削除方法まで設計する必要があります。

PersonalからTeam、Companyへ

公式READMEは最初の導線としてpersonal brainを案内し、その先にmulti-user、OAuth-scopedなcompany brainのチュートリアルを用意しています。したがって「個人向け製品か、会社向け製品か」という二択より、個人を基本単位に組織へ拡張できるアーキテクチャと捉える方が正確です。

設計の核心はbrainとsourceの二軸

公式architecture docsでは、brainは一つのデータベース、sourceはbrain内の名前付きコンテンツrepoと定義されています。両者は独立した軸です。

• データの所有者やアクセス方針が変わるなら、brainを分ける
• 所有者は同じで、テーマやrepoだけが変わるなら、sourceを分ける

この原則により、personal brainを残したまま複数のteam brainをmountできます。全社で一個の巨大データベースだけを運用する必要はありません。

会社利用で効く、読み取りと書き込みの非対称性

company brainでは、利用者やAIエージェントごとにOAuthクライアントを発行できます。公式チュートリアルのモデルでは、--sourceが書き込み先を一つに限定し、--federated-readが読み取り可能な複数sourceを指定します。読み取り範囲はSQL層でも制約されます。

# 例: 開発基盤エージェント
write: ai-platform
read:  ai-platform, shared, architecture

この形なら、エージェントが他部門の文脈を参照して回答しながら、生成物の保存先は担当sourceに閉じられます。人事・法務・評価情報などを別sourceや別brainへ分離する判断もしやすくなります。

ただし、権限設定だけで安全が完成するわけではありません。本番導入では、制限された資格情報を使った検索テスト、監査、バックアップ、誤取り込みへの対応を運用に含める必要があります。

社内AI基盤での活用案

社内利用では、アプリごとにsourceを切るより、所有者・機密区分・書き込み責任を先に決めるのがよいでしょう。Slack、Gitリポジトリ、ドキュメント、会議記録は入力チャネルであり、必ずしもそのまま権限境界ではありません。

たとえば次のような質問が、単一サービスの検索を越えた活用例になります。

• 「ある基盤移行は、最終的にどの案に決まり、未解決事項は何か」
• 「この認証方式を選んだ理由は、設計文書と会議記録で一貫しているか」
• 「この案件の現在地、直近の合意、次のアクションをまとめて」

ここで価値になるのは、Slack検索、Git検索、Drive検索を別々に行うことではありません。時間の異なる複数情報を、出典と不足情報を伴う一つの回答へ統合できることです。

導入するなら、最初に決めたいこと

1. 小さく始める：一つのチーム、一つの問い、一つのsourceから価値を確認する。
2. 所有者でbrainを分ける：個人、チーム、全社でデータオーナーが違うならDB境界を検討する。
3. 権限でsourceを分ける：閲覧範囲や書き込み責任が違う情報を同じsourceへ混ぜない。
4. 正本を決める：Slackの会話、GitのADR、Driveの文書が矛盾したとき、何を優先するか定義する。
5. 鮮度を運用する：同期失敗、古いページ、矛盾、誤情報を検知し、修正できる担当を置く。
6. 権限を実測する：制限ユーザーとして検索し、見えてはいけないsourceが返らないことを継続的に確認する。

なお、公式ドキュメントはSlackなどの取り込みを拡張可能なingestion sourceとして案内していますが、すべての外部サービスが標準コネクタとして揃うとは限りません。GitやDriveを含む具体的な接続方法、同期品質、API制約は導入時点の実装を確認すべきです。

まとめ

GBrainはPersonal Brainとして試しやすく、Team / Company Brainへ拡張できる記憶アーキテクチャです。会社利用で本当に重要なのは、情報を大量投入することではありません。brainを所有者の境界、sourceをrepo・テーマ・権限の境界として設計し、AIエージェントに必要最小限の読み書きを許可することです。

うまく設計できれば、GBrainは「社内を横断検索する箱」ではなく、意思決定の経緯、現在地、矛盾、まだ分からないことを出典付きで返す、組織の長期記憶になります。

参考資料

• GBrain公式リポジトリ
• GBrain Recommended Schema
• Brain vs Memory vs Session
• Reference Cron Schedule and the Dream Cycle
• Brains and Sources — the mental model
• Extend your personal brain into a company brain
• Deployment topologies

この記事は2026年8月17日時点の公式リポジトリとドキュメントをもとにしています。GBrainは更新が速いため、導入時には最新のREADMEとarchitecture docsを確認してください。