コード生成AIアプリのお問い合わせフォームをDifyで作ってみた – 導入・実験編 –

背景

2025年の暮れ、コード自動生成や脆弱性診断ができる生成AIアプリを開発しリリースしました。

※コード生成AIアプリ：生成AIを活用した設計、製造、テスト、運用業務効率化を目的とするAIアプリ。社内で評価中。

「これで一区切り！」……と思ったのですが、運用の現実が待っていました。

あ、お問い合わせ導線がない。

とりあえず、Formsで簡易的なお問い合わせフォームを作ることでいったん乗り切りましたが、いくつか課題が残りました。

従来のこういうアンケート形式だと

• ユーザーが問い合わせ種別や対象機能などを選ぶ必要があり、入力のハードルが高い
• 全件を担当者が目視で確認する必要があり、一次対応の負荷が大きい
• “ちょっと聞きたい”レベルの質問が流れにくい

など

そこで今回は、Difyを使って コード生成AIアプリ専用の問い合わせチャットボット を作ってみることにしました。

今回のゴールは以下の通り

• ある程度の質問はAIが即時に返答する
• 必要な問い合わせはチームへ通知できる形にする（※この記事では導入まで）
• ユーザー操作はできるだけ最小限にする

そもそもDifyってなに？

Difyは、ChatGPTのような大規模言語モデル（LLM）を使ったアプリを、ノーコード／ローコードで組み立てられるプラットフォームです。

UI上で「ノード」をつないで処理の流れを作れるので、チャットボットや文章生成アプリ、ツール連携を含む簡単なエージェントを比較的スピーディに構築できます。

たとえば、次のようなことが得意です。

• チャットボットの構築：FAQ対応、社内ヘルプデスク、問い合わせ一次受けなど 
• 文章生成・整形：テンプレメール作成、要約、レポート下書き、文章校正など 
• ワークフロー化：入力の分類 → 参照（ナレッジ検索） → 生成 → 出力整形…のように、LLM前後の処理も含めて設計できる 
• 外部連携：APIやWebhookを絡めて、通知やチケット起票など運用フローに接続できる（※本番運用で効いてくるところ）

つまり、今回のようなコード生成AIアプリの問い合わせチャットボットをパパッと作ろう、というユースケースには向いているわけですね。

さっそく触ってみます。

Dify導入へ

まず、Difyにはローカル版とクラウド版があります。

クラウド版

メリット

• 公式サイトにログインするだけで使える
• チームメンバーの招待が簡単で、共同作業をスムーズに始められる

デメリット

• コードレベルのカスタマイズには対応していない
• Sandboxプランを選択すれば無料で使えるが、厳しめの機能制限がある。

　　一方で、機能制限が緩くなるProfessionalプランだと月額59ドルかかる

ローカル版

メリット

• データを自社管理下で扱えるため、セキュリティ要件に合わせやすい
• コード生成AIアプリとの連携（ネットワーク・認証など）を含め設計しやすい

デメリット

• Docker前提で、セットアップや運用の手間は増える

今回のユースケースでは、社内AWS環境に載せてコード生成AIアプリと連携する想定だったのでローカル版を選択しました。

Dockerで立ち上げて docker compose up すれば、導入自体はスムーズでした。

起動してログインするとこのような画面になりました。

実験してみる

最初から作成を選択するとまずアプリタイプの選択や、アプリの名前などを入力する画面が表示されます

今回はチャットフローを選択

初期画面はこんな感じです。

視覚的にノードをつないでいくことでチャットボットの構築ができるようです。

まずはOpenAIのプラグインをインストールします。

自前のAPIキーを持ち込んで使用することができます。

実験的に簡単なチャットボットを構築してみます。

今回の実験では、質問のタイプで分岐させる構成にしました。

• まずユーザー入力を受け取る
• 入力を「検索で即解決しそう」か「整理・推論が必要」かに分類する
• 前者は定型メッセージ、後者はLLMで回答する

ノード構成と役割

ユーザー入力

開始ノードです。ユーザーの入力内容をここで処理します。いわゆるスタート地点です。

ユーザーが打ち込んだテキストを受け取り、後続ノード（質問分類器）に渡します。ここでは余計な加工をせず、原文のまま次へ送るのが基本になります。

• 役割：入力の受け口
• 出力：ユーザーの発話テキスト（以降のノードが参照する素材）

質問分類器

このフローの肝です。GPT-4（Chat）を使って、入力を2クラスに分類しています。

• クラス1：ブラウザで検索しても分かりづらい／整理や推論が要る内容（＝LLM向き） 
• クラス2：ブラウザで検索すればすぐ分かりそうなこと（＝定型返答で誘導） 

分類器を入れることで、「全部LLM回答」になりがちなチャットボットを、用途に応じて賢く出し分けできるようになります。

LLM

分類でクラス1に入ったものだけが、このノードに流れます。

ここではGPT-4（Chat）で、質問に対する本文回答（生成テキスト）を作ります。

分類器と同じモデルを使っていても構いませんが、役割は別物です。

• 分類器：短い判断（ルーティング）
• LLMノード：本文生成（アウトプットの中身）

という住み分けになります。

回答

分類でクラス2（検索すれば分かりそう）になったときの出口です。

スクリーンショットでは 「Googleで検索してみては？」 という固定メッセージを返す構成になっています。

回答2

こちらはクラス1側の出口です。

中身は固定文ではなく、直前のLLMノードが生成したテキストを変数参照で差し込んで返す形になっています。

つまりこのノードは、生成そのものではなく、「最終的にユーザーへ返す形に整えて出力する」役目です。

動作確認

プレビューボタンから作成したフローを試せます。

「検索ですぐ分かりそうな質問」と「整理が必要そうな質問」をそれぞれ投げてみると、想定どおり出力パターンが分岐することを確認できました。

最後に

Difyは、ノーコードでチャットフローを組めるので、実験→改善のサイクルが回しやすいのが印象的でした。

導入のハードルも（ローカル版でも）思ったより高くなく、まず試すにはちょうど良い選択肢だと思います。

次回は、コード生成AIアプリ向けに実運用するにあたって使ったノード（通知・外部連携など）や、運用設計の工夫についても紹介する予定です。