Difyでチャットボットを作る時に考えるべきこと（コスト編）

お疲れ様です。tkmiです。

前回の設計編に続き、今回はDifyでチャットボットを構築する際に見落としやすい「コスト」について整理します。

はじめに

チャットボットの導入検討では、回答精度や使いやすさに注目が集まりがちですが、実運用ではコスト設計も非常に重要です。
特にOpenAI APIのような従量課金型のLLMを利用する場合、設計段階で呼び出し方を整理しておかないと、想定以上の費用が発生する可能性があります。

そのため、どこでLLMを使うのか、どのモデルを選ぶのか、どの程度の利用量を見込むのかを事前に考えておくことが大切です。本記事では、Difyでチャットボットを作る際に押さえておきたいコストの考え方を、実務目線で解説します。

今回は想定として、以下の３つのパターンで考えていきます。

1. Difyだけで済ませる（Dify Professional有料プラン）
   OpenAI APIキーは発行せず、Difyのプランについているクレジットを使用してOpenAIモデルを使用する
   
   
2. DifyをSandbox（無料）、OpenAI API PlatformのAPIキーを使う
   Difyのクレジットは消費しないので、Sandbox（無料）でもいい
   
   
3. DifyをProfessional（有料）、補助にOpenAI API PlatformのAPIキーを使う
   Dify Sandbox（無料）での制限を緩和するため、Professionalを契約。
   Difyのクレジットを優先的に利用し、OpenAI APIキーは5000クレジットを超えた場合に利用する。
   ※DifyのクレジットとOpenAI APIキーの設定は併用可能です。クレジットを優先設定しておき、APIキーを登録します。クレジットを使い切ったタイミングでは、リクエストが失敗する可能性があります。 切り替え時の挙動は設定や利用状況に左右されるため、実運用前に検証しておくのが安全です。 

※Professionalの場合、当月にクレジットを使い切った場合、次月にまた5000使えるようになります。

チャットボットでLLMを使う場所

まずは、チャットボットの中でLLMがどこに使われるのかを明確にする必要があります。これが曖昧なままだと、不要な箇所で高価なモデルを呼び出してしまい、コストが膨らみやすくなります。

一般的に、LLMが使われる主な場面は次のとおりです。

• 応答生成
• 意図判断（質問分類やルーティング）
• 要約・整形
• ナレッジ検索を補助する処理
• 埋め込み（Embedding）生成

たとえば、ユーザーからの質問に対して最終回答を作る場面では、ある程度性能の高いモデルが必要になることがあります。一方で、「FAQへの問い合わせか」「担当者へのエスカレーションが必要か」といった分類処理であれば、比較的軽量なモデルでも十分対応できるケースが少なくありません。

このように、どの処理でLLMを使うのかを細かく分解しておくことで、必要以上に高性能なモデルを使わずに済みます。

LLMを利用する主な場面

1. 質問分類
   入力されたメッセージがどのような質問かを分類する
2. 回答生成
   知識検索で取得した内容をもとに回答を生成する
   一般的には、この工程が最もコストを消費しやすい部分です。

知識検索（ナレッジベース）で発生するコスト

1. 検索時のコスト
   選んだインデックス方式によって異なります。高品質 では embedding や rerank の設定に応じてコストが発生し得ます。一方、経済的 はキーワードベースで、追加の token 消費を伴わない方式です。
   ※ なお、Difyクレジット上は回数としてカウントされないケースがあります。
2. ナレッジベース作成時のコスト
   ナレッジベースの作成時にもクレジットが消費されます。作成方法には、主に次の2種類があります。
   • 高品質
     埋め込みモデルを使用する方式です。登録時にクレジットが消費され、消費量は文章量に比例します。
   • 経済的
     キーワード検索ベースの方式です。クレジット消費はほとんどなく、軽微に収まります。

なぜコストを意識する必要があるか

OpenAI APIの料金は、基本的に従量課金です。つまり、使った分だけ費用が発生します。主に影響するのは次の2点です。

• 呼び出し回数
• 入出力トークン量

1回あたりの利用コストが小さく見えても、利用回数が増えると月額では無視できない水準になることがあります。特にチャットボットは、ユーザーとの対話が増えるほどリクエスト数も増えるため、設計次第で費用が大きく変動します。

たとえば、以下のような設計はコストが膨らみやすい傾向があります。

• すべての処理で高性能モデルを使う
• 毎回長いプロンプトを送る
• 必要のない要約や整形を何度も実行する
• 検索結果を過剰に投入して回答生成する
• 埋め込み対象の文章を無計画に大量登録する

「とりあえず精度重視で強いモデルを使う」という考え方は、検証段階では有効でも、本番運用ではコスト面の課題につながることがあります。設計段階で費用構造を把握しておくことが重要です。

OpenAI APIキーを利用する場合

OpenAIの利用料はチャージ設定により変動するため、暫定として$10とする。
Dify Professionalを契約する。
※2026年4月に算出しているので、現在既に以下の料金は更新されています。最新版はOpenAI API Platform公式をご確認ください。

▼OpenAI利用料
残高上限：10 $/月
チャージ上限：10 $/月

月$10前提：モデル別試算（例/FAQ + RAG）

 ※Sandbox では API 利用枠に制限があります。実際に処理できる件数は、Dify 側の利用制限と、1問い合わせあたりの内部処理回数の両方に左右されます。最新の上限値は Dify 公式料金ページで確認してください。 

Dify Professionalのみで完結する場合

モデルごとのクレジット使用量

※2026年4月に算出しているので、現在既に以下の表は更新されています。最新版はDify公式をご確認ください。

※トークン量に関係なく、1回のLLM呼び出しで消費されるクレジット

LLMモデルの選び方

LLMの選定では、精度だけでなくコストとのバランスを考える必要があります。一般に、軽量モデルは安価で高速、高性能モデルは精度が高い一方でコストも上がりやすい傾向があります。

考え方としては、次のように整理すると分かりやすくなります。

軽量モデルが向いているケース

• FAQのように回答パターンが比較的明確なもの
• 質問分類や意図判定
• 定型的な要約や整形
• 前処理やルーティング

高性能モデルが向いているケース

• 文脈理解が必要な複雑な問い合わせ
• 複数の情報を統合した説明
• 表現の自然さや説得力が重要な回答
• 判断ミスが業務影響につながるケース

たとえば、質問回答にClaude Sonnet相当の品質を想定する場合、OpenAI系であれば GPT-4.1 や GPT-5 が候補になります。一方で、多少性能が落ちてもコストを重視するのであれば、GPT-4.1-mini や GPT-5-mini といった軽量モデルも有力です。

重要なのは、「どの処理に、どのレベルの精度が必要か」を切り分けることです。すべてを同じモデルで処理するよりも、用途ごとにモデルを使い分けたほうが、費用対効果を高めやすくなります。

想定コストの考え方

コストを見積もる際は、感覚ではなく、できるだけ分解して考えることが大切です。基本的には次のような要素を確認します。

• 1リクエストあたりの入力トークン数
• 1リクエストあたりの出力トークン数
• 1日の利用回数
• 月間の想定利用回数
• 利用するモデル単価
• Embedding生成の量

たとえば、1回の質問で以下のような処理が走るとします。

1. 質問分類
2. ナレッジ検索
3. 回答生成
4. 回答整形

この場合、実質的には1問い合わせで複数回のLLM呼び出しが発生する可能性があります。見積もりでは「ユーザーの質問1回＝API1回」と単純化せず、内部で何回モデルを呼ぶのかまで含めて考える必要があります。

  トークン内訳（例）

コストを抑える設計

コストを最適化するには、単に安いモデルを選ぶだけでは不十分です。設計そのものを見直すことで、精度を保ちながら費用を抑えられる場合があります。

※Difyチュートリアル：知識ベースを使用したカスタマーサービスボットを元に作成したワークフロー例

1. 不要なLLM呼び出しを減らす

まず効果が大きいのは、不要な呼び出しをなくすことです。

たとえば、明らかに定型文で返せるケースまで毎回LLMで生成していると、無駄なコストが積み上がります。

• 固定回答でよい問い合わせはテンプレート化する
• 分類結果によってはLLMを使わずに処理する
• 再利用可能な処理はキャッシュを検討する

2. プロンプトを短くする

入力トークンが増えると、それだけ費用も増えやすくなります。必要以上に長い指示文や参照情報を毎回渡していないか確認しましょう。

• システムプロンプトを簡潔にする
• 検索結果を必要最小限に絞る
• 重複する説明を削除する

3. RAGで情報精度を高める

RAG（Retrieval-Augmented Generation）を使うことで、必要な情報だけを絞って回答生成に渡しやすくなります。これは精度向上だけでなく、無駄な生成を減らす意味でも有効です。

ただし、RAGにもコストはあります。検索対象となる文書を登録する際には、Embedding生成が必要になるため、登録文量が増えるほど初期コストや更新コストがかかります。

※Difyの知識ベースは標準でRAGを使用しています。

4. モデルを使い分ける

質問分類は軽量モデル、回答生成は用途に応じて上位モデル、というように処理ごとに最適なモデルを選ぶ設計が有効です。

一律で高性能モデルを採用するより、実運用ではこちらのほうが費用を抑えやすくなります。

実際に考えた構成

ここまでの内容を踏まえると、実際の構成は「どこでLLMを使うか」「どこでは使わないか」を整理することが重要です。

たとえば、次のような構成が考えられます。

質問分類

• gpt-4.1-mini

質問の種類を判定する用途であれば、比較的軽量なモデルでも十分なケースがあります。ここで高性能モデルを使うと、問い合わせ件数が増えたときにコストが積み上がりやすくなります。

回答生成

• gpt-4.1
• gpt-5-mini
• gpt-5

回答品質が重視される場面では、精度とコストのバランスを見ながら選定します。

高い品質が必要であればGPT-4.1やGPT-5を、コスト重視であればGPT-5-miniのような選択肢を検討するとよいでしょう。

その他

• ナレッジベース登録時に Embeddingモデル を利用

見落としやすいのが、ナレッジベース登録時のコストです。RAGの精度を高めるために文書を多く登録すると、その分だけEmbedding生成の費用がかかります。特に文章量が多い場合やチャンク数が増える場合は、初回登録や更新時のコストが想定以上になることがあります。

このように、回答生成だけでなく、分類・検索・埋め込みまで含めて全体のコスト構造を把握しておくことが大切です。

どのくらい生成できるか

公式情報ではありませんが、目安として以下のように仮定します。

Difyクレジットの場合、1チャンク≒1クレジット
OpenAIの場合、text-embedding-3-smallの想定で、$0.00002 / 1,000トークン

200チャンクを処理する場合

文章量（トークン数） × 埋め込み単価

※Dify Sandbox（無料）の200クレジットを利用する場合

同じ文字数をOpenAIで処理する場合

パターン比較

最初の①～③のパターンについて、想定コストとどのくらいチャットができるか？を表にまとめました。
Difyにはナレッジの呼び出し間隔（ナレッジレート）の制限もありますので、安定した利用が可能かどうかも考慮しています。

①と③については、ほとんど変わらないように見えますが、利用数の想定により選択が変わります。

Difyはクレジット枠を使い切った場合、LLMを利用できなくなります。
現時点（2026年）でDifyはクレジットを追加購入することができません。月の途中でクレジットを使い切った場合、上位プランへアップグレードすることでクレジット枠を増やすことができます。

そのため、質問数が多いと予想される場合は③を選択し、クレジット枠を使い切ったとしても利用できるようにOpenAI APIキーを併用する想定になっています。

ただし、OpenAI APIは残高チャージ型のサービスであり、オートチャージ機能を利用してリチャージできるためコスト管理が必要になります。

まとめ

Difyでチャットボットを構築する際は、精度や機能だけでなく、コストも設計段階から考える必要があります。

特に重要なのは、次の3点です。

• どこでLLMを使うのかを明確にする
• 処理ごとに適切なモデルを選ぶ
• 呼び出し回数とトークン量を前提に月額コストを見積もる

コストは、後から問題になるのではなく、最初の設計で大きく決まります。

言い換えると、チャットボット設計はそのままコスト設計でもあります。

実運用で無理のない構成にするためにも、まずは「必要なところに、必要なだけLLMを使う」という考え方から整理していくことをおすすめします。