HopBaseLLM ゲートウェイを自前で運用するかマネージドを使うかは、「ゲートウェイの周辺業務」を自社チームが継続的に引き受けるかどうかで決まります。LiteLLM、One API、New API などのオープンソースを自前で運用すれば、ソフトウェアは無料で、どこに置くかも完全に自社で決められます。ただし各モデルベンダーのアカウント・契約・残高は自分で用意する必要があり、高可用性、クォータ、監査、請求の照合、新モデルや価格改定への追随も運用チームの仕事になります。マネージドゲートウェイはこれらをサービスとしてまとめて提供する代わりに、提供形態はサービス側が決めます。データの所在に厳しい要件がある、またはベンダーと契約済みのチームは自前運用が向いています。複数部門で複数ベンダーのモデルをすぐ使いたいが運用要員は増やしたくないチームには、マネージドが手間を減らします。
オープンソースゲートウェイを自前で運用すると、実際に何が必要か
LiteLLM は Python SDK であると同時に、自前でホストするゲートウェイサーバー(LiteLLM Proxy)としても動きます。One API と New API は自分でデプロイするオープンソースのゲートウェイで、複数ベンダーの API を OpenAI 互換形式にまとめ、キーとクォータの管理機能を備えています。これらが解決するのは「インターフェースの統一」です。次の作業は引き続き自社で行います。
- ベンダーごとのアカウントと残高。オープンソースのゲートウェイはモデルを提供せず、リクエストを変換・振り分けるだけです。Claude、GPT、Gemini、DeepSeek、Qwen を使うなら、ベンダーごとに登録・本人確認や契約・支払い方法の設定を行い、残高も個別に管理します。
- デプロイと高可用性。ゲートウェイ本体、データベース、キャッシュのデプロイとバックアップが必要です。複数インスタンス、ヘルスチェック、アップグレードとロールバック、監視とアラートも自前で用意します。ゲートウェイが止まれば、社内の AI 呼び出しがすべて止まります。
- キー・クォータ・監査を組織構造に合わせる。オープンソースには通常、仮想キーやクォータといった基本機能があります。部署の切り分け、誰がクォータを変更できるか、操作ログをどこまで追えるかは、設定または追加開発で対応します。
- 請求の照合。ベンダーごとに請求書が分かれ、通貨や課金ルールも異なります。月末にゲートウェイのログと各社の請求書を突き合わせ、部署ごとに按分する作業が発生します。
- 新モデルと価格改定への追随。ベンダーが新モデルを出す、モデル ID を変える、価格を改定するたびに、ゲートウェイのモデル一覧と価格表を更新しないと、社内の原価集計がずれていきます。
- プロトコル互換性。ストリーミング、ツール呼び出し、Anthropic Messages と OpenAI 形式の違いは、ゲートウェイを更新するたびに再確認が必要です。
マネージドゲートウェイがカバーする範囲(HopBase の場合)
- アカウントも残高もひとつ:Claude、GPT、Gemini、DeepSeek、Qwen、GLM、Kimi、Doubao、Hunyuan、Grok に加え、Seedance、Kling、Hailuo などの画像・動画モデル。各ベンダーの公式価格 × グループ割引で米ドル精算され、ベンダーごとの契約は不要です。
- 2 つのプロトコル:OpenAI 互換は
https://api.hop-base.com/v1、Anthropic Messages はhttps://api.hop-base.com(/v1 なし)。 - 容量とフェイルオーバー:各リクエストはキーに含まれるグループのひとつで処理され、その背後にはプールされた冗長容量と自動フェイルオーバーがあります。
- チーム管理:企業オーナーと企業管理者がメンバー・部署・キーを管理します。クォータはキー・メンバー・部署の 3 段階で、月次クォータは指定した締め日(毎月 1〜28 日)に一斉リセットされます。クォータ不足のリクエストは処理前に HTTP 402 で拒否されます。
- キーの制御:1 本のキーに 1〜10 個のグループを含められ、クォータ、有効期限、IP リスト、同時実行数を設定できます。いつでも無効化・失効が可能で、サーバー側には一方向ハッシュのみを保存します。
- 監査と照合:組織・メンバー・クォータ・キーの操作はすべて記録されます。利用状況ページから日付、キー、メンバー、部署で絞り込んで CSV を出力でき、各行を「公式原価 × 割引 ÷ 為替レート = 実請求額」で再計算できます。失敗したリクエストは課金されません。
- データ:プロンプトと出力はリクエストの処理にのみ使われ、業務データとして保持されず、学習にも使われません。通信はすべて TLS です。
なお、HopBase はオンプレミス提供を行っていません。それが必須要件なら、自前運用を優先して検討してください。
比較表:自前運用 vs マネージド
| 観点 | 自前運用(LiteLLM / One API / New API) | マネージド(HopBase) |
|---|---|---|
| ベンダーのアカウントと契約 | ベンダーごとに契約・入金 | ひとつのアカウントで複数ベンダーのモデル |
| 設置場所・データの所在 | 自社データセンター、指定のクラウドリージョン、社内ネットワーク | HopBase のサービスを利用(オンプレミス提供なし) |
| 高可用性 | インスタンス、バックアップ、監視、更新を自前で | プールされた冗長容量と自動フェイルオーバーを含む |
| キー・クォータ・監査 | 基本機能あり。組織構造は設定・開発が必要 | 3 段階クォータ、部署、監査ログをすぐ使える |
| 請求の照合 | 複数の請求書・通貨を手作業で統合 | 米ドルの請求ひとつ。CSV を行単位で再計算可能 |
| 新モデル・価格 | モデル一覧と価格表を自分で更新 | モデルカタログと公式価格はサービス側が維持 |
| カスタマイズ性 | コード変更、プラグイン追加、社内システム連携が可能 | コンソールと API が提供する範囲 |
| 主なコスト | ベンダー費用 + サーバー + 運用工数 | 従量課金。企業利用は営業が見積もり |
どちらを選ぶか
自前運用が向いているケース
- コンプライアンス上、リクエストを特定リージョンや社内ネットワーク内にとどめる必要があり、第三者のサービスを経由できない。
- モデルベンダーと企業契約や専用枠をすでに持っていて、それを直接使い続けたい。
- オンプレミスや社内システムとの深い連携が必要。
- 運用担当者がいて、ゲートウェイ障害の切り分けを自社で行える。
マネージドが向いているケース
- 複数ベンダーのモデルを使いたいが、ベンダーごとの契約・入金・照合は避けたい。
- 部署・メンバー・キー単位でクォータと利用額を管理したいが、開発はしたくない。
- 専任の運用チームがなく、可用性とフェイルオーバーをサービス側に任せたい。
- 経理部門が行単位で再計算できる利用明細を必要としている。
組み合わせる方法もある
すでに LiteLLM Proxy を運用しているなら、社内の統一入口として残し、HopBase を OpenAI 互換の provider として追加できます。モデル ID の先頭に openai/ を付け、api_base に https://api.hop-base.com/v1 を指定します。手順は LiteLLM 接続ガイドを参照してください。
4 ステップで判断する
- 要件を書き出す:使うモデル、対象業務、データを社外に出せるかどうか。
- 工数を見積もる:自前運用ならデプロイ、オンコール、月次照合、新モデル対応の人日を数える。
- 小さく試す:ひとつの部署で両方を 1 週間ずつ動かし、可用性、照合にかかる時間、障害対応を比べる。
- チェックリストで検証する:プロトコルの網羅性、同時実行時の挙動、課金の透明性を項目ごとに確認します。検証方法はチーム向けゲートウェイ選定チェックリスト、高同時実行とフェイルオーバーの仕組みはこちらの技術解説にまとめています。
マネージドを試すなら HopBase に登録してください。企業アカウントを作成すると、メンバーと部署を追加できます。銀行振込、請求書、企業向け精算については sales@hop-base.com までご連絡ください。
よくある質問
LiteLLM を自前で運用するとコストはどれくらい?
ソフトウェア自体は無料です。コストはベンダーへの利用料、サーバーとデータベース、運用工数の 3 つ。見落とされがちなのは運用工数で、デプロイ、更新、監視、照合、新モデル対応に継続的な手間がかかります。
One API / New API をデプロイしたら、モデルの利用枠は別途必要?
必要です。これらのゲートウェイはインターフェースの統一とリクエストの振り分けを担い、モデルの利用枠は各ベンダーで開設したアカウントから来ます。残高、レート制限、請求書はベンダーごとに管理します。
企業向け AI ゲートウェイの選定で最初に見るべき点は?
データ要件です。リクエストを社内ネットワークや特定リージョンにとどめる必要があるなら、自前運用から検討します。そうでなければ、運用工数、必要なモデルの数、照合の手間を比べてください。