Managed AgentsのDreams機能とは — 非同期でメモリを再構成する仕組み

Managed AgentsのDreamsは、既存のメモリストアと過去セッションの記録を読み込み、重複を統合し矛盾を解消した新しいメモリストアを生成する非同期ジョブです。名前から中身を想像しにくい機能ですが、やっていることは「メモリの棚卸し」に近く、入力元のストアは書き換えません。リサーチプレビュー扱いの機能で、利用にはアクセス申請が必要です。

Dreamsとは何か

エージェントは作業中にメモリストアへ随時書き込みますが、この書き込みはローカルかつ積み上げ式です。セッションを重ねるほど、メモリストアには重複・矛盾・陳腐化したエントリが溜まっていきます。Dreamは既存のメモリストアと過去セッションのトランスクリプトを合わせて読み込み、重複を統合し、古い値や矛盾したエントリを最新の値へ置き換え、新しい洞察を加えた別のメモリストアを出力します。入力元のストアは変更されません。出力を確認してから、気に入らなければ破棄できる設計です。

Dream用のエンドポイントは dreaming-2026-04-21 ベータヘッダーで制御されており、managed-agents-2026-04-01 ヘッダーだけではアクセスできません。セッション・メモリストア呼び出しは managed-agents-2026-04-01 だけで足ります。

Dreamを作成する

Dreamの入力は、既存のメモリストア1つと、1〜100件のセッショントランスクリプトです。

dream=$(curl -s https://api.anthropic.com/v1/dreams \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: managed-agents-2026-04-01,dreaming-2026-04-21" \
  -H "content-type: application/json" \
  --data @- <<EOF
{
  "inputs": [
    { "type": "memory_store", "memory_store_id": "$store_id" },
    { "type": "sessions", "session_ids": ["$session_a", "$session_b"] }
  ],
  "model": "claude-opus-4-8",
  "instructions": "Focus on coding-style preferences; ignore one-off debugging notes."
}
EOF
)
dream_id=$(jq -r '.id' <<< "$dream")

対応モデルはリサーチプレビュー期間中、claude-opus-5 / claude-fable-5 / claude-opus-4-8 / claude-opus-4-7 / claude-sonnet-5 / claude-sonnet-4-6 の6つです。既存のメモリストアがなくセッショントランスクリプトだけある場合は、先に空のメモリストアを作成してから memory_store 入力として渡します。

作成直後のレスポンスは status: "pending" を持つDreamリソースそのものです。outputs[] はまだ空配列で、session_id も null のままです。出力ストアのIDは、パイプラインが入力ストアの複製を終えたあと、running に切り替わってしばらくしてから outputs[] に現れます。running になった直後の outputs[] が一瞬空のままなのは正常な挙動で、複製が終わるまでのタイムラグです。ポーリング処理を書くときは、この一時的な空配列をエラーと誤認しないよう注意します。

任意の instructions フィールドでパイプライン全体の合成方針を指示できます。何を重点的に読むか、何を統合・削除するか、出力ストアをどう構造化するかに反映されます。ただしDreamはストアの文字列を直接編集するエディタではなく、入力全体を読んで合成するパスです。「この文の◯◯を△△に直して」のような特定行を狙った命令はほとんど反映されません。個別メモリを狙い撃ちで編集したい場合は、出力ストアに対してMemory Stores APIを直接使います。

進捗を追跡する

Dreamは非同期ジョブで、入力トランスクリプトの件数に応じて数分から数時間かかります。IDをポーリングしてステータスを確認します。

running になると session_id フィールドが、パイプラインを実際に動かしているセッションを指します。そのセッションのイベントをストリームすれば、Dreamが何を読み書きしているかをリアルタイムで観察できます。Dreamが終端状態に達すると、このセッションは削除ではなくアーカイブされるため、トランスクリプトは事後でも参照できます。

出力メモリストアを使う

status が completed になると、outputs[] 内の memory_store エントリが、完成した新しいストアを指します。ワークスペース内の通常のメモリストアと同じ扱いなので、Memory Stores APIかConsoleでレビューしたうえで、次のいずれかを選びます。

• 活用する: 入力元のストアの代わりに(または並行して)、以降のセッションに memory_store リソースとして接続する
• 破棄する: 出力ストアを削除、またはアーカイブする

Dream自体は入力を削除・変更しません。ただし実行中に入力メモリストアをアーカイブ・削除したり、入力セッションを削除したりすると、Dreamは input_memory_store_unavailable または input_session_unavailable エラーで失敗します。

pending または running のDreamは cancel エンドポイントで即座に canceled へ移せます。すでに canceled のDreamをキャンセルしても冪等に成功しますが、completed / failed のDreamをキャンセルしようとすると400エラーになります。キャンセル直後も、進行中だった処理が収まるまで数秒は usage が更新され続けることがあります。最終的な使用量が必要なら、usage の値が安定するまでポーリングを続けます。

終端状態(completed / failed / canceled)に達したDreamは archive でリスト表示から外せます。アーカイブ済みのDreamをもう一度アーカイブしても冪等に成功しますが、pending / running のDreamをアーカイブしようとすると400エラーになり、先にキャンセルする必要があります。アーカイブに取り消しはありません。アーカイブしてもDreamの status は終端状態のまま変わりません。アーカイブはDreamリソース自体の表示状態を変えるだけで、出力メモリストアには影響しません。出力ストアの削除・アーカイブはMemory Stores APIで別途行います。

ワークスペース内のDreamはIDを指定しなくても一覧できます。既定ではアーカイブ済みを除く非アーカイブのDreamだけを新しい順に返し、limit(既定20、最大100)と page カーソルでページングします。include_archived=true を付けるとアーカイブ済みも含めて返せます。

Dreamが失敗する主なパターン

Dreamのエラーは非網羅ですが、公式が挙げている代表例は次のとおりです。

input_memory_store_too_large と memory_store_org_limit_exceeded はどちらも容量起因のエラーですが、対象が違います。前者はその入力ストア自体のサイズ超過、後者は組織全体のメモリストア数上限です。前者は入力を絞る、後者は不要なメモリストアを整理するという別々の対処になります。

課金とコストはどう決まるか

Dreamは選択したモデルの標準APIトークンレートで課金され、リソースの usage に正確な合計が反映されます。コストは入力セッションの件数と長さにほぼ比例します。少数のセッションから試し、キュレーションの質に納得してから件数を増やすのが安全です。

コストを押し上げるのは主に入力側です。入力セッションのトランスクリプトが長いほど読み込むトークンが増え、その分だけ課金額が上がります。会話が長く続いたセッションを大量に放り込むより、要点が詰まった短めのセッションを絞って渡すほうが、同じキュレーション品質でもコストを抑えやすくなります。

利用制限

リサーチプレビュー期間中は、Dream作成にデフォルトのレート制限が適用されます。より高い上限が必要な場合はサポートへ連絡します。

Dreamsは何のためにある機能か

Dreamsが解決しているのは「メモリの手入れを誰がやるか」という問題です。エージェント自身に随時書き込ませる設計は、書き込みのたびに矛盾チェックをさせるとレイテンシーとコストが増えるため、通常は追記優先になります。Dreamsはその負債を後から一括で精算する非同期バッチとして切り出した形です。裏を返すと、メモリストアの手入れをリアルタイムに反映したい用途には向きません。Dreamは数分から数時間かかる非同期ジョブであり、対応モデルもリサーチプレビューの間は6つに限定されています。まとめて処理する設計だからこそ、日々の書き込みは追記優先のまま安く保てます。

命名の由来は推測の域を出ませんが、睡眠中の記憶の整理になぞらえたものと見て自然です。稼働中のエージェントには手を触れず、活動が落ち着いたタイミングでまとめてメモリを再構成する点は、比喩として的を射ています。ただし実体は定期実行のバッチジョブであり、機能名から連想しがちな自動判断や創発的な学習が起きるわけではありません。

まとめ

Dreamsは既存のメモリストアと最大100件のセッショントランスクリプトを入力に、重複・矛盾・陳腐化を整理した新しいメモリストアを生成する非同期ジョブです。入力元は変更されず、出力は確認してから採用するか破棄するかを選べます。instructions は合成方針の指示に使い、個別メモリの狙い撃ち編集には向きません。リサーチプレビューでアクセス申請が必要な機能です。

まずは既存ストア1つと数件のセッションだけで小さく試し、出力の質を見てから対象セッションの件数を広げていくのが安全な進め方です。

メモリストアへの書き込みやマルチエージェント構成でのMCP接続・スレッド設計はManaged Agentsでマルチエージェントを編成する方法、Managed Agents全体の設計思想はAgent SDKのManaged Agentsの設計思想を参照してください。