「LLMのコンテキストが伸びれば記憶問題は消える」——そう言われながら、長く動くエージェントほど「先週の方針」「あの人が担当した件」を都合よく忘れる。BrainAPI（Lumen-Labs/brainapi2）は、この“忘れる”を構造で解こうとするAIメモリ層だ。テキストを渡すと、複数のAIエージェントが読み込み、事実を書き取り、イベント中心のナレッジグラフを自動で描く。そして質問に対しては、類似度の当てずっぽうではなく、グラフを辿った根拠つきの経路で答える。

AIメモリ／RAG全体の地図はピラー記事 RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ にまとめている。本記事はその中で「エージェントがナレッジグラフを組む記憶層」という一角を、mem0・cognee・supermemoryと並べて切り分ける。

公式デモ動画「BrainAPI — What if your AI could actually understand your data — not just search through it?」（出典: YouTube / Lumen Labs）
この記事のポイント
  • BrainAPIはテキストからナレッジグラフを自動構築するAIメモリ層。GitHubで★205、ライセンスはPolyForm Small Business（source-available・非OSI）、実装はPython
  • イベント中心のグラフが特徴。「誰が・何を・いつ・どの文脈で」を第一級のEventノードとして持ち、多段の質問に根拠となる経路（triples）付きで答える
  • mem0・cognee・supermemory・LightRAGと、中核データ構造・保存方式・バックエンド・ライセンスで比較し、用途別の選び方と導入手順まで一次ソースで整理する

30秒でわかるBrainAPIとナレッジグラフのAIメモリ層

BrainAPIは、Lumen Labsが開発する「AIの記憶層（AI memory layer）」だ。まず要点だけ押さえる。

・BrainAPIは生テキストからナレッジグラフを自動生成するエンジン。GitHubで★205・Fork 27、実装はPython 3.11+
・特徴はイベント中心（event-centric）。「AはBに関係する」ではなく「誰が・何を・いつ・どの文脈で」を出来事（Event）として構造化する
・入力したテキストは4体のエージェントが分担して読み、ノートを取り、グラフを描き、検証する（後述のScout/Observer/Architect/Janitor）
・回答は類似度の推測でなく、グラフを辿った経路（triples）を根拠として返す。ここが「説明可能な記憶」を掲げる理由
・REST API・MCPサーバー・TUI・Web Console・プラグインを備え、mem0/cognee/supermemory/LightRAGと並ぶAIメモリ系ツールの一角（ただしライセンスはOSSでなくsource-available。後述）

BrainAPIの基本数値：★205、抽出エージェント4体、Fork 27、リリース30本（すべて-dev）
BrainAPIの実体を数字で。更新は活発だが全リリースが -dev、SDKは pre-1.0 と明記される（出典: GitHub API / 公式README・2026-07時点）

LLMのコンテキスト長がいくら伸びても、「アプリやエージェントがユーザーと出来事を覚えている」状態は別途設計が要る。BrainAPIはその記憶を、時間軸を持つグラフとして外出しするための選択肢の一つだ。以下、仕組み・構造・導入・比較の順に、公式リポジトリとドキュメントの一次情報で読み解く。

なぜ今「AIメモリ」なのか｜RAGとナレッジグラフの役割分担

ここ1〜2年で「AIメモリ（AI memory／agent memory）」が独立したカテゴリとして立ち上がってきた。背景にはLLM単体では解けない3つの限界がある。

第一に、コンテキストウィンドウの限界だ。長文脈モデルが増えても、毎回すべての履歴を詰め込むのはコストもレイテンシも跳ね上がる。長く走るエージェントほど、必要な事実だけを選んで渡す「記憶の出し入れ」が要る。

第二に、ステートフルなエージェントへの流れだ。一問一答のチャットボットと違い、何日も走り続けるエージェントは「自分が何を知っていて、相手が何を好むか」を跨セッションで保持しないと一貫性が崩れる。

第三に、RAGとの役割分担だ。RAGは「ドキュメントを検索して文脈に足す」仕組みで、静的な知識ベースの参照に向く。一方でメモリ層は「ユーザーや出来事について、矛盾や更新を扱いながら事実を育てる」点が本質的に違う。RAG自体もグラフやエージェントを取り込む方向へ進んでおり、その流れは RAGの進化｜Naive・Advanced・Graph・Agentic RAGの仕組みと選び方2026 に詳しいが、メモリ層はそれとは別軸で立ち上がってきた。両者は排他ではなくハイブリッドに使うのが2026年の主流だ。

BrainAPIの立ち位置
mem0・supermemoryが「事実をベクトルで持つ」記憶層だとすれば、BrainAPIやcogneeは「事実をグラフで持つ」記憶層に寄っている。グラフ側は多段の関係を辿れる反面、グラフDBという追加基盤が要る。どちらが上位という話ではなく、問いの形（単純な想起か、関係を跨ぐ推論か）で選ぶ。

具体例で考えると分かりやすい。「田中さんはPythonよりGoを好む」「先週の設計方針はAからBに変わった」——こうした、時間とともに増減・更新される事実は、文書を意味検索するだけのRAGでは扱いにくい。誰かの好みや、いつ何が決まったかは、どこかのPDFに固定文として書いてあるわけではないからだ。メモリ層はこの「動く事実」を専門に扱う。BrainAPIはさらに、その事実を出来事の連なりとしてグラフに刻むことで、「なぜそう言えるのか」を経路で示せるようにしている。

BrainAPIが際立つのは、そのグラフの組み方だ。多くのナレッジグラフは「エンティティAとエンティティBを辺でつなぐ」だけで、行為や出来事はフラットな辺に潰れてしまう。BrainAPIは行為そのものをノードに昇格させる。次章でその中身を見る。

BrainAPIの仕組み｜4体のエージェントがナレッジグラフを描く

BrainAPIに送ったテキストは、役割の異なるエージェント群（agent swarm）によって読み解かれる。各エージェントの仕事は狭く限定され、それがパイプライン全体の信頼性と監査可能性を担保する。公式READMEが挙げる4つの役割は次のとおりだ。

・🔍 Scout：テキストを読み、含まれるすべてのエンティティ（人・物・出来事・数量）を抽出する
・📝 Observations Agent：並行して、既知の文脈をふまえながらテキスト中の事実についてのノート（観察）を書き取る
・🏛️ Architect：Scoutが抜き出したエンティティを使い、テキストを読み直してイベント中心の関係（主体 —関係→ 出来事 —関係→ 対象）を組み立てる
・🧹 Janitor：Architectの結果を検証する。関係は正しいか、同じエンティティや同じ事実（triplet）が既にグラフに無いか。誤りがあれば具体的な修正指示をArchitectに戻し、綺麗になるまでループする

この「作る→検証して差し戻す→直す」の自己修正ループが、単発抽出との一番の違いだ。抽出を一度きりで終わらせず、Janitorが重複や誤りを潰してからグラフに追記する。

flowchart TD Text["生テキスト
(文書・会話・イベント)"] --> Scout["🔍 Scout
全エンティティを抽出"] Text --> Observer["📝 Observations Agent
文脈をふまえ
事実のノートを書く"] Scout -->|エンティティ| Architect["🏛️ Architect
イベント中心の
関係を構築"] Architect -->|関係＋エンティティ| Janitor["🧹 Janitor
正しさ検証＋
重複チェック"] Janitor -->|"誤り＋修正指示"| Architect Janitor -->|"OK"| Graph["📊 ナレッジグラフ
(追記専用)"] Observer --> Graph

なぜここまで役割を分けるのか。1体のLLMに「抽出も関係付けも検証も」まとめて任せると、どこで間違えたかが追えず、出力も安定しない。狭い仕事に割ると、各段の入出力が明確になり、Janitorのような検証専任を挟める。ScoutとObservations Agentが並行して走るのも、エンティティの網羅（Scout）と文脈をふまえた事実記述（Observer）という別種の作業を分離するためだ。抽出処理自体はCeleryワーカー上で非同期に走るので、ingestは投げてすぐ返り、グラフの構築はバックグラウンドで進む。大量投入時に詰まりにくい構成になっている。

パイプラインには2つのモードがある。デフォルトのaccurateは上の全工程（Scoutの全抽出・Observationsのノート・Janitorの検証と重複排除）を回す。lightweightは重要なエンティティだけを抜き、重い検証を省く高速・低コスト版で、--pipeline lightweightまたは.envのPIPELINE_MODEで切り替える。用途に応じて精度とコストを振り分けられる設計だ。まずlightweightで全体像を掴み、精度が要る本番用ブレイン（brain_id）だけaccurateに上げる、といった振り分けもできる。

BrainAPIのパイプライン：生テキスト→エージェント群→イベント中心グラフ→根拠つき回答
生テキストを入れると、エージェント群が読み解き、追記専用のグラフに整え、根拠経路つきで回答する（出典: 公式README）

エージェントが使うLLMは差し替え可能だ。.env.exampleでは小型・大型のLLMを分けて指定でき、Azure OpenAI（gpt-4o/4o-mini）、Google Vertex（gemini系）、AWS Bedrock（Claude系）、OpenAIに対応する。埋め込みはtext-embedding-3-large等のクラウドモデルのほか、e5-smallや多言語対応のparaphrase-multilingual-MiniLMといったローカルモデルも選べる。付属のbrainapi doctorはPython・Docker・Ollama・クラウド認証情報の状態を点検するため、ローカルLLM（Ollama）を組み合わせる運用も想定されている。

イベント中心グラフと追記専用設計｜mem0・LightRAGとの構造的な違い

BrainAPI最大の設計思想が、イベント中心（event-centric）のグラフだ。公式が「Triangle of Attribution（帰属の三角形）」と呼ぶこの構造では、あらゆる行為を中央のEventハブ（行為ノード）として表し、そこに3つの点——Actor（主体）・Target（対象）・Context（文脈）——を接続する。

例えば「EmilyがロンドンでAI Ethics Meetupを主催した」という一文は、次のように分解される。

graph TD Actor["Emily
(Actor / 主体)"] -->|":MADE"| Event["Organizing Event
(Eventハブ / 行為)"] Event -->|":TARGETED"| Target["AI Ethics Meetup
(Target / 対象)"] Event -->|":OCCURRED_WITHIN"| Context["London
(Context / 文脈)"]

ポイントは、行為（主催する）をフラットな辺ではなく独立したノードにしていることだ。これにより「2024年第1四半期にロンドンでAIイベントを主催したのは誰か」のような、明示的に教えていない多段の問いにも、グラフを辿って答えられる。回答には辿った経路（triples）が添えられ、なぜその答えになったかが可視化される。

フラットなA-B関係グラフとBrainAPIのイベント中心グラフの比較
行為をノード化するイベント中心グラフが、多段・追跡可能な回答の土台になる（出典: 公式README「Triangle of Attribution」）

もう一つの柱が追記専用（append-only）の設計だ。BrainAPIはグラフから何も削除しない。新しい行為はそのつど新しいイベントノードとして追記され、過去を上書きしない。これにより履歴が丸ごと残り、「事実が時間とともにどう変わったか」を再構成できる。多くのメモリ層が矛盾時に事実を更新・上書きするのに対し、BrainAPIは来歴（provenance）の痕跡を常に残す方針を採る。この差は、コンプライアンスや調査のように「いつ何が分かっていたか」が重要な用途で効いてくる。

追記専用は「じゃあ矛盾や訂正はどう扱うのか」という疑問を生む。BrainAPIの答えは「古い事実を消して上書きするのではなく、新しい出来事として追記し、時系列で並べる」だ。「先週はAが担当、今週はBに交代」という変化も、両方のイベントノードが残るため、どの時点の問いにも当時の状態で答えられる。事実を潰さないぶんグラフは膨らむが、来歴を失わないという設計上のトレードオフを選んでいる。

グラフの引き方も/retrieve/contextだけではない。特定エンティティの存在と周辺を返す/retrieve/entity/status、似たものを返す/retrieve/entity/synergiesに加え、多段の経路を辿る/retrieve/hops、近傍ノードを返す/retrieve/entities/neighbors、元テキスト片を返す/retrieve/text-chunksなどが用意される。用途に応じて「意味検索」「レコメンド」「多段トレース」を使い分けられるのが、グラフを持つ強みだ。

グラフを軸にする点は、rag系の LightRAG｜知識グラフ×デュアルレベル検索でRAGの精度と網羅性を高める仕組み と発想が近い。ただしLightRAGが文書検索の網羅性を知識グラフで底上げする「RAG強化」寄りなのに対し、BrainAPIは行為と時間を第一級に扱う「メモリ寄り」だ。同じ“グラフ×検索”でも力点が違う。

BrainAPIの導入と使い方｜TUI・Docker・REST APIで動かす

導入経路は主に3つある。いずれも公式が案内する手順で、ここでは「読者が実際に叩くコマンド」だけを載せる。

最短は専用のTUI（brainapi）だ。リポジトリのクローン、Python環境の用意、対話的な初期設定、バックエンドの起動までを一括で面倒みてくれる。

npm install -g brainapi-tui
brainapi init     # クローン・依存導入・セットアップウィザード（"Use default settings"を選ぶ）
brainapi start    # バックエンド + API + MCP + ワーカー + Console を起動

起動後は API が http://localhost:8000、Web Console が http://localhost:8000/console、MCP サーバーが http://localhost:8001/mcp で待ち受ける。Console にはセットアップ時に生成されるBRAINPAT_TOKENでログインする。

リポジトリから直接 Docker で上げることもできる。このdocker composeが、グラフ（Neo4j）・ベクトル（Milvus）・キュー（Redis）・文書（MongoDB）といったバックエンドをまとめて起動する。

git clone https://github.com/lumen-labs/brainapi2.git && cd brainapi2
docker compose -f example-docker-compose.yaml up -d

データの投入と検索はREST APIで行う。まず1件を投入する（ingest）。

curl -X POST http://localhost:8000/ingest/ \
  -H "Authorization: Bearer $BRAINPAT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"data": {"data_type": "text", "text_data": "Emily organized the AI Ethics Meetup in London on 2024-03-08."}, "brain_id": "default"}'

投入した知識に対して、文脈（根拠経路つき）を引く。

curl -X POST http://localhost:8000/retrieve/context \
  -H "Authorization: Bearer $BRAINPAT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"text": "Who organized AI events in London in March 2024?", "brain_id": "default"}'
# → text_context（答え） + triples（辿ったグラフ経路） + historical_context

検索系のエンドポイントは用途別に用意されている。主要な3つを押さえておけばよい。

・/retrieve/context：あるテキストに関連する情報（該当するグラフのtriplesと履歴的文脈）を返す
・/retrieve/entity/status：特定エンティティの存在確認。ノード・関係・観察をまとめて返す
・/retrieve/entity/synergies：あるものに強く結びつく「似たもの」を返す。実質的にグラフ上のレコメンド

BrainAPIセルフホストの構成：App層、Neo4j、Milvus、Redis+MongoDB
セルフホストはアプリ＋4系統のバックエンドが前提。単一バイナリで完結する軽量ツールではない（出典: example-docker-compose.yaml / .env.example）
導入前に知っておきたい“重さ”
BrainAPIのセルフホストは、Neo4j 5・Milvus（etcd/MinIO込み）・Redis・MongoDBという複数のバックエンドを伴う。検証はdocker compose一発で始められるが、本番ではNeo4jのメモリ設定や各サービスの運用が別途要る。「pip installだけの軽量ライブラリ」を期待すると想定と違うので、まずローカルで挙動を確かめてから規模を判断したい。

エージェント連携はMCPで行う。MCPサーバーはポート8001（http://localhost:8001/mcp）で別プロセスとして動き、Claude Desktopなどのランタイムから接続できる。プラグイン機構も特徴で、REST経路の追加・エージェントのプロンプト差し替え・MCPツールの登録・Celeryタスクの同梱までを、コア本体をフォークせずに行える。公式は共有用のプラグインレジストリも用意しており、brainapi plugins install @community/crm-entitiesで導入、brainapi plugins publishで公開できる。これにより「汎用の理解エンジン」を、CRM・法務・医療といった自社オントロジーに寄せた抽出器へ作り変えられる。こうしたMCP対応とプラグインにより、どのLLMランタイムからでもブレイン（ナレッジグラフ）を読み書きできるのが、エージェント基盤としての強みだ。

運用面では、TUIに管理コマンドがそろっている。設定を一部だけ変えたいときはbrainapi configでウィザードを再度開き、環境の健全性はbrainapi doctor（Python・Docker・Ollama・クラウド認証を点検）で確認、更新はbrainapi update（git pull＋依存の再インストール）で行う。TUIは~/.brainapi/配下にソース・venv・.env・state.jsonを置き、既存のgitクローンとは分離される。BRAINAPI_HOMEなどの環境変数で場所やブランチを上書きできるため、複数バージョンを並行検証しやすい。

ローカルで完結するAIメモリという発想は、同じrag系の Wax：Apple Silicon最適化のシングルファイルAIメモリレイヤー、サブミリ秒RAG対応 とも通じる。ただしWaxが単一ファイルの軽さを取るのに対し、BrainAPIはグラフDBやベクトルDBを積んで多段推論と来歴に振っている。「軽く速く」か「重くても構造と根拠」か——同じAIメモリでも設計の重心が対照的だ。

mem0・cognee・supermemory・LightRAGと比較｜AIメモリOSSの選び方

AIメモリ／グラフ系のツール（多くはOSS）は2024〜2026年で一気に増えた。BrainAPIを主要どころと並べ、中核データ構造・グラフ構築・更新方式・ライセンス・向く用途で整理する。優劣ではなく「担当領域の違い」として読んでほしい。

ツール 中核データ構造 グラフの作り方 更新方式 ライセンス 向く用途
BrainAPI イベント中心ナレッジグラフ エージェント群が構築＋Janitorが検証 追記専用（削除しない） PolyForm Small Business（source-available） 多段推論・来歴重視の記憶
mem0 事実（fact）＋ベクトル 会話から事実を抽出 更新・統合あり Apache-2.0 汎用の会話メモリを最小コードで
cognee ナレッジグラフ＋ベクトル ECLパイプラインで構築 パイプライン再構築 Apache-2.0 グラフ×ベクトルのメモリ基盤
supermemory 事実＋ベクトル（ハイブリッド検索） 抽出＋コネクタ同期 更新あり MIT アプリ後付けのMemory API
LightRAG 知識グラフ＋デュアルレベル検索 文書からグラフ抽出 追加・再インデックス MIT RAGの網羅性・精度の底上げ

※ ライセンス・構造は各公式リポジトリ／ドキュメントの表記に基づく（2026-07時点）。競合各ツールの詳細は個別記事を参照。cogneeのグラフ基盤はNeo4j/FalkorDB/KuzuDB/pgvector等が選べる。

この表で最も実務に効く違いがライセンスだ。mem0・cogneeはApache-2.0、supermemory・LightRAGはMITと、いずれもOSI承認の許容的ライセンスなのに対し、BrainAPIだけがPolyForm Small Business License 1.0.0という“ソース公開（source-available）”のライセンスを採る。これは優劣ではなく前提条件の違いで、組織規模によって無償で使える範囲が変わる（詳細は次章）。

選び方の目安は次のとおりだ。

・とにかく最小コードで会話メモリを足したい／Python中心 → mem0が無難
・アプリにユーザーの記憶を後付けしたい／低レイテンシのマネージドAPIが欲しい → supermemory
・文書検索（RAG）の網羅性をグラフで底上げしたい → LightRAG
・グラフ×ベクトルのメモリ基盤を自前で持ちたい → cognee
・「誰が・いつ・何を」を跨ぐ多段の問いに、根拠経路つきで答えさせたい／来歴を残したい → BrainAPIが刺さる

検証段階なら、同じデータを2〜3系統に入れて「抽出されたエンティティ・関係」と「検索の根拠の出方」を見比べるのが早い。特にBrainAPIはtriplesが返るので、根拠の質を目視で評価しやすい。

BrainAPIを使うべきケースと注意点｜pre-1.0の成熟度とライセンス

公式が挙げる主なユースケースは、エージェントの長期記憶、行動経路に基づくレコメンド、多段推論のセマンティック検索、組織内の専門家・知見マッピング、定性データからのBI、そして人・出来事・文書・時刻を結ぶ調査／コンプライアンスだ。READMEは「構造化された知識を雑多なソースから得たい」「説明可能な長期記憶が要る」「経路を辿れる多段クエリが要る」ときに向く、と整理する。逆に「データが既に固定スキーマに収まっている」「1本のSQLで解ける」ならオーバースペックだ。

一方で、採用判断に直結する注意点が2つある。

第一に成熟度だ。2025年10月公開で更新は活発だが、30本のリリースはすべて-devタグ、Python/Node.jsのSDKも公式にpre-release（v1.0前）と明記されている。READMEは「本番ではv1.0が出るまでREST APIを直接使う」ことを推奨している。したがってSDKに深く依存した本番実装は破壊的変更のリスクを見込む必要がある。RESTとMCPで薄く繋ぐのが安全だ。

第二にライセンスだ。BrainAPIはPolyForm Small Business License 1.0.0で、これはOSI承認のオープンソースではない。無償で使えるのは、従業員・業務委託が100名未満、かつ年間売上が約100万USD未満（2019年CPI基準）の小規模事業者の範囲で、その中では自己ホストやクローズド製品への組み込みまで認められる（コピーレフトなし）。この規模・範囲を超える場合は別途商用ライセンスが必要で、公式（[email protected]）への問い合わせが案内されている。mem0（Apache-2.0）やsupermemory（MIT）とはここが決定的に違うため、組織規模が大きい場合は導入前に必ずLICENSE本文と自社の要件を突き合わせてほしい。

まとめ：BrainAPIはどこを担当する道具か
「事実をベクトルで持つ」記憶層が主流の中で、BrainAPIは「行為と時間をグラフで持ち、根拠経路つきで答える」方向に振り切ったAIメモリ層だ。多段推論・来歴・説明可能性が要るなら有力で、逆に単純な想起や軽量導入が目的なら他の選択肢が向く。まずはローカルで実データを入れ、抽出と根拠の質を自分の目で確かめるところから始めたい。

参照ソース

・Lumen-Labs/brainapi2 — GitHub リポジトリ（README・LICENSE・example-docker-compose.yaml・.env.example）
・BrainAPI 公式ドキュメント（v2 / REST API リファレンス）
・BrainAPI 公式デモ動画（YouTube / Lumen Labs）
・PolyForm Small Business License 1.0.0（ライセンス本文）