MemoketのKITEをご紹介します

KITEのアーキテクチャ概要

質問に最も似た情報ではなく、今も正しい情報を記憶から取り出して答える、ベクトルを使わないメモリエンジン。デバイス上で動作するメモリを実現するための、私たちの第一歩でもあります。

セクションへ移動
  1. 開発の理由
  2. KITEのご紹介
  3. 実際に機能するのか?
  4. 2分で試す
  5. 今後の展開

チームが実際に何を決めたのかをAIアシスタントに尋ねると、裏側では、ほとんどの場合、同じ処理が行われます。話された内容をすべてベクトルに変換し、ベクトルデータベースに保存する。そして情報を取り出すときに、質問に最も似た文章の断片を返します。「これに似たものを探して」という用途には、優れた方法です。でも、記憶を扱うには適していません。記憶の問題は、似ているかどうかではないからです。時間の経過を踏まえて、何が正しいのかという問題です。決定は変わり、担当者は変わり、日程はずれます。そして、質問に最も似ている一文が、すでに正しくなくなった情報であることは、よくあります。

仕事の場では、どのようなことが起きるのでしょうか。2か月間の会議で記録された、あるプロジェクトの三つの場面を見てみましょう。

  1. キックオフ:「分析ダッシュボードは第2四半期にリリースしましょう。」

    決定 · 確定
  2. 定例ミーティング:「分析ダッシュボードはデータパイプラインの問題で進められないので、先に請求機能を刷新します。」

    状況・更新
  3. レビュー:「パイプラインの問題は解消しました。分析ダッシュボードを再開し、6月末を目指します。」

    状況・更新

1週間後、こう尋ねます。「分析ダッシュボードは結局どうなりましたか。いつリリースされますか?」

類似度検索

最も明確で、質問の主題に合う「分析ダッシュボードは第2四半期にリリース」という一文に一致し、「第2四半期です」と答えます。あるいは、「進められない」という一文を見つけて、作業が止まっていると答えます。三つの場面を照らし合わせ、現時点で正しい一つの答えにまとめることができません。

KITE

最新の状況である「進行中、6月末を目標」を取り出し、そこに至る経緯もたどれます。4月にパイプラインの問題で遅れ、5月21日に再開したことを、三つの会議の該当箇所すべてを根拠として示せます。

似ている情報と、今この時点で正しい情報。その隔たりが、知識を扱う仕事で、記憶の仕組みが気づかないうちに役に立たなくなる原因です。欠席した定例ミーティング、覆された決定、変更になった担当者。KITEは、この問題を解決するためにつくりました。そして、仕事だけのツールではありません。時間の経過に伴う情報の変化を踏まえて情報を取り出す仕組みは、生活のほかの場面にも、そのまま役立ちます。その後に更新された医師の助言、友人の新しい住所、変わり続ける家の計画。ユーザーの多くは一日を仕事に費やしているので、私たちの例も仕事が中心です。でも、時間の経過に伴う情報の変化をきちんと扱うことは、どんな場面でも、記憶の仕組みに求められることなのです。

1. 開発した理由

Memoketは、一日の仕事を記録し、その内容について質問できる記憶に変えるウェアラブルをつくっています。それを本当に役立つものにするには、会議、決定、フォローアップなど、数か月、さらには数年分の文脈・背景情報を保持し、その情報に基づいて正確に答えられるメモリエンジンが必要でした。

そこで、標準的な技術構成を採用しました。埋め込み、ベクトルデータベース、ニューラルリランカーです。そして、その先に何があるかが見えてきました。埋め込みそのもののコストは低いのです。高くつくのは、それを役立てるために積み重ねる仕組みです。検索先となるベクトルデータベースと、返された結果を精査して並べ替えるニューラルリランカー。この組み合わせは重いため、クラウド上で動作します。実質的には、データセンターから記憶を借りているようなものです。情報を取り出すたびにネットワーク通信が往復し、機密性の高い仕事のデータがデバイスの外へ出ます。オフラインでも、最終的に動かしたいと考えている、小型でプライバシーを守れるハードウェアでも、無理なく使える道筋がありません。

私たちが求めていたのは、いずれデバイス自体に置けるメモリでした。その第一歩は、それを不可能にしている要因、つまりベクトルを用いた技術構成を取り除くことでした。

2. KITEとは

KITE(Knowledge-Indexed Temporal Evidence)は、埋め込みも、ベクトルデータベースも、ニューラルリランカーも使わない長期メモリエンジンです。ベクトルを使わないことは、宣伝文句ではありません。私たちが意図して選んだ、設計上の制約です。そして、その制約に向き合った結果、出発点だったクラウド構成よりも、軽量で正確なアーキテクチャにたどり着きました。

三つの考え方を基にしています。

1. メッセージを、時刻情報を持つ構造化された事実に変えます。それぞれの事実に何が変わったかを記録し、元の一文を根拠として残します。

<fact t="2026-05-21" kind="status" project="analytics-dashboard"
      state="in_progress" target_date="2026-06-30" src="mtg17L4">
  Pipeline unblocked; analytics dashboard resumed, targeting end of June.
</fact>

2. 質問を、明示的な実行計画に変換します。ブラックボックスではなく、人が読めるフィルターと処理手順です。「分析ダッシュボードはいつリリースされますか?」という問いは、「このプロジェクトの最新状況を取り出す」という計画になります。

3. その計画を、シンボリックインデックス上で実行します。処理は決定論的で、その内容を確認できます。同じメモリと同じ質問からは、常に同じ根拠が返ります。

Answer: In progress, targeting end of June. It slipped in April (blocked
on the data pipeline) and resumed May 21 once the pipeline cleared.

Sources:
  mtg2L3  | "ship the analytics dashboard in Q2"           (superseded)
  mtg9L1  | "analytics blocked ... billing revamp first"   (superseded)
  mtg17L4 | "pipeline unblocked ... targeting end of June" (current)

埋め込みに変換するものも、ドリフトするものも、再構築するものもありません。

3. 実際の性能は?

長期メモリの性能は、LoCoMoとLongMemEvalという二つの標準ベンチマークで測定されます。分野の慣例に従い、私たちも結果を報告します。ただし、ランキングの順位よりも重視している点があります。これらのベンチマークは性能がほぼ飽和しており、約6〜7%のラベルノイズを含むため、正解率そのものでは、KITEとEverMemOSを実質的に同等と捉えています。KITEが実際に差をつけるのは、効率です。最も近い性能の比較対象システムより、回答生成側のモデルが使うトークン数を35〜39%削減しながら、最上位グループの性能に達しています。しかも、埋め込みもベクトルデータベースも使いません。それが、デバイス上での動作に向けた道筋に、現実性を与えています。

KITEと長期記憶システムのベンチマーク比較
LoCoMo(ACL 2024)およびLongMemEval(ICLR 2025)における、LLMを評価者とした正解率。KITEとEverMemOSの数値は、回答生成モデルと評価モデルの両方にgpt-4.1-miniを使った、私たち自身の評価によるものです。ほかのシステムのスコアは、それぞれが公表した結果から引用しています。出典の詳細は、ベンチマークガイドに記載しています。引用が古い、あるいは設定に誤りがあると思われた場合は、プルリクエスト(PR)をお送りください。修正します。手法を詳しく説明する論文は、今回のリリース後に公開する予定です。

4. 2分で試す

pip install kite

from kite import Memory

memory = Memory.load("artifacts/quickstart.xml")
memory.remember(
    [{"role": "user", "content": "Pipeline unblocked; analytics is back on for end of June."}],
    session_id="standup-05-21",
)
print(memory.answer("When does the analytics dashboard ship?"))

処理の流れは、これだけです。記憶し、その後、情報を取り出すか、質問に答えます。APIの全容、使用例、技術レポートはREADMEにあります。

5. 今後の展開

KITEは本日、Apache 2.0ライセンスのオープンソースPythonライブラリとして公開します。手法を詳しく説明する論文は、今後公開する予定です。次に取り組むのは、ウェアラブル、スマートフォン、デスクトップで動作するオンデバイスランタイムと、Claude Code、Codex、Cursor、OpenCodeを含む、エージェントのエコシステム全体との連携です。

記憶を必要とするエージェント、特にエッジで動かす必要のあるエージェントを開発している方は、Issueの投稿やプルリクエスト、ベンチマークの再現検証を通じて、ぜひご協力ください。

今も正しい情報を保持し、エッジでの動作を目指すメモリを、あなたのエージェントに。

GitHubでKITEにスターを付ける