家計診断AIを開発する過程で、Dify Sandbox の「月間3000リクエスト制限」に到達したことで、OpenAI APIを直接叩く方式への移行を検討することになりました。
その中で分かった、Dify と OpenAI API 直叩きのメリット・デメリットをまとめます。
Dify を使うメリット
✓ GUIで管理しやすい
モデル設定やプロンプト管理が視覚的で分かりやすい。
✓ すぐ動く
Webhook・ワークフロー・ナレッジなど、統合環境として優秀。
✓ チーム開発向け
権限管理・ログ・UIが揃っている。
Dify を使うデメリット（今回痛感したポイント）
✗ Sandboxは「月3000リクエスト」の制限
→ プロンプト調整中に簡単に到達してしまう。
✗ OpenAI APIの使用量とは無関係
→ OpenAI側は$3.62しか使っていないのに、Difyだけ停止する。
✗ 本番利用には有料プランが必須
→ 開発フェーズには少し重い。
OpenAI API を直接叩くメリット
✓ Sandbox制限がない
開発フェーズでプロンプト調整を何百回やっても止まらない。
✓ コストは必要な分だけ（今回 $3.62）
Dify経由のような“回数による停止”がない。
✓ WordPressのREST APIと相性が良い
fetch / PHP / serverless など自由度が高い。
✓ 本番環境で完全に制御できる
キャッシュ・再試行・プロンプト最適化も自由。
OpenAI API を直接叩くデメリット
✗ 自前で実装が必要
ログ・エラーハンドリング・認証などを自分で書く必要あり。
✗ UI統合が少し手間
Difyは最初からUIまで含むエコシステム。
FP向け家計診断では「直叩き」が最適解
今回のように、
- 同じプロンプトを何度も微調整
- マークダウンや表生成を頻繁に試す
- 開発フェーズの試行回数が多い
こういった用途では、OpenAI API直叩きの方が圧倒的に効率的です。
一方で、
- チーム全体でワークフローを共有したい
- 複雑なUI／Botを統合したい
という目的であれば、Difyの有料プランが適しています。
今後の予定：WordPress → OpenAI API のREST接続へ移行
次回は実際に、
**WordPress から OpenAI API を呼び出す最小コード（PHP）**を
ブログと本番サイトに実装していきます。
コメント