Difyの使い方｜ノーコードでAIワークフローを作る基礎

Difyは、プログラミング不要で生成AIアプリを構築・公開できるオープンソースのノーコードプラットフォームです。
GitHub Star10万超の支持を集めており、GPT・Claude・Llamaを切り替えながら、チャットボットからRAG、AIエージェント、ワークフロー自動化までドラッグ＆ドロップで組めます。

本業でAIツールを触ってきた立場から見ても、非エンジニアが最初に止まりやすいのはログイン直後のアプリタイプ選択で、ここで手が止まると「何を作るか」が決まりません。
この記事では、その分岐を先に整理し、5種類のうちどれを選べばよいかを最初に解きほぐします。

ゴールは、開始から終了までつながる簡単なワークフローを1本、自分で組み上げられるようになることです。
ノードをつなぐ操作、変数の受け渡し、ナレッジのチャンク設定という初心者がつまずきやすい2大ポイントまで扱うので、単なる機能紹介で終わりません。

無料Sandboxのクレジット200から始められる手軽さもDifyの強みで、その先にはチャットボット構築や業務自動化の案件につながる入口があります。
まずは小さく触って、動く形を1本作ってみましょう。

Difyとは何か｜ノーコードでAIアプリを作る仕組み

Difyは、プログラミング知識がなくても生成AIアプリを構築・公開できるオープンソースのノーコードプラットフォームです。
GitHub Star10万超という数字が示す通り、世界的に支持を集めており、仕組みを理解して使う価値のある土台の厚さがあります。
操作の中心はドラッグ＆ドロップで、左側パネルのノードを線でつないで処理の流れを組み立てます。
まずは「何を作るか」と「どう動かすか」を同時に見渡せる点が、Difyの入口だと考えるとわかりやすいでしょう。

プログラミング不要で作れるもの

Difyで最初に体感しやすいのは、コードを書かずに形になる速さです。
筆者の環境では、非エンジニアの同僚が初めて触れたとき、社内FAQボットの原型が30分で立ち上がりました。
開始、LLM、終了という最小構成でも動作確認まで進められるので、作りながら全体像をつかめます。
対話型のチャットボットに加えて、社内文書を検索して答えるRAG、手順を順に実行するワークフロー、判断を任せるAIエージェントまで広く扱えるため、用途の入り口を狭めないのが強みです。

複数のAIモデルを使い分けられる強み

GPT・Claude・Llamaなど複数のAIモデルをアプリ内で選択・切替できる点も、Difyの実務価値を押し上げています。
単一モデルに縛られないので、応答品質を重視する場面と、コストを抑えたい場面で頭脳を差し替えやすいからです。
GitHub Copilotなど他のAI開発ツールを使ってきた立場から見ると、この「後から替えられる」設計は運用段階で効いてきます。
作り始めるときより、公開後に負荷や料金を見ながら調整するときのほうが差が出るため、実務ではかなり扱いやすい発想です。

オープンソースだから無料で始められる

オープンソースであることも、Difyを試しやすい理由です。
無料のSandboxから始められる構成があり、学習や試作の段階で大きな初期投資を求められません。
セルフホストも選べるので、手元で動かしながら仕組みを確かめたい人にも向いています。
料金や公開形態を段階的に選べるため、まず小さく作って、必要になったら広げるという進め方がしやすいのです。
生成AIアプリを作るハードルを下げつつ、あとから運用の形を選び直せる柔軟さが、Difyの土台を支えています。

5つのアプリタイプの使い分け早見表

まずは目的別に切り分けると迷いにくくなります。
会話の窓口を置きたいならチャットボット、対話の流れを細かく作りたいならチャットフロー、定型の業務を流したいならワークフロー、AIに道具の使い方まで任せたいならエージェント、定型文を量産したいならテキスト生成です。
Difyではこの5タイプを同じ画面感で扱えるので、最初に「何をさせるか」を決めるだけで選択肢がかなり絞れます。
迷ったらチャットボットから始めるのがいちばん組み立てやすいでしょう。

会話で答えるなら『チャットボット/チャットフロー』

チャットボットは、サイト上の相談窓口や問い合わせ対応のように、ユーザーの質問へ会話で返す用途に向いています。
そこから少し踏み込んで、質問の順序や分岐を丁寧に設計したいならチャットフローが合います。
違いは対話をどう扱うかで、チャットボットは受け答えの入口、チャットフローは会話型AIアプリの設計図だと考えると整理しやすいです。

筆者が業務改善の相談を受けたときも、最初は全部をワークフローで組もうとして複雑になりました。
実際には、対話が必要な部分をチャットフローに切り出すだけで流れがかなり見通しよくなったのです。
向いている人は、まず相談導線を整えたい人や、対話の順番を細かく決めて応答品質を安定させたい人です。

処理を自動化するなら『ワークフロー』

ワークフローは、複数の処理を一連の流れとしてつなぎ、業務を自動化したいときに使います。
開始→LLM→終了の3ノードで要約アプリを動かせる手軽さがありつつ、条件分岐、イテレーション、HTTPリクエストなどを足していくことで、実務寄りの処理まで伸ばせます。
対話の有無で見るなら、会話を続ける必要がない処理はワークフローに寄せるのが自然です。

向いている人は、定型作業を減らしたい人、手順が決まっている社内処理を回したい人、入力から出力までを安定運用したい人です。
逆に、会話の途中でユーザーの意図を拾い直す場面が多いなら、ワークフローだけで抱え込むと設計が重くなります。
筆者もそこを外して複雑化させた経験があり、対話と処理を分ける発想が効きました。

AIに判断させるなら『エージェント』

エージェントは見た目こそチャットボットに似ていますが、AI自身が「どのツールを使うべきか」を判断して動く点が決定的に違います。
つまり、会話するだけでなく、検索や外部操作のようなツールを状況に応じて選ばせられるのが最大の特徴です。
チャットフローやワークフローが人の設計した順路をなぞるのに対し、エージェントは判断の余地を持たせます。

ただし、その自由度は設計の甘さも拾いやすいです。
エージェントを試したときにツールの判断をAIへ委ねすぎると、意図しない動作になりました。
初心者には、まずワークフローで手順を固定してから必要な部分だけエージェント化する流れの方が確実です。
向いている人は、複数ツールをまたぐ作業をAIに振り分けたい人ですが、最初から任せ切るより、段階的に広げる方が扱いやすいでしょう。

テキスト生成は、定型文や記事パーツを量産したいときに選ぶと使いどころがはっきりします。
会話や処理の分岐を持たず、まず文章を作ること自体が目的なら、他のタイプよりも軽く運用できます。
5タイプを同じ観点で並べると、会話ならチャットボット/チャットフロー、処理ならワークフロー、判断まで任せるならエージェント、文面を増やすならテキスト生成と分かれます。
ここまで絞れば、作り始める前の迷いは減るはずです。

アカウント登録から最初のアプリ作成まで

クラウド版のDifyは、無料登録だけでそのままアプリ作成を始められます。
Dockerなどの環境構築を飛ばして画面に入れるので、最初の一歩で止まりにくいのが利点です。
登録後はスタジオから新しいアプリを作り、タイプを選んで、必要なノードを置く流れになります。
ここで全体像を先に押さえておくと、初回の操作で迷いにくくなります。

クラウド版に無料登録する

クラウド版は、登録直後から触り始められるのが強みです。
ローカル環境にDockerを入れて構成を整える段階を省けるので、まず動かして感触を確かめたい人には最短ルートになります。
初期のつまずきは「使い方」より「始め方」に集中しやすいため、入口が軽いだけで学習コストは下がるでしょう。

無料Sandboxはメッセージクレジット200、チーム1名、アプリ5個までという枠があります。
ここは広く試すための無制限プランではなく、少ない操作で仕組みを理解するための検証環境だと捉えるのが自然です。
筆者も検証中にクレジット200を思ったより早く使い切り、テスト用でも実行回数を意識しないと確認が続かないと痛感しました。
まずは少数の試行で作り、動作の手触りを確かめてみてください。

スタジオで新しいアプリを作る

登録後の本筋は、スタジオに入って新しいアプリを作ることです。
流れはスタジオ、新規アプリ作成、アプリタイプ選択、ノード配置という一本道で、最初にこの順番を知っているだけで画面前の手止まりが減ります。
どこから触ればいいのかが見えていない状態だと、機能が多いほど迷いやすいからです。

アプリタイプの選択は、単なる分類ではなく、その後の設計の土台になります。
チャット系なのか、ワークフロー系なのかで置くべきノードの考え方が変わるため、先に役割を決めてしまうほうがです。
ここで構造を決めてからノードを置くと、後から組み直す手間が減ります。
おすすめです。

使うAIモデルを設定する

多くのアプリでは、AIモデルのAPIキー設定が先に必要になります。
どのモデルを使うかを選び、キーを登録して初めて応答が返る仕組みなので、ここを飛ばすと画面だけ進んでもAIは動きません。
非エンジニアがつまずきやすいのは、この「作成したのに返事がない」状態で、原因がモデル設定にあると気づくまで数分止まりがちです。
筆者も初めてDifyクラウド版を登録したとき、APIキーの設定を飛ばしてしまい、AIが応答せずに数分悩みました。
だからこそ、モデル設定は最初に済ませる前提で進めるのがいいでしょう。

設定の順序を先に固定しておくと、後工程の確認も楽になります。
モデルを選ぶ、キーを入れる、応答を確かめる、この3段階を通しておけば、あとはノード配置や入出力の調整に集中できます。
仕組みとしては単純ですが、最初にここを外さないことが、実際にはいちばんの近道です。
まず動く状態を作ってから、細かい調整に進みましょう。

ワークフローの作り方｜ノードを繋いで処理を組む

ワークフローは、開始ノードから終了ノードまで処理を一本の流れとしてつなぐ設計です。
まず入力、処理、出力の順番を決めると、どのノードが何を受け取り、何を次へ渡すのかが見えやすくなります。
複雑に見えても、最初は全体像を単純化して考えるのが近道でしょう。

ノードの種類と役割を押さえる

ワークフローの中心になるのがノードです。
LLMノードは文章生成・要約・分類などAIの中核処理を担い、知識検索ノードは登録済みナレッジから関連情報を引き出してRAGを実現します。
ここに条件分岐のIF/ELSE、イテレーション、HTTPリクエストを加えると、14種前後のノードを組み合わせて幅広い処理を組めるようになります。
とはいえ、最初から全部覚える必要はありません。
まずLLMと知識検索の2つを押さえるだけでも、初心者が触る土台としては十分です。

ノードを配置して線で繋ぐ手順

操作は単純で、左パネルからノードをドラッグ＆ドロップで配置し、ノード端子をドラッグして順番に線で繋ぎます。
コードを書く代わりに、処理の順序を視覚的に並べる感覚です。
開始ノードから出た出力が次のノードの入力になり、その先へまた渡っていくので、線の向きがそのまま処理の向きになります。
ここを逆にすると流れが止まるため、作業のたびに前ノードの出力と次ノードの入力を対応させて見ていきましょう。

簡単な要約ワークフローを作ってみる

筆者が最初に組んだのも、議事録を要約するだけの3ノードワークフローでした。
開始、LLM、終了の3つをつなぎ、長文を受けて短く返すだけなのに、動いた瞬間に「これなら業務で使える」と手応えが生まれます。
逆に、ノードを繋ぐ順序を間違えたときは出力が空になり、線の向きが前ノードの出力から次ノードの入力へ流れる前提だと体で覚えました。
イテレーションはリスト形式のデータを1件ずつ処理する仕組みで、複数の画像や領収書を順に扱う場面に向いています。
まずは小さく作って動かし、必要に応じてIF/ELSEやHTTPリクエストを足していく進め方がおすすめです。

初心者が最初に詰まる2大ポイント｜変数とナレッジ設定

変数の受け渡しとナレッジの検索精度は、初心者が最初につまずきやすい2大ポイントです。
どちらも「設定したつもり」で止まりやすく、実際には名前の打ち間違い、出力の接続漏れ、チャンクの切り方の甘さが原因になっていることが多いでしょう。
まずは仕組みを押さえ、どこを確認すれば切り分けられるかを先に持っておくと、デバッグの迷いが減ります。

変数が渡らない時に確認すること

プロンプト内で {{variable_name}} と二重中括弧で書くと、モデルに届く前に実際の値へ置き換わります。
ここで参照しているのは、前のノードが出した値を次のノードで使う仕組みそのものです。
つまり変数は飾りではなく、ワークフローの受け渡し口です。
筆者も変数名の打ち間違いで数十分デバッグし、原因が単純なタイプミスだと分かったことがあります。
初心者ほどここで止まりやすいので、まず参照名のスペル、前ノードの出力変数の指定、ノード同士をつなぐ線の3点を順に見ればよいです。

変数が見つからない時は、どこか一箇所だけが悪いとは限りません。
名前が合っていても、前ノード側で値を出していなければ次へ渡りませんし、線がつながっていなければ参照先自体が存在しません。
逆に言えば、この3点を確認するだけで大半は片づきます。
仕組みとしては単純なので、落ち着いて一つずつ確かめてみてください。
ここがポイントなんですが、複雑そうに見えても原因は意外と地味です。

ナレッジの検索精度が低い時のチャンク見直し

ナレッジのRAG精度は、実際にはチャンク設定でほぼ決まります。
チャンクが文書構造を無視していたり、正しいチャンクが上位に来なかったりすると、情報は入っているのに検索されない状態になります。
筆者はチャンクサイズを大きく取りすぎて検索が的外れになり、文書構造に沿って分割し直しただけで精度が明確に上がった検証をしています。
親子チャンキングは、子チャンクで拾って親チャンクの文脈をLLMへ渡すやり方で、精度向上の定石です。

見直す順番もはっきりしています。
まず文書の見出し単位で意味が切れているかを見て、次に検索で上位に来るチャンクが回答に必要な情報を含むかを確認します。
それでも弱いなら、親子チャンキングのように文脈を足す設計へ寄せるとよいです。
RAGが機能しない原因は「構造を無視した分割」「正しいチャンクが上がらない」「あるのに検索されない」の3つに集約されるので、設定を変えて試す前提で詰めていきましょう。

エラーの切り分け手順

エラー全般は、いつ、どこで、どんな操作で起きたかを時系列で整理すると早くほどけます。
入力なのか、ワークフローなのか、API連携なのか、ナレッジなのか、システムなのかを分けて考えると、原因の範囲が一気に狭まります。
ここを曖昧にしたまま作業を続けると、同じ失敗を何度もなぞることになりがちです。

切り分けのコツは、再現条件を先に特定することです。
同じ入力で必ず起きるのか、特定のノードを通ると起きるのか、ある操作だけで発生するのかを見れば、修正すべき場所が見えてきます。
とくに変数とナレッジは、見た目の設定より実際のデータの流れが原因になりやすいので、順番に追う姿勢が効きます。
原因を感覚で探すより、流れを分解して確認するほうがずっと速いです。

料金プランとセルフホスト｜無料でどこまで作れるか

料金プランは、無料で試す段階、月額を払って伸ばす段階、そして自前で抱える段階の3つに分けて考えると判断しやすくなります。
無料Sandboxは試作向けの入口としては十分ですが、使い込みが進むほどクレジットの消費が先に壁になります。
そこを越えるならProfessional、さらに費用より制御性を優先するならセルフホストが現実的です。

無料Sandboxで試せる範囲

無料Sandboxはメッセージクレジット200、アプリ5個、チーム1名までという小さな枠ですが、初回の検証にはちょうどよい広さです。
画面の使い勝手や自分の業務フローに合うかを確かめるには足りますし、複雑な運用に入る前に向き不向きを見極めやすい。
筆者もここで試作を進めるうち、思ったより早くクレジットに当たり、本格運用の段階では別の選択が要ると感じました。

この枠の良さは、機能の一部を断片的に見るのではなく、実際に数本のアプリを作って触れるところにあります。
とはいえ、日常的に回す前提だと消費速度が問題になりやすく、使い続けるほど「どこまで無料で粘るか」より「どの時点で移るか」を考える場面が増えます。
おすすめは、最初の検証をこの枠で一気に進め、アプリ数や実行回数が見えてきた時点で次の段階を見定めることです。

Professionalに上げるべきタイミング

Professionalは月59ドル、年払いなら実質月49ドルで年588ドルになり、チーム3名・アプリ50個・月5,000クレジット・5GBナレッジまで拡張されます。
個人の本格運用なら、無料枠の切れ目を気にしながら作業するより、このプランに上げたほうが流れを止めずに済みます。
とくにアプリ数とクレジットの両方が増えるので、検証から日常利用へ自然に移しやすいのが強みです。

筆者が月額と運用手間を比べたときも、判断軸は単純でした。
作るものが増え、使う回数が増え、都度の制約確認が面倒になるなら、月59ドルを払って作業を前に進めたほうが効率は上がります。
おすすめなのは、無料Sandboxで「手応えはあるが足りない」と感じた瞬間に、Professionalを候補に入れることです。
迷うなら、まず上限を超える原因がクレジット不足なのか、チーム人数なのかを見てみてください。

セルフホストという選択肢

コストを抑えたい、あるいはデータを自社側に置きたいなら、セルフホストが選択肢になります。
最小要件はCPU2コア以上、RAM4GB以上、Docker Compose 2.24.0以上で、macOSでは8GB以上の割り当てが安心です。
筆者がDocker Composeで立てたときも、RAM4GBでは本番運用に不安が残り、最小要件は「動く」ラインだと受け止めました。

セルフホストのライセンスは、マルチテナントSaaSとしての再提供禁止とロゴ削除禁止の2制限つきです。
ただし、その2点に触れなければ、自社アプリのバックエンドや企業向け開発基盤として商用利用できます。
おすすめの判断は明確で、費用を固定したいならProfessional、運用や配置を自分で握りたいならセルフホストです。
手間をかけてでも制御を取るか、月額で速度を買うか。
ここが分岐点になります。

作れるようになった先に｜Dify副業案件の相場

Difyでアプリを組めるようになると、副業案件は現実的になります。
シンプルなチャットボット構築なら月単価5万〜15万円が相場で、ノーコードで組めるぶん参入のハードルが低いのが特徴です。
まずは小さく動くものを1つ作り、そのまま提案材料に変えていく流れをつかみましょう。

チャットボット構築案件の単価

チャットボット構築案件は、問い合わせ対応や社内案内のような定型業務を自動化したい企業から出やすく、最初の受け皿として入りやすい分野です。
月単価5万〜15万円という水準は、要件がシンプルであるほど成立しやすく、Difyのように画面上で組めるツールと相性がいいからです。
筆者の周囲でも、Difyで問い合わせボットを作り、ポートフォリオとして見せた副業志望者がクラウドソーシングで初案件を取っていました。
動くものを1つ見せられるだけで、提案の説得力は一気に上がります。

自動化・エージェント案件の単価

業務自動化・最適化システムは月単価20万〜50万円、AIエージェント開発は月50万円以上が見えてきます。
単なる受け答えだけでなく、情報の取得、分岐、通知、記録までをつなげる必要が出るため、求められる設計力が上がるからです。
扱える範囲が広がるほど単価も上がる構造なので、学習の方向がそのまま収入の伸びにつながります。
筆者自身もAPI連携を絡めた自動化を組めるようになってから、単純なボット構築より提案の幅が広がり、同じ相談でも出せる見積もりのレンジが変わりました。

単価を上げるために身につけること

単価を押し上げる決め手は、API連携とUI/UXの知識です。
API連携ができると外部サービスとつなげて実務に落とし込めるため、ただのデモで終わらず「業務で使える提案」になります。
UI/UXまで意識できると、使う人が迷わない画面設計まで含めて任せられるので、依頼側の安心感も増します。
さらにDifyは専門家がまだ少なく、需要に供給が追いついていません。
今から触って、作って、提案してみてください。
先行者優位を取りやすい土壌があります。

ニッチ業界に特化したボットなら、月額3,000〜5,000円のサブスク課金でも受け入れられています。
受託だけでなく、自分で小さなサービスとして出す道があるのは強みです。
単発案件で経験を積みつつ、繰り返し課金につながる形に育てると、収入の安定感が変わってきます。
おすすめです。