📚

【LLM基礎#2】コンテキスト長とトークンコストを理解し、運用で最適化する

に公開
LLM
tech

この記事のねらい（ゴール）

  • LLMの料金は 入力トークン + 出力トークン で概ね決まると理解する
  • コンテキスト長（一度に処理できる上限）が不具合の原因になることを理解する
  • 運用者として、品質を落とさずにトークンコストを下げる実践手段を理解する

1. コンテキスト長とは？

LLMは「一度に読めるトークン数」に上限（= コンテキスト長）がある。文字数ではなくトークン数で数える点に注意。

代表例（目安）：

  • GPT-3.5: 約 4,096 tokens
  • GPT-4 Turbo: 約 128,000 tokens

この枠には以下すべてが含まれる：

  • システム／ツールの指示
  • あなたの入力（プロンプト）
  • 会話履歴
  • これから出力する分（= 余白が必要）

入力が長すぎると、出力用の余白が足りず 途中で切れる／古い履歴が 参照できない などの症状が起きる。

2. トークン数を実際に数える

#1で触れた tiktoken を使えば、文章のトークン数を確認できる。

import tiktoken
enc = tiktoken.get_encoding("cl100k_base")

text = "これはトークン数がいくつになるか調べるテストです。"
tokens = enc.encode(text)
print(tokens)
print(f"トークン数: {len(tokens)}")

出力例：

[1930, 1218, 539, 276, 107, 26891, 358, 1251, 25477, 109, 40633]
トークン数: 11

日本語は英語よりトークンが増えやすい。見た目が短くてもトークンは多いことがある。

3. 料金の考え方（ざっくり式と試算）

LLMの料金は概ね

総コスト ≒ (入力トークン × 単価_in) + (出力トークン × 単価_out)

単価はモデルやプランで変わるため、最新の料金表を必ず確認すること。以下は 例（仮の値）：

  • 入力: 1,000 tokens あたり 0.01 USD
  • 出力: 1,000 tokens あたり 0.03 USD

簡易試算スニペット：

def estimate_cost(in_tokens, out_tokens, rate_in=0.01, rate_out=0.03):
    return (in_tokens/1000)*rate_in + (out_tokens/1000)*rate_out

print(estimate_cost(1800, 400))  # 例: 0.022 USD

4. コンテキスト制限で起きることと対処

4.1 応答が途中で切れる

  • 原因：出力用トークンの余白不足
  • 対処：プロンプト短縮／履歴削減／max_tokens の見直し

4.2 会話の前半を忘れる

  • 原因：古い履歴が上限で切り落とされる
  • 対処：重要事項を毎回明示／要約を挟む／長期記憶はRAGで補う

4.3 料金が想定より高い

  • 原因：冗長な入力・過剰な出力
  • 対処：構造化（JSON/箇条書き）で短縮／不要な定型文を削除

5. コスト最適化の実践アプローチ（運用者向け）

5.1 プロンプト設計

  • 冗長表現を削る（例：「〜させていただきます」→「〜します」）
  • 長文説明より JSON/箇条書き を使う
  • few-shot は最小限にまとめ、共通部分はテンプレ化

5.2 履歴の扱い

  • 履歴を丸投げしない。必要部分だけ を抜粋
  • 長い履歴は 要約 して圧縮
  • 重要データは会話に混ぜず、外部参照（RAG/DB） で読む

5.3 モデル使い分け

  • 日常処理は 安価モデル、難問のみ 高性能モデル
  • 出力の上限 max_tokens を設定し暴走を防止

5.4 RAGの最適化

  • 必要な断片だけ を検索して渡す（全文貼らない）
  • チャンク設計を調整（大きすぎ＝浪費、小さすぎ＝検索精度低下）

5.5 運用・モニタリング

  • ユーザ/部署別に トークン使用量ダッシュボード を可視化
  • よくある問合せは キャッシュ で再利用
  • 利用ガイドラインの整備（「簡潔に」「要約して入力」）

6. Before/After 例（20〜50%削減のイメージ）

Before（自然文）

弊社の四半期売上の傾向について詳しく分析いただけますでしょうか。可能であれば、前年同期比の観点や主要な製品カテゴリごとの内訳なども含めて、包括的にご説明ください。

After（構造化＋簡潔）

目的: 四半期売上の傾向
要件: 前年同期比/製品カテゴリ内訳
出力形式: 箇条書き3点 + 1行サマリ

→ 指示の意図は保ちつつ、トークンを大幅削減。出力も短くなりやすい。

7. 運用チェックリスト（配布用）

  • 入力プロンプトは冗長でないか（定型の丁寧語を削除）
  • JSON/箇条書きなど構造化しているか
  • few-shot の例は最小限か／共通化されているか
  • 履歴は必要部分だけか／要約しているか
  • 長期知識はRAGで外出ししているか
  • モデルは使い分けているか（安価モデル優先）
  • max_tokens を設定しているか
  • トークン使用量の可視化・レポートがあるか
  • キャッシュ・テンプレートを活用しているか

まとめ

  • コンテキスト長は仕様。超えると出力が切れる/履歴が欠落する
  • 料金は トークン数 に比例。短く・構造化 が効く
  • 運用では、プロンプト設計／履歴管理／モデル使い分け／RAG最適化／モニタリング の5本柱で継続改善する

次回（#3）予告

生成のコントロール（Temperature / Top-p / Top-k）を取り上げ、
「同じ質問でも答えが違うのはなぜ？」を実験で確認します。

Discussion