プロンプトを磨く時代は終わりつつある。Claude Codeを率いるBoris Cherny氏は、Fable 5を軸に「ループ」「Dynamic Workflows」「Dreaming」を組み合わせれば、セッションをまたいで品質が上がるエージェントシステムを組めると説明している。
この記事では、同氏が示した自律改善エージェントの考え方と、Claude Code上で使える3つの機能の役割を整理する。
この記事でわかること
- Fable 5が自律改善エージェントに向く理由
/loop・/goal・Dynamic Workflows・Dreamingの違いと使い分け- モデル自体は変わらなくても、システム全体の精度を上げる設計のポイント
なぜ今「ループ」なのか
これまでのエージェント活用は、人間が毎ターン指示を出す「プロンプト駆動」が中心だった。Cherny氏はAcquiredの対談で「もうClaudeにプロンプトは書かない。ループを書くのが仕事だ」と語っている。ループとは、作業の発見・割り当て・検証・繰り返しをコードや設定で固定し、人間はその設計に専念する仕組みだ。
2026年6月13日の投稿では、Cherny氏がFable 5を「自律改善エージェントシステムを動かす最強のモデル」と位置づけ、約12分のデモで具体的な組み方を紹介したと紹介されている。ここで重要なのは、単一の長いプロンプトではなく、停止条件・並列処理・メモリ整理を組み合わせた「システム設計」が主役になる点だ。
Fable 5が担う役割
Claude Fable 5は、Anthropicが2026年6月9日に公開したMythosクラスのモデルだ。公式説明では、Claude CodeやClaude Managed Agentsといったエージェント基盤（ハーネス）上で数日単位の自律作業に対応し、段階的な計画立案、サブエージェントへの委譲、成果物の自己検証が可能とされている。
発表資料では、Slay the Spireの実験でファイルベースの永続メモリを与えた際、Opus 4.8と比べてパフォーマンスが3倍改善した例が示されている。モデルの重みを書き換えるのではなく、メモリを参照しながら出力を磨き上げる「文脈内の自己改善」だ。
料金は入力100万トークンあたり10ドル、出力100万トークンあたり50ドル。ただし2026年6月12日の更新で、Fable 5へのアクセスは一時停止されている。記事執筆時点では利用可否を公式アナウンスで確認する必要がある。
3つの機能が担うレイヤー
自律改善システムは、実行ループ・大規模並列・セッション間メモリの3層で考えると整理しやすい。
/loopと/goalで回す実行ループ
/loopは、開いているClaude Codeセッション内でプロンプトを定期的に再実行するコマンドだ。5mのように間隔を指定すれば固定スケジュールで動き、間隔を省略すればClaudeが状況に応じて待ち時間を調整する。PRのCI確認やレビュー対応など、同じ型の作業を繰り返す用途に向く。
一方/goalは完了条件を設定し、条件が満たされるまでターンを重ねる。各ターン終了後、軽量モデル（デフォルトはHaiku）が条件達成を判定する。テストがすべて通る、特定ファイルの移行が完了するといった「検証可能な終了状態」に向いている。
Cherny氏が強調するのは、ループに明確な停止条件を与えることだ。/goalなしでは「だいたい終わった」時点で処理が止まり、本来の品質まで到達しない。
Dynamic Workflowsで大規模並列をコード化
Dynamic Workflowsは、Claudeがタスク用のJavaScriptオーケストレーションスクリプトを書き、ランタイムがバックグラウンドで実行する仕組みだ。2026年5月28日に一般提供され、サブエージェントを数十から数百規模で並列起動できる。
サブエージェント方式では結果が会話のコンテキストに積み上がるが、ワークフローでは中間結果をスクリプト変数に保持し、最終回答だけがコンテキストに戻る。公式ドキュメントでは同時実行は最大16エージェント、1ランあたりの合計は最大1000エージェントとされている。コードベース全体の監査や大規模マイグレーションなど、1会話では収まらない作業向けだ。
/effort ultracodeを有効にすると、Claudeがタスクごとにワークフロー計画を自動で立てる。進捗は/workflowsで確認でき、うまくいったスクリプトはコマンドとして保存して再利用できる。
Dreamingでセッション間のメモリを磨く
Dreamingは、エージェントがセッションをまたいで蓄積したメモリを整理する非同期処理だ。Claude Managed Agents向けのDreams API（研究プレビュー）では、既存のメモリストアと最大100件の過去セッションを入力に、重複の統合・矛盾の解消・陳腐化した記述の置き換えを行った新しいメモリストアを出力する。入力ストアは変更されず、レビュー後に採用するか決められる。
Anthropicの公式ブログ（2026年5月6日）では、Dreamingが単一セッションでは見えない繰り返しのミスや、チーム全体で共有されるワークフローの傾向を抽出する用途を挙げている。Harvey社のテストでは完了率が約6倍に上がった例も紹介されている。
Claude Code側にも、セッション間でメモリファイルを整理するAuto-Dream機能の実装が報じられている。/memoryから状態を確認できるが、段階的ロールアウト中で全ユーザーが使えるわけではない点に注意が必要だ。
組み合わせの設計パターン
3機能は独立ではなく、次のように役割分担する。
- Fable 5：長時間の計画・委譲・統合を担うオーケストレーター
/loopまたは/goal：セッション内で作業を止めずに回す実行エンジン- Dynamic Workflows：並列サブエージェントと検証ループをスクリプト化
- Dreaming：セッションをまたいだ学習の蒸留とメモリの鮮度維持
Anthropic社内のLance Martin氏は、Fable 5で自己修正ループを回す際は、モデル自身による自己批判より独立した検証用サブエージェントを置く方が有効だと指摘している（参考）。MakerとVerifierを分ける設計は、Dynamic Workflowsの敵対的検証パターンとも一致する。
コスト面では、Fable 5を全工程に使うより、探索や実装をSonnet・Haikuに振り、計画と最終統合だけFable 5に任せるルーティングが推奨される。Dynamic Workflowsのスクリプトはステージごとにモデルを切り替えられる。
注意点
「自律改善」と聞くとモデルが自分で学習するイメージを持ちがちだが、現行のFable 5は公開モデルの重みをセッションから更新しない。改善が起きるのは、ループによる反復、検証ルーブリック、SkillsやSTATEファイル、Dreamingによるメモリ整理といったハーネス側の設計だ。
またDynamic Workflowsはトークン消費が大きい。公式も小さなスコープで試し、/workflowsのトークン表示を見ながら停止できることを推奨している。ループ系はセッションに紐づくため、PCを閉じると/loopは止まる。常時稼働が必要ならRoutines（Anthropic管理インフラ上の定期実行）の検討が必要だ。
プロンプト職人からループ設計者へ——Cherny氏のメッセージは、Fable 5という長期推論モデルと、Claude Codeのオーケストレーション機能が揃った今だからこそ実装可能になった設計思想だ。まずは/goalで小さな完了条件を1つ決め、そこからループを回すところから始めるのが現実的な第一歩になる。