Skip to main content

​
クイックアンサー

リクエストが実際に実行される前に、APIYI は事前差し引き（「モデル価格 × 推定 token」＝発生しうる最大コスト）を計算し、その金額をいったん残高から確保します。リクエスト完了後に、実際に消費した token で精算して差額を返金します。つまり、事前差し引きはあくまで見積もりであり、最終請求額ではありません。
2つの重要な行
  • 事前差し引き: リクエスト前の見積もりで、「この呼び出しを支払えるか」を判断するために使います。
  • 実際の請求: リクエスト完了後に実際の token で精算されます。これが本当に請求される金額です。
事前差し引きの見積もり > 現在の残高 であれば、リクエストは実行前に拒否され、insufficient_user_quota が返されます。これが「残高は明らかにあるのに、なぜか通らない」の根本原因です。

​
事前差し引きの仕組み

1

リクエスト前: 見積もって一時確保

システムは、あなたの 入力（prompt、画像、会話履歴など）を読み取り、モデルの現在の料金と 推定出力長 を使って、最大想定コスト を算出し、それをいったん残高から一時確保します。見積もりはおおむね次のとおりです。pre-deduction ≈ model price × (input tokens + estimated output tokens)
2

事前チェック: 残高は足りるか

事前差し引き を 現在の残高 と比較します。
  • 残高 ≥ 事前差し引き → 許可され、リクエストが送信されます
  • 残高 < 事前差し引き → insufficient_user_quota で拒否され、実際には呼び出しは行われません
3

リクエスト後: 実際の使用量で精算し、差額を返金

完了すると、システムは実際の入力/出力 token 使用量を取得し、実際の使用量で再課金します。
  • 実際のコストが 通常は 事前差し引きより 少ない → 余分に確保されていたクォータは残高に 返金 されます
  • 失敗した/中断されたリクエスト → 通常は課金されず、確保されていたクォータは解放されます
大きな事前差し引きがあっても、実際にその金額を使ったことを意味するわけではありません — これは「最悪ケース向けの予備枠」の見積もりです。実際に課金されるのは、リクエスト完了後の実際の tokens です。

​
insufficient_user_quota エラーの読み方

事前差し引きが残高を超えると、次のような内容が表示されます:
項目ごとの意味: 重要なのは、2つの数値の比率です。ここでは事前差し引き154753475が残高50264897の約3倍なので、ブロックされています。
これらの数値は APIYI の内部クォータ単位であり、直接比較できます。USD で見ると、残高 ≈ $100、このリクエストの事前差し引き見積もり ≈ $310（内部では約500,000単位 ≈ $1）です。つまり、この1件のリクエストは $300 超を確保しようとした一方で、アカウントには $100 しかなかったため、実行できませんでした。

​
「残高はあるのに実行できない」

大半のケースでは、問題は残高そのものではなく、入力が大きすぎることです。 実例: gpt-5.5 は最大 1,050,000 tokens のコンテキストウィンドウを持っています。そこに大規模なコードリポジトリ全体を詰め込むと、入力 token 数が膨大になり、事前差し引きも大きく膨らみます。たとえ $100 の残高があっても、$300 の見積もりはリクエストが実行される前に拒否されます。
入力が大きいほど、事前差し引きも大きくなる入力が大きすぎると、事前差し引きが膨らんで insufficient_user_quota を簡単に引き起こすだけでなく、次のような問題もあります。
  • 通っても、実際のコストが高い（実際の tokens に基づいて課金される）;
  • 関係のない内容を詰め込みすぎると、モデルが平凡な結果しか返さないことがある — お金は使ったのに、結果はよくない。

​
どう修正し、回避するか

入力を絞る

関連するコード/ドキュメントだけを送ってください。リポジトリ全体や長い文書を一度に投げ込まないことが、最も効果的な対処です。

max_tokens を設定する

出力の長さを明示的に上限設定して、「estimated output tokens」を下げ、それによって事前控除を抑えます。max_tokens ガイドをご覧ください。

残高をチャージする

どうしても大きな入力が必要な場合は、残高 > 事前控除 となるようにしておけば十分です。支払い方法をご覧ください。

まず小さいモデルで試す

安価なモデルで入力が妥当かを検証してから、高性能なものに切り替えてください。支払える以上に「消費する」ことは避けましょう。
大きな入力には注意: 長いコンテキストウィンドウを持つモデル（gpt-5.5 の 1.05M tokens など）は多くを保持できますが、「保持できる」ことと「保持すべき」ことは別です。リポジトリ全体を詰め込むのは、たいていコストが高いわりに品質もいまひとつです。まず本当に必要なコンテキストを考えましょう。

​
よくある質問

いいえ。事前控除はあくまでリクエスト前の一時的な仮押さえです。最終的な課金は、リクエスト完了後の実際の token 使用量で確定し、仮押さえしすぎた分は返金されます。表示されているpreConsumedQuotaは「最悪ケースの予備見積もり」であって、実際の請求額ではありません。
通常はされません。insufficient_user_quotaエラーは実行前にブロックされるため、モデルは実際には呼び出されず、実コストも発生せず、仮押さえされたクォータは解放されます。
このエラーは、あなたの残高と「実際のコスト」を比較するのではなく、事前控除と残高を比較します。入力が大きすぎると、事前控除の見積もりが残高を大幅に上回るため、拒否されます。まず入力を減らすか、max_tokensを低く設定して推定出力を抑え、それでも必要ならチャージしてください。
モデルの単価はモデル自体で決まります。ウィンドウが大きいほど単価が高いわけではありません。とはいえ、ウィンドウが大きいほどより多くの入力を与えられ、実際にそれを埋めると入力 token が急増し、事前控除も実際の課金も高くなります。高くなるのは「どれだけ投入したか」であって、ウィンドウ自体ではありません。

​
関連ドキュメント

残高があるのになぜ実行できないのですか？

残高不足に関する完全なトラブルシューティングと解決策です。

max_tokens はどう設定しますか？

出力長を制御し、事前差し引きの見積もりに影響します。

Token 課金モード

使用量ベースの精算の仕組みを理解します。

支払い方法

残高が少ないときにすばやくチャージする方法です。