OKF Agent Memory：AIコーディングエージェント向けGitネイティブ永続メモリ、トークン消費を80%削減
OKF Agent Memory – Git-native persistent memory for AI coding agents
OKF Agent Memoryは、AIコーディングエージェントの会話がコンテキストウィンドウの終了とともに失われる問題を解決する、Gitネイティブな永続メモリレイヤーです。GoogleのOKF v0.2仕様に準拠し、知識をリポジトリ内のMarkdownファイル（YAMLフロントマター付き）として保存。インメモリBM25検索により検索レイテンシは300µs未満、グラフ検証は約4msで、PythonやベクターDBベースのソリューション（Mem0、Lettaなど）と比較して圧倒的な速度を実現します。外部データベースやAPIコストは不要で、純Go製の単一バイナリは依存関係ゼロ。MCPサーバーを内蔵し、Claude CodeやCursorなどのエージェントとシームレスに連携します。プログレッシブディスクロージャーによりコンテキスト肥大化を防ぎ、トークン消費を最大80%削減します。
AIエージェントとの会話は、コンテキストウィンドウが閉じるとリセットされます。貴重なアーキテクチャ上の決定、ドメインの発見、運用上の事実は、永続的に保存されない限り失われます。
HNでの議論
31- opwizardx
なぜ仕様自体がこんなに単純なのに、MCPサーバーが必要なのですか？
- langs
理解できません。なぜレイテンシをベンチマークするのであって、再現率や適合率をベンチマークしないのですか？ミリ秒単位のレイテンシを最適化することは、LLM呼び出しの文脈では無意味です。精度こそがツールの最大の価値なのに、それに対するテストがないのはなぜですか？
- straumat
素晴らしいツールですね！あなたのOKFバンドルを人間が読める形で公開したい場合（GitHub Pagesや社内イントラネットなど）、私が開発したオープンソースのソリューションがあります：https://github.com/oak-invest/kiso - OKF向けのHugoのようなものです。
- kimseungyong
アイデアは気に入っています。コンテキストを失わないようにするために、私は主にプランニングセッションと実装セッションを分けて行っています。エンタープライズ製品を構築するという観点から、私が最も心配しているのは、実装しているエージェントがまったく異なるコンテキストを理解していない可能性があることです。okf_memoryがドメイン知識を非常によく維持してくれるなら、一貫したスムーズなセッション内でユニット機能単位での実装が可能になることが期待されます。しかし、このアイデアを実務に直接適用するにはリスクがあるため、個人的なプロジェクトで別途テストする必要があります。
- calebkaiser
このようなプロジェクトを見るのは大好きです。パフォーマンスベンチマークが見られるのは嬉しいですね。トークン使用量やタスク完了率などについて、OpenAIのSymphonyのようなアプローチと比較したベンチマークは行いましたか？