ChatGPTやClaudeと長期間にわたるプロジェクトを進めた経験はあるでしょうか。
新しいセッションを開始するたびに、AIは前回の会話内容を忘れています。
「先月決めた設計方針を覚えてる？」と聞いても、答えは返ってきません。
結果として、毎回同じ文脈を貼り付ける作業が発生します。
この問題に対して、あるRedditユーザーが興味深いアプローチを公開していました。
本記事では、その投稿とコミュニティの議論をもとに、LLMに永続的な記憶を持たせる手法について考察します。
コンテキストの断片化がもたらす問題
LLMを使った開発で、最大のペインポイントは「コンテキストの断片化」です。
あるRedditの投稿者は、この問題を「認知症ループ」と表現していました。
コンテキストウィンドウが埋まると、推論能力が急激に落ちる。
会話の中にノイズが多すぎて、AIが本当に重要な情報を拾えなくなるのです。
「じゃあ過去の会話をまるごとコピペすればいい」と思うかもしれません。
しかし、この方法もうまくいかないケースが多い。
会話履歴には雑談や試行錯誤が大量に含まれており、本当に必要なシグナルが埋もれてしまいます。
投稿者によれば、Word文書に会話全体を貼り付けてAIに読ませたそうです。
しかし、トークンの大半が「ノイズ」に消費され、肝心な情報の抽出に失敗したとのこと。
「チャット」ではなく「ファイル」を記憶にする
この問題に対して、投稿者が提案したのは「ファイルをメモリとして扱う」というアプローチでした。
考え方はシンプルです。
チャット履歴に頼るのではなく、Markdownファイルに「現在の状態」と「次のステップ」を記録させる。
セッション終了時にAIがファイルを更新し、次のセッション開始時にそのファイルを読み込む。
こうすれば、2万トークン分の会話履歴を流し込む必要がありません。
圧縮された要約ファイル1つで、コンテキストを復元できるわけです。
具体的な流れは、以下のようになります。
セッション開始時に、ブートスクリプトが現在のコンテキストファイルを読み込む。
ファイルには、進行中の作業内容や直近の意思決定、ユーザーの好みなどが記録されている。
セッション終了時には、AIがそのセッションで何が起きたかを要約する。
そして、ファイルに書き戻す。
古い情報は上書きされるため、常に最新の状態が保たれる仕組みです。
このアプローチのポイントは、AIのチャット機能を記憶の保存場所にしない点にあります。
記憶はファイルシステム上に存在する。
だから、人間が直接読み書きでき、Gitでバージョン管理もできます。
ネイティブメモリ機能との違い
「ChatGPTにもメモリ機能があるじゃないか」という声は当然あるでしょう。
たしかに、ChatGPTやClaude、Geminiはいずれも何らかのメモリ機能を備えています。
コメント欄でも、この点について活発な議論がありました。
しかし、投稿者はネイティブメモリを「付箋」にたとえています。
「ユーザーはPythonが好き」のような平坦な事実が数十個保存されるだけ。
プロジェクトの進化や状態の変遷は追跡してくれません。
一方、ファイルベースの記憶層は「検索エンジン付きのファイリングキャビネット」として機能する。
これが投稿者の主張でした。
具体的には、以下のような違いがあると説明されています。
まず、構造の違い。
ネイティブメモリはフラットな事実の羅列です。
一方、ファイルベースの手法では、ハードルール（プロトコル）、履歴（セッションログ）、進行中のタスク、重要な意思決定を別々のファイルとして管理する構成です。
次に、透明性。
ネイティブメモリでAIが間違った情報を「覚えて」しまった場合、修正が困難です。
しかしファイルベースなら、テキストエディタでファイルを開いて該当行を削除するだけで済む。
投稿者は、ユーザーが自分の「脳」に対して書き込み権限を持っていると表現していました。
さらに、鮮度管理。
ネイティブメモリにはガベージコレクションがありません。
そのため、1,000セッションを重ねると矛盾するデータが蓄積されていく。
ファイルベースの手法では、セッション更新プロトコルが古いデータを明示的に上書きし、コンテキストの鮮度を保ちます。
ただし、コメント欄では反論も見られました。
ネイティブメモリの進化は著しく、過去の会話を引用付きで参照する機能も登場している。
カジュアルな用途なら、ネイティブメモリで十分という意見にも一理あるでしょう。
検索の仕組み：ハイブリッドRAG
投稿者のプロジェクトでは、過去のセッション情報を意味レベルで検索する仕組みも組み込まれていました。
採用されていたのは、ハイブリッドRAGパイプラインです。
ベクトル検索とBM25（キーワードベースの検索）を組み合わせ、さらにクロスエンコーダーによるリランキングを加えた構成でした。
コメント欄のあるユーザーは、この組み合わせを高く評価していました。
ベクトル検索だけでは完全一致を見逃す。
キーワード検索だけでは意味的な類似性を見逃す。
両者を組み合わせることで、検索精度が大幅に向上するとの指摘です。
プラットフォーム非依存という強み
もう1つ注目すべきは、プラットフォーム非依存であるという設計思想でしょう。
記憶がMarkdownファイルとして手元に存在するため、特定のLLMプラットフォームに縛られません。
ChatGPTがダウンしたらClaudeへ。
Claudeが合わなければGeminiへ。
記憶ごと移行できます。
コメント欄でも「データ主権は多くの人が思っている以上に重要だ」という声がありました。
プラットフォームの価格改定やサービス停止に左右されず、自分のデータを自分で管理できる。
長期プロジェクトにおいて、これは大きな安心材料となるでしょう。
「消費者」と「構築者」の視点の違い
投稿のコメント欄で印象的だったのは、ネイティブメモリの評価が「使い方」によって大きく分かれる点です。
日常的な会話やちょっとした質問に使うだけなら、ネイティブメモリは十分に機能します。
しかし、数千行のコードベースを数百時間かけて開発するような場面では、事情が異なる。
チャット機能の付随メモリだけでは心許なく、ファイルシステムレベルの記憶管理が必要になってきます。
あるコメント投稿者は、この考えをさらに発展させていました。
「AIをカジュアルに使う段階を超えると、それはもう『おしゃべり』ではなく『システムアーキテクチャ』になる」と。
つまり、モデルを記憶のコンテナではなく推論エンジンとして扱う。
そして、記憶は外部のアーティファクト（ファイル）に持たせる。
この発想は、複雑なプロジェクトを長期間運用する上で合理的と言えるでしょう。
別のアプローチ：ガバナンスレイヤーの追加
コメント欄では、別のプロジェクトも紹介されていました。
記憶層に加えて「ガバナンスレイヤー」を設けるという手法です。
具体的には、AIの行動規範をファイルとして定義する。
管理する要素は、以下のようなものです。
- 権限の境界線
- 実行の安全ルール
- スコープの制御
- 意思決定のログ要件
- AI協力者への行動規範
この考え方では、記憶の永続化と検索に加えて、AIが「どう振る舞うべきか」も明文化された規則で制御する。
長期的な行動の一貫性と信頼性を担保するためのアプローチと言えるでしょう。
実践に向けた考慮点
この手法を導入する前に、いくつか考慮すべき点があります。
まず、このアプローチはIDE（統合開発環境）上での利用が前提です。
モバイルアプリやWebブラウザのChatGPTインターフェースだけでは実現が難しい。
コメント欄でも「スマートフォンで使えるか」という質問が多数寄せられていましたが、現時点ではデスクトップ環境が必須のようでした。
また、セッション終了時にファイルを更新する作業には規律が求められます。
投稿者自身も「規律は必要だが、効果はある」と認めていました。
自動化できる部分はあるものの、完全に放置できる仕組みではありません。
さらに、コンテキストウィンドウが長くなるほどハルシネーションのリスクが増すという指摘もありました。
記憶ファイルに読み込ませる情報量は、慎重にコントロールする必要があるでしょう。
まとめ
LLMに永続的な記憶を持たせる試みは、AI活用の新たなフロンティアとなりつつあります。
本記事で紹介したアプローチの核心は、「チャットを記憶の場所にしない」という発想です。
Markdownファイルとして記憶を外部化する。
人間が読み書きでき、バージョン管理もでき、プラットフォーム間で持ち運べる形にする。
カジュアルな会話であれば、ネイティブメモリで問題ありません。
しかし、複雑なプロジェクトを長期間にわたって進める場合には、ファイルベースの構造化された記憶層が大きな威力を発揮するはずです。
AIの活用が「おしゃべり」から「システム構築」へと進化する。
それに合わせて、記憶の管理も進化させる必要がある。
今回紹介した議論は、その方向性を示す良い事例と言えるのではないでしょうか。
