※本記事は、Cast Done by AI チャンネルのエピソード13の内容を基に作成されています。本エピソードのハイライトは、ChatGPTのような独自のAIアシスタントを構築できるOpen WebUIの詳細な解説です。個人利用や小規模チームでの活用に適したこのツールについて、RAG、Web検索、OllamaやOpenAIとの連携、ツール使用（エージェントワークフロー）などの実装方法を説明しています。また、GPT-4o miniとllama-3-groqモデル（関数呼び出し用）、およびBerkeley Function Callingリーダーボードに関する最新情報も提供しています。 本記事は動画の内容を要約したものであり、より詳細な情報や正確な文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。 Cast Done by AIは、生成AIによるビジネス課題の解決方法、実装方法、チームへの展開方法について、実践的な情報を提供しているチャンネルです。より詳細な情報や最新のアップデートについては、以下のプラットフォームでフォローいただけます：
- LinkedIn: /casedonebyai
- YouTube: @casedonebyai
- YouTube: @casedonebyai
- TikTok: /casedonebyai
- Github: https://www.github.com/casedone
- SubStack: https://casedonebyai.substack.com
1. はじめに
1.1. エピソード13の概要
皆様、Cast Done エピソード13へようこそ。私はホストのP（ベンチ）です。Cast Doneでは、AIと生成AIに関するニュースとインサイトをお届けし、皆様の業務やチーム、そして個人の能力向上に貢献することを目指しています。
本日は興味深いトピックを3つご用意しています。最初のトピックは、LLMプロバイダーを比較するための新しいツールです。アプリケーションを構築する際に、どのLLMを選択するべきか、様々な側面から評価することができます。
2つ目のトピックでは、LLMの関数呼び出し能力を評価するリーダーボードを紹介します。これは、ユーザーに回答を提供するために、エージェントがAPIを通じて特定の機能を呼び出したりサービスを利用したりする場合に、非常に有用な評価基準となります。
そして本日のハイライトは、最後のトピックとなるOpen WebUIです。このツールは、すぐに利用可能なインターフェースを提供し、OpenAIのAPIキー1つで利用を開始でき、さらにはOllamaとの連携も可能です。
1.2. 本エピソードの構成
まず、GPT-4o miniをご紹介します。これは先週OpenAIがリリースした、コスト効率の高いインテリジェントなLLMです。リリースノートによると、GPT-4o miniは通常のGPT-4と比較してやや性能は劣るものの、コスト面で大きな優位性があります。例えば、入力トークンは100万トークンあたり15セント、出力トークンは100万トークンあたり60セントと、GPT-4やGPT-4 turboと比較して大幅に安価です。
このモデルは、チェーンや多数のモデル呼び出しを必要とするアプリケーションにおいて、低コストと低レイテンシーでの実行が可能です。特に、PDFなど大量のトークンを処理する必要があるRAGアプリケーションにおいて、魅力的な選択肢となります。また、低レイテンシーの特性を活かし、リアルタイムでの顧客対応が必要なアプリケーションにも適しています。
現時点では、APIでテキストとビジョンのみをサポートしていますが、将来的にはテキスト、画像、動画、音声などのマルチモーダル入出力もサポートする予定です。コンテキストウィンドウは128,000トークン、出力は最大16,000トークンまで対応しています。
次に、GroqとGlaiveの共同開発によるLlama 3アーキテクチャベースのモデルを紹介します。これは関数呼び出しやツール使用に特化したモデルで、70Bと8Bの2つのバリエーションが用意されています。
これらのトピックを詳しく解説しながら、皆様がAI技術を実務に活用するための具体的な方法をお伝えしていきます。それでは、各トピックの詳細な解説に移っていきましょう。
2. LLMの最新動向
2.1. GPT-4o miniの特徴と性能評価
先週、OpenAIがGPT-4o miniをリリースしました。このモデルは、コスト効率の高いインテリジェントなLLMとしてリリースされています。リリースノートによると、GPT-4o miniは通常のGPT-4と比較して性能は若干劣るものの、コストの面で大きな優位性を持っています。
具体的なコストを見てみましょう。GPT-4o miniは入力トークンが100万トークンあたり15セント、出力トークンが100万トークンあたり60セントという価格設定になっています。これはGPT-4およびGPT-4 turboと比較して大幅に低コストであり、RAGアプリケーションの構築において魅力的な選択肢となっています。
GPT-4o miniは、低コストと低レイテンシーで実行可能なモデルとして設計されており、特にチェーニングや複数のモデル呼び出しを必要とするアプリケーションに適しています。また、PDFなど大量のトークンを処理する必要があるRAGアプリケーションでの参照回答の検索にも適しています。さらに、低レイテンシーの特性を活かし、顧客とのリアルタイムなインタラクションが必要なアプリケーションにも向いています。
現時点では、APIを通じてテキストとビジョンの機能のみをサポートしていますが、将来的にはテキスト、画像、動画、音声などのマルチモーダル入出力にも対応する予定です。コンテキストウィンドウは128,000トークン、出力は最大16,000トークンまでサポートしています。
2.2. Groq-Llama 3モデルの機能と特徴
Groqは、Glaiveとの共同開発により、Llama 3アーキテクチャをベースとした新しいモデルをリリースしました。このモデルには70Bパラメータと8Bパラメータの2つのバージョンが用意されており、関数呼び出しやツール使用に特化して訓練されています。
このLLMは、関数呼び出しやツールの使用において特に優れた性能を発揮します。これは、ユーザーからの要求に対して、エージェントが適切なAPIを呼び出したり、関数実行をトリガーしたりする必要がある場合に重要となります。関数使用やツール使用の精度が高いほど、アプリケーションのパフォーマンスも向上します。現在、このGroq-Llama 3モデルは、オープンソースの世界では関数呼び出しにおいて最高のパフォーマンスを示しているとされています。
このモデルはHugging Faceでも利用可能となっており、Berkeley Function Callingリーダーボードによる評価では、Llama 3 Groq Synth 70BおよびGroq 8Bのツール使用モデルは、Claude 3.5 Sonetなどと比較しても優れたオプションとなっています。
リリースノートを見ると、このGroqモデルの特徴が明確に表れています。GPT-4o miniのリリースノートでは、コストとレイテンシー、一般的なベンチマークでの性能に焦点が当てられているのに対し、Groqモデルのリリースノートは関数呼び出し能力に焦点を当てています。このことは、アプリケーションを構築する際に、AIアシスタントとしての利用なのか、ツールやAPIを呼び出すエージェントの構築なのか、目的に応じて適切なモデルを選択することの重要性を示しています。
3. Artificial Analysisによるモデル比較
3.1. 品質・速度・価格の3次元評価システム
Artificial Analysisは、AIモデルを独立して分析するコミュニティツールです。このツールにアクセスすると、最初のページで品質、速度、価格という3つの側面からのランキングを確認することができます。
品質の側面では、モデルの推論能力や指示に従う能力が評価されています。これは関数呼び出しの能力とも関連しており、現在GPT-4 turboが最高品質のモデルとして評価されています。しかし、品質はモデルサイズと関連があるため、速度面では6位にランクされています。価格の観点では、オープンソースのLlama 3が最も手頃な選択肢となっています。
2次元での比較も可能で、一般的な対話能力（Chatbot Arena）、推論と知識（MMLUベンチマーク）、コーディング能力（human evalベンチマーク）といった異なる評価軸で各モデルを比較できます。これらの評価において、GPT-4 turboは依然として最強のモデルの一つであり、次いでClaude 3.5 Sonnet、そしてGemini 1.5 Proが続いています。
特に有用なのが、品質と出力速度を組み合わせた2次元比較グラフです。Y軸に品質、X軸に出力速度をプロットしており、右上の象限が最も望ましい領域となります。このグラフによると、Gemini 1.5 FlashとGPT-4o miniが最適な領域に位置しています。また、速度よりも品質を重視する場合は、GPT-4 turbo、Claude 3.5 Sonnet、Gemini 1.5が良い選択肢として示されています。
グラフ上のドットのサイズは価格を表しており、大きなドットほど高価なモデルを示しています。例えば、Claude 3.5 SonnetはGPT-4 turboよりもドットが小さく、より手頃な価格設定であることがわかります。両者の品質と速度の指標が近い場合、なぜより高価なGPT-4 turboを選択する必要があるのかという疑問が生じます。
3.2. サービスプロバイダー別の性能比較と特徴分析
サービスプロバイダーの比較では、インフラストラクチャを提供する事業者の性能評価に焦点を当てています。X軸に価格（低いほど望ましい）、Y軸に出力速度をプロットした比較において、特にGroqの性能が際立っています。Groqは非常に高速なトークン生成速度を誇りながら、最も低価格な事業者の一つとなっています。対照的に、Microsoftは高価格にもかかわらず出力速度が低いという結果となっています。
出力速度対価格の観点では、Groqが明確な勝者となっており、時系列での性能推移を見ても、一貫して他のプロバイダーを上回る出力速度を維持しています。
このツールでは、個別のモデルに焦点を当てた詳細な分析も可能です。例えば、特定のモデルを選択すると、長所と短所の要約や、品質、価格、速度、レイテンシー、コンテキストウィンドウなどの詳細情報が表示されます。また、レイテンシーや速度などの具体的な数値データも確認することができます。
コンテキストウィンドウの長さについて、Gemini 1.5 Proは100万トークン、Gemini 1.5 Proの最新版は200万トークンをサポートしており、GPT-4やGPT-4o miniの128,000トークンと比較して大幅に長いコンテキスト処理が可能です。これは、大規模なドキュメント処理が必要なRAGアプリケーションにおいて、Vector Embedding Databaseの構築を省略できる可能性を示唆しています。
4. Berkeley Function Calling Leaderboard
4.1. 機能呼び出し性能の評価方法と指標
Berkeley Function Callingリーダーボードは、バークレー大学の研究グループによって開発された評価フレームワークです。このリーダーボードでは、約2,000のデータポイントを用いて、LLMの関数呼び出し能力を評価しています。
評価カテゴリーは大きく「Python」と「非Python」の2つの領域に分かれています。
Pythonの評価領域では：
- シンプルな関数評価：モデルに単一の関数が提供され、その使用能力を評価
- 複数関数の選択：提供された複数の関数の中から、適切な関数を選択する能力を評価
- 並列関数実行：複数の関数を同時に並列で呼び出す能力を評価
非Pythonの評価領域では：
- チャット能力評価：ユーザーが関数呼び出しを必要としない質問をした場合に、モデルが適切に判断できるかを評価
- REST API評価：実世界で広く使用されているREST API構文の適切な使用能力を評価
- SQL評価：SELECT、FROM、WHEREなどの正しいSQL構文の生成能力を評価
- Java/JavaScript評価：これらのプログラミング言語での関数呼び出しの実装能力を評価
さらに、抽象構文木による評価も行われており、モデルが関数呼び出しの必要性を判断するための論理的な決定木を構築できるかを検証しています。また、関数の実際の実行能力も評価対象となっています。
4.2. 主要モデルの性能比較と実装への示唆
現在のリーダーボードでは、Claude 3.5 Sonnetが関数呼び出しの総合評価で首位に立っています。性能、コスト、平均レイテンシーなども含めた総合的な評価において、最も優れた結果を示しています。
2位にはGPT-4が位置しており、GPT-4 turboは12位にランクされています。両者の平均性能スコアには約5ポイントの差が見られます。また、Gemini 1.5 Pro、Gorilla（バークレー大学のチームが開発）なども上位にランクインしています。
オープンソースモデルでは、Meta Llama 3 70Bが注目に値します。一方、8Bパラメータの小規模なLlama 3モデルは60点程度のスコアとなっており、信頼性の高い関数呼び出しが必要なアプリケーションには適していないことが示されています。
実例を用いた評価デモも提供されており、以下のような形式でモデルのテストが可能です：
- ユーザーからのプロンプト入力（例：特定の位置の天気予報リクエスト）
- 関数のドキュメント提供（利用可能な関数の説明）
- モデルによる関数呼び出しコードの生成
- OpenAI互換フォーマットでの出力
このような評価を通じて、商用目的でのアプリケーション開発においては、プロプライエタリモデルが関数呼び出しの能力で優位性を持っていることが明確に示されています。特に先進的な機能を必要とする場合は、オープンソースモデルの使用を避けることが推奨されます。ただし、適切なファインチューニングを行うことができれば、オープンソースモデルでも十分な性能を発揮できる可能性があります。
5. Open WebUIのセットアップと基本機能
5.1. Dockerを使用したインストール手順
Open WebUIのインストールでは、開発者も推奨しているDocker方式を採用することをお勧めします。まず最初に、お使いのマシンにDockerをインストールする必要があります。私の場合、MacBookでOllamaを使用する予定だったため、GPUを使用しないバージョンのDockerコマンドを選択しました。
インストールの具体的な手順は以下の通りです：
- Dockerをシステムにインストール
- ターミナルでOllamaサーバーを起動（「ollama serve」コマンドを使用）
- Dockerコンテナを実行
私の場合は、Dockerのグラフィカルインターフェースを使用してコンテナを起動することを好みます。ダウンロードしたDockerイメージはインターフェースに表示され、「run」ボタンをクリックすることで実行できます。システムがコンテナの準備を行い、実行状態になると、Webインターフェースにアクセスできるようになります。
5.2. 管理者設定とユーザー管理の実装
Open WebUIのユーザー管理システムでは、システムに最初にサインアップしたユーザーが自動的に管理者権限を持ちます。そのため、初回のサインアップは必ず管理者となるべき人が行うようにしましょう。
管理者インターフェースには以下の機能があります：
- ワークスペース管理
- 新規チャットの作成ボタン
- 左側パネルの最小化/展開ボタン
- チャットセッション固有の設定
- グローバル設定へのアクセス
実際のユーザー管理の例をご説明します。管理者パネルのユーザータブでは、システムに登録された全ユーザーのリストを確認できます。新規ユーザーがシステムに登録すると、初期状態では「pending」（保留）ステータスとなります。管理者は、そのユーザーが正当な組織メンバーであることを確認した後、「user」（一般ユーザー）または「admin」（管理者）権限を付与できます。
モデルへのアクセス管理も重要な機能です。管理者設定の「Users」タブでは、「ホワイトリスト」機能を通じて、一般ユーザーがアクセスできるモデルを制限できます。例えば、私のシステムでは現在、ユーザーはGPT-3.5とGPT-4のみにアクセス可能となっています。新しいモデル（例：GPT-4o mini）を追加する場合は、「add」ボタンをクリックし、利用可能なモデルのリストから選択するだけです。
管理者設定の「General」タブでは、新規ユーザーの登録（サインアップ）を有効/無効にすることができます。さらに、「Connections」タブではOpenAI APIやOllama APIとの連携設定が可能です。現在の私のシステムでは、5-20人程度のチームで問題なく運用できています。
このようにOpen WebUIは、必要最小限でありながら効果的な管理機能を提供しており、チームでのAI活用を容易にしています。基本的な設定が完了すれば、ユーザーは直感的なインターフェースを通じて、許可されたモデルにすぐにアクセスできるようになります。
6. Open WebUIの高度な機能実装
6.1. OpenAI APIとOllamaの連携設定
管理者が最初に行うべき設定は、モデルへのアクセス設定です。管理者パネルの「Settings」タブから「Connections」セクションで、OpenAI APIやOllama APIへの接続を設定できます。
OpenAI APIを設定する場合は、Base URLとAPIキーを入力します。もし独自のクラウドでLLMをホストしている場合は、そのBase URLを指定することも可能ですが、APIインターフェースがOpenAI互換である必要があります。
私の環境では、まず「ollama serve」コマンドでOllamaサーバーを起動し、その後Open WebUIからOllamaへの接続を設定しています。これにより、Gemma 2などのOllamaで利用可能なモデルにアクセスできるようになります。実際にテストを行ったところ、Ollamaとの連携は正常に機能し、ローカルで実行しているモデルとスムーズに対話できることを確認しました。
6.2. RAGシステムの構築と文書管理
RAGシステムの設定は、管理者パネルの「Documents」タブで行います。まず埋め込みモデルの選択が必要です。デフォルトではSentence Transformersが使用されますが、OpenAIやOllamaの埋め込みモデルも選択可能です。
文書管理では効率的なタグ付けシステムを採用しています。例えば「MBA Marketing」や「MBA Accounting」といったタグを使用して文書をグループ化できます。文書のアップロードは右側の「+」ボタンから行い、複数のタグを付与することが可能です。
アップロードされた文書は自動的にテキスト抽出され、処理されます。ただし現時点では基本的な処理のみが行われ、画像や図表からの情報抽出は行われません。高品質なテキストを含む文書であれば、効果的なRAGが実現できます。
RAGを実際に使用する場合、「#」記号を使用してドキュメントコレクションを指定します。例えば、マーケティングに関する質問をする場合、「#marketing」と入力することで、該当するタグが付けられた文書群から情報が検索されます。チャットセッション中でも、アップロードボタンから文書を追加することができますが、その場合は都度アップロードが必要となります。
6.3. Web検索機能の実装と活用
Web検索機能は、管理者パネルの「Settings」タブ内の「Web Search」セクションで設定します。この機能を有効化することで、モデルはインターネットから情報を検索できるようになります。
検索エンジンとしては、GoogleのCustom Search EngineやBingなどが使用可能ですが、これらはAPIキーが必要です。一方、DuckDuckGoは無料で使用でき、私も長年使用している信頼できる検索エンジンです。
Web検索の設定では以下のパラメータを調整できます：
- 検索結果の数（デフォルトは5件）
- 同時リクエスト数の制限
- SSL検証のバイパス設定
- YouTubeトランスクリプトのダウンロード設定
また、特定のWebページをRAGのコンテキストとして使用することも可能です。「#」記号の後にURLを指定すると、そのWebページの内容に基づいて回答を生成します。これは例えば、量子もつれについてWikipediaの情報を参照しながら回答するといった使い方が可能です。
6.4. DALL-E 3による画像生成の設定
画像生成機能のデフォルトはAutomatic 1111ですが、私の環境では、マシンの性能を考慮してOpenAI APIを使用したDALL-E 3を採用しています。これは、Automatic 1111やComfy UIをローカルで実行すると、システムが遅くなりクラッシュする可能性があるためです。
管理者パネルで画像生成機能の設定を行います。設定手順は以下の通りです：
- 画像生成機能を有効化
- OpenAI APIのBase URLとAPIキーを入力
- DALL-E 3をモデルとして選択
- 出力画像サイズを1024x1024ピクセルに設定
特に注意が必要なのは画像サイズの設定です。初期設定では512x512ピクセルに設定されていますが、DALL-E 3を使用する場合は1024x1024ピクセルに変更する必要があります。ステップ数は20から50の間で調整可能です。
6.5. プロンプトスニペットの作成と管理
プロンプトスニペットは、管理者パネルのワークスペースの「Prompts」タブで管理します。ここでは独自のプロンプトテンプレートを作成できます。プロンプトスニペットを作成する際は、タイトルを設定すると、それが自動的にスニペットコマンドとして使用されます。
基本的な画像生成用のスニペットの例として、以下のようなテンプレートを作成できます： "repeat this text create a {medium} of a {subject} with {attributes} in {scene}"
Open WebUIでは、画像生成のプロンプトは必ず「repeat this text」で開始する必要があります。これはChatGPTやGeminiとは異なる仕様です。
ユーザーは、バックスラッシュ（/）を入力してスニペットにアクセスし、Tabキーを押すことで各プレースホルダーを順番に入力できます。
6.6. Function Calling（エージェントツール）の実装
Function Callingは「Tools」タブで設定します。私のテストケースでは、「CityWeather」という単純なツールを作成しました。このツールは「get_current_weather」という関数を持ち、都市名を文字列として受け取り、常に「天気は良好」という結果を返すシンプルなものです。
実装手順は以下の通りです：
- 「+」ボタンでツールを新規作成
- ツール名とIDの設定
- 必要なPythonコードの実装
- モデルタブでベースモデル（GPT-4など）の選択
- システムプロンプトでツールの使用方法を指定
- ツールの選択と必要に応じた関連文書の添付
テスト段階では、ユーザーインターフェースに関していくつかの課題が見られました。例えば、時々グリッチが発生し、ログアウト・ログインが必要になることがありました。また、正しい動作を確認するには、管理者インターフェースで先にテストを行い、その後ユーザーインターフェースでテストを実施する必要がありました。
興味深い点として、管理者ページではツールが正常に動作する一方で、ユーザーページでは時々問題が発生することがありました。この問題は、一度ログアウトしてログインし直すことで解決できました。現状では発展途上の機能ですが、基本的な機能は動作することが確認できています。
7. Open WebUIの実践的活用事例
7.1. チーム内でのAIアシスタント活用方法
私は実際に自社でOpen WebUIを導入し、クラウドプロバイダー上でホスティングして運用しています。チームメンバーは外部リンクを通じて各自のラップトップからアクセスすることができます。この方法によって、チーム全体でAIアシスタントを共有することが可能になりました。
システムの中核となるのは、単一のOpenAIアカウントとそのAPIキーの共有です。チーム全体で1つのOpenAIアカウントを使用し、そのAPIキーをOpen WebUI上で設定することで、すべてのメンバーがアクセスできる環境を構築しています。
私の実践経験から、このシステムは5人から20人規模のチームで特に効果的に機能することが分かっています。実際に20人規模のチームで運用してみましたが、問題なく動作することを確認できました。システムの安定性と使いやすさは、チーム全体の生産性向上に大きく貢献しています。
7.2. コスト効率の高いAI実装アプローチ
Open WebUIは、特に小規模チームにとって極めて効率的なソリューションです。このインターフェースを使用することで、ChatGPTのWebブラウザインターフェースと同様の機能を実現しながら、より経済的な運用が可能になります。
私たちの経験では、特に以下の点でコスト効率の向上が見られました：
- 単一のOpenAIアカウントとAPIキーの共有による管理コストの削減
- Ollamaとの連携によるローカルモデル実行オプション
- チーム全体でのリソース共有による効率化
このように、Open WebUIは小規模から中規模のチームにとって、コスト効率が高く、かつ効果的なAI活用を実現するためのプラットフォームとして機能しています。実際の運用を通じて、このツールが企業のAI導入における実用的な選択肢となることが確認できました。
8. まとめ
8.1. 各ツールの比較と選択指針
本日のエピソードでは、3つの重要なトピックについて解説しました。まず、LLMプロバイダーを比較するための新しいツール、Artificial Analysisを紹介しました。このツールを使用することで、アプリケーションの要件に応じて最適なモデルを選択することができます。
次に、Berkeley Function Callingリーダーボードでは、機能呼び出しやツール使用に関するモデルの評価を行いました。これは、エージェントベースのアプリケーションを開発する際の重要な指標となります。
そして最後に、Open WebUIという強力なインターフェースを紹介しました。このツールは、オープンソースでありながら、RAG、Web検索、画像生成、ツール使用など、多彩な機能を提供します。私の経験では、5-20人程度の小規模チームでの活用に特に適しており、実際に私の会社でも導入して成果を上げています。
8.2. 実装時の注意点と推奨事項
Open WebUIの導入にあたっては、開発者推奨のDocker方式でのインストールを強くお勧めします。また、ユーザー管理において、最初のサインアップは必ず管理者となるべき人が行うよう注意してください。
RAGシステムの構築では、効率的な文書管理のためのタグ付けが重要です。Web検索機能の実装では、無料で利用可能なDuckDuckGoを使用することで、コスト効率の高いシステムを構築できます。
Function Callingの実装については、現時点ではまだ発展途上の機能であり、インターフェースに時折グリッチが発生することがあります。必要に応じて、ログアウト・ログインによる対処が有効な場合があります。
本日紹介したツールとその知見が、皆様のAI実装の参考になれば幸いです。