🔗

Claude Code/Cursor/Codex/Gemini、5LLM 横断して記憶する方法

に公開

こんな経験ありませんか?

土曜の朝、 新機能を開発する。 まずは Codex で DB migration の boilerplate を書かせる (= 機械的な作業、 Codex の方が早い)。 「users table の email column は CITEXT、 RLS は auth.uid() で scope」 と方針を伝えて、 30 分で完成。

水曜、 同じ機能の 複雑なビジネスロジックClaude Code で組み始める (= reasoning 必要、 Opus がよく考えてくれる)。

You:    Codex で書いた migration の RLS 制約、 ここで効くんだっけ?
Code:   申し訳ありません、 Codex の作業履歴にはアクセスできません。
        migration の内容を教えていただけますか?
You:    [~/.codex/ にある migration 全部 grep して Code に貼り直す]

別の例: 月曜、 大量の TypeScript 型定義Cursor (= Sonnet 4 安価) に量産させて token 節約。 火曜、 そのコードの アーキテクチャ判断Claude Code (= Opus、 reasoning 強い) に持ち込む。

You:    昨日 Cursor で 50 ファイル 型生成したんだけど、 これ
        集約する shared/types/ の構造どうすべき?
Code:   Cursor の出力を見れないので、 全 50 ファイル の
        構造を共有してください。
You:    [50 ファイル の type signature を貼る、 token 大量消費]

LLM 使い分けは コスト 効率 の最適化 (= 安い LLM で量、 高い LLM で質)。 でも各 LLM が 自分の memory に閉じているので、 結局 手動で context を再共有。 これが日常の pain。

これは Claude / Cursor / Codex / Gemini の bug ではなく、 設計上の挙動。 公式 memory tool (= Anthropic memory / ChatGPT memory) も同じく、 そのプロバイダー内に閉じている。

この記事は、 「LLM 横断で過去の判断 / 制約 / 構造を 全部共有」 する方法を 5 分で説明する。

体感の before / after

before — 各 LLM が独立した memory (= 手動で context 再共有)

土曜 Codex で migration 作成:
  You:    users / orgs / clients table、 RLS は auth.uid() で
          org_members 経由で scope。 fiscal_year_end は YYYY-MM-DD
          じゃなく "MM-DD" string で保存して (= 12月決算対応)。
  Codex:  完了。 migration file 9 個 作成しました。

水曜 Claude Code で API 設計:
  You:    Codex で書いた migration を前提に、 invoices CRUD endpoint 設計して。
  Code:   migration の中身を確認させてください。
          fiscal_year_end の format ? RLS policy の正確な定義?
  You:    [~/.codex/ history grep → 50 行貼り付け]
          ↑ context window の 30% 消費、 token も 5x 余分に支払う

after — 1 つの SQLite ファイルを 全 LLM が読み書き

土曜 Codex で migration 作成:
  You:    [上と同じ instruction]
          ↑ これを caveat に保存して。
  Codex:  🧠 [caveat] DB schema 設計判断
            - RLS scope: auth.uid() → org_members → org_id 経由
            - fiscal_year_end format: "MM-DD" string (= 12月決算対応)
            - migration files: 9 個、 supabase/migrations/ 配下
          (importance: 0.9、 protected)
          記録しました。

水曜 Claude Code で API 設計:
  You:    Codex で書いた migration を前提に、 invoices CRUD endpoint 設計して。
  Code:   🧠 [caveat] DB schema 設計判断 (土曜 Codex で記録)
            - RLS scope: auth.uid() → org_members 経由
            - fiscal_year_end "MM-DD" string
          この caveat に基づいて endpoint 設計します:
          [正しい設計、 月曜 Codex の判断を完全継承]

1 回 caveat 保存しただけで、 別 LLM が prior reasoning を継承。 context 再共有 0、 token 30% 節約、 「migration 何だっけ?」 で 5 分溶かす 日常 が消える。

何が起きてるのか — 各 AI の memory 設計

AI 公式 memory scope cross-LLM
Claude (Anthropic memory tool) ✅ あり Claude のみ
ChatGPT (Custom GPT memory) ✅ あり ChatGPT のみ
Cursor △ (manual rule files) Cursor のみ
OpenAI Codex △ (~/.codex/ config) Codex のみ
Gemini CLI △ (settings.json 内) Gemini のみ

5 つの memory が 並列に存在、 互いに知らない。 「公式で十分」 と思えるのは 1 LLM しか使わない人だけ。 power user は 4-5 LLM 併用が普通、 そこで memory 喪失が起きる。

解決: 単一 SQLite を 5 LLM で共有する MCP

Linksee Memory は MCP server。 ~/.linksee-memory/memory.db という 1 つの SQLite ファイルに caveat / goal / learning / implementation を記録する。 Claude / Cursor / Codex / Gemini が 同じファイルを読み書きするので、 1 回教えれば 全 AI で共有される。

┌──────────────────────────────────────────┐
│  ~/.linksee-memory/memory.db (1 file)    │
└──────────────────────────────────────────┘
       ↑      ↑      ↑      ↑      ↑
       │      │      │      │      │
  Claude  Cursor  Codex  Gemini  ChatGPT app *
  Code    IDE    CLI    CLI     (= Remote MCP 化が必要)
                                  でも基盤は同じ

* ChatGPT consumer app は stdio MCP 非対応、 HTTPS Remote MCP server 化が要る (= Linksee Memory v0.4 で対応予定)。 ただし その他 4 LLM は今すぐ全部つなげられる。

5 分で 4 LLM 全部に install する手順

Step 1: Linksee Memory を install (= 1 ファイル DB が作られる)

npm install -g linksee-memory
# or 各 LLM 設定の中で npx -y linksee-memory

~/.linksee-memory/memory.db が自動作成される。 これが 共有 DB

Step 2: Claude Code に登録

claude mcp add -s user linksee -- npx -y linksee-memory

Step 3: Cursor に登録

Cursor → Settings → Features → "Model Context Protocol" → Edit。 以下を 貼り付け:

"linksee": {
  "command": "npx",
  "args": ["-y", "linksee-memory"]
}

Step 4: OpenAI Codex に登録

codex mcp add linksee-memory -- npx -y linksee-memory

または ~/.codex/config.toml に:

[mcp_servers.linksee-memory]
command = "npx"
args = ["-y", "linksee-memory"]

Step 5: Gemini CLI に登録

~/.gemini/settings.json を編集:

{
  "mcpServers": {
    "linksee": {
      "command": "npx",
      "args": ["-y", "linksee-memory"]
    }
  }
}

→ 4 つの LLM、 全部 同じ MCP server を install = 全部 同じ DB を読む。 5 分で 4 LLM 横断 memory 完成。

動作確認 (= cross-LLM テスト)

Codex で アーキ判断を caveat 化

You:    「Supabase の RLS policy は org_members table を介して
        2 階層スコープする。 直接 auth.uid() を WHERE で
        使わない。 これ caveat に保存して、 importance 0.9」
Codex:  🧠 caveat 保存しました (memory_id: 1234)。

Claude Code を開く (= 同じ machine、 別 LLM、 別日)

You:    Supabase の transactions table の RLS policy 書いて
Code:   🧠 [caveat] 「RLS policy は org_members 経由 2 階層 scope、
                   直接 auth.uid() WHERE 使わない」 (importance: 0.9)
        この caveat に従って RLS policy 生成します:

        CREATE POLICY transactions_org_scope ON transactions FOR ALL
          USING (org_id IN (
            SELECT org_id FROM org_members WHERE user_id = auth.uid()
          ));
        [正しい 2 階層 scope policy]

→ Code が Codex の 過去判断を そのまま recall + 適用。 「Codex で 私 何決めたっけ?」 が消える。 1 ファイル DB の威力。

つまづきポイント (3 つ)

罠 1: npm package を 2 重 install する

npm install -g linksee-memory を 1 回やったあと、 さらに 各 LLM の設定で npx -y linksee-memory も指定する人がいる。 これは OK (= npx は cache から global install を使う)、 ただし update 時は npm i -g linksee-memory@latest で global を更新する。

罠 2: DB ファイルを 別 path に作ろうとする

~/.linksee-memory/memory.db絶対 path 固定で、 全 MCP instance がここを読む。 環境変数 LINKSEE_MEMORY_DIR で override できるが、 全 LLM 設定で 同じ override を指定しないと別 DB を読む。 default のまま使うのが安全。

罠 3: ChatGPT consumer app を期待する

ChatGPT (= web / mobile app) は stdio MCP を 読まない (= HTTPS Remote MCP server が要る)。 OpenAI Codex (= CLI dev tool) は読む、 ChatGPT app は読まない。 混同しがち。 ChatGPT app 対応は Linksee Memory v0.4 で Remote MCP build 予定。

TL;DR

  • Claude / ChatGPT / Cursor / Codex / Gemini は 各自の memory に閉じている (= 設計上)
  • 5 LLM 併用する power user は 1 LLM ごとに caveat を再教育する必要があり、 これが pain
  • Linksee Memory は MCP server で 1 つの SQLite ファイルを 4 LLM が読み書き
  • 5 分で Claude Code / Cursor / Codex / Gemini CLI 全部に install 可能 (ChatGPT app は v0.4 で対応予定)
  • 1 回教えれば 全 AI が知っている、 caveat 再教育 0

次のアクション

今すぐ試したい人(個人は完全無料):

npm install -g linksee-memory
npx -y linksee-memory-install-skill

各 LLM への登録は 上記 Step 2-5。 完了後、 Claude Code で 1 つ caveat 保存 → 別 LLM で recall できれば成功。

Pro tier (= cross-device cloud sync / team shared memory / web dashboard) は 2026 夏 launch 予定、 LP の waitlist から登録できる。

Discussion