LLMコスト最適化の基本|トークン・モデル・呼び出しの3変数
LLM(大規模言語モデル)の費用は、トークン数・モデルの単価・呼び出し回数の3つの変数で決まります。3変数それぞれを減らす方法、変数同士のトレードオフ、最適化の進め方(測る→偏りを見つける→試す→確かめる)、最適化の効果を概算と実費で確認する方法を、開発者・情シス向けに解説します。

LLM(大規模言語モデル)の費用は、トークン数 × モデルの単価 × 呼び出し回数の3つの変数で決まります。最適化とは、この3変数のどれか(または組み合わせ)を、業務の品質を保ったまま小さくすることです。やみくもに施策を入れるのではなく、自社の費用がどの変数で膨らんでいるかを見て、効く変数から手を付けます。
この記事では、3変数それぞれの減らし方、変数同士のトレードオフ、最適化の進め方と効果の確かめ方を説明します。具体的な施策の一覧は「生成AIコスト削減の方法|効果順に並べた12施策」、全体像は「生成AIコスト削減 完全ガイド」を参照してください。
費用を決める3つの変数
| 変数 | 内容 | 例 |
|---|---|---|
| トークン数 | 1回の呼び出しで使う入力・出力のトークンの量 | 長い指示、大きな資料、長い応答 |
| モデルの単価 | 1トークンあたりの料金。モデル・処理方式・経路で変わる | 高性能なモデル、通常の処理、キャッシュなし |
| 呼び出し回数 | モデルを呼び出す回数 | 利用者数、自動処理の件数、エージェントのステップ数 |
費用 = Σ(入力トークン × 入力の単価 + 出力トークン × 出力の単価)× 呼び出し回数
入力と出力で単価が違い、多くのモデルでは出力の単価のほうが高く設定されています。また、キャッシュされた入力やバッチ処理には、別の単価が適用されることがあります。
変数1: トークン数を減らす
| 方法 | 対象 | 注意点 |
|---|---|---|
| 指示を簡潔にする | 入力 | 必要な条件まで削ると品質が落ちる |
| 渡す資料を絞る | 入力 | 関係する部分だけを検索して渡す |
| 履歴を要約・削る | 入力 | 会話の文脈が失われない程度に |
| 出力の長さに上限を設ける | 出力 | 必要な情報が切れない長さに |
| 出力の形式を指定する | 出力 | 箇条書き・表など、冗長さを抑える形式 |
入力は「毎回同じものを送っていないか」、出力は「必要以上に長くないか」を見ると、減らせる部分が見つかりやすくなります。入力と出力のトークン数の比率を用途ごとに並べると、どちらを減らすべきかが分かります。
変数2: モデルの単価を下げる
| 方法 | 内容 | 注意点 |
|---|---|---|
| 用途に合ったモデルを選ぶ | 簡単な作業は安価なモデルで | 代表的な依頼で品質を確かめる |
| キャッシュを使う | 繰り返し送る入力部分の単価を下げる | 対象・条件はプロバイダごとに違う |
| バッチ処理を使う | 急がない処理を安い単価で | 結果が返るまで時間がかかる |
| 経路・地域を見直す | 同じモデルでも経路・地域で単価が違う場合がある | データの所在地の要件を確認する |
単価は各社の改定で変わるため、切り替えを判断するときは、その時点の公式の料金ページで確認します。
変数3: 呼び出し回数を減らす
| 方法 | 内容 | 注意点 |
|---|---|---|
| 使われていない処理を止める | 検証の消し忘れ、不要な定期処理 | キーごとの利用状況で見つける |
| まとめて処理する | 複数件を1回の呼び出しで処理 | 1回の入力が長くなりすぎないように |
| 応答を再利用する | 同じ質問に過去の応答を返す | 鮮度と正確さの管理 |
| エージェントのステップ数に上限を設ける | 繰り返しやループを防ぐ | 正常な依頼が止まらない値に |
変数同士のトレードオフ
3変数は互いに影響します。1つを減らすと、別の変数が増えることがあります。
| 施策 | 減る変数 | 増えるかもしれない変数 |
|---|---|---|
| 安価なモデルに切り替える | 単価 | 呼び出し回数(やり直しが増える)、トークン数(指示を詳しくする必要) |
| まとめて処理する | 呼び出し回数 | トークン数(1回の入力が長くなる) |
| 指示を削る | トークン数 | 呼び出し回数(結果が不十分でやり直す) |
| 履歴を削る | トークン数 | 呼び出し回数(文脈の再確認が必要になる) |
1つの変数だけを見て最適化すると、合計の費用が下がらないことがあります。施策を入れたら、3変数を掛け合わせた合計の費用で効果を確かめます。
最適化の進め方
| 段階 | やること |
|---|---|
| 1. 測る | 用途・キーごとに、入力・出力のトークン数、モデル、呼び出し回数を記録する |
| 2. 偏りを見つける | 費用の大きい用途・キー・モデルを特定し、どの変数が大きいかを見る |
| 3. 試す | 偏りの大きい部分に施策を当て、代表的な依頼で品質を確かめる |
| 4. 確かめる | 施策の前後で、合計の費用と品質を比べる |
| 5. 続ける | 月次で費用の内訳を見て、新しい偏りに対処する |
効果を概算と実費で確かめる
施策の効果は、まずキー・用途ごとの概算(トークン数 × 単価)で確かめます。細かい単位で前後を比べられるためです。そのうえで、月次の実費(請求と一致する金額)でも全体が下がっているかを確認します。概算だけで判断すると、単価表の更新漏れやキャッシュの扱いの違いで、実際の請求とずれることがあります。
用途別に効きやすい変数
| 用途 | 費用が膨らみやすい変数 | 効きやすい施策 |
|---|---|---|
| 社内チャット | 呼び出し回数・履歴のトークン | 履歴の要約、用途に合ったモデル |
| 文書の要約 | 入力トークン | 渡す範囲の絞り込み、バッチ処理、安価なモデル |
| 問い合わせ対応 | 呼び出し回数 | 応答の再利用、キャッシュ |
| 文章の作成 | 出力トークン | 出力の長さの上限、形式の指定 |
| エージェント | 呼び出し回数・履歴のトークン | ステップ数の上限、履歴の削減 |
| コードの作成 | 入力トークン・呼び出し回数 | 読み込むファイルの指定、作業の区切り |
用途ごとに、どの変数が大きくなりやすいかを知っておくと、最初に試す施策を選びやすくなります。
よくある質問
Q. 3変数のうち、どれから手を付けるべきですか? 費用の内訳を見て決めます。使われていない処理があれば呼び出し回数、高性能なモデルに偏っていれば単価、長い入力や出力が目立てばトークン数から手を付けます。
Q. 品質をどう確かめればよいですか? 代表的な依頼を10〜20件選び、施策の前後で結果を比べます。業務の担当者に評価してもらうと、許容できる品質の線が分かります。
Q. 最適化の効果が請求額に表れません。 施策を入れた用途の費用が全体に占める割合が小さい、単価表の更新漏れで概算がずれている、同じ時期に別の用途の利用が増えた、といった原因が考えられます。用途・キーごとの概算の前後比較と、全体の実費の推移を分けて見ます。
Q. キャッシュとバッチ処理は併用できますか? プロバイダや条件によって扱いが異なります。併用できるか、割引がどう適用されるかは、各社の公式の料金ページで確認してください。
まとめ
- LLMの費用は、トークン数 × モデルの単価 × 呼び出し回数の3変数で決まる
- トークン数は指示・資料・履歴・出力の長さで、単価はモデルの選択・キャッシュ・バッチで、回数は停止・集約・再利用・上限で減らす
- 変数同士はトレードオフがあり、1つだけを見ると合計が下がらないことがある
- 測る → 偏りを見つける → 試す → 確かめる の順に進め、効果は概算と実費の両方で確認する
ManageAIは、5プロバイダの利用量(入力・出力・キャッシュのトークン数)と費用を、APIキー・利用者・部署別に可視化し、CSVでモデル別の内訳も出力できます。3変数のどこで費用が膨らんでいるかを見つけ、施策の効果を概算と実費の両方で確かめられます。モニター企業を募集中です。
関連記事
次に読む
この記事を書いた人
モニター企業募集
初期費用0円・月額5万円(税別)
先着5社・2026年11月末まで
5プロバイダの利用量と費用を部署・利用者・APIキー別に可視化。読み取り専用キーの登録だけで当日から始められます。
募集要項を見る資料請求・お問い合わせ