MemAuthority

MemAuthority — AI エージェントのための Git ベースの長期記憶

中国語

MemAuthority は、MCP（Model Context Protocol）を通じて利用できる、AI エージェント向けの Git ベースの長期記憶システムです。新しいセッション、別のマシン、または別のエージェントがプロジェクトに蓄積されたコンテキストを呼び出し、同じ決定や落とし穴を再発見することなく作業を続けられます。

あらゆる細部を記録しようとするのではなく、次の内容を抽出することに重点を置いています。

将来のエージェントが一から再発見する必要のない、教訓と結論。

役割分担は明確です。

• あなたはゲートキーパーとして、本当に長期にわたって保持する価値のあるものを判断します。
• エージェントは実行を担い、記憶の理解、検索、要約、更新、整理を行います。
• MemAuthorityは安全網として、古い書き込み、重複した再試行、中断された更新から長期記憶を保護しながら、その信頼性と必要なときに利用できる状態を保ちます。

コンテンツの意味や変更の要否を判断するのは、引き続きエージェントです。MemAuthority は、保持される記憶の信頼性が長期にわたって保たれるようにします。

---

これは誰向けですか？

MemAuthority は、長期記憶の品質を重視するユーザー向けに設計されています。

さまざまな記憶ツールを使う中で、制御の難しさを感じたことがあるかもしれません。

• なぜ何かが記憶されたのかが不明確。
• いつ呼び出されるのかが分からない。
• 情報が古くなっていないか確認できない。
• 正確に編集または削除する手段がない。

あるいは、記憶ストアの維持を試みたものの、時間とともに肥大化して整理されなくなり、最終的にはエージェントの助けになるどころか、混乱を招いてしまったことがあるかもしれません。

次のような方に MemAuthority は適しています。

記憶の品質を整えるための労力は最小限に抑え、日常的な整理はすべてエージェントに任せたい方。

「労力をかける」とは、一日中ファイルを手作業で編集することではありません。重要なタイミングで、大きな効果をもたらす判断をすることです。

• この情報は長期にわたって保持する価値がありますか？
• 記憶を見直したり整理したりするのはいつですか？
• これに機密データやシークレットが含まれていますか？
• エージェントが提案する整理方法は、実際の意図に沿っていますか？

書式設定、分類、アーカイブ、対象を絞った検索など、機械的な作業はすべてエージェントが担います。

---

MEMORY.mdだけではだめなのでしょうか？

プロジェクトのメモリが小規模で、ほとんど変更されない場合や、単にメモリの保守に手間をかけたくない場合は、プレーンなMEMORY.mdを使い続けるのが最も簡単です。

そのファイルが単なるメモではなく、後のセッションで信頼して参照する必要がある長期的なプロジェクト状態になると、MemAuthorityが役立ち始めます。

より高度なニーズに対応します。

長期メモリの保守を、信頼性が高く、制御可能で、適切に設計されたワークフローに変えます。

「エージェントにMarkdownを編集させる」だけにとどまりません。堅牢な運用アーキテクチャを提供します。

• 必要に応じた的確な読み込み：タスクで必要な場合にのみメモリを読み込み、無関係な情報でコンテキストウィンドウが肥大化したり、汚染されたりするのを防ぎます。
• 役割の明確な分離：引き継ぎ状態、恒常的なルール、マイルストーンの進捗、落とし穴の回避を明確に分けます。
• 並行処理とバージョンの安全性：書き込み前に厳密なバージョンチェック（CAS — Compare-And-Swap）を実施し、古いリビジョンが新しい内容を気付かれないまま上書きするのを防ぎます。
• 冪等性と重複排除：ネットワークの不具合や実行の中断による再試行でも、メモリを重複させず安全に処理できます。
• 収束と完全な履歴：アクティブな作業メモリを簡潔に保ちながら、完全で監査可能なリビジョン履歴はGitに任せます。
• トランザクションとクラッシュ復旧：書き込みが中断または失敗した場合に備え、明示的なジャーナリングと復旧の仕組みを備えています。

次のように考えると分かりやすいでしょう。

Authorityは、後続のエージェントが今すぐ引き継ぐべき状態を保存し、Gitは完全な履歴を保存します。

つまり、

MEMORY.mdはシンプルさを優先し、MemAuthorityはプロジェクトの成長に合わせて長期メモリの信頼性を維持することを優先します。

---

日常のワークフロー

自然で簡潔な指示を使って、エージェントとやり取りします。

1. タスク開始時に必要な情報を取得する

エージェントは、MEMORY.mdと同様に実際のタスクの状況に基づいてメモリを呼び出すかどうかを判断します。または、特定のメモリを読むようエージェントに指示できます。

「このプロジェクトのMemAuthorityを確認して、必要なものだけ取り込んでください。」

MemAuthorityは固定の取得方法を定めていないため、エージェントは最短で最適な取得方法を選びます。場所が分かっている場合は直接読み、分からない場合は検索し、プロジェクト全体を手早く引き継ぐ必要がある場合はhandoffを使います。現在の会話にすでに十分なコンテキストが含まれている場合は、MemAuthorityを呼び出す必要はありません。

2. 記憶する内容を選別する

「このタスクから長期的に残す価値のある要点をリストアップしてください。何を保存するかは私が決めます。」

エージェントが候補項目をまとめ、何を残し、編集し、破棄するかを最終的に決めるのはあなたです。

3. 手軽に記録する

「このタスクを記録してください。」

一般的で、手間のかからない指示です。デフォルトでは、エージェントは慎重な方針を採用し、自ら長期的なrulesを変更せず、リスクの低いprogressエントリーとして記録します。

4. タスク後にメンテナンスする

「このタスクで実際に使ったMemAuthorityのメモリを確認してください。今回起きたことや検証できた内容を反映して更新し、古くなったものは削除してください。」

タスクを終えたばかりのエージェントは、コード、ツールの結果、実行時の事実、ユーザーの決定について最新の情報を持っています。そのため、毎回Vault全体をスキャンするのではなく、実際に読み込んで使用したメモリだけを保守すれば十分です。

5. コンテキストを空けるため、アイデアを後回しにする

「この方針は後で検討する価値があります。今のコンテキストを散らかさないよう、MemAuthority TODOに入れておいてください。」

ここでのTODOはプロジェクト管理用の課題トラッカーではなく、次のようなものです。

今は認知的な余力を使わず、後で再検討する価値のあるアイデアを一時的に置いておく場所です。

対応が済んだらTODO項目を削除し、そこから得られた永続的な結論を長期メモリに昇格させます。

---

「このタスクを記録して」— メモリーの肥大化を防ぐには？

MemAuthority では、何かを記録したいときに、その都度「ルールに入れるべきか、進捗に入れるべきか」を熟考する必要はありません。

「このタスクを記録して」のような自由形式の指示を出した場合、エージェントのデフォルトの動作は次のとおりです。

• デフォルトでは progress に記録します。
• このセッションで完了した主要な成果物のみを記録します。
• 意味のある状態遷移のみを記録します。
• 今後の作業を続けるために必要な重要なコンテキストのみを記録します。

デフォルトで積極的に除外するもの：

• チャットの全文、会話上のつなぎ言葉、社交辞令。
• 細かな操作ログや試行錯誤の詳細。
• 今後再利用する価値のない一時的な失敗。
• 保管庫にすでに記録されている重複情報。
• 一時的な情報、古くなった情報、機密情報、または純粋に推測に基づく内容。

一方で、何かが「重要そうに聞こえる」というだけで、エージェントがそれを長期的な rules エントリーに昇格させることはありません。真に確かなルール、引き継ぎ時の状態、落とし穴に関する教訓は、実際の作業を通じて段階的に抽出する必要があります。

MemAuthority が提供するシステムレベルのガードレール：

• すべての書き込みコンテンツに標準スキーマを適用します。
• メモリーの役割に基づいて変更を制限します（ロールベースアクセス）。
• 信頼度の高いシークレットや認証情報を自動でスキャンし、書き込みをブロックします。
• 冪等性の仕組みにより、再試行によるエントリーの重複を防ぎます。
• バージョン検証（CAS）により、古いリビジョンが新しいリビジョンを気付かれないまま上書きするのを防ぎます。
• 書き込みのコミット前に、保管庫の候補の整合性を検証します。
• クラッシュリカバリーに対応したジャーナル付きトランザクションをサポートします。

目標は「品質の低いメモを一つも作らないこと」ではなく、次のとおりです。

エージェントは慎重に記録し、MemAuthority は基盤となる状態の整合性を保証し、継続的な実作業によってメモリーを常に洗練し、不要な内容を削除していきます。

整合性は、次の2つの異なるレイヤーで保たれます。

• 意味的整合性：エージェントが、新しいタスクの成果と既存の知識を照らし合わせて調整します。
• 状態整合性：Git Authority、リビジョン CAS、冪等性、トランザクションジャーナリングに裏付けられた MemAuthority が強制します。

覚えておいてください。progress はマイルストーンを手軽に記録するためのエントリーポイントであり、変更できない追記専用のアーカイブではありません。

---

すでに MEMORY.md や従来のメモがある場合は？

すべてを手作業で書き直す必要はありません。

従来のデータの移行にあたり、MemAuthority は原則に基づいたアプローチを採用しています。

MemAuthority にあらゆる従来形式を取り込むカスタムインポーターを作るのではなく、エージェントに意味的な移行を実行させます。

エージェントが従来の資料を読み、理解できる限り、どのようなソースからでも移行できます。

• 既存の MEMORY.md ファイル。
• 一般的な Markdown 文書やプレーンテキスト文書。
• JSON エクスポート。
• システムプロンプトファイル。
• 過去の引き継ぎ情報やチャットの要約。
• 複数のソースにまたがる矛盾したメモ。
• LLM が解析できるその他のテキスト形式。

標準的な移行フロー：

1. エージェントが MemAuthority の構造仕様とメモリーの基準を学習します。
2. エージェントが従来のメモを読み込みます。
3. 情報の重複を取り除き、統合、更新、分類します。
4. 古くなった事実、重複したエントリー、生ログ、一時的なメモ、適さない内容を取り除きます。
5. 整理された出力を、標準の MemAuthority 保管庫構造にエクスポートします。

エージェントには、次のように指示するだけでかまいません。

「まず MemAuthority のメモリー仕様を読み、その後、この従来のメモリーファイルを確認してください。長期的に残す価値のある情報は、重複を取り除き、統合、更新、再構成してください。古くなった情報、繰り返しの内容、生ログ、一時的なメモ、長期保存に適さないものは削除してください。書き込む前に、確認用の移行案を提示してください。」

移行とは、本質的には情報を選別する判断であり、機械的なコピー＆ペーストではありません。

初期オンボーディングや大規模な移行には、v1 の次のワークフローを推奨します。

init (initialize empty vault)
  -> Agent curates vault in detached mode
  -> validate (verify integrity & schema)
  -> Human review
  -> Git commit (commit revision)
  -> managed serve (launch MCP service)

詳しいガイドについては、docs/ONBOARDING.md を参照してください。

---

MemAuthority には何を記録するのですか？

MemAuthority の長期記憶は、次の 4 つの役割に厳密に分けられています。

handoff（引き継ぎ状態）

エージェントがプロジェクトをすぐに引き継ぐために必要な最小限の重要なコンテキストです。 簡潔で実行可能な内容にし、常に最新の状態に保ってください。膨大な第 2 の README になってはなりません。

rules（長期ルール）

将来のエージェントが従うべき、アーキテクチャ上の制約、継続的に適用される決定事項、行動指針です。 長引いた議論や過去の話し合いではなく、確定した決定事項だけを記録してください。

progress（マイルストーンの進捗）

将来の作業にも関係する、重要なマイルストーンや状態の変化です。 記録を始める際の最も手軽な入り口ですが、追記専用のトランザクションログではありません。

pitfalls（落とし穴と教訓）

将来のエージェントが遭遇する可能性のある、繰り返し起きる失敗、気づきにくい落とし穴、実証済みの回避策です。 日常的なエラーや一度限りの誤字は、ここに記録する必要はありません。

信頼できる判断基準は次のとおりです。

これを知っておくことで、将来のエージェントの判断が変わるか、多くの試行錯誤を省けるか、同じ間違いの繰り返しを防げるでしょうか？

そうでなければ、長期記憶に含める必要はおそらくありません。

---

不要な MemAuthority の記憶が会話コンテキストに入るのを防ぐには？

MemAuthority は段階的な検索に対応していますが、エージェントに決まった手順を求めるものではありません。

1. 現在の会話にすでに十分なコンテキストがある場合は、MemAuthority を呼び出さないでください。
2. プロジェクトが不明な場合は、まず場所を特定して確認してください。
3. 正確な URI またはセクションが分かっている場合は、そこを直接読み取ってください。
4. プロジェクトは分かっているものの場所が不明な場合は、そのプロジェクト内を検索してください。
5. 概要をすばやく引き継ぐ必要がある場合は、通常 handoff から始めるのが最適です。
6. 何が関連するかはエージェントが判断し、現在のタスクに本当に役立つものだけを読み取ります。

検索結果は座標であり、コンテキストではありません。

目標はシンプルです。無関係な記憶が現在の会話コンテキストに入らないようにし、どれだけの根拠があれば十分かの判断は、タスクを実行するエージェントに委ねます。

---

複数のエージェントがいると競合しませんか？

MemAuthority v1 は、次の中核原則に基づいて構築されています。

複数のエージェント、単一の権威ある情報源。

異なるエージェントやクライアントが、同じ Managed Authority に対して交互に読み取りや変更を要求できる一方で、MemAuthority は単一の線形かつ決定論的なバージョン履歴を維持します。v1 は同時にチームで編集するための共同データベースではなく、単一ユーザーと単一の書き込み担当者向けに設計されています。

Agent A が記憶を更新した後、Agent B が古いリビジョンに基づいて変更を試みた場合、MemAuthority は競合を明示的に返し、古い状態で新しい状態が上書きされるのを防ぐため、書き込みを拒否します。

その後、Agent B は最新の状態を再取得し、マージ、上書き、中止、またはユーザーへの確認のいずれかを判断する必要があります。

MemAuthority は、主観的な意見のどちらが正しいかを判断しません。その責任は、より限定的です。

同時実行による競合を明示し、意見の異なる編集によって、誤った Authority が気づかないうちに確定されるのを防ぎます。

---

MemAuthority が肥大化するのを防ぐには

Git は Authority の完全な変遷を忠実に記録し、いつでも記憶をたどれるようにします。一方、エージェントは実際の作業で Git の履歴を読みません。エージェントが読むのはアクティブな記憶だけであり、それは自由に改訂できます。Git は復元可能性を保証します。

• ルールが変わったら、その場でルールを更新します。
• 状態が変化したら、引き継ぎ状態を更新します。
• 内容が古くなり、再び参照する必要もなくなったら、直接削除します。

---

インストール

MemAuthority の利用には、Git と Go 1.26.5 以降が必要です。現在の安定版リリースをインストールするには、次のコマンドを実行します。

go install github.com/iasi777/v-memory/cmd/[email protected]

互換性を維持するため、v1.x の Go モジュール ID は、正規のリポジトリ名と製品名が MemAuthority になった現在も、意図的に github.com/iasi777/v-memory のままです。GitHub は旧リポジトリの URL を iasi777/memauthority にリダイレクトします。

確認するには、次のコマンドを実行します。

memauthority version

想定される出力：

memauthority 1.3.2

既存の自動化では、互換性のある実行ファイルのインストールと呼び出しを引き続き使用できます。

go install github.com/iasi777/v-memory/cmd/[email protected]
v-memory version

現在、ビルド済みのリリースバイナリは公開されていません。代わりに、ソースのチェックアウトからビルドするには、次のコマンドを実行します。

go build -trimpath -o ./memauthority ./cmd/memauthority
./memauthority version

リリース CI では、Linux、macOS、Windows でテストスイート、vet、ネイティブ CLI ビルドを実行します。また、Linux CI では、本番環境向け Linux/ARM64 ターゲットも検証します。

---

はじめに

1. 空の Vault を初期化する

memauthority init ./vault

2. オンボーディングとキュレーション

新しい Vault を立ち上げる場合や、大規模なレガシーコーパスを移行する場合は、ファイルと Git の権限を持つエージェントに、次のファイルを読ませてください。 docs/AGENT-GUIDE.md

キュレーションが完了したら、Vault を検証します。

memauthority validate ./vault

3. コミットしてサービスを起動する

変更を確認して Git にコミットし、Managed MCP Service を起動します。

memauthority serve \
  --vault /absolute/path/to/vault \
  --state-dir /absolute/path/to/state \
  --write-enabled

• --write-enabled を省略すると、サービスは読み取り専用モードで実行されます。
• state-dir は Vault Authority ディレクトリの外に配置する必要があります。
• Detached モード（ファイルを直接編集）と Managed モード（サービスを実行）を同時に使用しないでください。
• 宣言型のランタイムメタデータは、Vault に登録済みのランタイムがない場合、デフォルトで無効です。ほとんどの単一マシンのユーザーは無効のままにしてください。runtime_resource がある既存の Vault では、ランタイムツールが自動的に有効になります。作業やデプロイのトポロジーの記録を意図的に開始する場合にのみ、--runtime-enabled を使用してください。

ローカル環境では、MCP クライアントからコマンドを stdio 経由で直接起動するのが最も簡単です。

接続すると、MemAuthority はツール定義、入力スキーマ、アノテーション、リソースメタデータをエージェントに自動で提供します。日々の Managed モードでの運用では、エージェントにパラメーターのスキーマを改めて説明する必要はありません。

利用方法全般のガイドライン（必要に応じた想起、慎重な記録、役割の選択、レガシーの移行）については、AGENT-GUIDE.md を参照してください。

HTTP トランスポート経由で公開する場合は、まず SECURITY.md と凍結済みの v1.3.2 Transport / Auth 仕様を確認してください。

ビルドと検証

go test ./...
go vet ./...
go mod verify
go build -trimpath -o ./memauthority ./cmd/memauthority

---

ベンチマーク

MemAuthority は、実際のエージェントのワークロードにおけるセッションをまたいだメモリの信頼性を検証する、公開済みで監査可能なベンチマークスイートを維持しています。

最新キャンペーン：変更操作のユーザビリティ回帰テスト（2026-09-08）

handoff-pending-01 — 保留中の作業を追跡する、セッションをまたいだプロジェクトの引き継ぎ

指標	結果
実行総数	30/30 PASS
セッション総数	90/90 PASS
変更操作	合計 426 件
変更エラー	2 件（0.5%）
人による意味的レビュー	30/30 件を確認
独立監査	Claude Opus 5、信頼度 HIGH

テスト済みのエージェントスタック（各10ラウンド）：

• Codex CLI + GPT-5.6 Sol：10/10 回の実行、変更エラー 0/136 件（0.0%）
• Codex CLI + GPT-5.6 Luna：10/10 回の実行、変更エラー 0/138 件（0.0%）
• Pi Agent + Gemini 3.8 Flash：10/10 回の実行、変更エラー 2/152 件（1.3%、どちらも復旧）

主な発見：テストしたすべてのエージェントスタックで、完全に独立したセッション間におけるプロジェクト状態の保持と復旧に成功しました。修正後の変更エラー率は 0.5%（2/426） であり、API の高いユーザビリティを示しています。

監査メモ：当初のレポートではエラーを18/426件と報告していましたが、MCP ログを包括的に分析した結果、2/426件に修正されました。どちらのエラーも同じ実行、同じツール、同じ検証上の問題で発生しました。エージェントは正常に復旧しました。手法については監査ドキュメントをご覧ください。

📊 全結果：benchmark/results/mutation-usability-regression/
📋 ベンチマーク仕様：benchmark/ | ドキュメント全文
📦 エビデンスのダウンロード：GitHub Releases（全30回の実行とすべてのアーティファクト）

---

公開コントラクト

現在の公開互換性ベースラインは v1.3.2 です。それ以前にリリースされたコントラクトスナップショットは変更されていません。

Vault のストレージ形式、MCP ツール、Managed のランタイム動作、変更／拒否のルール、セキュリティ境界、トランスポート／認証の動作、互換性ポリシーの正式な定義は、docs/contract/v1.3.2/ で管理されています。

この README とユーザーガイドは説明を目的としています。詳細が異なる場合は、バージョン管理されたコントラクトが正式な定義となります。

バージョン

memauthority version
memauthority --version

AI エージェントのメモリ、長期メモリ、MCP メモリサーバー、Git ベースのメモリ、エージェントメモリ基盤、エージェントの継続性

v1.3.2 では、主コマンドは memauthority 1.3.2 を出力し、互換性コマンドは v-memory 1.3.2 を出力します。

セキュリティ

HTTP トランスポートでサービスを公開する前に、SECURITY.md を必ずお読みください。

• 書き込みアクセスはデフォルトで無効です。有効にするには、--write-enabled を明示的に指定してください。
• HTTP による変更操作は、凍結された v1 仕様の OAuth およびセキュリティ要件に厳密に従う必要があります。
• MemAuthority には高い信頼度のシークレットスキャン機能が組み込まれていますが、包括的なシークレット検出ツールの代わりにはなりません。

関連ドキュメント

• docs/ONBOARDING.md — クイックスタート、レガシーシステムからの移行、初回セットアップガイド
• docs/MCP-CONFIG.md — stdio／HTTP 接続ガイドと設定仕様
• docs/AGENT-GUIDE.md — 想起、記録、メンテナンス、移行に関するエージェント向け実践ルール
• docs/FAQ.md — よくある質問、設計上の境界、トレードオフ
• examples/README.md — 実行可能なサンプル Vault と最初のローカル MCP セッション
• SECURITY.md — 対応するセキュリティライン、デプロイの境界、非公開での報告方法
• docs/contract/v1.3.2/ — バージョン管理された v1.3.2 公開コントラクト

コミュニティ

MemAuthority は LINUX DO コミュニティを認め、支援しています。

ライセンス

Apache License 2.0 の下で公開されています。詳細は LICENSE をご覧ください。

帰属表示とサードパーティに関する通知は、NOTICE と THIRD_PARTY_NOTICES.md に記載されています。