はじめに
「社内における生成AI活用推進」をチームで進める一環としてOSSツール Open WebUIを採用しました。
Open WebUIの採用理由などについては弊チームデザイナー@wc-nakagomiさんの記事をご覧ください。
まずは Open WebUI を動かしてみたいという方は上記記事に簡単な手順が記載されています。
この記事では、Open WebUI を弊社の社内向けAIチャットツールとして最適化するために行ったカスタマイズについてまとめます。
対象読者
- 生成AIを活用した業務効率化に関心のある方
- docker-composeやコンテナ技術、Pythonなどの基本的な知識がある方
Open WebUIの社内向け設定
今回は社内向けにセキュアでかつ、独自にRAG機能やモデルの追加が可能なLLM環境を構築するため、 docker-compose.yaml などの設定ファイルを必要に応じて追記変更をしていきました。
OneLoginを介したセキュアな設定
弊社で利用しているOneLoginを介してのみログインして利用可能にするための環境変数などの設定を open-webui サービスに追加しています。
また、このサービスの設定内で、データ永続化のためにDATABASE_URLの向き先をデフォルトのSQLiteからPostgreSQLに切り替えています。
open-webui:
image: XXXXXXXXXX:latest
container_name: open-webui
volumes:
- open-webui:/app/backend/data
depends_on:
- open-webui-pipeline
ports:
- 3000:8080
environment:
- 'OPENAI_API_KEY=XXXXXXXXXX'
- 'DATABASE_URL=postgresql://XXXXXXXXXX'
- 'ENABLE_OAUTH_SIGNUP=true'
- 'OAUTH_CLIENT_ID=XXXXXXXXXX'
- 'OAUTH_CLIENT_SECRET=XXXXXXXXXX'
- 'OPENID_PROVIDER_URL=https://XXXXXXXXXX'
- 'OAUTH_PROVIDER_NAME=Onelogin'
restart: unless-stopped
これらの環境変数を使ってOAUTHログイン設定をしOneLoginを介したログインのみに制限します。
Open WebUI 側のログイン画面実装は、初回の管理者アカウント登録時のみ通常のアカウント登録ができるようにし、それ以降は全てOneLoginを介したログインのみになるよう制御しています。
ログインgを例に挙げると プロジェクトルート/src/routes/auth/+page.svelte を下記の実装例のように修正することで変更ができます。
<!-- 初回時は表示する -->
{#if $config?.onboarding ?? false}
通常のEmail/Passwordフォームでログイン・アカウント登録処理
{:else}
OneLoginのOpenID Connect（OIDC）で認証処理
{/if}
$config?.onboarding で初回時かどうかの判定ができます。
同様に、社内LLMとしての利用では過剰な機能などは独自に修正を行っていきます。
独自のパイプラインを追加するための設定
Open WebUI は 公式で公開されているパイプライン を通じて、APIキーを設定するなどの簡単な操作のみで設定画面からGeminiなどのモデルを追加することができます。
公式にないモデルや独自に連携がしたい場合はパイプラインを自作して追加することができるので、今後 Vertex AI Search などの連携ができるようパイプラインの設定を入れます。
open-webui-pipeline:
image: ghcr.io/open-webui/pipelines:main
container_name: open-webui-pipeline
volumes:
- pipelines:/app/pipelines
ports:
- 9099:9099
restart: unless-stopped
environment:
- 'GCLOUD_PROJECT=${GCLOUD_PROJECT}'
カスタムパイプラインは設定画面からPythonファイルを読み込む方法と プロジェクトルート/backend/data/pipelines 配下に独自にパイプラインのPythonファイルを配置することでも、Open WebUI 起動のタイミングで読み込ませることができます。
公式で公開されているパイプラインをGitHubのURL経由で設定画面から追加した場合も、そのPythonファイルが プロジェクトルート/backend/data/pipelines に追加されます。
カスタムパイプラインの実装は基本的に公式のパイプラインの作りを参考に作成できます。
（Pipelineクラスの中でValvesやpipeを定義して処理を記載）
下記のGoogle Geminiパイプラインの例にあるように、
Pipelineクラスの中でValvesやpipeを定義して処理を実装していきます。
RAG機能をより活かすための設定
Open WebUI では管理者設定ワークスペースからモデルやナレッジベースを登録することで、下記例のように独自のRAGを簡単に作ることができます。
その際に独自のファイルを読み込ませてモデルやナレッジベースを作っていくのですが、Apache Tika を導入することで、テキストやPDFファイル読み込み時の認識精度を上げ、結果としてRAGの精度向上を行っています。
tika:
image: apache/tika:latest-full
container_name: tika
ports:
- 9998:9998
restart: unless-stopped
Apache Tikaを使える状態にしたら、管理者パネルのドキュメント設定からTikaを使用できるように設定できます。
LangFuse導入
今回導入した社内向けAIチャットツールの利用状況やコストを可視化するツールとして LangFuse の導入も併せて行いました。
LangFuseのパイプライン も公式で公開されており簡単に導入が可能です。
パイプライン設定でGitHubからLangFuseを追加して、LangFuseのプロジェクトで取得した Secret Key, Public Key, Host の設定をするだけで利用状況のモニタリングが可能になります。
下記がテスト環境でのモニタリングダッシュボード表示例です。
LangFuseは現状利用状況の確認程度でしか利用できていないので、今後より詳細な分析などに活用したいと考えています。
おわりに
弊社では Open WebUI を社内向けに独自にカスタマイズすることで、一般的なAIチャットツール活用方法に加えて、社内規程や制度、自社サービスなどのナレッジを持ったRAGを活用して業務効率化を進めています。
今後は社内独自のモデルやナレッジベースをより拡充し、評価分析による社内での利用モデルの最適化を進めていき、更なる業務効率化の手助けとなるツールにしていきたいと考えています。