6月9日の朝、Claude Fable 5 の公開を知らせるリリースノートを読みながら、カレンダーの 6月15日に目が行きました。Agent SDK や headless 実行の課金が、API レート準拠の月次クレジットへ移行する日です。新しいモデルの検証と、コスト構造の確定。二つの締切が同じ週に重なった形になります。
幸い、Fable 5 は 6月22日まで Pro / Max などの主要プランに追加費用なしで同梱されています。であれば、この無料の窓のうちに、個人開発で日々回している保守タスクで Opus 4.8 と並走させて、6月15日以降の使い分けを決めてしまおう。そう考えて、6月10日からの三日間、意識して二つのモデルに同じ仕事を渡してみました。
比較の段取り — 同じタスクを同じプロンプトで二度流す
検証に使ったのは、App Store で運用している壁紙アプリの保守で実際に発生していた三つのタスクです。
- 画像キャッシュまわりのリファクタリング（Swift・約1,200行のモジュール）
- Crashlytics のクラッシュログ約40件を、根本原因ごとに束ねる分類作業
- モジュール一式をまとめて読ませる設計レビュー（合計約9万トークン）
特別なベンチマークは組んでいません。個人開発の判断基準は「普段の仕事で差が出るか」の一点に尽きると考えているからです。同じプロンプトを --model だけ変えて二度流せば、条件はほぼ揃います。
# 同じタスクを 2 モデルに渡して、出力の構成を見比べる
claude -p --model claude-fable-5 < task_refactor.md > out_fable.md
claude -p --model claude-opus-4-8 < task_refactor.md > out_opus.md
diff <(grep '^##' out_fable.md) <(grep '^##' out_opus.md)なお、この claude -p による headless 実行こそ、6月15日からサブスク上限を外れて月次クレジット消費になる対象です。検証そのものが「移行後はいくらかかる作業なのか」を測る予行演習にもなりました。
差がはっきり出たのは「分割せずに渡す」場面でした
これまで設計レビューを頼むときは、モジュールを3〜4回に分けて渡し、最後に「全体を踏まえて矛盾を指摘してください」と統合する段取りを組んでいました。コンテキストに収まらないからというより、後半に行くほど前半の記憶が薄れる感触があったからです。
Fable 5 には約9万トークンのモジュール一式を、分割せずにそのまま渡しました。返ってきたレビューで印象的だったのは、ファイルをまたいだ整合性の指摘です。キャッシュの破棄ポリシーを定義しているファイルと、その破棄を前提にしていない先読み（プリフェッチ）側のファイル。分割レビューでは出てこなかった種類の矛盾を、一度の依頼で拾ってきました。
「どう分割するか」を考える工程そのものが消える。1M コンテキストの実務上の意味は、私にとってはここでした。
ただし、コストの見通しは先に立てておく必要があります。API 価格は入力 $10 / 出力 $50 per MTok。9万トークンを読ませると、入力だけで約 $0.9 です。チャットのように何度も往復する使い方には向きません。一回で深く読ませて、指摘を持ち帰る。そういう「精読の依頼」に絞るのが良さそうです。
単発の修正タスクでは、差はほとんど感じられません
一方で、画像キャッシュのリファクタリングと約40件のクラッシュログ分類では、二つのモデルの出力に実務上の差をほとんど見つけられませんでした。私の手元では、リファクタリングの diff はどちらもそのまま適用できる品質で、クラッシュの束ね方も40件中38件が同じグループ分け。解釈が分かれたのは残り2件だけでした。
ここで価格表を見直すと、面白い並びに気づきます。Opus 4.8 の fast モードは従来比3倍安・2.5倍速になっていて、Fable 5 と同じ $10/$50 per MTok。同じ予算で「速さを取るか、深さを取るか」という選択になっているのです。回数の多い単発修正や日次のバッチ処理は、待ち時間の短い側に流す。それが三日間を終えた私の結論です。
運用面の観察 — フォールバックと「考える量」の揺らぎ
Fable 5 には、サイバーセキュリティや生物・化学などの高リスク領域で応答をブロックし、Opus 4.8 へ自動フォールバックする安全機構があります（発動はセッションの5%未満とされています）。三日間の検証では一度も発動を確認できませんでしたが、自動化に組み込むなら「この出力はどちらのモデル由来か」をログに残す設計にしておきたいところです。品質のばらつきを調べるとき、モデルの取り違えは最初に疑うべき変数になるからです。
もう一つの観察は、常時適応思考による応答時間の揺らぎです。簡単に見えるプロンプトでも、モデルが「考える量」を自分で増やすことがあり、バッチ全体の所要時間が読みにくくなりました。スケジュール実行に載せるなら、タイムアウトには従来より余裕を持たせることをおすすめします。
過負荷時の備えとしては、Claude Code の fallbackModel 設定で受け皿を順に指定しておけます。
// .claude/settings.json — 過負荷時に順次フォールバック
{
"model": "claude-fable-5",
"fallbackModel": ["claude-opus-4-8", "claude-sonnet-4-6"]
}モデルの世代交代を業務ロジックに巻き込まない構えについては、Claude API のモデル抽象レイヤー設計 — 世代交代に業務ロジックを巻き込まない内部アーキテクチャに書いた抽象レイヤーの発想がそのまま使えます。モデル名の直書きを一箇所に集めておくと、こういう週の切り替えが設定一行で済みます。
6月15日以降の私の使い分け
三日間の並走で、線引きは次の形に落ち着きました。
- 毎日の単発修正・ログ分類・定型バッチ → Opus 4.8（待ち時間を優先する場面は fast モード）
- 月に数回の「モジュール一式を渡す」設計レビューや横断調査 → Fable 5 を回数を決めて
- スケジュール実行のタイムアウトとフォールバック設定を、適応思考前提に見直す
無料同梱の窓は 6月22日までです。もしまだ触れていないなら、普段のタスクをひとつ選んで、同じプロンプトを --model だけ変えて二度流すところから始めてみてください。差が出る場面と出ない場面が、抽象的な評判ではなく自分の仕事の形で見えてきます。
私自身は、128k トークンの長い出力を使った一括生成の検証がまだ残っています。窓が閉じる前にもう一往復するつもりです。同じように導入期間中の見極めを考えている方の参考になれば幸いです。