- 公開日
プロンプトへトークン予算を組み込むときは、入力に使う枠、回答などの生成に使う枠、反復全体で使う枠を分けます。「短く」「600字以内」という文章量の目標と、実行環境で計測・制限するトークン数は別です。圧縮では、重複した説明から削り、判断を変える条件、出典、権限、不明点を残します。最後に結果と不足を返す余地まで確保し、上限に達したら追加の生成や検索を止める設計にします。
何の数値を管理するのかを分ける
トークンは、モデルがテキスト等を処理するときの単位です。テキストをその単位へ分ける仕組みをTokenizer（トークナイザー）といいます。同じ文字数でも、言語、記号、内容、使う方式によってトークン数は変わります。日本語一文字を固定のトークン数へ置き換えて、厳密な残量として扱うことはできません。
予算の話には、少なくとも次の異なる数値が出てきます。
| 数値 | 何を表すか | その値だけでは分からないこと |
|---|---|---|
| 文字量の目標 | 読者へ返す文章の長さや、圧縮の目安 | 実際の入力・生成トークン数 |
| 入力トークン数 | 一回の要求に渡す情報を、対応方式で数えた量 | これから生成される量、最終費用 |
| コンテキスト上限 | モデルが一回の処理で扱える範囲の仕様上の限界 | 業務全体で何回繰り返せるか |
| 生成上限 | 一回の応答で生成を許す最大量 | 必要な回答が最後まで完成するか |
| 反復全体の予算 | 複数の要求を通算して許す入力・生成等の量 | 金額上限や外部ツールの課金総額 |
コンテキストは、その回にモデルが扱う文脈です。入力だけで枠を使い切ると生成の余地が残らない方式もあるため、両方の扱いを確かめます。含め方や上限はモデルとAPIの仕様で確認します。大きなコンテキストを使えることは、毎回その枠を使い切る理由にも、反復の無制限な許可にもなりません。
OpenAIのCounting tokensは、入力の計数にメッセージ構造やツール定義などが関わることを説明しています。利用者が書いた依頼文だけを数えても、実際に送る要求全体を数えたことにはなりません。本文、添付から展開するテキスト、履歴、検索結果、ツール定義、出力形式の定義を含め、対象APIに対応する方法で確かめます。
ローカルのトークナイザーで数えた値には、使用した方式と版、対象テキストを記録します。API側に要求全体を数える機能があるなら、その対象と対応モデルも確認します。ローカル計数、APIの事前計数、実行後に返る利用量は記録欄を分け、条件の違う値を同じ「実測」として混ぜません。手元で一部だけ数えた値しかない場合は、全体の入力数を未確認として残します。
生成の上限と、見える回答の長さは一致しない
「回答を600字以内にしてください」は、出力の書き方を伝える指示です。一方、APIの生成上限は、処理をどこで打ち切るかに関わります。どちらか一つを指定すれば、もう一方も厳密に管理できるわけではありません。
OpenAIのReasoning modelsでは、推論用トークンも文脈を使い、出力として課金されること、max_output_tokensが可視回答だけでなく推論等を含む生成全体の上限になることを説明しています。上限によってincompleteとなり、見える回答がないまま費用が生じる場合もあります。この挙動は対象モデル・APIの説明であり、全製品に同じパラメータ名や計数方法を当てはめません。
したがって、600字の本文を書かせたいから生成上限を600トークンにする、という対応付けはできません。必要な回答量と生成方式を踏まえて候補値を置き、実際の利用量と完了状態で確かめます。適切な余白の量は、利用するモデルや課題で変わります。公式文書のある設定例を、すべての業務に必要な固定予算へ読み替えないことも大切です。
利用明細のoutput_tokens等に推論分が含まれている方式では、そこへ推論トークンをもう一度足すと二重計上になります。反対に、表示された回答文だけを数えると、生成全体を過小に扱う可能性があります。何を含む項目かを仕様で確認してから、予算の集計に使います。
一回の枠と、反復全体の枠を同時に確かめる
以下は計算方法を説明する架空の配分です。実在モデルの容量、実測トークン数、推奨値ではありません。テキストのみを扱い、入力と生成が一つのコンテキスト枠を使う簡略化した環境を仮定します。この例では、コンテキスト上限を10,000トークン、一回の生成上限を最大2,000トークンとします。
各回の計画では「入力の配分＋生成の配分＋余白」が10,000以下になるようにします。入力配分には、その回に渡す指示、資料、必要な履歴、構造情報を含めます。生成配分は見える文章だけでなく、この仮定環境で生成として数える全量です。余白500トークンは設計上の仮定であり、未知の追加分が何でも収まる保証ではありません。
一件の資料比較に、入力と生成の合計で最大18,000トークンを配分するとします。期間はその一業務の開始から終了までです。生成のやり直しを含む呼出しは最大3回とし、そのうち最後の1回を結果整理に残します。
| 用途 | 入力の配分 | 生成の配分 | 入力＋生成 | 余白を含む一回の計画量 |
|---|---|---|---|---|
| 初回の比較案 | 3,500 | 1,500 | 5,000 | 5,500 |
| 必要な場合の訂正 | 6,000 | 2,000 | 8,000 | 8,500 |
| 最終的な結果整理 | 3,000 | 2,000 | 5,000 | 5,500 |
| 合計 | 12,500 | 5,500 | 18,000 | 各回で確認 |
単位はすべてトークンです。整数の仮定値をそのまま足しており、丸めは行っていません。一回の計画量はいずれも10,000以下、生成配分はいずれも2,000以下です。余白は使った量ではないため、利用実績へ加算しません。ここでは余白を未割当のまま保ち、実際に必要な入力が配分を超えたら発行前に再配分または停止する前提です。
通算では、3,500＋1,500＋6,000＋2,000＋3,000＋2,000＝18,000です。結果整理の5,000を先に残すため、それ以前の二回は合計13,000までです。初回と訂正のトークン消費が配分を下回っても、回数上限を自動で増やすことにはなりません。訂正が不要なら、その枠を使い切るために処理を追加せず、最終整理へ進むか、すでに完成した回答で終了します。
この表は、各回へ同じ入力を送るという意味でもありません。訂正時には根拠や指摘が追加され、最終時には必要な状態へ整理するので、配分が異なります。同じ資料を次回にも渡すなら、その回の入力として数えます。ただし、前の入力と出力を機械的に全部足して次の入力数とせず、実際に次回へ渡す要求を数え直します。キャッシュや状態管理による課金・文脈の扱いも、利用するAPIの条件を別に確認します。
18,000は、この仮定で定義した入力と生成の総量です。検索の従量料金、保存料、人の確認費、通貨換算や税を含めた金額ではありません。入力と出力で単価が異なる場合もあり、総トークン数だけから費用削減率を算出しません。失敗した呼出しも、利用量が生じれば通算対象にします。
長い依頼から、判断を変える条件を取り出す
配分を実際の文面へ落とすため、架空の二つのサービスを比較する依頼を考えます。ここからの資料名・条項・保存日数も説明用であり、実在サービスの契約条件ではありません。
資料A第2版の保存節には「通常データは30日保持。退会後のバックアップは最長90日保持」、資料B第1版の保存節には「通常データは30日保持」と書かれているとします。Bのバックアップについては、渡された節に記載がありません。資料番号と節名は、原文へ戻るための参照情報として残します。
元の依頼は、次のような長い文章だったとします。
「担当者が保存条件を確認するための比較メモを作ってください。忙しい人が読むので、長い紹介や何度も同じことを言う文章は避けたいです。比較する資料はA第2版とB第1版の保存節だけです。通常データの保持期間と退会後のバックアップは別に扱ってください。Aは通常30日、退会後バックアップは最長90日です。Bは通常30日で、バックアップはこの節に記載がありません。記載のない条件は未確認としてください。各判断には資料の版と節を示してください。追加の外部検索はせず、分からない情報を想像で埋めないでください。顧客には送らず、私へ確認用のメモとして返してください。600字以内を目安にしますが、重要条件や不足が落ちるなら、そのことを知らせてください。」
短くする前に、目的、対象資料と版、二種類の保持期間、未確認の扱い、出典、外部検索禁止、送信先、文章量の目標を取り出します。「短く書く」という目標は残しつつ、削る候補は読みやすさの説明や同じ依頼の繰り返しに絞ります。保存日数の対象や禁止した操作を削れば、依頼そのものが変わるためです。
圧縮の良し悪しを、短さ以外で比べる
例えば「A・Bは30日保存。600字以内で比較して」と縮めると、Aのバックアップ例外、Bの不足、対象版、出典、検索と送信の制限が消えます。短くても、AとBが同じ保存条件だという誤読につながるため採用できません。
圧縮案は、次のようにします。
「私向けの保存条件比較メモ。根拠はA第2版・B第1版の保存節のみ。A：通常30日、退会後バックアップ最長90日。B：通常30日、バックアップは当該節に記載なし。通常とバックアップを分け、欠落は未確認と表示。各判断に版・節を付ける。外部検索・顧客送信は禁止。600字以内を目安とし、重要条件や不足を省けない場合はその旨を報告する。」
この圧縮案は未実行です。文章を短くしただけで、トークン数や回答の改善を測定したことにはしません。次の対応表で、元の依頼と同じ判断ができるかを照合します。
| 保持するもの | 圧縮後に確かめる点 | 欠けた場合の扱い |
|---|---|---|
| 範囲と出典 | A第2版・B第1版の保存節に限定されるか | 参照先を戻し、資料全体への一般化を外す |
| 数値と例外 | 通常30日と退会後バックアップ最長90日が分かれるか | 数字の対象と「最長」を戻す |
| 不足の状態 | Bの当該節の不記載が未確認として残るか | 保持なし・0日という推測を削る |
| 許された操作 | 外部検索せず、依頼者への確認メモにとどまるか | 検索と顧客送信の禁止を戻す |
| 終了時の対応 | 目標文字量に収まらない理由を報告できるか | 条件を黙って削らない指示を戻す |
期待する回答は、通常保持の数字は同じでも、Aには別のバックアップ条件があり、Bの当該節だけでは比較が完成しないと示すものです。Aの30日と90日を足して120日とすることも、Bに条件がないと断定することも避けます。次の対応は、依頼者が不足資料を確認することです。追加検索を禁止したまま、エージェントが別の資料を取りに行くことは認めません。
圧縮前後を同じ計数条件で確認する
圧縮の比較では、同じモデル・版、同じ計数方法、同じ資料、同じ出力基準を固定し、依頼文の表現だけを変えます。両方について、実際に送る全入力を組み立ててから数えます。短い依頼文に直しても、そのほかの履歴やツール定義が増えていれば、全入力が減るとは限りません。
計数記録には、圧縮前と後の対象ファイルまたは版、計数日時、対象モデル、トークナイザー等の方式、入力に含めた項目、返された値を残します。まだ数えていない欄は「未計測」です。仮定の配分表へ当てはめた数値を、計数ツールの出力に置き換えて記録しません。本例ではトークナイザーやAPIを呼び出していないため、圧縮前後の実トークン数は未計測です。
文字数を実際に数える場合も、改行・空白・記号を含めるかを決め、同じ方法で比べます。その差は文字量の差です。実トークン数の差や、費用の差へ自動換算しません。数値比較に加えて、上の対応表と原資料へ戻り、意味と許可範囲を確認します。
実際の応答を評価するなら、数値の対象、例外、出典、不明点、禁止した操作を守れたかを別に判定します。トークンが減ってもAの例外が落ちれば、その圧縮案は不採用です。未実行なら合否を作らず、何を比較すれば採用を判断できるかという計画を残します。圧縮を別のモデルへ任せる場合は、その入力・生成と確認も追加の処理です。上の三回の配分へ黙って追加せず、予算と権限を組み直します。
上限では、不足を残して終了する
実行前には、その回の実入力が配分内か、生成に必要な枠があるか、通算の残りで最終整理まで進められるかを確認します。入力が大き過ぎるなら、重複の整理、不要な履歴の除外、対象資料の絞込みを検討します。対象を狭めることで依頼の意味が変わるなら、依頼者へ確認します。制限や出典だけを削って枠へ押し込む方法は採りません。
実行後は、使用量と完了状態を読みます。上限による途中終了を、完成した比較メモとして出してはいけません。未完の構造化データを下流の処理へ渡したり、不足する欄を推測で埋めたりせず、どこまで確認できたかを区別します。利用量の取得に失敗した場合も、消費がゼロだったとみなして次の呼出しを許可しません。
残量を使って結果整理ができる場合は、「Aの通常30日と退会後バックアップ最長90日は指定節で確認。Bのバックアップ条件は未確認。追加調査は行わず終了」と、確認範囲と不足を示します。これも期待する出力の例です。最終入力を3,000以内へ収められず、重要条件を保てない場合は、無理にその生成を発行しません。
残量がない、または生成上限で終了報告すら完成しない場合に備え、実行側で保存している確認済み項目と状態から定型の終了表示を返せるようにします。例えば「処理上限に達したため比較は未完了。取得済み資料と未確認項目を保存しました」と表示し、実際に保存した項目の参照先を添える設計です。保存が失敗したなら、保存済みとは報告しません。
プロンプトは、何を優先して残し、どう不足を伝えるかを決めます。計数と上限の適用は実行環境が担当し、追加範囲や再開は依頼者の判断につなぎます。圧縮案を採用するときは、計数記録だけでなく、残した条件と出典の対応、上限で終了した際の出力も確認します。
トークンの制約に合わせて長文を分割し統合する方法は「トークン制約に合わせて長文を分割し統合する方法」で解説しています。
