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

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

Claude Fable 5は、過去のセッションから得た教訓を記録し、後で参照できる状態にしたときに特に高い性能を発揮すると公式ガイドは述べています。仕組みは大がかりなものではなく、Markdownファイルのような単純な置き場所を1つ用意するだけで機能します。セッションをまたいで同じ間違いを繰り返さない、確認済みのアプローチを再利用する、といった効果が期待できる構成です。

これはAnthropicのManaged Agents APIが提供するメモリストア機能(セッション間で状態を持ち越す専用のAPIエンドポイント)とは別物です。メモリストアはワークスペース単位で管理される専用のドキュメント群で、セッションのサンドボックス内にディレクトリとしてマウントされ、専用のベータヘッダーを使ったAPI呼び出しで作成・編集します。対して本記事で扱うメモリシステムは、通常のシステムプロンプトと会話の中でClaude自身にノートを書かせ、読ませる運用上の工夫であり、専用のAPIエンドポイントもベータヘッダーも必要としません。Managed Agents環境を使っていないチームでも、システムプロンプトの指示だけで今日から始められる点が実務上の違いです。

記法 — 1レッスン1ファイルで書かせる

公式ガイドが示す指示文言は次の通りです。

この記法のポイントは「1レッスン1ファイル」という粒度です。教訓をまとめて1つの巨大なログファイルに追記していく方式ではなく、1つの学びごとに独立したファイルに切り出します。ファイル冒頭の1行要約は、後でClaudeがどのノートを読むべきか判断するための索引の役割を果たします。

さらに、書く対象を「リポジトリやチャット履歴にまだ残っていない情報」に絞っている点も重要です。コードやコミット履歴を読めば分かることをメモリに二重保存させないことで、ノートの総量を教訓そのものに絞り込みます。

運用ルール — 重複を作らず、誤りは消す

記法と同時に示されている運用ルールが、実際の品質を左右します。

この4点に共通するのは、メモリを「増やし続ける」のではなく「正しい状態に保ち続ける」運用だという点です。放置すると同じ内容のノートが増殖したり、後から誤りだと分かった教訓が残り続けたりします。更新と削除を明示的にルール化しているのは、蓄積型のログではなく手入れの前提のナレッジベースとして設計されているためです。

ノート1本の具体例

「1レッスン1ファイル」がどの程度の粒度になるか、具体例で見ておきます。

# Bashツールの権限チェックはグロブでなく正規表現で書く
 
以前、権限ルールを `Bash(git push:*)` のようなグロブ的な書き方で追加したところ、
`git push --force` も許可される想定外のマッチが起きた。
正規表現ベースのルール定義に切り替え、`--force` を明示的に除外する
パターンにしたところ再現しなくなった。今後、Bashの権限ルールを追加する際は
グロブ的な書き方を避け、除外したいフラグを明示したパターンを書く。

1行目の見出しがそのままファイル冒頭の要約になっており、以降の本文が「何が起きたか」「なぜ重要か」「今後どうするか」の順で1つの教訓に絞って書かれています。複数の学びを1ファイルに詰め込まず、この粒度でファイルを分けるのが公式ガイドの記法です。

ブートストラップ手順 — 過去セッションから教訓を抽出する

新しくメモリシステムを始める場合、ゼロから書き始めるのではなく、過去のセッション履歴からまとめて教訓を抽出させる手順が示されています。

ここでサブエージェントの利用が明示されている点は実装上の意味を持ちます。過去セッションの振り返りは、本流のタスクとは独立した調査作業です。Claude Fable 5は独立した規模のあるタスクをサブエージェントに委譲しやすい性質を持ち、メモリのブートストラップもその一例として位置付けられています。本流の作業コンテキストを消費せずに、過去ログの棚卸しだけを別コンテキストで完結させる構成です。

正式なメモリストアの運用ルールとの共通点

Managed Agents APIのメモリストアには、10,000件という保存上限があり、上限に達すると新規メモリへの書き込みが失敗すると説明されています。この制約を避けるための運用指針として、用途ごとに小さなストアへ分ける、ストアが埋まる前に古く重複した内容を削除する、断片化した内容を統合する「dreamingセッション」を使う、といった方法が挙げられています。

これは、本記事で扱ってきたシステムプロンプト側の運用ルール(重複を作らず更新する・誤りは削除する)と方向性が一致しています。専用APIを使うか、システムプロンプトの指示だけで済ませるかという実装手段は違っても、放置すると増殖し古くなるというメモリの性質そのものは変わらないため、どちらの実装でも「増やしたら手入れする」運用が前提になっているわけです。専用APIのような1万件単位の上限管理までは不要でも、ノートの数が増えてきたら定期的に統合・削除を検討する価値はあります。

興味深いのは、Managed Agents APIには「dreaming」というリサーチプレビュー機能があり、既存のメモリストアと過去のセッション記録を読み込んで、重複を統合し矛盾を最新の値に置き換えた新しいストアを自動生成する仕組みが用意されている点です。入力元のストアは変更されないため、結果を確認してから採用するかどうかを選べます。これは、ここまでのブートストラップ手順(サブエージェントに過去セッションを振り返らせてノートを作らせる作業)を、専用の非同期ジョブとして自動化したものに近い発想です。プロンプト側の工夫で今日から始められる仕組みと、それを専用機能として作り込んだ仕組みが、同じ「過去セッションからの教訓抽出」という課題に向き合っている構図が見えます。

なぜサブエージェントへの委譲が前提になっているのか

ブートストラップ指示がサブエージェントの利用を前提にしているのは、Claude Fable 5の別の性質と結びついています。公式ガイドは、Claude Fable 5が独立して規模のあるサブタスクへの委譲を積極的に行うようになったと説明しており、過去セッションの振り返りのような本流の作業と並行して処理できるまとまった調査は、委譲に向く典型例として位置付けられます。振り返り作業を本流のコンテキストの外に切り出すことで、本流のタスクに使える作業領域を圧迫せずに済みます。

同じ考え方は、メモリノートを書く理由付けにも波及します。公式ガイドは別項目で、Claudeにタスクの背景や意図を伝えると、自分で意図を推測するより性能が上がると述べています。メモリノートに「なぜその教訓が重要だったか」まで記録させておくのは、次回以降のセッションでこの背景情報を毎回書き直さずに済ませるための仕込みでもあります。

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

dreamingはリサーチプレビュー機能で、アクセス申請が必要なうえManaged Agents APIの利用が前提です。通常のシステムプロンプトだけでメモリシステムを組んでいるチームがこの恩恵に近いことをしたい場合は、ブートストラップ手順と同じ形で「既存ノート群を読み直して、重複や矛盾があれば統合し、古くなった内容を更新・削除する」棚卸しをサブエージェントに定期的に依頼する運用で代替できます。専用の自動化ジョブではなく人手(あるいは定期実行するプロンプト)でトリガーする点が違うだけで、狙いは同じです。

メモリシステムを組み込む手順

実装の流れを整理すると、次の3ステップになります。

1. ノートの置き場所を決める(リポジトリ内のディレクトリ、専用のファイルなど)
2. システムプロンプトに、1レッスン1ファイルの記法と重複禁止・削除ルールを明記する
3. 既存のセッション履歴があれば、サブエージェントに過去セッションの振り返りを指示してノートを初期構築する

このうち2番目の指示文言を欠くと、Claude自身が自発的にノートの粒度や重複排除を判断してしまい、記法が揺れます。公式ガイドの文言をそのままシステムプロンプトに含めるのが、最も再現性の高い導入方法です。実際にシステムプロンプトへ書き込む文面は、たとえば次のような形になります。

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

3番目のブートストラップ手順も、初回のセッションでそのまま渡せる指示文にしておくと迷いません。

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

Agent SDKでサブエージェントをプログラムとファイルどちらで定義するかはAgent SDKのサブエージェント定義で扱っています。長時間タスクの途中経過をユーザーに届ける仕組みはClaude Fable 5のsend_to_userツール設計を参照してください。

まとめ

Claude Fable 5のメモリシステムは、専用APIではなくMarkdownファイル程度の単純な置き場所と、1レッスン1ファイルの記法・重複禁止・削除ルールというシステムプロンプト側の運用ルールで成立します。新規に始める場合は、過去セッションをサブエージェント経由で振り返らせるブートストラップ手順を踏むと、ゼロから書き始めるより短時間で実用的な教訓ベースを作れます。既存のノートを更新せずに増やし続けたり、誤りが判明したノートを放置したりすると、後のセッションを誤誘導する原因になる点には注意が必要です。