なぜ「モデルを安いものに替える」から入ると失敗するのか
AIを組み込んだ業務システムの開発相談をいただくとき、運用コストの話は必ず出てきます。そして多くの場合、最初の質問は「どのモデルが一番安いですか」です。
気持ちはよく分かるのですが、この順番で考えると、たいてい期待したほど下がりません。理由は単純で、API料金は「単価」だけで決まっていないからです。モデルの単価を半分にしても、1回の処理で無駄に10倍のテキストを送っていたら、総額は元より高くなります。
本記事では、値段表の比較ではなく、設計で効くコスト構造の話をします。LLM（Large Language Model／大規模言語モデル。文章を入力すると文章を返すAIモデル)をAPI経由で使う前提で、中小企業が受注開発・内製開発のどちらを選ぶ場合でも判断材料になる観点を整理します。
コストの式を分解する — 3つの変数しかない
LLMのAPI課金は、ほとんどのベンダーで「トークン」単位です。トークンとは、文章をモデルが処理する単位に分割したもので、英語ではおおむね単語の一部、日本語では文字数に近い量になる傾向があります（分割方式はモデルごとに異なるため、正確な数はベンダーが提供するトークン計測ツールで確認するのが確実です）。
月額コストは、おおまかに次の掛け算で表せます。
- 単価（入力トークン単価・出力トークン単価）
- × 1回あたりのトークン量（送る文脈＋返ってくる出力）
- × 呼び出し回数
多くのプロジェクトで、削減余地が大きい順は「呼び出し回数 → トークン量 → 単価」です。単価は他社が決めた数字なので、こちらが設計で動かせる余地は一番小さい。逆に、呼び出し回数とトークン量は設計次第で桁が変わります。
| 変数 | 主な打ち手 | 設計コスト | 効果の幅 |
|---|---|---|---|
| 呼び出し回数 | 前段フィルタ、バッチ化、UI設計、キャッシュ | 中 | 大（桁で変わりうる） |
| トークン量 | 文脈の絞り込み、履歴圧縮、出力形式の制約 | 中〜高 | 中〜大 |
| 単価 | モデル選択、ルーティング、バッチAPI | 低 | 小〜中（倍率の範囲） |
打ち手1：呼び出し回数を減らす — 「LLMを呼ばない」判断を先に置く
一番効くのに、一番見落とされるのがここです。「AIを使うシステム」を作ると、つい全処理をLLMに通してしまいます。
ルールで済むものはルールで処理する
たとえば次のような場面です。問い合わせメールを自動分類するシステムで、全メールをLLMに投げて分類させる設計にしたとします。しかし実際には、件名に特定の文字列が含まれていればその時点で分類が確定するケースが相当数あるかもしれません。正規表現やキーワード判定で確定できるものを前段で処理し、判定に迷うものだけLLMに回す構造にすれば、呼び出し回数は確実に減ります。
この「LLMに行く前の門番」を置けるかどうかで、運用コストは大きく変わります。しかも副次効果として、ルールで処理できる部分は応答が速く、結果が安定します。
1件ずつではなく、まとめて処理する
100件の商品説明文を分類するとき、100回呼ぶのではなく、10件ずつ10回にまとめる。システムプロンプト（モデルへの指示文。毎回同じ内容を送ることが多い)が1回あたり1,000トークンあるなら、呼び出し回数を10分の1にすれば、その固定費も10分の1になります。
ただし、まとめすぎると精度が落ちる、1件のエラーが全体に波及する、といった副作用があります。実務では「何件まとめても品質が落ちないか」を小さく試して境界を見つける作業が必要です。
即時でなくていいものは即時に処理しない
主要ベンダーの一部は、即時応答を求めない処理向けに、通常より低い単価の「バッチ処理」窓口を用意しています（提供有無・割引率・納期保証はベンダーと時期によって変わるため、採用時に公式ドキュメントで確認してください）。夜間に回せる集計やタグ付けは、ここに寄せる価値があります。
裏返すと、要件定義の段階で「これは本当にリアルタイム応答が必要か」を確認しておくことが、そのままコスト設計になります。
打ち手2：文脈量を減らす — 「全部渡す」をやめる
次に効くのが、1回あたりに送るトークン量です。特にRAG（Retrieval-Augmented Generation／検索拡張生成。社内文書などを検索し、その内容をプロンプトに添えて回答させる手法）を使うシステムでは、ここが膨らみやすい。
検索結果を何件渡すか
社内規程を検索して回答するチャットボットを作るとき、「念のため上位20件渡す」という設計をよく見ます。しかし5件で十分なら、入力トークンは4分の1です。件数を減らして回答品質が維持できるかは、評価用の質問セットを用意して比較するしかありません。この評価セットの有無が、後からコストを削れるかどうかを決めます。
会話履歴をそのまま積み上げない
チャット形式のシステムでは、過去のやり取りを毎回全部送ると、会話が進むほど1回あたりのコストが増え続けます。直近数ターンだけ原文で保持し、それ以前は要約に置き換える、あるいは一定の長さで区切る、といった設計が必要です。「長く話すほど高くなる」構造を放置すると、ヘビーユーザーほどコストを押し上げます。
出力トークンを制御する
多くのモデルで出力トークンの単価は入力より高く設定されています。「〇〇について説明して」と投げると長文が返ってきますが、業務システムで本当に必要なのは分類ラベルやJSON（データ交換用の構造化テキスト形式）の数行であることが少なくありません。
- 出力をJSONなど構造化形式に固定する
- 最大出力トークン数の上限を設定する
- 「理由も説明して」を本当に使うかどうか検討する（使わない説明文は払い損です）
打ち手3：キャッシュを設計に織り込む
キャッシュとは、一度計算した結果を保存して再利用する仕組みです。LLM利用では、性質の異なる3種類があります。
| 種類 | 何を再利用するか | 向いている場面 | 注意点 |
|---|---|---|---|
| プロンプトキャッシュ | 毎回同じ長い前置き（システムプロンプト、固定資料）の処理結果 | 共通の指示文や規程類が長いシステム | 前置きを完全に同一にする設計が必要。提供条件はベンダー依存 |
| 応答キャッシュ | 同一入力に対する回答そのもの | FAQなど定型質問が多い用途 | 内容が更新されたときの失効処理 |
| 埋め込みキャッシュ | 文書をベクトル化した結果 | RAGの文書側 | 文書更新時の再計算管理 |
プロンプトキャッシュは、主要ベンダーが2024年前後から順次提供している仕組みで、繰り返し送る前置き部分の入力単価が割り引かれます。ただし「前置きが毎回まったく同じであること」が前提になるケースが多く、プロンプトの先頭に日時やユーザー名を入れていると効かない、ということが起こります。ここは実装で詰まりやすい箇所です。設計段階で「変わらない部分を前、変わる部分を後ろ」という順序を決めておくと後が楽になります。
応答キャッシュは効果が大きい一方で、注意が要ります。問い合わせ内容に個人情報が含まれる場合、キャッシュとして保存する行為自体が個人データの取扱いにあたり得ます。個人情報保護法（2022年施行の改正を含む）や、総務省・経済産業省が2024年に公表した「AI事業者ガイドライン」を踏まえ、保存範囲・保存期間・アクセス権限を設計に含めてください。コスト削減策が、そのまま情報管理の論点になります。
打ち手4：ここで初めてモデルを選ぶ — 段階処理とルーティング
構造を整えたうえで、ようやくモデル選択が効いてきます。考え方は「全処理に同じモデルを使わない」です。
- 段階処理：まず小型・低単価モデルで処理し、信頼度が低いものだけ上位モデルに回す
- 役割分担：分類・抽出・要約は小型モデル、文章生成や複雑な判断は上位モデル
- 推論型モデルの使いどころ：じっくり考えるタイプのモデルは出力トークンが増えやすく、単価表の数字以上にコストがかかる場合があります。難しい判断に限定して使う
注意点として、ルーティング（入力内容に応じてモデルを振り分ける仕組み）自体が複雑さを生みます。分岐が増えるほどテストすべきパターンが増え、障害時の切り分けも難しくなります。月数万円のコストを削るために保守工数が増えるなら本末転倒です。削減額と保守コストを並べて判断するのが実務的です。
実装で詰まりやすい点と、見積もりの立て方
最後に、開発を発注する・内製する際にあらかじめ決めておくとよい項目を挙げます。
- 計測の仕組みを最初に入れる：機能ごと・ユーザーごとのトークン消費量を記録していないと、どこを削るべきか分かりません。後付けは面倒なので最初に入れます
- 上限とアラート：想定外のループや大量投入で請求が跳ねる事故は起こり得ます。1リクエストの最大トークン、ユーザーあたりの日次上限、月間予算アラートを設定します
- リトライ設計：失敗時の自動再試行は、設定を誤ると同じ処理を何度も課金することになります。再試行回数と条件を明示します
- プロンプトのバージョン管理：プロンプトを変えるとコストも品質も変わります。変更履歴と、そのときの評価結果を残します
- モデル差し替えを前提にする：モデルの提供終了や値下げは頻繁に起こります。特定モデルに密結合させず、差し替えられる構造にしておく
見積もりについては、「月間処理件数 × 1件あたりの入力トークン × 入力単価 ＋ 同じく出力分」という単純な式で概算を出し、そのうえで2〜3倍の幅を見ておくのが現実的です。実運用では、想定外の長文入力や再試行で想定を上回ることがあるためです。
まとめ
LLMのAPIコストは、単価表の比較ではなく、次の順番で設計すると下がりやすくなります。
- 呼び出し回数を減らす — ルールで済むものを前段で処理し、まとめられるものはまとめる
- 文脈量を減らす — 検索件数、会話履歴、出力長を見直す
- キャッシュを織り込む — プロンプト・応答・埋め込みの3種を使い分け、保存内容の管理も設計に含める
- モデルを使い分ける — 全処理に同じモデルを使わず、ただし複雑さとのバランスを取る
そして、どの打ち手も計測がなければ効果を確認できません。トークン消費のログと、品質を比べるための評価セット。この2つを初期段階で用意しておくことが、結果的に最大のコスト対策になります。
AIを組み込んだ業務システムは、作って終わりではなく、運用しながら削っていくものです。発注時には「作る費用」だけでなく「運用コストを後から下げられる構造になっているか」を確認項目に入れることをおすすめします。