この記事をシェア
「昨日あれだけ細かく説明したのに、今日はまた最初から説明し直し」──AIエージェントを業務に導入した方なら、一度はこの徒労感を味わったことがあるのではないでしょうか。Claude Codeやその他のコーディングエージェント、社内チャットボット。どれも驚くほど賢いのに、驚くほど物忘れが激しい。セッションが切れると昨日の会話を忘れ、長い作業ではコンテキストが溢れて直前の指示すら抜け落ちる。
実はこれ、AIが「馬鹿」なのではなく、記憶のアーキテクチャがそもそも人間と違うことが原因です。そして良いニュースは、記憶は「設計」で補えるということ。本記事では、人間の記憶モデル（短期記憶／長期記憶）にたとえながら、AIエージェントに記憶を持たせる実践的な設計パターンを、私自身の運用経験も交えて解説します。
1. なぜAIエージェントは忘れるのか
コンテキストウィンドウ＝「作業机の広さ」
LLM（大規模言語モデル）が一度に「見る」ことのできる情報量には上限があります。これがコンテキストウィンドウです。Claudeなら20万トークン、モデルによっては100万トークンといった数字が謳われますが、本質は同じで、有限の作業机だと考えてください。
机の上に載っている書類（会話履歴、読み込んだファイル、ツールの実行結果）は、AIはすべて「見えて」います。しかし机が書類でいっぱいになったらどうなるか。古い書類から机の外へ押し出されるのです。長時間の作業でAIエージェントが「さっき言ったことを忘れる」のは、まさにこの状態。序盤の指示が机から落ちてしまい、物理的に参照できなくなっています。
セッション終了＝記憶の完全リセット
もうひとつの構造的な制約が、セッションをまたぐ記憶がデフォルトでは存在しないことです。人間なら一晩寝ても昨日の打ち合わせ内容を覚えていますが、LLMのセッションは終了した瞬間に机の上が完全に片付けられます。翌朝の新しいセッションは、まっさらな机で始まる「初対面」です。
「毎回同じ説明をさせられる」問題の正体はこれです。プロジェクトの背景、コーディング規約、避けてほしい操作──こうした情報は、誰かが毎セッション机の上に置き直さない限り、AIには存在しないのと同じなのです。
「賢さ」と「記憶力」は別物
ここで押さえておきたいのは、推論能力（賢さ）と記憶容量（記憶力）はまったく別のパラメータだということです。モデルが賢くなっても、コンテキストウィンドウの外にある情報は推論の材料になりません。天才コンサルタントでも、資料を渡されなければ的外れな提案しかできないのと同じです。
💡 ポイント：AIエージェントの導入で成果が出ないとき、疑うべきは「モデルの賢さ」より先に「記憶の設計」。モデルを乗り換える前に、必要な情報が机の上に載っているかを確認しましょう。
2. 記憶の3層モデル：作業机・引き出し・倉庫
人間の記憶が短期記憶と長期記憶に分かれているように、AIエージェントの記憶も層で捉えると設計しやすくなります。私は「作業机・引き出し・倉庫」の3層モデルで説明しています。
CLAUDE.md、メモリファイル、ベクトルDB。セッションが終わっても消えない。次のセッションの冒頭で机の上に置き直せる。短期記憶：コンテキストウィンドウ内の会話履歴
セッション中の会話履歴やファイル内容は、追加の仕掛けなしでAIが参照できる唯一の記憶です。強力ですが、前述のとおり容量有限・セッション限り。この層に頼りきる運用が「物忘れ」の温床になります。
中期記憶：要約（コンパクション）による圧縮保持
Claude Codeをはじめ多くのエージェントは、コンテキストが溢れそうになると会話を要約して圧縮する（コンパクション）仕組みを持っています。机の書類を「議事メモ1枚」にまとめて引き出しにしまうイメージです。作業の流れは引き継がれますが、要約の過程で細部は必ず失われます。「コンパクション後に挙動が変わった」と感じたことがあるなら、それは細部が落ちた証拠。重要な決定事項は中期記憶に任せず、後述の長期記憶へ明示的に書き出すのが安全です。
長期記憶：ファイル・DBへの永続化
セッションをまたいで残したい情報は、コンテキストの外側にある永続ストレージに書き出すしかありません。代表的な器は3つあります。プロジェクト直下の指示ファイル（CLAUDE.mdなど）、メモリ専用ディレクトリのMarkdownファイル群、そしてベクトルDBです。次章でそれぞれの使いどころを見ていきます。
3. 実践パターン集：3つの長期記憶の作り方
パターンA：プロジェクト直下の指示ファイル（CLAUDE.md / AGENTS.md）
最も手軽で、最も費用対効果が高いのがこのパターンです。Claude CodeならCLAUDE.md、OpenAI Codexや各種エージェントで広がるAGENTS.mdのように、セッション開始時に必ず読み込まれるMarkdownファイルをリポジトリ直下に置きます。
# CLAUDE.md の例
## プロジェクト概要
不動産管理SaaS。バックエンドはGo、フロントはNext.js。
## 必ず守ること
- テストは `make test` で実行（`go test` 直叩き禁止）
- DBマイグレーションは自動生成せず、必ず人間がレビュー
- 日本語でコミュニケーションする
## よくあるハマりどころ
- ローカル環境のS3はMinIOを使用（本物のAWSではない）
毎セッション「机の上に自動で置かれる書類」なので、毎回説明していたことをここに書けば、その瞬間から二度と説明不要になります。ただし全文が常にコンテキストを占有するため、書きすぎると肝心の作業スペースを圧迫します。「全セッションで必要な普遍的ルール」だけに絞るのがコツです。
パターンB：1ファクト1ファイルのメモリディレクトリ方式
「普遍的ルール」ではないが残したい記憶──ユーザーの好み、過去の意思決定、作業中プロジェクトの状況──は、メモリ専用ディレクトリに1ファクト＝1ファイルで蓄積する方式が向いています。各ファイルの冒頭に、検索用のメタデータ（フロントマター）を付けるのがポイントです。
---
name: deploy-approval-rule
description: 本番デプロイは必ず野口の承認を得てから実行する
type: feedback
updated: 2026-07-01
---
本番環境へのデプロイは、コマンドが用意されていても
即実行せず、必ず承認を得てから行う。
2026-06-12の誤デプロイ事故を受けて制定。
この方式の利点は、索引（各ファイルのdescription一覧）だけを机に載せ、本文は必要になったときだけ取り出せること。倉庫の在庫リストだけ手元に置くイメージで、コンテキスト消費を最小限に抑えつつ記憶量は事実上無制限に増やせます。また1ファクト1ファイルなので、古くなった記憶の削除や更新もファイル単位で安全にできます。
パターンC：ベクトルDB検索によるRAG型記憶
記憶が数千件を超える規模になったら、ベクトルDBに埋め込みを格納し、意味的に近い記憶を検索して取り出すRAG（Retrieval-Augmented Generation）型の出番です。過去の全会話ログ、社内ドキュメント全文、顧客対応履歴といった「人間がファイル名で整理しきれない量」の記憶を、質問の意味に応じて自動で引き当てられます。
仕組みの詳細は過去記事「ベクトルデータベースとRAG：AIが記憶を持つ仕組み」で解説していますが、導入・運用コストは3パターン中もっとも高くつきます。埋め込みモデルの選定、チャンク分割の設計、検索精度のチューニング──それぞれに落とし穴があるため、ファイルベースで限界を感じてから移行しても遅くありません。
3パターンの使い分け早見表
| パターン | A：指示ファイル | B：メモリディレクトリ | C：ベクトルDB（RAG） |
|---|---|---|---|
| 向く記憶 | 全セッション共通のルール・規約 | 個別の事実・決定・好み | 大量の文書・会話ログ |
| 記憶容量 | 小（常時コンテキスト占有） | 中〜大（索引のみ常駐） | ほぼ無制限 |
| 導入コスト | 極小（ファイル1枚） | 小（ディレクトリ＋運用ルール） | 大（DB・埋め込み・チューニング） |
| 検索方法 | 不要（常に全文が見える） | 索引から名前・説明で選ぶ | 意味ベクトルの類似検索 |
| メンテナンス | 人間がレビューしやすい | ファイル単位で棚卸し可能 | 中身がブラックボックス化しがち |
| 始めどき | 今すぐ・全員 | 指示ファイルが肥大化したら | 記憶が数千件を超えたら |
重要なのは、これらが排他的な選択肢ではなく積み重ねる階層だということです。A（指示ファイル）を土台に、必要に応じてB（メモリディレクトリ）を足し、規模が要求したときだけC（ベクトルDB）へ進む。この順番なら投資が無駄になりません。
4. 自社事例：Claude Codeのmemoryディレクトリ運用で起きたこと
私自身、このサイトの運用や受託開発でClaude Codeを日常的に使っており、パターンA＋Bの併用を続けています。プロジェクト直下のCLAUDE.mdには「日本語で会話する」「技術スタックはHTML＋CSS＋JSのみ」といった普遍ルールを置き、セッションをまたいで覚えておいてほしいこと──「ブログのアイキャッチには大きなキャプション文字を入れる」「本番デプロイ前に必ず確認を取る」といった作業のたびに口頭で伝えていた好みや失敗からの教訓は、メモリディレクトリに1件ずつ蓄積させています。
効果は明確で、セッション冒頭の「説明タイム」がほぼ消滅しました。以前は新しいセッションのたびに5分ほど前提を説明し直していましたが、今は「ブログ記事を書いて」の一言で、過去に指摘した細かい流儀まで反映された成果物が出てきます。体感では、繰り返し作業の指示コストが7〜8割減った印象です。
一方で運用して分かった注意点もあります。ひとつは、記憶は書いた時点の事実で凍結されること。サイト構成を変更した後、古い構成を前提にしたメモリが残っていて、AIが存在しないファイルを参照しようとしたことがありました。もうひとつは、何でも保存させると索引が濁ること。この2つはそのまま、次章のアンチパターンにつながります。
5. 記憶設計のアンチパターン
アンチパターン①：ゴミ屋敷メモリ
「とりあえず全部保存しておけば安心」は、記憶設計における最悪の選択です。使わない家具で埋まった倉庫から目的の工具を探すように、ノイズだらけの記憶は検索精度そのものを劣化させます。会話のたびに些末なやり取りまで保存させると、索引は膨れ上がり、本当に重要な記憶が埋もれ、AIは古い雑多な情報に引きずられた回答をするようになります。
🚫 保存すべきでないもの
- コードやドキュメントを読めば分かること（リポジトリが既に記憶している）
- その会話限りでしか意味を持たない文脈
- 「〜かもしれない」レベルの未確定情報
判断基準はシンプルで、「次のセッションの自分（またはAI)が、これを知らないと同じ失敗をするか？」。Yesなら保存、Noなら捨てる。記憶は多いほど良いのではなく、少なく鋭いほど効きます。
アンチパターン②：賞味期限切れ問題
記憶は保存した瞬間から古び始めます。「来週リリース予定」と書かれたメモは、3ヶ月後に読んだAIを確実に混乱させます。担当者の異動、仕様変更、廃止されたAPI──現実が変わっても記憶は自動では更新されないため、期限切れの記憶が現役の顔をして悪さをするのです。
対策は2つ。まず、日付は必ず絶対表記にすること。「昨日」「来週」ではなく「2026-07-08」と書く。相対表記は書いた瞬間から嘘になっていきますが、絶対表記なら少なくとも「いつ時点の情報か」をAIが判断できます。もうひとつは、定期的な棚卸し。月に一度でもメモリディレクトリを見直し、古くなったファイルを更新または削除する習慣をつけるだけで、記憶の品質は大きく変わります。1ファクト1ファイル方式なら、この棚卸しが「ファイルを消すだけ」で済むのも利点です。
6. まとめ：まずはMarkdownファイル1枚から
本記事の要点を振り返ります。
- AIエージェントが忘れるのは構造的な制約。コンテキストウィンドウ＝有限の作業机、セッション終了＝机の完全リセット
- 記憶は短期（机）・中期（引き出し）・長期（倉庫）の3層で設計する
- 長期記憶の器は指示ファイル → メモリディレクトリ → ベクトルDBの順に、必要になってから積み増す
- ゴミ屋敷メモリと賞味期限切れに注意。少なく鋭く保存し、日付は絶対表記、定期的に棚卸しする
高価なベクトルDBも、複雑なメモリ管理フレームワークも、最初は要りません。今日、リポジトリ直下にCLAUDE.md（またはお使いのエージェントの指示ファイル）を1枚作り、毎回説明していることを3つ書く。それだけで明日からのAIエージェントは見違えます。記憶設計は、小さく始めて、エージェントと一緒に育てていくものです。
AIエージェントとの協働の進め方全般については「【2025年】AIエージェントとの効果的なつきあい方」も併せてご覧ください。
この記事が役に立ったらシェアしてください
AIエージェントの「物忘れ」に悩む同僚・チームメイトにも、ぜひこの記憶設計パターンを共有してください。
