オープンソースの長期記憶でエージェントの限界が変わる

Garry Tanが自分で使っているAI基盤「GBrain」を公開した。MarkdownファイルをPostgres/pgvectorでハイブリッド検索できるようにして、1万件以上のファイルからエージェントが過去の情報を引っ張ってこれる。OpenClawやHermesのようなエージェントは夜間の"dream cycle"で知識を積み上げていく設計になっていて、毎回の会話が単発で終わらない。

• 基本的な考え方: 記憶が残って検索できるエージェントは、セッションごとに文脈が消えるチャットボットより、使うほど生産性が上がる。
• 実装: Markdown + Postgres/pgvectorという軽いスタック。grep的な全文検索とベクトル検索を両方使える。
• ライセンス: MITで全部公開。ベンダーのブラックボックスに依存しない選択肢を作りたい、という意図。

このやり方だと、セッションが終わるとコンテキストが消えるという現状のチャットボットの制約を回避できる。エージェントが過去の作業履歴や判断、資料を自分で持ち続けられる。業務の継続性が必要な企業にとって、エージェントが"時間軸"を維持できることの価値は大きい。

ステートレスの限界とGBrainの違い

話題性より、実際に使えるかどうかが問題だ。会話のたびに記憶が消えるツールは、使いやすくてもワークフローの知識を溜められない。GBrainはOpenClawのマルチチャネル・ゲートウェイやHermesのスキル共有と組み合わせて、夜間バッチのような"dream cycle"で知識を自動で増やしていける。非構造テキストから関係性を把握する方向に進める。

• 向いている人: 自前でインフラを回す気のあるビルダー。一方、AnthropicやGoogleに乗っかる企業は、オープンスタックの実用例が増えるほど再検討を迫られる。
• スケーラビリティの問題: grepからPostgresへの書き込みで一貫性が崩れると、ナレッジがバラバラになる。検証・監査の運用設計が肝心。
• 市場への影響: OSSメモリ＋独自学習の組み合わせが、クローズドな製品の優位（UIの磨きや微調整）を削る可能性。xAIやMistralのようなプレイヤーは、OSSメモリと自社学習資産のハイブリッドで勝負できる。

| 立場 | 根拠 | 業界への影響 | 所見 | |------|------|-----------------|-----------| | オープンソース系ビルダー | GBrainのMarkdown→Postgres構成（MIT） | セッション単位から永続メモリ単位への移行 | 個人や少人数なら即効性あり。企業はガバナンス層が必要 | | プロプライエタリ大手 | 今のところ目立った反論なし | OSSの信頼性を理由に退ける向きも | Hermes等の検証で閉鎖的優位は相対的に低下 | | 実務開発者 | OpenClaw/Hermesと接続して夜間学習を実装 | カスタムエージェント導入が加速 | 先行者優位。投資家の認知は後追い | | 懐疑派 | Tanの過去のgstack事例 | KPIがないので持続性に疑問 | 本質は「蓄積する記憶がAPI課金を上回るか」 |

要点: GBrainはメモリ基盤という土台をOSSで誰でも使えるようにして、プロプライエタリとの差を詰める。ただし、チーム規模で「正しく書けて壊さない」運用はまだ課題。コンテキスト長という物理的制約に縛られる大手製品に対して、OSS側が「継続学習」で圧力をかける構図でもある。

• Tanの影響力: YCのリーチがあるので、スキル共有やエージェント機能のマーケットプレイス化への期待は短期で出てくるかもしれない。
• 導入のポイント: 検索精度（ベクトル＋文字列）、書き込み検証、スキーマ設計、アクセス制御、ロールバック戦略を最低限のSOPとして用意すること。

結論: GBrain型のリコールをワークフローに組み込んだビルダーは、「自分専用AI」を先に手に入れる。これを無視する企業は、知識の蓄積がないままベンダーロックインを深めるリスクがある。恩恵が大きいのは、UIの磨きよりエージェント主権を重視する研究者・開発者だ。

重要度: 中程度
カテゴリ: オープンソース、開発者ツール、技術解説

判断: 今は早い側に入るタイミング。自前インフラを回せるビルダーと研究開発チームが優位に立つ。トレーダーや受け身のホルダーより、実装と運用で学習曲線を先取りできる人がリターンを得る。