GPT、Claude、Gemini など主要LLM APIのトークンコストを計算します。トークン数を直接入力するか、テキストを貼り付けて推定し、月間利用ベースの想定コストまで確認できます。
テキスト貼り付けモード、または直接入力モードで入力・出力が未入力の場合は、リクエストあたりのトークンを入力70%/出力30%と仮定してシミュレーションします。直接入力モードで入力・出力トークンの両方を入力した場合はその値をそのまま使用します。
新機能やサービスにLLM APIを組み込む前にコストを見積もっておくと、利用者数が増えたときに請求額が想定外の規模に膨らむのを防げます。特にプロンプトが長い、あるいは複数ターンの会話が続くサービスでは、1件あたりのコストが小さく見えても、1日・1ヶ月単位で積み上げると規模感が大きく変わります。この計算機はリクエスト1件あたりのコストと月間シミュレーションを併せて表示し、スケール前の予算感を掴む助けになります。
トークンはモデルがテキストを処理する最小単位で、単語や文字と1対1で対応するわけではありません。英語では「およそ4文字で1トークン」という目安がよく使われますが、これはあくまで近似値であり、実際にはモデルごとのトークナイザー(BPEなど)によって異なります。特に日本語・韓国語・中国語などCJK言語は、1文字が複数のサブワードトークンに分割されることが多く、英語より1文字あたりのトークン消費が多くなる傾向があるため、同じ文字数でも実際のコストは英語テキストより高くなることがあります。
ほとんどの提供元は、出力(生成)トークンの単価を入力(プロンプト)トークンより数倍高く設定しています。このページのデータに含まれるすべてのモデルもこのパターンに従っています。入力はすでに与えられたテキストを一度に処理(エンコード)できますが、出力はトークンを1つずつ順番に生成(デコード)する必要があり、計算量とレイテンシがより大きくなるためです。そのため、応答を短く保つことはコスト削減に特に効果的です。
プロンプトキャッシュ(コンテキストキャッシュ)は、毎回のリクエストで繰り返されるシステムプロンプトや長いコンテキスト・文書をサーバー側にキャッシュしておき、次回同じ内容が再び送られたときに、より低い単価で処理する機能です。システムプロンプトや会話履歴が毎回送信されるチャットボットのような構成で特に効果を発揮します。ただし毎回まったく新しいテキストを送る場合はキャッシュが適用されないため、この計算機の「キャッシュヒット時」の数値はあくまで参考シナリオです。
①プロンプトを必要以上に長くせず、必要なコンテキストだけを含める ②リクエスト間で繰り返されるシステムプロンプト・コンテキストにはプロンプトキャッシュを積極的に活用する ③分類・要約のような単純なタスクは、最上位モデルではなくより安価な小型モデルにルーティングする ④複数のリクエストをバッチ処理でまとめ、バッチ割引やスループット最適化を活用する。この4点だけでも実運用コストを大きく下げられます。
この計算機は各提供元が公開している定価(リストプライス)のAPI料金をもとにした見積もりです。ボリュームディスカウント、エンタープライズ契約、プロビジョンドスループット、無料クレジット、地域ごとの料金差、レート制限による実質的な処理遅延などは反映していません。実際の請求額は契約条件によって異なる場合があるため、予算計画の出発点として利用し、最終確定前には提供元に直接ご確認ください。