Qwen3.8-Max・Kimi K3・DeepSeek V4の請求を揃える

請求画面ではQwen3.8-MaxがCredits、Kimi K3とDeepSeek V4がToken表示になり、月額料金だけでは安さを判断できません。

今週の最短解決策は、料金表を直接比べず、7日分の利用履歴を「成功して納品できたタスク数」で割ることです。 Qwen3.8-MaxはCreditsの消費量、Kimi K3とDeepSeek V4はキャッシュ入力、通常入力、出力、再試行、ツール呼び出しを分けて記録します。

この記事は、3モデルの試用請求を整理する個人開発者、API予算を管理する技術責任者、コード生成や自動化Agentを運用するチーム向けです。総合性能ランキングではなく、異なる請求方式を同じ判断表へ落とし込むための内容です。

最終更新：2026年8月8日。QwenCloud、Kimi API、DeepSeek APIの公式モデル・料金・利用量仕様を確認しています。

まず「1回の呼び出し」ではなく「成功タスク」を分母にします

月額プランの料金、Creditsの残量、100万Tokenあたりの価格は、それぞれ別の情報です。特にQwen3.8-MaxのToken Planは、複数のモデルやツールをCreditsで利用する仕組みであり、公式資料でもモデルごとに消費係数が設定されると説明されています。Creditsを独断でToken単価へ変換する公式の固定比率は確認できません。

QwenCloudの個人向けプランには5時間枠と7日枠があり、未使用分は次の期間へ繰り越されません。QwenCloudのToken Plan仕様では、Qwen3.8-Max-Previewがプレビュー版であり、終了後に停止または正式版へ置き換えられる可能性も示されています。したがって、期間限定の割引やプレビュー時の消費軽減を、長期予算の通常単価として保存してはいけません。

一方、Kimi APIは入力、キャッシュ入力、出力をToken単位で請求します。Kimiの公式料金案内では、Kimi K3が100万Tokenのコンテキストに対応し、キャッシュヒットとキャッシュミスを分けて扱うことが説明されています。DeepSeek APIも入力キャッシュヒット、入力キャッシュミス、出力を分けて請求し、APIの利用量レスポンスで該当Token数を確認できます。料金項目の確認にはKimi APIの公式料金案内を使用します。

実務では、次の式だけを共通の基準にします。

有効タスク単価
＝ 期間中の総費用 ÷ 受け入れ条件を満たした成功タスク数

総費用には、モデル費用だけでなく、再試行、追加のAgent呼び出し、Web検索などの外部ツール費用を含めます。失敗したHTTPリクエストが課金されないサービスでも、タイムアウト後の再送や、ツール失敗後にモデルが組み立て直す呼び出しは別の費用になるため、ログ上で分離する必要があります。

注意： 「1回の回答が安い」と「納品物を1つ完成させる費用が安い」は別です。コード修正、テスト実行、レビュー、再生成まで含めない比較は、Agent用途では特に誤差が大きくなります。

料金表を請求台帳へ変換する項目

最初に、各サービスの料金ページをそのまま比較表にするのではなく、同じ列を持つ請求台帳へ転記します。Qwen3.8-MaxはCreditsの消費記録を中心にし、Kimi K3とDeepSeek V4はAPIレスポンスのusage値を正本として扱います。

DeepSeekの公式料金ページでは、DeepSeek-V4-FlashとDeepSeek-V4-Proについて、キャッシュヒット入力、キャッシュミス入力、出力を別料金として掲載しています。また、公式APIは両モデルで1Mコンテキストとツール呼び出しに対応すると案内しています。DeepSeek API公式料金表を基準にし、画面の残高だけでなくリクエスト単位のToken数を保存します。

Qwen3.8-MaxのCreditsを100万Token単価へ直せますか。

長期予算の基準としては、直さない方が安全です。Creditsは入力Token、キャッシュToken、出力Tokenだけでなく、契約プラン、モデル係数、ツール利用、期間限定キャンペーンの影響を受けるためです。

同じプロンプトを10回送ってCreditsが何個減ったかを測ることはできますが、それは特定モデル、特定プロンプト、特定期間における観測値です。公式に固定された「1 Credit＝何Token」という換算値として保存せず、「この業務を1件完了するのに平均何Credits消費したか」で管理します。

長文書ではキャッシュの有無を3条件で分けます

長文書やコードベースの比較では、同じ入力Token数を送っても費用順位が変わります。固定されたシステム指示、リポジトリの共通ファイル、参照文書を毎回送り直す業務は、キャッシュを使えるモデルに有利です。ただし、会話履歴の一部を変更しただけでキャッシュ対象の先頭部分が変わる場合、期待したヒット率にならないことがあります。

Kimi K3の公式案内では、キャッシュヒット入力とキャッシュミス入力が別料金です。入力Token全体を一つの単価で計算しないようにし、APIのusage値から各項目を保存します。DeepSeekもキャッシュヒットTokenとミスTokenをusageに分けて返す仕様で、同一プレフィックスの再利用がキャッシュ判定の前提です。DeepSeekのコンテキストキャッシュ説明では、キャッシュの適用は入力の先頭から一致することが条件とされています。

比較時は、同じ長文書について次の3パターンを別のタスクとして記録します。

1. 冷起動：初回に文書やコードベースを送る。
2. 連続会話：同じ前提を保ったまま追加質問する。
3. 文脈変更後：主要ファイル、指示、出力形式を変更して再実行する。

Kimi K3とDeepSeek V4のキャッシュ費用を比べるとき、単価だけを見ればよいですか。

単価ではなく、キャッシュヒット率と出力長を掛け合わせて確認します。キャッシュ入力が安くても、毎回異なる前置きを追加してミス入力が増えれば、実効単価は上がります。逆に、同じリポジトリを何度も解析するレビュー業務では、固定プレフィックスを保てるかが費用差に直結します。

Agentの請求は再試行とツール費用を別建てにします

プログラミングAgentでは、最終回答を返したリクエストだけを集計してはいけません。1つのタスクを、計画、ファイル検索、コード変更、テスト実行、エラー修正、最終レビューという連鎖として扱います。

特に次の4つは、モデル単価とは別に記録します。

• モデルが自発的に行った再試行。
• ツールの失敗後に発生した再呼び出し。
• タイムアウト後の継続実行。
• 子Agentやサブタスクへ分岐した呼び出し。

QwenCloudの公式料金資料では、Function CallingやMCPはツール自体の追加料金がなくても、ツール定義が入力Tokenとして数えられる場合があります。また、Web検索など一部の組み込みツールには別料金が設定されています。QwenCloudのAPI料金とツール料金を参照し、モデル費用とツール費用を同じ列へ混ぜないようにします。

プログラミングAgentのAPI費用が料金表の試算より高くなる理由は何ですか。

主な理由は、出力Tokenの増加、履歴の再送、テスト失敗後の再試行、そして1つの依頼が複数のAPI呼び出しへ分解されることです。料金表に「入力100万Token、出力100万Token」と書かれていても、実際の1タスクが何回のリクエストで完了したかを含めなければ、成功タスク単価にはなりません。

DeepSeek V4では推論モードや推論強度もリクエスト条件として記録します。同じモデル名でも設定が異なる呼び出しを一つに集約しないことが重要です。

経験則： Agentの比較では、最終レスポンスの料金より、成功判定までに何回のモデル呼び出しとツール実行が必要だったかを先に確認すると、予算超過の原因を追いやすくなります。

第一歩：1週間のログから購入判断へ進めます

次の手順なら、3モデルを無理に総合順位へ並べず、用途別に判断できます。

1. 成功条件を固定します。
   例えば、コード変更後に指定テストが通る、文書要約の必須項目が欠落しない、Agentが人手修正なしで納品できる、といった受け入れ条件を先に決めます。

2. 同じタスク集合を用意します。
   短いコード修正、長文書の抽出、複数ファイルのレビュー、ツール連携を含むAgent作業を混ぜます。モデルごとに別の課題を使うと、請求差とタスク難度を区別できません。

3. リクエスト単位の利用量を保存します。
   モデルID、入力Token、キャッシュ入力、出力Token、推論設定、ツール呼び出し、HTTP状態、処理時間、再試行回数をCSVなどへ出力します。

4. タスク単位へ束ねます。
   1回のAPI呼び出しではなく、開始から成功判定までの全呼び出しを同じtask_idへまとめます。失敗タスクは成功件数に入れず、失敗するまでに消費した費用を別列で残します。

5. 有効タスク単価と成功率を並べます。
   費用だけでなく、成功タスク数、平均再試行回数、キャッシュヒット率、平均出力Tokenを並べます。安いが失敗が多いモデルは、運用費用を含めると順位が変わる可能性があります。

6. 条件分岐で採用候補を絞ります。
   データが足りない場合は、1つの総合ランキングを作らず、同じ条件で並行試行を続けます。

条件分岐による採用判断

• Creditsの利用率を予測したい場合は、Qwen3.8-Maxの契約期間、利用枠、モデルID、成功タスク数を優先して記録します。CreditsからToken単価を推定する方式には戻しません。
• 高頻度で安定したAPI呼び出しが中心の場合は、Kimi K3とDeepSeek V4を入力・キャッシュ・出力Tokenの実績で比較します。
• 同じ文書やコードベースを繰り返し参照する場合は、冷起動、連続会話、文脈変更後のキャッシュヒット率が高い候補を残します。
• Agentがテストや外部ツールを多用する場合は、単発のToken単価ではなく、再試行込みの成功タスク単価が低い候補を選びます。
• 請求変動、データ管理、API継続性が許容範囲を超える場合は、そこで初めてオープンウェイトモデルの自ホスト費用やクラウドMacの運用費を比較します。

API請求を揃えた後に自ホストを検討する基準

API方式の弱点は、料金改定、キャッシュ判定、利用制限、モデルIDの変更、障害時の継続性をチーム側で完全には制御できない点です。長時間のAgent実行では、再試行の費用だけでなく、環境が途中で切断された場合の復旧時間もコストになります。

そのため、まずは一週間分のAPI usageと成功記録を使い、この記事の項目で請求を一度正規化します。その結果、API料金よりも再試行、実行環境の継続性、データ管理、自ホスト検証の手間が大きな変数になった場合は、Qwen3.8-Maxのプレビュー費用を確認する記事やローカル実行環境の選び方を使って、次の比較へ進めます。

現在のAPI構成をそのまま使い続ける場合、料金単位がモデルごとに違うこと、キャッシュや再試行の内訳が見えにくいこと、長時間Agentの実行環境を別途管理しなければならないことが負担になります。短期の検証や一時的なAgent実行であれば、JexMacのクラウドMacを使って同じログ収集環境を用意し、API費用と実行環境費用を分けて検証する方が、購入前の判断を誤りにくくなります。JexMacの料金案内で利用条件を確認し、長期の安定負荷や物理インターフェースが必要な用途では自前のMacや専用サーバーと比較してください。