Cherry Studioの費用統計の見方：Requestsの空欄、Tokenの見積もり、実際の請求

Cherry Studioで画像は生成できたのに、RequestsのCostが空欄やダッシュになっていても、その生成が無料だったとは限りません。金額が表示されていても、そのままプロバイダーの請求額と見なすことはできません。まず 設定 → 使用状況 → リクエスト（Settings → Usage → Requests） で該当する記録を探し、費用の出所、課金単位、実際の課金額を照合しましょう。価格が未設定なのか、クライアントが見積もれないのか、それとも双方で別の呼び出しを集計しているのかを切り分けられます。

既存のリクエスト記録と請求記録を保存しておけば、Costに数字を表示させるためだけに画像を繰り返し生成する必要はありません。以下の画面と計算の説明は、公式の公開版ソースコードと取り込み済みの変更に基づきます。クライアントが費用を記録する仕組みを説明するものであり、特定のプロバイダー、モデル、アカウントの組み合わせを実際の呼び出しで検証した結果ではありません。

まずバージョンを確認する：画像単価の設定はmainに取り込み済み

2026-10-17時点で、公式のlatestリリースはv2.1.6です。画像単価を編集する機能のPR #21892は、同日にmainへ取り込まれました。 mainは開発ブランチです。変更が取り込まれたという記録だけでは、インストール済みの正式版にその機能が含まれているとは判断できません。正式リリースの記録、画像単価設定のPRを参照してください。

2026-10-16、codeBennyLawはWindowsのv2.1.6について、Issue #21870で、モデルの価格設定には100万Token当たりの項目しかなく、一部の画像リクエストのCostがダッシュになると報告しました。これはそのユーザーの環境についての報告です。すべての画像モデルが無料だという意味ではありません。IssueはPRの取り込みに伴ってクローズされましたが、自分の画面を判断する際は、引き続きインストール済みのバージョンを確認してください。

実際に使っている画面	できること	対応
v2.1.6のモデル価格エディター	入力、出力、キャッシュのToken単価と価格帯を編集できる。画像単価の入力欄はない	Token課金のモデルはToken単価を確認する。画像単位の課金はプロバイダーの記録と直接照合する
PR #21892を含み、Price unitとImage priceが実際に表示されるビルド	生成画像1枚当たりの価格を編集できる	プロバイダーが画像数に応じて課金することを確認し、単価を入力して新しいリクエストで確認する
上記と画面が異なる新しいビルドや独自ビルド	機能はそのビルドによる	そのビルドの説明と実際の項目を確認する。別バージョンの画面から設定を推測しない

この区別は、v2.1.6の価格エディターと変更取り込み後の価格エディターに基づきます。以下では設定を見つけやすいように英語の項目名を併記します。実際の表示名はクライアントの言語設定によって変わります。

Requestsで同じリクエストを特定する

金額を比較する前に、同じ呼び出しの記録かどうかを確認します。 クライアントのバージョン、当時使用したプロバイダー設定、正確なモデルID、同じプロバイダーアカウントの使用量または課金記録を用意してください。モデルの表示名が同じでも、同一のモデルや課金経路とは限りません。

1. Settings → Usage → Requests を開き、対象リクエストを含む期間を選択して、Dateで該当する記録を探します。
2. 各行のモデル名と、その下にあるプロバイダー名を照合します。Sourceは、その呼び出しがどのアシスタント、セッション、機能から発生したかを示します。費用の出所ではありません。
3. 日時、Tokens、Cost、通貨を控えます。記録が見つからない場合は、まずDateでの並べ替えに戻し、期間を確認して、一覧下部から追加の記録を読み込みます。Costで並べ替えると、選択した通貨による絞り込みも適用されるため、費用が欠けている記録は結果に含まれない場合があります。
4. プロバイダー側の同じ時間帯の記録も保存します。クライアントに記録される日時は呼び出しの完了時刻です。プロバイダーは別の計上時刻やタイムゾーンを使う場合があるので、まず呼び出し全体を含む時間帯で照合してください。

項目と表示方法は、公式のRequestsテーブルのソースと記録の書き込み処理で確認できます。

一覧全体に記録がないなら、期間、読み込み、呼び出しが完了しているかを先に確認します。Costだけが欠けているなら、価格と費用の出所を調べます。この2つは次に取る対応が異なります。再インストールや履歴の削除だけでは、プロバイダーに課金されたかどうかは分かりません。

Costには3つの状態がある：Source列では費用の出所は分からない

表示の細かさより、その金額がどこから来たかが重要です。 公式の記録処理は、条件を満たすプロバイダーの費用を先に採用します。採用できなければ、リクエスト時点で保存した価格スナップショットから見積もり、どちらも使えなければ空欄にします。費用の記録処理にこの順序が定義されています。

記録の状態	意味	照合での扱い
costSourceがprovider	クライアントがプロバイダーから返された費用を採用した。プロバイダーの機能宣言、金額、通貨の条件を満たす必要がある	そのレスポンスに含まれていた費用として扱い、アカウントの実際の課金記録と照合する
costSourceがcomputed	クライアントが使用量と当時の価格スナップショットから計算した	見積もりや傾向の把握に使い、ローカルの単価が実際のアカウントの条件と一致するか確認する
Costが欠け、出所も空	採用できるプロバイダーの金額がなく、ローカル計算もできない	金額は不明。実際の課金額をプロバイダーの記録で確認し、ゼロに置き換えない

v2.1.6では、Costの欠損値は - と表示されます。今回確認したmainの英語表示は Unable to estimate です。現在のRequestsテーブルには、独立したcostSource列も、費用の出所を示すツールチップもありません。Source列をその代わりにしたり、金額だけから出所を推測したりしないでください。 画面に明示されていなければ、出所は未確認として扱います。mainのテーブル、英語表示の定義を参照してください。

プロバイダーがレスポンスに費用フィールドを入れていても、クライアントが必ず採用するわけではありません。実際の課金額を返すプロバイダーとして宣言されているか、通貨を特定できるかなどの条件もあります。内部記録を編集する必要はありません。実際の課金額と一致するかは、最終的にプロバイダーのアカウントで確認します。公式の費用仕様に詳しい条件があります。

Tokenから費用を見積もる：単位と内訳を確認する

RequestsのTokensは使用量の合計なので、単一の単価をそのまま掛けることはできません。 computedが示すのは、金額をローカルで計算したということだけです。Token数自体がローカルの推定値だという意味ではありません。公式の合計関数はtotalTokensを優先し、それがなければ既知の入力数と出力数を加算します。両方とも不明なら欠損値のままにします。Token合計の定義で確認できます。

Settings → Model Provider → プロバイダーを選択 → 対象モデルの歯車 → More settingsから、価格の設定部分を開きます。そのアカウント、モデル、価格帯に適用される現在の単価と照らし合わせてください。

• **Input Price / Output Price：**入力と出力それぞれの100万Token当たりの単価です。プロバイダーが1,000Token当たりの価格を示している場合は、100万Token当たりに換算してから入力します。数字だけをコピーしないでください。
• **Cache Read Price / Cache Write Price：**キャッシュの読み取りと書き込みの単価をそれぞれ確認します。現在のエディターでは、空欄にするとその価格帯の入力単価が適用されます。0を入力するとローカル計算で無料の単価として扱います。空欄は無料という意味ではありません。
• **入力長に応じた価格帯：**クライアントは今回の入力全体の量から価格帯を1つ選び、その単価を呼び出し全体に適用します。使用量を区切って順番に異なる単価を掛ける累進方式ではありません。必要な使用量や単価が欠けていれば、見積もりは空欄のままになる場合があります。

項目と保存処理は価格エディター、計算の扱いは公式の費用仕様を参照してください。

照合用の記録には、内訳ごとの使用量と単価を一緒に残します。計算の形は、キャッシュを使わない入力 × 入力単価 ＋ キャッシュ読み取り × 読み取り単価 ＋ キャッシュ書き込み × 書き込み単価 ＋ 出力 × 出力単価です。各項を100万Token当たりの単位にそろえて計算してください。入力合計にキャッシュ分が含まれている場合は、まず内訳に分け、キャッシュ数を通常の入力に重複して加えないようにします。推論Tokenがすでに出力に含まれている場合も、もう一度足してはいけません。内訳が得られない部分は不明として残し、Tokensの合計だけから正確な請求額を推測しないでください。

通貨にも注意が必要です。確認した価格エディターでは、$はUSD、¥はCNYを表し、JPYではありません。記号を切り替えても為替換算は行われません。入金額や銀行明細が現地通貨で、モデルの単価が米ドルの場合は、まずドル建ての呼び出し費用を照合し、入金時の為替レートと手数料を別に確認します。異なる通貨の金額を直接足し合わせないでください。通貨の対応と価格保存のソースが根拠です。

価格を変更したら入力欄の外をクリックし、同じモデルを開き直して値が保存されたか確認します。プロバイダーに価格倍率や時間帯別の価格ルールが設定されていないかも確認し、すでに倍率込みの実際の単価に、再び倍率を掛けないようにしてください。過去のリクエストには元の価格スナップショットが使われるため、今価格を変えても自動で新しい金額にはなりません。倍率・時間帯ルールのソース、リクエスト時点の価格スナップショットを参照してください。

画像のCostが空欄なら、リクエスト単位か画像単位かを先に確認する

1リクエスト当たり、画像1枚当たり、画像Token当たりの課金は、それぞれ別の条件です。 1つのリクエストで複数の画像が返ることがあります。リクエスト単位の定額を、そのまま画像1枚の単価にしたり、Input PriceやOutput Priceへ入力したりしてはいけません。

v2.1.6には内部的な画像単価の計算条件がありますが、デスクトップの価格エディターに対応する入力欄はありません。ローカル計算には、実行時の価格スナップショットにperImageがあり、そのunitがimageで、呼び出しからimageCountが提供されることが必要です。Token単価だけがある場合や、単位がpixelの場合は不十分です。画像費用の計算条件で確認できます。

使用中のビルドに新しい項目が実際に表示され、プロバイダーが生成画像数に応じて課金すると明示している場合は、次のように設定します。

1. 同じプロバイダー、同じモデルの価格設定で、Price unitをImageに切り替えます。
2. Image priceに、該当する通貨の画像1枚当たりの単価を入力します。入力欄からフォーカスを外すと自動保存されるので、モデルを開き直して確認します。
3. 価格が不明なら空欄のままにします。単価が本当にゼロの場合だけ0を入力してください。任意にゼロを入れても変わるのはローカル表示であり、プロバイダーの課金が止まるわけではありません。
4. この選択は、どの価格を編集するかを切り替えるだけです。Token単価と画像単価はどちらも保持されます。「リクエストごとの定額課金」モードを追加するものではなく、ピクセル数や画像Tokenによる見積もりにも対応するわけではありません。
5. 変更後の新しい生成1回で照合します。結果を取得したら、実際に返された画像数、リクエスト時刻、新しいCostを控え、プロバイダーの記録と比較してください。ローカル計算は「生成画像数 × リクエスト時点で有効な画像単価」を使い、適用される倍率や時間帯ルールも考慮します。確認用の新しいリクエストにも料金が発生し得るので、もともと必要だった次の生成で確認するのがよいでしょう。

この手順は、新しい価格エディターと価格の保存関数に基づきます。項目が見つからなければ、まずプロバイダーの実際の記録で照合し、インストールした正式版に機能が含まれていると確認できてから設定してください。

画像単価を入力しても、新しいリクエストのCostが欠けることはあります。別のモデル設定で呼び出している、画像数が得られない、通貨情報が不完全、実際の課金条件が画像単位ではない、といった可能性を個別に確認します。公式のカスタム画像タスク処理は、返された画像URLの数をimageCountとして記録します。そのため、ローカルでダウンロードに成功したファイル数を、そのまま代わりに使うことはできません。この数がすべてのプロバイダーの請求上の数量と一致する保証もありません。画像タスクの記録処理を参照してください。

プロバイダーの課金記録と照合し、差を説明できる記録を残す

月間合計をいきなり比べるより、完了した1件のリクエストから照合する方が違いを見つけやすくなります。 同じプロバイダーアカウントを使い、Keyのラベルやグループで区別できる場合はそれも記録してください。ただし、スクリーンショットや問い合わせには完全なキーを含めないでください。

保存する項目	Cherry Studio側	プロバイダー側
対象の識別	クライアントのバージョン、プロバイダー設定、モデル表示名と正確なID	実際のアカウント、モデルID、適用された価格帯
時間	リクエストの完了時刻とローカルのタイムゾーン	計上時刻、タイムゾーン、同じ呼び出しを含む時間帯
数量	表示されるTokens、画像タスクで実際に返された画像数	入力、出力、キャッシュなどの使用量内訳、課金対象のリクエスト数または画像数
金額	Cost、通貨、欠損値を元のまま保存	実際の課金額、通貨、確認できる返金や調整
対応関係	リクエストが属するセッションや機能	プロバイダーが提供するリクエスト識別子や請求識別子

双方に同じプロバイダーのリクエストIDが明示されていれば、それを優先して照合できます。なければ、アカウント、モデル、時間帯、数量を組み合わせます。Cherry Studioの内部リクエスト識別子には独自の命名方法があるため、プロバイダーのIDと同じだと決めつけないでください。公式の記録構造に説明があります。

すでにBetterTokenを利用している場合は、公式の使用量案内に従って、コンソールで現在の使用量と課金履歴を確認できます。そのうえで、画面に実際に用意されている項目を使い、モデル、時刻、状態、Tokenを照合してください。

金額が一致しなければ、次の順で確認します。

• **数量から一致しない：**同じアカウントを他のツールでも使っていないか、1回の操作で複数の呼び出しが発生していないかを確認します。クライアントから観測できないSDKの再試行は、Requestsに入らない場合があります。双方の件数が必ず1対1になるとは限りません。
• **数量は同じなのに金額が違う：**モデル、画像単位・リクエスト単位・Token単位の区別、キャッシュのルール、価格帯、通貨、倍率、アカウントの実際の単価を確認します。リクエストが発生した時点の古い価格スナップショットも確認してください。
• **プロバイダーでは課金されているが、Costは空欄：**空欄を維持し、対応する金額とともに「クライアントでは見積もれず、プロバイダーでは課金済み」と記録します。欠損値を自分でゼロに変えないでください。
• **クライアントに記録がない、または失敗表示なのに、プロバイダーには記録がある：**プロバイダーの完了判定、課金、返金のルールを先に確認します。機密情報を除いた日時、モデル、プロバイダーのリクエスト識別子を提示し、再現のためにすぐ大量のリクエストを送り直さないでください。

公式では、この使用量記録を、可能な範囲で取得する分析用データとして位置付けています。クライアントが観測できない再試行、失敗、移行された過去の記録などは、件数の比較に影響し得ます。実際の課金額はプロバイダーの記録を基準とし、その記録の不明点はプロバイダーに確認します。Costの空欄から判断することはできません。記録の対象範囲と限界を参照してください。

何を確認できれば照合は完了か

同じリクエストについて双方の記録を保存し、次の3点を説明できる状態が目標です。どのモデルと課金単位を使ったか、クライアントの金額の出所が明確か、それとも見積もり・不明か、そしてプロバイダーの最終的な課金額と差の理由です。 ローカルの価格を変えた場合は、新しいリクエストで保存と計算結果を確認します。古いリクエストは元の値を残し、過去のデータが新しい価格で再計算されることを期待しないでください。

まず既存の画像リクエストを1件選び、バージョン、モデル、時刻、実際の画像数、Cost、プロバイダーの課金額を控えましょう。その1件を説明できてから、集計期間を広げます。説明できない場合は、不足している項目と該当リクエストをまとめ、プロバイダーまたはクライアントの開発プロジェクトに調査を依頼してください。