AIに毎回自分を説明するのをやめた — ChatGPT・Claude・CodexをつなぐPersonal Memory（前編）

新しいチャットを開くたびに、仕事、目標、最近悩んでいること、過去に試したことを説明し直す。その繰り返しをやめるために、ChatGPT、Claude、Codex、Claude Codeが同じ長期記憶を読めるPersonal Memoryを作った。前編では、なぜ必要だったのか、何を「記憶」として残すのか、実際の相談がどう変わったのかを書く。実装の詳細は後編：MCP・OAuth・PostgreSQL＋pgvectorで作るAI横断の長期記憶で紹介する。

0. 作りたかったのはプロフィール帳ではない

最初の相談は単純だった。

「ローカルのClaude Code、ClaudeのWeb版、ChatGPTの間で、自分の性格、特技、悩み、できたことを共有できないか」

プロフィールだけなら、各サービスのCustom Instructionsへ同じ文章を貼ればよい。しかし、実際に引き継ぎたかったのは固定プロフィールではなかった。

• 以前、何について相談したか
• そのとき何を不安に思っていたか
• どんな制約があったか
• どの案を比較し、なぜ一つを選んだか
• 試した結果、何がうまくいき、何が失敗したか
• それから状況や考え方がどう変わったか

たとえば「私はSoftware Engineerです」だけでは、次のキャリア相談にはほとんど役に立たない。過去のプロジェクト、評価への不安、スピードと品質のトレードオフ、他者へ知識を渡すことへの抵抗までつながって、初めて今の自分に合う助言になる。

1. 最初に考えた方法と、その限界

最初からPostgreSQLを建てようと思っていたわけではない。むしろ、できるだけ単純に始めたかった。

INDEXとトピック別Markdownは、小規模なら今でも良い方法だと思う。しかし私が欲しかったのは「必要なファイルを自分で開くノート」ではなく、会話前にAIが関連記憶を探し、相談後に変化を同じ場所へ戻せる仕組みだった。

そこで、MCPを共通の読み書き口にし、保存先を一つにする方針へ進んだ。

2. 原文を全部入れると長すぎる。短い要約では薄すぎる

設計で一番難しかったのは、保存先ではなく、何をどの粒度で残すかだった。

会話の原文をすべて保存すれば情報は落ちない。しかし、毎回それをAIへ渡すことはできない。初期データ100件をまとめて読ませたとき、返却は約535KB、約26万文字になった。しかも当時は詳細本文と要約が実質同じ内容で、要約層が働いていなかった。

逆に、「転職について悩んでいた」「画像を作った」のような一行要約だけでは、次の相談に必要な因果関係が消える。

この中間として決めたのが、詳細case recordだった。

これは会話の書き起こしでも、一般的なサマリーでもない。次のAIが元の会話を開かなくても、なぜその判断に至ったのかを再構成できる最小限の記録を目指している。

具体例：なぜGoogle DriveのMarkdownからPostgreSQLへ移ったのか

最初はGoogle DriveにINDEX.mdとトピック別のMarkdownを置いた。複数のAIから同じ情報を読むところまでは、これで動いた。

この経験を一行だけで保存すると、次のようになる。

Personal MemoryにはPostgreSQL＋pgvectorを選んだ。

しかし、これでは後から「Google Driveで動いていたのに、なぜわざわざデータベースへ移ったのか」が分からない。そこで、判断に至るまでの流れをcase recordとして残した。

後日、「Markdownの束ではなぜ駄目だったのか」と聞かれたとき、AIは「PostgreSQLを使った」という結論だけでなく、最初は何が動き、どこで限界が出て、何と比較して決めたかまで説明できる。これが一行メモと詳細case recordの違いである。

3. 人は変わるので、現在値だけを上書きしない

もう一つの問題は、本人が変化することだった。

「Staff Engineerを目指している」「今の職場に不安がある」「この方法が好き」といった情報は、永遠の真実ではない。今の状態だけを上書きすると、過去の判断がなぜ合理的だったのか分からなくなる。一方で、古い状態を現在の事実として返すのも困る。

そのため、記憶を大きく三種類に分けた。

現在の要約は更新するが、過去のrevisionとevidenceは残す。人間の記憶から着想は得たが、「思い出すたびに原典まで書き換える」部分は真似しない。柔らかく更新する解釈と、硬く残す履歴を分けた。

4. AIには全部読ませず、必要なところまで段階的に開く

毎回何百件も読む問題は、三段階の読み込みに変えた。

1. index — タイトル、カテゴリ、タグ、短い索引だけを見る
2. summary — 関係しそうな記憶の詳細case recordを読む
3. full — 正確な引用が必要なときだけ原文evidenceを読む

図書館で、最初から全ページを机に積むのではなく、蔵書検索から本を絞り、必要なら該当ページを開くのに近い。

5. 実際の相談はどう変わったか

一番分かりやすかったテストは、キャリア相談だった。

Claudeに、「Big TechのStaff Engineerを目指す場合の現在の強みと不足している証拠を、過去の仕事、スピードと品質のトレードオフ、これまでの不安を踏まえて整理してほしい」と聞いた。さらに、事実と推論を分け、次の90日でやることを三つに絞るよう頼んだ。

AIは一つのプロフィールを読むのではなく、10件の記憶を横断した。そこには、過去の職務経験、数値化された成果、開発スピード、品質投資への不安、昇格基準の曖昧さ、知識を共有すると自分の価値が下がるのではという恐れが別々に保存されていた。

返ってきた提案は、次の三つだった。

1. 複数システムを一枚で説明するPlatform Layerの設計文書を作る
2. 1on1で昇格基準を「証拠リスト」と「判定日」へ変える
3. 名前の付いた知識移転を一件実行する

重要だったのは、これらが一般的なStaff Engineer向けチェックリストではなかったことだ。私の強みが個人の実行速度に偏り、不足している証拠が「他者へ再現可能な形で渡したこと」だという、複数の過去記録から作られた推論だった。

これで初めて、Personal Memoryが検索デモではなく、過去の経験を材料に新しい助言を作る仕組みになったと感じた。

6. 「自動で更新される」の実際

ここは誤解しやすい。サーバーがすべての会話を勝手に盗み見て保存するわけではない。

対応するAIクライアントには、個人的な相談の前に索引を読み、会話で将来役立つ変化があれば保存候補を作る指示を置く。通常のprivateな追加や状態変化は、私があらかじめ与えたstanding approvalの範囲で提案から確定まで進められる。

一方で、次の操作は自動確定しない。

• 既存事実を争う訂正
• 複数記憶の統合
• 削除
• 公開または非公開化

また、既存のチャットへサーバーから記憶をpushするわけではない。各クライアントが次の相談で読みに来たとき、最新revisionが見える。

7. 個人情報は保存する。ただし秘密情報と公開は分ける

このシステムの目的は、抽象化しすぎない助言を受けることだ。そのため、本人が話した名前、会社、年収、上司、仕事、人間関係、悩みは、必要なら具体的にprivate記憶へ入れられる。

ただし、次は常に保存を拒否する。

• SSNなどの政府識別番号
• パスワード
• APIキー
• 復旧コード
• 秘密鍵

さらに、private記憶とブログは別経路にした。ブログが読むのは、明示的に内容を確認し、必要なredactionをしたpublic projectionだけである。privateな原文やevidenceを、そのままフロントエンドへ送らない。

暗号化や認証は重要だが、AIが認証済みで読み込んだ情報は、そのAIサービスへ渡る。ここは暗号化では解決できない。結局、「どのクライアントへ、どの記憶を読ませるか」という運用上の信頼境界は残る。

8. うまくいかなかったことも含めて、今の評価

Personal Memoryは、少なくとも次の点では使える状態になった。

• Claude、ChatGPT、Codex、Claude Codeが同じ正本へ接続できる
• 日本語と英語が混ざった過去記録を検索できる
• 事実とAIの推論を分けた回答を作れる
• 状況が変わっても過去を消さずに更新できる
• private記憶とブログ公開用データを分離できる

一方、完全な「第二の脳」ではない。

• 検索語とaliasが悪いと、存在する記憶を見落とす
• AIが毎回必ず適切なツールを呼ぶかは、クライアント設定にも依存する
• 似た記憶の統合は情報を失う可能性があり、まだ人間の確認が必要
• 過去会話の一括取り込みは、モデルのusage、レート制限、重複処理との戦いになる
• 記憶から正しく数字を取得できても、元の数字そのものが未確認なら事実にはならない

それでも、毎回ゼロから自己紹介する状態には戻りたくない。今は「AIが私を知っている」というより、私の過去を必要なときに調べ、根拠を示しながら考えられる状態に近い。それくらいの距離感が、むしろ信頼できる。

後編では、MCP、OAuth＋PKCE、PostgreSQL＋pgvector、FTS/trigram/vectorのハイブリッド検索、immutable revision、過去会話backfill、そして実際に踏んだ失敗を、実装側から詳しく書く。

→ 後編：MCP・OAuth・PostgreSQL＋pgvectorで作るAI横断の長期記憶