第1回：Development MCP――AIに「開発そのもの」を任せるために作った仕組みでは、AIにコードを書かせるだけでは実際の開発は回らず、workspace、テスト、Pull Request、merge、本番環境といった現実側の状態を管理するためにDevelopment MCPを作った話を書きました。
Development MCPによって、AIがかなり安全に開発を進められるようになると、次の問題が出てきました。
そもそもAIは、「いま何を作っているのか」をどこまで正確に知っているのか。
一つのChatの中だけなら、それほど問題にはなりません。
しかし、数日、数週間と開発を続け、仕様書が増え、設計変更が入り、別のChatから作業を再開するようになると、会話履歴だけでは厳しくなってきます。
「前回こう決めたはず」
「たしかこの機能は完成していた」
「この仕様書が最新だったと思う」
人間でも危ない判断ですが、AIに開発を続けさせる場合はさらに問題になります。
そこで作ったのが、今回紹介するKnowledge MCPです。
私が欲しかったのは、単にAIが過去を覚えている仕組みではありませんでした。
必要なときに、プロジェクトの現在の正しい状態を外部から取り直せる仕組みでした。
- ChatGPTのMemoryだけでは駄目なのか
- Context、Memory、RAG、Knowledgeは同じではない
- 欲しかったのは「記憶」ではなくcanonicalな状態だった
- Knowledge MCPはMarkdownのVaultから始まった
- Handoffを作ると、Chatをまたいで仕事を続けられる
- Handoffも古くなる
- SHAを使う理由
- 文書が増えれば増えるほど、Knowledgeは難しくなる
- AIにKnowledgeを自由に書き換えさせない
- Implementation snapshot ― 2026年9月2日
- CLI常駐型になってもKnowledge MCPは残る
- Knowledge MCPを作って分かったこと
- 「MCPでつくる自作AIサーバー」シリーズ
ChatGPTのMemoryだけでは駄目なのか
最初にここを整理しておいた方がよいと思います。
ChatGPTにはMemoryがあります。
現在のMemoryは、過去の会話などから有用な文脈を継続的に利用し、ユーザーが毎回同じ説明をしなくても済むようにする仕組みへかなり進化しています。
私はこの機能を普通に使っていますし、Personal AI PlatformでもMemoryをなくそうとは考えていません。
問題は、Memoryとプロジェクトの仕様書では役割が違うことです。
例えば、
「私はPersonal AI Platformを開発している」
「安全性を落としてまで開発速度を上げたくない」
「Knowledgeを開発前に確認する」
といった情報は、継続的な文脈として非常に役立ちます。
一方で、
「現在採用されているCLI Orchestratorの統合仕様はどの文書か」
「その仕様書のSHA-256はいくつか」
「昨日のPRでその仕様は変更されたのか」
「productionで本当にそのバージョンが動いているのか」
という話になると、私はMemoryに任せたくありません。
これは「だいたい覚えていてほしい情報」ではなく、間違えると次の開発そのものを誤る情報だからです。
Context、Memory、RAG、Knowledgeは同じではない
AIの長期記憶について考え始めると、Context、Memory、RAG、Knowledge Baseという言葉が混ざりやすくなります。
私のPersonal AI Platformでは、現在は次のように分けて考えています。
| 仕組み | 主な役割 |
|---|---|
| Context | 今この会話で何を話しているか |
| Memory | ユーザーや継続的な活動についての文脈 |
| RAG | 大量の外部情報から関連する情報を検索してLLMへ渡す |
| Knowledge MCP | プロジェクトの仕様、判断、履歴、証拠を外部から再取得・管理する |
もちろん境界は完全に独立しているわけではありません。
Knowledge MCPも検索を使いますし、検索結果をLLMへ渡すという意味ではRAG的な動作をします。
ただし、私がKnowledge MCPで特に重要だと思っているのは検索技術ではありません。
「どの文書を現在の基準として扱うか」まで管理することです。
欲しかったのは「記憶」ではなくcanonicalな状態だった
開発を続けていると、仕様書は一枚では済みません。
最初の設計書があります。
途中の検証結果があります。
問題が見つかれば修正版があります。
その設計を実装した記録があります。
さらに次の開発へ引き継ぐhandoffがあります。
これらを全部AIに検索させればよいようにも思えます。
しかし、検索結果に古い仕様書が出てきたらどうでしょう。
内容は関連しています。文章ももっともらしい。しかも検索上位に出てきた。
AIがそれを現在の仕様だと思って開発を始めれば、システムを古い設計へ戻してしまう可能性があります。
そこで重要になったのが、canonicalという考え方でした。
ここでいうcanonicalは、「世界で唯一正しい文書」という意味ではありません。
このプロジェクトでは、現在これを基準として扱うと明示された文書です。
例えば現在進めているCLI Orchestratorの開発では、統合仕様書をcanonical requirementとして指定し、そのSHA-256まで固定します。
AIが続きを始めるときは、仕様書の名前を覚えているから続行する、ではありません。
対象文書をKnowledge MCPから改めて読み、SHAを確認し、そのうえで現在のGitやruntimeの状態を見る。
仕様書が変わっていれば、以前の前提のまま進まず止める。
こうすることで、
AIが覚えている現在
ではなく、
外部状態から再構成した現在
を使えるようになります。
Knowledge MCPはMarkdownのVaultから始まった
Knowledge MCPの基盤自体は、かなり単純です。
中心にあるのはMarkdown文書です。
プロジェクトの仕様、調査、handoff、検証結果、日次記録、出力物などをサーバー上のKnowledge repositoryへ保存し、Knowledge MCPから検索・一覧・読み込み・更新できるようにしています。
現在は大まかに、Projectとして進行中のもの、再利用可能なKnowledge、完成したOutputs、Dailyな記録、古くなったArchive、AIが一時的に扱うWorkspace、というように役割を分けています。
ここでも重要だったのは、LLM専用の特殊なデータ形式を中心にしなかったことです。
基本は人間も読めるMarkdownです。
AIシステムを全部捨てても、仕様書そのものは残ります。
別のLLMへ変更しても読めます。
必要ならGitや通常のテキスト処理でも扱えます。
Knowledgeの寿命を、特定のLLMや特定のAIサービスの寿命に合わせたくなかったからです。
Handoffを作ると、Chatをまたいで仕事を続けられる
Knowledge MCPを作って、実用上かなり大きかったものの一つがhandoffです。
長い開発をしていると、一つのChatを永遠に使い続けることはできません。
以前は新しいChatへ移るとき、人間が状況を説明し直していました。
「ここまで終わっている」
「このPRはマージ済み」
「次はこれをやる」
「この仕様は変えないで」
という説明です。
しかし、開発が大きくなると、それ自体が危険になります。
一つ書き忘れれば、次のAIはその情報を知りません。
そこで、作業の節目でhandoff文書を作るようになりました。
handoffには、現在のmission、canonical specification、SHA、完了した作業、残った課題、安全上の制約、次に確認すべきlive stateなどを記録します。
新しいChatでは、それを読んでから始めます。
ただし、ここにも落とし穴がありました。
Handoffも古くなる
handoffを書けば問題が全部解決するわけではありません。
handoffを書いた30分後に、別の開発がmainへマージされるかもしれません。
productionが更新されるかもしれません。
別のworkspaceが同じコンポーネントを触り始めているかもしれません。
つまり、handoffは非常に有用ですが、handoff自体もsnapshotです。
このため現在は、
Knowledgeから過去の状態を読む → 現在のlive stateを再確認する
という二段階で考えています。
これは第1回のDevelopment MCPともつながります。
Knowledge MCPが「こうなっているはず」を教え、Development MCPなどの実システムが「いま実際にどうなっているか」を教える。
片方だけでは足りません。
SHAを使う理由
Knowledge MCPでは、多くの文書をSHA-256と一緒に扱っています。
少し大げさに見えるかもしれません。
しかし、AIに長期開発をさせる場合、「同じファイル名」というだけでは弱いのです。
仕様書Aを読んだ。その後、人間か別のAIが仕様書Aを修正した。数時間後、最初のAIが「仕様書Aに基づいて続行します」と作業を再開する。
ファイル名だけ見れば何も変わっていません。
しかし、中身は違います。
そこで、重要な仕様については、
私はこの内容を読んだ
という状態をSHAまで含めて固定します。
内容が変わったら、同じ名前でも別の状態として扱えます。
これはAIに「記憶力」を与える仕組みではありません。
むしろ逆で、AIの記憶を信用しすぎないための仕組みです。
文書が増えれば増えるほど、Knowledgeは難しくなる
Knowledge MCPを作り始めた頃は、「全部残して検索できれば便利になる」と考えていました。
これは半分正しく、半分間違っていました。
文書が増えると、確かに過去を失わなくなります。
一方で、検索結果には似た文書が大量に出てきます。
古い設計。途中の案。失敗した実装。その後置き換えられた仕様。新しい仕様。
それらが全部Knowledgeです。
ここで初めて、
保存することと、知識として使えることは違う
と分かりました。
情報量が増えるほど賢くなるわけではありません。
古い文書を消さずに歴史として残しつつ、現在の判断ではどれを優先するのか。duplicateなのか。staleなのか。supersededなのか。historicalとして残すべきなのか。
その分類が必要になります。
最近のKnowledge MCPでは、単なるMarkdown検索だけでなく、source identity、claim、confidence、last reviewed、knowledge status、gap analysisといった情報を扱う方向へ拡張しています。
つまり、「ファイル置き場」から少しずつKnowledgeを管理する層へ変わってきました。
AIにKnowledgeを自由に書き換えさせない
もう一つ、実運用でかなり重要になったのがwrite側です。
AIがKnowledgeを読めるなら、学んだことを自動でKnowledgeへ書き戻せば便利です。
実際、その方向へ進めています。
しかし、ここでも単純に、
「AIが学んだら自動で仕様書を書き換える」
とはしていません。
AIが一度誤った解釈をし、その内容でcanonical documentを書き換えたらどうなるでしょう。
次のAIは、その誤った文書を「正しいKnowledge」として読みます。
すると間違いが自己増幅します。
そのため現在は、重要なKnowledge更新について、sourceを示す、変更するclaimを明示する、addなのかreviseなのかsupersedeなのかを区別する、提案として作る、必要なreviewを通す、という境界を徐々に作っています。
Knowledgeへの書き込みは、単なるファイルwriteではない。
これは実際にKnowledgeを長期間使うようになって強く感じたことです。
Implementation snapshot ― 2026年9月2日
この記事を作成している2026年9月2日時点で、私のKnowledge Platformはv2.20.0で稼働しており、Knowledge repositoryには2,164件のMarkdown文書があります。
現在は単純な検索・読み込みだけでなく、文書の作成・更新・移動・archive、change proposal、Knowledge gap analysis、evidenceを伴うKnowledge update proposalなどを扱えるようになっています。
一方で、2,000文書を超えたから完成したわけではありません。
むしろ、この規模になったことで、どこまで自動分類するのか、canonicalとhistoricalをどう分けるのか、似たKnowledgeをどう統合するのか、古くなった情報をどう検出するのか、AIが書き込める範囲をどこまで広げるのか、といった次の問題が見えるようになっています。
Knowledge Baseは、作れば終わるデータベースではなく、手入れを続ける必要があるシステムなのだと思います。
CLI常駐型になってもKnowledge MCPは残る
現在、Personal AI Platformでは、Browser版ChatGPTを中心にした構成から、サーバー上にCodexを常駐させるCLI/App Server型の構成へ移行を進めています。
ここで最初に検討したことの一つが、「CLI側に新しいMemoryを作るべきか」という問題でした。
結論としては、作らない方針にしています。
新しいCLI側に第二のKnowledge DBや第二のvector indexを作れば、一見きれいな新システムになります。
しかし、その瞬間に、Browser ChatGPTが見ているKnowledgeと、CLIが見ているKnowledgeの二つができます。
どちらが正しいのかを管理する仕事が増えます。
そのため次世代構成でも、Knowledge MCPはshared external cognitionとして再利用する設計です。
ReasonerがBrowser ChatGPTからCodexへ変わっても、同じKnowledgeを読む。
AIの入口が変わっても、外部知識基盤は共有する。
これはKnowledgeをLLMの内部機能として作らなかったことの利点でもあります。
Knowledge MCPを作って分かったこと
AIの長期利用では、Memoryは重要です。
RAGも重要です。
大量の文書を検索できることも重要です。
しかし、長期プロジェクトをAIと続ける中で、私が一番重要だと感じるようになったのは別の部分でした。
「いま何を正しいものとして判断しているのか」を、AIの外側に残すこと。
そして必要なときに、それを改めて取得できること。
さらに、そのKnowledge自体も古くなる前提で管理することです。
Knowledge MCPは、AIに完璧な記憶を持たせるための仕組みではありません。
むしろ、
AIが忘れても、Chatが変わっても、モデルが変わっても、仕事を再構成できるようにする仕組み
として作っています。
Development MCPによってAIは「作る」ことができるようになりました。
Knowledge MCPによって、何を作っているのかを「知り直す」ことができるようになりました。
しかし、まだ問題が残ります。
DevelopmentもKnowledgeも使えるのに、AIへの一回の指示が終われば仕事も止まる。
誰が次の状態を観測し、次の行動を決め、必要ならまた実行するのか。
そこで作ったのが、次回のLoop Engineです。
「MCPでつくる自作AIサーバー」シリーズ
- #1 Development MCP――AIに「開発そのもの」を任せるために作った仕組み
- #2 Knowledge MCP――AIに「記憶」ではなく知識基盤を持たせる（この記事）
- #3 Loop Engine――MCPをつなぐだけではAIエージェントは動き続けない（予定）
- #4 Publishing MCP――ChatGPTからWordPressとSNSまで公開する仕組み（予定）
コメント