ロードマップ¶

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

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

翻訳について: 正本は英語版です。日本語版が古い場合は英語版を参照してください。

1 本の線ではなく 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 つの分離ヘルパー、挙動を固定するテストハーネス、そしてテストが噛むことを示す変異証明。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 系で、想起プロセス・入力契約・出口・それぞれの測り方を扱います。この節はその索引です。

破ってよいもの。 内部アーキテクチャとツール契約を、梯子を通して破ります。スキーマについては、追加のテーブルと列は想定内です (グラフと連鎖ノードがそれを必要とします)。再構造化は計画していません。

機能 — それぞれが実測された問題に答えます:

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 のままにするためです。

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

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