GBrain：個人向けAI知識管理システムの実装例
Vannevar Bushが想像した「memex」を現代的に実装したプロジェクト。GBrainは個人の思考、会話、経験を体系化し、AIエージェントが自動的に知識を拡張・検索可能にする仕組みを提供する。2,983スターを獲得し、マークダウンベースのシンプルな設計とスケーラブルなアーキテクチャの有効性が広く認識されている。
マークダウンベースの知識体系化
GBrainの最大の特徴は「Gitで管理されたマークダウンファイルが知識の全て」という設計。人物、企業、メディア、アイデアを統一フォーマットで記録し、ファイル単位の直感的な構造化を実現する。
実装例として、人物3,000人以上のプロファイル、13年分のカレンダーデータ21,000件以上、Apple Notes 5,800件以上、会議トランスクリプト280件以上が同じ検索インターフェースで運用可能。さらに300以上の独自アイデアと500以上のメディアページ（動画トランスクリプト、書籍、記事）を一元管理できる。
重要な設計思想：編集可能な「確定情報」と履歴を残す「追記タイムライン」を分離。 ページ上部には検証済みの事実を配置し、下部には時系列記録を追記型で積み上げる。過去の判断背景を失わず、現在の理解も正確に保つ二層構造により、長期的な知識管理の耐久性を確保する。
ソーシャルグラフの検索と関係管理
3,000人規模のプロファイルから複雑なクエリに応答。「PedroとDianaの両方を知っている人は誰か」「Series A以降に変わった点は何か」といった質問に、単純な集合演算とタイムライン差分で答える。参照修正や重複プロファイルの統合も半自動化可能。
取材相手、投資家、パートナーの接触履歴と専門分野を記録することで、既存データから「この2人を紹介すべきか」といった判断を導出。複雑なネットワーク構造を組織的に保つ仕組みになっている。
AIエージェントによる自動エンリッチメント
OpenClawやHermes Agentとの統合により、会話データ、メール、カレンダー、Apple Notesを自動入力。「ドリームサイクル」と呼ぶ夜間の自動処理では、日中の会話をスキャンして不足エンティティを補完し、参照を修正、メモリを統合する。朝起床時には脳が前夜より拡張された状態を実現する。
このサイクルは継続的な知識蓄積を生み出す。信号（会議、メール、ツイート、リンク）がエージェントに検出されると、既存情報を読み込んで文脈を持たせ、応答後に新情報を書き込む。各サイクルで知識が複合される構造。MCP層を経由することで、エージェント側の実装依存性を排除する設計を採用している。
スケーラビリティの実装戦略
初期段階：grep + Git管理 マークダウンファイルとシンプルなテキスト検索で開始可能。500ファイル程度まではこれで十分。Gitリポジトリとテキストエディタがあれば即座に立ち上げられる。
成長段階：Postgres + pgvector 1,000～10,000の長文ドキュメント規模に到達すると、grepは応答速度の課題に直面する。GBrainのCLI/MCPレイヤーでPostgres + pgvectorを活用し、キーワード検索とセマンティック検索を融合させた検索基盤に移行。インクリメンタル更新により、ファイル単体の変更で全インデックスを走査しない効率化を実現する。
設計上、ファイルベース→Postgres移行時も、マークダウン群が唯一の真実（source of truth）であり続ける点が重要。CLI/MCPはあくまで検索基盤に過ぎず、知識モデル本体はGitで保全される。段階的なスケーリングを可能にする柔軟性が組み込まれている。
アーキテクチャの構成
知識入力（会話、メール、メモ）
↓
マークダウン変換層
↓
ファイルベース保存（Git管理）
↓
┌─ ~500件 → grep検索
├─ 500～10,000件 → Postgres + pgvector
└─ MCP/CLI層を経由
↓
クエリ処理と検索結果
↑
外部エージェント（OpenClaw、Hermes Agent）
↓
ドリームサイクル（夜間自動処理）
↓
エンリッチメント（情報補完・統合）
知識モデル層はマークダウンで統一スキーマを保つ。検索インターフェース層は運用規模に応じて柔軟に選択可能。エージェント統合層はMCP層を経由して実装される。このレイヤー分離により、バックエンド技術の選択を後から変更でき、フロントエンドの安定性を維持できる。
実装開始のハードル
スキーマはGBRAIN_RECOMMENDED_SCHEMA.mdを参照。自動化スキルセットはGBRAIN_SKILLPACK.mdで確認できる。
知識集約的な業務（研究、ジャーナリズム、経営判断）、多数の関係者を追跡する環境、長期的な思考拡張を必要とする業務において、この仕組みの価値が顕在化する。規模拡大時のPostgres移行も段階的に判断可能。Gitリポジトリ→Postgres/pgvectorへの段階的移行パスが用意されているため、小規模から始めて成長に応じて技術スタックを進化させられる。
