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 できれば成功。
- GitHub (star 歓迎): https://github.com/michielinksee/linksee-memory
- LP (Pro tier waitlist): https://linksee-site.vercel.app/?utm_source=zenn&utm_medium=article&utm_content=crossllm_0514
- 過去記事:
Pro tier (= cross-device cloud sync / team shared memory / web dashboard) は 2026 夏 launch 予定、 LP の waitlist から登録できる。
Discussion