Claude Dreamingとは？Anthropic Managed Agents新機能・自己改善メモリ・Harvey6倍効率化を徹底解説【2026年5月発表】

Claude Dreaming（ドリーミング／Dreams）は、Anthropicが2026年5月6日に Claude Managed Agents 向けに公開した、エージェントの永続メモリを自己整理させる非同期ジョブ機能です。既存のメモリストアと過去セッションを読み直し、重複・矛盾・陳腐化したエントリを統合した「新しいメモリストア」を別途生成するため、長期運用するエージェントが「使うほど賢くなる」仕組みを作れます。

この記事では、Claude Dreamingの定義・仕組み・対応モデル・料金・主要API・制限事項に加え、同時発表されたOutcomes／Multi-agent orchestrationとの関係、Harveyの「タスク完了率6倍」事例、メモリ汚染リスクと安全運用のポイントまで、2026年5月時点の公式情報をベースに整理します。

この記事でわかること

Claude Dreamingの正確な定義と、Managed Agents全体の中での位置づけ
対応モデル・100セッション制限などの実装上の制約
Harvey／Wisedocs／Netflixなど公式が公開した導入事例の数値
料金（標準APIトークン課金）と運用コストの考え方
メモリ汚染（memory poisoning）リスクと推奨される3層メモリ設計

こんな読者向けの記事です

Claude Managed AgentsでエージェントAPIを評価検討中のエンジニア・PdM
長期運用エージェントの記憶設計に課題を持つチームリード
法務・医療・金融など、規制対象データを扱う事業でエージェント導入を検討する担当者

Claude Dreamingとは何か（定義と全体像）

Anthropic Claude Opus 4.7のキービジュアル（DreamingはOpus 4.7とSonnet 4.6に対応）

出典: Anthropic公式

Claude Dreamingは、Claude Managed Agents上で動作するエージェントの永続メモリを、Claude自身に読み直させて整理させる非同期パイプラインです。神経科学でいう「Memory Consolidation（睡眠中の記憶固定化）」をエージェント設計に応用したコンセプトで、Anthropicは公式に "dream" と命名しています。

公式ドキュメント（platform.claude.com/docs/en/managed-agents/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.

要点は以下の3つです。

入力は「既存メモリストア1個」と「過去最大100セッション分のトランスクリプト」
出力は重複統合・矛盾解消・新たな知見を表面化した新しいメモリストア（別ID）
入力ストアは絶対に書き換えられないため、人間がレビューして採用するか破棄するかを選べる

つまり、ユーザーがDreamを実行しても既存の運用環境は壊れません。「夢の中で記憶を整理した別ストアが提案される」設計になっており、本番反映の判断は常に人間側に残ります。

Managed Agents全体の中での立ち位置

Dreamingは独立機能ではなく、Managed Agentsスタックの最上位レイヤーに位置します。前提機能のMemory（永続メモリ／2026年4月23日にPublic Beta化）が無いとDreamは動きません。

レイヤー	機能	ステータス（2026年5月時点）
基盤	Managed Agents（agents / sessions / environments）	Public Beta
記憶	Memory Stores（テキストファイルベース永続メモリ）	Public Beta
自己改善	Dreaming（メモリ自己整理）	Research Preview（要アクセス申請）
評価	Outcomes（rubric採点による自己修正）	Public Beta
編成	Multi-agent orchestration	Public Beta
拡張	Webhooks	利用可能

Dreamingだけが「Research Preview」で招待制です。多くの日本語記事がこの区別を曖昧にしているため、評価・申請を進める際は注意してください。

Managed Agents全体像をまだ押さえていない方は、先にClaude Managed Agentsとはを読むと前提が揃います。

なぜ「Dreaming」が必要なのか — 解決する課題

長期運用するエージェントは、永続メモリに逐次的にメモを追記する仕様ゆえ、次のような問題が発生します。

重複エントリ：同じTipsが複数セッション由来で繰り返し書き込まれる
矛盾エントリ：古い設定値と新しい設定値が両方残る
陳腐化：APIの仕様変更後も古い回避策が残り、誤動作を誘発する
暗黙知の埋没：個別セッションでは見えなかった「再発パターン」「収束したワークフロー」が表面化しない

DreamingはこれらをClaude自身に読み直させて再構築することで解消します。Anthropic公式ブログでは「再発するミス／複数エージェントが収束したワークフロー／チームで共有されている好み」を表面化させると説明されています。

ChatGPT Memoryのような「個人単位の私についての記憶」とは設計思想が異なり、マルチエージェント・マルチセッション横断の集合知整理を狙った機能である点が大きな特徴です。

Claude Dreamingの仕組み（API・ライフサイクル）

Claudeの内部表現を扱うAnthropicリサーチのキービジュアル（Dreamingはモデル内部の知見を再構成する仕組み）

出典: Anthropic Research

Dreamingは非同期ジョブとして動作します。実行時間は数分〜数十分（公式記載・入力サイズに依存）で、SSEストリーミングによる進捗観測も可能です。

Dreamの入力と出力

inputs:
  - memory_store      # 必須・1個（読み取り専用）
  - sessions          # 任意・最大100個の過去セッション
model: claude-opus-4-7 または claude-sonnet-4-6
instructions: 自由記述（4,096文字まで）

outputs:
  - new_memory_store  # 別IDで生成。人間がレビューしてから採用判断

ステータス遷移

status	意味
pending	作成・キュー待ち
running	パイプライン実行中（usageが逐次更新）
completed	完了。`outputs[]`に新メモリストアID
failed	エラー終了。出力ストアは部分書込状態で残る
canceled	ユーザーによるキャンセル

主要エンドポイント

メソッド	パス	用途
POST	`/v1/dreams`	Dream作成
GET	`/v1/dreams/{id}`	ステータス確認
POST	`/v1/dreams/{id}/cancel`	キャンセル（pending/runningのみ）
POST	`/v1/dreams/{id}/archive`	アーカイブ（terminal状態のみ・unarchive不可）
GET	`/v1/dreams`	一覧（最新順、limit最大100）

必須ベータヘッダー

リクエスト時には次の2つを併記する必要があります（公式SDKは自動付与）。

anthropic-beta: managed-agents-2026-04-01,dreaming-2026-04-21

managed-agents-2026-04-01（親バージョン）と dreaming-2026-04-21（Dreaming専用）の2つを同時に渡さないと有効化されない点が、独自実装で詰まりやすい箇所です。

公式SDK・CLI

Python / TypeScript / Go / Java / .NET / PHP / Ruby と、CLI（ant beta:dreams）が提供されています。実装初期は公式SDK経由で動かすのが安全です。

Claude Dreamingの料金（2026年5月時点）

公式ドキュメントの "Billing" セクションでは、Dreamingに専用の追加料金はなく、標準のAPIトークン課金と明示されています。

課金項目	内容
入力トークン	選択モデルの input_tokens 単価
出力トークン	選択モデルの output_tokens 単価
キャッシュ作成	cache_creation_input_tokens（割増）
キャッシュ読込	cache_read_input_tokens（割引）
Dreaming追加料金	なし（2026年5月時点）

コストは入力セッション数とその長さに対してほぼ線形に増加します。Anthropicは「最初は小規模なセッションバッチで品質を確認してからスケールせよ」と公式に推奨しており、本番投入前に少数セッションでパイロットを回す運用が現実的です。

なお、リサーチプレビュー終了後のGAタイミングで料金体系が変更される可能性は否定されていません。本番採用判断時は最新の公式料金ページで再確認してください。

Managed Agents全体のレートリミット（参考）

Operation	Limit
Create系（agents/sessions/environments など）	300 req/min
Read系(retrieve/list/stream など)	600 req/min

Dreaming単体のレートリミットは「Default rate limits apply」とのみ公式記載で、組織あたり何dream/分かは非公開です。引き上げが必要な場合はAnthropicサポートに問い合わせる流れになります。

できないこと・実装上の制約

公式ドキュメントに明記された制約を整理します。実装で詰まるのはほぼここです。

項目	値・条件
1 dreamあたりの最大入力セッション数	100
`instructions`の最大文字数	4,096文字
対応モデル	claude-opus-4-7 と claude-sonnet-4-6 のみ
入力メモリストアの書き換え	不可（読み取り専用）
実行中の出力ストア削除/アーカイブ	不可（400エラー）
実行中の入力ストア/セッション削除	dreamが`input_*_unavailable`で失敗
完了済みdreamのキャンセル	不可（400エラー）
アーカイブの解除	不可（unarchive APIが存在しない）
pending/running状態でのアーカイブ	不可（先にcancelが必要）

主なエラータイプ

error.type	発生条件
`timeout`	実行予算超過
`internal_error`	未分類のパイプライン失敗
`memory_store_org_limit_exceeded`	組織のメモリストア上限到達
`input_memory_store_too_large`	入力ストアがサイズ制限超過
`input_memory_store_unavailable`	入力ストアが途中で削除/アーカイブ
`input_session_unavailable`	入力セッションが途中で削除/アーカイブ

input_memory_store_too_largeの具体閾値は公式非公開ですが、Memory Stores APIの参考制約として「1ファイル100KB（約25Kトークン）」が知られています。

公式が公開した導入事例（Harvey・Wisedocs・Netflix）

法律AIスタートアップHarveyの公式キービジュアル（Dreamingでタスク完了率6倍を達成したと発表）

出典: Harvey公式ブログ

2026年5月6日の公式ブログ「New in Claude Managed Agents」で、3社の事例が公開されました。Dreaming単体だけでなく、同時発表機能も含めて整理します。

企業	業界	利用機能	公開された効果
Harvey	法律AI（弁護士向けドラフト・契約書）	Dreaming	タスク完了率が約6倍（モデル変更ではなく、ファイル種別ごとの回避策やツール固有パターンを記憶した効果）
Wisedocs	医療文書レビュー	Outcomes	文書レビュー時間を50%短縮
Netflix	内部ビルド分析	Multi-agent orchestration	数百ビルドのログを並列処理（具体倍率は非公開）

Harvey「6倍」の正しい読み方

Harveyの「タスク完了率6倍」は強烈な数字ですが、過度に期待しすぎないために以下を押さえておくべきです。

Harvey内部テストでの計測であり、外部監査値ではない
既にClaude Opus 4.6を本番稼働中で、Opus 4.7への切り替え＋Dreamingの合算効果である可能性が高い
母集団・期間・タスク種別の内訳は非公開
法律ドメインに固有のパターン（書式・引用・契約条項）が学習対象だった可能性が高い

つまり、別ドメイン・別ワークロードで同じ倍率が出るとは限りません。自社で評価する際は、Dreaming導入前後でA/B比較を取るか、固定タスクセットでの完了率を測ることが現実的です。

Outcomesの数値（参考）

同時発表のOutcomesでは、標準プロンプトループに対しタスク成功率が最大10ポイント改善、ファイル形式別ではdocx +8.4% / pptx +10.1%という具体値が示されています。Dreamingと組み合わせる前提で評価設計するチームは、Outcomesの数値も合わせて把握しておくと判断しやすくなります。

競合機能との違い

Dreamingに似た「エージェント記憶」系機能は他社でも増えていますが、設計思想は異なります。

比較対象	アプローチ	Dreamingとの違い
OpenAI ChatGPT Memory	個人単位の「私についての記憶」	Dreamingはチーム横断の集合知を整理
Google ReasoningBank（研究）	抽象的な「推論戦略」を蓄積	Dreamingは具体テキスト形式・人間レビュー可能な実用設計
コンテキスト圧縮（compaction）	単一セッション内のトークン節約	Dreamingはマルチセッション・マルチエージェント横断

Dreamingの差別化は、「人間がレビューしてから採用できる、テキストファイルとして読める形のメモリ」を保ったまま自己整理を回せる点にあります。コンプライアンス上、AIによる自律的な記憶書換に不安がある企業でも採用しやすい設計です。

セキュリティリスクと推奨運用

AI時代のセキュリティを示すAnthropic Project Glasswingのキービジュアル（Dreamingにはメモリ汚染リスクの設計対策が必要）

出典: Anthropic公式

Dreamingは便利な反面、自律的にメモリを書き換える性質上、メモリ汚染（memory poisoning）リスクが指摘されています。VentureBeatや独立系セキュリティ研究者（kenhuangus.substack.com など）が公開している分析を踏まえ、運用上の注意点を整理します。

主なリスク

メモリ汚染：汚染されたセッションが入力に混ざると、Dreamがそれを「正規の知見」として統合してしまう
プロンプトインジェクション：外部入力経由でメモリに悪意ある記述が紛れ込み、Dreamが昇格させる
説明可能性の欠如：自律的に書換が起きるため、EU AI Act・国内のAI事業者ガイドライン対応で監査ログ要件を満たす設計が必要
アーカイブ不可逆性：dreamのarchiveは解除できないため、運用設計時に戻し操作が取れない

推奨される設計パターン

外部分析が共通して推奨しているのは、3層メモリ構造＋人間レビューの組み合わせです。

組織メモリ（最上位／レビュー必須）：チーム全体に昇格させる確定知見のみ
プロジェクトメモリ（中間）：プロジェクト範囲で共有する作業知見
ワーキングメモリ（最下層）：個別エージェントが自由に書き込む一時メモ

Dreamの出力は最初ワーキングメモリに置き、レビューゲート＋出所確認を経てから上位レイヤーに昇格させます。自動昇格をルーチン化しないことが、メモリ汚染対策の核心です。

公式の安全装置

Anthropic側もリスクを意識した設計を行っており、以下が公式仕様として保証されています。

入力ストアは絶対に変更されない（必ず別ストアを出力）
dream中のセッションはアーカイブのみで削除はされない（事後監査可能）
Memory Stores APIでusage・session eventsを記録できる

エージェント全般のセキュリティ設計はAIエージェントセキュリティガイドで詳しく整理しています。Dreaming導入前に併読することをおすすめします。

アクセス申請とすぐ試せる前提条件

DreamingはResearch Previewのため、Managed AgentsのAPIキーがあってもそのままでは使えません。

申請の流れ

アクセス申請フォーム（https://claude.com/form/claude-managed-agents ）に組織情報・想定ユースケースを記入して送付
Anthropicからの承認連絡を待つ（承認までの日数は公式非公開）
承認後、anthropic-beta: managed-agents-2026-04-01,dreaming-2026-04-21 ヘッダー付きでDreams APIが利用可能に

前提として必要なもの

AnthropicのAPIキー（Managed Agents自体はAPIキー保有者にデフォルト有効）
既にMemory Stores（Public Beta）でメモリを蓄積している運用エージェント
100セッション分程度の過去トランスクリプト（最初のDreamを意味あるものにするため）

「まずManaged Agents自体を立ち上げてMemoryを運用 → 数週間ログを貯める → Dreamingを申請」という段階を踏むのが現実的です。

こんな人におすすめ／おすすめしない人

Dreamingは強力ですが、すべてのチームに合うわけではありません。導入判断の目安を整理します。

こんな人・チームにおすすめ

長期運用エージェントでメモリの重複・矛盾・陳腐化に悩んでいる
マルチエージェント構成で「チーム横断の暗黙知共有」を仕組み化したい
既にClaude Managed Agents＋Memoryを本番運用しており、ログが100セッション以上貯まっている
レビューゲート付きの3層メモリ運用を設計できる体制がある
Opus 4.7／Sonnet 4.6を採用しており、トークン課金の規模感に許容度がある

こんな人・チームにはおすすめしない

規制対象データ（医療PHI・金融取引・個人情報）を本番でそのまま流す予定で、監査ログ要件が固まっていない
短期・低頻度タスクのみで、メモリの蓄積量が少ない
Managed Agents自体をまだ評価していない（先に基盤側を整備すべき）
自動昇格を前提にした「人手レビューなしの全自動運用」を望んでいる
Research Preview特有の挙動変更を許容できず、SLAを必要とする本番ワークロードに即時投入したい

「導入すべきか判断に迷う」という場合は、まずOutcomes（Public Beta）かMulti-agent orchestration（Public Beta）から先に評価し、Dreamingは運用が安定してから検討する順序が安全です。

よくある質問（FAQ）

Q. Claude Dreamingは無料で使えますか？

専用の追加料金はありませんが、選択モデル（Opus 4.7／Sonnet 4.6）の標準APIトークン課金が発生します。100セッションを処理するため、入力サイズに応じてコストは線形に増えます。本番投入前に小規模バッチで試算するのが公式推奨です。

Q. ChatGPT Memoryと何が違いますか？

ChatGPT Memoryは個人単位の「私についての記憶」を中心にしており、ユーザーごとに最適化されます。一方Dreamingはチーム横断の集合知整理を狙う設計で、複数エージェント・複数セッションのトランスクリプトをまとめて読み直し、整理した新しいメモリストアを生成します。用途レイヤーが異なります。

Q. 入力したセッションは削除されますか？

Dreaming中のセッションはアーカイブのみ行われ、削除はされません。事後監査のためにトランスクリプトが残るので、コンプライアンス対応上もログ追跡が可能です。

Q. Dreamの結果が気に入らない場合、元に戻せますか？

Dreamは入力メモリストアを絶対に書き換えません。出力は別IDの新メモリストアとして生成されるため、人間がレビューして採用しなければ元の運用環境はそのままです。気に入らなければ出力ストアをMemory Stores APIで削除するだけで済みます。

Q. アーカイブしたDreamは元に戻せますか？

戻せません。Anthropicはunarchive APIを提供していません。アーカイブはID指定での参照のみ可能で、デフォルト一覧からは除外されます。運用設計の段階で「戻し操作不可」を前提にしてください。

Q. 日本語のセッションでも品質は同等ですか？

公式ドキュメントには日本語セッションでのDream品質に関する具体的な言及はありません。Opus 4.7・Sonnet 4.6自体は日本語対応していますが、Dreamingの精度を保証するベンチマークは現時点で公開されていないため、自社で小規模パイロットを回して確認するのが安全です。

Q. どのモデルが対応していますか？

2026年5月時点ではclaude-opus-4-7とclaude-sonnet-4-6の2モデルのみです。Haikuや今後のリリースモデルへの拡張は未告知です。

まとめ — Claude Dreamingの導入判断軸

最後に、本記事の要点を整理します。

Claude Dreamingは、Managed Agentsの永続メモリをClaude自身に整理させる非同期ジョブ。2026年5月6日にResearch Previewで公開
入力は最大100セッション、対応モデルはOpus 4.7／Sonnet 4.6、専用追加料金はなく標準APIトークン課金
Harveyのタスク完了率6倍など強い数値が公開されているが、内部テスト・モデル切替との合算効果である点を割り引いて評価する必要あり
メモリ汚染リスクへの対策として、3層メモリ構造＋レビューゲート＋自動昇格回避が推奨パターン
Research Preview特有の挙動変更を許容できる範囲で、まずパイロット導入し、本番ワークロードへの全面投入は慎重に判断する

長期運用するエージェントを「使うほど賢くなる」資産に変えられる可能性は高い一方、リスク管理込みで運用設計を組める体制が前提となる機能です。