API利用コスト管理術

設計で7割決まる：モデル選択とプロンプト最適化

API料金は「入力トークン＋出力トークン」に単価が掛かる従量制が基本です。したがって、最初の設計で無駄を作らないことが最大の節約になります。用途に応じたモデル選択から着手しましょう。要約・分類・ルーティングは小型モデル、創作や長文生成は大型モデルという役割分担が定石です。例として、一次判定は軽量なChatGPTやGeminiの廉価グレード、最終生成のみClaudeの高性能グレードに回す二段構成は現場で効きます。

プロンプト最適化も実コストに直結します。systemメッセージは使い回しできる最短テンプレートに圧縮し、出力はJSONのスキーマを明示して冗長文を抑えます。会話機能では履歴をそのまま積まないで、過去発話を数文に要約してから付け直す「履歴蒸留」を標準化します。max_tokensは機能ごとに上限値を設定し、n=1固定、temperatureは要件に応じて下げると暴走を防げます。

トークンの“固定費”を削る

• 定型の前置きは短いタグ化（例：「役割=法務_要約」など）して毎回の長文説明をやめる
• RAGでは取得テキストの重複を除去し、要点見出し＋抜粋の形で渡す
• 画像生成（MidjourneyやStable Diffusion）もプロンプトを差分管理し、共通スタイル指示はプリセット化

二段推論とルーティング

同じ質問でも難易度は揺れます。まず小型モデルで「難易度・機密度・必要出力形式」を判定し、しきい値を超えたときだけ高性能モデルへルーティングします。判定の信頼度と回答の長さ想定から「期待コスト=単価×想定トークン」で自動選択すると、品質を落とさずに平均単価を下げられます。

観測とガードレール：使い過ぎを防ぐ運用

設計の次は可視化です。コストは「見えれば下がる」が実感値。ログには必ずrequest_id、tenant_id、feature、model、tokens_in/out、price_estimate、latency、retry回数を入れ、15分粒度で集計します。ダッシュボードは機能別のCPL（Cost Per Launch/呼び出し当たり）、p95トークン、失敗率を並べると意思決定が速くなります。

• ガードレール1：機能別・テナント別の日次/月次クォータ。超過時は自動的に廉価パスへフォールバック
• ガードレール2：プロンプト長とmax_tokensに上限。動的に上限を下げる節電モードを用意
• ガードレール3：残高/原価アラート（閾値・増分の両方）と締め日前の自動スロットル

リトライ方針と重複課金の回避

429/5xxのみ指数バックオフで再試行し、アプリケーション側はidempotency keyを付与。生成系は再試行で別回答になりがちなので、機能により「前回の下書きで続行」か「厳格に同一結果を求める」かを分けます。ストリーミングは途中中断でも課金が走るため、長文機能は段落単位の分割生成が無難です。

キャッシュと再利用：RAGと埋め込みの現実解

同じ質問・同じ文脈なら、毎回推論する必要はありません。まずは語彙ベースの簡易キャッシュ（プロンプト＋上位ドキュメントIDのハッシュ）でヒットを取り、次にベクトル類似のセマンティックキャッシュを重ねます。埋め込みの再計算は「ドキュメント更新時のみ」が原則です。更新頻度の低い知識は夜間バッチで再構築し、オンライン書き込みは最小限に抑えます。

ドキュメント側を軽くする

• チャンクは300〜500トークンを目安、top-kは3〜5。取りすぎるほどコストが跳ねる
• 再ランキングは軽量モデルで十分。大型LLMでの再ランキングは最後の手段
• 図表やコードは要点抽出して短文化。モデルに向かない入力は事前に構造化

画像生成のA/B検証は高コストになりがちです。スタイルを固定し、変数（被写体・構図・ライティング）のみを回すと試行回数が抑えられます。高頻度のサムネイルはStable Diffusionの社内推論、キャンペーンだけMidjourneyの高品質を使う二層運用も選択肢です。

身近な企業活用例：中堅ECが月次コストを55%削減

顧客問い合わせの一次応答にLLMを導入しました。当初はChatGPTの高性能グレードで全問い合わせを処理し、会話履歴をフルで投入。1件あたり入力が平均8,000トークンに膨らみ、月間5万件のピークで原価が想定の2倍に。さらにタイムアウト時の無制限リトライで重複課金も発生しました。

改善策は次の通りです。一次分類をGeminiの廉価モデルに切替、FAQ命中時はテンプレ回答で即返。未解決のみClaudeへルーティング。履歴は要約して上限1,200トークンに圧縮。RAGはtop-kを5→3に見直し、重複文を除去。プロンプトはJSON出力に固定し、max_tokensを機能別に設定。APIゲートウェイにidempotency keyとテナント別クォータを実装。結果、平均入力は8,000→1,200トークン、失敗率は2.1%→0.6%、月次コストは55%減、応答中央値は3.2秒→2.1秒に改善しました。品質アンケートは横ばいで、コストだけが綺麗に下がった好例です。

教訓は明確です。高性能一本足ではなく、役割分担と観測、そして「入れる文字を減らす」。この3点が効きます。

明日からできるチェックリスト

• 機能ごとにモデルの役割表を作る（一次判定/最終生成/再ランキング）
• systemプロンプトを200文字以内に圧縮、履歴は要約して差し替え
• ログにtokens_in/outとprice_estimateを必須化、15分集計のダッシュボードを用意
• テナント/機能別のクォータと自動フォールバックを実装
• RAGはチャンク300〜500・top-k 3〜5・重複除去を標準設定
• リトライは429/5xxのみ、idempotency keyで重複課金を防止

生成AIプラットフォーム事業では、マルチモデル・マルチテナントの原価をリアルタイムに観測し、ワークロードへ最適に割り振る設計が土台になります。上記の設計・運用・再利用の3点を押さえると、機能拡張のスピードを落とさずに原価をコントロールでき、プラットフォームとしての信頼性と継続性が自然と積み上がります。