Fable 5 を活用した「ループ」の設計術

Claude Fable 5のようなMythosクラスのモデルは、私たちアンソロピック（Anthropic）の多くのメンバーの働き方を劇的に変えました。今回は、このクラスのモデルを最大限に活用するための2つのヒントをご紹介します。

1. 自己修正ループ（Self-correction loops）

最近、ループ（繰り返し処理）への注目が高まっています。同僚の @bcherny は「（自分の）仕事はループを書くことだ」とまで言っています。評価指標に基づいてモデルに試行錯誤（ヒルクライム）をさせるのは、タスクのパフォーマンスを向上させるための王道の手法です。Claude Codeの /goal 機能や、Claude Managed Agentの「Outcomes」は、この一般的な手法を特定のタスクに適用できるようにするための基本要素です。

プロンプティングガイドでも触れている通り、Fable 5はループ内での自己修正に非常に優れています。適切に設計された「ゴール（目標）」や「ルーブリック（評価基準）」を設定することで、Claudeが動作する環境にフィードバックが加わります。これにより、Claudeは実行、ゴールや評価基準によるフィードバックの収集、自己修正、そしてゴールが達成されるまでの進行というプロセスを自律的に繰り返すことができます。

私がFableのテストに使った簡単な例を紹介しましょう。「Parameter Golf」というオープンソースのMLエンジニアリング・チャレンジです。これは、8基のH100 GPUを使用し、10分以内で16MBの容量に収まる最適なモデルをトレーニングするというものです。

これは @karpathy の「autoresearch」プロジェクトに似ており、エージェントが基本的なトレーニングコード（1つの train_gpt.py ファイル）を編集し、トレーニングを開始し、ログを監視し、スコアを読み取って、次にどの実験を行うかを決定する能力をテストします。

私は、Claude Managed Agents (CMA) を使用して、このチャレンジで Fable 5 と Opus 4.7 を比較しました。CMAはエージェントを動かす仕組みとホストされたサンドボックスを提供するため、Fable 5による長時間のタスクに適しています。Parameter Golfでは、セルフホストのサンドボックスとして8基のH100 GPUへのアクセスをCMAに与えました。

ここで重要なポイントが一つあります。それは「何が判定を下すか」です。モデルが自分自身の出力に対して自己批判を行う際、いくつかの問題が生じることがわかっています。これについては、Prithvi Rajasekaranがエンジニアリングブログで解説しています。

Fable 5では、自己批判よりも「検証用サブエージェント（verifier sub-agent）」を立てる方がパフォーマンスが高くなる傾向にあります。これは、採点が独立したコンテキストウィンドウで行われるためです。CMAの「Outcomes」機能は、ユーザーに代わって採点用のサブエージェントを生成することで、この処理を自動的に処理します。

各テストにおいて、私は9つのチェック項目（例：ベースラインの実行、20回の実験の実施など）を含むルーブリック（ファイル）を提供しました。その上で、Parameter Golfを最大8時間実行させました。Outcomesの採点エージェントは、Claudeが作業を終了することを許可する前に、すべての実験基準が満たされていることを確認しました。

結果として、Fable 5はOpus 4.7よりも約6倍、トレーニングパイプラインを改善しました。実験を「構造的（アーキテクチャの変更など）」なものと「スカラー的（定数の調整など）」なものに分けると、Fable 5はより大きな構造的変化に賭け、レジリエンス（回復力）を示しました（例：量子化による一時的な精度低下を乗り越え、最終的に最大の成果を出すなど）。 対照的に、Opus 4.7の最初の実験は小さな成功を収めましたが、その後のほとんどは「数値を調整し、測定し、良ければ維持する」という同じパターンの繰り返しでした。

2. メモリ（Memory）

メモリもまた、Fableが秀でている領域です。これは、複数のセッションをまたぐ「外側のループ」と考えることができます。Claudeがあるセッションでメモリに書き込み、その内容を将来のセッションで取り出すという形です。

@pgasawa とそのチームが最近「Continual Learning Bench 1.0」を公開したので、これをFable 5と以前のモデルでテストしてみたいと考えました。

Parth Asawa (@pgasawa) ・ 5月5日 本日、Continual Learning Bench 1.0をリリースします。これは、AIシステムがオンライン環境でどのように学習・改善できるかを測定するための、初めての現実的なベンチマークです。 現在のベンチマークは、モデルが「ステートレス（状態を持たない）」であることを前提としています。各例題は独立しており、システムがタスクを終えると、まるで……（さらに表示）

私は、Fable 5、Opus 4.7、Sonnet 4.6をこのベンチマークのタスクの一つで比較しました。このタスクは、SQLデータベースへのアクセス権を与えられたエージェントに一連の質問に答えさせるものです。各質問は個別のエージェントセッションであり、メモリ機能が提供されます。

ここでは、セッション間で共有可能なファイルシステムにアクセスできる「メモリ機能付きCMA」を使用しました。 このタスクにおいてメモリを効果的に使うには、次のような段階的なプロセスが求められます：

1. 失敗（間違いを犯し、それを記録する）
2. 調査（次へ進む前に、なぜ間違えたか原因を突き止める）
3. 検証（診断結果を、確認済みの事実へと変える）
4. 抽出（検証結果を、一般的なルールに落とし込む）
5. 参照（再度イチから考えるのではなく、そのルールを読み込む）

Sonnet 4.6は、ステップ1あたりで脱落します。その記録は失敗のメモやあやふやな推測（例：「prcではなくprc_usdかも？」）の羅列になり、以前のメモを参照することは稀です。パフォーマンスを上げるには、タスク固有のメモリ指示が必要になります。

Opus 4.7は、ステップ3あたりで止まります。不確実な点にフラグを立てたスキーマ参照（例：「prcはセント単位の可能性あり。要確認」）を作成しますが、検証の網羅率は低く、質問の7〜33%にとどまりました（中央値は約17%）。

Fable 5は、このプロセスを最後までやり遂げる傾向があります。最も優れた実行結果では、検証網羅率は73%（30問中22問）に達し、学んだ内容を将来のタスクに役立つ一般的なルールへと抽出していました。

まとめ

Fable 5を直接プロンプトで細かくコントロールしようとするよりも、環境からのフィードバック（/goalやOutcomesなど）に応じてモデルが自己修正し、自らコンテキストを管理（メモリ経由など）できるような「ループ」を設計する方が、多くの場合で良い結果が得られます。

今回ご紹介したのは私が行った小規模な実験のいくつかに過ぎませんが、難しいタスクでFable 5を試し、自己修正やメモリのためのループを活用してみる価値は十分にあります。

詳細については当社のドキュメントを参照するか、最新バージョンのClaude Codeに尋ねてみてください。組み込みの /claude-api スキルを使って、Fable 5（プロンプティングのベストプラクティスなど）、/goal、Claude Managed Agents、その他のAPI機能について教えてくれるはずです。