Fable 5でループを設計する

• Anthropic の内部作業方式を変えた Mythos-class モデル Claude Fable 5 をうまく活用するための2つの中核手法として、self-correction loop と memory を提示
• 適切に設計された goal・rubric が環境にフィードバックを注入し、Claude が実行→フィードバック収集→自己修正を 目標達成まで反復 する構造
• Parameter Golf ML エンジニアリング課題で、Fable 5 は Opus 4.7 と比べて学習パイプラインを 約6倍 改善
• セッションをまたぐ outer loop である memory により、Claude がセッション中に記録した内容を後続セッションで再利用
• 直接プロンプトしたり操作したりするよりも、モデルが自ら修正し文脈を管理するループ設計 が効果的だという点が核心

---

Self-correction loop（自己修正ループ）

• 評価基準の上でモデルに hillclimb させる方法は、タスク性能改善の一般的なレシピ
  • bcherny は「自分の仕事は ループを書くこと だ」と述べている
  • Claude Code の /goal、Claude Managed Agent の Outcomes は、このレシピを特定タスクに適用する primitive
• うまく設計された goal または rubric は、Claude が実行される環境にフィードバックを追加し、実行・フィードバック収集・自己修正を経て goal/rubric を満たすまで進行

Parameter Golf テスト

• Parameter Golf は、16MB artifact に収まる最高性能モデルを 8xH100 で10分以内に学習させるオープンソースの ML エンジニアリングチャレンジ
  • 単一の train_gpt.py ファイル編集、学習実行、ログのポーリング、スコア確認、次の実験の判断能力を試す
  • karpathy の autoresearch プロジェクトに類似
• Claude Managed Agents(CMA) を使って Fable 5 と Opus 4.7 を比較
  • CMA は agent harness とホスティングされた sandbox を提供し、Fable 5 の長時間タスクに適している
  • Parameter Golf には 8xH100 GPU を self-hosted sandbox として提供

採点主体の重要性

• モデルが 自分の出力に対する self-critique で問題を示すことを確認（Prithvi Rajasekaran がエンジニアリングブログで記述）
• verifier sub-agent は self-critique より優れており、独立した context window で採点が行われるため
  • CMA の Outcomes が grader sub-agent を自動生成して処理
• 9つのチェック可能な基準（baseline 実行、実験20回実施など）を含む rubric を提供し、最大8時間実行
  • Outcomes grader がすべての実験基準の充足を確認して初めて Claude の作業終了を許可

結果比較

• Fable 5 は Opus 4.7 と比べて学習パイプラインを 約6倍 改善
  • 実験を構造的（アーキテクチャ変更）とスカラー的（定数調整）に分けると、Fable 5 は より大きな構造的変更に賭け、回復力を発揮（quantization regression を突破して最大成果を達成）
• Opus 4.7 は最初の実験で小さな成果を出した後、ほぼ同じテンプレートを反復: スカラー調整・測定・良ければ維持

Memory（メモリ）

• セッションをまたぐ outer loop として、セッション中に作成した memory を後続セッションで検索・再利用
• pgasawa チームが Continual Learning Bench 1.0 を公開
  • オンライン環境で AI システムがどの程度改善するかを測定する、初の現実的ベンチマーク
  • 既存ベンチマークはモデルを stateless と仮定し、各例を独立して処理

テスト構成

• ベンチマーク課題の1つとして Fable 5・Opus 4.7・Sonnet 4.6 を比較
  • SQL database へのアクセス権を持って逐次的な質問に答える課題で、各質問は別個の agent セッションであり memory が提供される
• CMA の memory を使用し、セッション間で共有可能な mounted filesystem を各 agent に提供

効果的な memory 使用の段階

• 効果的な memory 活用は、fail（誤りを記録）・investigate（原因を把握）・verify（検証済みの事実化）・distill（一般ルール化）・consult（ルール参照） の進行を通じて強化される
• Sonnet 4.6 は1段階付近で停止
  • 保存領域は失敗メモと未解決の推測の一覧（"maybe prc instead of prc_usd?"）になっており、過去のメモをほとんど参照しない
  • 性能改善には課題別の memory 指示が必要
• Opus 4.7 は3段階付近で停止
  • 不確実性を明示した schema reference を生成（"possibly prc in cents? Verify."）するが、検証カバレッジは 7〜33% と低い（中央値は約17%）
• Fable 5 はこの進行を完了する傾向
  • 最良の実行では検証カバレッジが最大73%（30件中22件）に達し、学習内容を将来の課題に役立つ一般ルールへと distill

総合

• Fable 5 を直接プロンプトしたり操作したりするより、環境フィードバック（/goal, Outcomes）に反応して自己修正し、memory によって自ら文脈を管理するよう ループを設計する方式 のほうが効果的
• 困難な課題で自己修正・memory ループを活用し、Fable 5 を直接テストしてみることを推奨