OmniRoute解説｜340プロバイダを1エンドポイントに束ねる無料AIゲートウェイとLiteLLM比較

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

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

そのうえで、READMEの数字をそのまま書き写すのではなく、リポジトリを実際に落として数え直しました。結果、読む前に知っておくべきズレが2つ見つかっています——「340」はまだリリースされていないmainの数字でnpm install -g omnirouteで入るのは290であること、そして無料系プロバイダではツール呼び出し（function calling）の対応が想像よりずっと薄いことです。どちらも第5章で検証手順ごと示します。

なお本記事は、Claude Code側の設定や運用そのものには踏み込みません。インストールからCLAUDE.md・Hooksまでを通しで押さえたい方は、Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きを先にどうぞ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

とくに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:fastやauto/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%削減

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

これらをワンクリックで組み合わせたプリセットが、冒頭の棒グラフの各モードです。目安の削減率は、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のオフライン評価ハーネスで削減率と忠実度のトレードオフを測ってから強いモードへ上げるのが賢明です。

12エンジンが「何を入れるか」を絞るのに対し、その外側には「どう・いつ・何を出すか」を整える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画面でモデル別・キー別に追跡できます。

5. 実測で確かめた——「340」は何を数えた数字か

ここまではOmniRouteが「掲げていること」を読んできました。この章では掲げた数字を実際に数え直します。OmniRouteはプロバイダ一覧をdocs/reference/PROVIDER_REFERENCE.mdとして自動生成しており（「do not edit by hand」と明記）、これが検証にそのまま使えます。

npmで入るのは340ではなく290

まず、いちばん影響が大きいズレから。READMEの見出しは「340 AI Providers」ですが、この自動生成ファイルのfrontmatterはversion: 3.8.50・lastUpdated: 2026-08-15。一方npmで配布されている最新版はv3.8.49です。つまり340は未リリースのmainの数字で、npm install -g omnirouteで入るのは1つ前の版になります。

README自身も、この差を隠さず表にしています（「The Gateway Keeps Growing」）——v3.8.49が290プロバイダ／1,185モデル、v3.8.50が340プロバイダ／1,202モデル。実際に両方のタグを引いて、一覧のデータ行を数えて確認しました。

# 公開中の最新リリース（npmで入る版）と main を数え比べる
git clone --depth 1 https://github.com/diegosouzapw/OmniRoute.git && cd OmniRoute
git fetch --depth 1 origin refs/tags/v3.8.49:refs/tags/v3.8.49

# main（v3.8.50）の一覧行数 → 340
grep -cE '^\| `[^`]+` \|' docs/reference/PROVIDER_REFERENCE.md
# リリース済み v3.8.49 の一覧行数 → 290
git show v3.8.49:docs/reference/PROVIDER_REFERENCE.md | grep -cE '^\| `[^`]+` \|'

行数はカテゴリ別の見出しに書かれた内訳（No-auth 10・OAuth 25・Web Cookie 35・APIキー 228・ローカル 12・検索 12・音声 12・上流プロキシ 2・クラウドエージェント 3・システム 1）とも一致し、合計はちょうど340になります。数字自体は正確で、ズレているのは「どの版の話か」だけ、というのが結論です。

ツール呼び出しの対応表記があるのは340中14件だけ

もう1つ、コーディングエージェント用途ではこちらのほうが重要です。Claude Code・Cline・OpenCodeといったツールは、ファイルを読む・コマンドを実行するといった動作をすべてツール呼び出し（function calling）で行います。ツール呼び出しが効かないプロバイダに繋ぐと、モデルは「おしゃべりするだけ」になります。

PROVIDER_REFERENCE.mdにはTool calling列があり、native（本物のfunction calling API）／emulated（プロンプト経由の疑似実装）／none（toolsを捨てる）の3値で表記されます。ただしこの列は「where shown」＝一部の表にしか出ません。実際に集計すると、表記があるのはno-auth（10件）とWeb Cookie（35件）の計45件だけで、リポジトリ全体でもtoolCallingの宣言は14件しかありませんでした。

# toolCalling の宣言を種類別に数える（→ emulated 12 / native 1 / none 1）
grep -rhoE 'toolCalling: "[a-z]+"' src/shared/constants/providers/*.ts | sort | uniq -c

無料のClaude枠（claude-web）はツール呼び出しが効かない

そのうえで、noneがただ1つclaude-webに付いているのは見逃せません。READMEの一枚看板は「Claude Code, Codex, Cursor, Cline, Copilot & Antigravity into FREE Claude / GPT / Gemini」——つまり「Claude Codeを無料のClaudeに繋ぐ」が売り文句なのに、その無料Claude枠こそがツール呼び出しを落とす実装になっています。

そもそもClaude Codeが何をするツールなのかを整理したい方はClaude Codeとは？2026年版の基礎解説を、日々の運用を詰めたい方はClaude Codeベストプラクティスを合わせて読むと、「ツール呼び出しが効かない」という事象の重さが掴みやすくなります。

これは推測ではなく、ソースにそう書かれています。src/shared/constants/providers/web-cookie.tsのclaude-web定義には、コメントごと残っています。

// #7286 Level 3 (deferred): still silently drops tools[] — getDefaultTools()
// is a fixed Claude.ai backend contract; needs an emulate-vs-native decision.
toolCalling: "none",

対応するIssue #7286 は「claude-webとgemini-webにツール呼び出しを」という要望で、2026-07-19にcompletedとしてクローズ済みです。ところがクローズ後に生成された一覧（2026-08-15）でもclaude-webはnoneのまま。実装側を追うと理由がはっきりします——疑似実装のシムprepareToolMessagesを読み込んでいるのはgemini-webなど十数個の実行系で、claude-webだけは実行系のどのファイルからも参照していません。

# gemini-web はシムを読む / claude-web は読まない
grep -l "prepareToolMessages" open-sse/executors/gemini-web.ts     # → ヒットする
grep -rl "prepareToolMessages" open-sse/executors/claude-web.ts open-sse/executors/claude-web/  # → 何も出ない

Issueが「completed」なのはgemini-web側（Level 2）が入ったからで、claude-webは「Level 3（先送り）」として意図的に残されている——コメントのdeferredがそう明言しています。Issue本文が挙げる症状は、そのまま利用者の体験です。曰く、エラーも警告も出ずtoolsが静かに捨てられるので、機能未対応ではなく「設定を間違えた」ように見える。

規約リスクのフラグは41件

もう1つ、コードが持っている自己申告値としてsubscriptionRiskがあります。これは「そのプロバイダのサブスクを第三者クライアント経由で使うと規約に触れうる」ことを示す内部フラグで、UIの警告表示（riskNoticeVariant: "webCookie"）に紐づきます。数えると41件（OAuth系18件＋Web Cookie系23件）でした。

grep -rh "subscriptionRisk: true" src/shared/constants/providers/*.ts | wc -l   # → 41

READMEの無料枠会計に出てくる「15プロバイダがToSフラグ」とは数える対象が別（あちらは無料トークン量の集計に含めるかどうかの話）なので、単純比較はできません。ここで言えるのは、コード側は41件に規約上の注意を明示しているという事実です。claude-webにもこのフラグが立っています。無料枠を積み上げる設計は魅力的ですが、業務で使うなら各プロバイダの規約確認は避けて通れません。

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

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

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

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

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

7. セットアップと使い方（Claude Code・Cursor・Codex接続）

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

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

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

ただし繋ぐ相手は選んでください。リポジトリのプロバイダ一覧はKiroに「⚠️ Kiro ToS prohibits third-party proxy/harness use（Kiroの規約は第三者プロキシ／ハーネス経由の利用を禁止）」と明記しており、第5章で見たsubscriptionRiskフラグ41件の1つでもあります。まず試すだけなら規約上の制約が無いものから、恒常的に使うなら各プロバイダの規約を読んでから——が安全です。またエージェント用途では、第5章のとおりclaude-web（無料Claude枠）はツール呼び出しが効かない点にも注意してください。

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のような品質優先モードに任せておけば、そのとき最も適したモデルへ自動で寄せてくれます。

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

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）にも対応し、エージェント同士のワークフローに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で自動化されています。ダッシュボードは43のロケールに翻訳済みで、初回訪問時にはブラウザ言語を自動検出します。

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

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

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

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

参照ソース

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