Show HN: 二層メモリ – AIコーディングエージェントのためのクエリ可能な長期記憶

AIコーディングエージェントのデフォルトの長期記憶は、セッション開始時にMarkdownファイルをコンテキストウィンドウにすべて読み込む方式です。ファイル数が10程度なら機能しますが、140を超えるとすべてが限られたウィンドウを奪い合い、限界を超えた部分は静かに切り捨てられます。エージェントは過去の解決策を忘れ、既に解決した問題を再解決し、先週の決定と矛盾する行動を取ります。多くの人はモデルのせいにしますが、真の問題はファイルシステムにあります。これは1970年にデータベースが解決した古い問題です。構造化して保存し、インデックスを作成し、必要な行だけを取得する。

このプロジェクトは二層メモリアーキテクチャを提案します。第一層は常にロードされるインデックス（INDEX.md）で、各課題はタイトルとポインタのみの1行で表現され、コンテキストをほとんど消費しません。エージェントに「何が存在するか」だけを伝え、詳細は含めません。このインデックスは第二層のデータベースから自動生成されるため、ずれることはありません。第二層はオンデマンドでクエリされるSQLiteデータベースで、すべての困難な問題が行として保存されます。問題、根本原因、解決策、注意点、成果物などが含まれます。1000行あっても、クエリを実行するまではコストゼロです。何かが既知の問題に似ていると感じたとき、エージェントは文章を探し回る代わりにテーブルに問い合わせます。

使い方は簡単です。python3 memory.py init で初期化し、memory.py add でレコードを追加（エリア、タイトル、問題、根本原因、解決策、注意点、タグを指定）、memory.py query で全文検索（FTS5）、memory.py index でINDEX.mdを再生成します。依存関係はPython 3とその組み込みsqlite3のみで、追加インストールは不要です。

作者はツールだけでは罠だと警告します。習慣と衛生管理が不可欠です。エージェントには「まず記憶を検索してから行動する」というルールを徹底させなければ、データベースは死重になります。レコードは解決当日に書き、間違っていたらすぐに削除・更新します。古いレコードは空のテーブルよりも誤解を招きます。また、現在の全文検索はマッチした単語を見つけるだけで、意図した行を正確に取得できるとは限りません。将来、セマンティック検索や埋め込みをこのリレーショナルベースに追加することを検討すべきですが、最初から始めてはいけません。

エージェントへの統合は、プロジェクトの指示に二つのルールを追加するだけです。新しい困難な問題に直面したら、まず検索してヒットしたらその結果を利用する。新しい問題を解決したら、レコードを追加し、インデックスを更新する。常にロードされるINDEX.mdがエージェントに既知の情報を伝え、データベースが詳細を保持することで、コンテキストウィンドウの問題を回避します。ソースコードはschema.sql（FTS5トリガー付きテーブル定義）、memory.py（CLI）、自動生成されるINDEX.mdとmemory.dbで構成され、MITライセンスで公開されています。