ロードマップ¶

各リリースラインがどこへ向かうのか、なぜそうなのかを書きます。今どこまで進んだかは書きません。進捗はリリースノートに、ラインの tier と現在のバージョンは SUPPORT.md に、ラインが従う規則はリリースライフサイクル標準にあります。

このページは説明の文書です。ラインが何のためにあるか、何の互換性を崩してよいか、各機能がどの問題に答えるかを記録します。納期の約束ではありません。「未定」と書いた項目のほうが、誰も測っていない計画で埋めた項目より役に立ちます。

翻訳について: 原文は英語版です。日本語版が古いときは英語版を参照してください。

3 つの軸¶

バージョン番号を 1 列に並べると、別々に動く 3 つのものの区別がつかなくなります。

軸	そこで動くもの	読む場所
リリースライン (2.4 → 2.5 → 2.6 → …)	サーバーが何をするか、何の互換性を崩してよいか	このページ
ランタイムとスケール	1 つのインストールが持てるコーパスの大きさと応答速度 (SQLite 上の Python から Go の索引サービスへ)	下のスケールの階段
サポート tier (Stable / Current / Experimental)	どのラインを運用すべきか、いつまで修正を受けるか	SUPPORT.md

ランタイムの軸は、リリースラインをまたいで進みます。階段の 1 段は準備ができた時点で Current になっているラインで出荷されます。したがって「2.6」という番号が指すのは検索機能の集合だけであり、階段をどこまで登ったかは表していません。

決して変わらないもの¶

次のことはどのラインでも成り立ちます。これらのどれかを曲げないと成り立たない機能は、予定に載せず、設計をやり直します。意図した例外は 1 つだけで、黙って行わず、ここで明示します。 3.0 は保存層を置き換えるので、3.0 以降は下の 2 項目めと 3 項目めの範囲が狭まります (理由と、移る方法)。

サーバーは言語モデルを呼びません。要約・抽出・判断はエージェントの仕事で、サーバーは決定論的に保存・索引・検索します。したがって記憶は生成 API の費用を一切足さず、結果はコーパスと設定から再現できます。
利用者が所有するローカルの保存先。外部データベースも、データが依存するサービスもありません。埋め込みは別プロセスで、無くても動きます。2.x の間、保存先は 1 つの SQLite ファイルです。3.0 はそれを、まだ決まっていない保存先に置き換えます。この項目は、その保存先がなお満たすべき条件です。
データベースのスキーマは同じメジャーバージョンの中では前にしか進みません。アップグレードはその場でマイグレーションします。追加 (新しい列・新しいテーブル) が通常の形です。既存テーブルの再構造化には前例が無く、まだ存在しないマイグレーション設計が要ります。メジャーバージョンをまたぐときは保存形式の互換性がなくなることがあり、それはサポートされた変換器がある場合に限ります。3.0 には 2.8 からの変換器が付きます。
劣化は報告され、隠されません。ベクトル層を失った recall は応答の中でそれを報告し、ヘルスチェックは検証できなかったものを明示します。
挙動は変える前に固定されます。観測した応答を記録した golden と等価性ゲートが、どのリファクタに対しても「呼び出し側が受け取るものが誰にも気づかれずに変わること」を防いでいます。

リリースライン¶

2.4: 出荷された形¶

現在のドキュメントにある製品の形を確立しました。3 つの検索層 (ベクトル・全文・キーワード) のランクによる融合、スコア付きでゲートを通した結果リスト、agent / project / channel による分離、ヘルスとメンテナンスのツール、PyPI のパッケージです。機能は凍結済みで、Stable の修正ポリシーだけを受けます。

2.5: 内側を安定させ、外側を保つ¶

目的。深い監査で脆いと分かった内部を、検索品質に手を入れる前に作り直すことです。中身は、1 か所にまとめた接続の層、1 つの分離ヘルパー、挙動を固定するテストハーネス、テストが実際に誤りを検出することを示す変異証明です。2.6 のリストにあるものはすべて recall のホットパスに触るので、このラインはその土台です。

互換性を崩してよいもの。内部アーキテクチャの互換性は自由に崩します。それがこのラインの主な狙いです。ツール契約は、契約の正直さや一貫性が上がる場合に限り、pre-release の段階を踏んで互換性を崩します。データベースのスキーマの互換性は崩しません。2.4 のデータベースは 2.5 で開け、元にも戻せます。

このラインに入ったほかのもの (どれも追加で、ロールバックできたため) は、サーバー側で強制されるクライアント別ケイパビリティ、その上の同一性層としての OAuth、サーバーが供給する運用コンテキスト、申告型セッション同一性、埋め込み索引の連続配置とチャンク走査 (下の階段の最初の 2 段)、走査窓を越える opt-in の到達範囲、拒否する前に警告するサイズ上限、更新の認知 (サーバーが「新しいバージョンがある」「取り下げられたバージョンである」と言えること) です。

どう閉じるか。 このラインの機能開発は止まっています。残る pre-release は修正で、 final は新しい挙動を運ぶ最後のバージョンになります。その後ラインは凍結し、本番で soak したうえで、Stable として認証するかどうかを決めます。この手順はライフサイクル標準に従います。

ランキングを変えるスコアリングの訂正は、意図して 2.6 に回しています。soak 中にランキングが変わると、デグレと見分けがつかないからです。

2.6: recall の品質¶

目的。2.5 が築いた土台の上で、何が返ってくるかを改善します。以下の各項目はランキングか到達範囲を変えます。それが、どれも 2.5 で出荷しなかった理由です。このラインの詳しい内容は Reliable Recall — 2.6 系にあり、想起プロセス・入力契約・出口・それぞれの測り方を扱います。この節はその索引です。

互換性を崩してよいもの。内部アーキテクチャとツール契約の互換性を、pre-release の段階を踏んで崩します。スキーマについては、追加のテーブルと列は想定内です (グラフと連鎖ノードがそれを必要とします)。再構造化は計画していません。

機能。どれも実測された問題に答えます。

Deliberative Recall (想起プロセス): recall が、1 回の呼び出しの中で有界かつ決定論的に反復するループになります。動的な検索窓を作り、取得し、評価し、見つけたものの手がかりを追って修正します。モデルが答える前に推論するのと同じ形で、しかもその反復にエージェントのトークンを使いません。

入力は Cued Recall (手がかり想起) です。エージェントが半分思い出していること (3 値の確信度を持つ時間の手がかり) を、フィルターではなく prior として宣言します。既定は off で、手がかりが無ければ出力は byte 単位で同一です。 - 適応的融合: このラインの中心となる機能です。ベンチマークは、字面の層が弱い埋め込みモデルを大きく助け、強いモデルをほとんど助けないこと、そして固定重みの融合がどちらの状況にいるかを判別できないことを示しました。目標は定数ではなく、モデル・コーパス・クエリに合わせて振る舞う融合です。 - 連想記憶: 宣言的なグラフ層です。エイリアスを持つ登録語と、エージェントが主張しサーバーが保存・走査する主語・述語・目的語の関係から成ります。設計として決定論的です。あいまいな拡張は試すたびにデグレを起こしたので、連想は、他の 2 経路が確率的であるところで正確な第 3 の検索経路になります。A/B で汚染のデグレが無いと示すまで、既定は off です。 - スコアリングにおける新しさと、最終再ソートの行方: 時間は、後段の再ランクだけでなく候補選抜の中で重みを持つべきです。測定は、現行の confidence 再ソートが有効な時、融合の順序を丸ごと上書きしていることを示しました。このラインで、その段を残すのか、新しさを融合の中の 1 項にするのかを決めます。走査窓の外にある「far」候補の重みも、同じ prior の特殊例として設計します。2.6.0a7 で決定: 再ソートは既定では走らず、 far の重みと経過時間の重みは、ゲートが通したものの順序を決める一本化した事前分布になります。既定値は計測の後にだけ動かします。 - 融合の深さと応答数の分離: 現状では 5 件を求めると各 retriever も 5 候補しか融合せず、測って分かるほど精度を下げています。深さは独立したつまみになり、limit は文字どおりの意味になります。 - 溢れ分の連鎖: 埋め込みの窓は最長の記憶より短いので、長いレコードの尾はベクトル検索から見えません。窓を超えるレコードは、それぞれが自分の埋め込みを持つ連鎖ノードに分割されます。応答はヒットしたノードを指し、残りはエージェントが取りに行きます。 - 再構成想起: retriever の候補を想起単位に組み立てる別ツールです。選択し、整列し、支える各行に役割を与えます。保存された記憶は一切変えず、保存していない文を合成することもありません。

その count は再構成窓です。エージェントに届くものの上限であり、サーバーがどこまで深く見たかとは分離されています。溢れ分の連鎖はその下部構造で、連鎖は自然なクラスタキーになります。 - 意味判断の委託経路: サーバーは候補を決定論的に列挙してエージェントに brief を渡し、エージェント (または選んだサブエージェント) が判断し、別のツールが verdict を明示的で検証済みの操作として適用します。「モデルを呼ばない」規則を保ちつつ、メンテナンスがモデルを使えるようにします。

このラインの序盤には複数の利用者にまたがって互換性を崩すという理由で、共有 vendored 層の MCP SDK 2.0 移行も載ります。(かつてここに載っていた埋め込み呼び出しのネイティブな {attempted, ok, error} 結果は、既存の戻り型に触れない追加の第 2 メソッドとして 2.5 で出荷済みです。)

「完了」の意味と、Go の索引サービスのように意図して条件にしないものは、ラインのページに書いてあります。各条件がどこまで進んだかは進捗のページにあります。

2.7: 記憶の知性¶

目的。ある記憶をどれだけ信用してよいか、そしてそれがどう変わったかを、サーバーが示せるようにします。2.6 は想起プロセスを作り、2.7 はそのプロセスに欠けている手がかりを与えます。証拠で重み付けされた確信度、訂正と矛盾の扱い、時間状態と履歴、忘却と保持の方針、想起が何に使われたかのフィードバック、コーパスが大きくなる中での品質劣化の制御です。

これらはそれぞれ、想起プロセスが追える手がかりになります。このラインの詳しい内容は Memory Intelligence — 2.7 系にあり、5 つの項目、各項目の設計の問い、まだ決まっていないこと、「完了」の意味を扱います。この節はその索引です。

このラインには実装されたものも測定されたものもまだありません。ラインのページは設計であり、決まっていない問いにはそう書いてあります。

2.8: まだ候補¶

認知のホメオスタシス。エージェントが自分の記憶環境を観測し、健全に保てることです。auditor の profile 群がエコシステムに育つこと、健全性・警告・更新の認知・構成診断、変更の前後での再監査、修復を囲む方針と権限の境界、ロールバックを含みます。有界で opt-in の修復 (承認された修復を適用して再監査する conformer で、観測だけを行う auditor とは分けたもの) は、この境界と一体なので、ここに置きます。当初は 2.7 に挙げていたものです。番号は暫定です。重要なのは能力の境界であり、切り直されることがあります。何を載せることになっても、2.8 は 3.0 の変換器が読むバージョンです。

3.0: 持続する同一性と、グラフ計画の残り¶

目的。モデル・サービス・端末を越えた、経験・理解・自己認識の連続性です。自伝的・時間的・関係的な記憶、運用上の自己モデル、複数のクライアントと複数のモデルを同時にまたぐ継続を含みます。ランタイムの軸では、ここがサーバー本体の大部分が Go になると見込む場所です (下記)。同じメジャーバージョンなのは、そのためです。

互換性を崩すもの: 保存層。階段のこれまでの段はどれも、データが SQLite の行にあるという 1 つの事実を回避するものでした。費用は今、そこに集まっています。埋め込みを SQLite からメモリへ出すことがベクトル検索のボトルネックで、コーパス全体に一致する問いでは、全文検索の層 (SQLite の FTS5) が、10 万行で 1 回の recall の 70% を占めました (測定)。そのため 3.0 は保存層を置き換え、3.0 のサーバーは 2.x のデータベースを開きません。

移る方法は 2.8 のデータベースを 3.0 の保存先へコンパイルする変換器です。サポート期間は 3.0 のリリース時に示します。それより前の 2.x のデータベースは、すべての 2.x アップグレードと同じく、まずその場で 2.8 に上げます。まだ決まっていないこと: SQLite を何で置き換えるか (SQLite 固有のボトルネックと、どの保存先でも残るボトルネックを分けた後に選びます)、そして誰かに変換を実行してもらう前に、変換が正しいことをどう示すか。

画像を含む記憶。 エージェントの経験はテキストだけではありません。作業の記録にはすでにスクリーンショットや図があります。3.0 は画像を 4 つのものとして保存します。元の画像。モデルの画像入力の上限に合わせた複製と、その費用 (トークン数) の記録 (recall がその分を予算に入れられるように)。エージェントが書く説明と、画像の中に見える文字 (サーバーは引き続きモデルを呼ばないため)。そして、検索用の画像埋め込み (埋め込みプロセスが作ります)。モデルに渡す形を、事前に計算した視覚トークンではなく画像にするのは、たとえば Claude API が画像をバイト列・URL・アップロード済みファイルとして受け取り、ほかの場所で計算した視覚トークンを受け取る入口がないからです。元の画像を残すのは、新しいモデルや、より良い変換が、残りを作り直せるようにするためです。音声と動画は、それ自身の設計ができるまで範囲外です。

以前の計画は 3.0 を「グラフのリリース」としていました。エンティティと関係のテーブル、エッジ上の bi-temporal モデル、モデル駆動の記憶進化を 3 つのサブフェーズで、という計画です。その後に動いたものと突き合わせて仕分けると、次のようになります。

以前の 3.0 の項目	今の位置
グラフ記憶 (エンティティ・エッジ・言及)	2.6 の連想記憶として前倒しし、設計もやり直しました。モデル駆動のエンティティ抽出ではなく、宣言された関係とエイリアスの正規化。
bi-temporal なエッジ (`valid_from` / `valid_to`、時間クエリ)	時間状態と履歴として 2.7 に前倒し。旧設計はモデルに日付を抽出させていましたが、「モデルを呼ばない」規則の下では、有効期間はエージェントが主張し、サーバーが保存して問い合わせます。
完全な記憶進化 (遡及的なエッジ更新・剪定・強化)	未定。モデル駆動の形は外れました。残るのは、2.6 の委託経路とメンテナンスツールがまだ覆っていない決定論的な統合のうち、何であれ必要なものです。
サブフェーズ化 (機能ごとの alpha → beta → final)	このページのライン構造に置き換えられました。

3.0 の先の方向はインフラです。権限を分離した組織の記憶、個人・共有・公共の知識の境界、組み込み用途のために MCP を通さない経路です。これは計画ではなく、方向として述べています。

ランタイムとスケールの階段¶

既定のインストールの目標は 1 ファイル・小さなマシン・数百万行です。数億行は opt-in、または専用の別サービスになります。

10 万行のコーパスで測ると、ベクトル検索のボトルネックは演算ではなく、埋め込みを SQLite からメモリへ出すところでした。階段はそこを 1 段ずつ改善し、各段は前提が満たされないときに 1 つ下の段へ切り替わります。

段	何	状態
0	SQLite から読んだ埋め込みの全走査	基準
1	チャンク化した厳密走査 (ピークメモリを抑える)	2.5 で出荷
2	データベースの隣に置く厳密 float32 の連続索引 (近似なしで数倍速い)	2.5 で出荷
3	バイナリの粗い候補生成 + 厳密な再ランク。最初の Go コンポーネント (sidecar プロセス) で、劣化ゲートが要る最初の段	設計済み。おおよそ 100 万行で有効になる
4	近似最近傍	opt-in、または専用の埋め込みサービス
5	字面の層の費用 (コーパスの大きさでなく、一致した行数に比例して増える)	測定中

Go への移行は段階的に進みます。新しいコンポーネントと測定されたボトルネックが先で、サーバー本体は後です。Python はリファレンスランタイムとして、また、どんな移植も再現しなければならない挙動 golden の生成器として残ります。境界を in-process の拡張でなく sidecar プロセスにしているのは、PyPI パッケージを pure Python のままにするためです。

このページを正直に保つ方法¶

項目に書くのは、チケットではなく理由です。ラインの目的が変わったら、このページは決定とともに変わります。機能が出荷されても、ここで「完了」と印は付けません。それはリリースノートの仕事です。このページと出荷されたリリースが食い違ったら、正しいのはリリースで、その食い違いは報告に値します。