AIものさし

Dify CloudのAI creditsとAPIキー｜利用経路と請求先を確認する

Dify Cloudのワークスペース契約、AI credits、自分のAPIキーを分け、Usage Priorityとモデル呼出し回数から費用の確認先を整理します。

AIものさし編集部

Dify CloudでAIアプリを動かすときは、Difyの契約、AI credits、自分で接続したモデル提供元の利用料を分けて確認します。特に、AI creditsとAPIキーを併用している場合、「Difyの残高が減らないから費用も発生していない」とは判断できません。

この記事はDify Cloudの公式資料を基にした、モデル利用経路と費用の確認手順です。セルフホスト環境の運用費は対象外です。Difyへの登録、キー設定、モデル呼出し、請求確認は行っていません。途中の案件と実行記録は説明用の架空例です。

目次

三つの確認先を分ける

まず、何に対する費用や制限なのかを整理します。

表は横にスクロールできます

確認先確認する内容混同しないもの
Difyの契約対象ワークスペースのプラン、機能、利用枠すべての接続先モデルを無制限に使う権利
AI credits対応モデルをDifyのクレジットで使う経路アプリの実行回数そのもの
モデル提供元のアカウント自分のAPIキーを使ったモデル利用と請求Difyのクレジット残高

Dify公式のBilling（新しいタブで開く）は、契約をワークスペース単位と説明しています。Settings > Billingでは、OwnerとAdminが契約・利用状況・請求履歴を管理します。自分が今開いているワークスペースと、確認している請求先が一致するかを先に見てください。

ワークスペースの説明（新しいタブで開く）でも、アプリはワークスペースのモデル設定を引き継ぐ構成です。一人が作ったアプリだからといって、その人だけのモデル設定や費用として独立しているとは考えません。

Sandboxの200 creditsを「毎月200回」と読み替えない

公式のQuick Start（新しいタブで開く）は、新規アカウントのSandboxに200 AI creditsが含まれ、月次補充ではなく一度限りの割当と説明しています。対象モデルは、提供元をインストールすると自分のAPIキーなしで使える案内です。

ここでの単位は「credits」です。「毎月200回アプリを実行できる」「200件の問い合わせを必ず処理できる」とは読み替えません。どのモデルを何回呼ぶかで、業務一件との対応が変わります。実際の付与と現在の条件は、契約画面と公式案内で確認してください。

APIキーを併用するときはUsage Priorityを見る

公式のModel Providers（新しいタブで開く）では、モデル提供元を管理できるのはワークスペースのOwnerとAdminです。追加したAPIキーはワークスペース全体で使われ、費用はそのキーに対応する提供元アカウントへ発生します。

同じ資料は、AI creditsと自分のキーを併用でき、Integrations > Model Providerにある提供元カードのUsage Priorityで先に使う側と、もう一方へのフォールバックを制御すると説明しています。

そのため、AI creditsを先に使う想定でも、キーを併用した構成ではクレジットがなくなった後に提供元側の利用へ移る可能性があります。クレジット残高だけを、すべての費用が止まる仕組みとして扱わないでください。

既に接続された環境なら、変更する前に次を記録します。

  • 今開いているワークスペース。
  • 対象アプリが呼ぶモデルと、その提供元。
  • AI creditsを使う設定か、自分のキーを使う設定か。
  • 両方ある場合のUsage Priority。
  • キーに対応する提供元アカウントと、その管理担当。

キーの値を記録表や依頼文へ貼る必要はありません。管理者に確認するのは、どの経路と請求先を使う設定なのかです。利用経路が確認できなければ、「無料で動くはず」と決めて試行を繰り返しません。

一件の依頼と、モデル呼出し回数を分ける

Model Providersは、AI responseを一回のモデル呼出し、つまり一組の入力と出力として説明しています。一応答の消費creditsはモデルによって異なります。応答数をそのままcredits数にも変換しないようにします。

架空の「問い合わせを分類し、返信案を作り、内容を確認する」処理を考えます。ここでは各工程が一回だけモデルを呼び、再試行はないものとします。

表は横にスクロールできます

架空の依頼実行した工程モデル呼出し数
A：返信案まで作る分類、下書き、確認3
B：分類だけで終える分類1
合計依頼は2件、モデル呼出しは別に数える4

この例の確認結果は「2件の依頼で4回のモデル呼出し」です。4 credits、4円、実環境の請求額という意味ではありません。採用モデルごとの消費条件と、実際に使った経路を確認しなければ、費用は決まりません。

また、アプリの画面へ一つの回答が返ったことだけから、内部でもモデルが一回しか使われなかったとは判断しません。ワークフローの経路、モデルを呼ぶ工程、再試行を含め、実際の処理記録と対応させます。

費用が想定と違うときの確認順

  1. 対象を固定する。 ワークスペース、アプリ、実行時刻、モデルを揃えます。別のワークスペースや期間の残高を比較しないようにします。
  2. 利用経路を確認する。 対象提供元のAI credits、キー、Usage Priorityを管理担当と確認します。残高が減っていないという観察だけで経路を確定しません。
  3. 処理回数を対応させる。 業務の件数、アプリ実行、モデル呼出しを分けます。再試行や追加工程があれば別に残します。
  4. 記録を突き合わせる。 Dify側の確認情報と、キーを使った場合の提供元側の利用記録を、同じ対象・期間で照合します。
  5. 未確定を残す。 提供元側を見られない、当時の設定が分からない、同じキーが別の処理でも使われている場合は、金額の原因を断定しません。

提供元の利用料が見えても、その期間の全額を一つのDifyアプリへ割り当てるには根拠が必要です。専用の管理単位や対応する実行記録がない場合、単なる時刻の近さだけでは内訳を確定できません。

管理者へ渡す確認メモ

「Difyが無料ではなかった」という報告より、対象と不明点を分けた方が確認しやすくなります。

表は横にスクロールできます

項目架空の確認メモ
対象チームの検証用ワークスペース、返信案アプリ
観察対象期間にアプリを使ったが、AI creditsの変化が想定と違う
確認したものアプリ名、実行時刻、選択モデル
未確認当時のUsage Priority、キー側の利用、他アプリとの共用
依頼利用経路と請求先を確認し、続行前に費用の扱いを決める

このメモは架空例です。「キー側へフォールバックした」と確認できていない段階では、原因として書き込みません。現在の設定と当時の実行が対応するかも確認します。

次の試作へ進む前に、誰のワークスペースで、どのモデル経路を使い、どの管理担当が利用記録を確認するかを揃えます。支払い方法を追加すれば解決とせず、必要な処理を続けられることと、想定する費用管理ができることを合わせて判断してください。

参考資料

資料確認日：2026年10月21日。対象はDify Cloudです。モデル、消費条件、利用枠、設定画面は変わるため、利用時点の公式案内と対象ワークスペースを確認してください。