Dify とは
Difyは、LLMアプリケーションを構築するためのオープンソースのプラットフォームです。ビジュアルなワークフローキャンバス、取り込みから検索までのRAGパイプライン、マーケットプレイス、MCPサーバー、カスタムAPIのツールを使えるエージェント、プロンプトIDE、バックエンド・アズ・ア・サービスのAPI、Langfuse、Opik、Arize Phoenixなどのオブザーバビリティツールとの連携を提供します。Dify Cloudを利用するか、Docker ComposeでCommunity Editionをセルフホストするか、SSO、RBAC、サポートSLAを追加するDify Enterpriseについて問い合わせることができます。CodeノードはサンドボックスでPythonまたはJavaScriptを実行し、Human Inputノードはワークフローを一時停止して、人間の応答を待ちます。
アプリビルダーとガバナンスの効いたエージェントプラットフォーム
DifyとEDDIはRAG、ツール、エージェントの面で重なりますが、最適化している対象の人が異なります。Difyは、アプリケーションをビジュアルに組み立てて素早く出荷したいビルダーに向けて最適化されており、コードノードが逃げ道になります。EDDIは、エージェントの挙動を、ガバナンスに囲まれた宣言的でレビュー可能な設定にする必要があるオペレーターに向けて最適化されています。多くのチームがDifyから始めるのは妥当であり、テナンシー、ライセンス、監査の要件が出てきた段階で移行するチームもあります。
ビルダーの利便性と運用面
| 観点 | Dify | EDDI |
|---|---|---|
| 主要な抽象化 | ビジュアルなワークフローおよびチャットフローのキャンバスと、プロンプトIDE | Config-as-Code：ManagerまたはAPIで作成するJSONリソース。ソースコードのようにバージョン管理 |
| ライセンス | Dify Open Source License：Apache 2.0に条件を追加したもの。ソースをマルチテナントで運用するには書面による許可が必要で、フロントエンドのロゴと著作権表示を残す必要がある | Apache 2.0（OSI承認） |
| カスタムロジック | Codeノードは、ファイルシステム、外向きのネットワーク、システムコマンドをブロックし、パッケージが固定されたサンドボックスでPythonまたはJavaScriptを実行 | 実行時のコード評価はない。ロジックは宣言するか、MCPツールやHTTP呼び出しの先に置く |
| ヒューマン・イン・ザ・ループ | Human Inputノードはワークフローを一時停止し、Webアプリまたはメールで回答するフォームを提示。デフォルトの待機は3日間で、その後タイムアウト分岐 | ターン、ツール呼び出し、グループのフェーズにゲート。タイムアウトポリシーはWAIT_INDEFINITELY、AUTO_APPROVE、AUTO_REJECT、ABORT。ManagerとSlackでの承認 |
| ツールと連携 | マーケットプレイス、MCPサーバー、カスタムAPI | 84のMCPツール、MCPクライアント、OpenAPIインポート、httpCall、A2A |
| RAG | ドキュメント抽出を備えた組み込みのナレッジパイプライン | 8の埋め込みプロバイダー、6のベクトルストア、およびインフラ不要のhttpCall RAG |
| マルチエージェント | エージェントとワークフローのノードをキャンバス上で組み合わせる | 7つのスタイルのグループディスカッション。決定事項と反対意見を記録し、フェーズごとに任意で人間の承認 |
| IDとアクセス | ワークスペース。SSOとRBACはDify Enterpriseで提供 | オープンソース版で、オプションのKeycloak/OIDCと、eddi-adminおよびeddi-approverロール |
| オブザーバビリティと監査 | ログとモニタリング、Langfuse、Opik、Arize Phoenixとの連携 | Prometheusメトリクスに加え、HMAC署名付き、追記専用、連番検証付きの監査台帳 |
| デプロイ | Dify Cloud、Docker Compose、Enterpriseは要問い合わせ | Docker、Helm、Kustomize、OpenShift（Red Hat認定イメージ、OperatorHub経由のOperator） |
他ツールに関する内容は、2026年10月時点の公式ドキュメントとリポジトリで確認しています。これらのプロジェクトは変化が速いため、判断する前にベンダーに最新の挙動をご確認ください。
選び方
Dify が適している場面
- 非エンジニアが読んで拡張でき、構築中にすぐフィードバックを得られるビジュアルキャンバスが欲しい場合。
- プラグインマーケットプレイスと既成のワークフローテンプレートが、連携にかかる時間を実際に節約してくれる場合。
- ホスト型の選択肢（Dify Cloud）が欲しく、自分では何も運用したくない場合。
- Codeノードが欲しい機能である場合：ワークフロー内でPythonまたはJavaScriptによる小さなデータ変換を行いたい。
- 自チーム向けに社内で1つのデプロイを運用しており、マルチテナントというライセンス条件が該当しない場合。
EDDIが適している場面
- 法務チームが、1つのデプロイから多数のテナントや顧客にサービスを提供する場合も含めて、素のApache 2.0ライセンスを必要とする場合。
- セキュリティレビューが、サンドボックス化されているかどうかにかかわらず、自動化プラットフォーム内でのコード実行を禁じている場合。
- 特定のツール呼び出しやグループのフェーズに人間の判断が必要で、署名付き台帳に記録する場合。
- エージェントの挙動を、設定としてバージョン管理し、差分を確認し、環境間で昇格する必要がある場合。
- Kubernetes、OpenShift、またはローカルモデルを使ったエアギャップ環境でのデプロイが必要な場合。
Dify からのアプリの移行
Difyのアプリはビジュアルなグラフで、EDDIのエージェントは設定であるため、インポートではなく変換になります。最も検討が必要なのはCodeノードで、これは設定または宣言したツールに置き換わります。
| Dify | EDDI |
|---|---|
| チャットフローまたはワークフロー | EDDIエージェント：パイプラインとBehavior Rules |
| LLMノードとプロンプト | システムメッセージと、バージョン管理されたプロンプトスニペットを持つLLMタスク |
| ナレッジベース | 埋め込みプロバイダーとベクトルストアを持つEDDIのRAGナレッジベース |
| ツール、プラグイン、またはMCPサーバー | MCPクライアント接続、httpCall、またはOpenAPIからインポートしたAPI |
| Code node | Behavior Rulesとプロンプトのロジック。実際のコードが必要ならMCPツール |
| Human Input node | PAUSE_CONVERSATIONルールまたはtoolApprovals。タイムアウトポリシー付き |
| プロバイダーのAPIキー | Secrets Vaultのエントリ。${vault:key}として参照 |
よくある質問
Difyはオープンソースですか？
Difyはソースを、Apache 2.0に追加条件を加えたDify Open Source Licenseの下で公開しています。書面による許可なくソースを使ってマルチテナント環境を運用することはできず、フロントエンドからロゴや著作権情報を削除することもできません。これはEDDIが採用している素のApache 2.0ではないため、どちらかの条件が該当しうる場合は、法務チームと一緒にお読みください。
EDDIにはDifyのようなビジュアルビルダーがありますか？
EDDI Managerは、エージェントの構築、デプロイ、監視のための本番品質のReact UIで、11言語に対応しています。ノードキャンバスではなく管理インターフェースです。エージェント、プロンプト、ツール、パイプラインを設定し、すべての変更は図ではなくバージョン管理されたリソースになります。
EDDIがコードノードを避けるのはなぜですか？
サンドボックス化されたコードノードは妥当な機能であり、Difyもアクセスできる範囲を制限しています。しかし、プラットフォーム内でのあらゆるコード実行は、セキュリティレビューで検討すべき攻撃対象領域です。EDDIはエージェントの挙動を宣言的に保つため、ツールにできることは、宣言して承認したことだけになります。
DifyとEDDIを併用できますか？
はい。DifyはMCPサーバーとカスタムAPIを利用でき、EDDIはMCPサーバーとREST APIを公開しているため、DifyのワークフローからEDDIのエージェントを、ガバナンスの効いたステップとして呼び出せます。EDDIはhttpCall経由でDify APIを呼び出せます。