【ITニュース解説】Zep charges per 350 bytes, so the same 15,000 episodes can land on a $125 or a $375 plan

Zepというサービスは、アプリケーションが生成するデータの断片である「エピソード」の管理を提供する。システムエンジニアを目指す皆さんにとって、クラウドサービスの料金モデルや、システム設計におけるデータ管理の重要性を理解する上で役立つ情報となるだろう。

まず、Zepというサービスについて理解しよう。Zepは、ユーザーからのメッセージやシステムログ、AIエージェントの対話履歴など、特定のイベントや情報をエピソードとして管理する。Zepの大きな特徴は、このエピソードの数ではなく、エピソードの**サイズ（データ量）**に基づいて課金される点にある。具体的には、最初の350バイトまでが1クレジットとして計算され、それ以降は350バイト増えるごとに、またはその一部でもさらに1クレジットが加算される仕組みだ。これは、例えば300バイトのエピソードでも1クレジット、700バイトのエピソードなら2クレジットとして計算されることを意味する。credits = ceil(bytes / 350)という式でこの計算方法が示されている。ceilは「切り上げ」を意味し、小数点以下を切り上げて整数にする関数である。

この課金体系が実際にどのような影響をもたらすかを見てみよう。月に15,000件のエピソードを処理するという同じ作業量でも、エピソードの平均サイズが変わるだけで月額料金が大きく変動する例が示されている。例えば、エピソードが300バイトなら月額125ドルのプランで収まるが、エピソードが3,500バイトに増えると、同じ15,000件のエピソードでも月額375ドル、つまり3倍の料金になる可能性がある。書き込み回数は同じなのに、データサイズが増えるだけでコストが劇的に上がるという点が重要だ。これは、開発者がシステムを設計する際に、単に処理回数だけでなく、データのサイズまで考慮する必要があることを示唆している。

しかし、Zepには利点もある。Zepはデータの「取得（読み出し）」、「ストレージ（保存）」、「スレッド（処理単位）」、「ユーザー（アカウント数）」、そして「グラフストレージ」といった要素に対しては課金しない。これは、もしあなたの製品がデータを頻繁に読み出すタイプであったり、少量のデータを書き込む頻度が高いが、保存期間が長くなりがちな場合に、コストパフォーマンスが良い可能性があることを意味する。また、Zepが課金モデルを公開している点も、透明性が高く評価できるポイントとして挙げられる。

エピソードのサイズが意図せず増大する問題も指摘されている。例えば、初期段階では単純なメッセージ本文だけを送っていたサポート連携システムが、後からチケットのメタデータ、以前のステータス、システムメモなどを追加で送るようになった場合を考えてみよう。システムが「書き込む頻度」は変わらなくても、一度に書き込む「データ量（エピソードサイズ）」は増えてしまう。これにより、気付かないうちにZepへの課金が増えてしまう可能性があるため、注意が必要だ。

Zepの利用を検討している場合、以前はサービスを自分で運用する「自己ホスティング」という選択肢もあったが、2025年4月からはその戦略が変更された点にも触れられている。Zepの「コミュニティエディション」が非推奨となり、Zepの基盤となっているグラフエンジン「Graphiti」のみがオープンソースとして残された。そのため、Zepのサービス全体を自分で運用することはできなくなり、Zepの提供するホスト型サービスを利用することになる。無料枠もあるが、これもホスト型プランの一部として提供される。

Zepの利用を停止し、代替となるソリューションを探す場合に考えられる6つの選択肢が紹介されている。それぞれの代替案は、Zepのどの部分を代替するか、どのような技術を使うか、そしてコストがどこに移動するかが異なる。

1. Graphiti：これはZepの基盤となるグラフエンジンそのものだ。Zepのデータモデル（エンティティ、リレーション、有効期間）を維持しつつ、サービス自体は自分で運用する。Neo4jなどのグラフデータベースの運用コストや、グラフを構築するためのデータ抽出コストが発生する。
2. Statewave：PostgreSQLとpgvectorという拡張機能を使って、主体（ユーザー、アカウントなど）ごとのメモリを管理する。データは追加専用で、ポリシーに基づいたデータ取得が可能だ。コストはPythonサービスとPostgreSQLの運用、そしてデータコンパイル時のLLM（大規模言語モデル）の利用料金に移動する。
3. Hindsight：エージェントが経験や事実を統合し、観察結果やメンタルモデルを形成することに特化している。PostgreSQLなどを利用し、エージェントが「推論」することで信念を形成するタイプだ。この場合、推論（インファレンス）のためのモデル呼び出しコストが増える可能性がある。
4. Cognee：ドキュメントやコード、セッション履歴から知識グラフを構築する。リレーショナル、グラフ、ベクトルデータベースなど多様なバックエンドをサポートし、特に異なる種類のデータやコードを含む知識グラフ構築に適している。主に設定にかかる時間や労力がコストの中心となる。
5. Mem0：ユーザーごとのメモリAPIを提供する。ベクトルストアを自由に設定でき、短期間での導入が可能だ。ただし、グラフメモリ機能は現在、ホスト型プラットフォームでのみ提供されているため、移行前に必要な機能がどのエディションに含まれているか確認が必要である。コストはベクトルストアの運用費用とデータ抽出の呼び出し費用に移動する。
6. Letta：ステートフルなエージェントランタイムを提供し、編集可能なメモリブロックやバージョン管理されたファイルシステムを持つ。エージェントのメモリ設計に独自の哲学があり、オーケストレーション（複数のサービスや機能を連携させる仕組み）全体を置き換える場合に適している。既存のオーケストレーションがある場合は、その書き換えコストが発生する可能性がある。

これらの代替案を選ぶ際には、いくつかの重要なテストを行うことが推奨されている。例えば、「変更された事実が正しく追跡され、古い情報も見られるか」、「以前のセッションで語られた内容が、改めて明示的に指定しなくても想起されるか」、「ポリシーによって機密情報が適切に拒否され、その拒否が確認できるか」、「特定のエピソード（主体）を削除した際に、関連するすべての情報が完全に削除されるか」といった点だ。これらは、新しいシステムが期待通りに機能するか、データの一貫性やセキュリティが保たれるかを確認するために不可欠なテスト項目である。

そして何よりも重要なのは、あなたのアプリケーションが生成するエピソードの「バイトサイズ」を正確に把握することだと強調されている。Zepの課金がこのバイトサイズに大きく依存するだけでなく、代替サービスを検討する際にも、どのようなデータがどれだけの量で扱われるのかを知ることが、コストを予測し、適切な選択をするための出発点となる。システム設計や運用において、目に見えないデータ量がいかにコストに直結するかを改めて認識させられる内容である。