Difyのようなノーコードツールで最も価値があるのは、開発を発注する前に「その業務にAIを入れる意味があるか」を自社で試せることです。 作ってみたら使われなかった、という失敗を、開発を発注する前の小さな費用で確認できます。この記事では、Difyの公式ドキュメントと個人情報保護委員会の注意喚起を根拠に、向く業務・限界・クラウド版とセルフホストの選び分け・開発に切り替える分岐点を、発注や稟議を判断する担当者の目線で整理します。
Difyとは何か
Difyの公式ドキュメントは、Difyを「AIアプリケーションを構築するためのオープンソースプラットフォーム」と定義しています。自分のデータを活用するエージェント、ワークフロー、チャットボットを作り、Webアプリとして公開したりAPIで他のシステムと連携したりできます(出典1)。開発元はLangGenius, Inc.です。
利用方法は2つあります。提供元が運用するDify Cloudと、自社のインフラで動かすセルフホスト(Community Edition)です。公式ドキュメントでは、Dify Cloudにはインストール不要で無料のSandboxプランがあること、セルフホストはDocker Composeで立ち上げられることが案内されています(出典1)。
画面上で処理の流れを組み立てるため、プログラムを書かずに動くものを作れます。 ただし「オープンソース」の中身には注意点があります。GitHubで公開されているライセンスは、Apache License 2.0を基にしつつ追加条件が付いたものです。具体的には、Difyから書面の許諾を得ずにマルチテナント環境(1テナント=1ワークスペース)を運営することはできず、Difyのフロントエンドを使う場合はコンソールやアプリ内のロゴ・著作権表示を削除・変更できません(出典3)。社内利用ではほぼ問題になりませんが、Difyを土台に顧客向けのサービスを作る構想がある場合は、この条件を先に確認してください。
費用は3階建て
「Difyは無料」という理解のまま稟議を書くと、月額の見積りを誤ります。費用は次の3層に分けて考えてください。
| 階層 | 内容 | クラウド版 | セルフホスト |
|---|---|---|---|
| 1階:Difyの利用料 | プラットフォームの使用料 | 無料のSandboxプランから有料プランまで | ソフトウェア自体は無償 |
| 2階:LLMのAPI利用料 | ChatGPT・Claude・GeminiなどのAPIを使った分の従量課金 | 別途発生 | 別途発生 |
| 3階:運用の費用 | 参照文書の更新・精度の確認・障害対応にかかる時間 | 担当者の時間 | 担当者の時間+サーバー費+更新・監視 |
Dify自体が無料でも、AIの利用料は別に発生します。 問い合わせ対応のように処理件数が多い用途では、2階のほうが1階より金額として大きくなります。API利用料の計算方法はAI開発のAPI利用料|月額の見積り方にまとめています。
3階を見落とす稟議も多くあります。セルフホストの場合、公式ドキュメントはCPU2コア以上・メモリ4GiB以上を最小要件とし、Docker Compose 2.24.0以上で、コアサービス7つ・依存コンポーネント8つ・初期化タスク1つのコンテナを起動する構成を示しています(出典2)。立ち上げは短時間でも、バージョンアップのたびに設定ファイルの差分を確認し、コンテナを更新する作業が続きます。その担当を誰が持つかまで含めて費用です。
向く業務
1. 社内文書を参照する問い合わせ対応
社内マニュアルや規程を読み込ませ、質問に答えさせる用途です。Difyの「ナレッジ」機能はRAG(検索拡張生成)の仕組みで、質問に関連する箇所を登録済みの文書から検索し、それを文脈としてLLMに渡して回答を作ります。この構成は一般的で、Difyで到達できる範囲に収まることが多くあります。 社内向けの問い合わせ窓口、営業資料の検索、規程の照会などがこの型です。
2. 定型の文書生成
議事録の整形、報告書の下書き、問い合わせへの一次回答の下書きなど、入力と出力の形が決まっている処理です。人が最終確認して送る前提なら、精度が完全でなくても業務に乗ります。後述する物流会社の例がこの型です。
3. 発注前の検証
最も価値が出る用途です。 「この業務にAIを入れる意味があるか」を、開発を発注する前に自分たちで確認できます。数日で試せるものに、数十万円かけて開発を発注する必要はありません。試した結果「使われない」と分かることも、十分な成果です。 使われない理由が「精度」なのか「業務の流れに合わない」のかが分かれば、開発に進む場合の要件がそのまま手に入ります。
限界が出るところ
| 要件 | Difyでの扱い | 開発に移る目安 |
|---|---|---|
| 既存の業務システムの値を見て答える | 連携先にAPIがあれば接続を試せる。なければ難しい | 配送状況・在庫・受注などの「いまの値」を答えさせたい |
| 独自の判断ロジックを細かく組む | 画面上の分岐で表現できる範囲に限界がある | 分岐が10通りを超え、画面で追えなくなった |
| 大量の同時アクセスをさばく | 運用設計が別途必要 | 全社・社外に公開して利用者が増えた |
| 既存の社内システムに画面を埋め込む | APIで連携する形になる | 業務システムの画面から離れずに使わせたい |
| 権限を既存システムと揃える | 個別の設計が必要 | 部門ごとに見せる文書を厳密に分けたい |
「既存システムとの連携」で限界に当たるケースが最も多くなります。 文書に書いてあることを答えるのと、システムの中にある「いまの値」を答えるのは、必要な仕組みがまったく別です。後者の要件が出た時点で、開発の検討に移ります。
クラウド版とセルフホストの選び分け
| 比較項目 | クラウド版(Dify Cloud) | セルフホスト(Community Edition) |
|---|---|---|
| 立ち上げ | アカウント登録ですぐ使える | サーバーの用意とDocker環境の構築が必要 |
| データの所在 | 提供元の環境 | 自社が指定した環境 |
| 最小要件 | なし | CPU2コア以上・メモリ4GiB以上(公式ドキュメント) |
| 運用の手間 | 少ない | バージョンアップ・監視・バックアップの担当が必要 |
| 向くケース | 早く試したい・データの所在に制約がない | 社内規程でデータの所在に制約がある |
セルフホストを選ぶのは、データの所在に制約がある場合です。 「なんとなく自社サーバーのほうが安心」で選ぶと、運用の担当を置く必要が出てきます。注意したいのは、セルフホストにしてもLLMのAPIは外部の提供事業者を使うのが一般的で、入力した文章はその事業者に送られる点です。データを完全に社内で閉じるには、LLM自体を社内で動かす構成が必要になり、それは別の規模の話になります。
個人情報を入力するときの確認事項
問い合わせメールや顧客名簿を扱う用途では、個人情報保護委員会が2023年6月2日に公表した「生成AIサービスの利用に関する注意喚起等」が判断の基準になります。個人情報取扱事業者に対する注意点は2つです(出典4)。
- 個人情報を含むプロンプトを入力する場合、特定された利用目的を達成するために必要な範囲内であることを十分に確認する
- 本人の同意なく個人データを含むプロンプトを入力し、その個人データが応答結果の出力以外の目的で取り扱われる場合、個人情報保護法に違反する可能性がある。そのため、提供事業者が当該データを機械学習に利用しないこと等を十分に確認する
同じ文書は一般の利用者向けにも、応答結果に不正確な内容が含まれることがあると注意しています。Difyで組む場合、確認すべき「提供事業者」は2つあります。Dify Cloudを使うならDifyの提供元、そしてどちらの方式でも接続先のLLM提供事業者です。利用規約で学習利用の有無を確認し、確認できない場合は氏名・住所・電話番号をマスキングしてから入力する処理を、ワークフローの最初に置いてください。 この整理はAI開発のセキュリティでも扱っています。
例:物流会社の営業事務部門で配送問い合わせメールの一次返信下書きを作る
物流会社の営業事務には、取引先から「この荷物はいつ届くか」「再配達を依頼したい」「納品書を再発行してほしい」「集荷の時間を変えたい」といったメールが日々届きます。1件ごとの返信は数分でも、件数が積み上がると午前中がメール対応で終わる、という部門は少なくありません。この業務をDifyで試す場合、次のように組みます。
まず、受信メールの本文を入力として、問い合わせの種類を分類します。次に、配送約款・営業所一覧・再配達の受付手順・納品書再発行の手順といった社内文書をナレッジに登録し、分類結果に応じて該当箇所を検索させます。その内容を基に、自社の文面ルール(宛名の書き方、署名、使わない表現)を指示したLLMノードで返信の下書きを生成します。下書きは担当者が読んで修正し、送信は人が行う運用にします。 送信まで自動化しないのは、誤った案内が取引先に直接届く事故を避けるためです。
ここで、Difyで到達できる範囲と限界がはっきり分かれます。「再配達の受付方法」「納品書の再発行手順」のように、文書に書いてあることを答える問い合わせは、この構成で下書きが作れます。一方「この伝票番号の荷物はいまどこにあるか」は、配送管理システムの中にある値を見なければ答えられません。配送管理システムにAPIがあればDifyから接続を試せますが、ない場合や、伝票番号の照合に取引先ごとの例外処理が入る場合は、開発の検討に移る分岐点です。
個人情報の扱いにも注意が要ります。問い合わせメールには荷受人の氏名・住所・電話番号が含まれます。前述の個人情報保護委員会の注意喚起に沿い、接続先のLLM提供事業者が入力データを学習に使わない設定になっているかを確認し、確認できるまではマスキングしてから入力する処理を最初のノードに置きます。
判断の仕方も先に決めます。試用期間を1ヶ月とし、下書きを「そのまま送れた」「軽い修正で送れた」「作り直した」の3段階で担当者が記録します。そのまま送れた割合と軽い修正で済んだ割合の合計が、部門で決めた水準を超えれば継続、超えなければ対象の問い合わせ種類を絞って再試行するか、開発に進むかを判断します。この記録は、開発に進んだときの検収基準としてそのまま使えます。試用の1ヶ月で得られる最大の成果は、下書きの精度ではなく「どの問い合わせにAIが効き、どこで止まるか」の記録です。
導入前に決めておくこと
| 手順 | 決めること | 決める人 | 期限 |
|---|---|---|---|
| 1 | 対象業務を1つに絞る(例:配送問い合わせの一次返信) | 部門長 | 着手前 |
| 2 | 参照させる文書と、その更新担当 | 業務担当者 | 着手前 |
| 3 | 誰が使えるようにするか(部門内か全社か) | 部門長・情報システム担当 | 着手前 |
| 4 | 個人情報の扱い(学習利用の確認・マスキングの要否) | 情報システム担当・法務 | 着手前 |
| 5 | 精度が落ちたとき・エラー時の対応担当 | 業務担当者 | 試用開始時 |
| 6 | 試用の期間と、継続・中止・開発移行の判断基準 | 部門長 | 試用開始時 |
6番を決めておかないと、試したまま放置されます。 「1ヶ月使ってみて、下書きの採用率が部門で決めた水準を超えていたら継続」といった基準を先に置いてください。放置されたツールは、次にAI導入を提案するときの反対材料になります。
開発に切り替える分岐点
次のいずれかに当てはまったら、開発を検討する段階です。
- 既存システムの「いまの値」を見て答えさせたい
- 処理の分岐が複雑になり、画面上で管理しきれない
- 利用者が増え、権限を細かく分ける必要が出た
- 出力の形式を業務システムに合わせて厳密に制御したい
- 送信・登録・発注といった「実行」まで自動化したい
この段階で、Difyで作ったものが無駄になるわけではありません。 どんな質問が来るか、どこで間違えるか、どの文書が参照されたかのデータが残っており、それが開発時の要件と検収基準になります。内製と外注の分かれ目はAI開発は内製か外注かに、開発を発注する場合の流れはAI受託開発の進め方にまとめています。
商談で聞かれる質問
Q1. 実際にどんな事例がありますか
顧客名を出せる事例はお約束できませんが、当社自身の実例はお見せしています。当社は500ページ超の自社サイトをAIで開発・運用し、記事の自動公開パイプラインとサイト上のAIチャットも自社で作って動かしています。これらはノーコードツールではなくコードで組んだものです。理由は、公開の判定・ビルド・検索エンジンへの通知といった複数のシステムをまたぐ処理と、細かい例外処理が必要だったからで、前節の「開発に切り替える分岐点」に当たる案件でした。逆に、文書を参照して答えるだけの構成なら、当社でもまずノーコードで試すことをおすすめします。
Q2. どこまでを御社がやり、どこからが自社の作業ですか
Difyで試す段階では、初回30分の無料相談で対象業務の絞り込みまでを整理します。ナレッジに入れる文書の整理・ワークフローの初期設計・判断基準の設定まで伴走をご希望の場合は、AI開発顧問(300,000円/月・税抜・最低3ヶ月)の範囲で支援します。日々の試用と記録は貴社の業務担当者が行います。ノーコードの利点は現場が自分で直せることなので、当社が全部作ってしまうと利点が消えます。開発に移る段階では、要件整理・実装・実データでのテスト・納品後の動作フォローを当社が担い、貴社には業務の判断基準に答えられる担当者を1名置いていただきます。
Q3. 導入後の運用は誰がやりますか
試用で終わらずに使い続けるには、参照文書の更新、回答の精度の定期確認、LLM側のモデル変更への追随、エラー時の一次対応の4つを回す必要があります。社内で担当を置ける場合は、その方に運用手順を引き渡します。置きにくい場合は、AI開発顧問(300,000円/月・税抜・最低3ヶ月、以降1ヶ月単位)として、月次で精度の確認と改善を外から支える形をご用意しています。
当社の関わり方と費用
| 状況 | ご提案 |
|---|---|
| まだ試していない | まずノーコードで試すことをおすすめします |
| 試して手応えがあった | その結果を要件として開発をご提案します |
| 試して使われなかった | 対象業務の選び直しからご一緒します |
| 最初から連携要件がある | 開発をご提案します |
| プラン | 料金 | 初期費用・契約条件 | 含まれるもの |
|---|---|---|---|
| 業務自動化ミニ開発 | ¥300,000〜(税抜・単発) | — | 1業務の自動化ツールを設計・開発/例: 見積書生成・日報集計・レポート自動作成/要件整理から納品まで2〜4週間/納品後1ヶ月の動作フォロー付き |
| AI組込み開発おすすめ | ¥800,000〜(税抜・要件見積) | — | 社内チャットボット・RAG(社内ナレッジAI)/Claude・GPT・Gemini API統合/業務アプリ・ダッシュボード開発/開発期間1〜3ヶ月・保守プランは別途 |
| AI開発顧問 | ¥300,000/ 月(税抜) | 契約期間 最低3ヶ月(以降1ヶ月単位) 最低期間の総額 ¥900,000(¥300,000×3ヶ月) | Claude Code環境構築・開発伴走/社内メンバーの内製化支援/月次の開発ロードマップ設計/チャット相談・コードレビュー |
ノーコードで足りる場合は、その旨をお伝えします。 配送問い合わせの一次返信のような1業務であれば、業務自動化ミニ開発(300,000円〜・税抜・単発)で連携部分だけを作り、下書き生成はDifyのまま残す組み合わせも選べます。
初回30分の相談は無料・オンライン対応・秘密厳守です。Difyで試した画面や記録をお見せいただければ、開発に進むべきかどうかをその場で整理します。
まとめ
- 最大の価値は「開発を発注する前に必要かを試せること」。使われないと分かるのも成果
- 費用は「Difyの利用料+LLMのAPI利用料+運用の費用」の3階建て
- 向くのは社内文書の参照・定型の文書生成・発注前の検証
- 限界に当たるのは主に「既存システムのいまの値を見て答える」要件
- 個人情報を入力するなら、利用目的の範囲と学習利用の有無を先に確認する
- 試用の期限と判断基準を先に決める。決めないと放置される
あわせて読みたい
- 社内AI(RAG)構築の費用と手順|ナレッジAI導入の発注ガイド2026
- AI開発のAPI利用料|月額の見積り方
- AIチャットボット|既製品と自社開発
- 問い合わせ対応のAI自動化開発|一次回答ボットと有人エスカレーション設計
- 営業事務のAI自動化開発|見積書・受発注・顧客リスト整備を仕組み化する費用
- AI開発の記事一覧
出典
- Dify ドキュメント(Dify Docs・日本語) — Difyの定義、Dify Cloud(無料のSandboxプラン)とセルフホスト(Community Edition)の2つの利用方法
- Docker Compose で Dify をデプロイする(Dify Docs・日本語) — セルフホストの最小要件(CPU2コア以上・メモリ4GiB以上・Docker Compose 2.24.0以上)とコンテナ構成。2026年8月25日更新
- Dify Open Source License(GitHub・langgenius/dify) — Apache License 2.0を基にした追加条件(マルチテナント運営の制限・ロゴと著作権表示の保持)
- 生成AIサービスの利用に関する注意喚起等について(個人情報保護委員会・2023年6月2日) — 個人情報取扱事業者が生成AIサービスに個人情報を含むプロンプトを入力する際の注意点