AI エージェントのための長期記憶。
WOS は記憶 API です。ユーザーの記憶を一度保存すれば、あとはクエリごとに関連する記憶だけを呼び出して、モデルのプロンプトに渡せます。
検索は純粋にセマンティックで、キーワードや BM25 のマッチングは一切ありません。そのためリコール品質は言語を問わず同一です。どれだけ保存しても各クエリは小さく上限のあるコンテキストを返し、保存された記憶の上でモデルが実行されることはありません。
主要な操作
store- ユーザーの記憶を保存します。recall- クエリに関連する記憶を取得します。これが中心となる呼び出しです。search- 保存済みの記憶に対する生のセマンティック検索です。supersede- 古くなった記憶を更新または置き換えます。forget- 単一の記憶、またはユーザー全体を削除します(GDPR 対応)。
3 つのモデル、ひとつの系譜。
WOS のモデル名は、人類が歴史の中で知識を残してきた手段に由来します - Tablet、Scroll、Codex。石板、巻物、綴じられた本。後のモデルほど、エージェントにできることが増えていきます。
Tablet
提供中記憶を刻み、呼び出すための軽量・高速・低コストな方式。すべてのモデルはこの土台の上に築かれます。
Scroll
提供中言語モデルを加えて質問をより深く読み取り、より充実したコンテキストを持ち帰ります。散らばった手がかりが 1 ピース欠けることなく、まとまって戻ってきます。
Codex
次期自ら正しいページを開きます - その瞬間に必要な記憶とツールを選び、使うほど鋭くなっていきます。
Tablet 1 の完全なベンチマークレポートはベンチマークページにあります。
WOS に払うのは $2。LLM 側でその何倍も節約。
WOS がクエリごとに LLM へ渡すのは約 1,200 トークン - 上限があり関連性の高いスライスです。全履歴を毎回プロンプトに詰め込む場合との差は非常に大きく、履歴が増えるほど広がります。
WOS に使う $1 ごとに、LLM 側で ~$98 を節約できます。履歴が大きいほど、モデルが高価なほど、ROI は大きくなります。
節約が生まれる仕組み
- WOS なしでは、毎回のプロンプトに全履歴を詰め込みます -
100K tokens × $2.50/1M = $0.25がクエリ 1 件ごとに(GPT-4o の入力単価基準。Opus 級モデルでは約 2 倍)。 - WOS ありでは、取り込みは一度だけ(
$2/1M)。以降の各クエリは小さな取得($3/1M × 1,200)と、約 1,200 トークンだけを読む LLM のコストで済みます。 - LLM が読むトークンが少ないほど、支払いは減ります。そして WOS は、記憶が増えてもその数を一定に保ちます。
どの言語でも、同じ精度。
検索は純粋なセマンティックで、埋め込みのみ。キーワードや BM25 のマッチングはゼロです。だからユーザーが日本語、中文、Español、English のいずれで書いても、リコール品質は同一です。
BM25 のような字句マッチングは、特定の言語のかたち - 形態素、分かち書き、文字体系 - に合わせて調整されています。多言語のストアでは、それが言語ごとの検索品質のばらつきになります。WOS は字句マッチングを一切使わないため、すべての言語が同じ経路を通ります。
ひとつのストアに 3 言語を同時に
ストアごとに言語を選ぶ必要はなく、自由に混在できます。以下では 1 人のユーザーの記憶に日本語・英語・スペイン語が同時に入っており、どの質問も言語に関係なく正しい記憶を見つけています。これは本番 API に対する実際のやり取りです:
# one user, three languages stored together mem.add("彼女はコーヒーより紅茶が好き", user_id="alice") # Japanese mem.add("she works at a design studio in Brooklyn", user_id="alice") # English mem.add("A ella le encanta hacer senderismo los sábados", user_id="alice") # Spanish
"¿Qué bebe ella?" -> 彼女はコーヒーより紅茶が好き "what does she do on weekends?" -> A ella le encanta hacer senderismo los sábados "彼女の仕事は?" -> she works at a design studio in Brooklyn
翻訳ステップも、言語検出も、言語ごとの設定もありません。記憶と質問は言語ではなく意味で配置されます - 意味が一致すれば、言語は関係ありません。
キーワードを意図的に禁止した理由
BM25 のような字句スコアリングは、一部の言語の検索を他の言語より強めてしまい、ひとつのストアに多くの言語が入る場面では妨げになります。そこでエンジンから完全に取り除き、このルールをコードレビューでも徹底しています。経路に字句スコアリングがひとつでもあれば、リコール品質は言語によって変わってしまうからです。
記憶の上でモデルは動きません。
保存は原文のまま、エンジンは埋め込みで検索します - 安価で、高速で、決定的です。保存された記憶の上でモデルが実行されることはありません。Tablet はモデルを一切使わず、Scroll と Codex はより強い結果のためにエンジンの周囲にモデルを加えますが、モデルが見るのはクエリだけで、保存内容は決して見ません。
- 決定的なエンジン。同じクエリには毎回同じ記憶を返します - ベンチマークの分散がリーダーモデル由来のみである理由です。
- スケールしても安価。保存にも取得にも生成コストがかからないため、記憶が増えても請求はストレージに比例します - モデル使用量ではありません。
あなたの言葉を、そのまま
よくある設計のひとつに、書き込み時に言語モデルを走らせてテキストから「事実」を抽出・書き換えるものがあります。この設計は 3 つを犠牲にします。書き込みごとの生成コスト、追加のレイテンシ、そして原文ではなくモデルの言い換えを保存すること。WOS は逆のトレードを選びます - 言われたことを変えずに保存し、読み取り時に原文を手にしたあなたの LLM に解釈させます。
90.7%。実測で、再現可能。
LongMemEval-S で 90.7%。独立した 5 回の実行の平均(σ 0.5%、選り好みなし)で、ベンチマーク公式の GPT-4o ジャッジが採点しています。
同じベンチマークでも、採点プロトコル - ジャッジ、プロンプト、検索レイヤーに許される操作 - によってスコアは大きく変わります。私たちは公開されているベンチマーク公式のサードパーティ GPT-4o ジャッジをそのまま使い、テストに合わせた変更は一切行わず、採点コードとリーダープロンプトを公開して、誰でも 90.7% を正確に再現できるようにしています。
プロトコルを 1 つの表で
| 項目 | 私たちのやり方 |
|---|---|
| データセット | LongMemEval-S(クリーニング済み)、1 問あたり約 240K トークンの履歴 |
| ジャッジ | ベンチマーク公式の GPT-4o ジャッジ - 私たちではなくサードパーティ |
| 実行回数 | 独立した 5 回の実行。全スコアを公開し、平均を報告(σ 0.5%) |
| リーダー | リーダーモデルとプロンプトを固定し、原文のまま公開 |
誠実さを支えるもの:サードパーティのジャッジ、無修正で公開されたリーダープロンプト、純粋にセマンティックな検索、そしてベストだけでなく全実行の報告。検索エンジンは決定的で、もう一度実行しても同じ記憶が返ります。
より難しいベンチマークへ登り続けます
私たちは、まだ制覇していない最も難しい標準ベンチマークでテストします - 数字はすべての WOS モデルを通じた最高記録で、より良いモデルが出るたびに更新されます。94% を超えたら、さらに難しいベンチマークへ進みます。
モデルごとに 2 つのトークン単価、
加えてリクエストあたり $0.0001。
100 万トークンあたりの単価に、リクエストごとの一律 $0.0001 を加えた従量課金です。サブスクリプションなし、ストレージ賃料なし、記憶数の上限なし。支払いが発生するのはエージェントが書き込むか読み取るときだけで、覚えている分には一切かかりません。
| モデル | 入力 / 1M | 出力 / 1M | |
|---|---|---|---|
| Tablet 1 | $2 | $3 | 提供中 |
| Scroll 1 | $4 | $8 | 提供中 |
| Codex 1 | - | - | 未定 |
- リクエストあたり $0.0001。トークン使用量に加えて、すべての API 呼び出しにかかる一律の手数料です。
- ストレージは無料。取り込み時に一度支払えば、保持は無料です。件数制限も保持期間の制限もありません。
- 私たちは保管するだけ。学習にも利用にも閲覧にも使いません。エージェントの記憶はあなたのものです - 私たちは取り出せるように整理するだけです。
- Tablet がこの価格である理由:そのエンジンはモデルを動かさないため、私たちのコストは埋め込みとディスクであって GPU ではありません。Scroll と Codex はモデルを加えており、その分が価格差になります。
呼び出しは 3 つ: store、recall、answer。
API はひとつ。recall() は短期記憶・長期記憶・周辺コンテキストを 1 回の往復で返し、そのままプロンプトに入れられます。
保存
add() でユーザーの事実や会話ターンを保存。取り込み時に埋め込み化 - LLM なし。
呼び出し
recall() は短期 + 長期 + コンテキストを 1 回の呼び出しで返します - 上限のある固定サイズのコンテキストです。
回答
その限られたコンテキストをあなたの LLM に渡すだけ - プロバイダーは自由、キーはあなたのもの。
from wontopos import Client mem = Client(api_key="wos-...") mem.add("she prefers tea over coffee", user_id="alice") # one call: short + long + context ctx = mem.recall("what does alice drink?", user_id="alice")
5 分で最初のリコールを。
キーひとつ、インストール 1 行、呼び出し 3 つで、エージェントに記憶が備わります。このページのスニペットはすべて実際に実行したもので、レスポンスは原文のまま掲載しています。
API キーを取得
コンソールで作成します。wos-live- で始まる 155 文字のキーは一度だけ表示されます。環境変数に保管し、コードには決して書かないでください。
インストール
pip install wontopos # Python npm install wontopos # TypeScript / JavaScript cargo add wontopos # Rust # curl - nothing to install, just set WOS_API_KEY
ストアを作成し、保存と呼び出しを
ストアとは、読み書きの単位となる user_id です。ストアは明示的で、まず作成し(下の呼び出し)、その中で保存・呼び出しを行います。保存 - 取り込み時に埋め込み化、LLM 呼び出しなし。呼び出し - 短期 + 長期 + コンテキストを 1 往復で。
from wontopos import Client
mem = Client(api_key="wos-live-...", user_id="alice") # set the store once
mem.create_store() # create it (stores are explicit)
mem.add("she prefers tea over coffee") # no user_id needed
# one call → short-term + long-term + context
ctx = mem.recall("what does alice drink?"){"user_id": "alice", "status": "created"}{"id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "stored (1 chunks)"}user_id を渡せば、以降のすべての呼び出しがそれを使うため、繰り返す必要はありません。個別の呼び出しに user_id を渡せば、その呼び出しだけ上書きできます。ストアは明示的:存在しないストアへの保存・呼び出しは 404 を返します - まず作成してください。すべてのアカウントには最初から default ストアがあるため、user_id を一切指定しないゼロ設定の経路もそのまま動きます。一覧と管理は ストア を参照してください。recall() は 4 つのブロックを返します - short_term(直近のターン)、long_term(関連する記憶)、context(ベストマッチの前後)、そして LLM に使い方を伝える instruction。まるごとプロンプトに入れてください。
ストア - 作成、一覧、削除。
ストアとは、読み書きの単位となる user_id です - エンドユーザー、エージェント、トピックごとに隔離された記憶空間になります。ストアは明示的です。保存や呼び出しの前に作成しないと、呼び出しは 404 を返します。すべてのアカウントには最初から default ストアがあるため、作成の呼び出しなしでも始められます。
mem.create_store("alice") # create (idempotent)
mem.list_stores() # [{"user_id","created_at"}, ...]
mem.delete_store("alice") # delete the store + all its memories{ "user_id": "alice", "status": "created" } // "exists" if it already did{ "collections": [
{ "user_id": "default", "created_at": "2026-06-26T02:23:14Z" },
{ "user_id": "alice", "created_at": "2026-06-26T02:24:01Z" }
], "count": 2 }{ "error": { "type": "not_found_error",
"message": "Store 'ghost' does not exist. Create it first with
POST /api/v1/memory/collection {\"user_id\":\"ghost\"}, then store or recall." } }"alice"、"user_42")使えば、各人の記憶を分離できます。個人用エージェントなら default ストアひとつでも構いません。コンソール(Memory ids → Issue)からコードを書かずにストアの作成・閲覧もできます。ストアの削除は恒久的で、その中のすべての記憶が消えます。Python - 全メソッドを 3 グループで。
書き込み、読み取り、削除。以下の例はすべて 2026-06-10 に本番 API に対して実行したもので、レスポンスは原文のままです。
pip install wontopos
from wontopos import Client mem = Client(api_key="wos-live-...") # or read from an env var
モデルを選ぶ
API キーはどの記憶か(あなたのアカウント)を決め、モデルはどのエンジンが読むかを決めます。すべてのモデルはひとつの記憶を共有するため、あるモデルで保存して別のモデルで呼び出せます。クライアントにデフォルトを設定し、個別の呼び出しは model= を渡して上書きします。
mem = Client(api_key="wos-live-...", model="tablet-1") # default engine mem.recall("...", user_id="alice") # tablet-1 mem.recall("...", user_id="alice", model="tablet-1") # or pick a model per call
list_models ✓ live-tested
カタログ - model に渡せる id と、それぞれの提供状況です。memory: "shared" のモデルは同じストアを読み、"isolated" は独自のストアを持ちます。API キーは不要です。
mem.list_models()[{"id": "tablet-1", "name": "Tablet 1", "available": true, "memory": "shared"}]上のカタログは、常に現時点で利用できるモデルを反映しています - それ以外の id を渡すと明確なエラーが返ります。新しいモデルは出荷と同時に自動で現れます。
書き込み
add ✓ live-tested
記憶を 1 件保存します。取り込み時に埋め込み化 - LLM 呼び出しはなく、支払いは埋め込み分だけです。
mem.add("she prefers tea over coffee", user_id="alice")
{"id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "stored (1 chunks)"}add_turn ✓ live-tested
会話ターン 1 件(ユーザー + アシスタント)を、短期記憶と長期記憶に同時に保存します。
mem.add_turn("alice", "hi", "hello!")
{"status": "ok"}add_bulk ✓ live-tested
大きなテキストの塊を一括投入します。サーバー側でチャンク化・埋め込み化されるため、既存履歴のインポートに最適です。
mem.add_bulk("Alice moved to Brooklyn in March. She works at a design studio downtown.", user_id="alice")
{"elapsed_secs": 0.154154944, "status": "ok", "stored": 1, "total_chunks": 1}update ✓ live-tested
事実が変わったとき。古い記憶は superseded とマークされ(履歴として保持)、新しい記憶がリコールでその座を引き継ぎます。
mem.update("alice", old_memory_id="576700aa-...", new_content="she switched to coffee this year")
{"new_memory_id": "07e94433-b7cc-4e49-8d8f-f37fc1a392b7",
"old_memory_id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "superseded"}読み取り
search ✓ live-tested
セマンティック検索で、関連度の高い順に返します。純粋な埋め込みでキーワードマッチングがないため、どの言語からでもどの記憶にも届きます。SDK は memories 配列を直接返します。以下は生の HTTP ボディです。
r = mem.search("what does she drink?", user_id="alice", limit=1)
{"memories": [{
"id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624",
"content": "she prefers tea over coffee",
"category": "general",
"time_bucket": "2026-06",
"importance": 0.3,
"similarity": 0.6316057443618774,
"is_superseded": false,
"superseded_by": null,
"created_at": "2026-06-10T04:20:39.688276876Z"
}], "search_ms": 315, "total_found": 1}| フィールド | 意味 |
|---|---|
| similarity | クエリとの生の埋め込み類似度(0–1)。 |
| is_superseded | update() によって置き換えられた事実なら true。 |
| search_ms | サーバー側の検索所要時間。 |
recall ✓ live-tested
1 回の往復で、LLM に必要なものがすべて返ります - 結果をそのままプロンプトに貼るだけです。どれだけ保存していても、上限のある固定サイズのコンテキストです。
ctx = mem.recall("what does she drink?", user_id="alice")
{"short_term": {"count": 2, "turns": [{"role": "user", "content": "hi", ...}]},
"long_term": {"count": 4, "memories": [{"content": "she prefers tea over coffee",
"similarity": 0.63, ...}]},
"context": {"count": 4, "around_top_memory": [
"[match] she prefers tea over coffee",
"[after] Alice moved to Brooklyn in March. ..."]},
"instruction": "Use short_term for recent context, long_term for relevant
past memories, context for surrounding conversation of the
most relevant memory."}history ✓ live-tested
直近の会話ターン(短期記憶)を、古い順に返します。
turns = mem.history("alice")
{"count": 2, "turns": [
{"role": "user", "content": "hi", "timestamp": "2026-06-10T04:20:40.989011337Z"},
{"role": "assistant", "content": "hello!", "timestamp": "2026-06-10T04:20:40.989013416Z"}
], "user_id": "alice"}stats ✓ live-tested
1 ユーザーの記憶数を返します。
mem.stats("alice")
{"short_term_turns": 2, "total_memories": 4, "user_id": "alice"}削除
delete ✓ live-tested
id を指定して記憶を 1 件削除します。
mem.delete("alice", memory_id="576700aa-...")
{"memory_id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "deleted"}delete_all ✓ live-tested
1 ユーザーのすべてを消去します - 1 回の呼び出しで、GDPR 対応です。
mem.delete_all("alice")
{"memories_deleted": 4, "status": "deleted", "user_id": "alice"}TypeScript - 全メソッドを 3 グループで。
書き込み、読み取り、削除。以下の例はすべて 2026-06-10 に本番 API に対して実行したもので、レスポンスは原文のままです。
npm install wontopos
import { Client } from "wontopos"; const mem = new Client({ apiKey: "wos-live-..." });
モデルを選ぶ
API キーはどの記憶か(あなたのアカウント)を決め、モデルはどのエンジンが読むかを決めます。すべてのモデルはひとつの記憶を共有するため、あるモデルで保存して別のモデルで呼び出せます。コンストラクタでデフォルトを設定し、個別の呼び出しは withModel() で上書きします。
const mem = new Client({ apiKey: "wos-live-...", model: "tablet-1" }); // default mem.recall("...", "alice"); // tablet-1 mem.withModel("tablet-1").recall("...", "alice"); // or pick a model per call
listModels ✓ live-tested
カタログ - model に渡せる id と、それぞれの提供状況です。memory: "shared" のモデルは同じストアを読み、"isolated" は独自のストアを持ちます。API キーは不要です。
await mem.listModels();
[{"id": "tablet-1", "name": "Tablet 1", "available": true, "memory": "shared"}]上のカタログは、常に現時点で利用できるモデルを反映しています - それ以外の id を渡すと明確なエラーが返ります。新しいモデルは出荷と同時に自動で現れます。
書き込み
add ✓ live-tested
記憶を 1 件保存します。取り込み時に埋め込み化 - LLM 呼び出しはなく、支払いは埋め込み分だけです。
await mem.add("she prefers tea over coffee", "alice");
{"id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "stored (1 chunks)"}addTurn ✓ live-tested
会話ターン 1 件(ユーザー + アシスタント)を、短期記憶と長期記憶に同時に保存します。
await mem.addTurn("alice", "hi", "hello!");
{"status": "ok"}addBulk ✓ live-tested
大きなテキストの塊を一括投入します。サーバー側でチャンク化・埋め込み化されるため、既存履歴のインポートに最適です。
await mem.addBulk("Alice moved to Brooklyn in March. She works at a design studio downtown.", "alice");
{"elapsed_secs": 0.154154944, "status": "ok", "stored": 1, "total_chunks": 1}update ✓ live-tested
事実が変わったとき。古い記憶は superseded とマークされ(履歴として保持)、新しい記憶がリコールでその座を引き継ぎます。
await mem.update("alice", "576700aa-...", "she switched to coffee this year");
{"new_memory_id": "07e94433-b7cc-4e49-8d8f-f37fc1a392b7",
"old_memory_id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "superseded"}読み取り
search ✓ live-tested
セマンティック検索で、関連度の高い順に返します。純粋な埋め込みでキーワードマッチングがないため、どの言語からでもどの記憶にも届きます。SDK は memories 配列を直接返します。以下は生の HTTP ボディです。
const r = await mem.search("what does she drink?", "alice", 1);
{"memories": [{
"id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624",
"content": "she prefers tea over coffee",
"category": "general",
"time_bucket": "2026-06",
"importance": 0.3,
"similarity": 0.6316057443618774,
"is_superseded": false,
"superseded_by": null,
"created_at": "2026-06-10T04:20:39.688276876Z"
}], "search_ms": 315, "total_found": 1}| フィールド | 意味 |
|---|---|
| similarity | クエリとの生の埋め込み類似度(0–1)。 |
| is_superseded | update() によって置き換えられた事実なら true。 |
| search_ms | サーバー側の検索所要時間。 |
recall ✓ live-tested
1 回の往復で、LLM に必要なものがすべて返ります - 結果をそのままプロンプトに貼るだけです。どれだけ保存していても、上限のある固定サイズのコンテキストです。
const ctx = await mem.recall("what does she drink?", "alice");
{"short_term": {"count": 2, "turns": [{"role": "user", "content": "hi", ...}]},
"long_term": {"count": 4, "memories": [{"content": "she prefers tea over coffee",
"similarity": 0.63, ...}]},
"context": {"count": 4, "around_top_memory": [
"[match] she prefers tea over coffee",
"[after] Alice moved to Brooklyn in March. ..."]},
"instruction": "Use short_term for recent context, long_term for relevant
past memories, context for surrounding conversation of the
most relevant memory."}history ✓ live-tested
直近の会話ターン(短期記憶)を、古い順に返します。
const turns = await mem.history("alice");
{"count": 2, "turns": [
{"role": "user", "content": "hi", "timestamp": "2026-06-10T04:20:40.989011337Z"},
{"role": "assistant", "content": "hello!", "timestamp": "2026-06-10T04:20:40.989013416Z"}
], "user_id": "alice"}stats ✓ live-tested
1 ユーザーの記憶数を返します。
await mem.stats("alice");
{"short_term_turns": 2, "total_memories": 4, "user_id": "alice"}削除
delete ✓ live-tested
id を指定して記憶を 1 件削除します。
await mem.delete("alice", "576700aa-...");
{"memory_id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "deleted"}deleteAll ✓ live-tested
1 ユーザーのすべてを消去します - 1 回の呼び出しで、GDPR 対応です。
await mem.deleteAll("alice");
{"memories_deleted": 4, "status": "deleted", "user_id": "alice"}Rust - 全メソッドを 3 グループで。
書き込み、読み取り、削除。以下の例はすべて 2026-06-10 に本番 API に対して実行したもので、レスポンスは原文のままです。
cargo add wontopos
use wontopos::Client; let mem = Client::new("wos-live-...");
モデルを選ぶ
API キーはどの記憶か(あなたのアカウント)を決め、モデルはどのエンジンが読むかを決めます。すべてのモデルはひとつの記憶を共有するため、あるモデルで保存して別のモデルで呼び出せます。with_model() でデフォルトを設定し、もう一度チェーンすれば個別の呼び出しだけ上書きできます。
let mem = Client::new("wos-live-...").with_model("tablet-1"); // default mem.recall("...", "alice").await?; // tablet-1 mem.with_model("tablet-1").recall("...", "alice").await?; // or pick a model per call
list_models ✓ live-tested
カタログ - with_model に渡せる id と、それぞれの提供状況です。memory: "shared" のモデルは同じストアを読み、"isolated" は独自のストアを持ちます。API キーは不要です。
mem.list_models().await?;
[{"id": "tablet-1", "name": "Tablet 1", "available": true, "memory": "shared"}]上のカタログは、常に現時点で利用できるモデルを反映しています - それ以外の id を渡すと明確なエラーが返ります。新しいモデルは出荷と同時に自動で現れます。
書き込み
add ✓ live-tested
記憶を 1 件保存します。取り込み時に埋め込み化 - LLM 呼び出しはなく、支払いは埋め込み分だけです。
mem.add("she prefers tea over coffee", "alice", json!({})).await?;
{"id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "stored (1 chunks)"}add_turn ✓ live-tested
会話ターン 1 件(ユーザー + アシスタント)を、短期記憶と長期記憶に同時に保存します。
mem.add_turn("alice", "hi", "hello!").await?;
{"status": "ok"}add_bulk ✓ live-tested
大きなテキストの塊を一括投入します。サーバー側でチャンク化・埋め込み化されるため、既存履歴のインポートに最適です。
mem.add_bulk("Alice moved to Brooklyn in March...", "alice", "general").await?;
{"elapsed_secs": 0.154154944, "status": "ok", "stored": 1, "total_chunks": 1}update ✓ live-tested
事実が変わったとき。古い記憶は superseded とマークされ(履歴として保持)、新しい記憶がリコールでその座を引き継ぎます。
mem.update("alice", "576700aa-...", "she switched to coffee this year").await?;
{"new_memory_id": "07e94433-b7cc-4e49-8d8f-f37fc1a392b7",
"old_memory_id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "superseded"}読み取り
search ✓ live-tested
セマンティック検索で、関連度の高い順に返します。純粋な埋め込みでキーワードマッチングがないため、どの言語からでもどの記憶にも届きます。SDK は memories 配列を直接返します。以下は生の HTTP ボディです。
let r = mem.search("what does she drink?", "alice", 1).await?;
{"memories": [{
"id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624",
"content": "she prefers tea over coffee",
"category": "general",
"time_bucket": "2026-06",
"importance": 0.3,
"similarity": 0.6316057443618774,
"is_superseded": false,
"superseded_by": null,
"created_at": "2026-06-10T04:20:39.688276876Z"
}], "search_ms": 315, "total_found": 1}| フィールド | 意味 |
|---|---|
| similarity | クエリとの生の埋め込み類似度(0–1)。 |
| is_superseded | update() によって置き換えられた事実なら true。 |
| search_ms | サーバー側の検索所要時間。 |
recall ✓ live-tested
1 回の往復で、LLM に必要なものがすべて返ります - 結果をそのままプロンプトに貼るだけです。どれだけ保存していても、上限のある固定サイズのコンテキストです。
let ctx = mem.recall("what does she drink?", "alice").await?;
{"short_term": {"count": 2, "turns": [{"role": "user", "content": "hi", ...}]},
"long_term": {"count": 4, "memories": [{"content": "she prefers tea over coffee",
"similarity": 0.63, ...}]},
"context": {"count": 4, "around_top_memory": [
"[match] she prefers tea over coffee",
"[after] Alice moved to Brooklyn in March. ..."]},
"instruction": "Use short_term for recent context, long_term for relevant
past memories, context for surrounding conversation of the
most relevant memory."}history ✓ live-tested
直近の会話ターン(短期記憶)を、古い順に返します。
let turns = mem.history("alice").await?;
{"count": 2, "turns": [
{"role": "user", "content": "hi", "timestamp": "2026-06-10T04:20:40.989011337Z"},
{"role": "assistant", "content": "hello!", "timestamp": "2026-06-10T04:20:40.989013416Z"}
], "user_id": "alice"}stats ✓ live-tested
1 ユーザーの記憶数を返します。
mem.stats("alice").await?;
{"short_term_turns": 2, "total_memories": 4, "user_id": "alice"}削除
delete ✓ live-tested
id を指定して記憶を 1 件削除します。
mem.delete("alice", "576700aa-...").await?;
{"memory_id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "deleted"}delete_all ✓ live-tested
1 ユーザーのすべてを消去します - 1 回の呼び出しで、GDPR 対応です。
mem.delete_all("alice").await?;
{"memories_deleted": 4, "status": "deleted", "user_id": "alice"}curl - インストール不要、同じメソッド。
インストールする SDK はなく、任意の HTTP クライアントで動きます。キーを一度設定すれば、SDK がラップしているのと同じエンドポイントを呼べます。ベース URL は https://api.wontopos.com、認証は X-API-Key、入出力は JSON です。
# set your key once (never hard-code it) export WOS_API_KEY="wos-live-..."
書き込み
store ✓ live-tested
記憶を 1 件保存します。取り込み時に埋め込み化 - LLM 呼び出しなし。
curl -X POST https://api.wontopos.com/api/v1/memory/store \ -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \ -d '{"user_id":"alice","content":"she prefers tea over coffee"}'
{"id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "stored (1 chunks)"}store-turn ✓ live-tested
会話ターン 1 件(ユーザー + アシスタント)を、短期・長期記憶に同時に保存します。
curl -X POST https://api.wontopos.com/api/v1/memory/store-turn \ -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \ -d '{"user_id":"alice","user_msg":"hi","assistant_msg":"hello!"}'
{"status": "ok"}supersede ✓ live-tested
事実が変わったとき - 古い記憶は superseded とマークされ、新しい記憶がリコールでその座を引き継ぎます。
curl -X POST https://api.wontopos.com/api/v1/memory/supersede \ -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \ -d '{"user_id":"alice","old_memory_id":"576700aa-...","new_content":"she switched to coffee this year"}'
{"new_memory_id": "07e94433-...", "old_memory_id": "576700aa-...", "status": "superseded"}読み取り
search ✓ live-tested
セマンティック検索で、関連度の高い順に。純粋な埋め込みなので、どの言語からでもどの記憶にも届きます。
curl -X POST https://api.wontopos.com/api/v1/memory/search \ -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \ -d '{"user_id":"alice","query":"what does she drink?","max_results":1}'
{"memories": [{"id": "576700aa-...", "content": "she prefers tea over coffee",
"similarity": 0.63, "is_superseded": false}], "search_ms": 315, "total_found": 1}recall ✓ live-tested
1 回の往復で、短期 + 長期 + コンテキスト + instruction が返ります。そのままプロンプトに貼ってください。
curl -X POST https://api.wontopos.com/api/v1/memory/recall \ -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \ -d '{"user_id":"alice","query":"what does she drink?"}'
{"short_term": {"count": 2, "turns": [...]},
"long_term": {"count": 4, "memories": [{"content": "she prefers tea over coffee", "similarity": 0.63}]},
"context": {"count": 4, "around_top_memory": ["[match] she prefers tea over coffee"]},
"instruction": "Use short_term for recent context, long_term for relevant past memories..."}削除
forget ✓ live-tested
id を指定して記憶を 1 件削除するか、id を省略してユーザーのすべてを削除します(GDPR)。
curl -X POST https://api.wontopos.com/api/v1/memory/forget \ -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \ -d '{"user_id":"alice"}' # omit memory_id = delete all
{"memories_deleted": 1, "status": "deleted", "user_id": "alice"}Engrams
モデルが呼び出せるリコールツールです - それぞれが、同じ記憶に対する異なる検索戦略になっています。ひとつだけ使っても、複数を同時に実行しても構いません。
エングラムは定期的に追加されます - このリストは増えていきます。
Memoir & Archive 近日提供
これは呼び出し可能なツールではなく、モデルのモードです。モデルで選択すると、通常の検索を含むすべてのリコールに、その流儀で書かれた時間が付いて返ります。近日提供。
Time_awareness 近日提供
呼び出しごとのオプションではなく、モデルのモードです。モデル - Time_awareness-memoir または Time_awareness-archive - を選ぶと、通常の検索、recall、任意のエングラムまで、すべてのリコールが追加パラメータなしにその流儀で描画されて返ります。Memoir は人が思い出すように読め、Archive は正確な記録を保ちます - 違いが最も表れるのは、時間の書き方です。Time_awareness- という接頭辞は、後から機能を増やす余地を残しています。
Memoir
Time_awareness-memoir何が起き、その瞬間が次にどうつながったかを、人が思い出すときのやわらかな時間感覚とともに語ります - リストではなく、体験として読めます。
Archive
Time_awareness-archiveマッチを正確な記録として返します - 精密な経過時間と絶対的なアンカーを備え、モデルがそのまま読み取れる構造です。
user_id の下でのひとつの store / add 呼び出しです(その user_id がその人のストアそのものです)。まず保存してください。その後はどのリコールも - 下の通常検索も含めて - 時間タグ付きで返ります。保存の方法は クイックスタート を参照してください。# plain search - no engram - on a memoir model
r = mem.search("what does Alice drink?", user_id="alice", model="Time_awareness-memoir", tz=9)
# every hit gets a .time field → "a couple weeks ago" (archive model → "2 weeks ago (Jun 09)")tz は呼び出し側の UTC オフセット(時間単位)です - これにより "this morning" のような表現や午前 4 時の日付境界が、その人の現地時間で決まります。省略すると UTC、HTTP では X-WOS-Timezone ヘッダーです。地域別の目安: 米国東部 -5、米国中部 -6、米国西部 -8 · 英国 / リスボン 0 · 中央ヨーロッパ +1 · 東ヨーロッパ +2 · インド +5.5 · 中国 / シンガポール +8 · 韓国 / 日本 +9 · シドニー +10。(標準時基準です - 夏時間で +1 になる地域もあるため、ユーザーが実際に使っている値を渡してください。)
同じ検索を 2 つのモデルで - 記憶は同一で、変わるのは time だけです:
{ "count": 3, "memories": [
{ "content": "Alice prefers tea over coffee", "time": "a couple weeks ago" },
{ "content": "met Alice at the cafe downtown", "time": "yesterday afternoon" },
{ "content": "Alice moved to Brooklyn", "time": "about half a year ago" }
] }{ "count": 3, "memories": [
{ "content": "Alice prefers tea over coffee", "time": "2 weeks ago (Jun 09)" },
{ "content": "met Alice at the cafe downtown", "time": "yesterday at 14:00" },
{ "content": "Alice moved to Brooklyn", "time": "6 months ago (Dec 2025)" }
] }| 経過時間 | Memoir | Archive |
|---|---|---|
| 3 分 | a few minutes ago | 3 minutes ago |
| 14 分 | about 15 minutes ago | 14 minutes ago |
| 30 分 | half an hour ago | 30 minutes ago |
| 50 分 | about an hour ago | 50 minutes ago |
| 2 時間 | a couple hours ago | 2 hours ago, at 13:10 |
| 8 時間 | this morning | 8 hours ago, at 07:10 |
| 昨日の午後 | yesterday afternoon | yesterday at 14:00 |
| 昨夜 | last night | 17 hours ago, at 22:00 |
| 2 日 | a couple days ago | 2 days ago (Tue 15:10) |
| 6 日 | several days ago | 6 days ago (Fri 15:10) |
| 9 日 | about a week ago | last week (Jun 16) |
| 16 日 | a couple weeks ago | 2 weeks ago (Jun 09) |
| 35 日 | about a month ago | last month (May 21) |
| 60 日 | a couple months ago | 2 months ago (Apr 2026) |
| 180 日 | about half a year ago | 6 months ago (Dec 2025) |
| 380 日 | about a year ago | last year (Jun 2025) |
| 800 日 | a couple years ago | 2 years ago (Apr 2024) |
| 1500 日 | about 4 years ago | 4 years ago (May 2022) |
上の値はすべてレンダラーの実際の出力です。「昨日」の 2 行を見てください。Memoir は昨日の午後と昨夜を分けます - 一日とはひと眠りのことだからです。一方 Archive は時計の時刻ひとつで書き、昼と夜の線を引きません。
各モードの時間の読み方
Memoir - 人が実際に口にする言い方。直近はかなり鮮明なまま(15 分ほど前、30 分前)、遡るほど言い回しが広がっていきます - 2 週間ほど前、半年ほど前、数年前 - 記憶そのものが、距離とともにゆるんでいくように。一日の中では時計を捨てて目印で語ります:今朝、昨夜、昨日の午後。そして一日はカレンダーの一目盛りではなく、ひと眠りです。境界は現地時間の午前 4 時ごろにあり、夜更かしはまだ同じ夜のままで、もう明日にはなりません。
Archive - 正確に、常にアンカーとともに。すべての行に、正確な経過時間と、モデルが計算に使える絶対的な基準が付きます。近いほどアンカーは細かくなります。今日は時計(8 時間前、07:10)、今週は曜日と時計(2 日前(火 15:10))、今月は日付(先週(6 月 16 日))、それより前は月と年(6 か月前(2025 年 12 月))。曖昧にならず、間違えません。
deep_recall
マルチホップリコール。まずクエリで検索し、トップマッチの内容でもう一度検索します - 単発の検索では届かない、つながったコンテキストを引き込みます。記憶同士が参照し合う場面(人物 → そのプロジェクト → 詳細)に最適です。最大約 12 件を返します。
out = mem.engram("deep_recall", "what should I know about Alice?", user_id="alice"){ "engram": "deep_recall", "hops": 2, "count": 12,
"memories": [ ... ],
"usage": { "input_tokens": 5, "output_tokens": 61 } }usage(入力 + 出力)を返し、API の他の部分と同じトークナイザーで数えます。エングラムごとの隠れた料金はありません。複数を同時に使いたいときは並行して呼んでください - 各エングラムは独立したリクエストです。timeline
時系列リコール。関連度ではなく、出来事が起きた時点の新しい順に記憶を返します。「いつ X した?」という質問、履歴、順序の把握に。最大 15 件を返します。
events = mem.engram("timeline", "project milestones", user_id="alice"){ "engram": "timeline", "hops": 1, "count": 15,
"memories": [ ... ],
"usage": { "input_tokens": 4, "output_tokens": 88 } }usage(入力 + 出力)を返し、API の他の部分と同じトークナイザーで数えます。エングラムごとの隠れた料金はありません。複数を同時に使いたいときは並行して呼んでください - 各エングラムは独立したリクエストです。gather
広域収集。検索したうえで、上位 3 件のマッチの周辺を展開します - deep_recall より広い網です。人物・プロジェクト・トピックに関連するものすべてを、1 回の呼び出しで集めるのに使います。最大約 18 件を返します。
related = mem.engram("gather", "everything about Project Atlas", user_id="alice"){ "engram": "gather", "hops": 4, "count": 18,
"memories": [ ... ],
"usage": { "input_tokens": 6, "output_tokens": 142 } }usage(入力 + 出力)を返し、API の他の部分と同じトークナイザーで数えます。エングラムごとの隠れた料金はありません。複数を同時に使いたいときは並行して呼んでください - 各エングラムは独立したリクエストです。すべてのエンドポイントを、ひとつのベース URL で。
SDK は不要で、任意の HTTP クライアントで動きます。ベース URL は https://api.wontopos.com、認証は X-API-Key ヘッダー、入出力は JSON です。記憶の操作は POST、ストアの管理は /collection への POST / GET / DELETE です。ストアが先に存在しないと(ストア を参照)、ストア内の操作は 404 を返します。
| エンドポイント | 用途 | ボディフィールド |
|---|---|---|
| POST /api/v1/memory/collection | ストアを作成 | user_id |
| GET /api/v1/memory/collections | ストアを一覧 | (なし) |
| DELETE /api/v1/memory/collection | ストアとその記憶を削除 | user_id |
| /api/v1/memory/store | 記憶を 1 件保存 | user_id · content · metadata? |
| /api/v1/memory/store-turn | 会話ターンを保存 | user_id · user_msg · assistant_msg |
| /api/v1/memory/bulk-store | テキストの塊を一括投入 | user_id · content · category? |
| /api/v1/memory/search | セマンティック検索 | user_id · query · max_results? |
| /api/v1/memory/recall | 短期 + 長期 + コンテキスト | user_id · query |
| /api/v1/memory/history | 直近のターン | user_id |
| /api/v1/memory/stats | 記憶数 | user_id |
| /api/v1/memory/supersede | 変わった事実を置き換え | user_id · old_memory_id · new_content |
| /api/v1/memory/forget | 1 件(または全件)を削除 | user_id · memory_id? (省略 = 全件削除) |
# create the store once (stores are explicit) curl -X POST https://api.wontopos.com/api/v1/memory/collection \ -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \ -d '{"user_id":"alice"}' # store a memory curl -X POST https://api.wontopos.com/api/v1/memory/store \ -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \ -d '{"user_id":"alice","content":"she prefers tea over coffee"}' # recall - one call, ready for your prompt curl -X POST https://api.wontopos.com/api/v1/memory/recall \ -H "X-API-Key: $WOS_API_KEY" -H "Content-Type: application/json" \ -d '{"user_id":"alice","query":"what does alice drink?"}'
{"id": "576700aa-f0e0-4c26-99a0-10e2d5b0d624", "status": "stored (1 chunks)"}機能は全員同じ。
ティアは上限を引き上げるだけ。
どのティアもフルエンジンで動きます - 同じリコール品質、同じ言語対応、すべてのメソッド。ティアは累計クレジット購入額の増加に応じて Tier 5 まで自動で上がり、申請も営業とのやり取りも不要です。Enterprise(Tier 6)だけが例外です。
支出上限
各ティアには、暦月ごとに支出できる上限があります。累計クレジット購入額が次のしきい値に達すると、即座に昇格します。
| 利用ティア | クレジット購入額 | 月間支出上限 |
|---|---|---|
| Tier 1 | $5 | $100 |
| Tier 2 | $40 | $500 |
| Tier 3 | $200 | $1,000 |
| Tier 4 | $400 | $5,000 |
| Tier 5 | $1,000 | $25,000 |
| Tier 6 - Enterprise | お問い合わせ | 無制限 |
レート制限
レート制限はアカウント単位です - アカウント内のすべての API キーがひとつの制限を共有し、ティアに応じて拡大します。超過すると retry-after ヘッダー付きの 429 が返るので、バックオフ(1s → 2s → 4s)して再試行してください。すべてのエンドポイントは冪等性に配慮した設計のため、再試行しても安全です。
| ティア | 毎分リクエスト数 |
|---|---|
| Tier 1 | 150 |
| Tier 2 | 300 |
| Tier 3 | 600 |
| Tier 4 | 1,500 |
| Tier 5 | 3,000 |
| Tier 6 - Enterprise | カスタム |
Enterprise(Tier 6)にはカスタムレート制限、SLA、専任サポート、オプションのセルフホストライセンスが付きます - お問い合わせください。
何かがうまくいかないとき。
エラーは JSON エンベロープで返ります。安定した type、人が読めるメッセージ、そして問題の報告時に添えられる request_id が含まれます。
{"type": "error", "error": {
"type": "authentication_error",
"message": "Invalid or revoked API key.",
"request_id": "063f8b83-eee2-4383-a5cf-11e4bcd29d7c"
}}| HTTP | 意味 | 対処 |
|---|---|---|
| 401 | API キーが無効または失効している | キーを確認し、コンソールで新しいキーを発行してください。 |
| 422 | 不正なボディ(フィールドの欠落・型違い) | メッセージに該当フィールドが明記されます - 修正して再試行してください。 |
| 429 | レート制限を超過 | 指数バックオフ(1s → 2s → 4s)で再試行してください。すべてのエンドポイントは冪等性に配慮しているため安全です。 |
| 5xx | サーバー側の問題 | バックオフしつつ再試行してください。お問い合わせの際は request_id を添えてください。 |
# SDK error handling (Python) from wontopos import Client, WosError try: mem.search("...", user_id="alice") except WosError as e: if e.status == 401: ... # bad key elif e.status == 429: ... # back off and retry
レート制限はアカウント単位で、すべてのキーが共有し、ティアに応じて拡大します - 利用ティア を参照してください。アカウントの使用状況はコンソールで確認できます。
あなたのサーバーに、あなたのデータを。
エンジンは自社インフラの中でも動かせます - 同じ API、同じ SDK のままで。クライアントの向き先を自分のホストに変えるだけで、ほかには何も変わりません。
mem = Client(api_key="...", base_url="https://wos.your-host.com")- データレジデンシー。記憶があなたのネットワークの外に出ることはありません。
- 同じインターフェース。同じメソッドとエンドポイントが、まったく同じように動きます。
- ライセンス。セルフホストのパッケージはデプロイごとに個別に取り決めます - お問い合わせください。
コンテキストウィンドウを超えて。
WOS は 1.4M トークンの履歴 - どの LLM のコンテキストウィンドウよりもはるかに大きな規模 - からリコールし、それでも約 1,470 トークンの引き締まったスライスだけを返します。
エージェントの記憶は、プロンプトに収まる量に縛られません。すべてを保持し、履歴がどれだけ大きくなっても、重要なものだけを取り出します。
プライベートで、あなたのもの。
データはあなたのストアに留まります。学習にも閲覧にも再利用にも使いません - 取り出せるように整理するだけです。
- BYOK。LLM キーはリクエストごとに送られ、保存されることはありません。
- 隔離。記憶はアカウント単位、さらに
user_id単位でスコープされます。 - GDPR 削除 & セルフホスト。1 回の呼び出しでユーザーを消去でき、必要ならエンジンを自社環境で運用できます。