※「ChatGPTと育てる、自分専用AI基盤」第1回。自分で使うAI環境を、実際に困った順番に作ってきた記録です。
ここでいう「長期記憶」は、ChatGPTのモデル内部に記憶を追加するという意味ではありません。後の会話や別のAIからも参照できる、外部の知識・記録基盤という意味で使っています。
ChatGPTを長く使っていると、少し変な状況が起きます。
その場の会話ではかなり深いところまで話せる。仕事の背景も説明できるし、どういう考えで判断したのかも残せる。ところが、別のChatへ移ると、その積み重ねをもう一度説明しなければならないことがある。
私の場合、研究、会社の案件、ブログ、投資、サーバー開発など、扱う話題がかなり多い。しかも一つのテーマが数か月、場合によってはもっと長く続きます。
毎回ゼロから説明するのは面倒です。それ以上に困ったのは、「以前なぜそう決めたのか」が会話の奥に埋もれていくことでした。
そこで最初に欲しくなったのが、ChatGPTの外に置く長期記憶でした。
Chatを記録の本体にしない
2026年7月下旬に残した構想を見ると、この時点ですでに方針はかなり単純でした。
Chatは作業画面。Vaultを長期記憶にする。
ChatGPTとの会話そのものを正式な記録庫にするのではなく、残す価値があるものをMarkdownとして外へ出す。過去の判断、案件情報、記事候補、調査結果、失敗、今後の方針などを、後から検索できる形で持っておく。
保存先にはVPS上のMarkdown Vaultを使うことにしました。
Markdownにしたのは、特別なアプリがなくても読めて、検索しやすく、差分も取りやすいからです。将来別のAIや別のツールへ移っても、ただのテキストとして残ります。
ただ、サーバーにフォルダを作っただけではChatGPTから使えません。
そこで、そのVaultをChatGPTから検索したり、文書を作ったりできる窓口として作ったのがKnowledge MCPでした。MCPはModel Context Protocolの略で、ここではChatGPTから外部のツールやデータへアクセスするための接続口として使っています。
最初の構成は、かなり単純です。
ChatGPT
↓
Knowledge MCP
↓
Markdown Vault
├─ 現在の文書
├─ History
└─ Archive最初は「外部記憶」だった
7月29日の開発記録では、すでにVPS上にMarkdown知識基盤があり、Knowledge MCPが動き、Secure MCP Tunnel経由でChatGPTから接続できる状態になっていました。
最初の役割はかなり素朴です。
- 過去の文書を探す
- 内容を読む
- 新しい記録を残す
- 後のChatからもう一度取り出す
これだけでも、ChatGPTの使い方はかなり変わりました。
「前に話したあの案件」で終わらず、必要な記録を探してから話を再開できる。会話が切れても、重要な判断まで一緒に消えるわけではありません。
ただし、使い始めるとすぐに別の問題が出ました。
読めるだけでは足りない。でも、自由に書き換えられるのも怖い。
古い内容で上書きしたくない
たとえばChatGPTがある文書を読み、その内容をもとに修正版を作ったとします。
その間に別の作業で同じ文書が更新されていたら、古い内容を基準にした修正版で上書きしてしまうかもしれません。
人間同士で共有ファイルを編集するときにも起こる問題ですが、AIに操作させるなら、ここを「気をつけて」で済ませたくありませんでした。
そこでKnowledge MCP v2では、文書を更新するときにSHA-256のハッシュ値を使うようにしました。
先に読んだ文書のハッシュ値と、書き換える直前の文書のハッシュ値が同じ時だけ更新する。途中で内容が変わっていれば、更新を拒否します。
さらに、更新前の文書はHistoryへ保存する。削除も本当に消すのではなくArchiveへ移す。移動も既存文書を上書きしない。
2026年7月30日の本番検証では、Markdown文書の検索・読取、新規作成、SHA-256不一致時の更新拒否、正しいSHA-256での更新、更新前History保存、文書移動、Archiveへのソフト削除、テンプレートからの文書作成まで実際に確認しています。
いま振り返ると、ここで作っていたのは単なる「AI用メモ帳」ではありませんでした。
間違えても戻せる記憶を作ろうとしていたのだと思います。
保存できるようになると、今度は散らかる
そして当然のように次の問題が起きました。
記録を簡単に残せるようになると、記録が増えます。
最初は「とりあえず保存できればいい」と思っていても、仕事の話、個人活動、投資、生活、AI基盤の話が同じ場所へ積み上がると、今度は何が正式な情報なのか分かりにくくなってきます。
そこで8月1日にVault全体を整理し直しました。
大きくは、Company、Ventures、Finance、Personal、Platformの5領域へ分け、その中でInbox、Projects、Areas、Knowledge、Outputs、Daily、Archive、AI Workspaceというライフサイクルを持たせました。
ここで重要だったのは、フォルダ名そのものよりも、全部のMarkdownを同じ種類の「記録」として扱わないことでした。
思いつきを一時的に置いたものと、今後も参照する正式な知識は違います。作業中の下書きと、公開済みの記事も違います。古くなった情報と、現在の正本も分けたい。
記憶を増やすほど、「何を覚えるか」だけでなく「どの状態の情報を信用するか」が重要になりました。
Knowledge MCPに何でもやらせなかった
Knowledge MCPを使っているうちに、もう一つ重要な境界も見えてきました。
ChatGPTからVaultを触れるなら、そのままコードを直したり、Dockerを再起動したり、Gitを操作したりできれば便利そうです。
実際、その欲求はすぐに出てきました。
でも、それをKnowledge MCPへ追加するのはやめました。
Markdown文書を整理するために必要な権限と、サーバー上のコードを書き換えてサービスを再起動するために必要な権限は、明らかに強さが違います。
一つの万能MCPへ全部を入れれば便利かもしれません。しかし、何か一つ問題が起きたときの影響範囲も一気に広がります。
そこでKnowledge MCPは「知識を扱う道具」に残し、開発操作は別のMCPへ分けることにしました。
この判断から作ることになったのが、次のDevelopment MCPです。
振り返ると、最初に作ったのは記憶ではなく「継続性」だった
当時は、単純に「ChatGPTに長期記憶が欲しい」と考えていました。
でも現在のシステムまで作ってから振り返ると、欲しかったのは記憶そのものより、別のChat、別の日、別のモデルになっても仕事を続けられることだったのだと思います。
会話が終わっても、何を考え、何を決め、なぜそうしたのかが残る。
AIが変わっても、その続きを読める。
間違って書き換えてもHistoryから戻せる。
情報が増えても、どれが正本なのかを区別できる。
Knowledge MCPは、その後作ることになるPersonal AI Platformの中では比較的地味な部品です。記事を公開するわけでも、コードを自動で開発するわけでもありません。
それでも、最初にこれがあったから、その後の開発で起きた失敗や判断を次のChatへ持ち越せるようになりました。
この連載自体も、その時から残してきた記録を掘り返して書いています。
そう考えると、自分専用AI基盤の最初の一歩としては、かなり正しかったのかもしれません。
次回：ChatGPTにコードを書かせるだけでは足りなかった
Knowledge MCPで記録は残せるようになりました。
次に気になったのは、ChatGPTがコードを書いても、結局そのコードをサーバーへ運び、テストし、再起動するのは自分だということでした。
そこで、Knowledge MCPには強い開発権限を追加せず、開発専用のDevelopment MCPを別に作ることになります。
次回は、ChatGPTを「コードを書いてくれる相手」から「実際に開発作業を進められる相手」に変えていった話を書きます。
連載ナビ
- 第1回：ChatGPTに長期記憶が欲しくて、Knowledge MCPを作った ← 今回
- 第2回：ChatGPTにコードを書かせるだけでは足りなかった。Development MCPを作った
- 第3回：AIに自分自身を再起動させたら止まった。Development Runnerを分離した
- 第4回：ChatGPTからPRを作り、安全にマージできるようにした
- 第5回：記事を書くだけでは自動化にならなかった。Publishing MCPを作った
- 第6回：MCPをいくつ作っても、AIは自律化しなかった。そこでLoop Engineを作った
- 連載一覧
コメント