Claudeエージェントに「記憶」を持たせる完全ガイド：組み込みメモリからDreamingまで12ステップ

本サイトは Google AdSense による広告が表示される場合があります。本記事は MindStudio による実践ガイド「How to give your Claude agent a memory in 12 steps」を一次情報として精読し、Anthropic 公式ドキュメントと照合のうえ運営者（現役 IT エンジニア・15 年以上の業界経験）が日本語で再構成したものです。仕様は 2026 年 5 月時点。最新情報は Anthropic 公式ドキュメント をご確認ください。

Tech Notes · Claude Memory · 2026.05

新しいチャットを開くたびに、Claude はすべてを忘れる。あなたの名前も、先週直した同じミスも、「箇条書きは要らない」という何度目かの訂正も。セッションをまたいで記憶が続かない——これはバグではなく、言語モデルの根本的な仕様だ。しかし 2026 年 3 月以降、一般ユーザーでも段階的に記憶を持たせられる仕組みが公式に揃い始めた。本記事では「付箋紙」から「毎週金曜に自己反省する社員」まで、4 つの記憶レイヤーを 12 のステップで構築する方法を、実際の API コードと判断基準ごとまとめる。読了 20 分。

user@sinyblog:~/article ❯ 01_tldr.md90 秒ダイジェスト：何が手に入るのか

本記事の核心を先に言う。Claude エージェントの記憶は「1 つの機能をオンにする」問題ではなく、4 つのレイヤーを積み上げる設計問題だ。それぞれのレイヤーは独立した役割を持ち、組み合わせることで初めてセッションをまたいで知識が蓄積する。

最初の 4 ステップ（Layer 1 + Layer 2）だけでも今夜セットアップできる。それだけで次のセッションの体験が変わる。Layer 3 以降はコード環境が必要だが、繰り返しワークを自動化するなら必須の投資だ。Layer 4 の Dreaming は API プレビュー段階のため、開発者向けの内容として後半に分けて扱う。

user@sinyblog:~/article ❯ 02_why-goldfish.mdなぜすべてのエージェントは「金魚」なのか

新しいチャットを開くたびに、Claude は真っ白な状態から始まる。名前を知らない。昨日直した 3 つのミスを知らない。「箇条書きではなく文章で」という要望も、「auth モジュールは自動承認しない」というルールも、すべてゼロだ。

これはバグではない。言語モデルがどう動くかの根本的な仕様だ。チャットボットとしてはそれで十分だが、繰り返し同じ仕事をこなすエージェントにとっては致命的な欠陥になる。

An agent with no memory is exactly as useful on run 100 as it was on run 1.

MindStudio — How to give your Claude agent a memory in 12 steps / [1]

記憶のないエージェントは、100 回実行しても 1 回目と同じ能力しか持たない。同じ失敗を繰り返し、同じ質問をし、前回あなたが教えた回避策を知らない。記憶がないということは、成長しないということだ。

では記憶があればどうなるか。Harvey（法律 AI 企業）はエージェントに Dreaming（後述の Layer 4）を有効化したところ、法的文書作成ワークフローのタスク完了率が約 6 倍に向上したと報告している^[1]。ファイルタイプの癖やツールの回避策をセッションをまたいで覚えられるようになった、それだけで成功率がそこまで跳ね上がった。

user@sinyblog:~/article ❯ 03_four-layers.md4 つの記憶レイヤーの全体像

記憶の仕組みを理解するうえで最も重要なのは、「記憶」と呼ばれているものが実は 4 種類の異なるメカニズムの総称だという点だ。それぞれ動作が違い、対象となるユーザーも異なる。

Layer 1：組み込みチャットメモリ（付箋紙）— 2026 年 3 月、Anthropic がすべての Claude アカウント（無料・Pro 共通）に展開したビルトイン機能^[2]。会話の中で Claude が好みやプロジェクトの文脈を自動学習し、次の会話に持ち越す。24 時間ごとに「記憶合成」が走る。

Layer 2：Projects の固定指示（職務記述書）— Projects は永続的なワークスペースで、中に書いた指示がすべての会話に自動でロードされる。エージェントの役割・制約・スタンダードを一度書けば繰り返し有効になる。

Layer 3：メモリファイル（ノート）— CLAUDE.md（Claude Code）や memory.md（Project Knowledge）のような、エージェントが読んで書き込む生きたテキストファイル。セッションをまたいで知識が蓄積される。コード環境が前提。

Layer 4：Dreaming（金曜の振り返り）— Managed Agents API のリサーチプレビュー機能^[3]。夜間または週次でバックグラウンドプロセスを走らせ、過去のセッション履歴とメモリストアを読み込み、重複を統合・陳腐化した情報を新しい知見で置き換え・新しいインサイトを抽出した新メモリストアを生成する。

user@sinyblog:~/article ❯ 04_builtin-memory.mdStep 01：Claude 組み込みメモリをオンにする

まず、多くの人が存在を知らないまま使っていない機能から始める。2026 年 3 月、Anthropic はすべての Claude アカウントに「Chat Memory」と呼ばれる永続メモリ機能を展開した^[2]。無料プランでも Pro でも同様に使える。

Claude はこの機能を通じて、好みや進行中のプロジェクト、作業スタイルをすべての会話にまたがって自動的に記憶する。有効になっていれば、あなたが「Markdown よりプレーンテキストで返して」と言った好みや、現在取り組んでいるプロジェクトの文脈が、次のセッションでも生きている。

有効化の手順は次のとおりだ。

1. プロフィールアイコンをクリック
2. 「Settings（設定）」→「Capabilities（機能）」へ移動
3. 「Memory」セクションまでスクロール
4. 「Generate memory from chat history（チャット履歴から記憶を生成）」がオンになっているか確認

裏側ではMemory Synthesis（記憶合成）と呼ばれるプロセスが約 24 時間ごとに走る。Claude が会話を蒸留し、プロフィールを更新する仕組みだ。最初の会話の翌日には記憶が反映されている計算になる。

user@sinyblog:~/article ❯ 05_seed-memory.mdStep 02：記憶は待つより能動的に植える

公式ドキュメントが明示している、直感に反するポイントがある。Claude の好みを自動推論で学ぶ記憶合成は 24 時間ごとにしか動かない。だから「使い続けていれば自然に覚えてくれる」と待っていても、翌日まで何も変わらない。

答えは簡単で、明示的に伝えることだ。 推論よりも直接入力のほうが常に速く、確実で、精度が高い。新しい会話を開いて、以下のような形で一度伝えるだけでいい。

以下を今後のすべての会話で覚えておいてください：

- 私は [職種・業界] で働いており、主なプロジェクトは [X, Y] です
- 回答は [箇条書きより文章 / 短く簡潔に / 詳細に] 返してください
- 私の文体は [説明してください]
- 絶対にやらないでほしいこと：[毎回修正している行動]

これを送信すると、Claude は即座に記憶に書き込む。24 時間待たずに次のセッションから機能する。一度のメッセージで、「同じ説明をまた求められる」という最大の摩擦が消える。

user@sinyblog:~/article ❯ 06_projects-home.mdStep 03：Projects でエージェントの「家」を作る

Layer 2 はProjectsの固定指示だ。Projects は永続的なワークスペースで、カスタム指示ボックスに書いた内容がその Project 内のすべての会話に自動でロードされる。エージェントの役割・スタンダード・制約を一度書いておけば、毎回コピペする必要がなくなる。

Project の作り方はシンプルだ。

1. Claude.ai の左サイドバーで「Projects」→「New Project」
2. 名前をつける（テーマではなく仕事の内容を反映した名前が良い。例：「コードレビューエージェント」「ブログ執筆アシスタント」）
3. カスタム指示ボックスに、エージェントの役割・スタンダード・制約を記入
4. この Project の中で会話を始める

Project に入れる指示の例として、コードレビューエージェントであれば以下のようなものになる。

あなたはシニアエンジニアとしてコードレビューを担当します。

【役割】
- セキュリティの問題を最優先でチェックする
- OWASP Top 10 の観点から常に評価する
- 問題点だけでなく、改善案のコードも示す

【スタンダード】
- Python は PEP 8 準拠。型ヒントは必須
- auth モジュールの変更は必ずセキュリティ警告を付ける

【制約】
- auth モジュールへの PR を自動承認してはいけない
- 箇条書きではなく文章で指摘する

この指示を書いたら、Project の中で新しい会話を始めるたびにこの内容が読み込まれる。毎回コピペしなくていい。エージェントは最初から自分の役割を知っている状態で動く。

user@sinyblog:~/article ❯ 07_projects-dont-remember.mdStep 04：Projects が覚えないもの（落とし穴）

ここは多くの人が引っかかるポイントなので、丁寧に整理する。Projects は指示を記憶する。会話の履歴は記憶しない。

詳しく言うと、こういう状況が起きる。Project を作ってカスタム指示を書き、いくつかの会話をこなしたとする。アーキテクチャの決定を下し、半分まで進んだタスクがあり、先週のデバッグセッションで判明した根本原因があった。そして Project の中で新しいチャットを開いた瞬間、それらはすべて消える。

この制約を知ったうえで Project を使うと、Layer 3 のメモリファイルが何のためにあるかが自然に理解できる。指示は Project に、知識はメモリファイルに——これが基本的な分業だ。

user@sinyblog:~/article ❯ 08_memory-file.mdStep 05：生きたメモリファイルを追加する

Layer 3 に入る。最もシンプルかつ実際に機能する永続記憶は、エージェントがセッション開始時に読んで、セッション末に追記する単一ファイルだ。

Claude Code では、このファイルはCLAUDE.mdという名前が標準だ^[4]。Claude.ai の Project では「Project Knowledge」に memory.md として追加できる。どちらも考え方は同じで、エージェントはこのファイルを読んで前のセッションの文脈を得る。

Claude Code で CLAUDE.md を生成する場合、/init コマンドが一発でスターターファイルを作ってくれる。ただし公式ドキュメントが強調する重要な注意点がある^[4]。

メモリファイルに書くべき内容の例を示す。

## 好み
- ステータス更新は文章よりも箇条書き
- 主張には必ず元ファイル名を明記する

## 決定済み事項
- 2026-04-18 Postgres を採用（Mongo は見送り）理由：レポート機能が関係データを要求するため

## 既知の回避策
- エクスポートツールは 50MB 超のファイルで失敗する。先に分割が必要

## 繰り返すべきでないミス
- auth モジュールに触れる PR を自動承認しない

逆に、以下はメモリファイルに書くべきでない内容の典型だ。

## プロジェクト構造
- src/ にソースコード
- tests/ にテスト
- README.md がある

## 使用技術
- Python 3.11
- Django 4.2
- PostgreSQL

後者はコードを見れば自明なことばかりだ。モデルはリポジトリを読める。わざわざメモリファイルに書く意味はない。

user@sinyblog:~/article ❯ 09_auto-memory.mdStep 06：Claude Code の自動記憶機能をオンにする

Claude Code にはメモリファイルを手動で書き続けなくても済む自動記憶機能が搭載されている。この機能をオンにすると、エージェントがあなたの修正や好みをもとに自分自身にノートを取り、次のセッション開始時にそのメモを読み込む。

有効化はセッション内で /memory コマンドを実行するか、プロジェクト設定で autoMemoryEnabled を true にする。

/memory

これで軽いセルフドキュメント化が始まる。あなたが訂正すると、その訂正が次のセッションに生き残るようになる。

user@sinyblog:~/article ❯ 10_structure-memory.mdStep 07：メモリファイルを構造化して使い続ける

メモリファイルは構造なしに育てると、すぐにノイズの塊になる。シグナルとノイズが混在したファイルは、有用な記憶がない状態と大して変わらない。初期設計の時点でセクションを決めておくことが重要だ。

推奨するセクション構成は次のとおりだ。

## 好み (Preferences)
- ステータス更新は箇条書き
- コードの主張には必ずファイル名と行番号を添える
- 説明は先に結論、後に理由

## 決定済み事項 (Decisions)
- YYYY-MM-DD：[判断内容]（理由：〇〇）
- 例 2026-04-18：Postgres 採用。Mongo は見送り（レポートが関係データを要求）

## 既知の回避策 (Known Workarounds)
- エクスポートツールは 50MB 超で失敗 → 先に分割する
- テスト環境で環境変数 X が設定されていないと落ちる

## 繰り返すべきでないミス (Recurring Mistakes to Avoid)
- auth モジュールへの PR を自動承認しない
- ユーザー入力は必ずバリデーションを通す（2 回同じミスをした）

各エントリは「掲載されている理由がある」と言えるものだけを入れる。理由が言えなければ削除候補だ。メモリファイルは長くなるほど読み込みコストが上がり、真に重要な情報が埋もれる。定期的に棚卸しをして、陳腐化したエントリを消すのも仕事のうちだ。

user@sinyblog:~/article ❯ 11_what-to-remember.mdStep 08：何を保存する価値があるかを判断する

Layer 3 の核心は記録の技術ではなく、フィルタリングの技術だ。すべてを覚えようとするメモリは、何も覚えないメモリと同じくらい役に立たない。

判断の基準はシンプルだ。

Would this change how the agent acts next time? If yes, store it. If no, let it go.

MindStudio — Step 08: Decide what is worth remembering / [1]

「次回のエージェントの行動を変えるか？」——イエスなら保存、ノーなら捨てる。この問いを毎回のセッション終了時に当てはめる。

重要なセッションが終わったタイミングで、エージェントに次のように聞いてみるのが効果的だ。

今日のセッションを振り返って、次回のセッションで役立つ可能性がある情報（決定・回避策・好み・失敗パターン）を CLAUDE.md の該当セクションに追記してください。すでに知っていることや自明なことは追記しないでください。

user@sinyblog:~/article ❯ 12_dreaming.mdStep 09：Layer 4「Dreaming」とは何か

2026 年 5 月 6 日、Anthropic は「Code with Claude」イベントでDreamingを Managed Agents のリサーチプレビューとして公開した^[3]。名前は神経科学からの借用だ。

The name is borrowed from neuroscience on purpose: when humans sleep, the brain consolidates the day's experiences into long-term memory. Dreaming does the same for an agent.

MindStudio / [1]

人間が眠っている間、脳はその日の経験を長期記憶に統合する。Dreaming はエージェントに同じことをさせる仕組みだ。スケジュールされたバックグラウンドプロセスが、既存のメモリストアと過去のセッション履歴を読み込み、新しい整理済みメモリストアを生成する。具体的には：

• 重複したエントリを統合する
• 陳腐化した情報を最新の値で置き換える
• 複数セッションにまたがる本質的なパターンを表面に出す

入力のメモリストアは読み取り専用のままで、出力はまったく新しいストアとして生成される。既存の記憶が破壊されることはない。

Harvey（法律 AI 企業）はこの Dreaming を法的文書作成ワークフローに適用した。セッションをまたいでファイル形式の癖やツールの回避策を覚えられるようになっただけで、タスク完了率が約 6 倍になったと報告している^[1]。

user@sinyblog:~/article ❯ 13_dream-api.mdStep 10–11：Dream を API で実行し出力を検証する

Dreaming はリサーチプレビュー段階のため、実行には 3 つの前提条件がある^[3]。

1. Managed Agents API キー
2. Anthropic のフォームから Dreaming へのアクセスを申請済み（ゲーテッド公開）
3. Python または TypeScript 環境と最新の Anthropic SDK

Dream の呼び出しには 2 つのベータヘッダーを重ねる必要がある。SDK が自動で設定してくれるが、仕組みを理解するために示す。

anthropic-beta: managed-agents-2026-04-01,dreaming-2026-04-21

Dream の呼び出しコードは次のとおり。入力として「既存のメモリストア」と「参照するセッション ID（最大 100 件）」を渡す。

import anthropic

client = anthropic.Anthropic()

# Dream を実行する
dream = client.beta.dreams.create(
    inputs=[
        {"type": "memory_store", "memory_store_id": store_id},
        {"type": "sessions", "session_ids": [session_a, session_b, session_c]},
    ],
    model="claude-opus-4-7",  # または claude-sonnet-4-6
    instructions=(
        "コーディングスタイルの好みに注目して統合してください。"
        "一回限りのデバッグメモは無視してください。"
    ),
)

print(dream.id)  # drm_01...

Dream が完了すると、outputs[] 配列に新しいメモリストアの ID が入る。入力ストアは変更されていない。

# 出力ストアの ID を取得する
output_store_id = next(
    output.memory_store_id
    for output in dream.outputs
    if output.type == "memory_store"
)

print(f"新しいメモリストア: {output_store_id}")

ここで必ず行うべきレビューがある。出力ストアを読んで確認する。統合されたエントリは正しいか、置き換えられたエントリは本当に陳腐化していたか、表面に出てきたインサイトは実際の経験から来ているか。

レビューの観点は 3 点だ。① 統合されたエントリは正しく統合されているか。② 置き換えられたエントリは本当に古かったか（最新のものが残っているか）。③ 新しくサーフェスされたインサイトはノイズではないか。

user@sinyblog:~/article ❯ 14_schedule-dream.mdStep 12：スケジュール化して自己成長ループを完成させる

出力ストアの検証が終わったら、本番への切り替えは 1 行の変更だ。エージェントが参照するストア ID を、古いストアから新しいストアに変えるだけでいい。

# 本番ストアを新しいものに切り替える
agent_config["memory_store_id"] = output_store_id
# これだけ。エージェントは次回起動から新しいメモリで動く

次にやることはスケジュール化だ。エージェントの稼働頻度に応じて夜次または週次で Dream を定期実行する。これでループが閉じる。

1. エージェントが日中に仕事をこなす
2. 夜間（または週末）にバックグラウンドで Dream が走る
3. 翌朝、エージェントは統合・整理された記憶を持って目覚める
4. 再トレーニングなし・手動設定なしで、毎週少しずつ賢くなる

コスト面では、Dream は選択したモデルの標準 API トークンレートで課金される。入力セッションの数と長さに比例して費用が増えるため、公式ドキュメントが推奨する通り、最初は小さなバッチから始めて品質を確認してからスケールするのが賢明だ^[3]。

user@sinyblog:~/article ❯ 15_anti-patterns.mdよくある失敗パターンと対処法

記憶の仕組みを理解した後でも、運用でよく踏む落とし穴がある。特によく遭遇するパターンをまとめた^[1]。

最後に付け加えると、記憶が大きいほど良いという思い込みが最大の罠だ。記憶は道具であり、道具は目的に対して適切なサイズがある。lean で structured（小さく、構造化された）記憶が、long で complete（長く、網羅的な）記憶に常に勝る。

user@sinyblog:~/article ❯ 99_summary.mdまとめ：4 レイヤーで何が変わるか

Claude エージェントの記憶は一発で解決する問題ではなく、4 つのレイヤーを積み上げる設計の問題だ。それぞれが独立した役割を持ち、組み合わせることで初めてセッションをまたいだ知識の蓄積が実現する。

1. Layer 1（組み込みチャットメモリ）は今夜オンにできる。Settings → Capabilities → Memory。次に「好みを能動的に植える」一通のメッセージを送る。これだけで次のセッションの体験が変わる。
2. Layer 2（Projects）はエージェントの役割と制約を固定する場所だ。指示は Projects に、知識はメモリファイルに——この分業を守ることが、「前の話がなぜ消えたのか分からない」という最大の混乱を防ぐ。
3. Layer 3（メモリファイル）はセッションをまたいで知識を蓄積する仕組みだ。構造化して、フィルタリングして、定期的に棚卸しする。大きくすることが目的ではなく、次回の行動を変える情報だけを残すのが目的だ。
4. Layer 4（Dreaming）は繰り返す仕事をこなすエージェントだけに意味がある。夜間に自己反省し、翌日はより賢く動く——その自己改善ループが閉じたとき、エージェントは本当の意味で「育つ」存在になる。

Harvey が 6 倍のタスク完了率を達成したのは、モデルを変えたからでも、プロンプトを書き直したからでもない。記憶が続くようにしたから、それだけだ。