Claude Fable 5.2 vs Opus 5.5：コーディングとエージェント作業

この4本の小さなコーディングとツール課題では、Fable 5.2 の割高分を払う価値はありませんでした。Claude Fable 5.2 と Claude Opus 5.5 はどちらも29項目のコードチェックをすべて通過し、標準料金での試算はこの4本の合計で Opus が $0.031、Fable が $0.146 でした。より難しい推論や長いエージェント実行は、Opus を高い effort で試して物足りないときに Fable を検討してください。

Fable 5.2 と Opus 5.5 の概要

Fable 5.2 のほうが新しいのですが、コンテキストはどちらも 1M トークン、最大出力は 128K トークンで同じです。今回のテストで実務上の差が出たのは、コードの正しさではなくトークンの使用量でした。

Anthropic の Fable 5.2 モデルページ と Opus 5.5 モデルページ では、どちらも利用可能で、テキストと画像の入力に対応するとされています。Fable は 2026年11月9日、Opus は 2026年9月22日に公開されました。デフォルトの effort が違うので、比較するときは両方 medium に設定してください。

Anthropic の モデル一覧 は、ほとんどのタスクで Opus 5.5 を勧めています。Fable 5.2 は、要求の厳しい推論や長時間のエージェント作業、または高い effort の Opus 5.5 の評価がなお届かない場合に向くと位置づけています。これはベンダーの位置づけで、今回のテストが扱ったのは小さな4本の課題です。

Fable 5.2 の変更点は Fable 5.2 の変更点 に、単体の記事は Opus 5.5 レビュー にまとめています。

4本の課題にいくらかかるか

Anthropic の 公式料金ページ では、Fable 5.2 が入力 $8・出力 $40（100万トークンあたり）、Opus 5.5 が $4 と $20 です（2026年11月12日時点）。Batch はどちらも半額、fast モードはどちらも2倍になります。

採点対象の4本で、Fable は入力 3,439 トークン、出力 2,954 トークンを使いました。Opus は 2,421 と 1,065 です。標準料金で計算すると次のとおりです。

• Fable: (3,439 × $8 + 2,954 × $40) ÷ 1,000,000 = $0.1457
• Opus: (2,421 × $4 + 1,065 × $20) ÷ 1,000,000 = $0.0310

これらは観測したトークンから出した標準料金の試算で、請求書の金額でも OmniaKey の請求でもありません。Opus の応答は fast 速度、Fable は standard を報告しました。Anthropic は fast の入力と出力を標準の2倍の料金としています。ここでは両方を標準料金に揃えているので、この数字は統制された時間や請求の比較ではありません。

標準料金での試算（米ドル）：

4本の平均は Fable が $0.0364、Opus が $0.0077 で、Fable の標準料金試算は4本の合計で $0.1147 高くなりました。実際の判断基準は「使える1本あたりのコスト」、つまり API の費用に再試行とレビューの時間を足したものです。実際の課題で失敗が多く、その追加費用に見合うときだけ上に移してください。この4本の小さな課題では、そこまで行きません。

実時間の合計は Fable が 27.8 秒、Opus が 43.6 秒でした。Fable の応答は standard 速度、Opus は fast を報告し、speed はどちらも指定していません。これは観測値として読み、速度の順位づけには使わないでください。

Python の修正2本：どちらも 22/22 項目

どちらの修正も短く、両モデルとも動く関数を返しました。この2つの失敗例は、ライブラリの知識ではなく revision の扱いとページングの端のケースを試すので、残しておく価値があります。

使用量の合計：新しい失敗が古い成功を打ち消す

古い関数は complete のイベントをすべて合計していました。revision も status も見ていないので、再試行でトークンが二重に数えられ、新しい failed の revision が古い complete を打ち消せませんでした。

プロンプトの中心となるルール：

Keep only the highest revision for each event_id, and on equal revisions keep the last occurrence in the input. A newer failed revision supersedes an older complete one and contributes nothing.

最小の再現は、イベント x の revision 1 が complete で 10 トークン、そのあとに同じ x の revision 2 が failed で 10 トークン、という並びです。正しい合計は 0 で、古い関数は 10 を返します。

両モデルとも、最も高い revision を残し、同じ revision なら入力で最後のものを採り、failed の勝者を飛ばし、トークン0のユーザーを残し、入力を変更しませんでした。結果： 各 8/8 項目で、関数は同等でした。

カーソルページング：同じタイムスタンプでも重複させず、欠けさせない

古い版は ts だけで並べ替え、cursor を適用する前に先頭ページを切り出し、同じタイムスタンプを <= で受け入れ、limit を検証せず、常に next cursor を返していました。ts=4 の行が2つあると、ID が重複したり欠けたりします。

プロンプトの中心となるルール：

Sort descending by (ts,id). Select rows strictly LESS than the cursor tuple, so tied timestamps neither repeat nor skip IDs. Return next_cursor only if MORE eligible rows remain. Raise ValueError unless limit is an integer from 1 through 100; bool is invalid.

両モデルともすべて直しました。(ts,id) のタプルで並べ替え、cursor より厳密に小さい行だけを選び、スライスの前に全リストを絞り込み、行が残るときだけ next cursor を返し、True、False、0、101、1.5、'2'、None を弾く検証を入れました。結果： 各 14/14 項目で、タイムスタンプが並ぶ行を1行ずつたどる確認も含みます。

非同期の台帳：数字は同じ、JSON の形が違う

両モデルとも照合は正しく、予約の純額が $0.93、t3 が保留、t1 と t5 が完了、t3 の次の一手は poll_existing でした。

課題に付けた合成のログでは、金額は例示用で OmniaKey の価格ではありません。主要な行は次のとおりです。

POST key=a => 201 task=t1 quote=0.40

POST key=a, identical body => 200 task=t1

GET t1 => SUCCEEDED

POST key=b => 201 task=t2 quote=0.40

GET t2 => FAILED

POST key=c => 201 task=t3 quote=0.13

Client stopped polling t3 after 120 seconds; last status PROCESSING

POST key=d => 201 task=t4 quote=0.13

GET t4 => CANCELED

POST key=e => 201 task=t5 quote=0.40

GET t5 => SUCCEEDED

計算は 0.40 + 0.13 + 0.40 = 0.93 です。t2 と t4 は返金、t1 と t5 は消費、t3 は予約が残ります。タスクが失敗したからではなく、クライアントがポーリングを止めたためです。

最後に観測した状態が SUCCEEDED のタスクだけを数えると、両モデルは同じ値を返しました。Fable は生の JSON を返しました。Opus は JSON を JSON のコードフェンスで包みました。プロンプトには "Return ONLY JSON" とあったので、Opus の返答にそのまま厳密な json.loads をかけると、フェンスを外すまで失敗します。これは形式だけの逸脱で、要求は JSON schema も構造化出力モードも使わない素の JSON テキストでした。結果： 値はどちらも合格です。自動化に使うなら、生の返答を厳密なパーサで検証するか、構造化出力に切り替えてください。観測した逸脱は1件で、一般的な傾向ではありません。

2ターンのファイル課題：読み取り1回、修正1回

fixture の古い remaining_quota は、すべてのイベントの units を引いていました。各 id の最後の状態も max(0, ...) の下限も見ていないので、failed や canceled のタスクも枠を消費し、同じイベントが繰り返されると二重に引かれます。

課題は次のとおりです。

Use read_file once to inspect quota.py, then return one Python code block containing only a corrected remaining_quota(limit, events) function.

両モデルとも quota.py に対して read_file をちょうど1回だけ呼びました。fixture が返ったあと、両モデルは同じ修正ロジックを返しました。各 id の最後のイベントを残し、reserved か succeeded のときだけ units を合計し、max(0, limit - consumed) を返します。結果： 各 7/7 項目で、failed のあとに reserved になる場合や上限を超える場合も含みます。

これは2ターンと1つの fixture です。モデルが正しいファイルを求めて正しく修正することを示しますが、長いエージェント実行を扱うものではありません。

テストの方法

2026年11月12日、4本の課題を claude-fable-5-2 と claude-opus-5-5 に送りました。経路は OmniaKey の Messages エンドポイントです。モデルと課題の各組み合わせで新しい会話とコールドキャッシュを使い、effort は medium、max_tokens はリクエストごとに 4096、システムプロンプトなし、temperature と top_p は未指定、試行は1回です。どちらのモデルを先に送るかは課題ごとに交互にしました。

エージェント課題では厳密な read_file ツールを1つだけ与え、tool_choice は auto にしました。それ以外は単一のユーザーメッセージです。採点スクリプトは各 Python の回答を AST で検査し、独立したプロセスで3秒のタイムアウトを付けて実行しました。使用量8件、カーソル14件、エージェント7件で、モデルあたり29件のコードケースです。どのリクエストも1回だけ実行しました。

最初の台帳プロンプトは、FAILED/CANCELED のタスクを completed_task_ids に入れるかを決めていませんでした。あいまいだったその回は、モデルごとに明確化したプロンプトで1回ずつ再実行し、最後に観測した状態が SUCCEEDED のタスクだけを数えています。元の出力は採点対象の4本の合計から外しました。

12件のリクエストはすべて HTTP 200 を返し、要求したモデル ID と一致し、end_turn、または tool_use のあと end_turn で終わり、切り詰めはありませんでした。どちらも service tier は standard でした。Fable は speed を standard と報告し、thinking トークン数を別に返しました。Opus は speed を fast と報告し、thinking トークンのフィールドがありませんでした。speed はこちらで指定していません。出力トークンには課金対象の thinking がすでに含まれるので、Opus にフィールドがないことは thinking が0という意味ではありません。

同じ effort の文字列は設定であって、揃った計算予算ではありません。この実行では effort を medium に固定しています。自分の作業では、必要な effort の水準を一通り試してください。これは小さな fixture のテストで、リポジトリ全体や長時間のエージェントのベンチマークではありません。他の課題の通過率を予測するものでもありません。OmniaKey は両モデルへのアクセスを提供しており、上の価格は Anthropic の公式定価です。

Fable を検討するとき

短く、要件がはっきりした作業は Opus 5.5 から始めてください。29項目のコードチェックはすべて Fable と同じで、Fable の標準料金試算は Opus の 4.7 倍でした。

要求の厳しい推論や長いツールのループでは、高い effort の Opus が自分の実際の課題で失敗したあとに、Fable 5.2 を次の候補にしてください。これは Anthropic の位置づけで、この実行が扱ったのは小さな4本だけです。切り替える前に、実際に失敗した10〜20件で試してください。

Anthropic の Fable 5.2 公開記事 にはベンダー報告の数字がもう1つあります。Fable 5.2 は High で FrontierCode 2.0 が 45.3%、Opus 5.5 は Max で 45.5% で、1タスクあたりのコストはおよそ半分でした。記事はまた、Fable 5.2 が Xhigh で 49.1% に達し、テストした公開済みモデルの中で最高だったとしています。これは Fable の High と Opus の Max の組み合わせで、両方 medium の今回のテストとは別の比較です。

実際のプロジェクトでは、使える1タスクあたりの API 費用に、再試行とレビューの時間を足して比べてください。小さく、すでに通っている作業なら、Opus が安い既定の選択です。

Claude Code でどちらかを使う場合、Claude Code の設定ガイド に base URL とキーの設定があります。モデルページ：Claude Fable 5.2、Claude Opus 5.5。

よくある質問

Fable 5.2 は Opus 5.5 より高いだけの価値がありますか？

高い effort の Opus が自分の課題で失敗したあとに Fable を検討し、Fable が改善するかを確かめてください。この実行では難しい課題の結論は出せません。小さな4本では、どちらも 29/29 項目を通過し、標準料金の試算は Fable が $0.1457、Opus が $0.0310 でした。

Fable 5.2 と Opus 5.5 は同じコードテストに通りましたか？

はい。使用量 8/8、カーソル 14/14、ファイル修正 7/7 をどちらも通過しました。台帳の答えもどちらも正しく、違いは形式が1点だけ、Opus が JSON のコードフェンスを付けたことです。

コーディングでは Fable 5.2 と Opus 5.5 のどちらが安いですか？

Anthropic の標準定価では Opus 5.5 です。入力が100万トークンあたり $4、出力が $20 で、Fable 5.2 は $8 と $40 です。今回のトークンでは、Fable の標準料金試算は Opus の 4.7 倍になり、4本で $0.1457 対 $0.0310 でした。

Fable 5.2 は Opus 5.5 より速いですか？

この実行では判断できません。観測した合計は Fable が 27.8 秒、Opus が 43.6 秒でしたが、Fable の応答は standard 速度、Opus は fast を報告し、speed は指定していません。同じ speed 設定でもう一度比べてください。

OmniaKey から Claude Code で両方のモデルを使えますか？

はい。この実行ではどちらのモデル ID も OmniaKey 経由で呼びました。Claude Code の設定ガイド に base URL とキーがあります。接続したら、クライアント側でモデル名を確認してください。

参照した情報源

• Anthropic：Claude Fable 5.2 モデルの概要
• Anthropic：Introducing Claude Fable 5.2 and Mythos 5.2
• Anthropic：Claude Opus 5.5 モデルの概要
• Anthropic：モデル一覧
• Anthropic：料金

すべて2026年11月12日に確認しました。