Mozilla.ai が開発するオープンソースの LLM 制御プレーン（コントロールプレーン）。2026年7月6日に公開された。使う AI プロバイダーが増えるほど、SDK・API キー・請求先がバラバラに散らばり、アプリ側に「つなぎ込みのためだけのコード」が積み上がっていく。Otari はその手前に立ち、40以上のプロバイダーを単一の OpenAI 互換エンドポイントに集約する。加えて、ワークスペースやキー単位の予算上限、鍵の一元管理、利用ログ、プロバイダー障害時の自動フェイルオーバーまでを一箇所で受け持つ。ホスト版とセルフホストの両方に対応し、セルフホストなら API キーも利用データも自社環境の中に留められる。ライセンスは Apache-2.0。
主な特徴
- 単一エンドポイントで40以上のプロバイダー: OpenAI 互換（および Anthropic 互換）の 1 つのエンドポイントに向けるだけで、背後のプロバイダーを切り替えられる。アプリ側のコードを書き換えずにモデルを乗り換えられるのが最大の利点
- バーチャル API キー: 実プロバイダーの鍵を配らず、Otari が発行する仮想キーをチームやアプリに渡す。個別に失効できるため、退職・漏洩・PoC 終了といった場面で影響範囲を最小化できる
- 予算上限をリクエスト前に強制: ユーザー単位・キー単位で上限を設定でき、超過するリクエストは実行前に止まる。請求書が届いてから気づく、という事故を防げる
- 利用状況と支出のログ:
/v1/usageエンドポイントと管理ダッシュボードから、誰が・どのモデルを・どれだけ使ったかを追える。監査や社内配賦の材料になる - ガードレールとサンドボックスツール: プロンプトインジェクションの検知をリクエスト単位でかけられるほか、サンドボックス化された Python 実行と Web 検索をゲートウェイ側の機能として持つ
- エージェント対応（Agent Harnesses）と自動フェイルオーバー: エージェント用途を想定した仕組みを内蔵し、プロバイダー障害時には別プロバイダーへ自動で切り替えられる
- ホスト版とセルフホストの両対応: Docker 単体、Docker Compose（PostgreSQL 付き）、Render、Railway で自前運用できる。セルフホストしながら otari.ai の機能を併用するハイブリッド構成も用意されている
料金
| プラン | 料金 | 主な内容 |
|---|---|---|
| セルフホスト | $0（Apache-2.0） | ソフトウェア自体は無料。自分で用意したプロバイダーの API キーを使い、費用は各プロバイダーに直接支払う |
| ホスト版（otari.ai） | 要確認 | Otari 側が用意するプロバイダーを使う場合、ウォレットに対してトークン単位で課金される方式が案内されている |
料金は2026年8月時点の情報です。ホスト版の課金体系は公開情報が限られているため、最新かつ正確な条件は公式サイトおよび公式ドキュメントをご確認ください。
メリット・デメリット
✅ メリット
- OpenAI 互換エンドポイントなので、既存のコードやライブラリの多くをそのまま流用できる
- Apache-2.0 のオープンソースで、セルフホストすればベンダーロックインが起きにくい
- API キーと利用データを自社ネットワーク内に留められるため、社内規程や取引先要件が厳しい環境でも導入しやすい
- 予算上限が「請求後の分析」ではなく「リクエスト前の遮断」として効くので、コスト事故を構造的に防げる
- 仮想キーの発行・失効が個別にできるため、チームやプロジェクト単位での権限管理がしやすい
⚠️ デメリット
- セルフホストする場合、コンテナ・データベース・アップデートの運用を自分たちで抱えることになる
- ゲートウェイを 1 枚挟む構成上、そこが単一障害点になりうる。冗長化の設計は利用者側の責任
- 2026年7月公開と歴史が浅く、周辺エコシステムや事例の蓄積はこれからの段階
- ホスト版の料金体系について公開されている情報が少なく、比較検討には問い合わせが必要になりやすい
- プロバイダー横断の抽象化は、各社固有の最新機能をそのまま使いたい場面では制約になることがある
類似サービスとの比較
| 比較項目 | Otari | LiteLLM | OpenRouter | Cloudflare AI Gateway |
|---|---|---|---|---|
| 提供元 | Mozilla.ai | BerriAI | OpenRouter | Cloudflare |
| 形態 | OSS + ホスト版 | OSS + 有償版 | ホスト型サービス | ホスト型サービス |
| セルフホスト | 可能（Apache-2.0） | 可能 | 不可 | 不可 |
| 主眼 | 鍵・予算・監査の一元管理 | 統一 SDK / プロキシ | 多モデルへの即時アクセス | 可観測性・キャッシュ・レート制御 |
| 予算・上限管理 | ユーザー/キー単位で事前遮断 | キー単位の上限あり | クレジット残高ベース | レート制限中心 |
| 自前の鍵の利用 | 前提（BYOK） | 前提（BYOK） | 任意 | 前提（BYOK） |
こんな人におすすめ
- 複数の LLM プロバイダーを併用していて、SDK と API キーの管理が煩雑になっているチーム
- 部署やプロジェクトごとに AI 利用のコスト上限を明確に設けたい組織
- API キーや利用ログを外部 SaaS に預けたくない、セキュリティ要件の厳しい環境
- 特定プロバイダーへのロックインを避け、モデルの乗り換え余地を残しておきたい開発者
- エージェントを本番運用しはじめ、障害時のフェイルオーバーや暴走時のコスト制御が必要になった開発チーム
まとめ
Otari は、LLM の「つなぎ込み」に散らばりがちな鍵・請求・ログ・切り替えを、一枚のゲートウェイに集約するオープンソースのツールである。単一のプロバイダーだけを使っている段階では恩恵は薄いが、プロバイダーが増え、利用者が増え、コストが読めなくなってきたタイミングで効いてくる。まずはセルフホスト版を Docker で立ち上げ、既存アプリのエンドポイントを差し替えて挙動を確かめるところから始めるのが現実的だ。ホスト版の課金条件は公開情報が限られるため、本格導入前に公式へ確認しておきたい。