Difyはどのプランを買うべきか：共同で保守する人数を数え、モデル費用を計算する

チームが初めてDifyを購入するときは、モデル数の比較から始めがちです。しかし、実際にプラン選びを左右することが多いのは、誰がワークスペースに入ってアプリを保守する必要があるか、そして1件の業務リクエストでモデルを何回呼び出すかです。一人で社内向けの質問応答フローを検証するだけなら、まずSandboxを使いましょう。4人の同僚が全員で保守する必要があるなら、3人用のProfessionalを長期的な選択肢と考えるべきではありません。

以下の判断は、2026年11月3日に確認した公式料金ページとドキュメントに基づいています。負荷テストの結果ではなく、特定のプランが実際の同時処理需要を満たせると保証するものでもありません。

公式料金ページに記載されているワークスペースのメンバー上限は、Sandboxが1人、Professionalが3人、Teamが50人です。これを、そのアプリが1日に対応できる訪問者数とそのまま解釈してはいけません。購入時は、ワークスペースへのログイン、フローの変更、ナレッジ資料の保守が必要な人をまず書き出し、そのうえでアプリの提供方法に応じたアクセス要件を別途確認します。

例えば、業務責任者、フロー保守担当者、ナレッジベース保守担当者がちょうど3人なら、Professionalを候補にできます。4人目にも継続的にワークスペースの保守へ参加してもらう必要があるなら、複数人で一つの管理アカウントを共有するのではなく、Teamを検討すべきです。上司が出力をたまに見るだけなら、まず提供方法を確認し、読む人が一人増えただけでアップグレードしないようにしましょう。

現在の月払いの表示価格は、Professionalがワークスペースあたり59米ドル、Teamがワークスペースあたり159米ドルで、いずれも適用される税金を含みません。月額の差は100米ドルです。この差額に見合うかどうかは、追加の共同作業者が本当にワークスペースの席を必要としているかを先に確認して判断します。メンバー数を性能指標として扱うものではありません。

Difyのクレジットはモデルの応答ごとに差し引かれます。1回の応答とは1回のモデル呼び出しであり、業務担当者が送信する一連のリクエスト1件と同じではありません。複雑なフローでは、最初に分類し、次に検索して生成し、最後に書式を確認することがあります。この3つのステップでそれぞれ1回ずつモデルを呼び出すなら、1件のリクエストに3回の呼び出しが含まれます。これは費用計算のための例であり、すべてのDifyフローが必ず3回呼び出すという意味ではありません。

自分で用意したモデルのAPI keyに伴う費用は、対応するプロバイダーのアカウントに請求されます。そのため、予算は少なくともDifyのワークスペース契約と、自分のkeyで発生するモデル費用の2項目に分ける必要があります。プロバイダー側のレート制限も別途確認してください。Difyのプランを上げたからといって、あらゆるモデル呼び出しが無制限になると判断することはできません。

すでに使用を許可された製品説明資料を基に、カスタマーサポートの返信案を生成するなど、リスクの低いフローを選びます。模範解答のある質問を20件用意し、資料の不足、曖昧な表現、対象範囲外の質問も含めます。この件数は試行のための提案であり、公式のテスト基準ではありません。

同じフローを質問ごとに実行し、回答を採用できるか、各質問でモデルが何回呼び出されるか、人による修正が必要か、どのステップで失敗するかを記録します。試行の目的は見栄えのよい平均値を出すことではなく、2種類の問題を区別することです。誤った資料を頻繁に引用するなら、まずナレッジベースと検索ロジックを修正すべきです。回答がすでに使える状態なのに、共同作業者数やリソースの上限が妨げになっているなら、その段階で有料アップグレードを検討します。プランのアップグレードは、コンテンツ品質の改善の代わりにはなりません。

公式のDocker Composeドキュメントに記載された最低ハードウェア要件は、2コアCPUと4 GiBのメモリです。これは導入の最低要件にすぎず、本番環境での処理能力を保証するものではありません。また、アップグレード時には追加・変更された環境変数を確認するよう求められており、セルフホストはインストール後に保守が不要になるわけではないことが分かります。

アップグレード、バックアップの検証、障害対応を誰が担当するか明確にできないチームでは、まずクラウドサービスを購入したほうが、通常は責任範囲と必要な投入を見積もりやすくなります。運用保守の能力があるなら、実際のデータフローと管理要件に照らしてセルフホストを検討してください。選択したモデルや外部サービスにデータがどう送られるかも確認する必要があります。アプリを自社サーバーに置いたというだけで、すべてのデータが内部にとどまるとは判断できません。

立ち上がったばかりのチームにとって堅実な購入順序は、小さなサンプルでフローの有用性を確かめ、実際に共同で保守する人数を確認し、プラットフォーム契約とモデル料金をそれぞれ予算に組み込むことです。すでに使えるワークフローを明確な上限が妨げているときに初めて、アップグレードで具体的な便益を買うことになります。