全体像 ── 「二重のループ」という読み方
記事は「Fable 5 のような Mythos クラスのモデルは Anthropic 社内の働き方を変えた」という書き出しから始まり、このクラスのモデルを使いこなすための 2 つのコツを紹介します。共通するテーマは、モデルを信じて放置するのではなく、フィードバックが還流する「ループ」を環境側に設計することです。2 つのコツは入れ子の関係で整理できます。
※ 記事の構成（Self-correction loops / Memory の2章立て）を基にした概念図。内側ループは「実行 → ゴールやルーブリックによる評価 → 自己修正」をゴール達成まで繰り返し、外側ループは「セッション中にメモリへ書き込み、将来のセッションで取り出す」ことでセッションを越えた改善を実現します。
記事では、それぞれのループを実際の検証課題で試した結果も示されています。要点は次の 3 つです。
自己修正ループ ── Self-correction loops
背景 ── 「仕事はループを書くこと」
記事は、最近の「ループ」への関心の高まりから始まります。評価基準を与えてモデルを反復実行させ、スコアを少しずつ登らせる（ヒルクライム）のが、タスク性能改善の定番レシピになっているという文脈です。
「（自分の）仕事はループを書くことだ」（大意）
このレシピを自分のタスクに適用するための「プリミティブ（基本部品）」として、記事は Claude Code の /goal と Claude Managed Agent（CMA）の Outcomes を挙げます。よく設計されたゴールやルーブリックは、Claude が動く環境にフィードバックを追加します。その結果、Claude は「実行 → フィードバック収集 → 自己修正」をゴール達成まで自律的に続けられる──Fable 5 はこのループ内での自己修正が得意である、というのが本章の主張です。
ループの基本構造（フローチャート）
※ 記事の説明（「Claude を走らせ、ゴールやルーブリック経由でフィードバックを集め、自己修正し、満たされるまで続ける」）を基に構成。暴走防止のため、ループには必ず上限（バウンド）が設定されます。
2 つの実装 ── /goal と Outcomes（比較表）
記事には「Goal-driven loops: two implementations」という比較表が掲載されています。その要旨を再構成すると次の通りです。
| 観点 | Claude Code /goal | CMA Outcomes |
|---|---|---|
| ゴールの形式 | 測定可能な「終了状態」を定義する | 採点可能な基準を並べた「ルーブリック」を定義する |
| 採点者 | 独立したグレーダーモデル | 独立したグレーダー・サブエージェント |
| ループの駆動 | 採点の判定結果が次のターンの起点になる | 実行 → 採点 → 修正を反復する |
| 上限 | ターン数・時間の上限 | max_iterations |
| フィードバック | グレーダーモデルからの指摘 | グレーダー・サブエージェントからの指摘 |
| 終了条件 | 達成で自動クリア（手動クリアも可） | ルーブリック合格、または中断 |
※ 原記事の表を基にした再構成です。参照画像の解像度の制約上、各セルは要旨レベルでまとめています。正確な記載は原記事の表をご確認ください。
誰が採点するかが重要 ── 「自己批判」の罠（関係図）
記事が「subtle point（見落としやすい点）」として強調するのが、「何が」採点するかです。モデルは自分自身の出力への自己批判（self-critique）に問題を抱えることが知られており（Anthropic エンジニアリングブログの Prithvi Rajasekaran 氏の記事として言及）、Fable 5 では独立したコンテキストウィンドウで採点する検証サブエージェントの方が、自己批判を上回ることが分かったとしています。
※ 記事の記述「verifier sub-agent tends to outperform self-critique with Fable 5, because grading is done in an independent context window」を図式化したものです。
Outcomes の動き（シーケンス図）
※ Parameter Golf 検証時の運用（ルーブリックをファイルで供給し、Outcomes のグレーダーが全基準達成を確認するまで Claude は作業を終了できない）を基にしたシーケンスの概念図です。
検証実験 ── Parameter Golf
検証に使われたのは、オープンソースの ML エンジニアリング課題「Parameter Golf」です。お題は「8×H100 GPU で 10 分以内に訓練でき、16MB の成果物に収まる最良のモデルを作る」こと。Andrej Karpathy 氏の autoresearch プロジェクトに似た構成で、エージェントが単一の訓練コード train_gpt.py を編集し、訓練を起動し、ログを監視し、スコアを読み、次に何を実験するかを自分で決める能力を試します。実行基盤には CMA を使い、8×H100 をセルフホスト・サンドボックスとして接続しています。
※ 記事の説明「edit basic training code, launch training, poll the log, read the score, and decide what experiment to run next」を図式化。
結果 ── 約 6 倍の改善と、対照的な「賭け方」
※ 記事掲載グラフ（20 実験・val_bpb の推移）の傾向を基にした概念的な再構成です。座標値は実データではありません。正確なグラフ・数値は原記事を参照してください。
結果は Fable 5 が訓練パイプラインを Opus 4.7 の約 6 倍改善。さらに記事は、実験を「構造的（structural）」と「スカラー（scalar）」に分類し、両モデルの行動パターンの違いを分析しています。
FABLE 5構造的な変更に賭ける
- アーキテクチャ変更のような、大きな構造的変更を選ぶ
- 量子化によるリグレッション（一時的な悪化）を押し切って、最大の改善に到達する「粘り強さ」を見せた
- 結果：改善幅は Opus 4.7 の約 6 倍
OPUS 4.7スカラー調整の繰り返し
- 最初の実験で小さな改善を獲得
- 以降はほぼ同じテンプレートを反復：「定数を調整 → 測定 → 良ければ採用」
- 堅実だが、大きなジャンプは生まれにくい
メモリ ── セッションを越える外側のループ
2 つ目のテクニックはメモリです。記事はこれを「セッションをまたぐ外側のループ」と位置づけます。Claude はセッション中にメモリへ書き込み、その記憶を将来のセッションで取り出して使えます（全体像は Fig. 01 参照）。検証には、Parth Asawa 氏（@pgasawa）らが公開したばかりのベンチマークが使われました。
「AI システムがオンライン環境でどのように改善できるかを測定するための、最初の現実的なベンチマーク」
検証タスクの構造 ── 独立セッション × 共有メモリ
使われたタスクは「SQL データベースへのアクセスを与えられ、順番に出題される質問に答える」もの。ポイントは、各質問が独立したエージェントセッションとして実行されることです。会話の文脈は質問ごとにリセットされ、引き継がれるのはメモリだけ。実装には CMA のメモリ機能（セッション間で共有できるマウント済みファイルシステム）が使われています。比較対象は Fable 5・Opus 4.7・Sonnet 4.6 の 3 モデルです。
結果 ── メモリで「セッションを越えて」賢くなる
※ いずれも記事の記述（「Memory is another area where Fable excels」および掲載グラフ）の傾向を示す概念図です。実測値・正確なグラフは原記事と Continual Learning Bench 1.0 を参照してください。
メモリ活用の 4 段階（アローダイアグラム）
記事の結びでは、このタスクで効果的にメモリを使うには「段階的な進行（progression）」が有効だとして、次のステップが挙げられています。
何かを間違えたら、それを文書化する
先に進む前に、なぜ間違えたのかを突き止める
診断を「確認済みの事実」に変える
再利用できる知識へ抽出していく（…）
参照したスクリーンショットはこの説明の途中までで終わっています
まとめと示唆
記事の核は、独立した採点者を持つフィードバックループを環境側に設計することで、長時間の自律タスクの品質を担保するという設計思想です。信頼できる自律ループの成立条件は、次の 3 要素の重なりとして整理できます。
※ 記事内容（ゴール／ルーブリック、独立グレーダー、バウンド・終了条件）を基に本ページ作成者が整理した図です。
| 内側ループ ── 自己修正 | 外側ループ ── メモリ | |
|---|---|---|
| 範囲 | 1 つのセッションの中 | セッションを横断 |
| 仕組み | ゴール／ルーブリック ＋ 独立した採点者 | 共有ファイルシステムへの書き込みと読み出し |
| 使う機能 | Claude Code /goal・CMA Outcomes | CMA のメモリ機能 |
| 検証課題 | Parameter Golf（ML エンジニアリング） | Continual Learning Bench 1.0（DB 探索） |
| 結果 | Fable 5 は Opus 4.7 比で約 6 倍の改善 | Fable 5 が 3 モデル中で最高スコア |
エージェント活用の品質は「モデルの賢さ」だけでなくループの設計で決まる、というのがこの記事の実務的な含意です。長時間の自律タスクを設計するときは、(1) 合否をチェックできるルーブリックを先に合意し、(2) 採点は作業者と分離し（独立コンテキスト）、(3) 上限と終了条件を必ず置く。さらにセッションを越えて改善させたい場合は、(4) 失敗 → 調査 → 検証 → 蒸留の流れでメモリに知識を蓄積させる──という整理が、PoC 設計や提案の枠組みとしてそのまま使えます。
出典・クレジット
一次出典
- Lance Martin（@RLanceMartin・Anthropic, MTS）「Designing loops with Fable 5」── X（旧Twitter）の Articles 機能で公開された記事。2026 年 6 月 10 日閲覧。本ページの解説・図はすべて本記事の内容に基づきます。
記事内で言及・引用されている資料
- Boris Cherny 氏（@bcherny）の発言「（自分の）仕事はループを書くことだ」（大意）
- Anthropic「prompting guide」── Fable 5 がループ内での自己修正に優れるという記述の参照元
- Prithvi Rajasekaran 氏による Anthropic エンジニアリングブログ記事 ── モデルが自身の出力への自己批判を苦手とする問題について
- Parameter Golf ── オープンソースの ML エンジニアリングチャレンジ（16MB・10 分・8×H100）
- Andrej Karpathy 氏（@karpathy）の autoresearch プロジェクト ── 類似の自律実験フレームワークとして言及
- Parth Asawa 氏（@pgasawa）ほか「Continual Learning Bench 1.0」── 2026 年 5 月 5 日公開ポスト（記事内に引用）
- Anthropic 製品機能：Claude Code
/goal、Claude Managed Agents（CMA）のOutcomes・メモリ機能
【著作権に関する注記】本ページは上記記事の私的学習・社内共有を目的とした要約・解説であり、原文の全文転載はしていません。原記事のスクリーンショット・グラフ・図表は転載せず、掲載図はすべて本ページ作成者が内容理解のために独自に再構成した概念図です。グラフの形状・数値は正確な再現ではありません。引用部分は「 」で明示しています。各リンク先資料の正確な URL は原記事内のハイパーリンクを参照してください。権利者からの指摘があれば速やかに対応します。