Clawy / ガイド / 有料 AI API の価格設定

損をせずに有料 AI API を価格設定する方法

GPT や Claude を定額のコール単価で再販・ラップしていると、1 つの大きなプロンプトだけで請求額を上回るコストがかかることがあります。その計算と、2 つの解決法を示します。

あなたは LLM をラップし、エンドポイントの背後に置き、きれいな定額——たとえば 1 回 $0.15——を請求しています。顧客には分かりやすく、扱いやすい。問題は、その下のモデルはコールごとに課金しないことです。トークンごとに課金し、トークンはプロンプトと応答のサイズに比例します。小さなリクエストでは大きなマージンを得ますが、大きなリクエストでは受け取った額を超えて支払うことがあり——プロバイダーの請求書が届くまで気づきません。

なぜ定額は漏れるのか

トークン課金モデルは、入力（送信するプロンプト）と出力（モデルが生成する内容）を別々に課金します。Claude の公式料金によると：

1 コールあたりのコストは単純に：

cost = (input_tokens × input_price + output_tokens × output_price) / 1,000,000

Opus 4.8 を定額 $0.15/回 とします。出力だけで 100 万トークンあたり $25——つまりわずか 6,000 出力トークンで $0.15、入力トークンを 1 つも数える前に売価をすべて使い切ります。顧客が 10 万トークンの文書をコンテキストとして送り、長い回答を求めれば、その 1 コールだけで請求額の数倍かかることがあります。ヘビーユーザー数人を掛ければ、"利益が出る"はずの製品は赤字で回ります。

リリース前に損益分岐を見つける

重要なのは、1 コールのコストが請求額を超える前に提供できる最大のプロンプトです。出力サイズを固定すると、損益分岐の入力サイズは：

break_even_input_tokens = (price × 1,000,000 − output_tokens × output_price) / input_price

Opus を $0.15、回答 800 トークンとすると：(0.15 × 1,000,000 − 800 × 25) / 5 = 26,000 入力トークン。プロンプトが約 26k トークンを超えると、毎コール赤字です。実トラフィックが常にそれを超えるなら、定額は誤ったモデル——または価格が低すぎます。

解決策 1 —— 入力と出力に上限を

定額を維持したいなら（顧客は予測可能性を好みます）、両側に上限を設け、最悪ケースのコールでも売価を超えないようにします：

• 入力サイズに上限を。トークン/文字数の上限を超えるプロンプトは拒否または切り詰める——しかも課金やモデル呼び出しの前に行い、過大なリクエストでコストが発生しないようにします。
• 出力に上限を（max_tokens）。余裕のあるデフォルトでも、高コスト側は抑えられます。$25/100万なら、出力 1,000 トークンごとに $0.025。
• 上限は上の計算から決める。worst-case cost < price となる上限を選び、リトライ・フォールバック・プロンプトキャッシュミスのための余裕を残します（約 25〜40% の余裕を確保）。
• 上限を公開する。入力/出力の上限を API スキーマに記載し、クライアントが予期せぬ拒否に遭う代わりに自ら制限できるようにします。

定額のエンドポイントが破綻しない仕組みは、まさにこれです：価格は固定でも、その裏側の作業量に上限があるため、決して赤字にならないのです。

解決策 2 —— 従量課金

もう一つの方法は、コールが一様だと装うのをやめ、実際の消費量で課金することです：トークンを計量する（多くはコストに対する上乗せ倍率付き）か、リクエストサイズに応じた段階価格にします。きれいな数字という単純さは失いますが、価格がコストに連動するため、大きなリクエストで損をすることは決してありません。プロンプトサイズが大きくばらつく、または大コンテキスト処理を提供する場合は従量課金が正解です。

隠れたコストを忘れずに

• リトライ＆フォールバック。失敗して別モデルで再試行されたコールは、顧客から見える 1 リクエストのトークン消費を倍にしかねません。
• プロンプトキャッシュのミス。キャッシュは繰り返しプレフィックスのコストを約 90% 削減しますが、ヒット時のみ——静かな無効化要因（システムプロンプト内のタイムスタンプ、未ソートの JSON）があると、毎回フル価格を払うことになります。
• 思考 / 推論トークン。拡張/適応思考を有効にすると、それらのトークンも出力として課金されます。

どのモデルを選んでも、規律は同じです：コール単価を把握し、損益分岐を把握し、最悪ケースが課金顧客に届く前に上限を設けること。