その AI API 中継は
使う価値があるかの見極め方
自分で回せる 4 つの検証：倍率を正しく読む、キャッシュ命中を測る、レスポンスの model を見る、usage と請求を突き合わせる。同じ入力を 3 回以上送り、1 回目を捨てて初めて定常値になります。
いちばん手軽な 4 つの検証
キャッシュは連投で測る
1 回では命中率は分かりません。同じ入力を 3 回以上送って初めて定常値が出ます。
コールドスタートは定常ではない
初回はほぼ確実にコールドスタート。平均に含めると命中率が上にも下にもぶれます。
最も安価な探り
レスポンスの model と usage は「頼んだものが返ってきたか」を無料で確かめられる 2 つの信号です。
増やす前に試す
最小額をチャージして全工程を通し、課金の基準と返金・譲渡の条件を確認してから増やします。
「安い」がいちばん当てにならない理由
同じ「0.1 倍」でも、公式価格に対する 0.1 なのか、社内の記帳単位に対する 0.1 なのかで意味が変わります。「¥1 = $1 クォータ」も等価に見えますが、それは割引ではなく記帳単位です。横並びで比べられる数は 1 つだけ ——「支払額 ÷ 公式価格換算で受け取ったクォータ」。これを出してから比べると、多くの価格表は魅力を失います。
まず「クォータ $1 あたりいくら払うか」を出す
任意の価格表について、実際の支払総額 ÷ 公式価格換算のクォータ を計算します。初期費用・手数料・ボーナスクォータの有効期限も按分してください。使用期限や出金制限のあるボーナスは額面で数えられません。出てくるのは「通貨 / クォータ $1」という、事業者をまたいで比較できる単価です。
試用の順番
少額をチャージし、登録・支払い・キー発行・初回リクエストまで一通り通します。ここで見るのは速度ではなく、詰まる工程がないか、サポートに連絡が付くかです。
同じ入力を 3 回以上送り、1 回目を捨てて残りの usage を読みます。テストごとに固有のランダム文字列を付け、自分のキャッシュが読みを汚さないようにします。
数回分の usage を合計し、請求の差し引きと 1 件ずつ突き合わせます。合わなければ質問し、筋の通る説明が得られなければ量を増やさないことです。
測れること vs 測れないこと
自分で測れる
① クォータ $1 あたりの実質単価（計算するだけ）。② 定常状態のキャッシュ命中率（同一入力の連投）。③ レスポンスの model がリクエストと一致するか。④ usage と請求が合うか。⑤ 日次上限・並列上限・1 回あたりのチャージ上限の有無。
測れない
① 上流アカウントの出所と状態。② 事業者の資金繰りと存続期間。③ 送ったリクエスト本文が保存・再利用されるか。④ ピーク時の実容量。これらは規約・評判・時間でしか判断できません。だからこそ「まず少額、あとで増やす」が単発のテストより効きます。
よくある 2 つの形
従量課金（残高から差し引き）
実際の token 消費で課金。使い残しが無駄にならず繰り越せます。確認すべきは単価の基準、残高の有効期限、譲渡可否。使用量の波が大きい人向け。
月額プラン（日次上限つき）
定額で日次または月次の枠を買います。費用は読みやすい一方、使い残しは通常返金も繰り越しもされません。名目単価は上限ではなく実際に使い切れる量で割って評価してください。使用量が安定している人向け。
見落とされがちな 3 点
① 1 回あたりのチャージ上限：決済チャネル側の制限で、大きい金額は分割か銀行振込になることが多いので事前に確認を。② 残高の譲渡・出金可否：デジタル商品は返金不可が多く、譲渡できるかどうかが失敗時の回収余地を決めます。③ 通貨の相互利用：人民元残高と米ドル残高が別勘定で相殺できないプラットフォームがあります。
QCode では
公式価格 × サービス料率で計算し、レスポンスの usage がそのまま差し引きの根拠になります。請求は 1 件ずつ突き合わせ可能です。上記の方法は当社にもそのまま当てはまります —— 最小額で一度回してから判断してください。明記すべき 2 点：返金には対応していません（開通した時点でアカウント資源を占有するため）が、会員間の残高譲渡には対応しています。人民元残高と米ドル残高は別勘定で相互に移動しません。
よくある質問
倍率 0.1 と「¥1 = $1 クォータ」はどちらが安い？
直接は比べられません。前者は公式価格に対する比率、後者は記帳単位です。どちらも「支払額 ÷ 公式価格換算のクォータ」に直して初めて同じ物差しになります。
頼んだモデルが返ってきたかを確認するには？
レスポンスの model がリクエストと一致するかを見ます。リクエストに無かった接頭辞・接尾辞・プロバイダ名が付いていれば、途中に書き換え層があります。それ自体が悪いとは限りませんが、何を書き換えているかは確認する価値があります。
キャッシュ命中率はどう測れば正確？
ある程度長い入力を固定し、3 回以上連投して 1 回目（ほぼ確実にコールドスタート）を捨て、残りの usage のキャッシュ読み取り量を見ます。テストごとに固有のランダム文字列を付け、別のテスト同士で命中しないようにします。
請求と usage が合いません。過大請求ですか？
とは限りません。よくある正当な理由：キャッシュの書き込みと読み取りが別計上、思考トークンが出力に計上、ツール呼び出しで往復が増える、集計が現地時間か UTC か。まず基準を確認してから誤りかどうかを判断してください。
事業者が消えるリスクはどう見積もる？
少額から始められるか、返金と残高譲渡の条件が明文化されているか、サポートがどれくらいで応答するか。そして時間 —— 同じドメインで安定運営してきた期間は、どんな宣伝文句より情報量があります。大金を一度に預けないことです。
やけに速いレスポンスを警戒すべき理由は？
同じモデル・同じ入力なら所要時間には下限があります。極端に速い回があれば、出力品質と model の返り値をついでに見てください。速いのは good news（キャッシュ命中）のこともあれば、想定した段でない可能性もあります。
情報源
本ページの検証方法は公開・再現可能な信号に基づきます：レスポンス本文の model と usage（各社の公式 API ドキュメントに定義あり）、キャッシュの課金規則（各社の料金ページ）。特定の事業者名は挙げず、未確認の噂も再掲しません。ご自身の実測と各社の公式規約が優先します。確認日 2026-09-02。
関連記事
QCode 料金ガイド
プランの段階、単価の考え方、よく誤解される計算。
AI コーディングツール比較
主要な CLI と IDE の違いと向き不向き。
中国本土での Claude Code 利用
ネットワーク、エンドポイント、よくある設定の問題。
本ページは一般的な検証方法を示すもので、特定の事業者に対する評価や推奨ではありません。規約・上限・課金規則は各社の公式ページが優先し、随時変更されます。