まな先生解説
こころ質問
すい要点整理
結論：初心者がまずやるべき3つのこと
やるべきこと①：自分の出口を先に決める
横スクロールできます
やるべきこと②：APIキーの使用上限を先に設定する
やるべきこと③：公開範囲を決めてから作る
Difyとは何か？ChatGPTやGPTsと何が違う？
前提：日本ではまだ「使っている人」が少数派
補足
上の数値は2024年度調査に基づく2025年公表値です。生成AIの普及速度を考えると、現時点の実利用率はこれより高い可能性があります。
Difyを使うべきか？5問の診断チャート
5問の分岐チャート
各出口の判断理由・初月コスト・乗り換えシグナル
| 出口 | そう判断する理由 | 初月に出ていく金額 | 乗り換えシグナル |
|---|---|---|---|
| 【A】ChatGPT/GPTs・Claude Projects | 配布も自動化も不要なら、Difyの学習コストが純粋な損 | 0円（既存サブスク内） | 「あの人にも使わせて」と言われたら【B】へ |
| 【B】Dify Sandbox＋自前APIキー | 配布はしたいが機密は扱わない。無料枠で公開まで届く | $0＋API従量（数百〜数千円） | アプリ5個・ナレッジ50文書を超えたら【C】へ |
| 【C】Dify Professional | 複数人運用・トリガー常用はSandboxの枠を確実に超える | 年額$590（月額換算 約$49）＋API従量 | メンバー4人目、またはナレッジ500文書超で Team へ |
| 【D】セルフホスト（Community Edition） | データを自社管理下に置ける。Dify利用料は無料 | VPS費（月2,000〜5,000円程度）＋API従量 | 運用工数がProfessional代を上回ったらCloudへ戻す |
| 【E】Difyを使わない | 機密データを扱うのにDocker運用者がいない構成は事故が起きる | — | ローカルLLM導入か、構築の業務委託を検討 |
注意
【E】は上位記事がほぼ書かない「撤退基準」です。「機密を扱う × 誰もサーバーを見られない」でCloudに載せるのが、個人・中小事業者で最も起きやすい事故パターンです。Q2がYesでQ5がNoなら、Difyを使わない判断を先に検討してください。
Dify以外の選択肢との切り分け
- n8n / Zapier：SaaS間のデータ連携が主目的で、LLMは味付け程度 → n8n側が適任
- Microsoft Copilot Studio：Microsoft 365・Teamsに深く統合したい、既にMS基盤がある → Copilot Studio
- Dify：LLMの振る舞い（プロンプト・RAG・エージェント）そのものを作り込みたい → Dify
- LangChain等のコード実装：エンジニアがいて、細かい制御が要る → コードで書いた方が速い
Difyの料金はいくら？月額の計算式と3ケース試算
計算式と前提の置き方
プラン別のプラットフォーム費（Dify公式料金ページ 2026より）
| プラン | 料金 | メッセージクレジット | アプリ数 | メンバー | ナレッジ文書 | ベクトルストレージ |
|---|---|---|---|---|---|---|
| Sandbox | $0 | 200（通算枠・月次リセットなし） | 5 | 1人 | 50件 | 50MB |
| Professional | 年額$590（月額換算 約$49） | 5,000/月 | 50 | 3人 | 500件 | 5GB |
| Team | 年額$1,590（月額換算 約$133） | 10,000/月 | 200 | 50人 | 1,000件 | 20GB |
| Community Edition（セルフホスト） | 無料 | —（自前APIキー） | 制限なし | 制限なし | インフラ次第 | インフラ次第 |
二層構造の要点：クレジットとAPI課金は別レイヤー
- Difyのクレジットを使う：Difyのプラン枠を消費する。API側の請求は発生しない
- 自前APIキーを使う：Difyのクレジットは減らない。代わりにOpenAI等から直接請求される
- 両者は併用可能で、優先順位も設定できる
3ケース×3構成の試算表
| 利用シナリオ | (A) Sandbox＋自前APIキー | (B) Professional | (C) VPSセルフホスト |
|---|---|---|---|
| (1) 社内5人が1日10回＝月1,000メッセージ | プラットフォーム$0＋API従量。ただしメンバー1人制限に抵触し5人運用は不可 | $49/月＋（クレジット5,000内なら追加API費なし、自前キーならAPI従量） | VPS費＋API従量。メンバー制限なし |
| (2) 顧客向け公開ボット 月5,000メッセージ | $0＋API従量。公開URLのアクセス制御が必須 | $49/月＋クレジット5,000でほぼ収まる規模 | VPS費＋API従量。スパイク時のスケールは自己責任 |
| (3) トリガーで夜間バッチ 月3,000実行 | トリガー常用はクレジット/枠管理が前提。個人検証向き | $49/月＋従量。定期実行の主戦場 | VPS費＋API従量。cron的運用と相性が良い |
- 使うモデルの公式価格ページで、入力単価・出力単価（1Mトークンあたり）を確認する
- `月間メッセージ数 × 1,500トークン ÷ 1,000,000 × 入力単価` を計算する
- `月間メッセージ数 × 500トークン ÷ 1,000,000 × 出力単価` を計算する
- 2と3を足し、プラットフォーム費とインフラ費を加える
注意
LLMの単価は各社が随時改定します。ここに固定値を書くとすぐ嘘になるため、必ず利用するモデルの公式価格ページで当日の単価を確認してください。概算を出すなら、まず1週間の実測メッセージ数を取ってから月換算するのが最も外れません。
具体的な使い方：最短で「公開できる状態」まで
手順1〜5：作成から公開まで
- Dify Cloudにサインアップし、ワークスペースを作る（GoogleまたはGitHubアカウントで開始できます）
- 設定 → モデルプロバイダーで、自前のAPIキーを登録する（先にここをやる。後回しにするとクレジット200をデバッグで溶かします）
- アプリを作成する（チャットボット／テキストジェネレーター／エージェント／ワークフロー・チャットフローから選択）
- プロンプトを書き、プレビューでデバッグする（この段階ではまだ公開しない）
- 公開設定でアクセス範囲を決めてから公開する
配布方法は4系統、被害範囲が違う
| 配布方法 | 用途 | 漏れたときに起きること |
|---|---|---|
| Webアプリ（URL共有） | 社内・顧客に手早く配る | URLを知る全員が使える。トークンが消費される |
| API連携 | 自社システムに組み込む | APIキー漏洩で外部から任意に呼ばれる |
| サイト埋め込み | 自社サイトにチャット窓を設置 | 埋め込み先ドメイン外からも叩かれ得る |
| MCPサーバー公開 | Claude Desktop・Cursorから使う | URLに認証資格情報が含まれる |
RAG（ナレッジ）の精度が出ないときの直し方
- インデックスが完了していない：アップロード直後は検索対象になりません。ナレッジ画面で処理完了を待ちます
- top_kが小さすぎる／大きすぎる：小さいと必要な断片が拾えず、大きいと入力トークンが膨張してコストが上がります。まず3〜5で試し、外すなら増やします
- PDFの表が崩れている：表組みPDFはテキスト抽出で列が壊れます。表はCSVやMarkdownにテキスト化してから投入するのが確実です
- チャンクの切れ目が悪い：見出し単位で切れていないと文脈が途切れます。区切り文字とチャンクサイズを見直します
補足
「LLMが悪い」と判断する前に、まずナレッジ側を疑ってください。RAGの精度問題の大半は、モデルではなく前処理と検索設定が原因です。
公開ボタンを押す前の15項目チェックリスト
アクセス制御（4項目）
| # | 確認項目 | 確認箇所 | 未対応だと何が起きるか |
|---|---|---|---|
| 1 | □ 公開URLにアクセス制御を設定したか | アプリ → 公開 → Webアプリ設定 | URLを知る全員が使え、自分のAPIキーのトークンが第三者に消費される |
| 2 | □ 埋め込み先のドメインを限定したか | アプリ → 公開 → サイト埋め込み | 想定外のサイトから呼ばれる |
| 3 | □ MCPサーバーURLを共有した相手を把握しているか | アプリ → 公開 → MCPサーバー | URLに認証資格情報が含まれるため、漏洩＝アクセス権の譲渡になる |
| 4 | □ 漏洩時にURL／キーを再生成する手順を確認したか | 各公開設定画面 | 漏れた後に止める手段がなく、公開停止しか選べない |
課金の上限（3項目）
| # | 確認項目 | 確認箇所 | 未対応だと何が起きるか |
|---|---|---|---|
| 5 | □ OpenAI等の管理画面で月次使用上限（ハードリミット）を設定したか | 各プロバイダーの請求設定 | 暴走時の請求上限が青天井になる |
| 6 | □ 自前APIキーとDifyクレジットの優先順位を把握したか | 設定 → モデルプロバイダー | どちらが減っているか分からないまま課金が進む |
| 7 | □ 想定外の使われ方（連投・長文投入）の上限を決めたか | アプリ設定・プロンプト設計 | 1回あたりのトークン量が跳ね、単価想定が崩れる |
データの中身（4項目）
| # | 確認項目 | 確認箇所 | 未対応だと何が起きるか |
|---|---|---|---|
| 8 | □ ナレッジに入れてはいけない情報（顧客氏名・契約書・カード情報）を除外したか | ナレッジ → 文書一覧 | 回答経由で第三者に機密が出る |
| 9 | □ プロンプトに機密情報を直書きしていないか | アプリ → プロンプト | プロンプトインジェクションで抜かれ得る |
| 10 | □ ログ保持期間とプランの上限を把握したか | ワークスペース設定・プラン内容 | 入力内容が想定より長く残る／必要なログが消える |
| 11 | □ 利用者に「入力しないでください」と明示したか | アプリの説明文・開始メッセージ | 利用者が個人情報を入力してしまう |
セルフホストとライセンス（4項目）
| # | 確認項目 | 確認箇所 | 未対応だと何が起きるか |
|---|---|---|---|
| 12 | □ SECRET_KEYを既定値から変更し、v1.14.2以降に更新したか | .env／docker compose設定 | テナント分離の既知の修正が未適用のまま運用される |
| 13 | □ バージョンを固定し、検証環境で先に上げる運用にしたか | docker-compose.yml のタグ指定 | 1.15／1.16でUIと機能が変わり、手順書が陳腐化する |
| 14 | □ クライアント提供がマルチテナント提供になっていないか | 提供形態の設計 | ライセンス追加条件に抵触する |
| 15 | □ フロントエンドのロゴ・著作権表示を消していないか | 公開画面 | 同じくライセンス追加条件に抵触する |
注意
やめるときの撤収手順も先に書き出してください。公開停止 → APIキー失効 → ナレッジ削除 → アカウント削除の順です。「使わなくなったが公開したまま」が、最も静かにトークンを溶かす状態です。
セルフホストの前に確認すべきことは？
動作要件とデプロイ手順
セキュリティ更新は必須
商用利用時のライセンス制約
- 書面による許可なきマルチテナント提供の禁止
- フロントエンドUI利用時のロゴ・著作権情報の削除／変更の禁止
注意
「Difyで作ったボットを月額で複数社に提供する」というビジネスモデルは、構成によってはマルチテナント提供に該当します。事業として始める前に、ライセンス条項の原文（GitHubのLICENSE）を確認してください。
専門家・公的情報の見解：Difyの信頼性はどう判断する？
認証取得とTrust Center
セキュリティ情報（認証状況・サブプロセッサ一覧等）は、公式のTrust Center（https://security.dify.ai/）で公開されています。どのサブプロセッサにデータが渡るかを確認したい場合は、まずここを見てください。
運営主体と国内導入実績
中小企業のAI導入という文脈
バージョン追従はどうする？手順記事が動かない理由
直近1年で何が変わったか
| 時期 | 変更内容 |
|---|---|
| 2025年11月 | 新基盤「トリガー（Trigger）」正式リリース。スケジュールや外部イベント起点でワークフローを自動起動できるようになり、手動実行／API呼び出し依存から脱却 |
| 2026年5月 | v1.14.1／v1.14.2でセルフホストのセキュリティ修正（SECRET_KEYハードニング、テナント分離等） |
| 2026年6月 | v1.15.0でCLIクライアント`difyctl`、Chain-of-Thought（思考過程）可視化、Human-in-the-Loopフォーム強化（ドロップダウン・ファイルアップロード対応）、ランディング／オンボーディング刷新 |
| 2026年7月17日 | v1.16.0で「Dify Agent（Beta）」搭載。Linuxサンドボックス上でシェルコマンドやファイル操作を実行可能に |
Dify Agent（Beta）の注意点
追従方針の実務ルール
- 手順の一次情報は公式日本語ドキュメント（docs.dify.ai/ja/）を見る（2026年6月時点でワークフロー入門レッスンが整備されています）
- ブログ記事は「考え方」を読み、画面操作は公式で確認する
- セルフホストはイメージのバージョンタグを固定する（`latest`運用は事故のもと）
- セキュリティ修正リリースだけは速やかに適用する（機能追加とは扱いを分ける）
やってはいけないNG対応
NG①：テスト中に公開URLを共有する
NG②：APIキーの上限を設定しないまま運用する
NG③：機密文書をとりあえずナレッジに入れる
NG④：古い記事の手順を鵜呑みにする
NG⑤：ライセンス条項を読まずに商用提供を始める
注意
上記5つのうち、①②は「知らなかった」では済まない金額になり得ます。公開前チェックリストの1番と5番に対応しているので、そこだけは必ず確認してください。
