Skip to content

Super Memory ​

Super Memory は Breezell が独自に開発した記憶システムです。Breezell に組み込まれた 2 つのモデルを使用して、会話から有用な情報を抽出します。これらのモデルの正式名称は公開されていません。

記憶の抽出は Breezell 内部のモデルパイプラインで処理されるため、ユーザーが設定したモデルのトークンやトークン枠は消費しません。

Super Memory が抽出できる情報 ​

抽出した情報は、次の種類に分類されます。

  • Memory: 後で役立つ可能性がある事実、設定、継続的な指示、決定事項。
  • Skill: タスクの中で見つかった再利用可能な方法やワークフロー。
  • Experience: 過去の作業から得られた結果、教訓、実践的な知識。
  • Trajectory: タスク、決定、目標が時間とともに進んだ過程。
  • Resource: 作業に関連する有用なファイル、リンク、ツール、参考資料。

これらの項目は会話から自動的に抽出、分類され、後のやり取りで関連するコンテキストとして呼び出せます。

記憶の表示と絞り込み ​

Super Memory パネル

パネルでは次の表示と操作を利用できます。

  • Memories、Context、Insights: 抽出された記憶、構成されたコンテキスト、記憶全体から得られた分析を切り替えます。
  • 検索: テキストを使用して保存済みの項目を検索します。
  • 優先度: P0、P1、P2、またはすべての優先度で絞り込みます。
  • 種類: Memory、Skill、Experience、Trajectory、Resource で絞り込みます。
  • 状態: Active と Dormant の項目を分けて表示します。
  • 容量カウンター: 項目の総数と、常駐項目、記憶、スキル、経験で使用している現在の容量を確認します。
  • Select: 選択モードを開き、管理する項目を個別に選択します。

項目が存在しない場合は、会話から記憶が自動抽出されることが表示されます。会話を続けると、ユーザーが手動で入力しなくても有用な項目がここに追加されます。

主な利点 ​

Super Memory は、強力な自動抽出と効率的で制御性の高い検索を組み合わせています。

  • 強力な抽出: Breezell 内部の 2 つのモデルが会話を分析し、有用な情報を Memory、Skill、Experience、Trajectory、Resource の構造化された項目に変換します。手動入力は必要ありません。
  • 効率的な検索: 種類、優先度、状態、鮮度、コンパイル済みメモリインデックスを使用して、保存済みのすべての項目を同等に扱うのではなく、現在のタスクに関連する情報へ検索範囲を絞ります。
  • 制御可能なコンテキスト注入: Context 画面では、現在のターンに注入されたスナップショット、次のターンのメモリインデックスプレビュー、推定トークン数を確認できます。
  • 明確なライフサイクル管理: P0 永続、P1 30 日、P2 7 日の優先度と Active、Dormant の状態を組み合わせ、重要な知識を維持しながら一時的な情報の保持期間を短くできます。
  • 確認可能な知識状態: コンパイル状態、ソースとコンパイラーのバージョン、古いリソース、失敗、検証、修正、鮮度、未同期件数を確認できます。
  • トークンの可視化: 抽出処理はユーザーが設定したモデルのトークンを消費しません。検索された記憶がリクエストに注入されると、そのリクエストのコンテキストに含まれます。プレビューと節約統計により、この使用量を確認できます。

Context と検索制御 ​

Super Memory の Context 画面

Context 画面では、会話で記憶がどのように使用されるかを確認できます。

  • Current Turn Injection: 現在の会話ターンに注入された記憶のスナップショットを表示します。スナップショットがない場合は、空の状態が明確に表示されます。
  • Memory Index Preview: 次のターン用に準備されたインデックスと推定トークン数をプレビューします。
  • Conversation Turns: 現在のスレッドのターン数を表示し、ターン単位の記憶利用を確認できます。

これにより、記憶が注入されたか、次に何が準備されるか、おおよそのコンテキストコストを確認できます。

Insights とシステム状態 ​

Super Memory の Insights 画面

Insights 画面では、記憶システムの状態と効果をまとめて確認できます。

  • Project Knowledge Health: 最終コンパイル、コンパイラーとソースのバージョン、古いリソース、失敗したコンパイル、検証または修正された件数を表示します。
  • Token Savings: 十分な利用記録がある場合にトークン節約量を表示します。
  • Viking Filesystem: Memories、Skills、Experiences、Trajectories、Resources、Unsynced の件数を表示します。
  • Priority Distribution: P0 永続、P1 30 日、P2 7 日の分布を表示します。
  • Freshness Pulse: 24 時間以内、7 日以内、30 日以内、それより古い知識に分類します。

Context と Insights により、Super Memory が何を抽出し、何を検索対象にする可能性があり、保存された知識がどの程度新しく健全であるかを確認できます。

Active と Dormant ​

Active の記憶は、関連する情報を呼び出すために利用可能な状態です。Dormant の記憶は保持されますが、Active の集合から分離されます。これにより、後で必要になる可能性がある情報を残しながら、現在のコンテキストを整理できます。

デモ:修復作業を再利用可能な記憶に変換する ​

この例では、意図的に不具合を含めた HTML タスクマネージャーを使用し、短い修復作業を Super Memory が再利用可能な知識に変換する過程を示します。

依頼では、想定された UI や機能を変更せずに、タスクの作成、削除、完了状態、フィルター、カウンター、localStorage の永続化、キーボード入力、完了タスクの削除に関する問題をコード全体から特定して修正するよう AI に求めています。

1. タスクマネージャーを調査して修復する ​

Breezell は各症状を別々の不具合として扱うのではなく、コードを調査して共通の根本原因を特定し、実装を修正して一連の動作を検証します。

タスクマネージャーを修復する Breezell

修復には、シリアライズと解析、重複読み込み、破損した保存データ、空タスクの検証、安定したタスク ID、キーボード操作、完了状態の切り替え、対象を指定した削除、フィルター、カウンター、完了タスクの消去が含まれます。

2. 最初の P2 Resource 記録 ​

小規模なテストであり、最初の結果が主に具体的なファイル編集を示しているため、Super Memory は test.html の 2 つの編集箇所を P2 Resource として最初に記録します。

修復から作成された P2 Resource 記録

この記録には、何をどこで変更したかが保存されます。短期的な実装の詳細には P2 の低い優先度を与えつつ修復履歴を残すため、後で AI が変更箇所を確認できます。

3. より深い振り返りを促す ​

この小規模なデモでは、ユーザーが次のように質問します。

この問題を解決して、どのような教訓を得ましたか?

修復から得た教訓をまとめる AI

回答では、共有状態の所有元を直すこと、コレクション要素を安定した ID で扱うこと、派生状態をすべての描画経路で再計算すること、永続化を検証済みデータ境界として扱うこと、真偽条件を慎重に確認すること、不正な入力経路を終了させること、時刻だけを ID にしないこと、現実的な一連の操作で機能を検証することなど、再利用可能な教訓が抽出されます。

4. 構造化された修復知識を抽出する ​

修復をより深く検討した後、Super Memory は価値の高い構造化項目を追加します。

  • 共有タスク状態と安定した ID の修復に関する P1 Experience。
  • 保護されたシリアライズと解析によって破損した localStorage 永続化を修復する P1 Skill。
  • 複数の不具合と解決過程をまとめた P2 Trajectory。
  • 編集箇所を保存する最初の P2 Resource 記録。

振り返り後の構造化された修復記憶

このデモで分かること ​

  • 抽出の深さは価値に応じて変化します: 小さな編集は P2 Resource から始まり、再利用可能な根本原因の知識は P1 Skill や Experience として記録されます。
  • 記憶の種類ごとに役割が異なります: Resource と Trajectory は何が起きたかを、Skill と Experience はどのように、なぜ解決したかを保存します。
  • 優先度を制御できます: P1 は再利用性の高い知識を長く保持し、P2 は短期的な詳細を永続的な重みを与えずに利用可能にします。
  • 将来の AI 作業で利用できます: 後のタスクでは元の会話だけに頼らず、関連するファイル履歴、修復方法、エンジニアリング上の教訓を検索できます。
  • 通常は手動で質問する必要はありません: この質問は小さなテストで明確な結果を示すために使用しています。長期的または重要な不具合では、ユーザーが質問しなくても Super Memory が永続的な修復経験を自動的に検出、記録できます。

詳細分析:Memory が空である理由 ​

この例を Memory で絞り込むと 0 件と表示されますが、Super Memory は有用な知識の抽出に成功しています。

修復後も空の Memory カテゴリ

これは抽出の失敗ではなく、意図的な分類です。この修復では、一般的な Memory に保存すべき永続的な個人設定、安定したユーザー情報、継続的な指示は生成されませんでした。すべてを汎用メモリとして重複保存せず、Super Memory は将来の用途に適した Skill、Experience、Trajectory、Resource に分類します。

Skill:再利用可能な localStorage 復旧パターン ​

P1 Skill は、特定の修復をクライアント側状態の永続化に再利用できる手順へ変換します。

展開された localStorage 修復 Skill

カードには次の情報が表示されます。

  • タグ: localStorage、JSON、状態の復元、データリカバリーにより、関連する問題から検索しやすくなります。
  • L1 Overview: タスク配列を JSON.stringify で保存し、保護された JSON.parse で読み込み、有効な読み込み後に初期データを追加せず、復旧できない古い値を破棄して正常な既定値へ戻します。
  • Why Remembered: 状態を持つクライアントアプリで再利用できる、検証済みの永続化と復旧パターンとして記録された理由を示します。
  • L2 Full Content: 詳細な失敗原因と完全な復旧手順を保存します。
  • メタデータ: P1 優先度、種類、状態、確認回数、参照回数、最終更新、ライフサイクルを確認できます。

localStorage を修正したという曖昧なメモではなく、将来の AI が再利用できる具体的な手順になっています。

Experience:共有状態と安定した ID の診断 ​

P1 Experience は、複数の UI 不具合に共通するエンジニアリング上の教訓を保存します。

展開された共有状態修復 Experience

タスク、フィルター、カウンター、永続化が同時に失敗した場合は、共有するタスク配列と状態遷移から調査する必要があることを示します。また、衝突しない安定した ID と、入力検証、キーボード操作、フィルター、カウンター、消去、再読み込み後の永続化をまとめて再確認する一連のテストも記録します。

タグには状態管理、デバッグ、UI、安定した ID、不変条件、テスト、localStorage が含まれます。Why Remembered は、1 つの状態モデルに依存する機能を検証する再利用可能なチェックリストである理由を示します。

Skill は繰り返し使える修復方法を、Experience は診断の考え方、不変条件、検証戦略を保存します。

Trajectory:実際の修復経路を保存する ​

P2 Trajectory は最終的な教訓だけでなく、タスクがどのように進んだかを保存します。

展開された Task Manager 修復 Trajectory

元の目標、復旧した結果、ツールの順序、復旧可能な 1 件のエラー、その後の成功手順、最終結果が含まれます。この例では、コード読み取り、ディレクトリ確認、To-Do 管理、ファイル編集、ブラウザー操作、評価にわたる 14 回のツール呼び出しを記録しています。

P2 と unverified のラベルにより、この短期的な実行履歴は再利用性の高い P1 Skill、Experience と分離されます。正確な作業経路を確認する必要がある場合に利用でき、重要な結論はより長く使える形式で保持されます。

この分類が重要な理由 ​

  • Memory は永続的な事実、設定、継続情報を保存しますが、このテストでは生成されませんでした。
  • Skill は再利用可能な解決方法を保存します。
  • Experience は根本原因の考え方と検証チェックリストを保存します。
  • Trajectory は操作、エラー、復旧の順序を保存します。
  • Resource は具体的なファイルと編集箇所を保存します。

この分離により、検索の精度と制御性が保たれます。将来のタスクは、1 つの大きな汎用メモリを読み込まずに、方法、教訓、実行履歴、変更リソースを個別に取得できます。

検証:新しい会話と別のアプリで再利用する ​

2 回目のテストでは、抽出された知識が元の Task Manager の会話を離れても役立つかを確認します。

古い会話を削除し、別の HTML アプリである test2.html の Reading Library 用に新しい会話を作成します。データモデルはタスクではなく本を扱いますが、状態、ID、フィルター、カウンター、キーボード、削除、localStorage に同じ種類の不具合を意図的に含めています。

1. 別の会話から開始する ​

別の会話で開始した Reading Library テスト

デモでは、変更前に関連する記憶、過去の教訓、学習済みパターンを確認するよう Breezell に明示しています。これにより検索の様子を確認できます。通常は、この指示がなくても Super Memory が関連する知識を自動的に呼び出せます。

2. 削除された会話から知識を呼び出す ​

test2.html を編集する前に、Breezell は保護された JSON 読み込みに関する以前の P1 Skill と、古い test.html の編集箇所を示す P2 Resource を呼び出します。

Skill と Resource を呼び出す Breezell

ここでは 2 種類の検索が行われます。

  • Skill: 保護された JSON.stringify と JSON.parse、破損した古いデータの安全な拒否、正常な既定値の復元という再利用可能な永続化パターンを提供します。
  • Resource: 以前のファイルで変更された場所を示し、学習したパターンの具体的な出所を保存します。

このテストでは、元の会話を削除しても、そこから抽出された構造化 Super Memory 項目は削除されず、後の会話で利用できました。

3. 古いパッチではなく方法を転用する ​

Breezell は古い tasks 配列向けのコードをコピーせず、以前の教訓を Reading Library の共有 books 状態に適用します。

呼び出した知識で修復された Reading Library

新しい修復には次が含まれます。

  • 保護された JSON のシリアライズと解析。
  • 復旧できない古い値の安全な削除。
  • 有効な空のライブラリをサンプル本の重複なしで読み込む処理。
  • 衝突しやすい時刻ではなく決定的で一意な本の ID。
  • 既読・未読カウンター、フィルター、空の表示状態。
  • 状態切り替え、対象を指定した削除、既読本の消去。
  • 入力検証と Enter キーだけによる送信。
  • 各本の安定した ID を使用するイベント処理。

Breezell は 14 項目のブラウザーワークフローで検証し、完了後にテスト前の localStorage 値を復元します。

2 回目のテストで分かること ​

  • 構造化された知識は元の会話を離れても残ります: 古い会話を削除しても、このテストでは Skill と Resource を呼び出せました。
  • 異なる実装にも一般化できます: 状態と永続化の構造が共通しているため、Task Manager で学んだパターンを Reading Library に適用できます。
  • Skill はパッチ履歴以上のものです: P1 Skill は再利用できる方法を提供し、P2 Resource は具体的な実装履歴を残します。
  • AI は根本原因を修復します: 古いコードを行単位で再現せず、共有状態、安定した ID、永続化境界、エンドツーエンド検証の原則を転用します。
  • 明示的な呼び出しは任意です: デモを見やすくするために記憶の確認を依頼しています。通常は関連する Super Memory 項目が自動的に呼び出されます。

常駐メモリ(P0) ​

現在のリクエストと意味的に一致しない場合でも、毎回のメモリ検索で利用したい Super Memory 項目は Resident に設定できます。

項目を常駐に設定する ​

メモリカードのピンアイコンにカーソルを合わせるか選択します。Set resident のツールチップがこの操作を示します。

メモリカードの常駐設定

設定後は次のようになります。

  • 優先度が P0 になります。
  • カードに Resident ラベルが表示されます。
  • 常駐状態を示すピンが強調表示されます。
  • 常駐容量カウンターが増加します。この例では Resident 1/12 になります。
  • P0 フィルターに表示されます。

P0 Resident に昇格したメモリ

P0 は永続的な優先度です。期間が設定された P1、P2 と異なり、ユーザーが常駐状態を解除するまで利用可能です。

新しい会話への常駐注入 ​

Super Memory が検索を実行すると、常駐項目は意味的な関連性とは別に注入されます。

新しい会話に注入された常駐メモリ

例では新しいチャットの入力が「Hello」だけでも、状態には次のように表示されます。

Injected 1 memories (1 resident · 0 relevant)

関連性で一致する追加メモリが 0 件でも、P0 Resident が 1 件注入されたことを示します。重要な知識をすべての検索サイクルで確実に利用できます。

P0 を使用する場面 ​

重要なアーキテクチャ上の不変条件、必須ワークフロー、長期的な復旧規則、常に必要な設定など、AI を一貫して導く情報に使用します。

一時的なファイル位置、一度限りのタスク詳細、大きく価値の低い記録は常駐させないでください。常駐項目はリクエストのコンテキストに注入され、すべての回答に影響する可能性があるため、簡潔で汎用的な内容にします。画面上の常駐容量は最大 12 件です。

常に呼び出す必要がなくなった場合は、強調表示されたピンをもう一度選択して Resident を解除します。