ゲーム開発者が長時間のAI対話コストを見積もる方法
ゲーム内での長時間のAI対話にかかるコストを見積もるには、完全なプレイヤーセッション全体で使用されたトークンを測定し、未キャッシュの入力、キャッシュされた入力、出力を分類した上で、選択したモデルの最新レートを適用します。最後に、各対話長でプレイヤーが実際に行ったセッション数で結果を加重平均します。短いプロンプトでのテストや単一の「平均的」セッションだけでは、後半のターンで繰り返し送信される履歴や、キャッシュミス、異例の長時間プレイセッションを見落としてしまう可能性があります。
1. 見積もる単位を定義する
まずは明確な単位を選択します。例えば、対話セッションごと、アクティブプレイヤー日ごと、または1,000セッションあたりのモデル推論コストなどです。セッション単位の見積もりの場合、セッションの開始と終了のタイミングを定義します。実践的なルールとしては「最初の対話リクエストから、リクエストがないまま30分経過するまで」などが挙げられますが、このタイムアウト設定は測定上の選択肢であり、普遍的な基準ではありません。他の開発者が見積もりを再現できるよう、設定内容を記録しておきます。
プレイヤーのメッセージ数だけでなく、モデルへのリクエスト数をカウントします。1回のインタラクションで複数の呼び出しが発生する場合があり（例えば、応答に続いて個別のツール処理呼び出しが行われるなど）、リトライによってさらに増加することもあります。ゲームが音声、画像入力、情報検索（RAG）、またはツールを使用している場合は、それらの関連モデルトークンを記録するだけでなく、コスト項目としても分けて管理してください。プロバイダーの価格設定には、通常のテキストトークン料金に加えて、ツールの利用手数料やモダリティ固有のレートが含まれる場合があります。例えばOpenAIでは、個別のツール料金が設定されており、組み込みツールに使用されるモデルトークンは選択したモデルのレートで請求されると記載されています（OpenAI API pricing）。
2. リクエストあたりの実際のトークン数を測定する
呼び出しごとに、プロバイダー、モデル識別子、タイムスタンプ、セッション識別子、リクエストの目的、入力トークン数、出力トークン数、およびレポートされたキャッシュトークンや思考トークンの内訳をログに記録します。リトライ、エラー、ツール呼び出し、および呼び出しが完了したかどうかも記録します。個別に正当化される製品上の目的がない限り、対話内容自体の保存は避けてください。コストの見積もりには、通常、トークンの合計数と運用メタデータがあれば十分です。
主要な測定値として、完了した呼び出しからプロバイダーから報告された使用量（usage）を使用します。実行前のトークンカウント（Preflight counting）はプロンプトの構成をテストするのに役立ちますが、最終的な請求項目と一致しない場合があります。OpenAIのドキュメントによると、報告される出力トークンには一部のフォーマットやツールの構造トークンなど、表示されるテキスト以外のトークンも含まれるため、プレイヤーに見える内容だけで出力を推定しないよう推奨されています（OpenAI token-counting guide）。GoogleのGeminiのドキュメントでも同様に、使用量メタデータ内でプロンプト、キャッシュされたコンテンツ、候補出力、思考トークンの数が区別されています（Gemini token guide）。
新規プレイヤー、リピーター、短い会話、長い会話、そして本番環境のプロンプトとツール設定を含む代表的なサンプルを作成します。セッションをサンプリング単位として維持してください。40ターンの対話は、40回の独立したプレイヤーセッションとして扱うのではなく、累積コストを伴う1つの観測値として残す必要があります。プロトタイプの段階では、スクリプト化された固定の会話セットがプロンプトの変更を比較するのに役立ちますが、ローンチ後は、実際に観測されたセッションに基づいて予測を立てる必要があります。
3. 履歴の増大とコンテキストの再利用を考慮する
多くの対話システムでは、各リクエストに現在のユーザーターンの内容に加え、会話履歴の一部またはすべてが含まれます。履歴が繰り返し再送信される場合、各プレイヤーメッセージが短くても、ターンごとに入力トークンが増加する可能性があります。モデルに送信される実際のリクエストペイロードを測定してください。実装が毎回本当に同じ量を送信している場合を除き、1ターンのプロンプトサイズにターン数を掛けるだけの計算は避けてください。
キャッシュを適用すると、対象となる繰り返しの入力に適用されるレートが変わりますが、これは対話全体が無料になることや、セッションが継続しているからといってキャッシュヒットが保証されることを意味するわけではありません。OpenAIは、プロンプトキャッシュを変更のないプロンプトプレフィックスの再利用と説明しており、新しい入力は依然として処理される必要があると指摘しています。同社のキャッシュ診断機能は、キャッシュ読み取りとミスを測定するのに役立ちます（OpenAI prompt-caching guide）。Anthropicも同様にキャッシュ書き込みとキャッシュ読み取りを区別しており、個別のレートとキャッシュ保持期間を公開しています（Anthropic pricing and prompt caching）。
テレメトリでは、プロバイダーが報告している場合、未キャッシュの入力トークン、キャッシュされた入力トークン、およびキャッシュ書き込みトークンを分離します。対象リクエストで割ったキャッシュヒット率と、実際にキャッシュとして請求された入力トークンの割合を記録します。これらは異なる問いに答えるものです。繰り返されるプレフィックスが小さい場合、リクエスト全体でのヒット率が高くても、キャッシュされた合計トークンの割合はわずかである可能性があります。キャッシュの適用条件、最小サイズ、有効期限、プロンプトプレフィックスの安定性、モデルのサポート状況はプロバイダーによって異なります。使用状況データで確認された削減額のみをカウントしてください。
4. 透明性のある計算でレートを適用する
100万トークン単位で価格設定されているモデルの場合、各セッションを次のように計算します。
セッションコスト = (未キャッシュ入力 × 入力レート + キャッシュ入力 × キャッシュ入力レート + キャッシュ書き込み × キャッシュ書き込みレート + 出力 × 出力レート) ÷ 1,000,000 + その他適用される料金
デプロイされた構成における、正確なモデル、エンドポイント、モダリティ、リージョン、およびサービス層のレートを使用します。レートやモデルカタログは変更されるため、予算を準備する直前にプロバイダーの価格ページで個別に確認してください。キャッシュが保存されたトークンとその期間に対して課金される場合は、ストレージ料金も含めます。例えば、Geminiの公開価格では、有料利用向けのトークンカテゴリと特定のコンテキストキャッシュ構成向けのストレージ時間あたりの価格が記載されており、課金ドキュメントでは入力、出力、キャッシュされたトークン、およびキャッシュストレージ期間が課金対象要素として指定されています（Gemini pricing、Gemini billing）。
計算例を作成すると、前提条件が可視化されます。単なる説明のための仮定として、1つのセッションに割り当てられた測定呼び出しに、18,000の未キャッシュ入力トークン、12,000のキャッシュ入力トークン、および6,000の出力トークンが含まれているとします。2026年12月31日までの利用向けに公開されているGemini 3.8 Flashの有料層レート（100万入力トークンあたり0.75ドル、100万キャッシュトークンあたり0.075ドル、100万出力トークンあたり3.75ドル）を適用すると、適用されるキャッシュストレージやその他の料金を除いて、$0.0135 + $0.0009 + $0.0225、つまり0.0369ドルになります。この例は、記載されたキャッシュトークンがキャッシュレートで請求され、測定された合計値の外部にある初期キャッシュ作成コストは含まれていないことを前提としています。これらのレートには有効期限があるため、それ以降の期間を見積もる際には再確認する必要があります（Gemini pricing）。
5. セッション長の分布を活用する
恣意的に選んだ1つの「典型的な」セッションにプレイヤー総数を掛けて予測と呼ぶことは避けてください。観測されたセッションをターン数やその他の有用な長さの区分ごとにグループ化し、各区分内の平均コストを計算した上で、各区分をセッション全体のシェアで重み付けします。平均値と合わせて中央値および上位パーセンタイルも記録してください。平均値はセッション数を掛けたときの合計使用量を見積もるのに役立ち、パーセンタイルは短いセッションや異例に長いセッションにどれだけのコストがかかるかを把握するのに役立ちます。
例えば、サンプルに短いセッションが多数あり、非常に長いセッションがごく少数含まれている場合は、各区分におけるセッションのシェアと各区分のコストの両方をレポートします。そうすることで、10,000セッションの予測は、すべてのセッションが全体の中央値に類似していると仮定するのではなく、「区分内のセッション数 × 区分内の平均コスト」の合計として計算できます。ゲームモード、言語、プラットフォーム、新規とリピーターの違いによって使用量が大きく異なる場合は、それらを合算する前に層化します。セグメント化の選択は分析上の判断です。各セグメントがトークン使用量やリクエストの挙動を変化させる理由を説明できるようにしてください。
6. 不確実性を文書化し、見積もりを更新する
サンプル収集日、セッション境界のルール、モデルとエンドポイント、プロンプトのバージョン、観測されたセッション数、キャッシュヒットの定義、価格ページの確認日、含まれる料金、除外されるコンポーネントを簡潔な前提条件記録として保持します。根拠のないバッファを適用するのではなく、セッション長の構成比、出力サイズ、測定されたキャッシュヒット率などの観察可能な入力を変更して、低・中・高のシナリオを提示します。観測されたセッションを超えた将来の予測行動は、測定された事実ではなく、明示的なシナリオとして扱ってください。
見積もりの完全性は、測定機構と課金対象カテゴリの網羅性に依存します。ロガー外でルーティングされた呼び出し、リトライ、APIで公開されていないキャッシュトークンカテゴリ、モデル側の思考トークン、ストレージ期間、メディア処理、またはトークンレート以外のプロバイダー料金が見落とされる可能性があります。利用可能な場合は、サンプリングされた使用量とプロバイダーの請求レポートを照合し、重大な乖離があれば調査し、モデル、プロンプト、キャッシュの挙動、またはプレイヤー向け機能を変更した後は計算を再実行してください。得られる結果は、観測されたワークロードに対する文書化された運用コストの見積もりであり、将来のセッションや請求書がそれに完全に一致することを保証するものではありません。