Claude CodeとCodex CLIの記憶共有ツールmemcpを運用視点で検証する

複数のAIコーディングエージェントを併用しているエンジニアに向けた話です。Claude Code（Anthropic製のCLI型AI開発支援ツール）とCodex CLI（OpenAI製の同種ツール）を場面によって使い分けている場合、両者のセッション履歴が別々のフォーマットで保存され、互いに参照できないという問題があります。この状態を解消するオープンソースツール「memcp」の仕組みを、クラウド運用や障害対応の文脈でどう捉えるべきか整理します。

memcpは複数のAIエージェントのセッションログを1つのローカルSQLiteデータベースに集約し、MCP（Model Context Protocol、AIエージェントが外部ツールやデータソースにアクセスするための標準プロトコル）経由で他のエージェントに公開する仕組みです。GitHubのnnyannya-tech/memcpリポジトリで公開されており、クラウド同期やテレメトリ送信は行わず、全データがローカルマシンに留まる設計になっています。

何が起きているのか: エージェント間の「記憶の孤島」問題

Claude CodeとCodex CLIは別ベンダーの製品なので、セッションログの保存形式がまったく異なります。前者はある形式、後者は「rollout-style」と呼ばれるJSONL（1行1JSONの形式）でログを吐き出します。

この違いにより、片方のツールで決めたアーキテクチャ判断や修正したバグの経緯を、翌日別のツールで一から説明し直す手間が発生します。運用の現場に置き換えると、障害対応の記録がSlackとConfluenceとJiraコメントに分散していて、どこに正しい根本原因（ルートコーズ）が書いてあるか探し回る状況に近いといえます。

memcpはこの分散した記録を一箇所に正規化して集約する点で、ポストモーテム（障害後の振り返り記録）の一元化に似た発想を持っています。

技術的な仕組みを段階的に見る

memcpの処理フローは次の順で進みます。

エージェントのセッションが終了
  ↓ (自動)
ログをパースして正規化
  ↓
ローカルSQLite DBに保存 (FTS5で全文検索可能)
  ↓
接続中のどのエージェントからでもMCP経由で検索可能

この中で重要なのが「正規化」の工程です。各エージェント専用の小さなパーサーが、独自形式のログをsession（セッション単位）・message（発言）・tool call（ツール呼び出し）という共通スキーマに変換します。新しいエージェントへの対応を追加する場合も、次のシグネチャを持つ関数を1つ書くだけで拡張できる設計です。

ParseFn = Callable[[Path], tuple[Session, list[Message], list[ToolCall]]]

memcpはMCPツールとして4つの機能を公開しています。search_memoryは全セッション横断の全文検索、read_sessionは特定セッションの会話を読む機能、list_recent_sessionsは直近セッションの一覧表示、ingest_sessionは特定のログファイルを手動で取り込む機能です。

実際の動作例として、数日前のClaude CodeセッションでJWTリフレッシュトークンのローテーション方式（Redisを使ったスライディングウィンドウ方式）を決めた後、別日にCodex CLIで同じ質問をすると、search_memoryが呼ばれてClaude Code側の記録を正しく引用する、という挙動が報告されています。

クラウド運用の観点からどう見るか

この仕組みを監視・障害対応の実務に照らすと、いくつか比較できる既存の考え方があります。

まず、SREの現場で使われるインシデント管理ツール（PagerDuty、Opsgenieなど）は、アラートの発生源が複数（クラウドベンダーの監視、APM、ログ基盤）に分散していても、1つのタイムラインに集約する設計を採っています。memcpのSQLite集約も同じ思想で、記録の分散を解消する点は共通しています。

次に、全文検索にFTS5（SQLiteの拡張機能）を使っている点は、Elasticsearchのような重量級の検索基盤を持ち込まずに済む選択として妥当です。個人のローカル開発環境や小規模チームでの利用であれば、追加のインフラコストなしに検索性能を確保できます。ただし複数人・複数マシンでログを共有したい場合、SQLiteはファイルベースのDBなので、同時書き込みや複数ホストからのアクセスには向いていません。チームで同様の仕組みを検討するなら、共有ストレージへの書き込み競合や、DBファイルのバックアップ運用まで見越しておく必要があります。

また、「セッション終了時に自動でログを取り込む」仕組みは、Claude Code側にはSessionEndフックが存在するため機能しますが、Codex CLI側には現時点でこの相当のフックイベントが用意されていません。つまり自動連携の完成度にはツールごとの差があり、Codex CLI側は手動でのingest_session実行が必要になる場面が残っています。継続利用を検討する場合は、この非対称性が運用の抜け漏れにつながらないか確認しておく方が安全です。

今日確認できること

memcpの導入や類似構成の検討にあたって、次の点を確認しておくと判断しやすくなります。

使用中のClaude Code・Codex CLIのバージョンが、それぞれのMCPサーバー登録機能に対応しているか（各ツールの設定ドキュメントでMCP関連の項目を確認）
プロジェクト直下のCLAUDE.mdやAGENTS.mdに「proactively search memory」のような、能動的に記憶を検索させる指示が書かれているか（書かなければMCPツールは呼び出し可能な状態のまま使われない）
ログの保存先ディレクトリと、既存の監視ログ・監査ログの保存ポリシーが衝突しないか（特にセキュリティ要件が厳しい環境では、コード内容や会話ログのローカル保存自体が社内規程に触れる可能性がある）
複数人での共有を想定する場合、SQLiteファイルの同時アクセス制御やバックアップ体制をどう設計するか

これらは公式リポジトリのREADMEやセットアップ手順に記載がある範囲で確認できる項目です。導入前にドキュメントを開いて、上記の設定箇所が自分たちの環境にそのまま当てはまるかを見ておくと、後からの手戻りを防げます。

まとめ

memcpが解決しているのは、複数のAIコーディングエージェントを使う際に発生する「記憶の孤島」問題です。ログの正規化とMCP経由の公開という2段構えの仕組みで、ベンダーの異なるツール間でも会話の文脈を引き継げるようにしています。

運用視点で見ると、この設計はインシデント管理ツールの記録集約や、ポストモーテムの一元化と近い発想を持っています。一方でSQLiteベースゆえの同時アクセスの弱さや、Codex CLI側の自動取り込み未対応といった制約も現時点で残っています。

導入を検討する場合は、まず自分の環境のツールバージョンとMCP対応状況を確認し、CLAUDE.mdやAGENTS.mdへの指示追加が必要かどうかをチェックしてみてください。ログ保存が社内のセキュリティポリシーに抵触しないかも、あわせて見ておくと安心です。