言語モデルはトークンを読み、トークンを書き、その両方に対して課金されます。トークン最適化とは、回答を良くする場所にだけトークンを使うことです。うまくやれば、コストと遅延が下がり、焦点の絞られたプロンプトは従いやすいので、品質も上がることが多いです。
トークンとは
トークンは、モデルの語彙に含まれるテキストの断片です。単語、単語の一部、句読点、あるいはスペースと単語の組み合わせなどです。英語の文章では、おおまかに 1 トークンあたり 4 文字、つまり単語の 4 分の 3 というのが目安です。この目安は、よく外れます。
- コード、JSON、珍しい識別子は、文章よりトークンを多く使います。
- 英語以外の言語は、単語あたりのトークン数が多くなりがちです。
- プロバイダーごとに独自のトークナイザーがあるため、同じテキストでもモデルごとにトークン数が異なります。
本物のトークナイザーで数える
見積もりは最初の目安としては十分でも、予算には不向きです。OpenAI はトークナイザーを公開しているので、オフラインで正確に数えられます。Anthropic と Google はトークン数を数えるエンドポイントを提供しており、それがなければ数値は近似になります。
PromptFlowEngine はこの区別に従っています。OpenAI のモデルはそのトークナイザーで計算して「正確」と表示し、他のプロバイダーは「近似」と表示します。プロンプトはワークスペースまたは HTTP API で確認できます。
curl -s https://promptflowengine.com/api/v1/tokens \
-H 'content-type: application/json' \
-d '{"prompt":"Summarize the notes below in 5 bullets.","model":"gpt-4.1"}'
コストの出どころ
1 回の呼び出しのコストは、入力トークン × 入力単価 + 出力トークン × 出力単価です。あらゆる最適化を左右する事実が 3 つあります。
- 出力トークンは通常、入力トークンの数倍のコストがかかります。 回答の長さを制限するほうが、プロンプトを削るより節約になることがよくあります。
- プロンプトの固定部分は、呼び出しのたびに支払います。 100 万回実行されるシステムプロンプトで 50 トークンを無駄にすると、5,000 万トークンになります。
- 会話やエージェントのループでは、履歴が毎ターン再送されます。 コストはターン数より速く増えます。
プロンプト圧縮：何を削るか
最も安全な削減から、最もリスクのあるものへ順に進めます。
つなぎ言葉と丁寧表現。 「こんにちは」「お願いします」「〜していただきたいのですが」「〜ということに注意してください」。これらは指示を含みません。
Before: Hello! I would like you to please summarize the notes below.
Please make sure to keep it brief.
After: Summarize the notes below in 3 sentences.
繰り返し。 同じ指示が 2 回書かれていることがあります。何か月も編集を重ねて、別のセクションに現れていることも多いです。
回りくどい表現。 「〜するために」は短く、「〜という事実のために」は「〜ので」にします。
使われていない文脈。 どのテストケースも依存していない背景情報。削除して、テストをやり直します。
過剰な例。 8 個ではなく 3 個の例を試し、測定します。
冗長な形式。 長いキーでインデントした JSON は、短いキーのコンパクトな JSON よりコストがかかります。プロンプトに挿入するデータには、コンパクトな形式が呼び出しごとにトークンを節約します。
最初の 3 つは機械的に行えます。PromptFlowEngine のプロンプトオプティマイザーはそれらを適用し、元の文、要件、コードブロック、変数がすべて残っていることを検証します。ここは手作業で確認すると手間のかかる部分です。
削ってはいけないもの
- 要件と制約。 ルールが抜けた短いプロンプトは、別のプロンプトです。
- 出力形式。 削っても 10 トークンの節約にしかならず、パーサーを失います。
- 入力を囲む区切り。 安価で、インジェクションを防ぎます。
- 構造。 セクションの見出しは数トークンのコストで、遵守率を高めることがあります。冠詞や接続語を削ぎ落とした過度に圧縮されたテキストは、モデルには曖昧になり、次に編集する人には読めなくなります。
コンテキストウィンドウの最適化
コンテキストウィンドウは、モデルが一度に考慮できるトークンの最大数で、入力と出力の合計です。ウィンドウは非常に大きくなり、問題は「収まるか」から「そこにあるべきか」に変わりました。
文脈を増やすのは無料ではありません。 コストと遅延のほかに、入力が増えると品質が下がることがあります。数千の無関係なトークンに囲まれた関連する一節は、モデルにとって使いにくくなります。タスクに必要なものを送りましょう。
すべてを含めるのではなく、検索する。 質問に関連する一節を検索し、それだけを挿入します。RAG のプロンプティングを参照してください。
長いプロンプトでは順序が重要です。 多くのモデルは、長い入力の冒頭と末尾に最もよく注意を向けます。長いドキュメントを先に、質問や指示をその後に置くか、重要な指示を末尾で繰り返します。
会話履歴を管理する。 古いターンを要約し、不要になったツールの結果を捨て、話題が変わったら新しい会話を始めます。
回答用の余地を残す。 入力がウィンドウを埋めると、出力が途中で切れます。想定する最長の回答の分を空けておきます。
作業を分割する。 プロンプトチェーンなら、各ステップに必要な文脈だけを渡せます。
キャッシュを使う
主要なプロバイダーはプロンプトキャッシュを提供しています。プロンプトの先頭が最近のリクエストと一致すると、繰り返し部分は割引料金で課金され、処理も速くなります。恩恵を受けるには、次のようにします。
- 変わらない内容を先頭に置く：システムプロンプト、ツール定義、例、参照ドキュメント。
- 変動する内容を最後に置く：ユーザーの質問と、リクエストごとのデータ。
- 呼び出しの間で、タイムスタンプのように変わるものを固定部分に入れない。
キャッシュは、長くて固定のプロンプトをずっと安くします。ただし、無関係な文脈による品質面のコストはなくなりません。
出力の長さを制御する
- 数を指定する：「100 語以内」「ちょうど 5 項目」。
- 必要なものだけを頼む：説明付きのラベルではなく、ラベルだけ。
- API の最大出力トークン数を、強制的な停止として設定する。
- 推論モデルでは、単純なタスクで推論の労力を下げる。
予算を決めて、強制する
本番の各プロンプトが使えるトークン数を決め、自動でチェックします。プロンプトテストゲートは、プロンプトファイルがトークン上限を超えるとビルドを失敗させます。
{ "include": ["prompts/**/*.md"], "model": "gpt-4.1", "maxTokens": 1500 }
これで、トークンの増加は請求書で気づくものから、プルリクエストでレビューするものに変わります。測定によってプロンプトを改善する、より広いプロセスについては、プロンプトの最適化を参照してください。