エージェントの記憶を「夢見て」整理し直す──Claude Managed Agentsの新機能Dreamsを読む

Claude Managed Agentsで動かしているエージェントは、作業のたびに「メモリストア」へ知見を書き込んでいく。だがこの書き込みは局所的・逐次的で、セッションを重ねるほど重複・矛盾・陳腐化した情報が溜まっていく。この整理をClaude自身にやらせる「Dreams（研究プレビュー）」という機能を、Anthropicの公式ドキュメント（platform.claude.com/docs/en/managed-agents/dreams）を実際に開いて確認した。

• Dreamsは既存のメモリストア1件と過去セッション1〜100件を読み、重複統合・矛盾解消・新知見抽出をした別の新メモリストアを生成する非同期ジョブ
• 入力ストアは一切変更されない。生成された出力を見て気に入らなければ、そのまま捨てられる設計
• 課金は選んだモデルの標準トークン単価どおりで、コストは入力セッション数・長さにほぼ比例する。公式は「小さいバッチから始めて満足したら増やす」ことを推奨している

Dreamsは何をするジョブなのか

公式ドキュメントの説明はこうだ。

A dream reads an existing memory store alongside past session transcripts, then produces a new, reorganized memory store: duplicates merged, stale or contradicted entries replaced with the latest value, and new insights surfaced.

（dreamは既存のメモリストアと過去セッションのトランスクリプトを読み、重複を統合し、陳腐化・矛盾したエントリを最新の値に置き換え、新しい知見を浮かび上がらせた、新しい再編成済みメモリストアを生成する）

入力は「メモリストア1件」＋「セッション1〜100件」の組み合わせで、出力は入力とは別IDを持つ新しいメモリストアだ。ドキュメントは "The input store is never modified" と明記しており、Dreamsは既存データを上書きする機能ではなく、あくまで別バージョンを作って見せる機能として設計されている。

ジョブはAPI経由で作成し、pending→running→completed（またはfailed／canceled）のライフサイクルをポーリングまたはイベントストリームで追う。5つの状態それぞれの意味は、公式ドキュメントに次のように定義されている。

running中は、session_idフィールドが、このパイプラインを裏で動かしている実際のセッションを指しており、そのセッションのイベントをストリーミングすることで、dreamが何を読み書きしているかをリアルタイムで観察できる。dreamが終了状態に達すると、このセッションは削除ではなくアーカイブされるため、後からトランスクリプトを確認できる、という設計だ。

なお、出力ストアのIDは、パイプラインが「入力ストアをクローン」した直後——runningになってすぐ——にoutputs[]へ現れる。つまり実装としては、入力ストアの複製を作ってからそれを作り替えていく、という手順になっており、「入力ストアは一切変更されない」という設計は、この複製元と複製先を明確に分けることで担保されている。

所要時間は「数分から数時間」と幅があり、入力トランスクリプトの量に依存するとされている。対応モデルは研究プレビュー時点で claude-opus-5・claude-fable-5・claude-opus-4-8・claude-opus-4-7・claude-sonnet-5・claude-sonnet-4-6 の6種で、instructionsフィールド（最大4,096字）で「コーディングスタイルの好みだけに注目し、単発のデバッグメモは無視して」のように再編成の方針を指示できる。ただしドキュメントは、このinstructionsが「特定の1文を書き換えて」のような行単位の指示には効かない、統合パイプライン全体への高レベルな方針指定用だと注記している。

キャンセル・アーカイブにも細かい仕様がある。pendingまたはrunningのdreamは即座にcanceledへ移行できるが、completedまたはfailedのdreamをキャンセルしようとすると400エラーが返る。アーカイブは終了状態（completed・failed・canceled）のdreamにのみでき、archived_atが設定される（status自体は変わらない）。アーカイブに「戻す」操作は用意されていない、ともドキュメントは明記している。

Managed Agentsベータの中でも、さらに別枠のアクセス申請が要る

Dreamsのドキュメントページ冒頭には、次のような注記がある。

"Dreaming is a research preview feature. Request access to try it."

（訳：Dreamingはresearch previewの機能である。試すには[アクセスを申請]する必要がある）

Claude Managed Agents自体の概要ページ（managed-agents/overview）を確認すると、この位置づけがより明確に書かれていた。

"Within the beta, MCP tunnels and dreaming are in a more limited research preview. Request access to enable them."

（訳：ベータ版の中でも、MCPトンネルとdreamingは、さらに限定されたresearch previewに位置づけられている。有効化するにはアクセス申請が必要）

つまりDreamsは、「Claude Managed Agentsのベータに入っていれば誰でも使える機能」ではなく、その中でもMCPトンネルと並んで別枠の申請が必要な機能だ。同じ申請フォーム（claude.com/form/claude-managed-agents）が2つの独立したドキュメントページから案内されている点からも、これが単発の記載ミスではなく一貫した扱いであることが確認できる。

実際に使う上での細かい仕様──入力ストアが無くても始められる、アーカイブは既定で一覧から消える

ドキュメントのCode例の直後には、次のような補足がある。

"If you only have session transcripts and no existing store, create an empty memory store first and pass it as the memory_store input."

（訳：セッションのトランスクリプトしか無く既存のストアが無い場合は、まず空のメモリストアを作成し、それをmemory_store入力として渡せばよい）

つまり「整理したい既存メモリストアがまだ無い」という状態でもDreamsは使え、空ストア＋セッション群という組み合わせから新規にメモリストアを立ち上げる用途にも対応している。

一覧取得（GET /v1/dreams）にも注意点がある。ドキュメントは「ワークスペース内のアーカイブされていないdreamを新しい順に返す」と明記しており、アーカイブ済みのdreamも見たい場合はinclude_archived=trueを明示的に渡す必要がある。デフォルトの一覧には出てこない、という挙動だ。

また、dream実行中の入力データの扱いについても、警告ボックスで次のように注意喚起されている。

"While a dream is pending or running, the 400 guard applies to archiving the dream itself, not its stores. Archiving or deleting an input memory store mid-run (or deleting an input session) will cause the dream to fail with input_memory_store_unavailable or input_session_unavailable."

（訳：dreamがpendingまたはrunningの間、400エラーによるガードはdream自体のアーカイブ操作に適用されるものであり、入力に使っているストアには適用されない。実行中に入力メモリストアをアーカイブ・削除したり、入力セッションを削除したりすると、dreamはinput_memory_store_unavailableまたはinput_session_unavailableで失敗する）

つまり「dream自体は実行中に誤ってアーカイブできないよう守られている」が、「dreamが読んでいる入力データ側」は実行中でも普通に削除・アーカイブでき、その場合はエラーで失敗する、という非対称な設計になっている。実行中のdreamが参照しているメモリストア・セッションは、完了まで触らない方がいい。

使いどころと制約

公式が挙げている使い方は「メモリストアを育てたが整理していないエージェント」の棚卸しだ。出力は既存セッションにリソースとして差し替えることも、元のストアと並行して使うこともできる。一方で制約もはっきりしている。

• ベータヘッダーdreaming-2026-04-21が別途必要（managed-agents-2026-04-01だけでは有効化されない）
• セッション数の上限は1ジョブあたり100件
• instructionsフィールドの上限は4,096字
• 研究プレビュー期間中はデフォルトのレート制限が適用され、それ以上必要な場合はサポートへの問い合わせが必要

公式ドキュメントのErrorsセクションには、起こりうるエラーが（「非網羅的なリスト」と断りつつ）6種類挙げられている。

課金面は「選んだモデルの標準API単価で、usageに実際のトークン数が出る」とされ、特別割引は明記されていない。ここは無料お試し枠ではなく、通常のAPI課金の対象だと読むのが妥当だ。

なぜ整理が必要なのか──メモリストアには1万件の上限がある

Dreamsが解決しようとしている問題の輪郭は、メモリストア自体を扱う別の公式ドキュメント（managed-agents/memory）を読むとより具体的になる。メモリストアは「ワークスペース単位のテキスト文書コレクション」で、セッションにアタッチするとサンドボックス内のディレクトリとしてマウントされ、エージェントは他のファイルシステムと同じツールで読み書きする。各メモリはパスでアドレス指定され、変更のたびに「メモリバージョン」という不変の記録が作られ、監査証跡と特定時点への復元が可能になっている。

このメモリストアには、1ストアあたり1万件のメモリという上限があり、これに達すると新規メモリへの書き込みが失敗する（既存メモリの読み書きは可能なまま）と明記されている。加えて、個々のメモリ1件にも上限があり、「個々のメモリは100KB（約2万5千トークン）を上限とする。メモリは少数の大きなファイルではなく、多数の焦点を絞った小さなファイルとして構成すること」とドキュメントは推奨している。

ベストプラクティスのセクションは、この上限に達する前の対処法として「陳腐化・冗長なメモリを削除する」ことと並べて、直接「dreamingセッションを実行する」ことを挙げており、Dreamsを「元のストアを直接書き換えるのではなく、統合された別の新しい出力ストアを作る」仕組みとして紹介している。同セクションはさらに具体的な運用手順として「dreamの出力ストアにセッションを切り替え、その後で元のストアをアーカイブまたは削除する」という順序を推奨している。つまりDreamsは、単なる「あったら便利な整理機能」ではなく、メモリストアが持つ具体的な容量上限に対する、公式が推奨する対処法の1つという位置づけになる。

ChatGPTの「Dreaming」との違い

似た名前の機能が競合にもある。ChatGPTのメモリ機能は2026年6月に「Dreaming V3」へ刷新され、事実の記憶精度が67.9%から82.8%に上がったと報じられている（当サイトの既報）。ただし対象がまったく違う。ChatGPTのDreamingはコンシューマー向けチャットの会話メモリを裏側で自動的に統合する仕組みであるのに対し、ClaudeのDreamsはManaged Agents（自前のエージェントをAPIで組む開発者向けプラットフォーム）のメモリストアを、明示的なAPI呼び出しで整理する機能だ。「夢見て記憶を整理する」という比喩が両社で偶然揃った形だが、コンシューマー向け自動処理と開発者向け明示的ジョブという性質は別物だと理解しておいた方がいい。

APIキーなしで確認できたこと、できなかったこと

この記事は公式ドキュメントのcURL・Python・TypeScript等のコード例と説明文を読んで書いており、実際にDreamsジョブを走らせて挙動を確認したものではない。Anthropic APIの課金呼び出しは本記事の作業範囲外としたため、「重複統合の精度がどれくらいか」「典型的なジョブの実際の所要時間」「instructionsの効き方の実例」は、ドキュメントに書かれている説明の域を出ない。「数分から数時間」という所要時間の幅について、具体的にどれくらいのセッション数・長さでどちらの端に寄るのかという目安も、ドキュメントには記載がなく本記事でも確認できていない。また、Claude Managed Agents自体がClaude Code・claude.aiの通常利用とは別の製品（自前のエージェントをAPIで構築・運用するためのプラットフォーム）である点も、混同しないよう明記しておく。

関連記事: Claude Code / Claude APIの2026年8月の変更点まとめ / ChatGPTのメモリ刷新「Dreaming V3」 / MCPとは

感想・指摘はコメント欄へ。