GPT-6 Astra vs Claude Fable 5.1 — 同じ$10/$50なのに請求書が変わる3つの理由

問いの設定：表示価格が同じ2モデルを、どう選び分けるか

2026年9月1日に Claude Fable 5.1、その2日後の9月3日に GPT-6 Astra が出ました。 そして両者の料金は入力$10 / 出力$50 per MTok で完全に一致しています。 コンテキストはどちらも約1Mトークン、最大出力は128K。カタログスペックの上では、選ぶ手がかりがほとんどありません。

さらに厄介なのは、第三者の総合指標でも決着がつかないことです。 Artificial Analysis（以下AA）のIntelligence Index v4.3では、両モデルの最大構成が53対53で並びます。 ベンダー公表のベンチマークは自社有利に並ぶのが常ですが、独立指標で同点というのは「どちらでもいい」を意味しません。 実際には、同じ表示価格で同じスコアなのに、請求書は2倍以上変わります。

この記事では、その差がどこから来るのかを①トークン消費量 ②キャッシュ単価 ③272Kの長文料金の3点で分解し、 そのうえでAPI制約・安全性の違い、そして「どのワークロードをどちらに流すか」というルーティング設計まで整理します。 結論を先に書くと、単発の難問はAstra、キャッシュを温め続ける長時間エージェントと超長文はFable 5.1です。

スペックと料金：同じ表示価格、違う請求書

まず全体像です。表示価格が一致する一方で、キャッシュ読み取りと長文料金という2つの「見えにくい欄」で構造が違います。

この表で実務上いちばん効くのは最後から2番目の行、データ保持です。 Fable 5.1は「Covered Model」に分類され、30日間のデータ保持が有効なワークスペースからしか呼べません。 Zero Data Retention（ZDR）を契約要件にしている組織では、そもそもFable 5.1が選択肢に入らないため、比較の前に確認が必要です。

ベンチマーク：勝敗が綺麗に分かれる

ベンダー公表値：数学・操作・サイバーはAstra、深い推論はFable

両社の公表値と第三者集計を並べると、領域ごとにはっきり勝ち負けが決まるのが分かります。 Astraが取るのは研究レベルの数学、画面操作、サイバー能力。Fable 5.1が取るのはツールを使った難問、科学コード、長文からの情報接続です。

差が大きいのは FrontierMath Tier 4（97.6% 対 87.8%）と ExploitBench（100% 対 70%）で、いずれもAstraが約10〜30ポイント上です。 逆に Humanity's Last Exam（ツールあり） では57.2% 対 65.0%とFable 5.1が8ポイント近く上回ります。 エージェントコーディングの Terminal-Bench 4.0 は57.7% 対 55.8%で、実質的に差がありません。

第三者の内訳：総合53対53の中身は非対称

AAのIntelligence Index v4.3は10個の評価の合成です。最大構成での総合は53対53の同点ですが、内訳を開くと得意分野が真逆だと分かります。

読み取れる構図はこうです。Astraは「手を動かす」評価（AutomationBench、Terminal-Bench、PDF読解）で勝ち、Fable 5.1は「考え込む・読み込む」評価（GDPval、SciCode、HLE、長文推論）で勝つ。 総合が同点なのは強みが打ち消し合っているだけで、「どちらでも同じ結果が出る」わけではありません。 自分のワークロードがどちらの列に近いかを見て選ぶのが、総合スコアを見るより確実です。

実コスト：表示価格が同じでも請求書は2倍以上ひらく

ここが本題です。AAの計測では、Intelligence Indexの1タスクあたりのコストがAstra $3.26、Fable 5.1 $7.63と2.3倍の差になります。 同じ$10 / $50なのにこうなる理由は3つあり、しかも3つの向きは同じではありません。

理由①：1タスクの出力トークンが27k対78k（Astra有利）

最大の要因はトークン消費量です。AAの計測では、同じスコアを出すために使う出力トークンが、Astraは1タスク27k、Fable 5.1は78kと約2.9倍違います。 内訳のうち推論トークンが17k対47kで、差の大半はここです。 出力単価が同じ$50 per MTokなら、出力トークンの差はそのままコスト差になります。

ただし速度は逆です。出力速度はFable 5.1が69トークン/秒、Astraが56トークン/秒でFable 5.1が上回ります。 それでも1タスクを終えるまでの総トークン数が3倍近く違うため、エンドツーエンドの応答時間はFable 5.1のほうが短い（AA計測で約283秒 対 約331秒）という結果になります。 つまりAstraは「トークン単位では速くないが、少ないトークンで済ませる」、Fable 5.1は「たくさん考えるが、吐き出すのは速い」という性格差です。

理由②：キャッシュ読み取りが4倍差（Fable 5.1有利）

逆向きに効くのがキャッシュです。キャッシュ読み取りはAstraが$1.00、Fable 5.1が$0.25で4倍違います。 他のClaudeモデルは基本入力の0.1倍ですが、Fable 5.1だけ0.025倍まで下がっています。

これが効くのは、長いプレフィックスを何十回も読み直すエージェントループです。 具体的に計算してみます。1セッション50ターン、毎ターンの入力80Kトークンのうち90%がキャッシュヒット（72K read + 8K 新規）、出力は毎ターン4Kという条件です。

同じトークン数を流す前提なら、キャッシュ主体のループではFable 5.1が約15%安くなります。 ただしこの計算は「出力トークン数が同じ」という仮定を置いています。 理由①の通りFable 5.1は思考が長いので、実際には出力側が膨らんでこの差を食い潰す可能性があります。どちらが安いかは、自分のワークロードの「キャッシュ読み取り量 対 出力トークン量」の比で決まります。

理由③：Astraは272Kを超えると割増（Fable 5.1有利）

3つめは長文料金です。Astraは入力272Kトークンを超えるリクエストで入力・キャッシュが2倍、出力が1.5倍になります。Fable 5.1にこの割増はありません。 1Mのコンテキストは両者にありますが、「入れられる」ことと「同じ単価で入れられる」ことは別です。

400Kトークンの資料を丸ごと読ませて2万トークン出力させる、という1回のリクエストで比べます。

同じ内容で約1.9倍の差です。長文推論のAA-LCR v1.1でもFable 5.1が85%対81%と上なので、272Kを超える入力を日常的に扱うなら、性能面でもコスト面でもFable 5.1に寄せる理由があります。 逆にAstra側で長文を扱うなら、272Kを閾値として設計する（要約ではなく索引化して参照する、分割して投げる）ほうが合理的です。

API制約：壊れ方の形が違う

どちらのモデルも「前世代からそのまま差し替え」では動きません。ただし壊れる箇所の性質が違います。 Astraはパラメータの受付が厳しくなった方向、Fable 5.1は会話履歴の扱い方に制約が入った方向です。

両方を並行運用するハーネスを書く場合、厳しい側の制約に合わせて1本にまとめるのが実務的です。 具体的には「temperature を渡さない」「forced tool useを使わない」「会話履歴をappend-onlyで扱う」の3つを共通ルールにすれば、どちらのモデルでも同じループが回ります。

// 両モデル共通で通る呼び出しに寄せる例
type Provider = 'openai' | 'anthropic';

// 共通ルール
//  1. temperature / top_p / logprobs は渡さない（Astraで400）
//  2. tool_choice は auto 固定。確実に呼ばせたいならプロンプトで名指しする（Fable 5.1で400）
//  3. history は append-only。過去ターンの編集・削除をしない（Fable 5.1のpreserved thinking）
async function ask(provider: Provider, history: Message[], tools: Tool[]) {
  if (provider === 'openai') {
    return openai.responses.create({
      model: 'gpt-6-astra',
      reasoning: { effort: 'high' },   // none は廃止。xhigh / max はResponses APIのみ
      tools,
      input: history,
    });
  }
  return anthropic.messages.create({
    model: 'claude-fable-5-1',
    max_tokens: 8192,
    output_config: { effort: 'high' },
    tools: tools.map((t) => ({ ...t, strict: true })), // 強制の代わりにスキーマで担保
    tool_choice: { type: 'auto' },
    messages: history,                  // thinking block はそのまま返す
  });
}

安全性：制限のかけ方が違う

セキュリティ関連の業務でどちらを使うかは、性能よりも「どう止まるか」で決まります。ここも設計思想が対照的です。

実務的な含意は「防御的なセキュリティ作業では、素で通りやすいのはFable 5.1」です。 Astraの一般提供版はCriticalの分類を受けて能力に制限がかかっており、正当な作業でも止まることが報告されています。 一方Fable 5.1は誤検知を減らす方向にチューニングされ、ソースコードの脆弱性発見は明示的に許可されています。 ただしどちらも拒否は起こるので、拒否ハンドリングとフォールバックは最初から組み込むのが前提です。 継続的にセキュリティ業務で使うなら、DaybreakかProject Glasswingへの申請を検討する段階に入ります。

ルーティング設計：どちらかに寄せない

ここまでの差分は、「片方が優れている」ではなく「コスト構造と得意分野が直交している」という形をしています。 だとすれば合理的な設計は一方に寄せることではなく、ワークロードの形で振り分けることです。

flowchart TD
    S["タスクが来る"] --> Z{"ZDR必須の組織か"}
    Z -->|"はい"| A0["GPT-6 Astra<br/>Fable 5.1は選択肢外"]
    Z -->|"いいえ"| L{"入力が272Kを超えるか"}
    L -->|"超える"| F1["Claude Fable 5.1<br/>長文料金なし・AA-LCRで優位"]
    L -->|"超えない"| C{"請求書で最大の行はどれか"}
    C -->|"キャッシュ読み取り"| F2["Claude Fable 5.1<br/>読み取り単価が4分の1"]
    C -->|"出力トークン"| A1["GPT-6 Astra<br/>同スコアを3分の1のトークンで出す"]
    C -->|"どちらとも言えない"| D{"タスクの性質"}
    D -->|"画面操作・数学・PDF読解"| A2["GPT-6 Astra"]
    D -->|"深い推論・科学コード・知識労働"| F3["Claude Fable 5.1"]
    D -->|"防御的セキュリティ"| F4["Claude Fable 5.1を第一候補<br/>拒否時のフォールバックは必須"]

ユースケース別に整理すると次の通りです。

まとめ

• ① 表示価格が同じでも実コストは2倍以上ひらく。 入力$10 / 出力$50は完全に一致し、AAの総合指数も53対53で同点。それでもタスクあたりのコストは$3.26対$7.63になる。差を作るのは出力トークン量（27k対78k、Astra有利）、キャッシュ読み取り単価（$1.00対$0.25、Fable有利）、272Kの長文料金（Astraのみ割増、Fable有利）の3点で、向きが揃っていないためワークロードの形で逆転する。
• ② ベンチマークの勝敗は領域で綺麗に分かれる。 Astraは「手を動かす」評価（画面操作・自動化・PDF読解）と研究数学・サイバー、Fable 5.1は「考え込む・読み込む」評価（知識労働・科学コード・HLE・長文推論）。総合が同点なのは強みが打ち消し合った結果であって、互換という意味ではない。ベンダーの比較表は自社が勝つ行だけが載るので、選定は第三者の内訳で行う。
• ③ 制約条件から先に絞り、残りをコスト構造で振り分ける。 ZDR必須ならFable 5.1は選択肢外、272K超を常用するならFable 5.1。それ以外は請求書の最大行（キャッシュ読み取りか出力トークンか）で決める。API制約は厳しい側に合わせて「temperatureを渡さない・forced tool useを使わない・履歴をappend-onlyにする」の3ルールで1本化できる。どちらを使う場合も、拒否時のフォールバックと重大操作の承認フローはモデルの外側に置く。