LLM APIのコストを下げる7つの方法（効果が大きい順）
LLM APIの請求が想定より高い。何から手を付けるべきか——この質問への答えは、やる順番でほぼ決まります。
多くの場合、最初に着手されるのはプロンプトの圧縮です。しかし効果の大きさで並べると、それは4番目以降にきます。1番目を先にやれば、2番目以降を全部足しても届かない差が出ます。
この記事では、LLM APIのコスト削減策を効果の大きい順に7つ整理します。
前提：コストは「単価 × トークン数」に分解できる
LLM APIの請求は、ほぼすべてこの形をしています。
- 単価 — どのモデルを使うか。桁が変わる。
- トークン数 — どれだけ入力し、どれだけ出力させるか。数割単位で変わる。
桁を動かせるのは単価側だけです。これが順番を決めます。
1. モデルを右サイズにする
最大の効果はここです。他の6つを全部やっても、これ一つには届きません。
現在流通しているモデルの単価には、入力で100倍以上の開きがあります。軽量なオープンモデルとフロンティアの最上位を比べると、それくらい違う。同じタスクを1つ下のティアに移すだけで、請求が桁で変わります。
実務では、こう切り分けると大きく外しません。
| 用途 | 適したティア | 例 |
|---|---|---|
| 分類・抽出・整形・要約 | 軽量 | glm-4.7-flash、deepseek-v4-flash、gemini-3.5-flash |
| 一般的な対話・下書き・RAGの回答生成 | 中位 | anthropic-claude-haiku-4-5、gpt-5.6-luna |
| 複雑な推論・長い自律作業・最終品質 | 上位 | anthropic-claude-opus-5、gpt-5.6-sol |
すべてを最上位モデルで処理しているなら、まずここを疑ってください。 定型処理を上位モデルで回すのは、コストのほとんどを何も生まないところに払っている状態です。
ただし「安いモデルに落として品質が保てるか」は推測では決まりません。それを確かめる方法は7番目に書きます。現在の単価は料金ページとモデル一覧で確認できます。
2. 出力トークンを削る
見落とされがちですが、出力の単価は入力より大幅に高いのが一般的です。手元のカタログ43モデルで見ると、出力単価は入力単価の中央値で約5倍、モデルによっては9倍を超えます。
つまり、入力を1,000トークン削るより、出力を1,000トークン削るほうが5倍効きます。
max_tokensを用途に合わせて設定する（無制限のまま運用しない）- 「200字以内で」「箇条書き3点で」のような長さ指定をプロンプトに入れる
- 構造化出力を使い、前置きや言い訳の文章を生成させない
地味ですが、効果が読みやすく副作用も少ない対策です。
3. 推論（reasoning）トークンを把握する
新しい世代のモデルには、回答前に「思考」を行うものがあります。この思考分は多くの場合、出力トークンとして課金されます。
これは体感と大きくズレます。実測例として、あるモデルでは51の出力トークンのうち44が思考分でした。画面に出てくる回答は短いのに、請求は約7倍の長さで来る計算になります。
対策は2つです。
- 推論の強度を明示的に指定する。
reasoning_effortのようなパラメータを持つモデルでは、軽い用途では最小に落とせます。指定しないと既定値で思考が走ります。 - 思考が常時オンのモデルを、軽い用途に使わない。 オフにできないモデルもあります。一問一答の定型処理には向きません。
4. プロンプトキャッシュを使う
同じ長いプロンプト（システムプロンプト、ドキュメント、Few-shot例）を毎回送っているなら、キャッシュが効きます。
実際の単価の関係はこうなっています。
| 種類 | 入力単価に対する比率 |
|---|---|
| キャッシュ読み取り | 約 0.1〜0.2 倍（大幅な割引） |
| キャッシュ書き込み | 約 1.0〜1.25 倍（割増になる場合がある） |
読み取りが安いぶん、同じ前置きを何度も使うワークロードほど効きます。逆に、一度しか読まれないものをキャッシュに書くと割高になります。
注意点が1つ。すべてのモデルにキャッシュ階層があるわけではありません。 階層のないモデルでは、同じトークンを送っても通常の入力単価で課金されます。「キャッシュしたから無料」ではないので、対応の有無を確認してください。
5. 日本語のトークン効率を考える
同じ内容でも、日本語は英語より多くのトークンを消費します。トークナイザの世代やモデルによって効率が違うため、同じプロンプトでもモデルを変えるだけで消費トークンが動きます。
詳細は日本語はトークンを食う：API料金を日本語で最適化するにまとめています。
6. サブスクとAPIの損益分岐を計算する
コーディングエージェントのように、月額サブスクとAPI従量課金の両方が選べる領域があります。ここはどちらが安いかが使用量で逆転します。
毎日フロンティアモデルを長時間回すならサブスクが有利で、週に数回・軽いモデル中心ならAPIのほうが安くなります。感覚ではなく、自分の実際の使用量で計算してください。試算の例はHermes × FastMetal の記事にあります。
7. 測ってから決める
ここまでの6つは、すべて「品質を落とさずに」という条件が付きます。その条件が満たされているかは、測らないと分かりません。
「安いモデルに落としたら品質が落ちた気がする」で元に戻すのが、最もよくある失敗です。固定タスクを10件ほど用意し、モデルを差し替える前後で完了率・出力の質・コストを比較すれば、判断できます。
やり方はLLMの評価（Evals）とは？モデル選定を実測で行う方法に書きました。1番目（モデルの右サイズ化）を安全に実行するための道具が、この7番目です。
注意：トークン以外で課金される機能がある
最後に、見積もりから漏れやすい落とし穴を1つ。
Web検索やコード実行といった付加機能は、トークンではなく利用回数で課金されることがあります。実測では、軽量モデルへの1回の呼び出しに検索機能を付けたところ、コストの97%が検索料金で、トークン代は誤差でした。
トークン単価だけで見積もっていると、この手の機能を有効にした瞬間に前提が崩れます。使う場合は別枠で見積もってください。
よくある質問
Q. まず何から手を付けるべきですか？ A. モデルの右サイズ化です。定型処理（分類・抽出・要約）を軽量モデルに移すだけで桁が変わります。プロンプトの圧縮はその後で構いません。
Q. 安いモデルに変えて品質が落ちないか不安です。 A. 固定タスクを10件用意して、差し替えの前後で比較してください。全用途を一度に移す必要はなく、まず定型処理だけ移すのが安全です。
Q. 請求額が読めないのが一番の問題なのですが。 A. 上限を持つ課金方式を選ぶのが確実です。プリペイド型なら、残高を超えた請求が構造的に発生しません。詳しくはプリペイド型API入門をご覧ください。
まとめ
- モデルを右サイズにする — 桁が動く。ここだけが桁を動かせる
- 出力トークンを削る — 出力単価は入力の中央値で約5倍
- 推論トークンを把握する — 出力の大半が思考分ということがある
- プロンプトキャッシュを使う — 読み取りは入力の約0.1〜0.2倍
- 日本語のトークン効率を考える
- サブスクとの損益分岐を計算する
- 測ってから決める — 1番目を安全に実行するための道具
FastMetalは1つのAPIキーと1つの残高で、軽量モデルからフロンティアまでを横断して呼べるOpenAI互換のゲートウェイです。model の値を変えるだけでティアを移せるので、1番目の対策がそのまま実行できます。プリペイド制なので、残高を超える請求も届きません。
無料でアカウントを作成して、まずは一番重い処理を1つ、下のティアで試してみてください。