結論から言う: Anthropic が2025年5月6日にリリースした Dreaming は、エージェントがセッション間で自分の過去の会話を自律的に振り返り、パターンを抽出してメモリに書き込む仕組みだ。人間の介入なしに、エージェントが自分自身の「経験」を蓄積する。
機能概要(クイックリファレンス)
| 機能 | ステータス | 概要 |
|---|---|---|
| Dreaming | リサーチプレビュー | 過去セッションのレビュー・パターン抽出・メモリ更新 |
| Outcomes | パブリックベータ | 開発者定義のルーブリックによる自動出力評価 |
| マルチエージェントオーケストレーション | パブリックベータ | コーディネーター + 最大20並列サブエージェント |
| Webhooks | パブリックベータ | タスク完了時のプッシュ通知 |
| 料金 | 提供中 | $0.08/アクティブセッション時間 + 標準トークンコスト |
Dreaming の仕組み
従来のメモリとの違い
従来のエージェントメモリは受動的だ。開発者が明示的に「これを覚えておけ」と指示するか、ユーザーが情報を提供したときにのみ記録される。
Dreaming は異なる。セッションとセッションの間にスケジュール実行されるバックグラウンドプロセスだ。エージェントは過去の会話トランスクリプトを読み返し、以下を特定する:
- 繰り返し発生しているミス
- 効果的だったアプローチ
- 見落としていたエッジケース
そして、その知見を自分のメモリストアに書き込む。元のセッションデータは変更されない。
なぜこれが重要か
単一セッションはクロスセッションのパターンを見られない。サポートエージェントが今月12回同じ分類ミスをしていても、各セッションはそれを知らない。Dreaming はまさにそのシグナルを浮かび上がらせる。
自律性の2モード
Automatic モード:
エージェントが自分で判断 → メモリに直接書き込み
Human Review モード:
エージェントがメモリ更新案を提案 → 人間が承認 → 反映
Outcomes:評価ループの閉じ方
Dreaming が機能するには「何が良い出力か」の基準が必要だ。それを提供するのが Outcomes だ。
開発者が成功ルーブリックを定義する。すると、エージェントの推論から隔離された別の Claude インスタンスが、そのルーブリックに照らして出力を評価する。失敗した場合、グレーダーが何を変えるべきかを特定し、エージェントは基準を満たすまで反復する。
Anthropic の内部テスト結果:
- タスク成功率:標準プロンプティング比 最大10ポイント向上
- 構造化ファイル生成:.docx で +8.4%、.pptx で +10.1%
- 主観的品質(編集トーン、ブランド一貫性)にも適用可能
Outcomes と Dreaming の関係:
- Outcomes = 試験(何が失敗かを特定)
- Dreaming = エラーノート(失敗を記憶)
この2つが組み合わさることで、人間の介入なしにフィードバックループが閉じる。
マルチエージェントオーケストレーション
コーディネーターエージェントがタスクを分解し、最大20のスペシャリストサブエージェントに並列委譲する。各サブエージェントは独自のコンテキストウィンドウを持ちながら、共通のファイルシステムを共有する。
主要な仕様:
- Claude Console でフルトレース可視化
- コーディネーターはワークフロー途中でフォローアップメッセージを送信可能
- サブエージェントはやり取り間でコンテキストを保持
- オーケストレーション深度は1レベルに制限(サブ-サブエージェントは不可)
実際の導入事例:
- Harvey(リーガルAI):タスク完了率が約 6倍 に向上
- Wisedocs(文書検証):品質を維持しながらレビュー速度が 50% 改善
- Netflix:オーケストレーションされたサブエージェントで数百のビルドログを並列バッチ分析
- Spiral by Every:Haiku コーディネーター + Opus ライティングサブエージェント + Outcomes グレーダー
落とし穴と制限事項
1. Dreaming はまだリサーチプレビュー
GA ではない。本番環境への組み込みを計画している場合、ステータスの変化を追う必要がある。
2. Claude モデル専用
Managed Agents は Claude モデルのみで動作する。オーケストレーション、Dreaming、Outcomes グレーディング、すべて Claude だ。
コスト最適化や特定タスクへの適性から複数モデルを使いたい場合、Managed Agents はその層を扱わない。モデル間のルーティングが必要なアーキテクチャは別途解決する必要がある。
3. オーケストレーション深度の制限
サブ-サブエージェントは現時点で不可。複雑な階層的タスク分解が必要なユースケースでは設計上の制約になる。
4. アイドル時間は無料だが計測が必要
$0.08/アクティブセッション時間の課金は、長時間実行タスクでは積み上がる。30分のタスクはトークンコストに加えて4セントのインフラ費用がかかる。
自己改善ループの全体像
タスク分解(オーケストレーション)
↓
実行
↓
出力評価(Outcomes)
↓
クロスセッションパターン反映(Dreaming)
↓
次回タスクへの適用
これはステートレスなツールから蓄積するシステムへのシフトだ。エージェントの競争優位は、もはやプロンプトやモデルだけではない。どれだけ長く稼働し、何を学んだかが差になる。
参考リンク
Author: Jessie, EvoLink
マルチモデル構成でエージェントを構築している場合は EvoLink が Claude、DeepSeek、GPT などへの統合ゲートウェイを提供している。
