投稿者 投稿日: カテゴリー Claude
Dreamingとは、過去セッションを振り返り記憶を整理する機能のことです。
本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづいて解説します。
DreamingとOutcomesは「Claude Codeの新機能」として日本語圏で紹介されがちですが、Anthropicの公式発表（2026年5月6日）を読むと、この2つが載っているのはClaude Codeではなく Claude Managed Agents というマネージド型エージェント基盤のほうです。ここを取り違えたまま社内で導入計画を立てると、自社の環境からは触れない機能の稟議を書くことになります。この記事では公式ブログと開発者向けドキュメントで確認できた仕様だけを使って両機能を整理し、商品説明文の一括生成、レビュー返信、在庫アラート整理という日次業務にどう落ちるのかを具体化します。すぐ使えるルーブリックと指示文のひな形を5本置きました。
DreamingとOutcomesは、そもそもどの製品の機能なのか
結論として、この2機能は2026年5月6日にClaude Platform上の Claude Managed Agents 向けとして公開されたものです。公式ブログの表題自体が「New in Claude Managed Agents」であり、Claude Codeの告知ではありません。理由は提供形態にあります。Managed Agentsは、エージェントの実行環境（サンドボックス）、セッション、メモリストアをAnthropic側が抱え込む構成で、DreamingもOutcomesもその実行基盤の上に乗ります。手元のターミナルで動くClaude Codeとは、そもそも動く場所が違います。
提供ステータスも2系統です。Dreamingはリサーチプレビューで、申請フォームからアクセス権をリクエストした開発者だけが触れる段階です。Outcomes、マルチエージェント・オーケストレーション、メモリはパブリックベータとして開発者に開放されています。APIリクエストには managed-agents-2026-04-01 のベータヘッダーが要り、Dreamingにはさらに dreaming-2026-04-21 が上乗せされます。今日から全ユーザーが使える一般提供機能ではなく、開発者が自社システムに組み込む前提の部品です。
ではClaude Codeと無関係かというと、そうでもありません。AnthropicのClaude Code向け公式解説（2026年7月22日）は、Claude Codeで組める検証ループの選択肢のひとつに「Rubrics in Claude Managed Agents（ベータ）」を挙げています。別のgraderエージェントが成果物の合否を判定し、不合格なら自動で手戻りさせる仕組み、という説明です。Claude Code側では /verify スキルやリンターの終了コードで検証ループを組み、より重い合否判定が要るときにManaged Agentsのルーブリックへ寄せる。この住み分けが公式に案内されています。
Claude Code本体にDreamingが搭載されたという公式アナウンスは、2026年8月3日時点で確認できませんでした。同時期のClaude Code側のアップデートは、4月14日のroutines、5月28日のdynamic workflowsという別系統の機能です。本記事で「Claude Codeでdreamingが使える」と書かないのはこのためで、今後変わる可能性がある点は要確認としておきます。
記憶と合否判定という2つの穴が、EC運用のどこで開いているか
エージェントに日次業務を任せたときに壊れるのは、たいてい「前回の学びが残らない」ことと「良し悪しを自分で判定できない」ことの2点です。DreamingとOutcomesは、この2つにそれぞれ対応します。
Outcomesは合否判定の担当です。公式ドキュメントによると、使う側はマークダウンで書いたルーブリック（採点基準）を渡し、エージェントはその基準を満たす方向へ作業します。ルーブリックは必須項目で、セッションに user.define_outcome イベントを送ると成果物を採点するgraderが自動で立ち上がります。graderはメインのエージェントとは別のコンテキストウィンドウで動くため、エージェント自身の実装判断に引きずられません。基準を満たしていなければ、graderは基準ごとの内訳で足りない箇所を返し、その指摘を持ってエージェントが次の反復に入ります。反復回数は max_iterations で指定でき、既定値は3、上限は20。評価結果は satisfied、needs_revision、max_iterations_reached、failed、interrupted の5種類です。
Anthropicが公表している数字は3つです。標準的なプロンプトループと比べてタスク成功率が最大10ポイント改善したこと、社内ベンチマークでdocx生成が8.4ポイント、pptx生成が10.1ポイント改善したこと。難しい問題ほど伸び幅が大きかった、とも書かれています。導入事例では、文書品質チェックのエージェントを構築したWisedocsが、Outcomesで社内ガイドラインに沿った採点を回すことでレビュー処理を50%高速化したと紹介されています。
Dreamingは記憶の担当です。公式ドキュメントでは、エージェントが作業しながらメモリストアに書き込む内容は局所的かつ逐次的で、セッションを重ねるほど重複・矛盾・古い記述が溜まると課題設定されています。dreamは非同期ジョブで、入力に既存のメモリストア1つと過去セッション1〜100件を取り、重複を統合し、矛盾する記述を最新の値に置き換え、新しい洞察を加えた別のメモリストアを出力します。入力側のストアは書き換えられないので、出力を読んでから採用するか捨てるかを決められます。処理時間は数分から数十分、instructions による方向づけは4,096文字まで。課金は選んだモデルの通常のAPIトークン単価です。
事例としては、リーガルAIのHarveyがManaged Agentsで長文ドラフティングや文書作成を回しており、Dreamingによってファイル形式ごとの回避策やツール固有のパターンをセッション間で覚えるようになった結果、自社テストで完了率が約6倍に伸びたと紹介されています。この6倍はHarveyの自社テストの数字で、汎用ベンチマークの値ではありません。
EC運用に置き換えると、対応関係は素直です。商品説明文の一括生成やレビュー返信の下書きは「合格ラインを言葉にできるが、毎回人が読んで直している」典型なのでOutcomes向き。毎晩の在庫アラート整理や、季節商材の切り替えでどのSKUが荒れるかという知識は「同じ判断を繰り返しているのにエージェント側に残らない」典型なのでDreaming向きです。128kトークン出力を使った商品説明文の一括生成や1Mコンテキストでの全商品CSV棚卸しのように、一度に読ませる量や吐かせる量で殴る手法とは補完関係にあります。量で処理しても、翌日には忘れているのが従来の弱点でした。
なお、dreamingパイプラインで選べるモデルとして公式ドキュメントに列挙されているのは、2026年8月3日に確認した時点で claude-opus-4-8、claude-opus-4-7、claude-sonnet-4-6 の3つです。2026年7月24日に公開されたClaude Opus 5が対応済みかどうかは記載を見つけられなかったため、要確認としておきます。
EC業務に配るルーブリックと指示文5本
ここからは実装パートです。配るひな形は5本で、内訳はOutcomes用のルーブリックが3本、Dreaming用の指示文が1本、Claude Codeで検証ループを組むためのSKILL.mdが1本になります。{ } で囲んだ箇所を自店の値に置き換えて使ってください。
1本目は商品説明文の一括生成です。現場で繰り返し見るのは、生成そのものより「薬機法・景表法に触れる表現が混ざっていないかの目視チェック」で工数が溶けているパターンでした。ここをgraderに移すと、人が読む対象を合格した原稿だけに絞れます。
# 商品説明文ルーブリック（{ジャンル}／{媒体}）
## 表現規制
- 医薬品的な効能効果を断定する記述がない（例：シミが消える、体質が変わる、飲むだけで変わる）
- 最大級表現と順位表現がない（例：日本一、他店より安い、業界初）
- 体験談の形式を借りた効能訴求がない
- 打消し表示が要る訴求には、同一画面内に読める大きさの注記がある
## 事実性
- 素材・産地・容量・保存方法は、渡した商品マスタの値とすべて一致している
- マスタに無い情報を新しく足していない
- 数値には単位が付いている（g、ml、cm、日、円）
## 媒体仕様
- {媒体}の商品説明フィールドの文字数上限を超えていない
- 冒頭120字以内に主要キーワード「{第1KW}」が1回入っている
- 同じキーワードを4回以上繰り返していない
## 出力形式
- 商品管理番号ごとに1ブロック、見出しと本文を分けて出力している
- 全件を1つのCSVにまとめ、列は 商品管理番号／見出し／本文 の3列とする
2本目はレビュー返信の下書きです。ある食品ジャンルの中規模店舗の事例では、AIに返信文を書かせた初月に「どの返信も同じ書き出し」という指摘が入りました。テンプレ化を防ぐ基準は、graderに採点させると機能します。楽天RMSのレビュー一覧から書き出したCSVを渡す運用を想定しています。
# レビュー返信ルーブリック（{店舗名}）
## 個別性
- 返信ごとに書き出しの1文が異なる（同一バッチ内で書き出しの重複がゼロ）
- レビュー本文に出てくる固有の要素（商品名、使った場面、家族構成、季節）を1つ以上引用している
- 定型の謝辞だけで終わっている返信が1件もない
## 内容
- 低評価レビューには、原因の推測と次の行動（交換、問い合わせ窓口の案内）が入っている
- 高評価レビューには、関連する自店の別商品に触れてよいが、購入を急かす表現は入れない
- 効能効果の断定、他店比較、価格の優位性の主張を含まない
## 分量と文体
- 1件あたり120〜200字
- ですます調で統一し、感嘆符は1件につき1つまで
- 顔文字と絵文字を使わない
## 出力形式
- レビューIDと返信本文の2列で出力する
- 判断に迷った返信には、末尾に「要人手」のフラグを立てる
3本目は楽天RMSの商品名です。楽天市場の商品名フィールドは半角255文字（全角換算127文字）、商品キャッチコピーは半角174文字（全角換算87文字）という上限があり、この枠のなかでSGS（楽天市場の検索アルゴリズム）に乗る語順を作る作業は、人がやると1商品5分では終わりません。
# 楽天RMS商品名ルーブリック（{ジャンル}）
## 文字数
- 商品名は半角255文字（全角換算127文字）以内
- 商品キャッチコピーは半角174文字（全角換算87文字）以内
- 商品名の前半30字以内にターゲットKW「{第1KW}」が1つ入っている
## 構成
- 前半：ターゲットKW＋ジャンル語
- 中盤：訴求語（実績のあるもののみ。受賞歴・送料条件・ギフト対応）
- 後半：型番、容量、色、入数
## 規約
- 楽天市場の出店規約で禁止される最大級表現を含まない
- 同一キーワードを3回以上繰り返さない
- 記号の連続使用（★★★など）を含まない
## 出力形式
- 1商品につき候補を5案、それぞれ想定検索意図を1行で添える
- 候補ごとに全角換算の文字数を数値で併記する
4本目はDreamingの指示文です。在庫アラートの整理を毎晩エージェントに回していると、メモリストアに「この商品は欠品しやすい」というメモが日ごとに積み重なり、矛盾したまま太っていきます。dreamに渡す instructions で、残す軸と捨てる軸を明示します。
このメモリストアは、{店舗名}の在庫アラート整理エージェントが夜間に書き溜めたものです。
残すもの：
- SKU単位で再現した欠品パターン（季節、曜日、キャンペーン連動、同梱セットとの共食い）
- 発注リードタイムの実測値と、仕入先ごとのぶれ幅
- 「この条件のときは自動発注せず人に上げる」という例外ルール
- 商品マスタ側の不備（入数の誤登録、単位違い）で誤アラートが出た事例
統合するもの：
- 同じSKUについて日付違いで重複している記述は、最新の値を残して1件にまとめる
- 「欠品しやすい」といった曖昧な表現は、観測回数と期間を伴う記述に書き換える
捨てるもの：
- その日限りのAPIエラーやタイムアウトの記録
- すでに廃番になったSKUの記述
- 同じ内容を言い換えただけの記述
出力の構造：
- 「SKU別の欠品傾向」「仕入先別リードタイム」「例外ルール」「マスタ不備の既知パターン」の4見出しに整理する
5本目は、Managed Agentsのアクセス権をまだ持っていない店舗向けの現実解です。Claude Code側で同じ発想の検証ループを組みます。プロジェクト直下の .claude/skills/ にマークダウンを置くだけで、毎回同じチェックが走ります。商品説明文を生成するスキルの末尾からこのスキルを呼び出す連鎖の形にすると、生成と検査が1コマンドでつながります。
# .claude/skills/verify-yakkihou/SKILL.md
---
name: verify-yakkihou
description: 生成した商品説明文に薬機法・景表法上の危険表現が混ざっていないか検査する。商品説明文・LP原稿・メルマガ本文を書いた直後に使う。
allowed-tools: [Read, Edit, Grep]
---
直前に生成した原稿ファイルを読み込みます。
以下の観点で1文ずつ判定し、該当する文をファイル名と行番号つきで列挙してください。
1. 医薬品的な効能効果の断定（身体の機能や構造を変えると読める記述）
2. 最大級表現・順位表現（一番、日本一、業界初、他店より安い）
3. 打消し表示が要る訴求に注記が付いていない箇所
4. 商品マスタに無い数値や産地の記述
列挙が終わったら、各該当箇所を規制に触れない表現へ書き換え、
書き換え前後を対比した一覧を最後に出力してください。
判断が割れる表現は書き換えず、「要人手」として残してください。
導入して転ぶ3パターンと回避策
最初につまずくのは、ルーブリックが感想文になっているケースです。「読みやすい文章にする」「ブランドらしさを守る」と書いてもgraderは採点できず、タスクの説明とルーブリックが噛み合っていないと判定されればfailedで返ってきます。回避策は、1基準を1行にして、数えられる語か、あるかないかで答えられる語に落とすこと。「読みやすい」は「1文60字以内」に、「ブランドらしさ」は「一人称は当店とする」「感嘆符は1件1つまで」に翻訳します。編集部で運用しているルーブリックも、抽象語を潰した結果、当初の倍近い行数になりました。
次に多いのが、反復回数の設定でコストが膨らむケースです。max_iterations は上限20まで指定できますが、20回粘る設定を全商品に適用すると、graderの評価ぶんも含めてトークン消費が跳ね上がります。既定値の3から始めて、needs_revisionで止まる比率を見てから上げるのが安全です。直近の支援案件で観測したのは、ルーブリックの精度が低いまま反復だけ増やしても、同じ指摘を繰り返して反復回数を使い切るという結果でした。反復回数はルーブリックの品質を補ってくれません。
3つ目は、Dreamingの出力ストアを検証せずに本番へ差し替えるパターンです。dreamは入力ストアを書き換えない設計なので、出力側を読んでから採用を決められます。この安全弁を使わず、完了したら自動で差し替える運用にすると、統合の過程で落ちた例外ルールに後から気づくことになります。運用初期は、出力ストアをコンソールで開き、「例外ルール」の見出しだけでも人が読む手順を残しておくのが無難です。
薬機法や景表法の最終責任が店舗側にある点も確認しておきます。graderが合格を出した原稿でも、規制の解釈が変わればリスクは店舗に残ります。ルーブリックは人の目を減らす道具であり、法務判断を肩代わりする仕組みではありません。
KPIと費用・工数の見積もり方
KPIは差し戻し率から取るのが実務的です。Outcomesを入れる前に、生成した原稿のうち人が直した比率を2週間分だけ手で数えておきます。この比率が導入後にどこまで下がったかが、そのまま効果の指標になります。公開値を参考にするなら、Anthropicの社内ベンチマークでdocx生成が8.4ポイント、pptx生成が10.1ポイント、標準的なプロンプトループ比でタスク成功率が最大10ポイントという水準です。日本語の商品説明文で同じ伸びが再現するとは限らないため、自店の数字で測り直す前提で置いてください。
工数の見立ては業務の性質で分かれます。商品説明文のように合格ラインを言語化しやすい業務は、初回にルーブリックを書く時間として半日から1日を見ておけば、あとは人が読む対象が合格原稿だけになります。レビュー返信のように判断が割れる業務では、「要人手」フラグの比率が2割前後に落ち着くまでルーブリックを育てる期間が要り、現場感覚では3〜4週間かかるケースが多い印象です。
費用面で押さえるべきは、Managed Agentsの課金がAPIのトークン単価で走る点です。ClaudeのProプランやMaxプランの月額とは別の財布になります。dreamの課金は選択したモデルの通常単価で、入力セッションの本数と長さにおおむね比例。ドキュメントも「少数のセッションから始めて、整理の質に納得してから増やす」ことを勧めています。Outcomesはgraderが別コンテキストで走るぶんトークンが増える構造なので、予算は生成側と採点側の2本立てで見積もってください。
モデル選択でコストが動く点も無視できません。Claude Sonnet 5の導入価格は100万トークンあたり入力2米ドル・出力10米ドルとされ、2026年8月31日までの適用と公表されています（公開情報ベース、要確認）。値下げの影響はOpus 5のトークン単価とEC運用コストで整理してあり、日次ルーティンをどこまでAIに寄せるかという設計思想はClaude Maxのデフォルトモデル変更とEC日次業務で扱っています。
2026年後半に向けた読み筋
同じ発表に含まれていたマルチエージェント・オーケストレーションと合わせて読むと、この3機能が向かう先が見えてきます。リードエージェントが仕事を分割し、専門エージェントがそれぞれ別のモデル・プロンプト・ツールを持って並行作業し、共有ファイルシステムに成果を書く。Netflixのプラットフォームチームは、数百件のビルドのログを並列に分析し、多数のアプリで再発する問題だけを浮かび上がらせる用途に使っています。Every社のSpiralは、リードをHaikuで動かして受付を担当させ、執筆はOpusのサブエージェントに投げ、Outcomesで編集方針と文体に照らして採点し、基準を超えた原稿だけ返す構成です。
この形はEC運営にそのまま写せます。楽天担当、Amazon担当、Shopify担当のサブエージェントを立て、リードが「今週の値付け変更を3媒体に反映する」という仕事を割り振る。媒体ごとに文字数上限も規約も違うので、専門エージェントに媒体固有のルーブリックを持たせるほうが、1つのエージェントに全媒体の制約を詰め込むより素直です。楽天RMSの商品登録画面、Amazon Seller Centralの商品名と箇条書きと検索キーワード、Shopify Adminの商品タイトルとハンドル。仕様を別のエージェントの責任範囲に切ると、片方の制約がもう片方に漏れる事故が減ります。
より本質的な変化は、店舗の暗黙知の置き場所が変わることだと考えています。「うちの商品説明はこう書く」という基準は、これまでベテラン担当者の頭の中と、社内チャットに散らばった指摘の履歴にありました。Outcomesを使えばその基準は読めるルーブリックになり、Dreamingを使えば判断の履歴が整理されたメモリストアになります。担当者が異動しても基準が残る効果のほうが、生産性向上より大きいケースもあるはずです。5,000社支援の中で何度も再現したパターンとして、業務が属人化している店舗ほど、AI導入で最初に詰まるのは「そもそも正解を言葉にできない」という壁でした。ルーブリックを書く作業は、その壁を正面から崩す作業でもあります。
慎重に見る点もあります。Dreamingはリサーチプレビューで、対応モデルや上限は変わりうる段階です。入力セッションは1回のdreamにつき100件までなので、1年分をまとめて振り返らせる使い方は現時点ではできません。月次で区切って回し、出力ストアを次月の入力にする運用設計が要ります。日本語環境での挙動は公開情報が乏しく、自社で小さく試して確かめる以外にありません。
よくある質問
Claude Codeの契約だけでDreamingとOutcomesは使えますか
いいえ、使えません。この2機能はClaude Platform上のClaude Managed Agentsで提供され、APIを介した開発が前提だからです。Outcomesはパブリックベータとして開発者に開放されていますが、Dreamingはリサーチプレビューで、Anthropicの申請フォームからアクセス権をリクエストする必要があります。Claude Codeユーザーが同じ発想を手元で再現するなら、.claude/skills/ に検証用のスキルを置いて検証ループを組む方法が公式に案内されています。
ルーブリックはどのくらいの分量で書けばよいですか
ルーブリックとは、成果物の合否を基準ごとに判定するためのマークダウン文書のことです。公式ドキュメントの例では、見出しごとに3〜5行の基準が並び、全体で12前後の基準になっています。分量そのものより、1つの基準が数えられるか、あるかないかで答えられるかのほうが効きます。最初は10行程度から始めて、graderが見落とした論点を追記していく育て方が現実的です。
反復回数は何回に設定するのが安全ですか
既定値の3から始めるのが安全です。max_iterations は最大20まで指定できますが、反復のたびにエージェント側とgrader側の両方でトークンを消費するためです。needs_revisionで終わる比率が高いときは、反復回数を増やす前にルーブリックの記述を見直してください。同じ指摘が繰り返される場合、基準の書き方が曖昧なことが原因のケースがほとんどです。
Dreamingを回すと元のメモリが壊れませんか
いいえ、壊れません。dreamは入力に受け取ったメモリストアを変更せず、整理結果を別の出力ストアとして作る設計だからです。出力ストアはワークスペース内の通常のメモリストアとして扱えるので、内容を読んでから次のセッションに接続するか、不要なら削除やアーカイブができます。処理が失敗した場合も、出力ストアはそこまでの内容を保持したまま残ります。
楽天のメルマガ運用にもOutcomesを使えますか
使えますが、楽天市場内で完結する内容に限定してください。楽天R-Mailの本文に自社サイトやSNSなど楽天市場外のURLを載せる運用は出店規約に反するため、ルーブリック側で「外部URLを含まない」を基準として明記しておくのが安全です。件名の文字数設計、配信セグメントの切り分け、楽天市場内の別商品ページへの導線といった、規約の範囲で意味のある改善に絞って基準を書いてください。
費用はどのくらいかかりますか
Managed Agentsの利用料は、選択したモデルのAPIトークン単価で計算されます。dreamの費用は入力セッションの本数と長さにおおむね比例するとドキュメントに記載があり、少数のセッションから試すことが推奨されています。Outcomesはgraderが別コンテキストで動くぶん、通常セッションよりトークン消費が増えます。ProプランやMaxプランの月額とは別建ての課金になる点に注意してください。
導入の最初の一歩は何をすればよいですか
自店で「毎回同じ指摘をしている業務」を1つ書き出すことから始めてください。商品説明文の表現チェック、レビュー返信の書き出し、値付け反映の抜け漏れ確認など、人が手戻りを出している箇所がそのままルーブリックの原型になります。その指摘リストを10行程度のマークダウンに整えれば、Managed Agentsでも、Claude Code側のスキルでも同じ内容を使い回せます。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
参考文献
- Anthropic／New in Claude Managed Agents: dreaming, outcomes, and multiagent orchestration（2026年5月6日）
- Claude Platform Docs／Dreams
- Claude Platform Docs／Define outcomes
- Anthropic／Building verification loops in Claude Code with skills（2026年7月22日）
- Claude Platform Docs／Multi-agent sessions
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
