研究室専用AIを作る第一歩

本記事は「研究室で生成AIを運用する基盤」を構築するメモシリーズの第1回です。
技術的には一周遅れで今更感もありますが、どう考えて導入してるかなどは意外とないので、メモを兼ねて公開します。
単なるインストール方法の記事は巷に溢れてるので、どちらかと言えばどう使うかという考え方に重点を置きたいと思います。
今回は OpenWebUI + LiteLLM
を用いて、研究室専用AIをブラウザから利用できる環境を構築し、用途別のカスタムモデルを作成するところまでを扱います。

第1回：研究室で管理しやすい学生用AIハブの導入(⇦この記事)
第2回：カスタムモデルで「良いAI活用方法」を埋め込む
第3回：プロジェクト単位ナレッジ管理のコンセプトとインデックス機能の実装
第4回：プロジェクト単位ナレッジ管理の検索・登録機能の実装
第5回：もう一つのナレッジとしてのAIエージェント（公開予定）
第6回：ユースケース：引き継ぎ資料の作成支援AIとプロジェクトナレッジとしての利用（最終回予定）

はじめに

生成AIは、いい意味でも悪い意味でも、研究や教育の現場に急速に浸透しています。
学生にとって今やAIを使うことが当たり前で、悪意もなく無意識にAIを利用しています（Googleで検索すればGeminiの回答が先頭に出る）。

禁止しても無意識に使う環境にあるなら、むしろ積極的に研究室の公式AI基盤を整備して、好ましい使い方ができるように誘導する方法について考えました。

今回は、まず研究室でAI基盤を運用しようとしたときに最初にぶつかる問題である、課金管理の問題について検討しました。研究室全体で運用しようとすると、次のような課題が見えてきます。

多くのサービスはユーザーごとのシート課金
実際の利用者が少なくても毎月固定費が発生する
学生の入れ替わりのたびにライセンス管理が必要
研究室では利用頻度にばらつきが大きく、固定課金が割に合わない

研究室では「毎日研究についてAIに相談したい学生」もいれば、「発表や論文執筆だけ相談したい学生」、そもそも「研究活動が完全に停止している学生」もいます。このような環境では、シート課金は合理的でなく従量課金の方が適しています。従量課金が割に合わないほどヘビーに利用する学生が出てくれば、（使い方が適切であればですが）別途シート課金のAIのメンバーにすればいいことです。
ところが、研究室単位で従量課金を前提としたAIサービスは意外と少ないのが現状です。さらに、内容によっては外部のAIに相談できない場合もありローカルLLMも検討したいところです。

今回のゴールは、学生がブラウザから研究室専用のチャットAIを利用できる環境を作ることで、研究室側から見れば従量課金で使った分だけの支払いにして、どのAIサービスを使うか、あるいはローカルLLMをつかうかは管理者が設定して、利用者である学生はどのAIでも統一したインタフェースで使えるようにします。

AIエージェント、ナレッジベース、SSOの認証基盤などはまた別の回に述べます。

なお、以下の話は、基本的に各社AIサービスの従量課金のAPI利用でAIを利用することを想定していて、それぞれの従量課金契約をして対応するAPIキーを取得済みであることを前提とします。

本シリーズで目指すもの

本シリーズが目指すのは、「ChatGPTの代替サービス」を作ることではありません。

用途ごとに役割を持ったAIを用意し、研究室全体で共通に利用できる環境を整備することです。

例えば、

プログラミング支援AI
論文添削AI
TA AI
アイデア発想AI

といったAIを用途別に用意し、学生は「どのモデルを使うか」ではなく、「何をしたいか」でAIを選べるようにします。

システム構成

今回構築する構成は次のとおりです。

利用者
   │
ブラウザ
   │
OpenWebUI
   │
LiteLLM
   ├── OpenAI
   ├── Gemini
   ├── Claude
   └── ローカルLLM

OpenWebUIはさまざまなAIサービスのAPIを束ねて、チャット画面を提供するHubとして機能し、LiteLLMは各LLMのAPIを統一的に扱うプロキシとして動作します。
各社のAIサービスについてAPI利用の従量課金契約をしており、APIキーを取得済みであるものとします。

なぜLiteLLMを使うのか

OpenWebUIだけでもHub機能があり各社APIへ接続できます。
しかし研究室運用ではLiteLLMを挟むメリットが大きくなります。

APIキーを一元管理できる
OpenAI互換APIとして統一できる
モデルの追加・変更をLiteLLMだけで行える
ローカルLLMも同じ仕組みに追加できる

研究室では「運用しやすさ」が重要です。その意味でLiteLLMは非常に相性の良い構成です。

今回扱う範囲

今回は次の内容までを扱います。

OpenWebUIの導入
LiteLLMの導入
API接続
カスタムモデルの作成
システムプロンプトの設定
パラメータ設定

以下は次回以降で扱います。

AuthentikによるSSO
Knowledge / RAG
VSCode Agent・Continueとの連携
ローカルLLM
権限管理

OpenWebUI + LiteLLM のインストール

ここから実際にOpenWebUIとLiteLLMを構築していきます。

OpenWebUIやLiteLLMには複数のインストール方法がありますが、ここでは導入・管理がしやすいDocker Composeで構築します。

詳細なオプションや最新版の情報については公式ドキュメントを参照してください。

ここでは、研究室AI基盤として利用するために必要な最小構成を作成します。

ディレクトリ構成

今回は次のような構成にします。

lab-ai/
├── docker-compose.yml
├── .env
├── openwebui/
└── litellm/
    └── config.yaml

役割は以下の通りです。

docker-compose.yml
- OpenWebUIとLiteLLMの起動設定
.env
- APIキーや管理用パスワード
litellm/config.yaml
- 利用するLLMモデル設定

共通の環境変数の設定

まず共通で使用する環境変数を設定します。

APIキーなどの秘密情報は直接設定ファイルには書かず、.envで管理します。.envのPermissionにも注意してください。600で、ルート以外書き込みはもちろん閲覧も禁止にしておきます。

# ===== LiteLLM =====
# LiteLLMの鍵、実際の鍵に書き換える
LITELLM_MASTER_KEY=lab-ai-master-key

# ===== Open WebUI =====
# OpenWebUIのURLと初期設定用の管理者キー
WEBUI_URL=http://lab-ai.local
WEBUI_SECRET_KEY=******

ENABLE_SIGNUP=true
ENABLE_OPENAI_API=true
# ===== LLM Provider API Keys =====
# 各種AIのAPIキーを書いておく
OPENAI_API_KEY=sk-*********************************
GEMINI_API_KEY=AIza********************************
ANTHROPIC_API_KEY=sk-********************************

ここで重要なのが LITELLM_MASTER_KEY です。
これはOpenAIなど外部サービスのAPIキーではありません。
LiteLLM自身へアクセスするための認証キーです。

つまり、

OpenWebUI
    |
    | OPENAI_API_KEY
    v
LiteLLM
    |
    | 実際のAPIキー
    v
OpenAI / Gemini / Claude

という関係になります。

docker composeの設定

docker composeで、litellmとopenwebuiが起動するように設定します。

services:
  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    ports:
      - "4000:4000"
    volumes:
      - ./litellm/config.yaml:/app/config.yaml
    command:
      - "--config=/app/config.yaml"
    env_file:
      - .env

  open-webui:
    image: ghcr.io/open-webui/open-webui:v0.9.4
    ports:
      - "3000:8080"
    volumes:
      - ./open-webui:/app/backend/data
    environment:
      OPENAI_API_BASE_URL: http://litellm:4000
      OPENAI_API_KEY: ${LITELLM_MASTER_KEY}
    depends_on:
      - litellm

volumes:
  open-webui:

OpenWebUIのバージョンについて

この文書を書いている時点の最新バージョンはv0.9.6ですが、あえてv0.9.4にダウングレードしています。これはOpenWebUIを API で使う場合にv0.9.5以降ではバグがあってうまくいかないので、v0.9.4に固定しています。

OPENAI_API_KEY の意味に注意

ここが少し混乱しやすい部分ですが、OpenWebUIの

    environment:
      OPENAI_API_BASE_URL: http://litellm:4000
      OPENAI_API_KEY: ${LITELLM_MASTER_KEY}

OPENAI_API_KEYはOpenAIのAPIキーではなく、OpenWebUIから見ると接続先はLiteLLMで、OpenAI互換APIで接続するためこのようになります。
本物のOpenAI APIキーはLiteLLMが.env経由で保持します。

LiteLLM設定

litellm/config.yaml

を作成します。

例:

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  
litellm_settings:
  drop_params: true
  callbacks: usage_callback.usage_logger
  turn_off_message_logging: true
  
model_list:
# Geminiのモデル
  - model_name: gemini-pro
    litellm_params:
      model: gemini/gemini-2.5-pro
      api_key: os.environ/GEMINI_API_KEY
  - model_name: gemini-flash
    litellm_params:
      model: gemini/gemini-2.5-flash
      api_key: os.environ/GEMINI_API_KEY
  - model_name: gemini-flash-lite
    litellm_params:
      model: gemini/gemini-2.5-flash-lite
      api_key: os.environ/GEMINI_API_KEY
# anthropicのモデル 
  - model_name: claude-haiku
    litellm_params:
      model: anthropic/claude-haiku-4-5
      api_key: os.environ/ANTHROPIC_API_KEY
      cache_control_injection_points:
        - location: message
          role: system
        - location: message
          index: -1
  - model_name: claude-sonnet
    litellm_params:
      model: anthropic/claude-sonnet-4-6
      api_key: os.environ/ANTHROPIC_API_KEY
      cache_control_injection_points:
        - location: message
          role: system
        - location: message
          index: -1
  - model_name: claude-opus
    litellm_params:
      model: anthropic/claude-opus-4-8
      api_key: os.environ/ANTHROPIC_API_KEY
      cache_control_injection_points:
        - location: message
          index: -1
# openaiのモデル
  - model_name: gpt-flagship
    litellm_params:
      model: openai/gpt-5-pro
      api_key: os.environ/OPENAI_API_KEY
  - model_name: gpt-standard
    litellm_params:
      model: openai/gpt-5
      api_key: os.environ/OPENAI_API_KEY
  - model_name: gpt-mini
    litellm_params:
      model: openai/gpt-5-mini
      api_key: os.environ/OPENAI_API_KEY
  - model_name: openai-reasoning
    litellm_params:
      model: openai/o3
      api_key: os.environ/OPENAI_API_KEY

最初のmaster_keyでOpenWebUIからLiteLLMにつながるように鍵を共有しています。

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

その後のmodelsにAIのモデルを設定していけばいいのですが、model_name はOpenWebUI側に表示される名前で、modelに実際のモデル名、api_keyに.env経由でAPIキーを設定します。
だいたい、各社の各サイズのモデルの代表モデルにしておくといいです。OpenWebUI側ではカスタムモデルでユーザにわかりやすい名前で公開するので、管理者がモデルがわかるくらいの名前にしておくといいです。
社名の後ろをワイルドカードにしてまとめて定義することもできますが、OpenWebUIから見えるモデル名が大量になるので、ここで具体的に記入しておいた方がいいでしょう。

起動

次のコマンドでサーバを立ち上げます。

docker compose up -d

ブラウザでアクセスします。

http://サーバIP:3000

初回アクセス時に管理者アカウントを作成します。

接続確認

OpenWebUIのモデル一覧に

gpt-mini
gemini-flash

など、LiteLLMで設定したモデルが表示されれば成功です。

ここまでで、

ブラウザUI
APIキー集中管理
複数モデル切替

ができる基本的な研究室AI環境が完成しました。

次は、このモデルをそのまま使うのではなく、研究室向けの「カスタムモデル」として設定していきます。

次回、研究室専用カスタムモデルを作る

OpenWebUIでは、同じLLMでも用途別にカスタムモデルを作成できます。

例えば

研究室プログラミング支援AI
論文添削AI
TA AI

などです。次回は、これらのカスタムモデルを作成する設定、システムプロンプトの例、AIパラメータの例をあげていきます。

まとめ

今回は研究室AI基盤の第一歩として、

OpenWebUI
LiteLLM

までを構築しました。

ここまでで、学生はブラウザから研究室専用AIを利用できるようになります。

次回は、カスタムモデルをより実践的に設計する方法を取り上げます。システムプロンプトやパラメータの考え方を掘り下げ、用途ごとのAIをどのように設計すればよいかを解説します。

第1回：研究室で管理しやすい学生用AIハブの導入(⇦この記事)
第2回：カスタムモデルで「良いAI活用方法」を埋め込む
第3回：プロジェクト単位ナレッジ管理のコンセプトとインデックス機能の実装
第4回：プロジェクト単位ナレッジ管理の検索・登録機能の実装
第5回：もう一つのナレッジとしてのAIエージェント（公開予定）
第6回：ユースケース：引き継ぎ資料の作成支援AIとプロジェクトナレッジとしての利用（最終回予定）