1. 背景 ―― “使ってないはずのGPT-4” から高額請求!?
先日、社内の OpenAI ダッシュボードを眺めていたところ、想定を大幅に上回る料金 が発生していることに気づきました。
「Dify のワークフローでは LLMノード を使っていないし、gpt-4 を指定した覚えもない。なぜ？」――疑問を抱き、急ぎエンジニアチームで調査を行いました。
2. 調査結果 ―― 会話タイトル自動生成で GPT-4 が動いていた
コードを追ったところ、Dify はワークフロー実行時に 会話タイトル（スレッド名）を内部で自動生成 していました。その際、リクエスト input を丸ごと gpt-4 に投げてタイトル案を作っていたのです。
| 観測ポイント | 内容 |
|---|---|
| 利用ノード | 「開始」＋「回答」ノードのみ（LLMノード未使用） |
| 請求対象モデル | gpt-4（会話タイトル生成に暗黙利用） |
| 料金インパクト | 入力トークン量 × GPT-4 単価（大量レビューを渡すほど高額） |
ポイント
- ワークフロー本体では GPT-4 を呼んでいなくても、メタデータ生成 で課金される
- 入力が巨大（レビュー数千件など）だと、そのまま GPT-4 料金に乗る
3. 影響範囲 ―― 大量データ入力時に課金が跳ね上がる
レビュー分析などで「レコード全部まとめて Dify に渡す」運用をしていると、トークン数が爆発的に増え、タイトル生成だけで数ドル〜数十ドル規模の追加コストが発生します。しかもブラックボックス的に内部呼び出しされるため、気づきにくい のが最大の落とし穴でした。
4. 即時対策 ―― 「設定」->「モデルプロバイダー」->「システムモデル設定」を変更
Dify の設定を確認したところ、タイトル生成用モデルのデフォルトが gpt-4 になっていたため、gpt-4.1-nano（または 3.5 系）に変更。
これでタイトル自動生成は軽量モデルに置き換わり、大幅にコストを抑えられます。
備考
- Dify のバージョンによっては環境変数
LLM_TITLE_MODELで上書き可- 変更後は 必ず 少量データでテストし、課金が抑えられているか確認する
5. これからの運用チェックリスト
- 内部呼び出しモデル をドキュメント・コードで明示する
- ワークフローに LLM 以外の隠れコスト がないか都度レビュー
- 大容量データ は可能な限り分割し、メタ生成用にはサマリのみ渡す
- OpenAI ダッシュボードで モデル別コスト内訳 を定期確認
- 新バージョン導入時は 小規模リクエストで試験運用 してから本番へ
6. まとめ ―― “設定デフォルト” の罠にご用心
今回の高額請求は、OpenAI ではなくDify 側のデフォルト設定が原因でした。 LLM を組み込んだ SaaS や OSS ツールでは、「意図しないモデル呼び出し」 が潜んでいることも多々あります。コスト管理のためには、
- 内部ロジックの透明性を担保 し
- 課金イベントを監視 し
- 軽量モデル／RAG／キャッシュ の活用でコスト最適化
を徹底しましょう。
「LLM ノードを使っていないから安全」ではなく、 “どのタイミングで、どのモデルが、どの入力を食っているか” を常に意識する―― これが高額請求を防ぐ最短ルートです。
7. おわりに
同じように Dify（や類似ツール）を活用しているチームの方は、ぜひ一度タイトル生成など非顕在部分での LLM 利用設定をチェックしてみてください。気づかないうちに、あなたのクレジットが溶けているかもしれません……！
引き続き、HALDATA Tech Blog では 実践的なLLM活用Tips と ハマりポイント を共有していきます。お楽しみに！
