Token on KnightLiブログ

LLM API はなぜ Token 課金なのか：入力・出力・コンテキストのコストをまとめて理解する

Sat, 25 Apr 2026 08:44:32 +0800

LLM API の料金体系で最も混乱しやすい点の 1 つは、なぜほとんどのプラットフォームが最終的に token という単位で課金するのか、ということです。要するに、なぜ大規模モデルは token ごとに課金され、しかも token の種類によって価格まで違うのか、という疑問です。

モデル API を使い始めたばかりの人が戸惑いやすいのは、モデル性能よりもむしろ請求額です。少し質問しただけなのに、なぜこんなに料金が増えるのか。なぜ入力は安く、出力は高いのか。なぜコンテキストが長くなるとコストが急に制御しづらくなるのか。

これをシンプルに捉えるなら、まず次の一文を覚えておくと分かりやすいです。課金されているのは「1 回の回答」ではなく、推論全体で消費された計算資源と帯域です。

1. token とは何か

LLM の課金でいう token は、文字数でも単語数でもありません。モデルがテキストを処理するときの分割単位です。

1 つの token は、たとえば次のようなものになり得ます。

1 つの漢字
英単語の一部
句読点
よく出る短いテキスト断片

そのため、API プラットフォームは通常「1 文ごと」や「1 リクエストごと」には課金しません。モデルが実際に読んだ token 数と生成した token 数に応じて課金します。
これはリクエスト回数ベースの課金よりも合理的です。同じ 1 回のリクエストでも、20 文字だけ入力する場合もあれば、20 万 token のコンテキストを入れる場合もあるからです。消費される資源はまったく違います。

2. なぜ入力と出力は別料金なのか

現在の多くのモデル API では、料金が次の 2 つに分かれています。

入力 token 料金
出力 token 料金

しかも一般的には、出力 token のほうが入力 token より高いです。

理由はそれほど難しくありません。

モデルが入力を処理するときは、基本的には既存の内容を読み取り、エンコードしています。けれども出力を生成するときは、次の token を 1 つずつ予測し続ける必要があります。これは単に読むだけではなく、継続的に推論とサンプリングを行う処理なので、通常はより多くの計算資源を使います。

大まかに言えば次のように考えられます。

入力：資料をモデルに渡す
出力：その場でモデルに回答を書かせる

その場で書くほうが、資料を一度読むよりも計算コストが高くなりやすいため、出力価格が高いのはよくある設計です。

3. なぜコンテキストが長いとコストが膨らみやすいのか

少し背景情報を足しているだけだと思っていても、請求の観点では想像以上に影響が大きいことがあります。

理由は、モデルは通常、各リクエストで渡されたコンテキスト全体をもう一度処理する必要があるからです。

つまり、現在のリクエストに次のようなものが含まれていれば：

システムプロンプト
会話履歴
ツールの返り値
長文書の断片
ソースコードファイルの内容

それらはすべて入力 token として課金対象になります。

請求額を本当に押し上げるのは、最後の一言の質問ではなく、その前にぶら下がっている長いコンテキストであることが多いです。
会話のターン数が増え、ツール呼び出しが増え、履歴メッセージが何度も再投入されると、token コストはラウンドごとに膨らんでいきます。

4. なぜツール呼び出しは特に token を増やしやすいのか

Agent、コーディングアシスタント、ワークフロー自動化のような場面では、token 消費は通常のチャットよりかなり大きくなりがちです。

問題は「モデルが少し長めに答えた」ことだけではありません。ワークフロー全体で次のような内容が絶えず発生するからです。

ファイルを読む
ログを確認する
API を呼ぶ
JSON を返す
ツール結果をモデルに戻す

ツール呼び出しの結果が次のラウンドのコンテキストに再投入されるたび、それは新たな入力 token になります。

だからこそ多くの開発者は最終的にこう気づきます。
問題はモデルの単価そのものではなく、ワークフローが token の請求額を何層にも積み上げていることがあるのです。

たとえばコーディング Agent が次のことを連続で行うとします。

プロジェクト構造を読む
いくつかのソースファイルを開く
テストを実行する
エラーログをモデルに戻す
さらに関連ファイルを読む

各ステップで、次のリクエストがより長いコンテキストを背負うことになります。単価が同じでも、総額はすぐに増えていきます。

5. 同じようなモデルでも価格差が大きいのはなぜか

モデルごとの token 価格差は、単にベンダーが高く売りたいからというだけではありません。多くの場合、次のような要素と直接結び付いています。

モデル規模
推論効率
コンテキスト長
配備コスト
ターゲット市場

モデルが大きく、アクティブパラメータが多く、推論経路が複雑になるほど、1 token を生成するコストは一般に高くなります。
さらに超長コンテキスト、複雑な推論、ツール利用最適化まで対応するなら、基盤側の負荷はさらに増えます。

そのため、価格設定は本質的に次のようなコストをカバーしています。

GPU / アクセラレータ資源
VRAM 使用量
推論レイテンシ
ネットワークとサービス安定性
ピーク同時実行能力

安いモデルが悪いとは限らず、高いモデルがすべての場面に向くわけでもありません。多くの場合、価格差は「その能力にどれだけの基盤コストがかかるか」を反映しています。

6. なぜキャッシュ入力は安くなるのか

多くのモデルプラットフォームでは現在、次のような仕組みが提供されています。

cached input
prompt caching
prefix caching

共通する考え方はシンプルで、すでに処理した大きな入力断片を、毎回フル価格でゼロから再計算しないようにすることです。

たとえば固定の system prompt、固定のツール説明、固定の長文書プレフィックスを毎ラウンドまったく同じように送るなら、プラットフォームはその一部をキャッシュできる可能性があります。すると同じ入力 token でも、キャッシュに当たった部分はより安い料金で計上できます。

この仕組みがあるからこそ、多くの API 料金表には次のような複数の価格帯があります。

通常入力
キャッシュ入力
出力

違いはテキストの意味ではなく、下層の計算が再利用できるかどうかです。

7. 「安い token」が必ずしも「安い総額」にならない理由

あるモデルが「100 万 token あたりとても安い」と書かれていると、総コストも必ず安いと思いがちです。ですが、実際にはそうとは限りません。

総額は大まかに次の式で考えられます。

token 単価 × 実際の消費量

そして実際の消費量は、さまざまな要因で膨らみます。

プロンプトが長すぎる
履歴メッセージを整理しない
ツール結果を戻しすぎる
出力が冗長すぎる
1 つのタスクを何度もやり直す

つまり請求額を決めるのは単価だけではなく、通常は次の組み合わせです。

モデル単価
各ラウンドの入力長
各ラウンドの出力長
呼び出し回数
ワークフロー設計

だからこそ、単価の安いモデルでも Agent タスクでは最終的な総費用がそれほど安くならないことがあります。より多くのラウンド、補足コンテキスト、再試行が必要になることがあるからです。

8. 開発者は token コストをどう見積もるべきか

実プロジェクトで予算を安定して管理したいなら、まずは素朴な見積もり方法が役に立ちます。

1 リクエストあたりの平均入力 token 数を測る
1 リクエストあたりの平均出力 token 数を測る
1 つのタスクが何ラウンド必要か見積もる
それをモデル単価に掛ける

たとえば次のようなイメージです。

1 ラウンドあたり入力 8k tokens
1 ラウンドあたり出力 1k tokens
1 タスクあたり 10 ラウンド

この場合、本当に消費しているのは「1 回のやり取り」ではなく：

入力およそ 80k tokens
出力およそ 10k tokens

途中でログ、ツール結果、ファイル内容が増え続ければ、総量はさらに上がります。

だから予算を見るときは、単一ラウンドではなく、タスク 1 件を最後まで回したときに何 token 消費するかを見るべきです。

9. 実際に請求額を抑えるには

すでに API や Agent を使っているなら、次の方法が特に効果的です。

system prompt を短くして重複表現を削る
古い履歴を定期的に削る
ツール出力は必要な項目だけ残す
長文書は先に検索して必要部分だけ渡す
出力長を制御して無制限な展開を防ぐ
高価なモデルは高価値タスクに、安価なモデルは低価値タスクに使う

多くの場合、節約の近道はむやみに安いモデルへ切り替えることではなく、まずワークフロー内の無駄な token 消費を削ることです。

10. 結局どう理解すればよいか

LLM の token 課金とは、要するに「モデルがどれだけ読み、どれだけ推論し、どれだけ書いたか」に対する課金です。

これは従来のソフトウェアのように、アカウント単位、回数単位、月額課金だけで資源消費を表しきれる世界ではありません。モデル呼び出しは動的な計算プロセスであり、送るコンテキスト量、呼ぶツール、求める出力長がすべて直接コストに反映されます。

だから大切なのは価格表を暗記することではなく、まず次の直感を持つことです。

長いコンテキストは入力コストを増やす
長い出力は生成コストを増やす
ツールチェーンは総 token を増幅する
キャッシュとワークフロー設計は請求額を大きく変える

この感覚がつかめれば、多くの LLM API の価格構造はかなり理解しやすくなります。

AI用語解説: Agent、MCP、RAG、Token をわかりやすく整理する

Thu, 23 Apr 2026 13:13:40 +0800

AI に触れ始めたばかりのとき、人を遠ざけやすいのはモデルそのものより、会話の中に次々出てくる用語です。Agent、MCP、RAG、AIGC、Token はどれも見覚えはあっても、やさしく説明されないと本当の意味まではつかみにくいものです。

この記事では、よくある入門向けの説明の流れに沿って、AI で頻出する 10 個の用語を覚えやすい形にまとめます。学術的に厳密に説明することよりも、日常的な AI の話題についていける基本イメージを作ることを目的にしています。

10 個の代表的な AI 用語は何を意味するのか

1. Agent: 会話だけでなく実行もする AI

Agent は、実際に作業を進めてくれる AI アシスタントだと考えると分かりやすいです。

普通のチャットボットは、質問すると答えるという形にとどまりがちです。Agent はそこから一歩進み、タスクを分解し、手順を組み立て、ツールを呼び出し、最後に結果を返します。資料整理、調査、文書生成のような依頼でも、助言だけで終わらず、一連の動作をつないで実行することがあります。

だから Agent の本質は、話せるかどうかではなく、動けるかどうかにあります。

2. OpenClaw: PC に常駐する AI アシスタント

ここでの OpenClaw は、PC の中に住む AI アシスタントのようなものとして説明されています。

この種のツールは、デスクトップ操作に近い AI 支援だと考えると分かりやすいです。文字入力を受け取るだけでなく、画面を見たり、ローカルツールを呼び出したり、手順に沿って作業したりすることがあります。一般的な Web チャットと比べると、実際の操作能力がより重視されます。

Agent が実行型 AI という抽象的な概念だとすれば、こうしたデスクトップ型アシスタントは、その考え方の PC 上での具体例だと言えます。

3. Skills: Agent に追加する能力パック

Skills は、Agent の機能モジュールや操作ルールだと捉えられます。

同じ Agent でも、どの Skills を持つかによって得意分野が変わります。文章作成寄りのものもあれば、データ整理向けのものもあり、コード処理に向いたものもあります。スマートフォンのアプリに少し似ていますし、再利用できるワークフロー集にも近いです。

つまり、モデルそのものが急に賢くなったというより、背後にあるルール、ツール、手順が明確になった結果だと言えます。

4. MCP: AI が外部ツールにつながるための共通方式

MCP は Model Context Protocol の略です。

身近な比喩で言えば、AI の世界における Type-C 端子のようなものです。以前はモデルを別々のツールにつなぐたびに個別実装が必要になりがちでしたが、共通プロトコルがあると接続方法を標準化しやすくなります。

多くの人にとって大事なのは、MCP が「モデルが答えられるかどうか」の話ではなく、「モデルが外部ツールや外部リソースに安全かつ安定して接続するにはどうするか」の話だという点です。

5. ガチャ: AI 生成にはランダムさがある

「ガチャ」という表現は、AI 画像生成、動画生成、クリエイティブ用途でよく使われます。

意味はシンプルです。同じプロンプトで、同じ方向性を指定しても、毎回まったく同じ結果になるとは限りません。すごく良い結果が出ることもあれば、明らかに崩れることもあります。そのため、何度も生成して当たりを引く感覚がゲームのガチャにたとえられます。

ここで押さえておきたいのは、AI 生成は固定的な公式ではなく、確率的な揺らぎを含んだプロセスだということです。

6. API: アプリとモデルをつなぐ入口

API は Application Programming Interface の略です。

プログラム同士がやり取りするための標準的な入口だと考えると分かりやすいです。自分のアプリ、スクリプト、エディタからモデルサービスを呼び出すときは、実質的に API を通じてリクエストを送り、結果を受け取っています。

モデルサービスをレストランにたとえるなら:

メニューは API ドキュメント
注文は API リクエスト
厨房から料理が返ってくるのはモデルの応答

そのため、見た目は違うツールでも、裏側では何らかの API を呼んでいることが多いです。

7. マルチモーダル: AI は文字だけを扱うわけではない

マルチモーダル とは、AI が文字の読み書きだけに限られず、複数の種類の情報を扱えることを指します。

たとえば画像を見たり、音声を理解したり、動画を解釈したり、画像を生成したり、リアルタイムの音声や映像のやり取りを支えたりできます。文字しか扱えなかった初期のモデルと比べると、「見る・聞く・話す・書く」に近い能力を併せ持つ方向へ進んでいます。

だからこそ、今の AI 製品は単なるテキスト入力欄だけでは語れなくなっています。

8. RAG: 先に資料を探し、そのうえで答えを作る

RAG は Retrieval-Augmented Generation の略です。

これはとても実務的な課題に向いています。モデルの学習データには時点の限界があり、社内の最新資料、サポート記録、業務ルールを自動では知りません。RAG は、まず指定した資料群から関連情報を探し、その内容を踏まえて回答を生成する考え方です。

価値が出やすい点は主に 3 つあります。

回答が実際の資料に寄りやすくなる
どの資料を根拠にしたか追いやすい
新しい資料を追加すれば知識を更新しやすい

そのため、企業向けナレッジベース、AI カスタマーサポート、社内 Q&A では RAG がよく使われます。

9. AIGC: AI が作るコンテンツ全体を指す言葉

AIGC は AI Generated Content の略です。

これは単独のツール名ではなく、AI が生成したコンテンツ全般を指す総称です。文章、画像、音声、動画などが含まれます。AI ライティング、AI イラスト、AI による短尺動画制作、AI 音声生成などはすべて AIGC の枠で理解できます。

大事なのは、この言葉が特定のモデルではなく、コンテンツの作り方そのものを指していることです。

10. Token: モデルが内容を処理するときの計量単位

Token は、モデルがテキストを処理するときの基本的な計量単位だと考えられます。

これは 1 文字や 1 単語と完全に一致するわけではありませんが、実用上は計算量や課金の共通単位として捉えて問題ありません。入力でも Token を消費し、出力でも Token を消費し、保持しているコンテキストも同じように Token を使います。

だから多くのモデルサービスがコンテキスト長、コスト管理、プロンプト圧縮を強調するのは、結局どれも Token と深く関係しているからです。