GLM API は「月額固定で使い放題」という製品ではなく、実際の利用量に応じて課金されます。多くのチームが最初に請求書を見たとき、「リクエスト数は多くないのに、なぜ費用が高いのか」と疑問に思います。原因は単価ではなく、入力が長すぎる、出力が制御できていない、キャッシュがヒットしていない、失敗した再試行で同じ内容をもう一度生成した、といった点にあることが少なくありません。

本記事では具体的な単価は記載しません。価格はモデル、コンテキストの段階、キャンペーンによって変わるためです。ここでは課金の構造、どこでコストが発生するか、どう見積もり、どう抑えるかを説明し、最後に実行可能なチェックリストを示します。現在の価格はモデル料金および GLM 提供元の公式価格ページをご確認ください。

注記：GLM、BigModel などの名称は各権利者の商標です。本記事は技術的な説明のみを目的としており、提供元と資本関係、代理関係、提携関係はありません。課金ルールと価格は変更される場合があるため、契約前に公式ドキュメントと請求画面をご確認ください。

一、課金の基本単位

テキストモデルはトークンを基本単位とします。提供元の公式ドキュメントでは、おおよそ 1 トークンが 1.6 文字の漢字に相当すると説明されていますが、実際の数はトークナイザーとテキスト内容によって変わります。最終的には API が返す usage を基準にしてください。つまり、見積もりは予算作成の参考にはなりますが、請求書の代わりにはなりません。

すべてのモデルがトークン課金とは限りません。画像生成、動画生成、音声合成、音声クローン、リアルタイム音声・映像、ナレッジベースの解析などは、回数、分、文字数、ページ単位で課金される場合があります。マルチモーダル製品を作る場合は、まず課金単位を確認してから単価の話をしてください。

二、入力と出力が分けて計算される理由

1 回のリクエストには通常、入力トークンと出力トークンが含まれ、両者は別々に課金されます。出力のほうが高いのが一般的です。長いコンテキストに対応するモデルでは、入力長に応じて段階が分かれることもあります。たとえば 32K を境に、超えると上位の段階になる場合があります。出力長で段階が変わるモデルもあります。つまり「同じモデル」でも使い方によって単位コストが変わり得ます。

コストに影響するのはリクエスト数そのものではなく、各リクエストが持ち込むコンテキストです。ナレッジベース全体、すべての会話履歴、数十個のツール定義をプロンプトに詰め込めば、入力は急速に膨らみます。よりよくある無駄は出力側です。最大出力長を設定しないとモデルは延々と生成し、費用は自然に上がります。

コスト項目 課金の基準 よくある発生場面 制御方法
入力トークン キャッシュ未ヒットの入力で課金 長いプロンプト、複数ターンの履歴、ツール定義 コンテキストを削り、要約する
出力トークン 生成内容で課金 長文作成、コード生成 最大出力長を設定
キャッシュヒット ヒット部分は割引価格 固定システムプロンプト、ナレッジベースの接頭辞 接頭辞を安定させる
長いコンテキストの段階 しきい値を超えると単価が変わる 長い文書、コードベース分析 分割、要約、必要時の読み込み
再試行と失敗 生成済み部分が課金される場合がある タイムアウト、ストリーム中断、重複送信 冪等化、バックオフ、重複排除
マルチモーダルとツール 回数、分、ページなどで課金 画像生成、音声、検索、解析 個別に採算を取る、呼び出しを制限

三、キャッシュヒット：削減できるのは繰り返しの接頭辞

GLM はコンテキストキャッシュ機能を提供しています。公式ドキュメントで主に説明されているのは暗黙的キャッシュで、システムが重複内容を自動的に識別し、手動でキャッシュポイントを指定する必要はありません。「固定のシステムプロンプト + 固定のナレッジベース + 変化する質問」という場面に向いています。

ヒット率を上げるには、少なくとも 3 つの条件を満たす必要があります。繰り返される接頭辞が十分に長いこと（公式の推奨は 500 トークン以上）、接頭辞の内容が完全に一致していること（スペースが 1 つ増えるだけでもヒットしない場合があります）、キャッシュが非同期に生成されるため、最初のリクエストの後少し待ってから次のリクエストを送ると効果が高いことです。ヒット状況は usage.prompt_tokens_details.cached_tokens で確認できます。

キャッシュは万能ではありません。短いプロンプト、毎回内容が変わるもの、頻繁に更新されるナレッジベースはヒットしにくくなります。キャッシュ保存に別途料金がかかるか、割引率がどの程度かは公式価格ページで確認してください。キャッシュは最適化項目として扱い、コストモデルの前提にはしないでください。

四、長いコンテキスト、バッチ、マルチモーダル

長いコンテキストは便利ですが、予算を超えやすい場所でもあります。契約書、論文、コードベースを扱うときは、まず 3 つ問いかけてください。本当に全部を一度に入れる必要があるか。先に検索してから結合できないか。分割して処理し、後でまとめられないか。多くのタスクは「検索 + 要約」で完了し、コストは全体を直接詰め込むよりはるかに低くなります。

バッチ処理では Batch インターフェースを検討できます。公式ドキュメントによると、対応モデルで Batch を使うと通常は割引があり、オフラインのラベリング、一括要約、データクリーニングなど、リアルタイム性を要求しない場面に向いています。代わりに遅延が大きくなり、タスクの編成も複雑になるため、キューと結果検証を持つチームに向いています。

マルチモーダル機能は個別に採算を取ってください。画像生成は枚数、画像理解は通常トークン、音声合成は文字数または分、ナレッジベース解析はページ単位で課金されます。これらの費用をテキストの予算に混ぜると、月末に必ず帳尻が合わなくなります。

五、再試行、ストリーム中断、隠れたコスト

失敗したリクエストが必ず無料とは限りません。サーバー側が一部の内容を生成した後にタイムアウトした場合、その分の利用量が課金される可能性があります。ストリーミング接続が中断したときも、生成済みの部分が請求に含まれる場合があります。そのため再試行は控えめにしてください。レート制限、5xx、ネットワークタイムアウトのみを対象にし、指数バックオフを使い、最大回数を設定します。

もう 1 つの隠れたコストは重複送信です。ユーザーがボタンを連打する、フロントエンドがタイムアウトで自動再送する、キューが同じメッセージを複数回処理する、といった行為は追加リクエストを生みます。リクエスト ID による冪等化や、ゲートウェイ層での重複排除は、後から請求を照合するよりはるかに有効です。

エンジニアリングコストも考慮してください。ログ、監視、評価、人手による確認はすべてコストです。モデル呼び出し料金は総コストの一部にすぎません。呼び出し料金を少し節約するために、数倍の人手を手作業の修正に投じるのは本末転倒です。

六、月次予算の見積もり方

見積もりは 4 ステップです。月間呼び出し数を集計し、平均入力・出力を見積もり、キャッシュヒット率を推定し、現在の単価を当てはめます。複数モデルの残高と利用量を 1 か所で管理したい場合は、ZSQH AI Gateway に登録するとまとめて確認できます。具体的な価格はモデル料金ページを基準にしてください。以下のコードは計算の枠組みであり、単価は公式価格ページから読み取って入力してください。

# 予算モデル：単価はすべてプレースホルダーです。現在の公式価格に置き換えてください。
monthly_calls = 300_000
avg_input_tokens = 1_200
avg_output_tokens = 300
cache_hit_rate = 0.35
input_rate = 0.0       # 入力単価（公式価格ページを確認）
output_rate = 0.0      # 出力単価
cache_rate = 0.0       # キャッシュヒット単価

uncached_input = avg_input_tokens * (1 - cache_hit_rate)
cached_input = avg_input_tokens * cache_hit_rate
per_call = (
    uncached_input * input_rate
    + cached_input * cache_rate
    + avg_output_tokens * output_rate
)
print(f"月間コスト見積もり：{monthly_calls * per_call:.2f} 元")

見積もりには余裕を持たせてください。新しい業務では、実際の入力が設計時より長くなることが多く、再試行や失敗も利用量を増やします。まず小流量で 2 週間稼働させ、実際の usage データで仮定値を置き換えてから予算を決めることをおすすめします。

七、予算管理チェックリスト

  1. 環境ごと、サービスごとに個別の上限額を設定する。
  2. すべてのリクエストに最大出力長とタイムアウトを設定する。
  3. システムプロンプトの順序を固定し、キャッシュヒット率を上げる。
  4. 長い文書は先に検索・要約し、長いコンテキストに入れるか判断する。
  5. 再試行可能なエラーだけを再試行し、バックオフと回数上限を設ける。
  6. 毎日利用量を確認し、毎週請求書を確認する。異常な増加はすぐに原因を特定する。
  7. オフライン処理は Batch を優先し、リアルタイム処理はオンライン API を使う。

八、よくある質問（FAQ）

1. GLM API の料金はいくらですか？

価格はモデル、コンテキストの段階、キャンペーンによって変わります。本記事では固定の数字を記載しません。モデル料金または提供元の公式価格ページを確認し、最終的には管理画面の請求書を基準にしてください。

2. キャッシュヒットはどのように課金されますか？

キャッシュにヒットした部分は割引価格、ヒットしなかった入力は通常の入力単価で課金されます。具体的な割引率と保存費用は公式価格ページで確認してください。ヒット量は usage フィールドから確認できます。

3. リクエストが失敗しても課金されますか？

失敗した段階によります。すでに一部の内容を生成していれば、実際の利用量に応じて課金される可能性があります。パラメータエラーや認証失敗では、通常、生成費用は発生しません。請求明細を基準にしてください。

4. 長いコンテキストは必ず高くなりますか？

通常は高くなります。多くのモデルは入力長で段階が分かれ、しきい値を超えると単価が上がります。分割や検索で解決できるタスクに、無理に長いコンテキストを使う必要はありません。

5. 既存のコストをすぐに下げるには？

まず 3 つを実行してください。最大出力長の制限、システムプロンプトの圧縮、キャッシュヒット率の向上です。この 3 つは通常、モデルを変更するより早く効果が出て、制御もしやすいです。

関連記事