「Claude Codeの定額枠を使い切った」「Cursorが急にレート制限で止まった」——OmniRoutediegosouzapw/OmniRoute)は、AIコーディングのこうした摩擦を「無料AIゲートウェイ」1本で解消しにくる、GitHubスター15,000超・MITライセンスのOSSです。気づけばOpenAI・Anthropic・Google・DeepSeekと、APIキーとダッシュボードが10個に増えていた——そんなプロバイダ分散のストレスを、OmniRouteは1つのエンドポイントへ畳み込みます。

このOmniRouteというAIゲートウェイが掲げるのは、たった1つの約束です。「1エンドポイント、237プロバイダ。二度と手を止めない——そして一番安く使えるものを勝手に選ぶ」。Claude Code・Codex・Cursor・Cline・Copilotといった手元のツールの接続先を書き換えるだけで、90以上の無料枠を含む膨大なプロバイダ群へ、自動フォールバックしながらリクエストを流し込めます。本記事は、この仕組みが結局何ができて/何を解決し/何を代替できるのかを、公式リポジトリの一次情報だけを根拠に読み解きます。

この記事のポイント
  • ・OmniRouteは237プロバイダ・90超の無料枠を1エンドポイント(localhost:20128/v1)に束ねるMITの無料AIゲートウェイ
  • 17のルーティング戦略4段フォールバック(サブスク→API→格安→無料)で、レート制限が来ても手が止まらない。
  • RTK+Cavemanのトークン圧縮で入力を15〜95%削減。コード・URL・JSONはバイト単位で保護。
  • 内蔵MCPサーバー(95ツール)・A2A・メモリ・ガードレールまで1プロセスに同梱。LiteLLM/OpenRouter/Portkeyより広い守備範囲。
  • ・前身は当サイトでも解説した9router。そのTypeScript全面書き換え版が本プロジェクト。

まずは公式の英語ウォークスルー動画で、ダッシュボードの雰囲気とプロバイダ接続の流れを掴んでおきましょう。

OmniRoute公式の英語ウォークスルー(出典: OmniRoute / YouTube

1. OmniRouteとは何か — 237プロバイダを束ねる無料AIゲートウェイ

あなたのIDE/CLIからOmniRouteの1エンドポイントを経由して237プロバイダへ振り分ける全体像。17ルーティング戦略・トークン15〜95%削減・$0開始のファクトを添えた図
OmniRouteの全体像——接続先URLを1つ書き換えるだけで、237プロバイダへ自動で振り分ける

OmniRouteは、あらゆるAIツールと237のプロバイダの間に立つ「AIゲートウェイ(AI Gateway)」です。ゲートウェイとは、複数の宛先へのリクエストを1か所で受け止め、認証・変換・振り分け・記録をまとめて引き受ける「関所」のこと。OmniRouteはこれをローカルで動く1プロセスとして提供し、Claude Code・Codex・Cursor・Cline・Copilot・Antigravityなど24以上のコーディングツールを、共通の設定(http://localhost:20128/v1)で束ねます。

技術スタックは100% TypeScript 6.0、フレームワークはNext.js 16 + React 19 + Tailwind CSS 4、データベースはbetter-sqlite3。CLIとWebダッシュボードは同じプロセス・同じポートで提供されます。テストは21,000件超(2,586ファイル)と、個人OSSとしては異例の物量が積まれています。

このプロジェクトの出自を知ると、性格がよく分かります。OmniRouteの謝辞(Acknowledgments)は、こう明言しています。

OmniRouteは巨人の肩の上に立っている。9routerのforkとして始まり、GoプロジェクトCLIProxyAPIのTypeScript移植として出発した——そこから、あらゆるサブシステムを、先にそこへ辿り着いたOSSから着想して作った。

つまりOmniRouteは、当サイトでも解説した9router(decolua/9router)|複数AIプロバイダへリクエストを自動で振り分けるAPIルーティングツールを土台に、マルチモーダルAPIと全面的なTypeScript書き換えで拡張した「進化版」です。ポート番号が9routerと同じ20128である点にも、その血筋がはっきり表れています。コスト計算に使う価格データはLiteLLMの公開データセットから同期しており、ルーティングやプロバイダ正規化の考え方もLiteLLMを参照しています。「車輪の再発明」ではなく「良い車輪を全部1台に載せた」のがOmniRouteだと考えると理解が早いでしょう。

数字で骨格を掴んでおきます。以下は公式が主要ルーターとの差として掲げるカバレッジです。

OmniRouteのカバレッジ指標:237プロバイダ、90以上が無料枠あり、17ルーティング戦略、MITで完全OSS・自己ホスト可能
他ルーターと桁が違うカバレッジ——237プロバイダ・90超の無料枠・17戦略・MIT

237プロバイダ:OpenAI・Anthropic・Gemini・xAI Grok・DeepSeek・Mistral・Qwen・Meta Llama・Groq・NVIDIA・MiniMax・Cohereなど主要ラボを網羅
90以上が無料枠あり/11が永久無料:Kiro・Qoder・Qwen・Pollinations・LongCat・Cloudflare AI・NVIDIA NIM・Cerebrasなど
42以上のロケールに対応した多言語ダッシュボード
Web・デスクトップ(Electron)・Android(Termux)・PWAのマルチプラットフォーム

実際の管理画面はこうなっています。プロバイダを種類別(APIキー互換・無料枠・OAuth)に並べ、トグル1つで接続を切り替えられます。

OmniRouteのプロバイダ管理画面。API Key Compatible / Free Tier / OAuthの各カテゴリにCerebras・DeepSeek・Groq・Kiro・NVIDIA NIM・Pollinations・Antigravity・Claude Codeなどが並ぶ
OmniRouteのプロバイダ管理ダッシュボード。無料枠プロバイダだけでも一画面に収まらない量が並ぶ(出典: diegosouzapw/OmniRoute

2. OmniRouteが解決する「APIキー地獄」とレート制限

従来はダッシュボード10個を行き来しレート制限で止まり想定外の請求が来ていたのに対し、OmniRoute導入後は1エンドポイントに集約・自動フォールバック・最安ルーティング・全ツール共通設定になることを対比した図
OmniRouteが潰しにいく「日常の痛み」——キーの分散・レート制限・想定外請求・ツールごとの設定

OmniRouteが向き合う課題は、AIヘビーユーザーなら誰もが心当たりのある「日々の摩擦」です。公式READMEは、痛みとその解決策をこう対応づけています。

・サブスクの枠が毎月使い切れずに失効する → 枠の残量を追跡し、リセット前に使い切る
レート制限でコーディングが中断する → サブスク→API→格安→無料の4段自動フォールバックがミリ秒で切り替える
git diffgrep・ログなどツール出力がトークンを浪費する → RTK+Cavemanの圧縮で該当トークンを15〜95%削減
高額なAPI(月$20〜50)がかさむ → ライブ価格表を見て最安の使えるモデルへ自動ルーティング
・ツールごとに別々のセットアップが要る → 1エンドポイント・全ツール・1ダッシュボード
・自国でAIがブロックされている → 3段プロキシ+TLSフィンガープリント偽装でどこからでも利用

この中核をなすのが「4段フォールバック」です。上位の枠(サブスク)から順に使い、枯れたら1つ下のティアへ自動で滑り落ちる。だから「手が止まらない」わけです。

OmniRouteの4段フォールバック。Tier1サブスク(Claude Code/Codex/Copilotの定額枠)→Tier2 APIキー(DeepSeek/Groq/xAI)→Tier3格安(GLM $0.5/MiniMax $0.3)→Tier4無料(Kiro/Qoder/Pollinations、常時ON)へ落ちる階層図
4段フォールバック——上の枠が尽きたら下へ。サーキットブレーカー・クールダウン・モデルロックアウトの3層で守る

このゲートウェイの内部フローを図にすると、OmniRouteが「関所」として何をしているかが見えてきます。クライアントからのリクエストは、圧縮とルーティング判定を通り、ティアを順に試しながら最初に成功したプロバイダの応答を返します。

flowchart TD A["あなたのIDE / CLI
Claude Code · Cursor · Codex · Cline"] -->|"localhost:20128/v1"| B["OmniRoute
スマートルーター"] B --> C["トークン圧縮
RTK → Caveman(10エンジン)"] C --> D{"ルーティング判定
17戦略 / 9因子スコアリング"} D -->|"Tier1"| E["サブスク枠
Claude Code / Codex / Copilot"] D -->|"枯渇したら"| F["Tier2 APIキー
DeepSeek / Groq / xAI"] D -->|"予算超過なら"| G["Tier3 格安
GLM $0.5 / MiniMax $0.3"] D -->|"最後の砦"| H["Tier4 無料(常時ON)
Kiro / Qoder / Pollinations"] E & F & G & H --> I["最初に成功した応答を返す
サーキットブレーカーで自己回復"] I --> A
「コスト」は請求額ではなく“節約額”

OmniRouteのダッシュボードに表示される「コスト」は、あなたに請求される金額ではありません。無料・格安モデルを使ったことで「本来かかったはずの金額をいくら浮かせたか」を示す節約トラッカーです。公式は「$290の総コスト=$290の節約」と説明しています。OmniRoute自体に課金システムはなく、支払いが発生するのは有料プロバイダに対してだけです。

3. Combos — 17のルーティング戦略と自動フォールバック

OmniRouteのCombos(ルーティング)管理画面。複数モデルを連鎖させたコンボと戦略を設定するダッシュボード
Combos管理画面——モデルの連鎖と戦略をGUIで組み立てる(出典: diegosouzapw/OmniRoute

OmniRouteの看板機能が「Combos(コンボ)」です。コンボとは、OmniRouteが自動で横断するモデルの連鎖のこと。枠が尽きる・プロバイダが落ちる・コストが跳ねる——そのたびに、コンボは静かに次のモデルへ滑る。これが「壊れないゲートウェイ」の正体です。

いちばん簡単な使い方は、コンボを作らずモデルIDにautoを指定するだけのゼロ設定ルーティングです。接続済みプロバイダから仮想コンボをその場で組み立て、9因子(健全性・残量・コスト・レイテンシ・成功率・鮮度など)でライブ採点します。用途別のバリアントも用意されています。

auto:バランス既定(直近で成功したプロバイダに固執するLKGP)
auto/coding:コード生成向けに品質優先の重み付け
auto/fast:レイテンシ最優先
auto/cheap:1トークンあたり最安を優先
auto/offline:残量・レート制限の余裕が大きい順
auto/smart:品質優先+10%の探索で、より良いモデルを発見

より細かく制御したい場合は、17のルーティング戦略を組み合わせて自前のコンボを設計できます。代表的なものだけ挙げます。

戦略 何をするか
priority 先頭から順に、各ターゲットを使い切ってから次へ
weighted ターゲットごとの重みで加重ランダム選択
cost-optimized ライブ価格表から1リクエストの$を最小化
headroom 残量がいちばん多いターゲットを選ぶ
context-relay 長い会話でコンテキストをターゲット間で引き継ぐ
lkgp Last-Known-Good:直近で成功したターゲットに固執
auto 全接続を9因子でライブ採点して選ぶ
fusion 複数モデルのパネルに並列で投げ、judgeが1つの答えに統合

とくにfusionは、当サイトでも取り上げたOpenRouterのFusion API|複数モデルを合議させて精度を上げる新ルーターと同じ「合議」の発想で、複数モデルの回答を1つに束ねて品質を底上げする戦略です。

耐障害性は、3つの独立したレイヤーで担保されています。粒度が違う3段構えなので、1つのモデルが429を返しても接続全体を殺しません。

サーキットブレーカー(プロバイダ単位):上流で失敗し続けるプロバイダへの連打を止め、自動プローブで回復を探る
接続クールダウン(アカウント/キー単位):レート制限されたキーを一時的に飛ばし、他のキーで配信を続ける
モデルロックアウト(プロバイダ+モデル単位):枠切れのモデル1つだけを隔離し、接続まるごとは止めない

さらに新機能のQuota-Shareは、同じ上流アカウント(例:1つのCodex Proプラン)に複数キーをぶら下げているチーム向けに、時間ベースの枠を公平に配分します。誰かのバーストが5時間枠を食い潰して全員をロックアウトする事故を防ぎつつ、遊んでいるメンバーの取り分は貸し出す「work-conserving(遊休を無駄にしない)」設計です。設定はYAMLでこう表現できます。

# コンボ「always-on」— 4層フォールバックで無停止(priority戦略)
combo:
  name: always-on
  strategy: priority
  steps:
    - cc/claude-opus-4-7      # 1. サブスク(使い切る)
    - cx/gpt-5.5              # 2. 別サブスク
    - glm/glm-5.1             # 3. 格安バックアップ($0.5/1M)
    - kr/claude-sonnet-4.5    # 4. 無料・無制限(落ちない最後の砦)
# 結果:4層のフォールバック=ダウンタイムゼロ

ルーティングは「タスク種別」まで見て賢くなっています。OmniRouteはtask-aware routingで、コード生成・要約・推論といったタスクの性質に応じて最適な接続を選び、auto/coding:fastauto/reasoning:proのようなOpenRouter流のauto/<カテゴリ>:<ティア>指定にも対応します。1リクエストだけ挙動を変えたいときは、HTTPヘッダで上書きできるのも実務的です。X-OmniRoute-Modeでモードプリセットを、X-OmniRoute-Budgetでそのリクエスト限りのUSD上限(ハードな費用天井)を、X-Route-Modelでモデルそのものを差し替えられます。さらにリモートモードを使えば、VPS上のOmniRouteを手元のノートPCから同じCLIで操作でき(omniroute connectでスコープ付きアクセストークンを発行)、read/write/adminのスコープでチームや CI に権限を絞って渡せます。

4. RTK + Cavemanのトークン圧縮で15〜95%削減

圧縮モード別のトークン削減率の棒グラフ。Lite15%、Standard(Caveman)30%、Aggressive50%、Ultra75%、RTK85%、Stacked(RTK→Caveman)89%
圧縮モード別のトークン削減率——コード・URL・JSONはバイト単位で保護し、削るのは入力の冗長部分だけ

OmniRouteのもう1つの目玉が、リクエストを透過的に通すだけでトークンを削る圧縮パイプラインです。標語は「少ないトークンで足りるなら、なぜ多く使う?」。クライアント側の改修は不要で、通過する全リクエストが10個の合成可能なエンジンの列を順に通ります。各エンジンはコンボごとに個別にON/OFF・設定できます。

# エンジン 何をするか
1 Session-Dedup ターン間で繰り返される内容を除去(内容アドレス指定)
2 CCR 大きなブロックを退避し、必要時だけ取り出す
3 RTK ツール結果のスマートなフィルタ・重複除去・切り詰め
4 Headroom 均質なJSON配列の可逆な表形式コンパクト化
5 Relevance 直近のクエリに対する抜粋的な文スコアリング
6 Caveman ルールベースの散文圧縮(出力で約65〜75%)
7 LLMLingua-2 MobileBERT ONNXによる意味的プルーニング(コード安全・非同期)
8 Lite 空白・画像URLの削減(低レイテンシの基準線)
9 Aggressive 要約+古いターンの段階的エイジング
10 Ultra ヒューリスティックなトークン刈り込み+任意の小型モデル層

これらをワンクリックで組み合わせたプリセットが、冒頭の棒グラフの各モードです。目安の削減率は、Lite約15%・Standard(Caveman)約30%・Aggressive約50%・Ultra約75%。そしてRTKとCavemanを積み重ねた「Stacked」モードは78〜95%に達します。積み重ねの計算はシンプルで、2つの圧縮率が同じペイロードに効くとき削減は掛け算で複利になります。

combined = 1 − (1 − RTK) × (1 − Caveman_input)
average  = 1 − (1 − 0.80) × (1 − 0.46) = 89.2%
range    = 78.4 – 94.6%

重要なのは、削るのは入力(プロンプト)側の冗長部分だけで、コードブロック・URL・JSON・構造化データは保護エンジンがバイト単位で常に守るという点です。公式は「圧縮は品質を損なわない」と説明しますが、実務では圧縮率が上がるほど欠落リスクも上がるため、npm run eval:compressionのオフライン評価ハーネスで削減率と忠実度のトレードオフを測ってから強いモードへ上げるのが賢明です。

10エンジンが「何を入れるか」を絞るのに対し、その外側には「どう・いつ・何を出すか」を整える3つの層があります。まずOutput Stylesは、応答の形を整える指示を決定論的・キャッシュ安全に注入する仕組みで、冗長表現を削る「Terse prose」、不要な足場コードを書かせない「Less code(怠け者シニア開発者=YAGNI)」などをlite/full/ultraの強度で重ねられます。次にアダプティブ・コンテキスト予算(ダイアル)は、ON/OFFの単一しきい値ではなく、モデルのコンテキストウィンドウに収まる範囲で、最も可逆・低コストなエンジンから必要なぶんだけ段階的に効かせます。そして優先順位は、リクエスト単位のx-omniroute-compressionヘッダを最上位に、コンボ設定→有効プロファイル→自動トリガーの順で解決され、適用結果はX-OmniRoute-Compressionレスポンスヘッダに echo back されます。「常時ONの安全既定はLite、ツール出力が多いセッションだけコンボでRTKを積む」といった使い分けが、設定を汚さずに実現できます。

圧縮の思想は、実は既存の有名OSSから継承されています。ルールベース散文圧縮のCaveman(★78K超の「why use many token when few token do trick」)、コマンド出力圧縮のRTK(Rust Token Killer)(★67K超)、MicrosoftのLLMLingua-2、表形式記法のTOONなど——OmniRouteはこれらの発想を1つのパイプラインに束ねています。散文の実例を見ると効き目が分かります。

# Standardモードの実例
Before(69 tokens):
"The reason your React component is re-rendering is likely because
 you're creating a new object reference on each render cycle. ..."

After(19 tokens):
"New object ref each render. Inline object prop = new ref = re-render.
 Wrap in useMemo."

→ 同じ答え。72%少ないトークン。精度ロスなし。

実際の使用量とコストは、ダッシュボードのUsage画面でモデル別・キー別に追跡できます。

OmniRouteのUsage Logs画面。モデル別・キー別のトークン使用量とコスト(節約額)を時系列で表示する
Usage Logs——圧縮でどれだけ削れたか、どのモデルにいくら“かかった(=節約した)”かが一目で分かる(出典: diegosouzapw/OmniRoute

5. LiteLLM / OpenRouter / Portkey / Heliconeとの比較

「AIゲートウェイ」や「LLMルーター」は今や激戦区です。定番のLiteLLM、SaaSのOpenRouter、エンタープライズ寄りのPortkey、オブザーバビリティ起点のHelicone——それぞれ狙いが違います。OmniRouteの公式比較ドキュメント(2026-Q2時点の公開リポジトリ監査)に、当サイトでHeliconeの位置づけを補って整理したのが次の表です。

項目 OmniRoute LiteLLM OpenRouter Portkey Helicone
プロバイダ数 237+ 約100 約50 約30 パススルー
無料枠プロバイダ 90+ なし パススルー なし なし
自己ホスト ❌(SaaS) ⚠ 有料
自動フォールバック 17戦略 優先度ベース ティアベース 加重 基本的
Fusion(合議+judge統合) ✅(Fusion API)
トークン圧縮 10エンジン なし なし なし なし
内蔵MCPサーバー ✅ 95ツール
A2Aプロトコル ✅ 6スキル
メモリ(FTS5+ベクトル)
オブザーバビリティ ✅ p50/p95/p99 一部 ダッシュボード ✅ 有料 ✅ 中核
主眼 全部入りゲートウェイ Python統合 SaaS集約 商用SLA ログ・監視
ライセンス MIT MIT プロプライエタリ プロプライエタリ Apache/OSS
比較表の読み方(誇張に注意)

この表はOmniRoute公式の自己申告値を基にしています。「237」「90+」「95%削減」といった数字はプロジェクト側の主張であり、他ツールの列も1〜2世代前のバージョン監査に基づく点に留意してください。Heliconeは「ログ・キャッシュ・監視」が主眼のオブザーバビリティ・プロキシで、プロバイダを大量にファンアウトするルーターとは設計思想が異なります。用途が違えば“勝ち負け”は決まらない、という前提で読むのが安全です。

公式が示す「どれを選ぶべきか」の指針は明快です。OmniRouteの守備範囲の広さ(プロバイダ数・無料枠・内蔵MCP/A2A・圧縮)が武器になるのは、自己ホスト前提で1プロセスに全部載せたいケースです。

OmniRouteを選ぶ:自己ホストで最大のプロバイダ網が欲しい/内蔵MCPサーバーやA2Aが要る/SaaS課金なしでガードレール・評価・監査が欲しい
LiteLLMを選ぶ:Python中心でlitellm.completion()に密結合したい/k8s・Helmの成熟した本番レシピが欲しい
OpenRouterを選ぶ:自己ホストしたくない/SaaSの従量課金で構わない/全プロバイダを1つの支払いで
Portkeyを選ぶ:商用SLAと稼働保証が要る/運用を持ちたくない/エンタープライズのコンプライアンス機能

同じ「複数LLMを束ねる」でも、セルフホストのチャット基盤という切り口ならDEEIX Chat|複数LLMを1つに束ねるセルフホスト型AI基盤という選択肢もあります。「コーディングツールの後段に置く関所」が欲しいならOmniRoute、「チームで使うチャットUIごと束ねたい」ならDEEIX、と用途で棲み分けると迷いません。

6. セットアップと使い方(Claude Code・Cursor・Codex接続)

OmniRouteのCLI Tools設定画面。Claude Code・Codex・Cursor・Clineなど各ツールをOmniRoute経由に設定するダッシュボード
CLI Tools画面——各コーディングツールをOmniRoute経由に切り替える設定を一元管理(出典: diegosouzapw/OmniRoute

導入は驚くほど短い手順で終わります。まずnpmでグローバルインストールして起動します。ダッシュボードはhttp://localhost:20128、APIは/v1に立ち上がります。

# 1) インストールして起動
npm install -g omniroute
omniroute
# ダッシュボード: http://localhost:20128
# API:          http://localhost:20128/v1

次にダッシュボードのProvidersから、サインアップ不要の無料プロバイダ(Kiro AIは無料のClaude枠、OpenCode Freeは認証不要)を1つ繋ぎます。あとは手元のツールの接続先を書き換えるだけです。

Base URL: http://localhost:20128/v1
API Key:  ダッシュボードの Endpoints からコピー
Model:    auto            ← ゼロ設定スマートルーティング

繋がったかどうかは、/v1/modelsを叩いて確認できます。接続済みモデルの一覧が返れば成功です。

# 2) 動作確認:接続済みモデルが並べば成功
curl http://localhost:20128/v1/models \
  -H "Authorization: Bearer YOUR_KEY"

Docker派なら、永続ボリューム付きで1コマンドです。マルチアーキ(AMD64+ARM64)対応なのでRaspberry PiやARMサーバーでも動きます。

# Docker(永続データ付き)
docker run -d --name omniroute --restart unless-stopped --stop-timeout 40 \
  -p 20128:20128 -v omniroute-data:/app/data diegosouzapw/omniroute:latest

無料だけで固める「$0スタック」の作り方も公式が例示しています。無料プロバイダを複数コンボに積み、自動フォールバックで配信を切らさない構成です。プレフィックス(kr/=Kiro、if/=Qoder、pol/=Pollinationsなど)でモデルを指定します。

kr/claude-sonnet-4.5(Kiro:アカウントあたり月50クレジット程度)
if/kimi-k2-thinking(Qoder:無制限)
pol/gpt-5(Pollinations:キー不要)
lc/LongCat-2.0(10Mトークンの一回きりバックアップ、KYC要)

なお、繋がる先にはClaude Sonnet 5のような最新モデルも含まれます。OmniRouteは新モデルが出るたびにプロバイダ経由で配線を追加しており、auto/codingのような品質優先モードに任せておけば、そのとき最も適したモデルへ自動で寄せてくれます。

「無料」には規約という前提がある

Qoder・Pollinationsなど一部の「永久無料」は本当に上限なしで使えますが、Cookieセッションやアカウントインポートを利用する接続方法の中には、提供元の利用規約(ToS)に抵触し得るものがあります。地理ブロック回避(3段プロキシ+TLSフィンガープリント偽装)やMITM復号といった強力な機能も同様で、使う環境と権限は自分の責任範囲に限定してください。個人の実験と、業務・本番運用とでは、踏み込んでよいラインが違います。

7. アーキテクチャと安全性 — MCP・A2A・ローカルファースト

OmniRouteのAnalytics画面。プロバイダ別のリクエスト数・レイテンシ・コスト・成功率などのメトリクスを可視化
Analytics——p50/p95/p99レイテンシや成功率、コスト(節約額)をプロバイダ別に可視化(出典: diegosouzapw/OmniRoute

OmniRouteは単なる「振り分けサーバー」ではなく、80以上のコマンドを持つCLIコックピットであり、エージェントが自分でゲートウェイを操作するための開いたプロトコルを備えます。ここが「何を代替できるのか」の核心です。

内蔵MCPサーバーは、OmniRouteの全機能——ルーティング・プロバイダ・コンボ・キャッシュ・圧縮・メモリ——を95個のMCPツール(3トランスポート・30スコープ)として外部エージェントに公開します。Claude Codeに丸ごと渡すのも1行です。

# Claude CodeにOmniRouteの全ツールセットをMCPで渡す
claude mcp add-server omniroute \
  --type http --url http://localhost:20128/api/mcp/stream

MCPの基礎から押さえたい人は、当サイトのMCPサーバーとは|仕組み・代表的なサーバー一覧・自作手順を先に読むと、この「ゲートウェイ自体をツール化する」発想がすっと入ります。加えてA2A(Agent-to-Agent)プロトコル(JSON-RPC 2.0+SSE、6スキル)にも対応し、エージェント同士のワークフローにOmniRouteを組み込めます。

守備範囲の広さを、公式の全体像でまとめておきます。

互換性:OpenAI ↔ Claude ↔ Gemini ↔ Responses APIの相互変換、OAuth自動リフレッシュ(PKCE、8プロバイダ)、Batch+Files API
プロトコル:MCP・A2A・ACP・クラウドエージェント(Codex・Cursor・Devin・Jules)
メモリ:FTS5+ベクトル(Qdrant/sqlite-vec)、既定オフ、リクエスト単位で無効化可能
品質・運用:内蔵Evals(ゴールデンセット)、ガードレール(PII・インジェクション・ビジョン)、ヘルスダッシュボード、p50/p95/p99テレメトリ、Webhook、コンプライアンス監査
AIエージェントスキルskills/*/SKILL.mdマニフェストをドロップインで、43スキルが利用可能

動く場所を選ばないのもゲートウェイとしての強みです。npm install -g omnirouteのグローバルインストールに加え、マルチアーキ(AMD64+ARM64)のDockerイメージ、システムトレイ常駐のElectronデスクトップ版(Windows/macOS/Linux)、そしてAndroid上でTermuxを使えばスマホの上で24時間・root不要で動かせます。ブラウザから「ホーム画面に追加」すればPWAとしてオフライン利用も可能です。各ツールをOmniRoute経由に切り替える設定も、omniroute setupのウィザードや、ツールごとのsetup-*コマンド(Claude Code・Codex・Cline・Continue・Cursor・Roo Code・Kilo Code・Aider・OpenCodeなど)、ゼロ設定ランチャーのomniroute launchで自動化されています。ダッシュボードは42以上のロケールに翻訳済みで、初回訪問時にはブラウザ言語を自動検出します。

プライバシーとセキュリティは「ローカルファースト」で貫かれています。OmniRouteはあなたのハードウェア上で100%動くローカルプロキシで、リクエスト経路にOmniRouteのクラウドは入りません。既定でテレメトリを送らず、APIキーとOAuthトークンはAES-256-GCMで暗号化保存。APIキースコープ・IPフィルタ・レート制限・プロンプトインジェクションガード・ループバック限定のプロセス経路など、ハードニングも施されています。すべてMITライセンスで監査可能なので、気になる挙動があればソースを読んで確かめられます。

読者の3つの問いに答えると

① 結局何ができる?——237プロバイダを1エンドポイントに束ね、自動フォールバックとトークン圧縮をかけながら最適なモデルへ流す。② 何を解決する?——APIキー分散・レート制限による中断・想定外のAPI課金・ツールごとの設定地獄。③ 何を代替できる?——LiteLLM/OpenRouter/Portkeyのようなルーターに加え、内蔵MCPサーバー・A2A・メモリ・ガードレールまで1プロセスに畳み込むことで、複数のSaaSレイヤーを自己ホストの1本に置き換えられる。

もっとも、これだけの機能を1プロセスに詰め込む設計は「全部入りゆえの学習コスト」と表裏一体です。237プロバイダも17戦略も10圧縮エンジンも、最初から全部使う必要はありません。まずはomniroute → 無料プロバイダ1つ接続 → autoの最小構成で動かし、レート制限に困ったらコンボを、トークン代が気になったら圧縮を、と必要になった機能だけを足していくのが、このゲートウェイを飼い慣らす近道です。

まとめ——「AIの関所」を自分の手元に置く。 OmniRouteは、乱立するAIプロバイダと膨大な無料枠を、1本のエンドポイントに束ねる「関所」です。17戦略の自動フォールバックで手を止めず、RTK+Cavemanの圧縮でトークン代を削り、内蔵MCP/A2A・メモリ・ガードレールまで自己ホストの1プロセスに畳み込む——その守備範囲の広さは、LiteLLMやOpenRouterといった定番ルーターの一歩先を行きます。

一方で、無料枠の規約リスクやMITM・フィンガープリント偽装といった強力すぎる機能は、使う側の責任範囲を問います。「まず最小構成で動かし、必要な機能だけ足す」——この付き合い方さえ守れば、OmniRouteは日々のAIコーディングから摩擦を確実に減らしてくれる、頼れる関所になるはずです。前身の9routerから数か月で237プロバイダまで育ったこのプロジェクトが、次にどこまで広がるのか。MITで全ソースが読める今、npm install -g omnirouteで自分の手元から確かめてみてください。

参照ソース

OmniRoute(diegosouzapw/OmniRoute 公式リポジトリ) — README・機能一覧・技術スタック・謝辞
OmniRoute vs Alternatives(公式比較ドキュメント) — LiteLLM/OpenRouter/Portkeyとの機能比較
OmniRoute 公式サイト — プロジェクト概要
npm: omniroute — パッケージ・バージョン情報