Dify×LINE Botで稼ぐチャットボット構築代行の受注手順

DifyとLINE Botを組み合わせたチャットボット構築代行は、技術が作れることと仕事として受注できることが別スキルだとはっきり分かる領域です。
シナリオ型ならFAQ100問の整備で20万円前後、AI型なら初期数十万円に月額10万〜30万円という相場があり、個人でも要件を絞れば十分に食い込めます。
筆者も本業エンジニアとして最初は社内FAQ風のデモBotを作りましたが反応が薄く、業種特化の見せ方に変えた瞬間に問い合わせが来ました。
そこで本記事では、Difyでボット本体を作り、LINE公式プラグインで中継サーバーなしに連携し、要件定義から納品前チェック、月額保守までを受注の流れとして具体的に整理します。

Dify×LINE Bot構築代行で稼げる理由と案件単価

Dify×LINE Botは、個人が副業で入りやすいチャットボット案件の中でも、初期投資と開発期間を抑えやすい組み合わせです。
市場の相場を見ると、シナリオ型、AI搭載型、生成AI型で費用構造が大きく違い、ここを切り分けて理解すると見積もりの土台が作りやすくなります。
案件単価も、相場の下に置きすぎなければ利益が残りやすく、保守まで含めると継続収益に変えやすい領域だといえます。

チャットボットの3タイプと費用相場の違い

チャットボットは大きく3タイプに分かれます。
シナリオ型は月額数千円〜5万円で運用でき、FAQ100問程度の整備で20万円前後が目安です。
AI搭載型は初期費用数十万円、月額10万〜30万円超が中心になり、生成AI型はSaaS月額数万円に加えてAPIトークン課金が別途数千〜数万円/月かかります。
つまり、見た目は似ていても、実際には「ルールを組むのか」「AIを学習させるのか」「RAGで知識を引くのか」で原価がまったく変わるのです。

この表が示すのは、価格だけでなく収益モデルの違いです。
シナリオ型は設計とFAQ整理が価値の中心で、AI搭載型は導入後の運用負荷まで含めた提案が必要になります。
生成AI型は導入しやすい反面、API実費の見積もりを外すと利益が崩れやすい。
だからこそ、Dify×LINE Botのように小さく始めて拡張できる構成は、個人に向いています。

個人がDify×LINE Botで参入しやすい3つの理由

Dify×LINE Botが個人受注に向く理由は3つあります。
第一に、Difyはノーコードでナレッジを積めるため、分割した資料を登録して調整すれば、1日でプロトタイプまで持っていきやすいことです。
第二に、LINE公式プラグインを使えば中継サーバーを用意せずにWebhook接続でき、窓口をLINE、頭脳をDify、つなぎをWebhookとして整理できることです。
第三に、Dify CloudはSandbox無料・Professional $59・Team $159の三層で、無料枠からデモを作れるので、初期投資ゼロに近い形で実績づくりができます。

この構成が強いのは、法人の専門会社と真正面からぶつからずに済むからです。
大規模開発ではない領域で「安く、早く、小回りが利く」提案がしやすく、業種特化のデモBotを1つ用意するだけでも商談の入口が広がります。
ランサーズでチャットボット開発の募集が常時400件超、AIチャットボット開発で413件あるという事実も、案件が一過性ではないことを示しています。
市場の厚みがあるので、まずは小さく受けて経験を積みましょう。

初期費用＋月額保守で利益が残る価格設計

価格は、初期構築費だけで決めないほうがいいです。
小規模FAQボットなら初期5万〜15万円、ナレッジ量や有人引き継ぎ要件が増えれば20万〜30万円に置くと、法人の生成AI型相場より下にありながら、個人の工数に見合う余地が残ります。
見積もりは初期構築費、ナレッジ整備費、連携設定費、月額保守、API実費を分けて積み上げるのが筋で、ここを曖昧にすると後から赤字になりやすいです。

保守の考え方も、フロー収益とストック収益を分けると整理しやすいです。
スクラッチ開発では年間開発費の20〜30%が保守相場ですが、Dify構築代行なら月額1万〜5万円の保守契約に落とし込みやすく、ナレッジ更新、回答チューニング、API利用監視をまとめて請けやすくなります。
ここを仕組みにしておくと、単発案件でも積み上がります。
おすすめです。
見積もりの基準をタイプ別相場に置き、保守を先に設計してみてください。

受注前に固める要件定義とヒアリング項目

受注前の要件定義で曖昧さを残すと、見積もりはすぐに崩れます。
とくにLINE公式アカウント連携のボットは、目的・対象ユーザー・想定質問数・ナレッジ元データ・有人引き継ぎの有無で工数が変わるため、契約前に論点を固定しておく流れが必要です。
あわせて、アカウント権限やDifyプラン、API費用の負担先まで先に決めておくと、納品後の揉め事をかなり減らせます。

ヒアリングシートに入れる必須5項目

ヒアリングシートに入れるべき項目は、①ボットの目的（問い合わせ削減・予約・集客）、②対象ユーザー、③想定質問数とジャンル、④ナレッジ元データの形式と提供範囲（PDF/CSV/URL）、⑤有人引き継ぎの要否、の5つです。
ここを先に埋める理由は、同じ「LINEチャットボット」でも、目的が問い合わせ削減ならFAQ精度が最優先になり、予約なら導線設計が、集客なら初回応答の設計が中心になるからです。
筆者の経験でも、想定質問数を曖昧にしたまま受注した案件で、後から質問リストが想定の3倍に膨らみ、工数が破綻しかけたことがありました。

さらに、ナレッジ元データの範囲を契約前に確定しないと、PDFだけで済む前提だったのにCSV整備やURL収集まで発生し、作業範囲が雪だるま式に増えます。
有人引き継ぎの要否も軽く見られがちですが、ここが曖昧だと、ボットで完結させるのか、有人対応へ切り替えるのかが曖昧なまま残ります。
ヒアリングシートは情報収集のためではなく、後工程の責任分界を先に切るための道具だと考えるとでしょう。

DifyプランとAPIコストの負担をどう決めるか

Dify CloudはSandbox無料、Professional $59/ワークスペース、Team $159/ワークスペースの三層で、無料枠はAPIコール概算1,000件/月、サンドボックスは1日500件までです。
本番運用の想定トラフィックが見えないままプランを選ぶと、デモ段階では足りていても公開後に不足しやすくなります。
だからこそ、クライアントのアカウントで構築するのか、自分のワークスペースを使うのかまで、契約時点で決めておく必要があります。

APIコストは、生成AI型である以上、OpenAI等のトークン課金が利用量に比例して発生します。
月額保守にAPI実費を含めるなら上限条件を設け、別建て請求にするなら請求タイミングと算定方法を明文化しておかないと、利用が伸びた月に赤字化します。
実際、口頭合意だけで進めた案件でAPI代をめぐって揉めた経験があり、それ以降は契約書に「API実費は実費精算」「月額保守には運用監視と軽微修正のみを含む」といった形で負担構造を書き分けるようにしています。

ブレない概算見積もりの積み上げ方

見積もりは『初期構築費＋ナレッジ整備費＋連携設定費＋月額保守（＋API実費）』の4〜5要素で積み上げると、説明しやすくなります。
とくに初期構築費とナレッジ整備費は混同されやすいですが、前者はDify側の設計やLINE連携、後者はFAQや資料の整理・分割・投入にかかる作業です。
ここを分けるだけでも、何にいくらかかるのかが伝わりやすくなります。

ナレッジ整備費は、想定質問数が50問か100問かで大きく変わります。
質問リストが少ない案件と、社内ルールや商品群まで含めた大規模案件では、同じボットでも整備量が別物だからです。
だから、質問リストの提供範囲を契約前に確定することが見積もり精度の肝になります。
積み上げ式で説明し、どこが固定費でどこが変動費かを分けて示せば、提案時の納得感も作りやすいでしょう。

DifyでAIチャットボット本体を構築する手順

DifyでAIチャットボット本体を組むときは、先にナレッジの作り込みと回答の出し分けを固めると、後工程の手戻りが減ります。
とくにRAGを土台にするなら、Knowledgeへの登録方法、Context側のRetrieval設定、Studioでのプロンプト設計を順番に詰める流れが再現しやすいです。
1日でプロトタイプまで持っていくなら、最初からテスト工程まで含めて設計しておきましょう。

ナレッジ(RAG)へのデータ登録と分割設定

Knowledgeを作成したら、まずFAQシートをCSV、TSV、Excelのような構造化データとして整え、原本PDFやURLとあわせて登録します。
PDFをそのまま放り込むと表組みが崩れて回答の根拠がずれやすく、FAQはCSVに整形してから入れたほうが、質問と回答の対応関係を安定して保てます。
分割サイズは一般に500〜1000文字程度が扱いやすく、長すぎると無関係な情報が混ざり、短すぎると前後の文脈が切れるため、この範囲が実務ではバランスを取りやすいです。

ナレッジ登録は単なる投入作業ではなく、後の検索品質を決める前処理です。
FAQ、PDF、URLを同じKnowledgeに入れておくと、定型回答はFAQから、補足説明は原本資料から拾う、といった役割分担がしやすくなります。
ここで素材の粒度を揃えておくほど、RAGの検索結果が安定し、回答のブレも抑えやすくなります。

回答精度を上げるTop-K・閾値・プロンプト調整

Context設定のRetrievalでは、Top-Kとスコア閾値が回答精度を左右します。
筆者の環境では、最初にTop-Kを大きく取りすぎて無関係なナレッジが混ざり、回答が散らかったことがありました。
そこから閾値を上げて取得件数を絞ると、必要な根拠だけが残って精度が安定しました。
引用や出典表示も有効化しておくと、どの情報を元に答えたかが見えやすくなり、納品時の説明責任を果たしやすいです。

精度が低いときは、触る順番を決めておくと迷いません。
まず分割サイズを見直し、次にTop-Kを調整し、それでも散るなら閾値を上げます。
最後にシステムプロンプトを詰める、という順番です。
分割が粗すぎると検索以前の問題が出るので、いきなりプロンプトをいじるより、検索対象そのものを整えるほうが効きます。
ボットの口調、回答範囲、ナレッジ外の質問への返し方を指示文で固定し、業務スコープを狭く保ちましょう。

テストして納品品質まで仕上げる

Studioではチャットアプリを作成し、先ほどのKnowledgeをContextに紐付けます。
ここでシステムプロンプトに、口調、業務範囲、回答できない質問の扱いを入れると、ボットの人格と役割がぶれません。
たとえば飲食店向けなら「営業時間、予約、メニュー説明に絞って答える」、士業向けなら「制度の一般説明にとどめ、断定的な個別判断は避ける」といった具合に、業種ごとに指示文を変えると実用性が上がります。
おすすめです。

ナレッジベース作成、パイプライン設定、RAGアプリ、テストの4ステップを回せば、1日でプロトタイプに到達できます。
テストでは想定問答のリストを用意し、正答率だけでなく、引用の出方、言い回しの自然さ、ナレッジ外質問への応答も確認しましょう。
ここで通らないまま次の工程へ進むと、LINE連携後に修正コストが膨らみます。
品質ゲートを先に置くのが、納品までの近道です。

LINE Messaging APIと連携してBotを公開する

LINE Messaging APIとDifyを組み合わせると、LINEが窓口、Difyが頭脳、Webhookがパイプという役割分担でBotを公開できます。
メッセージはLINEからWebhook経由でDifyへ渡り、生成された返答が再びLINEへ戻るため、流れを一度つかむと切り分けが速くなります。
副業の入口としても相性がよく、シナリオ型・AI型・生成AI型の相場感と比べると、個人でも提案しやすい価格帯に落とし込みやすいのが強みです。

LINEチャネル作成とトークン取得

最初に必要なのは、LINE DevelopersでMessaging APIチャネルを作成し、チャネルアクセストークンとチャネルシークレットを取得することです。
ここで押さえたいのは、Botは「LINE公式アカウントを作れば終わり」ではなく、どのアカウントを誰の権限で扱えるかを先に確認する点にあります。
クライアント所有のアカウントなら権限の受け渡しが曖昧だと後工程で止まりやすく、自分所有なら検証から公開までを速く進めやすい。

Dify公式プラグインでWebhook接続

Dify側は公式プラグイン方式を主軸にすると、実装の手数をかなり削れます。
Difyのプラグインから「LINE」を検索してインストールし、チャネルシークレットとアクセストークンを入力すれば、発行されたWebhook URLをLINE DevelopersのMessaging API設定へ貼り付ける流れです。
検証ボタンを押してからWebhookの利用をONにすれば接続が成立します。
中継サーバーを挟まずGUIだけで完結するので、初回納品の速度を上げやすい構成です。

ただし、Webhook URLを貼ったのに返信が来ない詰まりポイントは珍しくありません。
実際に初めて連携したときも、原因はDifyアプリをPublishしていなかったことでした。
接続そのものより、公開状態や設定の有効化で止まりやすいので、LINE、Dify、Webhookのどこでメッセージが止まっているかを順に見る習慣が役立ちます。

プラグイン方式と中継サーバー方式の選び方

受注のしやすさで見ると、Dify×LINE Botはクラウドソーシングでも相性がよく、チャットボット開発の募集は常時400件超、たとえばAIチャットボット開発で413件という水準があります。
1案件あたりの目安は、シナリオ型なら20万円前後、生成AI型でも小規模なら数十万円台に収まりやすく、個人が「まず1件納品する」入り口としては現実的です。
さらに保守はスクラッチ開発の年間開発費20〜30%に対し、Dify構築代行なら月額1万円〜5万円のストック型に設計しやすく、単発で終わらせず積み上げやすい。

拡張性が必要な案件では、中継サーバー方式に切り替える判断が出てきます。
外部予約システムとAPI連携した案件では、プラグイン方式より工数は増えましたが、フロー分岐や他システムとのつなぎ込みが柔軟になり、要件に合わせた提案がしやすくなりました。
最短納品と低コストを優先するならプラグイン、独自の処理や外部連携まで見込むなら中継サーバー、という分け方で考えるとでしょう。

納品前チェックとよくある連携トラブルの解消

納品前の確認で先に潰すべきなのは、返信が来ない状態の切り分けです。
DifyでアプリをPublish/Deployしていない、LINE側でWebhook利用がOFFになっている、チャネルアクセストークンに余分なスペースや文字欠けがある、この3点だけで外部連携は止まります。
編集途中のままでは動かない仕様なので、見た目の設定より先に配信状態と接続状態を確かめる流れにしておくと、原因特定が速くなります。

返信が来ないときの3大チェックポイント

最初に確認するのは、DifyでアプリをPublish/Deployしたかどうかです。
編集画面でロジックが正しく見えていても、公開されていなければ外部からは参照されません。
次に、LINE側のWebhook利用がONになっているかを見ます。
ここが切れていると、ユーザーの送信は届いてもBotの応答経路が成立しません。
ここまでで止まる案件は多く、設定の順番を誤ると、コードやプロンプトを何度直しても空振りになります。

三つ目はチャネルアクセストークンです。
納品直前に末尾へ紛れた半角スペースで返信が来ず、30分悩んだ末に気づいたことがありましたが、こうした見えない1文字で接続は簡単に失敗します。
文字欠けも同じで、コピペした瞬間は正しそうに見えても、実際には認証できていないことがあるため、先頭と末尾まで含めて再入力し、切り分けの最後ではなく最初に疑うのが実務的です。

ランニングコストと応答品質の最終確認

コストはクラウド版月額、APIコスト、プロンプト調整の体制コストを足し上げて見積もります。
想定利用回数にトークン単価を掛け、そこへ運用側の工数を載せると、見かけの月額だけでは判断できない実費が見えてきます。
特に想定トラフィックでDifyプランが無料枠の月1,000コール、日500件を超えるなら、早い段階で有料移行の見積もりまで添えておくべきです。
単価より先に上限を確認しておくと、納品後の想定外コストを防げます。

応答品質の確認では、速さだけでなく、長い質問への戻り方や、曖昧な入力に対して無理に答え切ろうとしない挙動も見ます。
おすすめなのは、実際の利用を想定した質問を流し、返答の長さ、応答までの待ち時間、失敗時の振る舞いを同時に見る方法です。
性能だけを追うと運用で崩れやすいので、速度と安定性をセットで詰めていきましょう。
必要なら、ここで有料プランへ移る前提の見積もりを並べて比較してみてください。

操作マニュアルとフォールバック設計の納品

ナレッジに該当がない質問には、返せる文言と有人引き継ぎ導線を先に決めます。
『答えられないときに何を返すか』まで設計して初めて、実務で使えるボットになります。
該当データがないときに黙るだけでは、利用者は不信感を持ちますし、問い合わせ先が分からなければ案件全体の評価も落ちます。
だからこそ、定型回答、担当者へのつなぎ方、記録の残し方を一続きで設計しておくのが筋です。

納品物は、テスト質問リスト、操作マニュアル、ナレッジ更新手順をひとまとまりにして渡します。
操作マニュアルを付けずに納品したころは、ナレッジ更新の問い合わせが頻発しましたが、更新手順書までセットにした後は、相手側で回るようになり、そのまま保守契約に発展しました。
クライアントが自走できる状態まで持っていくと、検収は通りやすくなりますし、後続の月額保守にもつながりやすいです。
おすすめです。
必要なものを揃えて、使い方まで見える形で渡しましょう。

初案件の取り方と継続・単価アップの導線

最初の一歩は、実績の有無ではなく「触れるデモを持っているか」で決まります。
架空依頼でも、業種を絞ったデモBotを1体つくって公開しておけば、提案文の説得力が跳ね上がり、低単価の応募戦でも通過率を押し上げやすくなります。
受注後は、納品で終わらせず月額保守までつなげて、実績と収益を同時に積み上げましょう。

実績ゼロから作るデモBotポートフォリオ

実績ゼロなら、まず架空依頼を1件設定して業種特化のデモBotを作るのが近道です。
汎用的な社内FAQ風よりも、「不動産店向け」「美容室向け」のように用途を絞ったほうが、見る側は導入後の使い道を想像しやすくなります。
筆者の経験でも、汎用デモを業種特化に作り変えた瞬間に問い合わせが増えました。
応募先が知りたいのは“作れそうか”ではなく、“自社で使えるか”だからです。

公開先は note、GitHub、ポートフォリオサイトの3点セットが基本です。
note で企画意図と工夫を書き、GitHub で実装の中身を見せ、ポートフォリオサイトで誰でも触れる状態にしておくと、提案の途中で離脱されにくくなります。
デモBotは「動く」「読める」「試せる」の3要素がそろって初めて評価されるので、画面だけで終わらせないことがポイントです。

クラウドソーシング・ココナラでの初案件獲得

初案件の入口は、クラウドワークス、ランサーズ、ココナラの3つを分けて考えるとです。
クラウドワークスとランサーズは案件数が多く、まずは実績を増やす場として向いています。
ココナラは出品型なので、自分から営業せずに受注できるのが強みです。
直営業は単価が高い反面、先に信用が要るため、最初の導線としては重すぎます。

ここでの定石は、低単価でも実績を優先して受けることです。
最初の目的は利益最大化ではなく、評価を貯めて次の受注に使える材料を増やすことにあります。
受注率を上げたいなら、提案文にはデモBotのURLを貼って「動くものを見せる」。
さらにヒアリングシートで要件を揃え、積み上げ見積もりで価格の根拠を示し、納期と保守範囲まで明記すると、比較検討の土俵に乗りやすくなります。

月額保守で継続収益化し単価を上げる

初案件は単発で終わらせず、納品直後に月額保守をセット提案すると次につながります。
ナレッジ更新、チューニング、軽微な改修を保守範囲に入れておけば、毎回ゼロから売る必要がなくなり、ストック収益が積み上がります。
実際、丁寧に納品して高評価をもらえた案件は、そのまま同クライアントから月額保守と追加案件に発展しやすい流れがあります。

評価と実績が貯まってきたら、直依頼や単価交渉に移る段階です。
最初は低単価でも、継続提案で関係を深めれば、同じ作業量でも売上の形は変わっていきます。
クラウドワークス初心者でも実績を積めば月5万円以上は十分現実的で、そこから保守を増やしていくと収入の土台が安定します。
おすすめは、受注後の提案までを1セットで考えてみてください。