Mneme Decision MCP について
Mneme Decision MCPは、アーキテクチャ上の決定を照会し、候補を提案できるローカルMCPサーバーです。正規の決定を変更する権限は与えず、追跡可能な決定情報と明確な人間の承認境界を必要とするAIコーディングワークフロー向けです。
主な機能
- 01正規の決定状態の照会
- 02決定と適用可能性の検索
- 03決定記録の追跡
- 04単件・一括提案の送信
- 05権限を持たない提案
活用シーン
- 01コーディングタスク向けのアーキテクチャ指針の取得
- 02コンテキストに適用される決定の確認
- 03決定の出典の追跡
- 04人間のレビューに向けた候補決定の提出
MCP 対応
ローカルstdioサーバーを通じて、決定の提案、取得、検索、適用可能性の確認、追跡を行う6つのツールを提供します。提案ツールから正規の決定を承認・有効化したり、その権限状態を変更したりすることはできません。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
ツール
ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。
詳細
Mneme HQ
Mneme は、エージェント型ソフトウェア開発のためのオープンな意思決定および制御レイヤーです。
これは、持続的なエンジニアリング上の意思決定を、AI コーディングエージェント、リポジトリ、CI ワークフロー全体にわたって、エージェントのコンテキスト、決定論的な強制、および検査可能な強制結果へと変換します。アーキテクチャは最初にサポートされる意思決定ドメインです。Mneme はアーキテクチャドリフトを防止します。これは、アーキテクチャ上の意思決定と ADR を、コーディングエージェント、リポジトリの変更、生成されるルール、CI ゲート全体にわたる決定論的なガードレールへと変換することによって実現します。
あなたのアーキテクチャは、実際にはどこで強制されていますか? アーキテクチャ監査を実行して、どの意思決定が保護されているか、どれが決定論的なガードレールになり得るか、そしてどれが依然として誰かがルールを覚えていることに依存しているかを確認してください。試してみる →
Mneme は、そのドリフト防止メカニズムの背後にある意思決定レイヤーです。AI コーディングシステムがコードを提案・変更する際に、記録されたエンジニアリング上の意思決定をアクティブに保ちます。ADR を受動的なドキュメントのままにしておくことはありません。

実線のサーフェスは現在提供されています。破線のサーフェスは計画中です。統合ごとのサポートレベル: 統合マトリクス。
現在のフェーズ: レイヤー 1 の検証。検索、強制、およびベンチマークのセマンティクスは、承認されたアーキテクチャとフリーズ記録によって管理されます。コアの動作を変更する前に、現在のフェーズを参照してください。
Mneme が行うこと
Mneme は、アーキテクチャ上のガイダンスと決定論的な強制を分離します:
- アーキテクチャ上の意思決定を記録する — 構造化され、監査可能な意思決定コーパスに。
- 関連する意思決定を取得する — エージェントまたはモデルがアーキテクチャ上のガイダンスを必要とするときに。
- 管理されたルールを決定論的に強制する — 明示的な適用可能性のセマンティクスの下で。
- 各コーディングワークフローが公開する最も早い信頼できる境界で統合する。
- 回避可能な変更パスを監査する — 変更前のブロックが技術的に利用できない場合に。
- CI で実行する — 互換性のない変更が受け入れられる前の、最終的な決定論的ゲートとして。
同じ入力と同じ管理された意思決定状態は、同じ強制結果を生み出します。Mneme は、そのコアの allow/warn/fail の判定において LLM ジャッジに依存しません。
Mneme は、汎用のベクトルストア、会話型メモリシステム、自律型コーディングエージェント、またはデプロイメント可観測性プラットフォームではありません。
インストール
Python 3.11 以上が必要です。
pip install mneme-hq
CLI を確認します:
mneme --help
リポジトリ開発の場合:
git clone https://github.com/MnemeHQ/mneme.git
cd mneme
pip install -e ".[dev]"
Decision MCP
Mneme は Decision Index をローカル MCP サーバー経由で公開するため、MCP 対応クライアントは、状態を変更する権限を得ることなく、アーキテクチャ上の決定案を提案し、決定の状態を照会できます。
オプションの MCP 依存関係をインストールします。
pip install "mneme-hq[mcp]"
ローカルの stdio サーバーを起動します。正規の読み取り元は、デフォルトでは永続化された .mneme/project_memory.json 内の Decision Index です。提案ストアは引き続き独立しています。
mneme decision-mcp
--memory を使って、別のプロジェクトメモリファイルを指定します。このファイルには有効な権威ある decision_index セクションが含まれている必要があります。MCP は、互換性のための decisions[] スナップショットから権威を再構築せず、フェイルクローズします。
mneme decision-mcp --memory path/to/project_memory.json
mneme init または mneme setup で作成したメモリには、空の decision_index セクションがすでに含まれているため、移行は不要です。まだ decision_index セクションがない古いファイルでは、移行を促すエラーが表示され、MCP は停止します。まず移行内容をプレビューしてください。何も書き込まず、確認できる影響を一覧表示します。非アクティブな決定は Layer 1 から除外され、従来の rule/anti_pattern 項目は一度だけ移行されます。
mneme decision-index migrate --memory path/to/project_memory.json
その後、プレビューどおりの移行を適用します。
mneme decision-index migrate --memory path/to/project_memory.json --apply
移行はデータを失わずに実行できる場合のみ行われ、できない場合は拒否されます。強制モードや修復モードはありません。EventCatalog からインポートした決定など、正規のインデックスで表現できない従来の決定メタデータを含むメモリは、セクションがない状態のままとなり、移行されません。
--adr-dir は、現在は検証入力としてのみ任意で指定できます。Mneme は起動前に引き続きそのコーパスを検証し、優先順位を解決しますが、ADR が MCP の第二の権威ソースになることはありません。
mneme decision-mcp --memory path/to/project_memory.json --adr-dir path/to/adrs
MCP のインターフェースは、次の 6 つのツールに意図的に固定されています。
decision.proposedecision.propose_batchdecision.getdecision.searchdecision.applicable_todecision.trace
提案ツールが作成するのは、権威を持たない提案のみです。読み取りツールは、提案と正規の決定状態を照会します。MCP には、承認、却下、有効化、置き換え、例外、バイパス、信頼済み証拠を扱う権限は意図的に公開されていません。
人間による承認権限は、mneme decision proposals | show | accept | reject で明示的に維持されます。提案を承認すると、正規の決定が作成されますが、保護が有効化されたり、Architecture Audit が実行されたりするわけではありません。
権限の境界とリリース契約については、ADR-027 と v0.9.0 リリースノート を参照してください。
Architecture Audit
アーキテクチャが実際に保護されている箇所と、ルールを人々が覚えておくことに依存している箇所を確認できます。
Mneme がリポジトリを監査し、アーキテクチャ上の決定を次のように表示します。
- 保護済み — すでに機械的に適用されています
- Mneme 対応 — 決定論的なガードレールにできます
- モデリングが必要 — 重要ですが、まだ安全に自動化できません
- ガイダンス — 参考になる情報ですが、適用すべきものではありません
監査を実行します。
mneme audit --memory .mneme/project_memory.json --repo-root .
Mneme 対応の決定については、有効化する前に、提案された保護を検証します。
mneme protect validate <decision-id> --memory .mneme/project_memory.json
その後、明示的に有効化します。
mneme protect activate <decision-id> --memory .mneme/project_memory.json
Mneme は、実際に適用されていることを検証できて初めて、決定を保護済みとして報告します。有効化に関する完全な契約については、保護の有効化に記載されています。
60秒で確認できる強制適用の例
プロジェクトローカルの意思決定コーパスを初期化します。
mneme init
アーキテクチャ上の決定を1つ記録します。
mneme add_decision \
--memory .mneme/project_memory.json \
--id config-format \
--decision "Use JSON for configuration files" \
--scope config \
--constraint "Use JSON only" \
--anti-pattern "Do not use YAML"
その決定に違反する入力案を作成します。
python -c "import pathlib; pathlib.Path('prompt.txt').write_text('Set up a new YAML config file', encoding='utf-8')"
決定論的なチェックを実行します。
mneme check \
--memory .mneme/project_memory.json \
--input prompt.txt \
--query configuration
厳格モードでは、禁止された YAML の提案に対して FAIL の判定と終了コード 2 が返されます。準拠する JSON の提案に対しては PASS と終了コード 0 が返されます。
CLI は共通の強制適用インターフェースです。エージェントとの統合では、各エージェント固有のイベントを同じ Mneme の意思決定および強制適用モデルに変換します。
呼び出し元が提示したコンテキストラベルにどの標準的な決定が適用されるかを、非権威的にプレビューするには、mneme check にオプトインの --applicability-preview <label> を繰り返し指定します。
mneme check --memory .mneme/project_memory.json --input prompt.txt --query configuration --applicability-preview platform:windows
プレビューは通常のチェック結果とは独立して、stderr にのみ出力されます。提示されたラベルを信頼したり、決定を除外したり、強制適用や stdout、JSON mneme.check/v1、フックの動作、終了コードを変更したりすることはありません。セクションのないメモリやプレビュー計算のエラーが発生した場合は、stderr に PREVIEW UNAVAILABLE と出力されます。メモリの移行や強制適用の緩和は行われません。このプレビューはセキュリティ制御ではありません。
セットアップモード(強制適用なし)
mneme setup はチームの作業方法を変えずに、リポジトリ内で Mneme を初期化します。プロジェクトメモリの作成または検出、サポート対象のエージェント環境の検出、保護の準備状況の報告を行いますが、ブロッキングを伴う強制適用は有効にしません。セットアップによって警告/監視の動作がブロッキング動作に変わることはありません。予防的な強制適用の有効化は、常に別途明示的に決定します。
mneme setup
必要に応じて、不透明な Architecture Audit の参照情報を記録すると、保存済みの Audit ベースラインとの関連をセットアップで特定できます。
mneme setup --audit-ref <reference>
セットアップはべき等です。既存の Mneme プロジェクトに対して再実行しても、有効な設定は変更されません。
仕組み
Architectural decisions / ADRs
|
v
structured decision corpus
|
+-----+--------------------+
| |
v v
relevant guidance deterministic enforcement
retrieval + applicability checks
| |
+------------+-------------+
|
v
workflow-specific boundary
|
+------------+-------------+
| | |
pre-change post-change CI
hooks audit gate
Mneme は、ワークフローで利用できる最も早い信頼性の高い境界でガバナンスを適用します。
- アーキテクチャのコンテキストをモデル呼び出しに注入できる場合は、生成前。
- エージェントがブロッキング可能なツール実行前フックを提供する場合は、サポート対象のファイル変更前。
- シェルやスクリプトによる書き込みを実行前に安全に検査できない場合は、範囲を限定した作業ツリー監査を通じて、回避可能な変更の後。
- CLI ベースの CI ゲートを通じて、マージ前。
これらの境界は相互に補完し合います。統合が対象として掲げるのは、そのハーネスで実装および検証された領域のみです。
検索は強制適用ではありません
決定の検索では、このタスクのガイダンスとして役立つアーキテクチャ上の決定はどれかを確認します。
強制適用では、提案された変更が、ここで適用される統制対象のルールに違反しているかを確認します。
この2つは意図的に分離されています。ADR-017、ADR-019、ADR-020を参照してください。
サポート対象のインターフェース
正式なサポートマトリックスはdocs/integrations/README.mdにあります。以下のラベルは、証拠レベルを示すものであり、相互に置き換え可能な宣伝文句ではありません。
| サポートレベル | インターフェース |
|---|---|
| ネイティブ統合 | Claude Code |
| ネイティブ統合 | Claude Agent SDK |
| ネイティブ統合 | Google Antigravity |
| ネイティブ統合 | Codex CLI |
| ネイティブ統合 | Kiro CLI 3.0 / v3 |
| 互換性検証済み | Paperclip — CLI および ACP トランスポート。アダプター不要 |
| ルールのエクスポート | Cursor |
| CLI ベースの CI ゲート | GitHub Actions、GitLab CI |
| 実験的 | OpenCode |
| 計画中 | Deep Agents ミドルウェアの概念実証 |
各統合のドキュメントでは、実際にブロッキングが行われる境界、回避経路、縮退時の動作、検証の根拠を説明しています。別のハーネスでの経験に基づいて推測するのではなく、まず統合マトリックスを確認してください。
ADR とプロジェクトメモリ
Mneme は、ADR を受動的な文章として扱うのではなく、アーキテクチャ上の決定を構造化されたガバナンス記録にまとめられます。
リポジトリのガバナンスに関する信頼できる唯一の情報源は .mneme/project_memory.json です。ADR のインポートパスでは、利用可能な場合に明示的なソースの来歴を保持するため、型付きルールを一貫して確認し、適用できます。
以下を参照してください。
アーキテクチャの保証
現在の仕組みは、次の 3 つの原則に基づいています。
- 巧妙さより決定性。 適用の動作は再現可能でなければなりません。
- 自律性より監査可能性。 判定の根拠となった決定、ルール、適用可能性の状態、証拠を追跡できなければなりません。
- レビューより予防。 変更前に信頼できる境界がある場合はそれを使用し、ない場合は経路が遮断されているかのように装うのではなく、制約を明示して後から監査します。
現在のレイヤー 1 の対象範囲、凍結された対象、承認済みの修正、実験的な作業、延期されているレイヤー 2 の作業については、docs/architecture/current-phase.md で管理しています。
リンク先の ADR またはアーキテクチャ文書のほうが具体的な場合、この README からアーキテクチャを推測しないでください。
ベンチマークと検証
Mneme のベンチマークは、検索と適用の動作に関する回帰・整合性チェックのためのものです。一般的なモデル品質ベンチマークではありません。
ベンチマークでは検索と適用のスコアを分けているため、ある対象の改善が別の対象の劣化を招いても、気付かれないままになることはありません。
以下を参照してください。
デモ
その他の例:mnemehq.com/demo
コントリビューション
検索、適用、適用可能性、競合処理、またはベンチマークのセマンティクスを変更する前に、対象を規定するアーキテクチャ文書と ADR を読んでください。
中核的な動作の変更には、リポジトリの憲章改定手続きが必要になる場合があります。ドキュメント、ツール、インテグレーション、例は、凍結された動作の変更を自動的に許可するものではありません。
ライセンス
MIT。LICENSE を参照してください。
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。