Claude Fable 5のトークンコストを削減する方法

Claude Fable 5 のトークンコストを最も速く削減する方法は、より安価なモデルで同等に処理できる作業にそれを使うのをやめることです。100万トークンあたり $10/$50 の Fable は Sonnet 5 の 5 倍ですが、私のテストではどちらも同じタスクを見事にこなしました。

あなたの Fable 5 の支出が実際にどこに使われるか

最適化する前に、どこで費用が漏れているのかを確認しましょう。典型的なエージェント型リクエストでは、入力トークンが出力トークンを大きく上回ります。1回のクエリで、出力がわずか1,000〜3,000トークンであるのに対し、入力は80,000〜140,000トークン（システムプロンプト、ツール定義、会話履歴、ファイルのコンテキスト）に達することがあります。出力はトークンあたりの価格が5倍高いにもかかわらず、入力の絶対量が非常に大きいため、通常はこちらのほうが費用の大きい項目になります。だからこそ、短い回答よりも、キャッシュとコンテキストの管理が重要なのです。

以下のすべての判断の基準となる料金は次のとおりです:

Prompt cachingは、キャッシュされた入力をベースレートの約10分の1に引き下げますが、キャッシュへの書き込みには追加料金がかかります（5分キャッシュは$12.50/M、1時間キャッシュは$20/M）。料金は2026年7月17日時点のAnthropicの公開料金で確認済みです。Sonnet 5の$2/$10は、2026年8月31日までの導入価格です。

Fable 5、Opus 4.8、Sonnet 5で同じタスクを実行しました

理論は――「使えるときはより安価なモデルを使う」――と言うのは簡単ですが、数字なしでは信頼しにくいものです。そこで、制御されたテストを実施しました。3つのモデルすべてに同じプロンプトを与えました。*空の入力と未ソートの入力を処理し、3つの assert ベースのユニットテストを備えた Python の merge_intervals 関数を書いてください。* その後、各回答を実行して、テストが実際に通ることを確認しました。

3つとも、すべてのテストに合格する正しいコードを生成しました。違いは完全にコストと速度にありました。

同じ入力（576トークン）、ほぼ同じ出力長、同じ正確性 — しかも価格に5倍の差があります。Sonnetは応答時間も3分の1でした。

これは小さく独立したタスクであり、ベンチマークではありません — 重い推論問題こそが Fable 5 の価格に見合うところであり、その差は縮まるか、逆転するでしょう。しかし要点は変わりません。ほとんどのセッションを埋める日常的な作業では、同じ結果のために 5 倍の料金を支払っている可能性があります。レイテンシの数値はサードパーティの API エンドポイントから取得したものなので、正式な SLA ではなく、あくまで傾向を示すものとして扱ってください。

レバー1: モデルをタスクに合わせる

これは、あなたが行える変更の中で最もROIの高いものであり、上のテストがその理由です。タスクの種類で振り分けましょう。深い多段階の推論、難しいリファクタリング、曖昧な仕様には Fable 5 を使い、定型文、フォーマット調整、簡単な修正、大量の単純な呼び出しは Sonnet 5 または Haiku 4.5 に送ります。迷うときは、まず安価なモデルで始め、出力が間違っている場合にのみ上位モデルへエスカレートしてください。安価な呼び出しが失敗しても、Fable の呼び出しのほんの一部のコストしかかかりません。

実務者たちがたどり着き続けているパターンがあります。Fable 5に計画させ、より安価なモデルに実行させるのです。Fableがアーキテクチャを書いたり、タスクを手順に分解したりし、Sonnet 5やHaiku 4.5が大半のタイピングを担います。ClineコーディングエージェントのチームはFableに1日で2,000ドル以上費やしたと報告し、その後、より安価なモデルに敵対的レビューのループを組み合わせることで、同等の——場合によってはより良い——結果を、はるかに低コストで得られることを見いだしました。

Claude Codeには知っておく価値のある実用上のひと工夫があります。チャットからセッションの途中でアクティブなモデルを切り替えることはできません。回避策は、自然な言葉で依頼することです。つまり、作業の計画はClaude自身に立てさせつつ、実装はより安価なモデルに任せるよう伝えると、実行用にSonnet 5のサブエージェントを起動し、高価なモデルは計画担当のまま残ります。これにより、最もトークンを消費する部分の作業について、Fable級のタスク分解とSonnet級のトークン単価を得られます。

単一のモデル内では、effort設定はより細かい粒度で同じレバーであり、私が最初に使うものです。通常の作業ではlowのeffortを既定にし、結果が実際に間違って返ってきたときだけ上げます。lowは、Fableが回答前に消費してしまうはずの推論トークンを省略するため、簡単なタスクでは品質を落とさずに純粋な節約になります。追加の推論が答えを変える問題では、highまたはmaxを使い続けてください。Fable 5 の high と max の effort ティアの比較では、その境界がどこにあるかを示しており、Sonnet 5 vs Fable 5では、どのタスクなら安全にティアを下げられるかを解説しています。

レバー2: プロンプトキャッシュを保護する

入力がトークン数の大半を占めるため、約90%のキャッシュ割引は2番目に大きなレバーです。注意点は、キャッシュが役立つのは、呼び出し間でプレフィックスがバイト単位で完全に同一である場合だけだということです。システムプロンプトの冒頭で1トークンでも変更したり、ツール定義の順序を入れ替えたりすると、その後の部分はすべてキャッシュミスとなり、通常料金で課金されます。

キャッシュを維持するには:

• 安定したプレフィックスを固定する。 system prompt と tool 定義は先頭に置き、セッションの途中で変更しないでください。新しいコンテキストは末尾に追加します。
• リクエスト間で tool の順序を並べ替えないでください — tool list を動的に再構築する agents は、静かに cache を無効化してしまいます。
• cache ウィンドウ内でまとめて再利用する。 5分の cache は書き込みコストが低いので、関連する calls は期限切れになる前にまとめて実行してください。

損益分岐点はすぐに来ます。5分間のキャッシュ書き込みは通常の入力トークンの1.25倍のコストですが、キャッシュされた読み取りごとに0.9倍を節約できるため、同じプレフィックスを2回再利用するだけでキャッシュは元が取れます。これは、毎ターン会話全体を再送信するあらゆるエージェントにとっては取るに足らない回数であり、キャッシュが保持されているかどうかが、繰り返される部分について $10/M を支払うか $1/M で済むかの違いになります。

レバー 3: コンテキストを減らして送信する

送信しないトークンは、どのプランでも料金が発生しないトークンです。ここでの成果は華やかではありませんが、積み重なっていきます:

• 無関係なタスクの間はクリアする。 Claude Code では、/clear を使うと新しく始められるため、古い履歴がその後のすべてのメッセージに引きずられなくなります。
• 長いセッションは圧縮する。 /compact はこれまでの会話を要約します。そこに「コードサンプルと API の使用に注目して」といった指示を追加すると、何を保持すべきかを伝えられます。
• 探索ではなくドキュメントを与える。 密度の高い事前作成済みのスキルや、バージョン固定されたドキュメントの一部を使うほうが、エージェントに同じ知識を検索・読解させるよりはるかにコストが低くなります。
• PDF より Markdown を優先する。 PDF にはモデルが必要としないレイアウトトークンが含まれます。同じ内容なら、プレーンな Markdown のほうが圧倒的に軽量です。

これらはいずれもレートを変更しませんが、100kトークンのコンテキストでは、すべての呼び出しごとに何千ものトークンを削減します。

レバー 4: トークンごとの料金そのものを下げる

上記のレバーは、消費するトークン数とどのティアを使うかを減らします。最後のレバーはトークンあたりの価格を下げます。AnthropicのファーストパーティAPIには、Fable 5向けのバッチ割引や非同期割引のティアはないため、表示されているレートがそのまま支払うレートです。

一つの選択肢は、Claudeへのアクセスを定価未満の上乗せ価格で再販するAPIアグリゲーターです。たとえばAIReiterはAnthropic-API互換で、Claudeモデルを公式料金のおよそ20%で提供しており、その結果Fable 5は1百万あたり約$2/$10となり、$10/$50ではなくなります。トレードオフは、どの再販業者でもおなじみのものです。つまり、Anthropicを直接使うのではなく、第三者のルーティングと稼働率を信頼することになるため、レイテンシ重視の本番経路よりも、大量かつコスト重視のワークロードに向いています。どちらの方法を選ぶにせよ、料金は他のすべてに掛け算で効くため、一度決めたら、毎日調整するトークン量のレバーに集中する価値があります。

実際に成果を動かすレバーはどれか

もし1つだけ行うなら、レバー1を行ってください — 仕事を適切なモデルに振り分けることが、テストで測定された差であり、他のどれもこれに及びません。率直な順位は次のとおりです:

1. モデルをタスクに合わせる — 誤ったルーティングの作業では最大約5倍。最も大きく、最も持続的な成果。2. プロンプトキャッシュを保護する — 繰り返し入力を最大約90%削減。エージェントループでは、これがトークンの大半を占めます。3. 送るコンテキストを減らす — トークン量を安定して20〜50%削減し、すべての呼び出しで積み重なります。4. トークン単価を下げる — 一律の乗数。1回設定すれば、すべてに効果があります。

魅力的な「抜け道」――プロンプトを画像としてエンコードしたり、独自のトークナイザーの工夫をしたり――は、次のモデル更新で壊れてしまうことがよくあります。ここでの4つのレバーはハックではなく、習慣です。実際の課金設計に合っているため、動き続けるのです。

よくある質問

Claude のトークンコストを削減するにはどうすればよいですか?

日常的な作業では low に努力レベルを設定し、より簡単なタスクは Sonnet 5 または Haiku 4.5 に振り分け、プロンプトのプレフィックスをバイト単位で安定させてキャッシュを適用し、タスク間ではコンテキストをクリアするか圧縮してください。最も大きな節約が得られるのは、モデル選択と努力レベルです。

Fable 5 のトークンごとの料金はいくらですか？

入力トークン100万件あたり$10、出力100万件あたり$50 — Opus 4.8（$5/$25）の2倍で、Sonnet 5（$2/$10、2026年8月31日までの導入価格）の5倍です。プロンプトキャッシュにより、キャッシュ済み入力の読み取りは100万件あたり約$1に下がります。

なぜFable 5のトークンをそんなにすぐ使い切ってしまうのですか？

通常は、過度に大きいコンテキスト（長い履歴や毎回の呼び出しに添付される大きなファイル）、各ターンで全文脈を再送するリトライループ、またはより安価なモデルで処理できる作業に Fable を使っていることが原因です。コンテキストを削減し、タスクを適切に振り分ければ、ほとんどは解決します。

Fable 5 にとってプロンプトキャッシュは価値がありますか？

はい、大きく安定したプレフィックスを再利用する場合は、キャッシュされた入力がベースレートの約10%になります。これは、プレフィックスが呼び出し間でバイト単位で同一のままの場合にのみ効果があるため、system prompt と tool definitions は固定してください。

努力設定を下げると品質は低下しますか？

単純なタスクでは、まれに low または medium が、そのタスクに不要な推論トークンを省きます。本当に難しい問題で、追加の推論が答えを変える場合にのみ high または max を使ってください。