業務で AI を使う環境を作るにあたって、
最初から「これが正解だ」と思える構成があったわけではありません。
むしろ、
- まずは Dify を触ってみる
- 実運用を考えて OpenWebUI に切り替える
- 人数が増える前提で SSO + GUI 管理構成まで作り込む
という形で、現場で使いながら構成を変えていった結果が今の形です。
この記事では、その流れを 3本の記事を軸にまとめて整理します。
「AI フロント環境を業務用で作ると、結局こういう構成に落ち着いた」という、
ひとり情シス目線の実務ログまとめです。
最初は Dify で検証した
最初に選んだのは Dify でした。
理由はシンプルで、
- OpenAI API を すぐ試せる
- フロント UI が揃っていて 構築が楽
- 業務検証用として ちょうどよい重さ
このあたりです。
正直なところ、
「まず触れる」「動かして検証する」ことが最優先だったので、
この段階では拡張性や長期運用はそこまで深く考えていませんでした。
実際にやった構築内容や、検証して感じたことは、こちらの記事にまとめています。
ここで、
- API の扱い
- 業務利用時のレスポンス感
- 社内での使われ方
このあたりを一通り確認できたことで、
「業務で使える」という感触は掴めたのが大きかったです。
運用を考えて OpenWebUI へ切り替えた
しばらく Dify を触っているうちに、
次のような点が気になり始めました。
- UI の細かいカスタマイズが難しい
- 複数人利用時の管理が少し重い
- 将来的な運用を考えると、もう少し軽い構成が良い
そこで検討し直して選んだのが OpenWebUI です。
決め手は、
- とにかく軽い
- Docker で管理しやすい
- フロント用途に割り切れる
という点でした。
この切り替え判断と、実際の構築ログは以下にまとめています。
このあたりから、
「検証環境」 → 「業務運用前提」
という意識に切り替わってきた感じがあります。
OpenWebUI + Portainer + Keycloak 構成へ
OpenWebUI を使い始めてから、
さらに業務寄りに構成を詰めていった結果、最終的にこうなりました。
- OpenWebUI：AI フロント
- Portainer：Docker 管理
- Keycloak：SSO（シングルサインオン）
ひとり情シス環境では、
- コンテナ管理を GUI で完結
- 認証を SSO で一元管理
この2点があるだけで、運用負荷がかなり下がります。
構築ログと、実際に使ってみて感じたことは、こちらにまとめています。
この構成にしてから、
- コンテナの更新
- ログ確認
- ユーザー管理
このあたりが 一気に楽になった印象です。
全体構成のまとめ
最終的な流れを整理すると、こんな感じです。
- Dify で API フロントを検証
- OpenWebUI に切り替えて軽量化
- Portainer + Keycloak で運用管理を強化
結果として、
「とりあえず動かす」
→「実際に使う」
→「業務で回す」
という 段階的な構成進化になりました。
最初から完成形を作ろうとすると、
たいてい設計で止まります。
でも、
- まず動かす
- 使いながら直す
- 問題が出たら構成を変える
この流れで進めると、現実的な構成に自然と落ち着く気がしています。
これから同じ構成を作る人へ
この構成は、
- ひとり情シス
- 中小企業の社内SE
- 少人数運用
このあたりの環境には、かなり相性がいいと思います。
大規模構成ほどの堅牢性はありませんが、
- 運用が楽
- トラブル対応しやすい
- 全体を把握しやすい
このバランスが、現場では一番大事だったりします。
関連記事まとめ（構築ログ一覧）
今回の構成に関する記事は、以下の3本です。
構築や運用で詰まった場合は、個別記事のほうが具体的です。
