最上位 AI モデルが「完全従量課金」になる日 〜 Claude Code で始めるモデルルーティング入門

エンジニアの又川です。

Anthropic の最上位モデル Claude Fable 5、もう使っていますか？ 7 月に入ってから、Claude Code にはこんなお知らせが表示されるようになりました。

▎ Fable 5 is back.
▎ Until July 7, you can use up to 50% of your plan's weekly usage limit on Fable 5.
▎ If you hit your limit, you can continue on Fable 5 with usage credits.
▎ Fable 5 draws down usage faster than Opus 4.8. Learn more

要するに、Fable 5 をサブスクプランで使えるのは週次利用上限の 50% まで。それを超えたら usage credits による従量課金 という案内です^(*1)。「サブスクに入っていれば最上位モデルが実質使い放題で、上限に当たったら回復を待てばいい」という今までの Claude Code とは、世界が変わってしまいました。

しかも提供条件は流動的です。お知らせにある期限 "Until July 7" は、期限当日になって米国時間 7 月 12 日までの延長が発表されました^(*8)。この告知は今後も変わるかもしれません。ただ一つはっきりしているのは、最上位モデルは、もう無邪気に使い放題にはできない ということです。

そこで本記事では、「高いモデルに簡単なタスクをやらせない」ためのモデルルーティングという考え方と、Claude Code にすぐコピペで導入できる設定例を紹介します。

この 1 か月の経緯を図にまとめました（日付・時刻は日本時間です）。

Claude Fable 5 の提供形態の変遷（2026 年）

Claude Fable 5 は 2026 年 6 月 10 日に公開された、Claude Opus の上位にあたる最上位モデルです^(*2)。ところが公開からわずか 3 日で、安全対策を回避するジェイルブレイク手法の発覚をきっかけとした 米政府の輸出管理命令により、全ユーザー向けに提供停止 となりました^(*7)。対策の安全分類器を追加した上で 7 月 1 日に再公開され、同時に「サブスクの週次利用上限の 50% まで使える」という期間限定プロモーションが始まりました。この期限は当初、日本時間 7 月 8 日 16 時ごろまでとされていましたが、期限当日になって日本時間 7 月 13 日 16 時ごろ（米国時間 7 月 12 日いっぱい）までの延長が発表されました^(*8)。それ以降、Fable 5 はサブスクの利用枠から外れ、usage credits をチャージした従量課金でのみ利用できる予定です^(*1)。

停止に復活に延長と、この 1 か月で提供条件は二転三転しており、SNS ではそのたびにちょっとしたパニックが起きています。では、従量課金になると何がどのくらい重いのでしょうか。

Fable 5 の API 料金は 入力 $10/MTok、出力 $50/MTok です^(*2)。MTok は 100 万トークンのことで、AI モデルの料金表示によく使われる単位です。Opus 4.8 の API 料金（入力 $5/MTok、出力 $25/MTok）のちょうど 2 倍で、しかも入力と出力で単価が 5 倍違う点に注意が必要です。

ピンと来ないと思うので、「毎日 100 万トークン使うと月いくらになるのか」を入出力の比率別に試算してみました（1 ドル 162 円［2026 年 7 月時点］、30 日換算）。

「毎日 100 万トークンなんて使わないでしょ」と思うかもしれませんが、Claude Code でエージェントにタスクを数件任せれば普通に到達する量です。つまり Fable 5 を今までどおり常用すると、サブスク料金に加えて 1 か月で 10 万円ほどの従量課金が発生する ことになります（プロンプトキャッシュが効けば入力は約 1/10 になるので、実際はここから多少下がる余地はあります）。

一方の Claude Opus 4.8 はサブスクの利用枠内です。参考までに、サブスク枠内で毎日どのくらい使えるのかの独自試算がこちらです。

同じ「毎日 100 万トークン」でも、Opus なら追加 0 円、Fable なら月 10 万円 です。この差を意識せずに使い続けるのは、さすがに危険ですよね。

まず、従量課金のスケール感がよく分かる実例を紹介します。

6 月の初公開時、Fable 5 の性能を最大限に引き出す試みとして 3 日間で約 300 万円 を投じた方がいます^(*3)。MacBook 上で 8〜10 セッションを並列で立ち上げ、各セッションがサブエージェントを 5〜100 体呼び出して 24 時間稼働させるという徹底ぶりで、ピーク時は 1 日 120 万円ペースだったそうです。ご本人は Kaggle でメダルを獲得するなどの成果を挙げており「ROI は十分」と総括されています。明確な意図と成果があってこその投資ですが、裏を返せば、最上位モデルの従量課金はここまでのペースで積み上がりうるということでもあります。

企業レベルでも、AI のコストは大きな論点になっています。Microsoft では Claude Code のトークン費用が膨らみ、一部部門でライセンスを終了して GitHub Copilot CLI へ誘導したと報じられました^(*4)。一方で、その Microsoft 社内の導入データを分析した研究によると、Claude Code などを使い始めたエンジニアは、マージされる Pull Request の数が使う前より約 24% 増えていたそうです^(*5)。コストは確かに重いものの、生産性も確かに上がっているのです。つまり「高いから禁止」で終わる話ではなく、どの利用が費用に見合うのかを設計する問題 なのです。

ここで厄介なのは、AI は自分から「このタスクは下位モデルで十分ですよ」とは言ってくれない という点です。ユーザーが選んだモデルで全力で応えるのがデフォルトの挙動で、変数名の相談だろうがアーキテクチャ設計だろうが、Fable を選んでいれば Fable が動きます。人間の上司なら「それ私がやる仕事じゃなくない？」と言ってくれるところですが、AI には誰も止める人がいません。

ただし面白いことに、Claude Code の組み込みサブエージェント（Explore など）は、探索タスクを勝手に Haiku という安いモデルで実行してくれます。ユーザーが独自のサブエージェントを作るときも、そのサブエージェントが使うモデルを指定できます（後ほど実例を紹介します）。つまり 仕組みとしてはモデルの使い分けは既に可能 で、足りないのはルールだけなのです。

そこで登場するのが モデルルーティング です。タスクの難易度と失敗コストに応じて、投げるモデルを振り分けることを指します。

会社に例えるなら「役員に議事録の清書をさせない」という、ごく当たり前の話です。人間の組織では役割に応じた仕事の割り振りが自然に行われていますが、AI 相手だと「一番賢いのに全部任せる」をやってしまいがちです（私もやっていました）。

モデルルーティングの全体像。昇格は提案してから、降格は自動で委譲する

Claude のモデルで整理すると、こんな分担になります。

実は弊社の Slack でも、Fable 5 の従量課金化をどう迎えるかが話題になりました。そこで出てきた実践が面白かったので紹介します。

あるエンジニアは、Fable 5 が公開された直後から 「Opus に実装させる前提で詳細な設計書を作って」 というプロンプトを使っていました。Fable に実装までやらせるのはオーバースペックだと感じて、設計書だけ書かせる運用にしていたそうです。さらにここからは本人の持ちネタをお借りするのですが、その Fable、設計書の最後に 「これなら Opus でも迷わず実装できると思います」 とナチュラルに下位モデルを見下す一言を添えてきたそうです。正式な上位モデルとしての自信を感じますね。

他にも「設計の時だけ Fable を使いたいので $100 追加お願いします、みたいな運用になりそう」という声もあり、Fable は常用モデルではなく、勝負所で切る高級カード という共通認識ができつつあります。

では、読者の皆さんの Claude Code にモデルルーティングを導入していきましょう。お手軽版と本格版の 2 段構成です。

その 1: CLAUDE.md にルールを追記する（お手軽版）

プロジェクトの CLAUDE.md（または ~/.claude/CLAUDE.md）に以下を追記するだけです。

## モデルルーティング

- タスクに着手する前に、そのタスクに必要なモデルのランクを判定すること
- 小さなバグ修正・テストの追加・ドキュメント作成は、Agent ツールで
  `model: sonnet` のサブエージェントに委譲すること
- ファイル探索・コード検索・ログの要約・定型的な調査は、Agent ツールで
  `model: haiku` のサブエージェントに委譲すること。メインのモデルで全部やらない
- 本格的な実装・テスト・リファクタリングは、現在のモデルのまま進めてよい
- 以下に該当するタスクだと判断したら、作業を始める前に
  「このタスクは Fable の利用を検討する価値があります。理由: ...」と一言提案すること。
  提案した上で、現在のモデルのまま作業を続けること（切り替えの判断はユーザーが行う）
  - システム全体のアーキテクチャ設計や技術選定
  - 選択を誤ると手戻りが大きい、複数案が拮抗する設計判断
  - 長時間詰まっている障害調査の突破口探し
- 逆に、現在のモデルが最上位モデル（Fable）の場合:
  下位モデルで十分なタスクは、作業前に「このタスクは Opus で十分です。理由: ...」と
  必ず伝えること

ポイントは 2 つあります。

1. 昇格は「提案」で止める。 「Fable を使った方が良さそうなら教えて」とだけ頼み、勝手に課金される事態を防ぎます。財布の紐はあくまで人間が握ります
2. 降格は自動で委譲させる。 小さなバグ修正やドキュメント作成は Sonnet、ファイル探索やコード検索は Haiku で十分なので、サブエージェントに勝手に投げてもらいます。こちらは安くなる方向なので自動で問題ありません

なお「Fable が必要かどうか」を Fable 自身に判定させるのはおすすめしません。自分を使う理由を作りがちだからです。昇格判定は Opus 側、つまり普段使いのモデルに持たせる のがコツです。

その 2: サブエージェント定義（本格版）

もう一歩踏み込むなら、.claude/agents/ にモデル指定付きのサブエージェントを定義します。サブエージェントは Markdown ファイルの frontmatter で model を指定できるので、役割ごとに適切なモデルを固定できる のです。

軽作業担当（Sonnet）の例です。.claude/agents/light-dev.md として保存します。

---
name: light-dev
description: 軽めの開発作業を担当するエージェント。typo や小さなバグの修正、テストの追加、README やドキュメントの更新、調査結果の整理など、設計判断を伴わない小粒なタスクで使うこと。
model: sonnet
---

あなたは軽微な修正とドキュメント整備の担当者です。
指示された小粒なタスクを素早く確実にこなしてください。
設計判断が必要になった場合は、作業を進めずにその旨を報告してください。

実装担当（Opus）の例です。.claude/agents/implementer.md として保存します。

---
name: implementer
description: 設計書に沿った実装・テスト作成を担当するエージェント。設計判断が済んでいて、あとは書くだけのタスクで使うこと。
model: opus
---

あなたは実装担当のエンジニアです。渡された設計・方針に従って
コードとテストを書いてください。設計自体に疑問が生じた場合は、
実装を進めずに疑問点を報告してください。

こうしておくと、メインの会話がどのモデルで動いていても、軽作業は Sonnet、本格的な実装は Opus に自動で振り分けられます。同じ要領で model: haiku の探索担当を足せば、先ほどの分担表の 4 段階がそのまま実現できます。description に「〜のタスクで使うこと」と発動条件を書いておくのがコツです。

その 3: 運用フロー「設計は Fable、実装は Opus」

最後に、先ほどの社内エピソードを運用フローに落とし込んだものです。

1. /model で Fable に切り替え、設計だけ依頼します

   Opus に実装させる前提で、迷いなく実装できる詳細な設計書を
   docs/design.md に書いてください。実装はしないでください。

2. /model で Opus に戻して、実装を依頼します

   docs/design.md に従って実装してください。
   テストとカバレッジ計測も忘れずに。

このフローのポイントは、課金される Fable の出番は短い設計フェーズだけにして、トークンを大量に消費する実装・テスト・手直しは追加 0 円の Opus に任せる という点です。Fable の賢さは設計書という形で残るので、従量課金は設計セッション 1 回分だけで済みます。Fable は一発でワンランク上のコードを書いてくれますが、Opus でもテストツールとカバレッジ計測を使い倒せば品質は追い込めるので、この分担で実用上は十分です。

「どうせそのうちサブスクに戻るんでしょ？」と思った方、鋭いですね。実際、Anthropic の開発者である Thariq 氏は「サブスクから一度外れるものの、キャパシティが許し次第、サブスクの標準機能として復活させることを目指す」と発言しています^(*6)。プロモーション期限が土壇場で延長されたのも、その意向の表れかもしれません。

ただ、仮に復活したとしても、モデルルーティングは無駄になりません。

• サブスクに戻っても週次の利用上限は消費します。安いモデルへの振り分けは 上限の節約 としてそのまま効きます
• 探索を Haiku に投げる構成は、コストだけでなく 応答速度 の面でも有利です
• そして何より、「どのタスクをどのモデルに流すか」という設計感覚は、今後どのベンダーのどのモデルを使う場合にも持ち運べる資産です

Microsoft の事例が示すように、AI のコストは人件費と違って「使った瞬間に増える変動費」です。これからは「AI を使えるか」ではなく 「どのタスクをどのモデルに流すか」 が、エンジニアの腕の見せどころになっていくと思います。

今回は Claude Fable 5 の完全従量課金化をきっかけに、モデルルーティングという考え方と、Claude Code への導入方法を紹介しました。

ちなみに、この記事の本文と図の生成・テコ入れに使った Fable 5 のトークン数は 543,147 トークン（内訳はおよそ入力 86%、出力 14%）、料金にして $62.64（約 1 万円） でした。記事 1 本で早くも「毎日 100 万トークン」の半分、比率も先ほどの試算表の「入力 90% / 出力 10%」に近い使い方です。試算が大げさではないこと、伝わったでしょうか。

最上位モデルがサブスクだけでは使い放題にならないという状況は Claude Code では初めてのことですが、冷静に考えれば「一番高い人材に全部任せない」という組織運営の常識が AI にも適用されるようになった、というだけの話でもあります。まずは CLAUDE.md への 1 コピペから、モデルルーティングを試してみてください。

エンジニアが AI を使えることは、もう当たり前になりました。アシアルが大事にしているのは、その先です。数ヶ月で状況が変わるこの分野で、本記事のモデルルーティングのように、これから多くの現場で顕在化する課題を半歩先に捉えて、解決の方向性を提言していきたいと考えています。興味のある方は会社情報や採用情報もご覧ください。

ではまた！

(*1) Claude Fable 5 Promotional Access — Claude Support
https​://support.claude.com/en/articles/15424964-claude-fable-5-promotional-access

(*2) Claude Fable 5 and Claude Mythos 5 — Anthropic
https​://www.anthropic.com/news/claude-fable-5-mythos-5

(*3) Claude Fable 5 に 3 日間で 300 万円課金した話 — 沖山 翔（note）
https​://note.com/sho_okiyama/n/n4106c42c2b3d

(*4) Microsoft drops Claude Code after budget burned — Cybernews
https​://cybernews.com/ai-news/microsoft-claude-code-burn-yearly-ai-budget/

(*5) Adoption and Impact of Command-Line AI Coding Agents: A Study of Microsoft's Early 2026 Rollout of Claude Code and GitHub Copilot CLI — arXiv
https​://arxiv.org/abs/2607.01418

(*6) Thariq (@trq212) — X
https​://x.com/trq212/status/2072814903170408784

(*7) Statement on the US government directive to suspend access to Fable 5 and Mythos 5 — Anthropic
https​://www.anthropic.com/news/fable-mythos-access

(*8) Claude (@claudeai) — X（プロモーション期限を 7 月 12 日まで延長する告知）
https​://x.com/claudeai/status/2074548242386178258