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

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

Dreamsとは何か

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

ベータヘッダーは呼び出しごとに違う

Dream用のエンドポイントは dreaming-2026-04-21 ベータヘッダーで制御されており、managed-agents-2026-04-01 だけではアクセスできません。公式のページ同士で、ほかの呼び出しのヘッダーの書き方が食い違っています。

Dreamsのページは「セッションとメモリストアの呼び出しは managed-agents-2026-04-01 だけで足りる」と書きます。メモリのページはメモリストアのリクエストで managed-agents-2026-04-01 を agent-memory-2026-07-22 に置き換えるよう案内し、併記すると400が返ると書きます。出力ストアの確認や削除をcurlで直接書くときは、メモリのページの記述に合わせる読み方になります。SDKを使う場合、Dreamsのページによればヘッダーは自動で設定されます。

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をポーリングしてステータスを確認します。

while true; do
  dream=$(curl -s "https://api.anthropic.com/v1/dreams/$dream_id" \
    -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")
  status=$(jq -r '.status' <<< "$dream")
  echo "status=$status input_tokens=$(jq -r '.usage.input_tokens' <<< "$dream")"
  [[ "$status" == "pending" || "$status" == "running" ]] || break
  sleep 10
done

ステータスは次の5種類です。

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

出力メモリストアを使う

status が completed になると、outputs[] 内の memory_store エントリが、完成した新しいストアを指します。ワークスペース内の通常のメモリストアと同じ扱いなので、Memory Stores APIかConsoleでレビューできます。採用する場合の切り替えは、次の順です。

出力ストアの添付は access の既定が read_write です。外部入力を扱うエージェントでは、プロンプトインジェクションで悪意ある内容が書き込まれ、後続のセッションが信頼済みの記憶として読むリスクがメモリのページに書かれています。参照用に回すストアは read_only にします。

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 はどちらも容量起因のエラーですが、対象が違います。前者はその入力ストア自体のサイズ超過、後者は組織全体のメモリストア数上限です。前者は入力を絞る、後者は不要なメモリストアを整理するという別々の対処になります。failed や canceled で終わったDreamの出力ストアが不要なら、Memory Stores APIで削除します。

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

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

usage は input_tokens / output_tokens / cache_read_input_tokens / cache_creation_input_tokens の4項目で返ります。作成直後の pending ではすべて0で、running の間に更新されます。上のポーリング例のように input_tokens を表示しておくと、件数を増やしたときの伸びを実行ごとに比べられます。

利用制限

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

Dreamを使う場面と、使わない場面

メモリストアの容量が詰まると、挙動がはっきり変わります。満杯になっても、既存のメモリは読み取りも編集もできます。

満杯に近づいたときの手当ては、メモリのページにいくつか挙がっています。Dreamはそのうちの1つです。

向かないのは、メモリへの変更をその場で反映したい用途です。Dreamは数分から数時間かかるうえ、対応モデルもリサーチプレビューの間は6つに限られます。個別の行を直したい場合はMemory Stores APIの出番です。

マルチエージェント構成でメモリストアを共有する設計はManaged Agentsでマルチエージェントを編成する方法、Managed Agents全体の設計思想はAgent SDKのManaged Agentsの設計思想に書いています。

まとめ

試すなら、少数のセッションでDreamを作り、出力ストアを read_only で併載して質を見てから件数を増やす進め方が、コストにも元のストアにも手堅い選択です。リサーチプレビューの機能なので、直接curlを書く場合はヘッダーと対応モデルを呼び出しの時点で公式ページと照らします。