Mads ThinesがLoreKitを立ち上げ、コーディングエージェントにローカルで検査可能なメモリを提供

Why it matters

LoreKit turns agent memory into developer-owned project artifacts, giving Thines a low-friction route from a free local tool to a shared hosted service. ([LoreKit](https://www.lorekit.io/blog/give-your-agent-a-memory?ref=runtimewire))

Mads Thines、コペンハーゲン拠点のデザイナー兼プロダクトエンジニアが、AIコーディングエージェントに過去のミスや修正、プロジェクト固有の教訓を記録させるオープンソースのメモリーレイヤーLoreKitを立ち上げた。初期のワークフローは開発者のマシン上で完全に動作し、メモリをアカウントやホスト型データベースを要求する代わりに読みやすいMarkdownファイルとして保存する。Thinesはローカル設定を8月15日のブログ投稿で詳述している。

このプロジェクトは、Thinesがエージェント向けの自律的ワークフローを構築するのに費やした約2年から生まれた。彼は、セッション終了後にエージェントが同じ環境情報やデバッグ修正を繰り返し再発見していることに気づいた。彼の最初の解決策はローカルファイルのコレクションだった。LoreKitは、その教訓がメモリシステムを単一のエージェントホストに結びつけることなく、マシン間、チームメイト間、継続的インテグレーションのジョブ間で移動できるようにしたいという欲求から生まれた。（Redditのローンチ投稿）

Thinesのエージェントインフラへの道は、AI研究というよりプロダクト作業に根ざしている。彼の公開プロフィールは、observabilityスタートアップDash0で働くコーダー兼デザイナーと記載しており、LinkedInにはフロントエンドとプロダクトエンジニアリングに移る前のグラフィックデザインでの訓練と仕事が記されている。LoreKitはその背景を反映しており、中心的な賭けは、開発者が既に理解しているツールで検査・編集できるメモリシステムに置かれている。（LinkedIn）

メモリはファイルであり、隠れたモデルプロセスではない

開発者はLoreKitのCLIとMCPサーバーを次のコマンドでインストールする：

npx @lorekit/cli install

インストーラーは3つのエージェントスキル、MCPサーバーのエントリ、およびサポートされる環境向けのライフサイクルフックを追加する。LoreKitのホームページはClaude Code、Cursor、Codexの名前を挙げているが、リポジトリにはMCP互換のクライアントであれば同じメモリツールを使用できると書かれている。（LoreKit）

ローカルモードでは、開発者はローカルストレージを選び、MCPエントリをCLIのローカルサーバーに向ける.lorekit.jsonファイルを追加する。メモリはその後 ~/.lorekit/ やリポジトリ内の .lorekit/ ディレクトリの下に保存される。各ファイルはMarkdownとYAMLフロントマターを含み、scope、key、タイムスタンプ、教訓が何度遭遇したかといったフィールドがある。（LoreKitのローンチ投稿）

Thinesが公開した例では、Postgresコンテナが動作していないために統合テストが失敗する。LoreKitのフックは修正を保存することを提案するが、ソフトウェアは自動的にセッションを記録するわけではなく、モデルが memory.write を呼び出す必要がある。Thinesが作成したメモリは、後のセッションに対してデータベースを起動してから ECONNREFUSED 5432 をコードの欠陥の証拠として扱うように指示する。例は創業者によるデモンストレーションであり、システムの独立したテストではない。（LoreKitのローンチ投稿）

その設計により、開発者は可視の監査証跡を得られる。メモリは開いて検索（grep）でき、リポジトリにコミットされ、編集や削除が可能だ。Thinesはまたエントリを助言的な観察と表現している。意図的なルールは CLAUDE.md のようなファイルに依然として置かれ、人間がレビューしてバージョン管理できるべきだとする。LoreKitは、最終的にルールになるかもしれないし、期限切れになるかもしれないし、有用な警告として残るかもしれない、低い信頼度の運用知識を保持する。（LoreKitのローンチ投稿）

ローカルメモリは普及の足がかり

LoreKitのローカルモードは、エージェントメモリを試すためのコミットメントを下げる。開発者は認証、ネットワークアクセス、あるいは新しいマネージドデータストアなしでツールを実行できる。この選択はまた、リポジトリのコンテキストや内部のデバッグ教訓を外部サービスに送ることに抵抗を示すチームへの道も開く。

ホストされた製品は個人ノートを共有システムに変える。Thinesによれば、ユーザーはアカウントを作成し、APIキーを生成してCLIをLoreKitのリモートPostgres対応ストアに向けることができる。ソフトウェアは既存のローカルファイルをディスク上に保持し続け、list コマンドは両方の場所からのエントリを提示する。古いローカルの教訓をチームメイトやCIと共有するには、ユーザーが別の移行コマンドでそれをプッシュする必要がある。（LoreKitのローンチ投稿）

Thinesによれば、ストレージの選択はLoreKitの検索ロジックの下位に位置する。スコープの優先順位、ランキング、重複排除、コンテキスト予算は、ソフトウェアがローカルディレクトリから読む場合でもホストされたデータベースから読む場合でも一貫して機能するはずだとされている。そのアーキテクチャはLoreKitのローンチ資料で説明されているが、独立してテストされたわけではない。（LoreKitのローンチ投稿）

組織はリポジトリのスコープを共有ストアにバインドし、閲覧者、メンバー、管理者、オーナーの役割を割り当てることができる。ローンチ投稿で説明されている無料のホスト層は最大5,000件のメモリと毎分120リクエストをサポートする。読み取り専用トークンはパイプラインがそれらを変更できないようにしながらCIにチームの教訓を公開できる。これらの制限と権限は企業が提供する製品仕様である。（LoreKitのローンチ投稿）

LoreKitはより狭いメモリ主張をする

エージェントメモリは独自のソフトウェアカテゴリになってきている。Mem0は自動抽出、信頼度と減衰スコアリング、衝突処理を備えたマネージドメモリインフラを販売している。（Mem0の紹介、長期記憶ガイド、およびメモリ減衰の発表）以前はMemGPTと呼ばれていたエージェント開発プラットフォームLettaは、構造化されたエージェントが編集可能なメモリブロックをエージェントのコンテキストに直接置く。LangMemはLangGraphベースのアプリケーション内で意味的、エピソード的、手続き的メモリを抽出、統合、検索するためのツールを含む。（LangMemのドキュメント）

LoreKitは現在、その多くの仕組みを避けている。検索は語彙的であり、埋め込みや意味検索ではなく、再出現、最新性、スコープ、語の重なりを使う。そのためパラフレーズされたクエリは関連する教訓を見逃す可能性がある。Thinesはシステムを6件から60,000件のメモリでロードテストしたと述べているが、そのパフォーマンス数値は自己申告であり検索品質を確立するものではない。公開資料には独立した検索ベンチマークは引用されていない。（Redditの議論）

より狭い設計はLoreKitの魅力の中心だ。それはエージェントのメモリを明示的な出所と人間の管理を伴う蓄積されたプロジェクトノートとして扱う。これにより、なぜある教訓がその文脈で現れたのかを理解しやすく、誤ったものになった教訓を削除しやすくなる。

矛盾するメモリや陳腐化したメモリは依然として難しい問題だ。LoreKitはブランチ固有のスコープとtime-to-live値をサポートし、一時的なノートが期限切れになると自動的に見えなくなるようにする。Thinesは、教訓を修正、昇格、削除する判断を開発者に委ねており、エージェントに自身の振る舞いから学ぶことを求めるシステムにとって重要な制約であると述べている。（LoreKitのローンチ投稿）

LoreKitは初期段階にあり、ホスト型サービスはローカルのMarkdownでは生じない疑問を生む。たとえばチームが機微なメモリをどのように評価し、誤った教訓が複数のエージェントに拡散するのを防ぐかといった問題だ。Thinesのローカルファーストアプローチは、運用上のコミットメントを行う前に開発者が基礎となるアイデアを実用的に試す方法を提供する。最初に役立つメモリは、彼らが読めるファイルであり得る。