本記事では、企業における生成AI活用をより一層推進するため、生成AI環境をリニューアルした取り組みをご紹介します。多様なモデルを使えることで、業務でのAI活用が広がることを目指しています。

背景

当社では、Azure OpenAI Serviceをベースに生成AI環境を社内展開していました。構築した2023年当時は、OpenAI社のモデルを使えることが最優先課題であったため、他のモデルのサポートは見送られました。API基盤としては、Azure API Managementで構築して、利用者にAPIキーを提供していました。さらに、独自開発したアプリケーション¹により、Web UIでの利用方法も提供していました。

しかし、2025年現在、様々なモデルが台頭しています。特にAI駆動開発のために、Anthropic ClaudeやGoogle Geminiなどの利用を望む声が社内で高まりました。AIチャットアプリケーションについても、Web検索等の機能追加が進まず課題を抱えていました。

また、Amazon BedrockやGoogle Vertex AIで扱えるモデルが充実してきたこともあり、Azure OpenAI Serviceありきの仕組みを見直す好機でもありました。こうした背景を踏まえて、社内の生成AI環境をリニューアルしました。

AIゲートウェイ

AIゲートウェイは、クライアントと生成AIサービスの間で、組織内の生成AIトラフィックを制御します。セキュリティ、モニタリング、ロギング、コストトラッキングなどを一元管理できる点が特長です。当社の従来環境では、Azure API Managementが相当します。

リニューアルの検討においては、Amazon BedrockとGoogle Vertex AIも利用することを念頭に、以下の点を重視しました。

1. 様々なLLMが使える：ClaudeにもGeminiにもその他のLLMにも対応
2. OpenAI互換APIで使える：既存のプログラムやオープンソース実装との親和性のため
3. 独自実装は最小限に：メンテナンスの負荷を抑制したい

Amazon BedrockとGoogle Vertex AIには、OpenAI互換APIが提供されていません。既存のAzure API Managementを活かして両サービスを統合するには、Azure OpenAI Serviceの場合と比べて相応の手間がかかりそうでした。

そこで、オープンソースのLiteLLM Proxyを新たに採用することにしました。

LiteLLM Proxy

LiteLLM Proxyは、様々なAIサービスとの接続をサポートするAIゲートウェイ実装です。Amazon Bedrock、Azure OpenAI Service、Google Vertex AIにも対応しています。開発とリリースが活発で、新モデルへの対応も迅速です。

構築にあたって特段難しい部分はなかったのですが、以下の点を工夫しました。

• モデル定義の設定ファイルを3つのAI基盤サービスで分割して、メンテナンスしやすく
• LiteLLM側に単価情報のないモデルは、設定ファイルに単価情報も追記
• APIキー利用者が指定するモデル名は、平易で分かりやすい表記に（クラウドサービスのモデルIDを流用しない）
• ログはAmazon S3に保管して、Amazon Athenaでコストとトークン数を集計可能に

なお、AIゲートウェイと各クラウドの生成AI基盤サービスとの疎通は当社Webプロキシ及びインターネット経由であり、閉域接続ではありません。当社で利用するAIエンドポイントへのアクセスについては、当社のグローバルIPアドレスからのみ許可する接続元IPアドレス制限をかけています。

LiteLLM Proxyベースの新たなAIゲートウェイは、以下のモデルに対応しています。

• Chat Completion： Amazon、Anthropic、Cohere、Google、Meta、Mistral AI、OpenAI各社の主要LLM
• Embeddings： Amazon、Cohere、Google、OpenAI各社の埋め込みモデル
• その他： リランク（Amazon、Cohere）、画像生成（Amazon、Google、Stability AI）、オーディオ（Google、OpenAI）

Chat Completionだけでも約40のモデルに対応し、選択肢が大幅に増えました。AIゲートウェイの利用者は、払い出されたAPIキーで上記のモデルをすべて使えます。

AI駆動開発での活用

AI駆動開発は、当社のAIゲートウェイ利用者にとっても主要なユースケースです。LiteLLM ProxyがOpenAIとAnthropicの互換APIに対応するため、AIゲートウェイ経由でCline、Roo Code、Claude Code等のAIコーディングツールを使えるようになりました。

Clineの場合、開発計画を考えるPlanモードとコードを生成するActモードで異なるモデルを指定できます。例えば、Planモードで推論性能の高いo3、Actモードでコーディング性能の高いClaude Sonnet 4といった使い分けも可能です。

LLMの性能向上に伴い、AI駆動開発もさらに加速すると思われます。AIゲートウェイが新しいモデルをサポートすれば、ツール側でも設定を変更するだけで最新モデルを活かせるので、開発者体験の向上につながると考えています。

AIチャットアプリケーション

AIチャットアプリケーションについては、独自開発では社員の期待する機能充実ペースを確保できなかった反省を踏まえて、開発が活発なオープンソースアプリケーションを検討しました。その結果、Open WebUIを採用しました。他の候補と比較すると、構築時の設定ファイルと環境変数の記述量が少なく、細かい設定は管理画面で可能なため、本運用に向けた調整が容易でした。

Open WebUI

Open WebUIは多機能なAIチャットアプリケーションで、複数モデルの同時実行、Web検索、ナレッジベース、プロンプト管理、コードインタープリター、アーティファクトなどの機能を備えています。前述のAIゲートウェイ（LiteLLM Proxy）と接続することで、様々なモデルを利用できます。

拡張性についても考慮されており、Open WebUI本体のソースコードに手を加えずに、機能を追加できるFunctionsという仕組みが用意されています。検討と動作確認のうえ、以下の2つの機能をFunctionsで実現しました。

アップロードファイルをLLMに全文渡すオプション

ドキュメントをベクトル検索するか全文をLLMに渡すかは、グローバル設定としてどちらか一方にする必要があります（2025年7月現在）。ナレッジベースの登録が充実していくと、LLMのコンテキストウィンドウの観点からベクトル検索が不可欠です。しかし、チャット画面で少数のファイルをアップロードする場合は、全文をLLMに渡して質問するほうが望ましいケースも十分にあるため、ユーザーが必要に応じて選択できるようにしました。

ユーザーIDをAIゲートウェイのログに含める

AIゲートウェイのログにはAPIキーの利用者を示すフィールドがあります。AIチャットアプリケーションからAIゲートウェイ経由でLLMを利用すると、誰が使ってもアプリケーション用に払い出されたAPIキーのエイリアスが記録されます。このままだとアプリ利用者ごとの集計が難しいため、別のフィールドに記録されるように調整しました。

他のシステムとの接続

Open WebUIは、OpenAI互換APIを持つAIエージェントとの接続が可能です。モデルの代わりにAIエージェントを選択して、利用できます。独自に構築した社内文書検索エージェントや、リサーチエージェントをAIチャットアプリケーション上で使えるようにしています。

また、Open WebUIは、MCPサーバーとの接続もサポートしています。ただし、Open WebUI独自のリバースプロキシ実装を経由する必要があり、本格的な活用には至っておりません。MCPサーバーとの連携は、AIの扱えるデータと回答の幅が大きく広がる可能性を秘めているだけに、今後の課題となります。

リニューアルを振り返って

当社の生成AI環境の構成をリニューアル前後で比べると、以下のとおりです。

多様なモデルをサポートするために複数のAI基盤サービスに対応する必要があり、そのためにAIゲートウェイを中心とする構成に変わりました。

リニューアルの結果、AIゲートウェイとAIチャットアプリケーションのいずれも、アクティブユーザーとAPIリクエストが大幅に増加しました。モデルの選択肢が生成AIを活用するモチベーションに、AIチャットアプリケーションの各種機能がユーザー体験の向上につながったと考えています。

今回のリニューアルでは、オープンソースソフトウェアの組み合わせで、多様なLLMのサポートと拡張性を両立できたと感じています。今後も、会社全体でAIスキルを向上させていく基盤として、生成AI環境の強化を推進していきます。