https://www.knightli.com/ja/tags/%E3%82%B3%E3%82%B9%E3%83%88%E5%88%86%E6%9E%90/ Recent content in コスト分析 on KnightLiブログ Hugo -- gohugo.io ja Sat, 25 Apr 2026 08:44:32 +0800 https://www.knightli.com/ja/2026/04/25/llm-token-pricing-principles/ Sat, 25 Apr 2026 08:44:32 +0800 https://www.knightli.com/ja/2026/04/25/llm-token-pricing-principles/ <p>LLM API の料金体系で最も混乱しやすい点の 1 つは、なぜほとんどのプラットフォームが最終的に <code>token</code> という単位で課金するのか、ということです。要するに、<strong>なぜ大規模モデルは token ごとに課金され、しかも token の種類によって価格まで違うのか</strong>、という疑問です。</p> <p>モデル API を使い始めたばかりの人が戸惑いやすいのは、モデル性能よりもむしろ請求額です。少し質問しただけなのに、なぜこんなに料金が増えるのか。なぜ入力は安く、出力は高いのか。なぜコンテキストが長くなるとコストが急に制御しづらくなるのか。</p> <p>これをシンプルに捉えるなら、まず次の一文を覚えておくと分かりやすいです。<strong>課金されているのは「1 回の回答」ではなく、推論全体で消費された計算資源と帯域です。</strong></p> <h2 id="1-token-とは何か">1. token とは何か </h2><p>LLM の課金でいう <code>token</code> は、文字数でも単語数でもありません。モデルがテキストを処理するときの分割単位です。</p> <p>1 つの token は、たとえば次のようなものになり得ます。</p> <ul> <li>1 つの漢字</li> <li>英単語の一部</li> <li>句読点</li> <li>よく出る短いテキスト断片</li> </ul> <p>そのため、API プラットフォームは通常「1 文ごと」や「1 リクエストごと」には課金しません。モデルが実際に読んだ token 数と生成した token 数に応じて課金します。<br> これはリクエスト回数ベースの課金よりも合理的です。同じ 1 回のリクエストでも、20 文字だけ入力する場合もあれば、20 万 token のコンテキストを入れる場合もあるからです。消費される資源はまったく違います。</p> <h2 id="2-なぜ入力と出力は別料金なのか">2. なぜ入力と出力は別料金なのか </h2><p>現在の多くのモデル API では、料金が次の 2 つに分かれています。</p> <ul> <li>入力 token 料金</li> <li>出力 token 料金</li> </ul> <p>しかも一般的には、<strong>出力 token のほうが入力 token より高い</strong>です。</p> <p>理由はそれほど難しくありません。</p> <p>モデルが入力を処理するときは、基本的には既存の内容を読み取り、エンコードしています。けれども出力を生成するときは、次の token を 1 つずつ予測し続ける必要があります。これは単に読むだけではなく、継続的に推論とサンプリングを行う処理なので、通常はより多くの計算資源を使います。</p> <p>大まかに言えば次のように考えられます。</p> <ul> <li>入力：資料をモデルに渡す</li> <li>出力：その場でモデルに回答を書かせる</li> </ul> <p>その場で書くほうが、資料を一度読むよりも計算コストが高くなりやすいため、出力価格が高いのはよくある設計です。</p> <h2 id="3-なぜコンテキストが長いとコストが膨らみやすいのか">3. なぜコンテキストが長いとコストが膨らみやすいのか </h2><p>少し背景情報を足しているだけだと思っていても、請求の観点では想像以上に影響が大きいことがあります。</p> <p>理由は、<strong>モデルは通常、各リクエストで渡されたコンテキスト全体をもう一度処理する必要がある</strong>からです。</p> <p>つまり、現在のリクエストに次のようなものが含まれていれば：</p> <ul> <li>システムプロンプト</li> <li>会話履歴</li> <li>ツールの返り値</li> <li>長文書の断片</li> <li>ソースコードファイルの内容</li> </ul> <p>それらはすべて入力 token として課金対象になります。</p> <p>請求額を本当に押し上げるのは、最後の一言の質問ではなく、その前にぶら下がっている長いコンテキストであることが多いです。<br> 会話のターン数が増え、ツール呼び出しが増え、履歴メッセージが何度も再投入されると、token コストはラウンドごとに膨らんでいきます。</p> <h2 id="4-なぜツール呼び出しは特に-token-を増やしやすいのか">4. なぜツール呼び出しは特に token を増やしやすいのか </h2><p>Agent、コーディングアシスタント、ワークフロー自動化のような場面では、token 消費は通常のチャットよりかなり大きくなりがちです。</p> <p>問題は「モデルが少し長めに答えた」ことだけではありません。ワークフロー全体で次のような内容が絶えず発生するからです。</p> <ul> <li>ファイルを読む</li> <li>ログを確認する</li> <li>API を呼ぶ</li> <li>JSON を返す</li> <li>ツール結果をモデルに戻す</li> </ul> <p>ツール呼び出しの結果が次のラウンドのコンテキストに再投入されるたび、それは新たな入力 token になります。</p> <p>だからこそ多くの開発者は最終的にこう気づきます。<br> <strong>問題はモデルの単価そのものではなく、ワークフローが token の請求額を何層にも積み上げていることがある</strong>のです。</p> <p>たとえばコーディング Agent が次のことを連続で行うとします。</p> <ol> <li>プロジェクト構造を読む</li> <li>いくつかのソースファイルを開く</li> <li>テストを実行する</li> <li>エラーログをモデルに戻す</li> <li>さらに関連ファイルを読む</li> </ol> <p>各ステップで、次のリクエストがより長いコンテキストを背負うことになります。単価が同じでも、総額はすぐに増えていきます。</p> <h2 id="5-同じようなモデルでも価格差が大きいのはなぜか">5. 同じようなモデルでも価格差が大きいのはなぜか </h2><p>モデルごとの token 価格差は、単にベンダーが高く売りたいからというだけではありません。多くの場合、次のような要素と直接結び付いています。</p> <ul> <li>モデル規模</li> <li>推論効率</li> <li>コンテキスト長</li> <li>配備コスト</li> <li>ターゲット市場</li> </ul> <p>モデルが大きく、アクティブパラメータが多く、推論経路が複雑になるほど、1 token を生成するコストは一般に高くなります。<br> さらに超長コンテキスト、複雑な推論、ツール利用最適化まで対応するなら、基盤側の負荷はさらに増えます。</p> <p>そのため、価格設定は本質的に次のようなコストをカバーしています。</p> <ul> <li>GPU / アクセラレータ資源</li> <li>VRAM 使用量</li> <li>推論レイテンシ</li> <li>ネットワークとサービス安定性</li> <li>ピーク同時実行能力</li> </ul> <p>安いモデルが悪いとは限らず、高いモデルがすべての場面に向くわけでもありません。多くの場合、価格差は「その能力にどれだけの基盤コストがかかるか」を反映しています。</p> <h2 id="6-なぜキャッシュ入力は安くなるのか">6. なぜキャッシュ入力は安くなるのか </h2><p>多くのモデルプラットフォームでは現在、次のような仕組みが提供されています。</p> <ul> <li>cached input</li> <li>prompt caching</li> <li>prefix caching</li> </ul> <p>共通する考え方はシンプルで、すでに処理した大きな入力断片を、毎回フル価格でゼロから再計算しないようにすることです。</p> <p>たとえば固定の system prompt、固定のツール説明、固定の長文書プレフィックスを毎ラウンドまったく同じように送るなら、プラットフォームはその一部をキャッシュできる可能性があります。すると同じ入力 token でも、キャッシュに当たった部分はより安い料金で計上できます。</p> <p>この仕組みがあるからこそ、多くの API 料金表には次のような複数の価格帯があります。</p> <ul> <li>通常入力</li> <li>キャッシュ入力</li> <li>出力</li> </ul> <p>違いはテキストの意味ではなく、下層の計算が再利用できるかどうかです。</p> <h2 id="7-安い-tokenが必ずしも安い総額にならない理由">7. 「安い token」が必ずしも「安い総額」にならない理由 </h2><p>あるモデルが「100 万 token あたりとても安い」と書かれていると、総コストも必ず安いと思いがちです。ですが、実際にはそうとは限りません。</p> <p>総額は大まかに次の式で考えられます。</p> <p><strong>token 単価 × 実際の消費量</strong></p> <p>そして実際の消費量は、さまざまな要因で膨らみます。</p> <ul> <li>プロンプトが長すぎる</li> <li>履歴メッセージを整理しない</li> <li>ツール結果を戻しすぎる</li> <li>出力が冗長すぎる</li> <li>1 つのタスクを何度もやり直す</li> </ul> <p>つまり請求額を決めるのは単価だけではなく、通常は次の組み合わせです。</p> <ul> <li>モデル単価</li> <li>各ラウンドの入力長</li> <li>各ラウンドの出力長</li> <li>呼び出し回数</li> <li>ワークフロー設計</li> </ul> <p>だからこそ、単価の安いモデルでも Agent タスクでは最終的な総費用がそれほど安くならないことがあります。より多くのラウンド、補足コンテキスト、再試行が必要になることがあるからです。</p> <h2 id="8-開発者は-token-コストをどう見積もるべきか">8. 開発者は token コストをどう見積もるべきか </h2><p>実プロジェクトで予算を安定して管理したいなら、まずは素朴な見積もり方法が役に立ちます。</p> <ol> <li>1 リクエストあたりの平均入力 token 数を測る</li> <li>1 リクエストあたりの平均出力 token 数を測る</li> <li>1 つのタスクが何ラウンド必要か見積もる</li> <li>それをモデル単価に掛ける</li> </ol> <p>たとえば次のようなイメージです。</p> <ul> <li>1 ラウンドあたり入力 <code>8k tokens</code></li> <li>1 ラウンドあたり出力 <code>1k tokens</code></li> <li>1 タスクあたり <code>10</code> ラウンド</li> </ul> <p>この場合、本当に消費しているのは「1 回のやり取り」ではなく：</p> <ul> <li>入力およそ <code>80k tokens</code></li> <li>出力およそ <code>10k tokens</code></li> </ul> <p>途中でログ、ツール結果、ファイル内容が増え続ければ、総量はさらに上がります。</p> <p>だから予算を見るときは、単一ラウンドではなく、<strong>タスク 1 件を最後まで回したときに何 token 消費するか</strong>を見るべきです。</p> <h2 id="9-実際に請求額を抑えるには">9. 実際に請求額を抑えるには </h2><p>すでに API や Agent を使っているなら、次の方法が特に効果的です。</p> <ul> <li>system prompt を短くして重複表現を削る</li> <li>古い履歴を定期的に削る</li> <li>ツール出力は必要な項目だけ残す</li> <li>長文書は先に検索して必要部分だけ渡す</li> <li>出力長を制御して無制限な展開を防ぐ</li> <li>高価なモデルは高価値タスクに、安価なモデルは低価値タスクに使う</li> </ul> <p>多くの場合、節約の近道はむやみに安いモデルへ切り替えることではなく、まずワークフロー内の無駄な token 消費を削ることです。</p> <h2 id="10-結局どう理解すればよいか">10. 結局どう理解すればよいか </h2><p>LLM の token 課金とは、要するに「モデルがどれだけ読み、どれだけ推論し、どれだけ書いたか」に対する課金です。</p> <p>これは従来のソフトウェアのように、アカウント単位、回数単位、月額課金だけで資源消費を表しきれる世界ではありません。モデル呼び出しは動的な計算プロセスであり、送るコンテキスト量、呼ぶツール、求める出力長がすべて直接コストに反映されます。</p> <p>だから大切なのは価格表を暗記することではなく、まず次の直感を持つことです。</p> <ul> <li>長いコンテキストは入力コストを増やす</li> <li>長い出力は生成コストを増やす</li> <li>ツールチェーンは総 token を増幅する</li> <li>キャッシュとワークフロー設計は請求額を大きく変える</li> </ul> <p>この感覚がつかめれば、多くの LLM API の価格構造はかなり理解しやすくなります。</p>