【Dify】RAGで作る副業向け小粒AIアプリ10選｜ネタ・MVP・売り方

DifyのRAGを副業に活かす場合、最初から大規模なサービスを開発する必要はありません。特定の会社や業務が抱える小さな課題に絞り、既存の資料を検索して回答や文章案を作る「小粒AIアプリ」として提供する方法があります。

たとえば、社内FAQへの回答、営業メールの下書き、問い合わせ返信案の作成、マニュアル検索などです。対象業務を限定すると、必要な資料や納品範囲を決めやすく、導入後の効果も説明しやすくなります。

この記事では、DifyのRAGを使って提案できる副業向けAIアプリを10種類紹介します。それぞれについて、想定顧客、解決する課題、必要な資料、最小限のMVP、納品物、料金モデルを整理します。

なお、掲載する料金や収益化の方法は一例であり、受注や収益を保証するものではありません。実際の料金は、資料の整理状況、構築範囲、テスト内容、運用支援の有無によって変わります。

この記事では副業ネタと商品設計を中心に扱います。DifyでRAGアプリを構築する詳しい手順は、RAGアプリ開発入門｜社内FAQチャットボットを作って学ぶナレッジ活用をご覧ください。

まずは10種類の一覧から、自分が知識や経験を持っている業界、または必要な資料を用意してもらいやすい業務を探してみましょう。

あわせて読みたい

【Dify】Lesson5-1：RAGアプリ入門｜社内FAQチャットボットを作ろう

DifyのRAG副業アプリ10選｜顧客・課題・MVP比較

DifyのRAGを副業案件として提案するときは、「どのようなAIアプリを作るか」だけでなく、「誰のどの作業を、どの資料を使って支援するか」を明確にすることが重要です。

以下では、10種類のアプリ案を、想定顧客、解決する課題、必要な資料、最小限のMVPで比較します。

副業案件の候補を選ぶときは、まず「発注者が必要な資料を用意できるか」を確認してください。資料が不足していたり、古い資料が混在していたりすると、アプリの回答精度以前に運用が成立しにくくなります。

また、規程、士業、不動産、保険などの重要な判断を伴う用途では、AIの回答をそのまま確定情報として使用せず、必ず担当者や専門家が確認する前提で提案します。

この章は副業商品を比較するための一覧です。Difyで実現できる用途全般を確認したい場合は、Difyの活用事例20選をご覧ください。

あわせて読みたい

Difyで何ができる？事務・営業・人事・マーケのAIアプリ活用例20選

各RAG副業アプリの詳細｜必要資料・MVP・納品条件

ここからは、10種類のRAGアプリについて、副業案件として提案する際に必要な資料、最小限のMVP、納品物、注意点を整理します。

この章では、顧客に「何を提供するか」を中心に説明します。ナレッジの登録やRAGアプリの詳しい構築手順は、DifyのRAGアプリ開発入門をご覧ください。

あわせて読みたい

【Dify】Lesson5-1：RAGアプリ入門｜社内FAQチャットボットを作ろう

① 社内FAQ自動回答

総務、情シス、人事などに同じ質問が繰り返し届いている会社向けのアプリです。質問への回答だけでなく、参照した社内資料の該当箇所を示すことで、担当者が内容を確認しやすくします。

必要な資料

• 社内FAQ
• 申請手順
• 社内規程や利用ルール
• 社内ポータルの案内ページ
• 問い合わせ先の一覧

古い資料が混在すると誤った案内につながるため、最新版と更新責任者を発注者に確認します。

最小MVPと納品物

最初は、質問に対して「回答案・参照箇所・元資料へのリンク」を表示するアプリに絞ります。該当する情報がない場合は、推測せず「担当部署へ確認してください」と案内します。

納品物には、Difyアプリだけでなく、登録資料の一覧、確認用のテスト質問、資料の更新手順を含めます。

人間による確認

人事判断、給与、契約、セキュリティに関する質問は、AIだけで回答を確定させず、担当部署による確認を前提にします。

提案しやすい商品形態

初期構築と資料整理をセットにし、必要に応じて資料更新やテストを月次で支援する形が考えられます。

② 営業向け提案文・メール生成

製品資料や導入事例を参照し、顧客に合わせた提案メールの下書きを作るアプリです。

文章を自動生成するだけでなく、社内で承認された情報だけを使用する点に価値があります。

必要な資料

• 製品・サービス資料
• 導入事例
• よくある質問
• 価格や契約条件
• 使用禁止表現
• 会社指定の文章ルール

最小MVPと納品物

顧客の業種、課題、提案する商品、文章の目的を入力すると、件名、本文、次のアクションを出力する形にします。参照した事例や製品情報も確認できるようにします。

納品物には、入力項目の設計、出力フォーマット、禁止表現のルール、テスト用の顧客条件を含めます。

人間による確認

価格、効果、他社比較、導入実績などの表現は、営業担当者が送信前に確認します。メールを自動送信する仕組みまではMVPに含めません。

提案しやすい商品形態

特定の業界や製品に絞った営業メール作成支援として提案します。製品数や使用する文章テンプレートが増える場合は、追加対応として切り分けます。

③ CS向け返信案メーカー

過去の問い合わせ対応やFAQを参照し、顧客への返信案を作るアプリです。返信文だけでなく、不足している情報や追加で確認すべき項目も表示させます。

必要な資料

• 解決済みの問い合わせ履歴
• 返信テンプレート
• FAQ
• 製品仕様
• 返品・返金・保証に関する規約

問い合わせ履歴に氏名、メールアドレス、注文番号などが含まれる場合は、登録前に個人情報を除外します。

最小MVPと納品物

問い合わせ文を入力すると、返信案、参照したFAQ、追加確認事項を表示する形にします。判断に必要な情報が不足している場合は、回答を確定させず確認質問を返します。

納品物には、返信フォーマット、対応できない質問の条件、テスト用問い合わせ、運用ルールを含めます。

人間による確認

返金、補償、契約、法的な表現を含む返信は、担当者が確認してから送信します。

提案しやすい商品形態

特定の商品や問い合わせ分類に限定した返信支援として始め、対象商品や対応範囲を追加する場合は別途拡張します。

④ 規程・ルール検索アシスタント

就業規則や社内規程から、質問に関連する箇所を探すアプリです。AIが判断を下すのではなく、担当者が判断するための根拠を示す用途に限定します。

必要な資料

• 就業規則
• 社内規程
• 申請・承認ルール
• 社内ガイドライン
• 規程の施行日や版情報

最小MVPと納品物

質問に対して、関連する規程名、該当箇所、簡単な要約、確認先を表示します。資料に記載がない場合は、推測せず担当部署への確認を促します。

納品物には、登録資料一覧、版管理ルール、テスト質問、更新時の差し替え手順を含めます。

人間による確認

人事、労務、法務に関する最終判断は、必ず担当部署または専門家が行います。

提案しやすい商品形態

規程検索の初期構築と、改定時の資料更新支援を分けて提案します。最新版の提供と内容の正確性は、発注者側の責任範囲として明示します。

⑤ 研修・社内ナレッジ検索

新人や異動直後の担当者が、手順書や社内Wikiから必要な情報を探すためのアプリです。回答だけでなく、次に行う作業まで示すと実務で使いやすくなります。

必要な資料

• 業務手順書
• 社内Wiki
• チェックリスト
• よくあるミス
• 問い合わせ先
• 研修資料

最小MVPと納品物

質問に対して、参照した手順、具体的な作業、注意点、次のアクションを表示します。スマートフォンでも確認しやすいよう、回答は短い手順に分けます。

納品物には、利用対象者の設定、回答フォーマット、テスト質問、更新手順を含めます。

人間による確認

安全、品質、顧客対応に関わる作業は、責任者への確認や承認が必要な条件を明示します。

提案しやすい商品形態

新人研修や引き継ぎ支援の一部として提案します。部署や職種が増える場合は、資料と利用範囲を分けて追加します。

⑥ 士業向け書類ドラフト作成

ヒアリング内容と事務所のテンプレートをもとに、書類の下書きを作るアプリです。専門家の代わりに判断するのではなく、聞き漏れ防止と下書き作成を支援します。

必要な資料

• 事務所の書式
• ヒアリング項目
• 記入ルール
• 注意事項
• 公開可能な過去事例

最小MVPと納品物

必要事項を順番に質問し、不足情報を確認したうえで「専門家確認前の下書き」として出力します。参照したテンプレートや注意事項も表示します。

納品物には、質問項目、出力書式、確認必須項目、利用してはいけない用途を含めます。

人間による確認

法律、税務、労務などの判断や、提出前の最終確認は必ず有資格者が行います。AIが完成書類を自動提出する仕組みにはしません。

提案しやすい商品形態

特定の書類や業務に限定したヒアリング・下書き支援として提案します。書類の種類が増える場合は、個別に要件を追加します。

⑦ 不動産・保険向け資料検索

商品資料、約款、重要事項説明書などから、質問に関連する箇所を探すアプリです。説明を自動確定するのではなく、担当者の確認を支援する用途にします。

必要な資料

• 商品パンフレット
• 約款
• 重要事項説明書
• 説明時のルール
• 商品ごとの適用条件
• 資料の版情報

最小MVPと納品物

質問内容と商品条件を入力すると、関連する資料の該当箇所、説明案、注意事項、追加確認項目を表示します。

納品物には、対象商品の一覧、条件入力項目、回答フォーマット、テスト質問、資料更新ルールを含めます。

人間による確認

契約、補償、重要事項などの説明は、必ず担当者が元資料を確認してから顧客へ案内します。

提案しやすい商品形態

対象商品を限定した資料検索支援から始め、商品や資料の追加は別の作業として扱います。

⑧ EC向け問い合わせ回答

商品の仕様書や取扱説明書を参照し、問い合わせへの返信案を作るアプリです。商品数が多い場合は、型番やカテゴリを正しく選べる設計が重要です。

必要な資料

• 商品仕様
• 取扱説明書
• 商品ページ
• 返品・交換規定
• 配送・保証ルール
• 型番やカテゴリ情報

最小MVPと納品物

商品名や型番、問い合わせ内容を入力すると、返信案、参照箇所、追加で確認する情報を表示します。

納品物には、対象商品の一覧、型番の管理方法、返信フォーマット、テスト問い合わせを含めます。

人間による確認

互換性、返品可否、保証対象などは、担当者が条件を確認してから回答します。

提案しやすい商品形態

特定の商品群を対象とした問い合わせ支援として提案します。商品追加や仕様変更への対応は、更新作業として分けます。

⑨ 店舗向けマニュアル検索

店舗スタッフが、接客、レジ、衛生管理、クレーム対応などの手順をすぐに確認するためのアプリです。

必要な資料

• 店舗マニュアル
• レジ操作手順
• 接客ルール
• クレーム対応手順
• 衛生・安全ルール
• 緊急時の連絡先

最小MVPと納品物

店舗や担当業務を選択し、質問に対して「最初に行うこと・具体的な手順・注意点・確認先」の順で表示します。

納品物には、対象店舗の設定、回答フォーマット、緊急時の固定案内、テスト質問を含めます。

人間による確認

事故、けが、衛生問題、重大なクレームなどは、AIの回答だけで処理せず責任者へ連絡します。

提案しやすい商品形態

一店舗または共通マニュアルを対象に始めます。店舗ごとにルールが異なる場合は、資料と回答範囲を分けて構築します。

⑩ 教育向け教材QA・学習ガイド

教材を参照して受講者の質問に答え、次に学ぶ内容を案内するアプリです。講師の代替ではなく、学習中の確認と自走を支援します。

必要な資料

• 教材本文
• 解説
• よくある質問
• つまずき事例
• 学習順序
• 受講ルール

最小MVPと納品物

質問に対して、教材の該当箇所、理解しやすい説明、次に取り組む内容を表示します。教材に根拠がない場合は、講師への質問を案内します。

納品物には、対象教材の一覧、回答範囲、学習ガイドの形式、テスト質問を含めます。

人間による確認

成績評価、受講者への個別判断、教材外の専門的な質問は、講師や運営担当者が対応します。また、登録する教材の著作権と利用範囲を事前に確認します。

提案しやすい商品形態

一つの講座や教材を対象にした質問対応支援として提案します。教材追加やカリキュラム変更は、更新作業として分けます。

DifyのRAG副業案件で確認したい6つの条件

RAGアプリは、Dify上で動くものを作っただけでは副業案件として成立しません。

発注者が必要な資料を用意できるか、導入後に誰が更新するか、AIの回答を誰が確認するかまで決めておく必要があります。

ここでは、RAGアプリを提案する前に確認したい6つの条件を整理します。

条件1：発注者が必要な資料を用意できる

RAGアプリは、発注者が持っている資料を参照して回答します。そのため、最初に確認するべきなのは、資料の量ではなく「利用できる資料が明確になっているか」です。

次の項目を確認します。

資料が不足している場合は、すぐにアプリを構築するのではなく、資料の棚卸しやFAQの整理を最初の作業として提案します。

条件2：対象者と解決する課題を一文で説明できる

対象者や用途が広すぎると、必要な資料と回答範囲が定まりません。

「誰が、どの場面で使い、どの作業を減らすのか」を一文で説明できる状態にします。

たとえば、次のように整理します。

効果を数値で示す場合は、導入前後で確認する指標を決めます。ただし、導入前の段階で削減時間や売上増加を保証する表現は使用しません。

条件3：出力をそのまま業務で確認・利用できる

回答が長いだけのアプリは、実際の業務で使われにくくなります。

利用場面に合わせて、出力形式をあらかじめ決めます。

回答を業務に合わせた形式に揃えることも、納品物の一部として扱います。

条件4：根拠を示し、答えられない質問には答えない

RAGアプリでは、もっともらしい回答を作ることより、発注者が内容を確認できることが重要です。

最低限、次のルールを決めます。

特に、法務、労務、税務、保険、契約、返金、健康、安全に関する内容は、人間による確認を前提にします。

条件5：資料の更新と承認の担当を決める

資料の内容が変わったときに、誰が更新するかを事前に決めます。

資料内容の正確性と利用可否の承認は、原則として発注者側が担当します。一方、Difyへの登録や差し替え作業は、契約内容によって発注者が行う場合と、開発者が代行する場合があります。

次の項目を決めておきます。

「発注者がすべて更新する」と一律に決めるのではなく、作業範囲を契約や提案書に記載します。

条件6：納品範囲と運用支援の範囲を分ける

副業案件では、どこまでが初期構築に含まれ、どこからが追加対応になるかを明確にします。

初期納品物の例は次のとおりです。

さらに、次の項目も事前に決めます。

最初からすべての機能を含めず、初期構築、追加対応、継続的な運用支援を分けて提示すると、発注者との認識を合わせやすくなります。

以上の条件を確認できたら、次に最小限のMVPを決めます。条件を満たしていない場合は、アプリ構築より先に、資料整理や要件整理を提案してください。

副業案件で納品するRAGアプリの最小MVP

副業案件の最初の段階では、さまざまな質問に答えられる大規模なRAGアプリを目指す必要はありません。

最初のMVPは、「一つの対象者が、一つの業務で使うアプリ」に絞ります。対象業務を限定することで、必要な資料、回答範囲、納品条件を発注者と共有しやすくなります。

MVPの対象範囲を一文で決める

最初に、MVPの対象範囲を一文で説明できる状態にします。

たとえば、次のように定めます。

「社内の質問になんでも答える」「すべての商品に対応する」といった広い範囲にはせず、最初に検証できる業務だけを対象にします。

最小MVPに含める5つの納品物

最小MVPでは、次の5つを基本的な納品物とします。

1．用途を限定したDifyアプリ

対象者、利用場面、回答してよい範囲を決めたDifyアプリを納品します。

アプリの目的は一つに絞り、対象外の質問を受けた場合は、担当者への確認や別の問い合わせ先を案内します。

2．登録資料の一覧

Difyに登録した資料について、次の情報を一覧にします。

資料の内容が正しいことを開発者だけで判断せず、発注者側の担当者に確認してもらいます。

3．業務に合わせた回答形式

回答は、利用者が確認しやすい順番に揃えます。

たとえば、問い合わせ対応では「回答案・参照根拠・追加確認事項」、社内規程の検索では「該当箇所・要約・担当部署への確認事項」といった形式です。

回答形式もアプリの納品仕様として、発注者と合意します。

4．回答できない場合の動作

RAGアプリが根拠を見つけられない場合や、質問の条件が不足している場合の動作を決めます。

「何に答えるか」だけでなく、「何に答えないか」も納品仕様に含めます。

5．テスト結果と更新手順

発注者に、実際の業務で使われる質問を10問程度用意してもらいます。

テストでは、次の項目を確認します。

すべての質問に必ず回答できることを合格条件にはしません。根拠がない場合に「回答できない」と適切に判断できることも確認します。

納品時には、テスト結果に加えて、資料の追加・差し替え・削除を行う際の手順も渡します。

最初のMVPに含めないもの

案件の範囲が広がりすぎないよう、次の機能は原則として初回MVPに含めません。

必要な場合は、MVPの確認後に追加対応として見積もります。

この章では、副業案件として何を納品するかを説明しています。DifyでRAGアプリを構築する具体的な操作は、RAGアプリ開発入門をご覧ください。

ナレッジの分割、検索設定、再ランキングなどの調整方法は、ナレッジの詳細設定方法と考え方で解説しています。

あわせて読みたい

【Dify】Lesson5-1：RAGアプリ入門｜社内FAQチャットボットを作ろう

あわせて読みたい

【Dify】Lesson5-2：ナレッジの詳細設定方法と考え方

DifyのRAG副業案件を商品化する方法｜提案・料金設計

DifyのRAGアプリを副業案件として提供する場合、アプリだけを商品にするのではなく、要件整理、資料確認、初期構築、テスト、更新手順まで含めて納品範囲を決めます。

料金は、期待できる効果だけで決めるのではなく、対象業務、資料の状態、構築範囲、テスト内容、納品後の支援範囲から算定します。

ここでは、RAG案件を商品として整理するための基本的な考え方を紹介します。

商品を初期構築・伴走支援・更新代行に分ける

発注者が自分で資料を更新できるか、継続的な支援を必要としているかによって、商品を分けます。

どの商品形態でも、資料内容の正確性と利用可否の最終承認は発注者が行います。

開発者が資料の更新作業を代行する場合も、独自の判断で規程、約款、商品情報などを書き換えないことを契約や提案書に記載します。

初期費用は作業範囲から算定する

初期費用には、次の作業を含めます。

見積もりでは、各作業について「どこまで含むか」を明記します。

たとえば、「資料整理を含む」とだけ書くのではなく、対象となるファイル数、資料形式、重複確認や旧版確認の有無を記載します。

資料数が多い場合や、資料の内容を整理し直す必要がある場合は、アプリ構築とは別の作業として見積もります。

月額費用は継続作業の内容から算定する

月額費用を設定する場合は、毎月行う作業を具体的に決めます。

「継続サポート一式」のような曖昧な表現は避け、対応回数、資料更新数、問い合わせ方法、返信までの目安を決めます。

契約範囲を超える資料追加、機能追加、外部サービス連携などは、別途見積もりにします。

DifyやAIモデルの利用料金を分ける

開発作業の料金と、外部サービスの利用料金は分けて説明します。

確認する費用には、次のようなものがあります。

原則として、発注者自身のアカウントで契約してもらうと、納品後の管理関係が分かりやすくなります。

開発者が一時的に立て替える場合は、利用上限、請求方法、契約終了時の扱いを事前に決めます。

期待効果は価格の説明材料として扱う

RAGアプリによって、問い合わせ対応、資料検索、文章作成などの時間が減る可能性があります。

提案時には、次の指標を確認します。

ただし、導入前の段階で「何時間削減できる」「売上が増える」と保証しません。

最初のMVPで導入前後の状況を確認し、実際の利用結果をもとに継続や追加開発を判断します。

最初に提案しやすい3つの商品

いきなり大規模なRAGアプリ一式を提案するのではなく、対象範囲を限定した商品から始める方法があります。

1．RAG導入前診断

発注者が保有する資料を確認し、RAGアプリとして利用できるかを整理します。

納品物の例は次のとおりです。

診断後に構築を依頼するかどうかは、発注者が判断します。

2．最小MVP構築

一つの対象者、一つの業務、一つの回答形式に限定したRAGアプリを構築します。

納品物には、Difyアプリ、登録資料一覧、テスト結果、更新手順を含めます。

MVPに含める資料数、テスト数、修正回数を事前に決めます。

3．運用・改善支援

MVPの利用開始後に、資料更新、テスト、回答形式の改善を支援します。

月額契約にする場合は、毎月実施する作業と対応上限を明記します。利用が少ない場合や改善作業が不要な場合に備えて、更新ごとの依頼方法も選択肢にできます。

提案書に記載する項目

提案書には、最低限、次の内容を記載します。

「Difyアプリを作ります」だけでなく、何を確認できれば納品完了になるのかを明確にします。

契約前に確認すること

RAG案件では、資料、入力内容、回答ログなどを扱う可能性があります。構築前に、次の項目を確認します。

発注者と開発者の責任範囲を事前に書面で共有しておくことで、納品後の認識違いを減らせます。

DifyのRAG副業案件で起きやすい6つのトラブルと対策

DifyのRAG副業案件では、回答精度だけでなく、資料の管理、個人情報、追加作業、外部サービスの費用などがトラブルの原因になります。

構築を始める前に、発注者と開発者の担当範囲、納品条件、運用方法を確認しておきましょう。

トラブル1：不足した資料や古い資料を参照する

発注者から提供された資料が不足していたり、古い版が混在していたりすると、RAGアプリが誤った情報を根拠として回答する可能性があります。

開発者だけで資料の正しさを判断せず、発注者側の担当者に承認してもらいます。

トラブル2：根拠がない質問にも回答してしまう

RAGを使用していても、登録資料に答えがない質問へ、それらしい回答を返す可能性があります。

特に規程、契約、保険、返金、法務などでは、根拠のない回答をそのまま利用すると問題につながります。

「すべての質問に回答すること」ではなく、「答えられない質問を適切に判定すること」も納品時の確認項目にします。

トラブル3：個人情報や機密情報を登録してしまう

社内資料、問い合わせ履歴、顧客情報には、氏名、連絡先、契約情報、営業秘密などが含まれている場合があります。

また、第三者が権利を持つ教材、記事、マニュアルなどは、AIアプリで利用できるとは限りません。

データの取り扱いについて判断できない場合は、発注者の情報管理担当者や専門家に確認します。

トラブル4：資料追加や機能追加が無制限に発生する

「少しだけ追加してほしい」という依頼が積み重なると、当初の見積もりを超える作業になることがあります。

資料の追加だけでも、内容確認、登録、テスト、回答の再確認が必要です。

対策は、提案書や見積書に、次の内容を記載します。

資料、部署、商品、外部連携などを追加する場合は、影響範囲を確認してから別途見積もります。

トラブル5：更新担当が決まらず運用が止まる

納品時には正しい回答ができても、資料が更新されなければ内容が古くなります。

また、DifyやAIモデルなどの利用料金が支払われていない場合や、利用上限に達した場合もアプリを継続できません。

原則として、外部サービスは発注者自身のアカウントで契約してもらうと、納品後の管理関係が分かりやすくなります。

トラブル6：精度や業務効果を保証したと受け取られる

発注者が「必ず正しい回答が出る」「問い合わせが必ず減る」「売上が増える」と受け取ると、納品後の認識違いにつながります。

RAGアプリは、登録資料、質問内容、利用方法、外部サービスの状態などによって回答結果が変わります。

導入効果は、実際の利用状況を確認したうえで評価します。提案時の想定値を、確定した成果として記載しないようにしてください。

案件開始前の最終チェック

構築を始める前に、最低限、次の項目を確認します。

LLMに任せるべきでない判断や文章については、LLMに任せないほうがいい文章と安全な扱い方で詳しく解説しています。

あわせて読みたい

【Dify】安全運用の基本｜数値・法務・固有名詞の事故を防ぐ

まとめ｜DifyのRAG副業は小さなMVPから検証しよう

DifyのRAGを副業に活かす場合は、最初から大規模なアプリを作るのではなく、特定の顧客と業務に絞った小さなMVPから始めます。

今回紹介した10種類のアプリ案から候補を選ぶときは、次の点を確認してください。

最初の案件では、一つの業務、一つの資料群、一つの回答形式に限定し、実際の質問を使って確認します。

すべての質問に答えられることを目指すのではなく、根拠がない場合に回答しないことや、担当者への確認を案内できることも重要です。

副業案件として提供する場合は、アプリ構築だけでなく、資料の確認、テスト、更新手順まで含めて納品範囲を決めます。料金は、資料の状態、構築範囲、修正回数、運用支援の有無から算定してください。

なお、DifyやRAGを使用しても、受注、収益、業務時間の削減、回答精度を保証できるわけではありません。実際の利用結果を確認しながら、発注者と改善範囲を相談します。

DifyでRAGアプリを構築する具体的な手順は、RAGアプリ開発入門｜社内FAQチャットボットを作って学ぶナレッジ活用で確認できます。

数値、法務、契約など、AIだけに判断させるべきでない内容については、LLMに任せない数値・法務・固有名詞の扱い方もあわせて確認してください。

Difyの基本から実践的なアプリ開発まで順番に学びたい場合は、Dify学習館 会員版｜16個の実践アプリで生成AIアプリ開発を学ぶをご覧ください。

あわせて読みたい

Dify学習館｜生成AIアプリ開発の基礎から実践まで