Claude Fable 5のメモリシステムを構築する仕組みと運用ルール

Claude Fable 5にメモリシステムが効く理由

Claude Fable 5は、過去の実行から得た教訓を記録し、後で参照できるようにしたときに特に高い性能を出します。置き場所はMarkdownファイル程度で足ります。同じ間違いを繰り返さない、うまくいったやり方を再利用する、という効果を狙う構成です。

仕組みは2通りあります。1つは、システムプロンプトの指示でClaude自身にノートを書かせ、読ませる方法です。もう1つは、Managed Agents APIのメモリストアを使う方法です。この記事の中心は前者で、後者は選び分けの材料として後半で扱います。

導入の3ステップ

システムプロンプトに入れる記法

公式ガイドが示す指示を日本語にすると、次のようになります。

## メモリの記法
 
教訓は1ファイルに1つずつ、ファイル冒頭に1行の要約を付けて保存すること。
修正点と確認済みのアプローチの両方を、なぜ重要だったかとあわせて記録すること。
リポジトリやチャット履歴にすでに残っている内容は保存しないこと。
既存のノートがあれば重複を作らず更新すること。
誤りだと判明したノートは削除すること。

核になるのは「1レッスン1ファイル」の粒度です。巨大なログファイルに追記し続けるのではなく、1つの学びを1ファイルに切り出します。冒頭の1行要約は、Claudeがどのノートを読むか選ぶときの索引になります。

書く対象を「リポジトリやチャット履歴にまだ残っていない情報」に絞る点も効いています。コードやコミット履歴から読み取れることを二重に保存させなければ、ノートは教訓だけになります。

残りの指示は、メモリを「増やし続ける」ものでなく「正しい状態に保つ」ものとして扱うための運用ルールです。

ノート1本の粒度

粒度の目安として、架空のノートを1本示します。

# テストは --filter を付けて対象パッケージだけ回す
 
モノレポで全パッケージのテストを回したところ、無関係なパッケージの
失敗で本来の確認が埋もれた。--filter で対象を絞ったら、確認が1回で済んだ。
今後、テストを回すときは対象パッケージを指定してから実行する。

1行目の見出しがファイル冒頭の要約になり、本文は「何が起きたか」「どう直したか」「今後どうするか」の順で1つの教訓に絞られています。複数の学びを詰め込まず、この粒度でファイルを分けます。

過去のセッションから初期ノートを作る

履歴が既にあるなら、ゼロから書き始めずに振り返りを依頼します。公式ガイドのブートストラップ指示を日本語にすると、次の形です。

これまで一緒に行ったセッションを振り返ってください。
サブエージェントを使って中核となるテーマと教訓を洗い出し、
[ノートの置き場所] に保存してください。
今後はこの場所を必ず参照するようにします。

[ノートの置き場所] には、手順1で決めたパスを入れます。

指示にはサブエージェントの利用が含まれています。ガイドでは、Claude Fable 5は並列のサブエージェントを以前のモデルより積極的に立て、長く動くサブエージェントとのやり取りも保てるとされています。

サブエージェントの定義方法はAgent SDKのサブエージェント定義にあります。長く動く処理の途中経過を利用者へ返す仕組みはClaude Fable 5のsend_to_userツール設計にあります。

ノートに「なぜ重要だったか」まで書かせる理由も、同じガイドにあります。タスクの背景や意図を伝えたほうが、Claudeが意図を推測するより性能が上がるという記述です。理由まで残しておけば、次のセッションで背景を毎回書き直さずに済みます。

システムプロンプト方式とメモリストアの違い

名前が似ていますが、2つは別の仕組みです。

メモリストアのAPIを呼ぶときは、ベータヘッダー agent-memory-2026-07-22 を使います。メモリストアへのリクエストで managed-agents-2026-04-01 と併記すると400エラーになります。一方、ストアをセッションに付けるセッション側の呼び出しは、これまでどおり managed-agents-2026-04-01 です。

メモリストアでも、置き場所の作法はこの記事の記法と同じ方向です。ストアの1件は100 kB(約25,000トークン)が上限で、「小さな焦点を絞ったファイルを多数」置く構成が勧められています。1レッスン1ファイルは、そのままこの勧めに沿った粒度です。

メモリストアで誤ったノートを直すとき

システムプロンプト方式なら、誤ったノートはファイルを直すか消すだけです。メモリストアでは、直し方に決まりがあります。

メモリのすべての変更は、書き換えられない版(memver_...)として残ります。専用の復元エンドポイントはなく、戻したい版を取得し、その content を更新のAPIで書き戻します。版は書き込みから30日保持され、それより長く履歴を残したいときはAPIで書き出します。

並行して書き込むセッションがあるときは、更新に content_sha256 の前提条件を付けます。読んだ時点の内容と保存中の内容のハッシュが食い違えば更新は適用されないので、読み直してやり直せます。

秘密情報や個人情報を書いてしまった場合は、過去の版の中身を消すredactを使います。誰がいつ何をしたかの記録は残ります。現在の先頭にあたる版はredactできないため、先に新しい版を書くか、メモリを削除してから、古い版をredactします。

エージェントがノートをどう読み書きしたかは、イベントストリームに通常のツール呼び出しとして出ます。一覧の取得には path_prefix と depth が使えます。path_prefix は / で終わる必要があり、パスの区切り単位で一致するので、/notes/ は /notes-archive/ を拾いません。

セルフホストのサンドボックスでは、ディレクトリはライブのマウントでなく、ワーカーが管理するローカルのコピーです。同期は既定で15秒に1回までで、別のセッションが変更を見るのは両方のワーカーが同期してからになります。

システムプロンプト方式とメモリストアの切り分け

選ぶ材料は、誰がどこからノートを読み書きするかです。

• 1つのリポジトリで、ノートを人が読み、Gitで管理したい: システムプロンプト方式。ノートは普通のファイルなので、差分もレビューもそのまま使えます
• 利用者ごと、チームごとにメモリを分け、同じエージェント設定を共有したい: メモリストア。1セッションに最大8つまで付けられ、利用者別・チーム別・プロジェクト別に分けるのは、ドキュメントが挙げる典型的な使い方です
• 共有の規約集は全セッションに読ませ、書き込みは各セッションの専用領域に限りたい: メモリストア。共有ストアを read_only で付け、セッション専用のストアは読み書き可能にします

アタッチしたストアの置き場所は、セッションのメモリストアリソースの mount_path に返ります。パスは組み立てず、そこから読む作りが指定されています。/mnt/memory/ 配下でストアのマウント以外のパスへの書き込みは失敗します。ストアごとの説明は、システムプロンプトにも自動で追記されます。

ノートが増えたときの手入れ

上限に達したストアでは、新しいメモリの作成が失敗します。既存のメモリは読み書きできます。挙げられている対処は、用途ごとに小さなストアへ分ける、満杯になる前に古い・重複した内容を削除する、満杯の元ストアを read_only で残して新しいストアに書く、の3つです。書き込み権限を、実際に書くセッションだけに絞る方法もあります。

システムプロンプト方式にはこうした件数の上限はありません。それでも、更新と削除のルールを置く理由は同じで、放置したノートは増殖し、誤った教訓が残ります。

dreamingで棚卸しを自動化する

Managed Agentsには、リサーチプレビューの機能としてdreamingがあります。既存のメモリストアと1〜100件の過去セッションの記録を読み、重複をまとめ、古くなったり矛盾したりした項目を最新の値に置き換えた新しいストアを出力します。入力のストアは変更されないので、結果を見て採用するかどうかを選べます。

dreamingは非同期のジョブで、完了までに数分から数時間かかります。利用にはアクセス申請と、ベータヘッダー dreaming-2026-04-21 が必要です。料金は選んだモデルの通常のAPIトークン単価で、入力するセッションの数と長さにほぼ比例します。少数のセッションで仕上がりを見てから増やす進め方が勧められています。

instructions には、まとめ方の大きな方針を渡します。たとえば「コーディングスタイルの好みに絞り、一度きりのデバッグ記録は無視する」です。dreamingはテキストの編集ではなく統合の処理なので、「第3節の件数を直す」のような特定の行への指示は、たいてい変更になりません。個別のメモリを直すなら、メモリストアのAPIを使います。instructions は4,096文字までで、dreamingに使えるモデルには claude-fable-5 も入っています。1回に渡せるセッションは100件までです。

終わった出力は、ふつうのメモリストアとして作業環境に現れます。内容を見たうえで、次のセッションにアタッチして使うか、削除またはアーカイブして捨てます。

dreamingの実行が失敗する典型は、実行時間の超過、入力ストアが大きすぎる、入力のストアやセッションが作成後に削除された、の3つです。ほかに、組織のメモリストア数の上限に達して作業用のストレージを確保できないときも失敗します。出力ストアは失敗時点の状態で残るので、使う前に中身を確かめます。

dreamingを使えない環境での代替

システムプロンプト方式のチームは、ブートストラップと同じ形で棚卸しを依頼すれば、近いことができます。既存のノートを読み直して、重複や矛盾を統合し、古い内容を更新・削除するよう、サブエージェントに頼む指示です。専用ジョブでなく人手か定期実行のプロンプトで起動する点だけが違います。

まとめ

先に決めるのは、メモリを置く場所と手入れの担当者です。システムプロンプト方式はファイル1つと指示文で始められ、ワークスペースをまたいで共有したい、版の履歴を残したいといった要件が出たときにメモリストアが候補になります。どちらでも、教訓は1件ずつ小さく書き、更新と削除を絶やさない運用が前提です。