OpenAI APIのフロントとしてDifyを構築して検証した話|ひとり情シスの実務ログ

生成AIが流行りだして、しばらく経った頃。
会社でも、例に漏れず「AIを業務に使いなさい」という話が出てきた。

とはいえ、「使え」と言われても、どう使わせるかが一番難しい。

全社員分のChatGPTアカウントを契約するとなると、そこそこのコストになるし、
実際にどれくらい業務効率が上がるかも読めない。

まずは 安価に、小さく試したい。

そう考えたときに思いついたのが、

OpenAI API + フロントエンド

という構成だった。


APIを直接使わせるのは現実的じゃない

APIを叩けば、社内向けのAIツールは作れる。
理屈では簡単だけど、実際にフロントを作るとなると、結構めんどくさい。

  • 認証どうする?
  • 利用制限どうかける?
  • ログ管理どうする?
  • UIどうする?

社内向けの「お試し」ツールに、ここまで作り込むのは正直しんどい。

「既にあるOSSで、ちょうどいいのないかな…」

と探していたときに見つけたのがDify だった。


Difyを知って「これでいいじゃん」と思った

Difyの記事をいくつか読んでみると、

  • OpenAI APIのフロントになる
  • RAG対応
  • 管理画面あり
  • Dockerで簡単構築

と、まさに求めていた構成。

「これは一度、業務検証で立ててみるか」

ということで、検証用サーバに構築することにした。


VPSで検証環境を用意

検証用なので、コストと手間を抑えたい。

今回は、普段からXServer VPS をそのまま利用した。
必要なときにすぐ立てられて、不要になったら潰せるのが楽。

OSは Ubuntu 24.04。
Docker構成でサクッと入れる。

実際に打ったコマンドはこんな感じ。

apt update && apt upgrade -y
apt install -y docker.io docker-compose-plugin git
git clone https://github.com/langgenius/dify.git
cd dify/docker
docker compose up -d

10分もかからず、管理画面が立ち上がった。

この辺は、正直かなり楽だった。


実際に使ってみて感じた「すごさ」と「違和感」

Difyの一番の魅力は、RAG構成を簡単に作れる ところ。

社内のマニュアルPDFを食わせて、
「この資料から答えて」みたいな構成を、ほぼノーコードで作れる。

これは確かにすごい。

ただ、しばらく触っているうちに、少しずつ違和感も出てきた。

  • ユーザーUIに会話履歴やプロンプト管理が無い
  • フローの設定が多く、調整が面倒
  • RAGの精度調整が地味に難しい
  • メモリ使用量が思ったより多い

特に、サーバースペックの消費が結構大きい のが気になった。

「検証用だからまあいいか」と思っていたが、
本番運用を考えると、もう少し軽い構成が良さそうだな…という印象。


フロント用途としては、ちょっと重い

一番の目的は、

社内で手軽にAIを触れるフロント

だった。

でも、Difyは

  • RAG
  • アプリ管理
  • ワークフロー
  • プロンプト管理

など、かなり多機能

逆に言うと、

フロント用途としてはオーバースペック気味

に感じた。

「フロントとして、もっと軽くてシンプルなの無いかな?」

と考え始めたのが、この検証の次のフェーズになる。


それでもDifyを立てて良かったと思う理由

結果的に、Difyは後に別の構成に置き換えることになる。

ただ、この検証は無駄だったかというと、まったくそんなことはない。

  • RAGの構成イメージが掴めた
  • 社内AI活用の現実ラインが見えた
  • サーバースペック感覚が分かった
  • 「やりすぎ」の境界が分かった

特に、

最初は、あえて多機能なものを触る

というのは、判断基準を作る上でかなり役立った。

いきなり軽量ツールから入っていたら、
ここまでの視野は持てなかったと思う。


ひとり情シス的には「まず立ててみる」が一番早い

正直、記事を読んで悩むより、

立てて、触って、壊して、捨てる

このサイクルを回す方が、圧倒的に早い。

そのためにも、
VPSのように「すぐ立てられて、すぐ潰せる」環境はかなり助かる。

個人的には、検証用途では Xserver VPS のこの手軽さがちょうど良い。

高性能すぎず、安すぎず、
「業務検証にちょうどいい」バランス感。


今回のまとめ

  • 社内AI活用の第一歩として、Difyを構築
  • RAG含めた多機能構成を体験
  • フロント用途としては、やや重いと感じた
  • でも「基準作り」としては、かなり良い検証だった

このあと、しばらく運用してみた結果、
「これはこのまま社内フロントとして使うのは厳しいな…」と感じる点も出てきました。

そのあたりの試行錯誤と、最終的に OpenWebUI に切り替えた判断 は、次の記事にまとめています。


この環境の構成まとめ

Dify → OpenWebUI → SSO 構成まで。業務用 AI フロント環境を VPS 上で作った全体ログまとめ
業務で AI を使う環境を作るにあたって、最初から「これが正解だ」と思える構成があったわけではありません。むしろ、まずは Dify を触ってみる実運用を考えて OpenWebUI に切り替える人数が増える前提で SSO + GUI 管理構成...

次の記事

Difyを構築して検証 → OpenWebUIへ切り替えた判断ログ|社内AI導入のリアル
まず最初に Dify を構築して検証したログはこちら。生成AIが流行り始めて少し経った頃、会社でも例に漏れず「AIを使いなさい」という話が降ってきた。ただ、「使え」と言われても、実際にどう使わせるかが一番難しい。ChatGPTを全員分契約す...