まず最初に Dify を構築して検証したログはこちら。
生成AIが流行り始めて少し経った頃、会社でも例に漏れず「AIを使いなさい」という話が降ってきた。
ただ、「使え」と言われても、実際にどう使わせるかが一番難しい。
ChatGPTを全員分契約すれば手っ取り早いが、何十人分ともなるとそれなりの金額になる。
しかも、業務でどれくらい効果が出るのかもよく分からない。
いきなりコストをかけて失敗するのは避けたい。
そこで考えたのが、「OpenAI APIを使って社内用のフロントを用意する」という形だった。
APIであれば、最小コストで始められるし、使われ方を見ながら調整もできる。
問題は、そのフロントをどう作るかだった。
フロントを自作するのは現実的じゃない
最初は簡単なWeb UIを自作しようかとも考えたが、
認証、履歴管理、プロンプト管理、権限管理……と考え始めるとキリがない。
「これはOSSに頼ったほうがいいな」と思い、色々探して見つけたのが Dify だった。
RAG構築、ワークフロー管理、UIまで一通り揃っている。
記事や紹介動画を見る限り、「これ1つで全部できる」ように見えた。
正直、この時点では「かなり良さそう」という印象しかなかった。
Dify を構築して検証
まずは検証用として、VPS上に Dify を立ててみる。
git clone https://github.com/langgenius/dify.git
cd dify/docker
docker compose up -d
このあたりは比較的素直に立ち上がる。
細かい設定調整や環境変数の調整は多少必要だったが、
「OSSとしてはかなり親切なほうだな」という感触だった。
実際に触ってみると、
- RAG構築ができる
- ワークフローが組める
- 管理画面も分かりやすい
と、機能面ではかなり充実している。
「これは本格運用いけるかも」と思い、数人に使ってもらう形で検証を始めた。
実運用で感じた違和感
ただ、使ってもらう中で、徐々に違和感が出てきた。
一番大きかったのが、ユーザー向けUIの使い勝手。
- 会話履歴の管理が弱い
- 過去のやり取りを振り返りづらい
- プロンプトの整理・管理がしにくい
業務利用では、「昨日何を聞いたか」「前回どんな回答だったか」を
後から見返せることがかなり重要になる。
その点で、DifyのUIはどうしても管理者寄りというか、
エンドユーザー向けとしては少しクセが強い印象だった。
また、RAGの構築も思っていた以上に手間がかかった。
データ整形や分割調整など、検証とはいえ、
ひとり情シスで回すにはそれなりに負荷が高い。
「高機能だけど、運用コストが重たい」
これが正直な感想だった。
そもそも社内に必要だったものは？
ここで一度、冷静に考え直した。
会社に、今本当に必要なのは何か。
結論はシンプルで、
まずは“普通に使えるチャット環境”だった。
多くの社員は、まだAIに慣れていない。
高度なRAGやワークフローより、
- 本家ChatGPTに近いUI
- 迷わず使える操作感
- 会話履歴が自然に残る
こういった「当たり前に使える体験」のほうが圧倒的に重要だった。
OpenWebUI への切り替え
そこで見つけたのが OpenWebUI。
初めて触ったとき、「あ、これなら説明いらないな」と思った。
UIは本家ChatGPTにかなり近く、操作に迷うポイントがほとんどない。
試しに構築してみる。
docker run -d \
-p 3000:8080 \
-v openwebui:/app/backend/data \
--name openwebui \
ghcr.io/open-webui/open-webui:main
驚くほどあっさり立ち上がる。
数人に使ってもらうと、反応はかなり良かった。
- 「普通に使える」
- 「前のより分かりやすい」
- 「これなら業務で使えそう」
この時点で、方向性はほぼ固まった。
Dify を捨てる判断の迷い
正直、ここまで時間をかけて構築した Dify を止めるのは迷った。
RAG検証も途中だったし、「もう少し頑張れば…」という気持ちもあった。
ただ、
- 利用率
- 運用負荷
- 社内への説明コスト
を考えると、OpenWebUIのほうが圧倒的に現実的だった。
「高機能だけど使われない」より「シンプルで使われる」
最終的に、この判断軸に落ち着いた。
切り替えてからの今
OpenWebUIへ切り替えてから、
少しずつだが社内でAIを使う人が増えてきた。
- 調べ物
- メール文案
- 資料の下書き
- 簡単なコード相談
派手ではないが、「業務の横にAIがある」状態が作れつつある。
今はこれで十分だと思っている。
RAGや高度な仕組みは、
使う文化が根付いてからでいい。
いきなり完璧を目指すと、だいたい失敗する。
今回の判断で学んだこと
今回一番強く感じたのは、
社内向けシステムは「高機能」より「使われる」が正義
ということ。
情シスは、どうしても技術的に優れた構成を選びたくなる。
だが、実際に触るのはエンドユーザーだ。
「自分が満足する構成」より、
「現場が迷わず使える形」。
Dify は、AI基盤として非常に優秀なOSSだと思う。
ただ、今の会社には早かった。
しばらくは OpenWebUI で「まず使う」フェーズを回す。
必要になったら、また次の選択をすればいい。
ひとり情シスの仕事は、
正解を選ぶことではなく、その時点で一番マシな選択をし続けること
だと、改めて感じた。
実際に OpenWebUI を社内向けに使える形にするため、
Portainer + Keycloak を使って、GUI管理 + SSO構成にしました。
その構成と構築ログは、次の記事にまとめています。
この環境の構成まとめ
次の記事
