ロードマップ¶

各リリースラインがどこへ向かい、なぜそうなのか — 今どこにいるか、ではありません。進捗はリリースノートに、ラインの 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」は検索機能の集合を名指ししているだけで、階段をどこまで登ったかについては何も言いません。

決して変わらないもの¶

どのラインでも成り立ちます。これらのどれかを曲げないと成立しない機能は、予定に載せず、設計をやり直します。

サーバーは言語モデルを呼びません。 要約・抽出・判断はエージェントの仕事で、サーバーは決定論的に保存・索引・検索します。したがって記憶は生成 API の費用を一切足さず、結果はコーパスと設定から再現できます。
利用者が所有する 1 つの SQLite ファイル。 外部データベースも、データが依存するサービスもありません。埋め込みは別プロセスで、無くても動きます。
データベースのスキーマは前にしか進みません。 アップグレードはその場でマイグレーションします。追加 (新しい列・新しいテーブル) が通常形で、既存テーブルの再構造化には前例が無く、まだ存在しないマイグレーション設計が要ります。
劣化は報告され、隠されません。 ベクトル層を失った 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 の特殊例として設計します。
融合の深さと応答数の分離 — 今日、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 はそれに欠けている信号を与えます: 証拠で重み付けされた確信度、訂正と矛盾の扱い、時間状態と履歴、忘却と保持の方針、想起が何に使われたかのフィードバック、コーパスが育つ中での品質劣化の制御。これらはそれぞれ、想起プロセスが追える手がかりになります。有界で opt-in の修復 — 承認された修復を適用して再監査する conformer で、観測だけを行う auditor から分離されたもの — もここに置きます。

この項目にはまだ設計も測定もありません。2.6 がこれを吸収しないよう主題に名前を付けているだけです。ラインが開いた時に、詳細は 2.6 と同様のページへ移ります。

2.8 — ラインではなく候補¶

認知のホメオスタシス: エージェントが自分の記憶環境を観測し、健全に保てること — auditor の profile 群がエコシステムに育ち、健全性・警告・更新の認知・構成診断、変更の前後での再監査、修復を囲む方針と権限の境界、ロールバック。番号は暫定で、重要なのは能力の境界であり、切り直されることがあります。

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

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

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

以前の 3.0 の項目	今の位置
グラフ記憶 (エンティティ・エッジ・言及)	2.6 の連想記憶として前倒し — かつ再設計: モデル駆動のエンティティ抽出ではなく、宣言された関係とエイリアスの正規化。
bi-temporal なエッジ (`valid_from` / `valid_to`、時間クエリ)	3.0 の候補のまま。旧設計はモデルに日付を抽出させていましたが、「モデルを呼ばない」規則の下では、有効期間はエージェントが主張し、サーバーが保存して問い合わせます。
完全な記憶進化 (遡及的なエッジ更新・剪定・強化)	未定。モデル駆動の形は外れました。残るのは、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 のままにするためです。

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

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