Claude CodeとCodexの切り替えでコンテキストを失わない方法
馴染みのある状況了吧:Claude Codeと一緒にターミナルに座り、分散キューの厄介なバグを1時間半かけてデバッグし、動作しない仮説を5つ試して、ようやく正しい解決策を見つけた。そしてセッションが大きくなり、コンテキストが圧縮され、リミットに天井にぶつかる。同じフォルダでCodexやOpenCodeに切り替えると、サーカスが始まる。新しいアシスタントは最初から briefing が必要だ:なぜNGINX設定に触れないのか、どのテストがすでに失敗しているのか、20分前に選んだデータベース構造は何か。
ai-memoryプロジェクトは、この問題を完全に解決することを目的としている。Fabio Akita(コミュニティではAkitaOnRailsとして知られる)によって作成された。このアイデアは、コンソールAIエージェントに共有長期メモリを提供し、セッション間や異なるモデル間での自動的なコンテキスト引き継ぎを可能にすることだ。
コンセプト
通常、「AIメモリ」とは、生のダイアログログを埋め込みとしてベクトルデータベースにダンプすることを意味する。実際のところ、これらのログは中間的なツール呼び出し、反復的なテスト実行、構文エラーなどゴミだらけだ。
ai-memoryの著者は、KarpathyのLLM Wikiコンセプトに触発され、別の道を歩んだ。メモリはGitリポジトリ内のMarkdownファイルの通常のWikiとして構造化されている。サーバーはエージェントのライフサイクルイベントを傍受し、不要なノイズを除去し、セッション終了時に圧縮サマリーをコンパイルする:何が行われたか、どのような結論に達したか、どのようなタスクが残っているか。
異なるエージェントで新しいターミナルを開くと、ツールは最初のプロンプト直前に構造化されたサマリーを自動的に提供する。手動のクリップボードコピーは不要だ。
内部構造とターミナル
サーバーはRustで書かれている。MCP(Model Context Protocol)サポート、ライフサイクルフック、組み込みWebインターフェースを備えたローカルサービスを起動する。
事実上すべての現在のエージェントCLIをサポートしている:
- Claude Code
- OpenAI Codex
- Command Code
- Devin CLI
- OpenCode、Cursor、Zed
- Gemini CLI、Grok Build CLI、Kimi Code、Kiro CLI、Pi / OMP
データは単一のディレクトリにローカルに保存される:
<data_dir>/
├── wiki/ # Markdown-страницы под версионным контролем Git
├── raw/ # очищенные сегменты сессий
├── db/ # SQLite с индексами FTS5, сущностями и эмбеддингами
└── logs/ # логи работы
各プロジェクトはリポジトリパスまたはマーカーファイル .ai-memory.tomlで分離される。モノレポや複数のGit worktreeを使用している場合、それらは統一されたコンテキストにリンクされる。
実践における主要機能
エージェント間のシームレスな切り替え
ai-memoryには管理セッションーモード ai-memory runがある。動作はシンプルだ:
cd /path/to/project
ai-memory run claude
# Закончили работу в Claude Code, продолжаем задачу в Codex:
ai-memory run codex --yolo
# А потом возвращаемся к сессии через Command Code:
ai-memory run command-code
エージェントは起動時に「前回の続き」ブロックを読み取る。そこには最近のアーキテクチャ上の決定、未解決の質問、テスト結果が含まれている。エージェント名を指定しない場合、 ai-memory run コマンドは現在のフォルダで最も最近のアクティブセッションを自動的に選択する。
ai-memory continue コマンドはさらに一歩を進める:任意のフォルダから呼び出すことができ、最後に作業していたプロジェクトに戻ってくれる。
ログダンプの代わりにWiki
ナレッジベース全体がプレーンテキストとして保存される。Obsidianで開いたり、 grep で読んだり、ポート 127.0.0.1:49374/web の組み込みブラウザで閲覧したりできる。
重要なプロジェクトルールを記録したい場合は、エージェントに「キューにはNATS JetStreamを使用するということを恒久メモリに保存して」と伝えればいい。エージェントはMCPツール memory_write_page を呼び出し、バージョン管理されたMarkdownファイルがリポジトリに作成される。
ナレッジベースの検索はハイブリッドだ。SQLite FTS5全文検索が最初に実行され、その後エンティティマッチングとページ間のグラフ接続が続く。埋め込みモデルに接続すると、ベクトル検索も追加される。
同時に、ai-memoryは安定したアーキテクチャルールと一時的なセッションノートを区別でき、 _rules/ と decisions/ フォルダからの安定したページを優先する。
外部LLMなしでの動作
興味深い詳細:ai-memoryはニューラルネットワークのAPIキーなしで起動する。「ゼロLLM」モードでは、検索はFTS5とエンティティを通じて動作し、セッションサマリーは決定論的ルールを使用してアセンブルされる。
キーを設定すると(Anthropic、OpenAI、Gemini、または互換性のあるエンドポイント経由のローカルOllama)、ツールはスマートなページ統合、ナレッジベースの競合検出、プロジェクトのバックグラウンド自己学習を有効にする。
Dockerによるクイックスタート
ワークステーションにサーバーを展開する最も 빠른 方法:
# 1. Запускаем локальный сервер
docker run -d --name ai-memory \
--restart unless-stopped \
-p 127.0.0.1:49374:49374 \
-v ai-memory-data:/data \
-e AI_MEMORY_LLM_PROVIDER=anthropic \
-e ANTHROPIC_API_KEY=sk-ant-... \
akitaonrails/ai-memory:latest
# 2. Подключаем MCP и хуки для Claude Code
ai-memory install-mcp --client claude-code --apply
ai-memory install-hooks --agent claude-code --apply
Arch Linuxユーザーの場合、AURでsystemdユニット付きの готовые パッケージ ai-memory-bin が利用可能だ。macOS向けにはApple SiliconとIntelのネイティブバイナリがリリースされている。
サーバーがホームサーバーやローカルネットワークに移動された場合、セキュリティはBearerトークンを介して設定される。サーバーはリクエストをlistenし、認証を確認し、オペレータースロット介して複数の開発者間のメモリを分離する。
何に役立つか
このツールは3つの具体的なタスクを解決する。
1つ目——マルチエージェント開発。Claudeでタスクを起草し、Codexでリファクタリングし、Geminiでコードレビューを行う方が速い。共有メモリレイヤーがないと、このワークフローは終わりなきコンテキストコピー作業になる。
2つ目——古いリポジトリへのエージェントのオンボーディング。 ai-memory bootstrap コマンドはコミット履歴、README、プロジェクトドキュメントを読み取り、初期ナレッジベースページを生成する。
3つ目——ローカル監査。いつでもWebインターフェースを開いて生成されたノートを確認し、 ai-memory restore-page で悪い編集を元に戻したり、古いデータをクリーンアップしたりできる。
まとめ
ai-memoryは実用的なアプローチでアピールする。外部ベクトルデータベースを使用した別の重量級スタックを構築する代わりに、著者は高速なRust、信頼性の高いSQLite、シンプルなGitとMarkdownを選んだ。
ターミナルAIアシスタントを積極的に使用しており、毎日モデルにプロジェクトコンテキストを説明し直すのに疲れているなら、リポジトリは確かに見る価値がある。ローカル実行から始めて、メインのCLIエージェントとペアにして、タスク間のコンテキスト転送がどれほど便利かを評価してみよう。
関連プロジェクト