ノーコードAIアプリ開発ツール『Dify』を使って、LLMにDBのデータ分析をさせてみた！

【IIJ 2025 TECHアドベントカレンダー 12/8の記事です】

始めに

こんにちは。九州支社営業推進課に所属する白川です。

普段はプリセールスエンジニアとして、IIJサービスや生成AI活用の提案を行っています。特に生成AI活用の提案においては、最近話題のノーコードで生成AIアプリを簡単に作れるDifyの導入活用支援を行っています。

今回はこのDify（ディフィー）の簡単なご紹介と、MCP(Model Context Protocol)という仕組みを使って、人の代わりにLLMがDB上のデータを分析できるらしいので、その検証をしてみたいと思います。

Difyとは

一般的に自社専用のAIチャットボットアプリなどを作る場合、Azure OpenAIやAmazon BedrockなどのLLMプロバイダを契約し、アプリ部分は自分でプログラミングする必要があるため、非プログラマーにとっては自由にアプリを作ることが難しいです。

このDifyですが、そうしたプログラミングの手間なく、AIアプリを作れるところが強みになります。DifyはOSSとして公開されており、Dockerコンテナを使うことで簡単にデプロイすることが可能です。

一度デプロイしてしまえば、下図のようにプロンプトを書いてボタンをクリックしていくだけで、用途に応じたAIアプリを構築することができます。

 

（図1：Difyのチャットボット編集画面）

 また複雑なアプリを作りたい場合は、下図のように様々な機能を持つブロックを繋いでいくことでもアプリを作ることができます。学校などで使われているプログラミング教材のScratchみたいな感じですね。

（図2：Difyのチャットフロー編集画面）

このように一昔前までだとチャットボットを作るだけでも非エンジニアには難易度が高かったのですが、Difyを使うことで比較的誰でも簡単にAIアプリを作ることができます。

本日試すこと

さてこのDifyですが、MCP(Model Context Protocol)という仕組みに対応しています。MCPを使うことで、LLMが外部のツールやシステム、データソースなどに簡単に接続できるようになります。

そこでこのMCPという仕組みを使って、Dify上からSQL Serverに接続して、LLMにDBのデータを分析してもらえるか検証してみたいと思います。

Dify環境構成

本検証を行うために下記のような検証環境を用意しました。

• Difyを動かすためのサーバ：Azure Virtual Machines
• LLMプロバイダ：Azure OpenAI(gpt-5-miniを利用)
• SQL Server：Azure SQL Database
• MCPサーバ
  • SQLサーバ接続用：dbhub（https://github.com/bytebase/dbhub）
  • グラフ作成用：AntV(https://github.com/antvis/mcp-server-chart)

MCPサーバは、LLMが各種システムと連携するための通信を仲介・代替する仕組みです。今回は Azure VM を一つ立て、その上に Dify と 2つの MCP サーバ（dbhub・AntV）をそれぞれDockerコンテナで構築しています。

Dify上でLLMにSQL Serverのデータを分析してもらう際の動きのイメージとしては下図のようになります。
※あくまで全体の処理フローのイメージとして捉えてください。細かい挙動は省いております。

（図3：DifyでMCPサーバを使うときの処理フローイメージ）

■ 処理フローの内容

1. ユーザがDifyで指示を出す
2. Dify側で使えるMCPサーバ情報とユーザの指示をLLMに伝達
3. LLMがやるべきことを分析。データ分析のためのSQLを作成し、そのSQLの実行をDifyに作業指示
4. DifyがdbhubにSQL実行を指示
5. dbhubがSQL Serverに対してSQLを実行
6. SQL ServerからdbhubにSQL実行結果を返却
7. dbhubがDifyにSQL実行結果を返却
8. DifyがLLMにSQL実行結果を返却
9. LLMがSQL実行結果から次のアクションを検討し、グラフ作成用データを元にグラフ作成をDifyに指示
10. DifyがAntVにデータを渡し、グラフ作成を指示
11. AntVがグラフ画像ファイルを作成し、Difyに返却
12. DifyがLLMにグラフ画像ファイルを返却
13. LLMがユーザへの回答文を作成
14. Difyの画面上にLLMの回答文（SQL実行結果とグラフ、分析内容）を表示する
15. LLMが深い推論をできる場合、正確な回答を生成するために②~⑬までを何度か繰り返すことがあります。

Dify上でLLMにDBのデータ分析をしてもらう

では実際にDifyでLLMにデータ分析をしてもらいます。下図はDifyで２つのMCPサーバに繋げる設定を行い、SQL Serverに登録されているテーブル情報を質問したときの画像です。

画面左下の「ツール」というエリアに、MCPサーバへの接続設定を追加しています。SQL Serverに接続するための設定として、sql_dbというMCPツールを設定し、グラフ作成用にAntVというMCPツールを設定しています。（AntVは棒グラフや円グラフなど各グラフでツール設定が必要なため、設定しているツール数が多くなっています。）

そして右側の画面では、LLMにDBのテーブル情報を検索させています。図の通り、人間の代わりにLLMがDBを操作してその結果を取得できるようになっています。
※今回サンプルデータとして、SQL Serverの受注・販売管理サンプルデータ「AdventureWorks」を利用しました。

（図4：DifyでMCPを設定した画面）

では、DBに登録されているデータは販売関係のデータなので、小売店をテーマにデータ分析をしてみたいと思います。まずは売上TOP10の商品を分析し、それを棒グラフで表示してもらいます。この指示を出すと、下図のように LLM が SQL を実行し、AntVサーバに棒グラフの作成を指示する様子が確認できます。

（図5：LLMが生成したSQLの実行と、棒グラフ作成の指示のログ）

そして結果は下図のようになります。AntVサーバは、情報を渡すと棒グラフなどの画像を返却します。
※ AntVはデフォルトだと画像をbase64エンコードしてテキストで返却してくるため、画像リンクで返却するようにコンテナを一部修正しています。

（図6：LLMによるデータ分析結果）

（図7：LLMの回答文内のリンクを開いた結果）

また、下図のように小売業で使われるようなABC分析やバスケット分析のような高度な分析もLLMに依頼することで自動実行してくれます。

（図8：ABC分析の結果と生成された円グラフ）

（図9：ABC分析でAクラスに分類された商品一覧）

（図10：LLMによるバスケット分析の結果）

 終わりに：LLMにデータ分析をさせてみた感想

ということで、実際にLLMにDB内のデータ分析をしてもらいました。感想ですが、自然言語だけでデータ分析できるのは非常に楽だなと感じました。

これまではDBの操作をするために、SQLクライアントなどを立ち上げて、手動でSQLを作成・実行する必要がありました。そういった操作を行わずに、チャットボット上で自然言語を入力するだけでできるので、かなりの業務改善効果がありそうです。

今回は商品の売上データの分析にしか使いませんでしたが、DBのテーブル設計やチューニングといった作業についても、AIの支援が有効なのではないかと感じました。

またSQLの知識がない方でも自然言語でDBから複雑なデータを取得できるため、旧来のBIツールと組み合わせることで、より高度な分析を誰もができるようになりそうです。経営ダッシュボードのように全体像を一目で把握したい場合はBIツールで、より詳細な個別分析を行いたい場合はこうしたAIツールを活用する、みたいな役割分担になっていくのかもしれません。

まとめとなりますが、これまでDBのデータ分析に苦労されていた方は、このようなことを一度ぜひ試していただければと思います。

（余談1）LLMのデータ分析を完全に信用できるか

上述の通り、LLMを使うことでデータ分析が簡単になるかも、というお話をさせていただきました。ただ、皆様も既に疑問に持たれているかもしれませんが、「LLMが行った分析結果って本当に合っているの？」という問いは変わらず持ち続ける必要があるのだろうなと思っています。

データ取得にあたりSQLを実行しているので、DBから取得したデータは正確です。ただ、LLMがSQL文の作成を誤ったり、SQL実行結果の解釈を間違えたりする可能性は今後も残ると思われます。

つまり、データ分析を実行すること自体は今後非常に簡単になってくるものの、その結果が正しいかを検証をするのは私たち側の仕事、というのは変わらず残ることになります。これらの課題に対しては、今回のような便利なツールを活用しつつ、実務を通じて少しずつ知見を貯める必要があるのかなと思っています。

ちなみに下図は先程のバスケット分析で使用されたSQL文です。見た瞬間「？？？？」となりましたので、この結果が正しいかどうかを判断するためには結局自分でバスケット分析を学ぶしかないのだ、という感想を持つことになりました。

（図11：LLMが作成したバスケット分析用のSQL。SQLが全く分からない。）

（余談2）LLMにDBを操作させて大丈夫なのか

さて、ここまで触れてきていませんでしたが、LLMにDBを操作させるのは危険ではないのか、勝手にデータを削除するのではないのか、という懸念を持たれる方もいると思いますので、そのお話にも触れたいと思います。

今回使っているdbhubはreadonlyオプションが用意されてあり、サーバの仕組み上、デフォルトでSELECT文以外の実行ができないようになっています。そのため、今回の検証ではそういったDBに変更を加えるような懸念を持たずに操作をすることができました。本番環境で利用する際は、dbhubのreadonlyのような設定だけでなく、接続するDBユーザ自体の権限も参照専用（SELECTのみ）に絞るなど、多層的な防御を行う必要がありそうです。

とはいえ、本当にLLMがデータを削除しないのかというのを検証してみたいと思います。下図は最も売れている商品データの削除を命令した結果です。

今回に関しては、プロンプトに入力している「InsertやUpdate、Deleteなどのデータベースに変更を加える処理は禁止です。」という文言が効いているのか、そもそもLLM側でDelete文の実行を止めてくれたようです。

（図12：プロンプト指示でDelete文を禁止した場合）

では次に「InsertやUpdate、Deleteなどのデータベースに変更を加える処理は禁止です。」という文言を消して再度同じ命令を出してみます。プロンプトでDeleteを禁止はしていないため、LLM側が色々な削除方法を考えて、最後にDelete文まで発行しています。ただ、今回はDBhub側でreadonlyオプションがあるため、SQLの実行が失敗する結果となっています。

（図13：禁止指示なしでDeleteを依頼した場合）

（図14：LLMがDelete文自体は実行できてしまうが、dbhub側で拒否される）

このようにLLMは忠実に人から与えられた指示を実行しようとするため、DB側やMCPサーバ側で何かしらの制限を行う必要があります。プロンプトによる制御も可能ですが、それが常に確実に機能するとは限らないため、仕組みで防ぐ必要があります。
※ とはいえ、最近のLLMは優秀なため、プロンプト側でDelete文の実行を禁止しておくと、どんなにお願いしてもDelete文は実行してくれませんでした。少し前までは、（悪い意味で）LLMが融通を利かせてくれるとのことだったのですが、進化しているのだなと学びを得ることができました。