mex-memory/mex レビュー: チームの記憶を Git に載せる MCP 対応メモリ層
Team memory for engineers and their AI agents. Lives in your repo. Shared through Git.
ひと目でわかる
- これは何？
- エンジニアとコーディングエージェントの共有コンテキストを、リポジトリ内の Markdown と Code Graph として保持する TypeScript 製 CLI。Git を同期層にする設計と、その代償を読む。
- 誰に向いている？
- 採用を検討すべきなのは、複数人が同じリポジトリで Claude Code や Codex を使い、セッションをまたぐ引き継ぎコストが実際に発生しているチームだ。単独作業で完結する人、Git のレビュー文化が薄い組織、Node.js 22.5 未満の環境には向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
誰の何を解決するのか: セッションの外に漏れ出す知識
このプロジェクトが名指ししている問題は、コードそのものではなく、コードの周辺にある説明の散逸である。README は「あるエンジニアは制約がなぜ存在するかを知っている。別のエンジニアはデバッグ履歴を持っている。コーディングエージェントは、誰も読まないセッションで重要なエッジケースを見つけた」と書く。つまり対象は、リポジトリを読めば分かることではなく、リポジトリを読んでも分からないことだ。設計判断の理由、過去に踏んだ地雷、次の担当が最初に知るべき前提。これらは Slack のログ、閉じた PR のコメント、あるいは誰の端末にも残っていないエージェントのコンテキストに散らばる。
想定利用者は、同じリポジトリで複数人がエージェントを併用しているチームである。README の例では Alex と Sam という 2 人のエンジニアが登場し、Alex が Codex に既存アーキテクチャと関連する決定を調査させ、変更を加え、Sam に引き継ぐ。単独開発者も対象外ではない。README は「メモリを使う次の人物は、新しいセッションのあなた自身かもしれない」と述べている。ただしこの一文は、チーム共有という主目的に対する補足として置かれている。
Git を同期層にするという設計判断
MEX の最も特徴的な点は、共有の仕組みを自作していないことだ。正典となるメモリは通常の Git の commit、push、pull で移動する。README は「ホスト型の MEX サービス、Docker、プロキシ、MEX アカウント、MEX 所有のモデルキーは不要」と明記している。認証もストレージも課金も Git ホスト側に委ねる。
この判断には具体的な帰結がある。各メンバーは自分のローカルインデックス、下書き、ID 選択、Hub をそれぞれ持つ。共有されるのは Markdown などの正典ファイルだけで、インデックスは共有されない。したがって、pull しただけでは検索やグラフが最新にならず、ローカルインデックスの更新という手順が挟まる。README の例でも Sam は「必要に応じてローカルインデックスを更新してから Hub を開く」と書かれている。同期の責務が Git とローカルインデックスに二分されている点は、理解しておかないと「pull したのに反映されない」という混乱を生む。
Wiki、Inbox、Relay、Code Graph の役割分担
README の表は、チームが保持したい情報の種類ごとに置き場所を割り当てている。システムの仕組みと理由は Wiki のアーキテクチャ、決定、規約、パターンとして Code Graph の裏付け付きで置かれる。共有に値する決定や説明は Inbox の提案として既存の Wiki 知識を追加または訂正する。製品要件は既存の Specs が引き続き担う。次の担当がどこから続けるかは Relay に、進捗、決定、ブロッカー、根拠、次のアクションとして書かれる。過去のワークフロー文脈は Workstream レコードとして読める状態が保たれる。
ここで重要なのは、書き込みの経路が 2 つに分かれていることだ。エージェントが Wiki の説明とコード参照を直接更新する経路と、チームのレビューに回すべき結論を Inbox の知識提案として用意する経路である。README の例では、Codex は Alex の指示の下で Wiki を更新しつつ、レビューが必要な結論については明示的な承認のために Inbox 提案を準備する。つまり「エージェントが勝手に正典を書き換える」のではなく、レビュー対象かどうかで経路が分岐する。
Relay の境界: 引き継ぎは配送ではない
Relay はこのプロジェクトで最も誤解を招きやすい部分だ。README は「Relay が運ぶのは説明と観測されたリポジトリの状態であり、未コミットのコードではない」とし、さらに「公開は Alex のチェックアウトにファイルを書き込むだけで、Sam に通知したり何かを配送したりはしない。Git を通じて共有されるまで届かない」と明記する。
これは制約であって欠陥ではない。通知基盤を持たない代わりに、引き継ぎの内容がコードと同じレビュー経路に乗る。Alex は Hub で下書きと公開プレビューを確認し、明示的に公開してから、コードと正典 MEX ファイルを commit、push する。Sam 側では Relay の受け取り自体が「もうひとつの正典変更」となり、これも commit と push の対象になる。受け取りの事実まで履歴に残る設計だ。ただしチームがこの境界を理解していないと、公開しただけで相手に届いたと誤認する。README 自身が「Relay boundaries」節への参照を置いて、ライフサイクルと並行性の詳細に読者を送っている。
導入手順とバージョン 0.8.1 で変わった点
パッケージは npm の mex-agent として配布され、Node.js 22.5 以上と TypeScript 5.9 が前提として示されている。CLI と、Claude Code 向けの $mex-relay のようなスキル、そして MCP サーバーで構成される。MCP については README のバッジが「MCP: source only」と明示しており、ここは導入前に確認すべき点だ。
リリースノートによれば v0.8.1 は「Explore context, share knowledge, keep work moving」と題され、視覚的な Context graph、プロジェクト知識への Inbox コントリビューション、チームに開かれた Relay、設定可能なエージェントログ、より安全なグラウンディング、そして Graph 構築中もリクエストを処理し続けられる Hub が挙げられている。v0.8.0 は「Project memory for the whole team」、v0.7.3 は「Graph performance and recovery」で、直近 3 版がグラフ性能、復旧、チーム共有の順に重心を移してきたことが読み取れる。Graph 構築中の可用性が 0.8.1 で改善項目に挙がっているということは、それ以前は構築中に Hub が止まりうる挙動だったと推測できるが、README には明示的な記述がない。
向かないケースと、代替との設計差
第一の制約は前提環境である。Node.js 22.5 以上が要求され、MCP はソースからのみとされている。古い LTS で固定されたモノレポや、npm 以外の配布経路しか許さない環境では、その時点で選択肢から外れる。
第二に、このツールは Git のレビュー文化を前提とする。Inbox 提案も Relay も、最終的には人間が確認して commit する流れを想定している。レビューを経ずにエージェントへ直接コンテキストを流し込みたいだけなら、MEX の提案と承認の往復は純粋なオーバーヘッドになる。
代替として挙げられるのは、エージェント側が提供するリポジトリ指示ファイルとセッション内メモリの組み合わせ、あるいは AGENTS.md のような単一の指示文書だ。違いは粒度と履歴にある。単一ファイルは 1 つの文書を全員が編集するため、変更の意図とレビューが同一平面上で衝突しやすい。MEX は Wiki、Inbox、Relay、Specs という種類ごとに置き場所を分け、Code Graph で説明と実装を結びつける。その代わり、扱う概念の数は明らかに多い。
保守コストとライセンス
ライセンスは MIT で、リポジトリの LICENSE へのリンクが README から張られている。MIT である以上、社内利用や改変、再配布における制約は小さい。ただしこれは法的助言ではない。エージェントが生成した知識提案を正典として commit する運用にするなら、その内容の扱いをチームのポリシーとして別途決めておく必要がある。
保守の観点では、MEX が Git に書き込むのは Markdown などのファイルなので、ツールを後で外してもリポジトリに残るのは読めるテキストである。ここはロックインが小さい。一方で、更新のたびにローカルインデックスの再構築が絡む。v0.7.3 の「Graph performance and recovery」と v0.8.1 の「Graph 構築中も Hub が応答し続ける」という項目は、グラフ構築がこのプロジェクトの継続的なコスト中心であることを示している。大規模リポジトリでグラフ構築がどれだけ時間を要するかは、提供された資料からは判断できない。導入検討時に自分のリポジトリで計測すべき項目だ。
編集部の結論
採用を検討すべきなのは、複数人が同じリポジトリで Claude Code や Codex を使い、セッションをまたぐ引き継ぎコストが実際に発生しているチームだ。単独作業で完結する人、Git のレビュー文化が薄い組織、Node.js 22.5 未満の環境には向かない。導入前に確認するのは、mex init が生成するディレクトリ構成が既存の .gitignore や CI と衝突しないこと、Hub がローカルで完結するか、そして Relay の公開が「ファイル書き込みであり通知ではない」という境界をチーム全員が理解できるかどうかである。
コミュニティノート