ほとんどのAIコーディングアシスタントは、各ストアで埋め込みAPIを呼び出して保存および取得を行うことでメモリの問題を解決します。これはスケールしません。1日あたりのセッションが15〜25件だと、何百ものAPI呼び出し、書き込みごとの待機、そして価格をいつでも変更できるサービスへの依存を意味します。
Claude Code内で動くメモリライフサイクルシステムには埋め込みが必要でした。システムは知識を5つの段階で処理します：バッファ、接続、統合、ルーティング、経年。埋め込みはフェーズ2〜4を推進します（接続追跡、クラスタ検出、類似性ルーティング）。
要件：1024次元ベクトル、コサイン類似度が0.75を超える場合、それが実際の意味的関連性を意味しなければならない、20件以上のエントリのバッチ処理、ゼロAPI呼び出し。
いくつかのモデルを試し、ONNX Runtimeを介してINT8に量子化したQwen3-0.6Bに決定しました。最初の直感的な選択ではありませんでした。Sentence-transformersモデルはデフォルトの選択のように見えましたが、1024次元のQwen3-0.6Bは、実際に関連するエントリと構造的ノイズ（形式は同じでもトピックが異なるセッションログ）をより良く分離しました。
コールドスタート問題：ONNXモデルのロードに約3秒かかります。全てのツール呼び出しが埋め込みチェックをトリガーするフックベースのシステムにおいて、それは使えません。解決策：起動時に一度だけモデルをロードするlocalhost:52525にある永続的な埋め込みサーバー。ウォーム推論：バッチあたり約12ms、コールドスタートの約250倍高速。
サーバーは起動フックを介して自動的に起動します。ダウンした場合、システムは直接ONNXのロードにフォールバックします。壊れることはなく、単に遅くなるだけです。
埋め込みが有効にするもの：
接続グラフ：新しいエントリは、コサイン類似度0.75を超える既存エントリにリンクされます。孤立したエントリは時間とともにフェードします。結合されたエントリは生き残ります。有効期限は孤立に基づき、時間ではありません。
クラスタ検出：3つ以上の結合エントリのグループは、LLM（Gemini Flashの無料枠で統合）によって検証済み知識に統合されます。
類似性ルーティング：検証済み知識は、既存コンテンツとの埋め込み距離に基づいて適切な設定ファイルへルーティングされます。
CPUのみ、GPU不要。0.6Bモデルは現代のほぼ全てのマシンで動作します。単一のPythonスクリプト、約2,900行、SQLite + ONNX。
オープンソース: github.com/living0tribunal-dev/claude-memory-lifecycle
閾値決定と障害モードを含む完全なエンジニアリングストーリー：3,874件のメモリの後、私のAIコーディングアシスタントは有用なものを見つけられませんでした
生成よりもインフラ用途として小さなローカルモデルを使っている人は他にもいますか？埋め込みはサブ1Bパラメータの適切なユースケースのように感じます。
[リンク] [コメント]
