Graphitiは、AIエージェント向けに「時間軸を持つ知識グラフ（Context Graph）」を構築・検索するためのオープンソースのフレームワークである。開発元は米国のZep。一般的なRAGがドキュメントの断片をベクトル検索で引き当てるのに対し、Graphitiは会話やデータから人物・組織・出来事といったエンティティと、その間の関係を抽出してグラフに蓄積する。特徴的なのは、事実（ファクト）ひとつひとつに「いつからいつまで有効だったか」という有効期間を持たせる点で、情報が変わったときも古い事実を削除せず「無効化」として記録する。2024年8月の公開以降、GitHubで3万を超えるスターを集め、Apache-2.0ライセンスで開発が続いている。
主な特徴
- 時間軸を持つファクト管理: 各事実に有効期間を持たせ、情報が更新されたときは上書き削除ではなく旧事実を無効化する。「以前は何が正しかったか」「いつ変わったか」を後から辿れるため、エージェントの記憶が矛盾しにくい
- エピソード単位の出典追跡: 取り込んだ会話やドキュメントを「エピソード」として保持し、グラフ上のエンティティ・関係がどの入力から生まれたかまで遡れる。回答の根拠を提示したい業務用途で効く
- ハイブリッド検索: 意味的な埋め込み検索、キーワード検索（BM25）、グラフ探索を組み合わせて文脈を取得する。ベクトル検索単独よりも取りこぼしが少なく、低遅延を狙った設計になっている
- 増分更新（バッチ再計算が不要）: 新しいデータが来るたびにグラフ全体を作り直す必要がなく、リアルタイムに追記できる。常時稼働するエージェントの記憶層に向く
- オントロジーの指定と学習: Pydanticモデルで独自のエンティティ型・関係型を定義でき、指定しない場合はデータから自然に浮かび上がったパターンを使う
- 幅広いバックエンドとLLMに対応: グラフDBはNeo4j、FalkorDB、Amazon Neptuneなどに対応。LLMはOpenAI（既定）のほかAnthropic、Google Gemini、Groq、Azure OpenAI、OpenAI互換エンドポイント（Ollama等のローカルモデルを含む）が使える
- MCPサーバーとREST API: 公式のMCPサーバーが用意されており、Claudeなどのクライアントからグラフへの記録・検索を直接扱える。FastAPI製のRESTサービスも同梱される
料金
| 対象 | 料金 | 内容 |
|---|---|---|
| Graphiti（OSS本体） | $0 | Apache-2.0ライセンス。自前環境で自由に利用できる |
| 実行にかかる外部コスト | 従量 | LLM APIの利用料、グラフDB（Neo4j / FalkorDB等）の運用費が別途必要 |
| Zep（マネージド版・参考） | Free $0 〜 | 同社のクラウドサービス。有料プランはFlex以上、Enterpriseは要問い合わせ |
料金は2026年8月時点の情報です。最新の料金は公式サイトをご確認ください。
Graphiti自体はオープンソースであり、ライセンス料はかからない。実運用のコストはLLMの呼び出し料金とグラフDBのホスティングに集約される。自分で運用したくない場合は、Graphitiをコアエンジンとして採用しているZepのマネージドサービスを使う選択肢もある。
メリット・デメリット
✅ メリット
- 事実の変化を「履歴として」保持できるため、長期間動かすエージェントでも記憶が古びにくい
- どの入力から生まれた知識かを辿れるので、回答の根拠提示や監査に強い
- ベクトル検索・キーワード検索・グラフ探索の併用で、単純なRAGより文脈の取りこぼしが減る
- Apache-2.0のオープンソースで、ローカル実行も含め自分の環境に閉じて動かせる
- 公式MCPサーバー経由で、Claudeなどのクライアントからそのまま記憶層として使える
⚠️ デメリット
- グラフDBの用意と運用が前提となり、ベクトルDBだけの構成より導入の手間が大きい
- データ取り込み時にLLMでエンティティ・関係を抽出するため、大量投入ではAPIコストと処理時間がかさむ
- 知識グラフやオントロジー設計の考え方に慣れが必要で、学習コストは低くない
- 精度は抽出に使うLLMの性能に左右され、モデル選定とプロンプト調整の余地が残る
- 開発の動きが速く、バージョン間の仕様変更に追随する必要がある
類似サービスとの比較
| 比較項目 | Graphiti | Mem0 | Zep（マネージド） | Microsoft GraphRAG |
|---|---|---|---|---|
| 提供形態 | OSSフレームワーク | OSS + クラウド | クラウドサービス | OSSライブラリ |
| データ構造 | 時間軸付き知識グラフ | ベクトル + グラフの記憶層 | Graphitiベースの記憶層 | 知識グラフ + コミュニティ要約 |
| 更新方式 | 増分更新（リアルタイム） | 増分更新 | 増分更新 | バッチ処理中心 |
| 時間軸の扱い | 有効期間つきで履歴を保持 | 限定的 | 有効期間つきで履歴を保持 | 想定外 |
| 主な用途 | エージェントの長期記憶 | エージェントの記憶 | 記憶層のフルマネージド運用 | 大規模文書の分析・要約 |
| 運用の手間 | 自前（グラフDB必要） | 自前またはクラウド | ほぼ不要 | 自前（バッチ実行） |
こんな人におすすめ
- 会話やイベントの積み重ねを覚えておく必要がある、長期稼働のAIエージェントを作りたい開発者
- 「その情報はいつ時点のものか」を扱う必要がある業務システム（顧客情報、契約状態、組織の変遷など）を扱う人
- 単純なベクトル検索のRAGで文脈の取りこぼしや古い情報の混入に困っている人
- 回答の根拠を出典まで遡って示す必要があるチーム
- データを外部に出さず、ローカルのグラフDBとローカルLLMで記憶層を完結させたい人
まとめ
Graphitiは、AIエージェントの「記憶」をベクトル検索ではなく時間軸を持つ知識グラフとして設計し直したフレームワークである。事実に有効期間を持たせ、変化を削除ではなく無効化として記録する仕組みは、長く動かすほど効いてくる。一方で、グラフDBの運用と取り込み時のLLMコストという実務上の負担があり、短期的なQAボットのような用途には過剰になりうる。まずはローカルにグラフDBを立て、公式のクイックスタートとMCPサーバーで小さく試し、記憶の履歴が本当に必要かを見極めてから本格導入するとよい。