背景
AIプロダクト開発の過程で、ユーザー数の増加に伴い、LLMを呼び出すたびにプロンプトに対してコストが発生します。結果に影響を与えずに、いかに不要なコストを極限まで削減するかが課題です。
LLMの料金体系
ここではOpenAIを例に説明します。

最新のOpenAI APIのトークン課金構造は次の通りです:
Input 入力: Cached inputの10倍の価格で、Outputの1/10の価格
Cached input キャッシュ済み入力: 最安で、Inputの1/10、Outputの1/100の価格
Output 出力: 最も高価で、Inputの10倍、Cached inputの100倍の価格
旧バージョンのLLM(例:gpt-4oシリーズ)では、Cached inputのトークン料金が廃止されています。
推奨対策
1, ユーザーに短く、確定性の高いキーワードを入力させる
ここで使うのは「ユーザーに促す」ことであり、「ユーザーの入力を制限する」ことではありません。
企業向けの完全なAIAgentの場合、ユーザーの入力メッセージの長さを制限できません。なぜなら、ユーザーの入力は意味を完全に保ってLLMへ送信される必要があるからです。
ユーザーに短い文章を入力させることで => コンテキストのトークン長を効果的に減らせる
ユーザーに確定性の高い文章を入力させる(あいまいな文章でなく) => モデルの生成精度が向上し、幻覚を減らせる
ユーザーにキーワードを入力させる => 検索精度が向上し、同時にコンテキストのトークン長も削減できる
2, LLMの出力長を制限する
LLMの出力も最もコストが高いので、プロンプトで
固定長の出力を明示的に指示したり、要約や概要的な表現で出力させる
=> Outputのトークン長を効果的に削減できる
3, LLM呼び出し回数の削減:メモリ設計が重要
呼び出すたびにOpenAIが自動的にCached inputを計算しコストを下げるものの不確実性があり、会話履歴の保存が重要となります。
ここでのメモリは長期・短期記憶を含みますが、本記事ではトークン使用削減を目的としたメモリ設計に限定します。
短期間でのユーザーの重複質問は毎回LLM呼び出し不要で、会話履歴から検索することで => LLM呼び出し回数を減らせる
Cached inputの設計原則は「変更しないものは極力変更しない、単語も変えない」ことです。
1, メモリ内の会話履歴はカテゴリ分けし、類似質問はまとめる => 検索精度向上とLLM呼び出し回数減少に貢献
2, メモリ内の会話履歴は要約する => 次回の会話入力時のコンテキストトークン長を減らす
4, プロンプト圧縮アルゴリズムの活用
構造化されたプロンプトは一般的に長くなりがちで、トークン数に影響するため、
ここではプロンプト圧縮アルゴリズム「LLMLingua-2」を紹介します。
詳細解説は割愛しますが、興味があれば調べてみてください。
5, プロンプトの書き方:Cached inputを最大限活用する
以下は説明のために中国語で記述していますが、実際は英語で書くのが望ましいです。
LLMを呼び出すたびにプロンプトは使用されます。
プロンプト内の指示文はユーザーの入力やRAGの検索結果などに応じて調整・補完されます。
コスト削減のためCached inputを最大限活用するには、プロンプト内の順序を変えて固定部分をキャッシュさせる必要があります。
例:
prompt = “
あなたは財務諸表に基づきリスク分析に長けたビジネスケース分析者です。
以下の背景情報を既に知っています:
{Background_msg}
そして財務諸表の内容:
{Financial_msg}
ユーザーの質問に基づき:
{question}
回答を返してください。
返却フォーマット:
return:
{
result:""
}
”
一見問題ないプロンプトに見えますが、Cached inputのルールでは最初の2行しかキャッシュされません。
以下はCached inputのルールに沿い修正したプロンプトです:
cached_prompt = “
あなたは財務諸表に基づきリスク分析に長けたビジネスケース分析者です。
背景情報と財務諸表内容を踏まえ、ユーザーの質問に基づいて回答してください。
返却フォーマット:
return:
{
result:""
}
背景情報: {Background_msg}
財務諸表内容: {Financial_msg}
ユーザーの質問: {question}
”
Cached inputルールにより、修正後のcached_promptは最初の7行がキャッシュされ、料金はInputの1/10になります。
6, 本当にLLMを呼び出す必要があるか
例:
半構造化または非構造化の文書をベクトルDBに保存する際に、正確性向上のためにLLMで原文を構造化形式(例:json)に変換するべきか。
この場合の代替案:
1, 正規表現フィルタリング
2, ルールベース解析
3, XGBoost分類アルゴリズム
4, キーワード検索
で半構造化文書を構造化データに変換する方法があります。
詳しくは以下の記事を参照してください:「RAGのStructural Chunks設計」
7, 結果品質を損なわずにLLMを切り替え可能か
同一シリーズ内のGPT-5モデルへの切り替えを推奨しますが、大量の生成結果テストが必要です。
最新モデルが必ずしも最高とは限らず、モデルごとに得意な機能が異なるため、AIエンジニアによる検証と判断が求められます。
8, LLMのAPI呼び出しは必須か
例えば、WhisperモデルのAPIで音声を文字起こしするにはコストがかかります。
一方、Whisperをローカルでデプロイすれば無料です。
TTSも無料利用可能な代替案が多く存在します。
9, ユーザー入力の長さ制限:Max_tokens
特定のAIAgentに基づき以下を判断します。
1, Max_tokensの設定の要否
2, 最大Max_tokensの値
私見ですが、
企業向けAIAgentで社内専用の場合は設定不要です。企業内ユーザーはトークンを過剰消費しにくいためです。
外部ユーザー向けの場合はMax_tokensを設定し、使用トークンの監視・制限が必要です。
10, プロンプトは英語で書くのが望ましい
平均的に
英単語 1語 = 0.75 token
中国語 1語 = 1.0 token
11, promptの長さ制限
“Promptのコンテキスト管理とフィルタリング”
まとめ
1回あたりの課金はわずかでも、1万人が10回使うと大きなコストになる。