最近、会社でAIエージェントをどう使えるかを考えていると、RAGやtool callingだけでは少し足りないと感じることがあります。会社の仕事では、前回なぜそう判断したのか、どの顧客文脈があったのか、その記憶を誰が見てもよいのかが重要になるからです。
そこで、Context GraphとNeo4j Agent Memoryを説明する動画が目に入りました。すぐに導入すると決めたわけではありません。まだ会社で使える方法を考えながら、いろいろな例を探している段階です。ただ、コンテキストグラフとエージェントメモリがなぜ一緒に語られるのかは整理しておきたいと思いました。
関連記事
- Ponytail と AI コーディング設定：良い哲学を会社テンプレートへ移植する
- WaterCrawl vs Firecrawl：LLM向けクローリングとサイドプロジェクトでの使い分け
- Claude Code /deep-research の Verify が API レート制限に当たる理由
要約
- コンテキストグラフは、すべてを保存する仕組みというより、現在のユーザー・仕事・状況に合う文脈を選ぶための構造として理解しました。
- エージェントメモリは、短期メモリ、長期メモリ、推論メモリに分けると会社での使い道を考えやすくなります。
- 社内技術サポート、顧客対応、障害対応、オンボーディング、個人業務アシスタントで可能性がありそうです。
- 最近のブログ、コミュニティ、GitHub issueを見ると、ユーザー分離、エンティティ品質、遅い抽出、空のrecall、出典管理が重要です。
目次
なぜコンテキストグラフを気にし始めたのか
AIエージェントの話では、memoryという言葉がよく出てきます。最初は長い会話履歴のように見えますが、会社の仕事では単に会話を長く保存するだけでは足りません。
顧客障害をAIが覚える場合、「A社で先月障害があった」だけではあまり役に立ちません。どのシステムだったのか、誰が暫定対応を承認したのか、なぜ正式対応を後回しにしたのか、どの情報は特定チームだけが見られるのかまでつながる必要があります。
だからこそコンテキストグラフが面白く見えました。すべての情報をLLMに渡すのではなく、今の仕事に必要なsubgraphを選ぶ考え方だからです。
グラフ、知識グラフ、コンテキストグラフの違い
| 区分 | 私の理解 | AIエージェントでの役割 |
|---|---|---|
| グラフ | ノードと関係で情報を表す構造 | 人、システム、課題、文書のつながりを表す |
| 知識グラフ | 概念、事実、関係を構造化した知識 | 社内知識、製品、ポリシー、顧客情報をつなぐ |
| コンテキストグラフ | 現在の仕事に必要な文脈を選ぶためのグラフ | LLMへ必要なsubgraphだけを渡す |
エージェントメモリは何を覚えるべきか
1. 短期メモリ
現在の会話や作業状態です。メッセージ順序、直前に選んだオプション、今話していたサーバー、 temporaryな状態などです。
2. 長期メモリ
ユーザーの好み、繰り返し出てくる事実、顧客特性、システム間の関係など、セッションを越えて残す情報です。ただし会社では権限と削除ルールが特に重要になります。
3. 推論メモリ
個人的に一番面白い層です。結論だけでなく、どのツールを呼び出し、どの根拠を見て、なぜその答えに至ったのかを残す記憶です。
会社で使うならどこに合うか
- 社内技術サポート: 過去の問い合わせ、構成、担当チーム、解決履歴をつなぐ。
- 顧客対応メモリ: 顧客ごとの環境や過去の例外対応を失わない。
- 障害対応と振り返り: 症状、ログ、対応、再発防止をグラフでつなぐ。
- 社内知識管理とオンボーディング: 文書、コード、ポリシー、担当者をつなぐ。
- 個人化された業務アシスタント: 会社ポリシー内で繰り返し業務を覚える。
最近のブログとコミュニティで見える現実的な悩み
この記事を補強するとき、動画と公式文書だけには頼りませんでした。最近のブログ、コミュニティ投稿、GitHub issueも確認しました。そこで見えたのは、単に「AIがもっと記憶できればよい」ではなく、記憶の更新、ユーザー分離、空のrecall、ローカルLLMやカスタムAPIとの連携をどう扱うかという悩みでした。
- Graphiti / PyTorch Korea の流れ: 繰り返し出てくるのはtemporal context graphです。従来のRAGのように文書を一度インデックスして終わるのではなく、会話、ビジネスデータ、文書からエンティティと関係を更新し、古い事実を現在の事実として扱わない方向です。
- Mem0 の流れ: 方向性は少し違います。チームが直接グラフを設計するより、AIアプリケーションがユーザーの好みや繰り返し出る文脈を覚えるメモリレイヤーとして扱います。
- GitHub issue で見える現実問題: Neo4j Agent Memoryにはユーザーごとの長期記憶の分離や関係抽出品質の問題があります。Graphitiには大きなコンテンツの抽出が遅い問題や、ローカルLLM・カスタムAPIエンドポイント連携の問題があります。Cogneeには処理遅延による空のrecallをどう見せるかの議論があります。
つまり、格好いいグラフDBを付ければ終わりではありません。 実際のチェックポイントは、記憶の分離、エンティティ統合品質、抽出遅延、空のrecall、ローカルモデル連携、監査可能な出典です。
考えてみて感じた利点
- 同じ文脈を何度も説明しなくてよい。
- 関係と出典を一緒に見られる。
- 推論過程を後から確認しやすくなる。
導入前に注意したいこと
- 何を記憶するかを決める。 すべての会話を保存すると便利そうですが、リスクも増えます。
- 権限モデルを先に設計する。
- エンティティ抽出品質を見る。
- 削除と監査を用意する。
- 運用コストを見積もる。
さらに見てみたい例
- Neo4j Agent Memory
- Create Context Graph
- Graphiti / Zep
- Mem0
- LangGraph Memory
- Cognee
結論
コンテキストグラフとエージェントメモリは、AIに長い会話を覚えさせるだけの技術ではありません。会社でAIを使うなら、何を記憶し、どの関係を保ち、誰が見られて、なぜその答えに至ったのかを残す仕組みが必要になります。
私はまだすぐに導入すると決めたわけではありません。ただ、RAGとtool callingの次に考えるテーマとしてはかなり説得力があります。
参考文献
- AIのための知識グラフ、Context Graphとエージェントメモリ
- Neo4j Labs Agent Memory
- Neo4j Labs Create Context Graph
- Neo4j Developer Blog: Graphiti knowledge graph memory
- PyTorch Korea: Graphiti discussion
- Mem0 Platform overview
- Neo4j Agent Memory issue: user isolation
- Graphiti issue: slow extraction
- Cognee issue: empty recall and processing lag
- 韓国語の元記事
この記事は韓国語の元記事をもとにローカライズしました。韓国語版もぜひかわいがってください。