比較

Busabase と Zep：AI エージェントに使うならどちらか

Zep はコンテキスト層です。会話、ドキュメント、業務データを時系列ナレッジグラフに変え、エージェントのターンごとに必要なコンテキストを渡します。Busabase は、エージェントとチームが仕事そのもの（レコード、ドキュメント、スキル、アプリ）を置く場所です。エージェントの変更はすべて、人が読んで、レビューして、巻き戻せるチェンジリクエスト（Change Request）として届きます。

一方はエージェントに記憶を与え、もう一方はチームが確認し、責任を持てるレコードを与えます。両方を使うチームも多いはずです。このページでは、実際に持ち込まれる仕事ごとに比べます。

最終確認：2026 年 11 月 13 日。Zep の料金ページ、公式ドキュメント、公式ブログ、Graphiti リポジトリ、および Busabase の現行製品にもとづきます。

結論

いちばんの違い：すべての変更がチェンジリクエスト

データのためのプルリクエストだと考えてください。Busabase では、レコード、ドキュメント、スキルのファイル、スキーマ変更まで、あらゆる編集がチェンジリクエストです。変更不可能なコミットの連なりを持つブランチで、マージするとレコードが先に進み、何も上書きされません。

Zep は設計上、その逆です。会話、ドキュメント、JSON レコードを episode として送ると、LLM 駆動のパイプラインがエンティティと事実を抽出してグラフに書き込みます。新しい事実が古い事実と矛盾すると、古い事実は終了日付きで無効化され、残ります。グラフは以前何を信じていたかを覚えています。これは本物の履歴ですが、あくまでパイプラインによるデータの解釈で、何を記憶に入れるかの判断はあなたに残ります。Zep のドキュメントにも「プロンプトの構築、記憶の受け入れ、ツール権限、アクションの認可は、引き続きアプリケーションの責任です」とあります。（後述の Zep Agent Skills には、バージョンと任意の承認ステップがあります。）

• すべての書き込みに説明と差分。変更ごとに何をするのかが書かれ、フィールド単位の前後が表示されます。
• どのエージェントがやったか分かる。作成者と、経由したキーやツールがコミットに残ります。
• 取り消しは標準機能。レコード、ドキュメント、スキルはすべて履歴を保持し、どの変更も巻き戻せます。
• レビューは選べる。書き込み権限があれば即座に反映。エージェントに「提案のみ」のキーを渡せば、変更は受信箱で人の承認か差し戻しを待ちます。

違いをひと言でいえば、Zep が記録するのはグラフが学んだこと、Busabase が記録するのはチームが決めたことです。必要なら反映前にレビューでき、いずれにしても元に戻せます。

Busabase がエージェントとチームに用意するもの

記憶層が渡すのは、ひとつのエージェントのためのコンテキストです。以下は、エージェントの仕事のまわりでチームに必要なもので、Busabase ではワークスペースに最初から含まれています。

やりたいことで比べる

各行は、チームがこの 2 つの製品に持ち込む仕事です。機能のチェックリストではありません。Zep が適している場面は、そのまま書いています。

次に来るもの

以下の 3 つは現在開発中で、まだ利用できません。計画の参考になるよう掲載しており、リリース時にこのページを更新します。

パイプラインが維持するグラフか、チームが持つレコードか

Zep は記憶のために作られていて、その仕事は得意です。すべての事実に2 本のタイムラインがあります。現実の世界でその事実がいつ成り立っていたかと、Zep がいつそれを知ったかです。各事実は元の episode へのリンクを保つので、エージェントは「いま何が正しいか」だけでなく「去年の 3 月はどうだったか」にも答えられます。Zep はグラフをユーザー、アカウント、業務領域ごとに持ち、ターンごとに Context Block を組み立てて渡します。

ただし、グラフは導き出されたものです。送った内容をモデルが読み、そこにどんなエンティティと事実があるかを判断します。事実を書いているのはチームの人ではありません。記憶にとってはそれが正しいトレードオフです。サポートエージェントが 1 万件の会話から学んだことを、手で管理したい人はいません。けれども、チームが責任を持つべきもの、つまり返金ポリシー、価格表、顧客との契約条件、すべてのエージェントに見積もりの出し方を教えるスキルにとっては、正しくありません。

そうしたものは、人が開いて、全文を読み、直し、巻き戻せるレコードであるべきです。Busabase ではレコードそのものが正本です。エージェントが新しい割引ルールを提案すると、正確な前後差分を持つチェンジリクエストができます。チームのメンバーは受信箱やカンバンでそれを読み、マージし、翌週に間違いに気づけば取り消せます。履歴に残るのはモデルの推論ではなく、チームの決定です。

この違いを詳しく知りたい方は、「エージェントのメモリ vs ナレッジベース vs システムオブレコード」をお読みください。

併用する

2 つは重ならず、うまく組み合わさります。よくある分担はこうです。

1. チームは業務ルール、顧客レコード、エージェントが従うスキルを Busabase に置きます。人の変更もエージェントの変更も、すべてチェンジリクエストです。
2. 変更がマージされると、Webhook かエージェントが更新後のレコードを JSON の episode として Zep に送ります。グラフは新しい事実を学び、古い事実を無効にします。
3. 実行時、サポートや営業のエージェントはターンごとに、このユーザーとこのアカウントのコンテキストを Zep に求め、正本のレコードを丸ごと必要とするときは Busabase を読みます。
4. エージェントが生み出したもの（調査、下書き、更新した顧客メモ）は、チェンジリクエストとして Busabase に戻り、チームが読んで取り消せます。

どちらかがもう一方を置き換えるわけではありません。Zep は変化に追いつく記憶をエージェントに与え、Busabase はその記憶の元になるべきレコードをチームに与えます。

料金の概要

2026 年 11 月 13 日時点の公開価格です。Zep の価格は月払いで、料金ページには年払い割引もあります。最新情報は Busabase の料金と Zep の料金をご覧ください。

Zep のほうが向いている場面

• エージェントがセッションをまたいで人を覚えておく必要がある。先月ユーザーが何を言い、その後何が変わったかを知る必要がある長期のアシスタントやサポートエージェントは、まさに Zep の時系列グラフが想定している用途です。
• ターンごとのコンテキストを組み立ててほしい。Zep が事実を抽出し、エンティティを統合し、プロンプトにそのまま入れられる Context Block を低レイテンシで返します。検索は従量課金されません。
• 時系列グラフを自社のスタックに組み込みたい。Zep の内部で使われているフレームワーク Graphiti は Apache-2.0 のオープンソースで、Neo4j、FalkorDB、Amazon Neptune 上で動きます。

Busabase に現時点でできないことも明記します。ベクトルインデックスはなく、会話から事実を抽出してグラフを作ることもなく、ターンごとに呼び出す記憶サービスでもありません。リアルタイム購読もありません。公開したアプリのエンドユーザー認証は開発中（アプリユーザー）で、まだ利用できません。いまエージェントの記憶が必要なら、Zep を併用してください。

よくある質問

次のステップ

いま使っているエージェントを接続して、チームの知識をひとつ Busabase に置かせてみてください。業務ルール、顧客テーブル、スキルなど何でも構いません。そのあと何かを変更させ、届いたチェンジリクエストを読んでみてください。

関連記事： エージェントのメモリ vs ナレッジベース vs システムオブレコード · Busabase と Mem0 の比較 · AI エージェントのシステムオブレコード · Busabase と Supabase の比較 · チェンジリクエストの仕組み · 検索と grep

出典： Zep home page, Zep pricing, How Graph Creation Works (Zep docs), “Context graphs: two timelines for every fact” (Zep blog), Security & Compliance (Zep docs), “Introducing Zep Agent Skills” (Zep blog, 5 Nov 2026), Agent Skills learning and admission (Zep docs), Context MCP Server (Zep docs), Graphiti on GitHub, Zep's open-source strategy (Zep blog, 2 Apr 2025), Busabase pricing