LLMコンテキストウィンドウ

計算式と考え方

キャッシュを考慮した実効入力トークンは「入力 ×（1−ヒット率）＋ 入力 × ヒット率 ×（1−割引率）」で求めます。入力30,000トークンでヒット率40%、割引率90%なら実効は19,200トークンとなり、100万トークンあたり450円で約8.64円です。出力1,500トークンは単価2,250円で約3.375円なので、1リクエストは約12.01円になります。1日500件なら約6,007円、30日で約180,225円です。合計31,500トークンは上限20万トークンの約15.8%にあたります。

コンテキスト上限と使い方の目安

LLMコンテキストウィンドウの詳しい解説

利用料の内訳を見ると、多くの業務用途では入力トークンが費用の大半を占めます。参照文書を毎回まるごと送る設計では、出力が数百トークンでも入力が数万トークンになり、単価差を考慮しても入力側が支配的になります。ここで効くのがプロンプトキャッシュです。システムプロンプトや参照文書のような毎回同じ内容を先頭に置いておくと、2回目以降はその部分の単価が大きく下がります。ヒット率が上がるほど削減額は大きくなりますが、キャッシュには有効期間があり、リクエストの間隔が空くと再び通常単価に戻ります。判断が分かれるのは、長いコンテキストに全部入れるか、検索で必要な部分だけを渡すかです。全部入れる方式は実装が簡単で、文書間の関連を読み取れるという利点があります。一方で入力量に比例して費用と応答時間が増え、情報が増えるほど必要な箇所を見落とす傾向も報告されています。検索を挟む方式は入力を数千トークンに抑えられるため費用は10分の1以下になりますが、検索の精度が結果の質を決めるため、埋め込みモデルの選定や分割方法の設計に手間がかかります。文書数が数十件までなら全部入れる方式、数千件を超えるなら検索を組み合わせる方式が現実的な分岐点になります。見落とされやすいのは、会話履歴の蓄積です。対話型の用途では往復のたびに履歴が積み上がり、20往復もすれば入力トークンが初回の数倍になります。1リクエストあたりの単価で見ていると想定を大きく超えるため、古い履歴を要約して圧縮する処理や、一定量を超えたら打ち切る仕組みを最初から組み込んでおく必要があります。トークン数と文字数の関係にも注意が必要です。英語では1トークンが約4文字ですが、日本語では1文字あたり1トークン前後を消費するため、同じ内容でも日本語のほうがトークン数が多くなります。見積もりの際は日本語の文字数に0.7から1.0を掛けた値を目安にすると実態に近くなります。単価は改定されることがあるため、最新の料金表で確認してください。

業界・現場での使い方

よくある間違い・注意点

• 出力トークンだけで費用を見積もる — 参照文書を送る用途では入力が費用の大半を占めます。単価は出力のほうが高くても、総量では入力が上回ります。
• 会話履歴の蓄積を考えない — 往復のたびに入力量が増え、20往復で初回の数倍になります。履歴の要約や打ち切りの設計が必要です。
• 日本語のトークン数を英語基準で数える — 日本語は1文字あたり1トークン前後を消費します。英語の目安である4文字1トークンで計算すると大幅に過小になります。

関連する規格・法規

• 日本統計学会
• 機械学習コミュニティ

※本ツールは公的基準に基づく参考計算です。実際の設計・施工・法令適用は最新の告示・規格および所轄官庁の判断に従ってください。

よくある質問（FAQ）

関連計算ツール