AIコーディングエージェントの記憶を、ベクトルDBを立てずにGitリポジトリだけで永続化する方法はあるのか——あります。2026年9月に入ってHacker Newsで75ポイントを集めた「OKF Agent Memory」は、GoogleのOpen Knowledge Format（OKF）v0.2仕様に準拠したMarkdownファイル群を knowledge/ ディレクトリとしてリポジトリに置き、依存ゼロのGo製CLIとMCPサーバーで検索・検証するオープンソースのメモリ層です（MITライセンス）。
CLAUDE.mdやAGENTS.mdのような「1枚の巨大メモ」と、Mem0・Lettaのような「ブラックボックス化しがちなベクトルDB」の中間を狙った設計で、エージェントの記憶をgit diffでレビューできる点が議論を呼んでいます。この記事では、2026年9月7日時点の一次情報（GitHubリポジトリとOKF公式仕様）をもとに、何が公開されたのか、既存手法と何が違うのか、日本企業のエージェント運用にどう組み込めるのかを整理します。
OKF Agent Memoryとして公開されたもの
OKF Agent Memoryは、単一のライブラリではなく「仕様＋運用規約＋ツール」の積層で構成されたプロジェクトです。リポジトリのREADMEでは次の5層アーキテクチャとして説明されています。
- OKF v0.2仕様：Markdown＋YAMLフロントマターの規範フォーマット（Google公開の外部仕様を採用）
- Agent Memory Convention：検索・レビュー・信頼度に関する行動ルール（v0.1）
- Agent Skill：LLM向けプロンプトと運用ワークフローの定義
- ツール層：Goライブラリ＋CLI（パース・検証・検索・MCPサーバー）
- 知識コーパス：プロジェクトごとの
knowledge/OKFバンドル
要するに「エージェントの長期記憶を、リポジトリ内のプレーンテキストとして規格化する」試みです。記憶の実体は knowledge/ 配下のMarkdownファイル群（バンドル）で、各ファイルが1つの「Concept（概念）」を表し、YAMLフロントマターに出所（provenance）・信頼区分（generated / verified）・鮮度（stale_after）・ライフサイクル（status）のメタデータを持ちます。
READMEが掲げる特徴のうち、設計判断として重要なのは次の3点です。
1. 記憶がgit diffでレビューできる
すべてがバージョン管理されたプレーンテキストなので、エージェントが書き込んだ記憶を git diff と git log で監査できます。外部データベースは不要です。「AIが何を覚えたか」をプルリクエストの差分としてレビューできるのは、ベクトルDB型のメモリにはない性質です。
2. 検索は埋め込みAPIを使わないローカルBM25
概念検索はインメモリのBM25（語彙ベースのスコアリング）で行い、埋め込みベクトルの生成APIを呼びません。リポジトリ記載の自社ベンチマークでは、検索レイテンシ300マイクロ秒未満・コーパス全体のパースとグラフ検証が約4ミリ秒・バイナリ起動4ミリ秒未満とされています（プロジェクト側の計測値であり、第三者検証値ではない点に注意。後述のコミュニティの反応も参照）。検索1,000クエリあたりのAPIコストはゼロです。
3. Progressive Disclosure（段階的開示）でコンテキスト肥大を防ぐ
階層化された index.md とリンクグラフを使い、エージェントは必要な概念だけを段階的に読み込みます。CLAUDE.mdが数千行に肥大して毎回全文がコンテキストを圧迫する、という運用上の悩みへの直接の回答です。あわせて「書く前に必ず既存記憶を検索する」というSearch-Before-Write原則を規約として明文化しており、概念の重複や、過去の記録と食い違う記憶の増殖を防ぐ設計になっています。
土台のOKF仕様はGoogle Cloud発
名前の由来であるOKF（Open Knowledge Format）は、このプロジェクトの独自規格ではなく、Google Cloudが公開している知識表現フォーマットです。公式仕様書（knowledge-catalogリポジトリのSPEC.md）は、OKFを「人間にもエージェントにも読み書きしやすい、知識表現のためのオープンフォーマット」と定義し、YAMLフロントマター付きMarkdownファイルのディレクトリという最小限の構造だけを規定しています。スキーマレジストリも中央権威も必須ツールもありません。
仕様の初版（v0.1）は2026年6月に公開され、MarkTechPostなどの技術メディアが「AIエージェントに文脈を与えるためのベンダー中立なMarkdown仕様」として報じました。現行のv0.2では、エージェントが継続的に書き込む知識コーパスを前提に、次の5つの問いに答えるメタデータが一級市民化されています。
- この知識は何から作られ、どう検証されたか（provenance：出所）
- どこまで信頼してよいか（trust：generated / verifiedの信頼区分）
- 今も真か（freshness：
stale_afterによる鮮度期限） - 現行版か（lifecycle：statusによる状態管理）
- 数値は決められた手順で算出されたか（attestation：証明）
「AIが生成しただけの記憶」と「人間がレビュー済みの記憶」をフロントマターで区別できるこの信頼階層は、Hacker Newsのコメントでも評価が集まったポイントです。エージェントの記憶を業務に使うなら、ハルシネーション由来の誤情報が「検証済みの事実」と同じ顔でコーパスに混ざる事態を防ぐ仕組みが要る——OKF v0.2はそれをフォーマット側で解決しようとしています。
なお、エージェントの記憶をファイルフォーマットとして設計する潮流そのものについては、Agent memory as a file format｜設計判断4つで設計上の論点を詳しく整理しています。OKF Agent Memoryはこの潮流の「実装が1つ出てきた」段階と捉えると位置づけが分かりやすいはずです。
CLAUDE.md・Mem0・Lettaとの違い
既存のエージェント記憶の選択肢と比べると、OKF Agent Memoryの立ち位置は「構造化されたプレーンテキスト」という中間解です。リポジトリ付属の比較ドキュメント（docs/ALTERNATIVES.md）とREADMEの記載をもとに、主要な違いを表にまとめます。
| 観点 | CLAUDE.md / AGENTS.md（単一ファイル） | Mem0・Letta（ベクトルDB型） | OKF Agent Memory |
|---|---|---|---|
| 記憶の実体 | 1枚の非構造Markdown | 外部DB内の埋め込みベクトル | 構造化Markdown群＋リンクグラフ |
| バージョン管理 | 可能（ただし構造なし） | 困難（DBの中身は差分レビュー不可） | Gitネイティブ（diff / log / PRレビュー） |
| 検索方式 | 全文をコンテキストに投入 | 埋め込み＋ベクトル類似検索 | ローカルBM25（埋め込みAPI不要） |
| 検索の追加コスト | トークン消費が線形に増大 | 埋め込みAPI課金が発生しうる | ゼロ（完全ローカル） |
| 信頼度・鮮度の管理 | なし（全部同格） | 実装依存 | 仕様で規定（trust / stale_after / status） |
| 外部依存 | なし | Python実行環境・DB・API | 依存ゼロの単一Goバイナリ |
| 意味的な曖昧検索 | LLM任せ | 得意（埋め込みの強み） | 語彙一致ベース（弱点になりうる） |
この比較はプロジェクト側の整理をベースにしているため、ベクトルDB型が有利な面も補足しておきます。BM25は語彙の一致に依存するため、「言い回しは違うが意味は同じ」記憶の想起はベクトル検索に分があります。また、リポジトリ横断・組織横断の記憶共有や、会話履歴のような大量の非構造データの蓄積は、Mem0やLettaのようなマネージドなメモリ基盤の得意領域です。OKF Agent Memoryが向くのは「特定リポジトリに紐づく、レビュー可能であるべき知識」——アーキテクチャ上の決定、ドメイン仕様、運用手順といった類の記憶だと整理できます。
手元で検証する手順（ビルドからMCP接続まで)
ツールチェーンはGo 1.26・外部依存ゼロの単一バイナリで、ビルドは1コマンドです。実際の検証フローをREADMEのQuickstartに沿って示します。
まずリポジトリを取得してCLIをビルドします。
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
git clone https://github.com/okf-memory/okf-agent-memory.git
cd okf-agent-memory
make build # bin/okf が生成される
# バンドルの整合性検証（グラフ接続性・記述ドリフトまで見る）
./bin/okf validate knowledge --strict --drift
# BM25による概念検索
./bin/okf search "architecture layers" knowledge
動作環境: Go 1.26以上、make（macOS / Linux）。ポイントは validate が単なるYAML文法チェックではなく、概念間リンクの双方向整合や説明文のドリフト検出まで行うことです。「記憶が壊れていないか」をCIで機械判定できます。
既存プロジェクトへの導入は bootstrap サブコマンドが入口です。
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
./bin/okf bootstrap /path/to/my-project --name "My Service"
これで対象リポジトリに knowledge/（OKFバンドル本体）、.agents/skills/okf-memory/（エージェントスキル定義）、AGENTS.md（エージェント向け運用指示）、検証・検索タスク入りの Makefile が一式生成されます。
Claude CodeやCursorから使う場合は、内蔵のMCPサーバーをstdioで起動します。設定例は次の通りです。
{
"mcpServers": {
"okf-memory": {
"command": "/path/to/okf-agent-memory/bin/okf",
"args": ["mcp", "/path/to/project/knowledge"]
}
}
}
ポイント: MCPサーバーが単一バイナリなので、Node.jsやPythonのランタイム管理が不要です。MCP接続でつまずいた場合の切り分けはMCPサーバーのデバッグ方法【2026年9月】接続エラーの切り分け手順が使えます。stdio型サーバーの起動失敗・パス指定ミスの診断手順はOKFでもそのまま通用します。
日本企業のエージェント運用にどう関係するか
国内でAIコーディングエージェントを業務導入しているチームにとって、このリリースが意味を持つ場面を3つ挙げます。
監査可能性が求められる現場でのメモリ選定
金融・製造など統制の強い業界では「エージェントが何を根拠に判断したか」の説明責任が導入のボトルネックになりがちです。記憶がリポジトリ内のテキストで、変更がすべてGit履歴に残るOKF方式は、外部SaaSのメモリDBに知識を預ける方式より監査・持ち出し統制の説明がしやすい構造です。データが社外に出ない完全ローカル検索である点も、セキュリティレビューの通しやすさに直結します。
CLAUDE.md肥大問題への段階的な移行先
すでに多くのチームが直面している「CLAUDE.mdが長大化し、古い記述と新しい記述が混在する」問題に対し、信頼区分と鮮度期限つきの構造化バンドルは現実的な移行先になりえます。長大な指示書がエージェントの行動をどこまで縛れるかについてはHANDBOOK.md解説｜長文ポリシーはエージェントを縛れない【2026】で検証した通り限界があり、「必要な知識だけを段階的に読ませる」方向への転換は理にかなっています。
マルチエージェント・マルチツール環境での記憶の共通化
Claude Code・Codex・Cursorを併用するチームでは、ツールごとに記憶ファイル（CLAUDE.md / AGENTS.md / .cursorrules）が分裂しがちです。OKFバンドル＋MCPサーバーという構成なら、MCP対応クライアントすべてが同じ記憶を読み書きできます。エージェント設定の標準化という文脈ではAgent Pluginsとは｜Claude SkillsとMCPを統一する標準とも地続きの動きで、2026年後半は「エージェント周辺資産の規格化」が同時多発的に進んでいる構図です。
コミュニティの反応——75ポイントの評価と宿題
Hacker Newsのスレッド（75ポイント）では、評価と懐疑がはっきり分かれました。ここはニュースの事実と区別して「コミュニティの受け止め」として読んでください。
評価された点：人間承認済みとAI生成を区別する信頼階層、およびProgressive Disclosureの実装が「よくできている」との声。エージェント記憶のレビュー可能性を重視する実務者からの支持が中心です。
批判・宿題として挙がった点：
- ベンチマークの軸がずれているのでは——「なぜレイテンシを測って、想起の再現率・適合率（recall / precision）を測らないのか」という指摘。検索が速くても、必要な記憶を取り漏らせば意味がない、という本質的な批判です
- よく書けたMarkdownで十分では——手書きの整理されたmdファイル運用と比べた実利がどれほどかを疑う声
- 類似プロジェクトとの差別化——mcp-memory系など既存のメモリ実装との違いが伝わりにくいという指摘
- 企業導入の障壁——ツールを組織的に一貫して使わせること自体の難しさへの懸念
特にrecall / precisionの指摘は導入判断に直結します。リポジトリにはローカルLLMでのトークン削減・TTFT（最初のトークンまでの時間）を測るベンチマークスイートが同梱されていますが、検索精度の第三者評価は2026年9月7日時点で確認できていません。本命の検証対象は「速度」ではなく「自分のコーパスで必要な記憶がちゃんと引けるか」だと押さえておきましょう。
導入前に知っておきたい失敗パターン
失敗1：会話ログをそのまま記憶として書き込む
❌ セッションの生ログや雑多なメモを knowledge/ に流し込む
⭕ 「概念」単位（設計判断・ドメイン事実・運用手順）に絞り、フロントマターで type と信頼区分を付けて書く
なぜ重要か：OKFは概念グラフとして検索・開示される設計のため、非構造ログを混ぜるとBM25検索のノイズが増え、Progressive Disclosureの利点が消えます。大量ログの蓄積は用途が違います（そちらはベクトルDB型が向きます）。
失敗2：generated（AI生成）の記憶を検証なしで放置する
❌ エージェントが書いた記憶をレビューせず、verifiedと同格に扱い続ける
⭕ PRレビューのフローに knowledge/ の差分を含め、確認済みの概念だけを verified に昇格させる。stale_after で鮮度期限も切る
なぜ重要か：信頼階層はフォーマットが用意してくれるだけで、運用しなければ機能しません。ハルシネーション由来の「事実」が verified 扱いで蓄積すると、以後のエージェントの判断全体が汚染されます。
失敗3：CIにvalidateを入れずに複数エージェントで書き込む
❌ 複数のエージェント・複数の開発者が検証なしでバンドルを更新する
⭕ okf validate knowledge --strict --drift をCIの必須チェックにし、リンク切れ・記述ドリフトをマージ前に落とす
なぜ重要か：記憶の実体がただのファイルである以上、壊れたリンクや矛盾した記述は黙って混入します。検証が約4ミリ秒（リポジトリ記載値）で終わる軽さは、CIに常設してこそ意味があります。マルチエージェント構成での書き込み衝突の設計はマルチエージェントの設計パターン3選｜失敗例と実装ガイド【2026】も参考になります。
よくある質問
OKF Agent Memoryとは何ですか？
GoogleのOpen Knowledge Format（OKF）v0.2仕様に準拠したMarkdown群をGitリポジトリ内の knowledge/ に置き、AIエージェントの永続記憶として使うオープンソースプロジェクトです。依存ゼロのGo製CLIとMCPサーバーが付属し、MITライセンスで公開されています。
利用にコストはかかりますか？
ソフトウェア自体はMITライセンスで無料です。検索はローカルのBM25で行うため、ベクトルDB型メモリと異なり埋め込みAPIの従量課金も発生しません（リポジトリのREADMEに明記。2026年9月7日確認）。
Mem0やLettaを置き換えるものですか？
用途が異なります。OKF Agent Memoryは「特定リポジトリに紐づく、レビューされるべき知識」の管理に向き、意味的な曖昧検索や大量の会話履歴の蓄積、組織横断のマネージドなメモリ基盤としてはベクトルDB型に分があります。併用も選択肢です。
Claude CodeやCursorから使えますか？
使えます。okf mcp knowledge でstdioのMCPサーバーが起動し、Claude Code・Cursor・Codexなど MCP対応クライアントから記憶の検索・参照ができます。設定はコマンドパスとバンドルパスを指定するだけです。
OKFはGoogleの公式プロダクトですか？
OKF仕様自体はGoogle CloudのGoogleCloudPlatform/knowledge-catalogリポジトリで公開されているオープン仕様です（v0.1は2026年6月公開）。一方、OKF Agent Memoryはその仕様を採用したコミュニティのプロジェクトであり、Googleの製品ではありません。
結論と次の一歩
OKF Agent Memoryは「エージェントの記憶は、レビューできるプレーンテキストであるべきだ」という設計思想を、Google発のオープン仕様＋依存ゼロのツールチェーンとして具体化した最初期の実装です。速度とコストの主張はプロジェクト側の計測値であり、検索精度（recall / precision）の第三者検証が宿題として残る一方、記憶のGit監査可能性・信頼区分・鮮度管理という枠組みは、統制を求められる日本企業のエージェント運用と相性が良い方向を向いています。
試すなら、本番リポジトリにいきなり導入せず、検証用リポジトリで make build → okf bootstrap → 2週間ほど実タスクを回して「自分たちのコーパスで必要な記憶が引けるか」を確かめるのが現実的な一歩です。CLAUDE.mdが肥大して困っているチームほど、得られる示唆は大きいはずです。
参考・出典
- OKF Agent Memory（GitHubリポジトリ・README） — okf-memory（参照日: 2026-09-07）
- Open Knowledge Format (OKF) Specification v0.2 — Google Cloud / knowledge-catalog（参照日: 2026-09-07）
- OKF Agent Memory – Git-native persistent memory for AI coding agents — Hacker News（75ポイント・参照日: 2026-09-07）
- Alternatives & Ecosystem Comparison（Mem0・Letta・ad-hoc markdown比較） — okf-memory（参照日: 2026-09-07）
- Google Cloud Introduces Open Knowledge Format (OKF) — MarkTechPost（参照日: 2026-09-07）
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
