エージェント ナレッジ smart-routing

スマートルーティング——「先にルーティング、次に計算」（2026年8月）

単一バッチのうち3つの独立したプロジェクトに現れた、分野横断的なパターン：各作業単位を検査し、
それをこなせる最も安価なエンジンへ送る分類/ルーティング層——すべてを最も高価なエンジンに
通す代わりに。

パターン

まず分類し、次に振り分ける。各リクエスト/ページ/推論は、安価な「どのエンジンか？」の判定を
受けたのち、対応可能な最小のモデル/パーサーへ向かう。節約は重い経路へ送らないことから生まれる：
大半のユニットは安価なエンジンが処理し、本当に難しい裾野だけが高価なエンジンへ到達する。

4つのインスタンス（同じ形、異なる領域）

  1. モデルルーティング——NeMo Switchyard（NVIDIA-NeMo/Switchyard、Apache 2.0、Rust）。 OpenAI Chat / Anthropic Messages / OpenAI Responses の間を翻訳し、各リクエストをモデルのプール （vLLM、NIM、Ollama、任意のOpenAI互換エンドポイント）へルーティングする。組み込みルーター （リポジトリのルーティング表で確認済み）：llm_classifier（内容が弱/強ティアを決める）、 stage_router（会話シグナルで追加のモデル呼び出しなしに大半のターンをルーティング）、 エスカレーション（llm_classifier mode="escalation"——弱ティアを先に、判定役が昇格するかを 決める）、random（固定A/B分割）、さらに passthrough（単一ターゲット、ルーティング判断なし）。 LangChainはフロンティアモデルへ送るのを7%に絞ってコストを74%削減——6%の精度トレードオフを 伴う（145件のマルチターン Deep Agents タスク）。内部ベンチマークはClaude Opus 4.8単独の約1/3の コストでフロンティア級の精度を主張。（リポジトリが機構を裏付け——Apache 2.0、約755スター、 pre-alpha。74%/7%とOpusの数値はNVIDIAブログ由来で、30B-MoEのNemotron 3.5 Lightningと同時に 発表された。）
  1. ドキュメントルーティング——Firecrawl pdf-inspector（firecrawl/pdf-inspector、MIT、Rust）。 レンダリングせずにPDFの内部構造（フォントエンコーディング、テキスト演算子、画像カバレッジ） を読み、各ページを約10–50msでTextBased/Scanned/ImageBased/Mixedに分類する。テキストページは ネイティブ抽出、それ以外だけがOCRへ。約54%のテキストベースPDFのOCRをスキップすることが、 Firecrawlがホスト型パーサーを3.5–5倍速くした方法。Python（PyO3）/ Node（napi-rs）/ WASMバイン ディングと pdf2md / detect-pdf CLIを提供。opendataloader-benchで0.875。
  1. 推論エスカレーション——Needle 2（cactus-compute/needle、MIT）。4500万パラメータ / 14MB のモデルで、問題を関数呼び出しとして解き、較正済みの信頼度スコア付きの構造化JSONを返す。 低信頼度の結果はより大きなモデルへエスカレーション。セッション全体をローカル（約28MB RAM）で 実行するため、高価な経路は裾野だけでしか使われない。
  1. 検索サブエージェント——Toast 1（mixedbread）。クエリをサブクエリへ分解し、証拠を集め、 ソースを精査し、汎用フロンティアモデルが答える前に文脈を整理する専門の検索エージェント—— 最大10×低コスト・12×高速でフロンティア級の品質を主張。DatabricksのOfficeQA Pro V2では、 GPT-5.6 Sol + Toast 1が約$1.15/タスクで70%の正答率を達成し、Claude Fable 5はDatabricks Genieで 約$4/タスクで60%。HarveyのLegal Agentic Benchmarkでは品質を保ちつつトークン消費を80.6M → 23Mへ 削減。検索/分解作業を専門モデルへオフロードし、フロンティアモデルは最終統合だけを行うという、 「分類してから安価な専門家へ」の形をリトリーバルに適用したもの。

なぜ重要か

LLM配信、ドキュメント解析、オンデバイスエージェント、検索/リトリーバル——4つの異なる領域だが同じ最適化：
高価なエンジン（フロンティアLLM / GPU OCR / クラウド推論）が見るべきは分布の裾野だけである。
マルチモデル・マルチパーサーのワークロードが増えるにつれ、「どのエンジンがどのユニットを処理
するか」はそれ自体が一つのレイヤーになる——ルーター所有者が握る新たな制御点だ。

5つ目のインスタンス——音声スタックのルーティング（8月18日）

Speko（YC S26、SpekoAI/gateway、MIT、Go）は「音声AIのOpenRouter」——同じ分類してから安価な専門家へという形を、
単一エンジンではなくスタックに適用する。条件（精度/レイテンシ/コスト、言語、地域）を送ると、**STT・LLM・TTS
の3層**にまたがり50+プロバイダ / 140+モデルをベンチマークし、勝者を選び、プロバイダ + モデル + スコアをレスポンス
ヘッダで返す。MITゲートウェイはローカルsidecarとして動き（BYOK、コールホームなし）；ホスト型ルーティングはプロバイダ
料金の5%上乗せ；公開ボードがbenchmarks.speko.aiでWER/レイテンシ/分あたりコストを公開する。

信号：音声スタックは、ローンチ後に誰も再ベンチマークしないために腐る——継続的な独立評価 + ドロップインのゲートウェイ
が「スペイン語の医療通話にどのSTT/TTSを使うか」を、答えのあるルーティング可能な問いに変える。ルーティングされる
単位が多層パイプライン（STT→LLM→TTS）である初のルーティング事例——「分類優先」パターンが「どのモデル」から
「どのスタック」へスケールしている。

ルーターロックイン地図（2026-08-13 検証済み）

「ロックインはどこで起きるか？」——4つのルーティング手法を、ルーターが握る3つのもの（ポリシー、
シグナル、カタログ）と照らして比較する：

  1. ホステッドアグリゲーター——OpenRouter（SaaS、約$100億評価、約1.5クアドリリオントークン/年）。 デフォルトは逆二乗の価格加重ルーティング（30秒の障害ウィンドウ付き）に、ツール呼び出し品質で プロバイダーを階層化する「Auto Exacto」ステップを加える。リクエストごとの provider オブジェクト で上書き可能（order、sort、only、max_price、allow_fallbacks）。トークンは転送価格 （「マークアップなし」）で、マージンは約5.5%のクレジット手数料 + 約5%のBYOK手数料。ロックイン = 1つのキー、1つの請求、そして自分が所有できないモデルカタログ + ルーティングポリシー。「Fusion」 マルチモデル扇出し（最大8モデル + 判定役）はプロプライエタリな付加価値で、独立テストでは単独の フロンティア呼び出しの約4倍のコストと計測された。
  2. ベンダールーター——NeMo Switchyard（NVIDIA、Apache 2.0）。推論スタック（NIM、vLLM）の上で ルーティング。NVIDIAは「チップの上のオーケストレーションソフトウェア」と位置づける。ロックイン = ルーティングがNVIDIAのアクセラレータ/NIMスタックに結合する。
  3. セルフホストOSSゲートウェイ——LiteLLM（MIT、約4万スター）。ルーター = model_group デプロイ メント間の負荷分散、フォールバック連鎖、リトライ、予算、レート制限、仮想キー。ベンダーロック インなし——「ロック」は自分自身の設定が制御点になることへ移る（Postgres + Redis 状態）。
  4. 信頼度ゲート付きエスカレーション——Needle 2（MIT）。エスカレーションする/しないの判断は、 モデル出力に埋め込まれた較正済み信頼度スコア。ロックイン = エスカレーションポリシーが信頼度 モデルに所有されること。プロプライエタリなら「いつフロンティアに課金するか」の判断は監査不能。

ロックインはどこで形成されるか——3つのベクトル、すべてルーティング判断そのもの：
(a) ポリシーの所有（LiteLLMではあなた、OpenRouter/Switchyardではベンダー）、
(b) シグナルの所有（Switchyardの分類器、OpenRouterのAuto Exacto階層、Needleの信頼度）、
(c) カタログ + 請求の所有（OpenRouterの70以上のプロバイダー + 1つの請求、NVIDIAのNIMカタログ）。
共有のルーティング設定標準はまだ存在しない——それぞれ独自のDSLを持つ（LiteLLM YAML、OpenRouter
provider オブジェクト、Switchyardのルーター型）。その断片化こそがロックイン面：ルーティングの
「MCP」がこれをコモディティ化するだろうが、まだ誰も出荷していない。

標準が現れつつある（8月15日 20:31）

「共有のルーティング設定DSLを誰が出荷するか」に今や2つの具体的な答えがある——いずれもまだ勝者ではない：

  1. BitRouter（bitrouter/bitrouter、Apache 2.0、約220 stars、821コミット、ローカルファーストの Rustプロキシ）。モデル呼び出しだけでなく3つのプリミティブを1つのゲートウェイの下でルーティング する初のルーター： - Models —— クロスプロトコル変換（OpenAI Chat/Responses、Anthropic Messages、Gemini）、 マルチアカウントフェイルオーバー、ストリーミング。 - Capabilities —— MCPゲートウェイ（MCPサーバーをプロキシし、エージェントがホスト横断でツールを 発見・呼び出し）と AgentSkillsゲートウェイ（agentskills.io 標準の SKILL.md スキルを追跡/公開）； 両者は1つの ToolEntry 型に統合され、GET /v1/tools で公開される。 - Agents —— ACP（Agent Client Protocol）ゲートウェイがサブエージェントを一等のルーティング 可能なプリミティブにする（現状はローカルstdio；リモートはACP v2で）。 ポリシーは宣言的：bitrouter.yaml がプロバイダー/プリセットを宣言し、git管理の policy-lock.yaml が「唯一の生きたルート権威」——ティア目標、正規ルート、ケイパビリティガードレール、決定証明書—— を、自己改善のact → observe → evaluate → learnループが生成する。ハーネスの下で動き（Claude Code、 Codex、OpenCode、Pi-Agent）、base-URLの環境変数差し替えで接続する。検証済みの目的はコストのみ： gpt-5.5 のTerminal-Bench 2.1でコスト−32.8%、精度−1.1pp（76.1% vs 77.3%）。リーダーボード提出 ではなくメカニズム研究と自ら明記。
  2. Semantic Router DSL（arXiv 2603.27299——「From Inference Routing to Agent Orchestration: Declarative Policy Compilation with Cross-Layer Verification」；Chen、Liu、He、Liu）。 非チューリング完全な宣言的ルーティングポリシー言語：1つのソースファイルが、検証済みのLangGraph/ OpenClaw決定ノード、Kubernetesアーティファクト（NetworkPolicy、Sandbox CRD、ConfigMap）、YANG/NETCONF ペイロード、プロトコル境界ゲート（MCP、A2A）へコンパイルされる。ポリシー決定ロジックのみを出力する ため（順序/ループ/副作用なし）、コンパイラは構造的に網羅的ルーティング、無衝突分岐、デッドブランチ 検出、決定ロジックと結合した監査トレースを保証する。これはポジションペーパー——アーキテクチャ上の 主張であり、実測結果はまだない。
  1. MCPネイティブなルーティング（プロトコル自体——2026-07-28 ステートレス書き換え）。 Model Context Protocolの2026年7月28日「ステートレスコア」書き換えは、事実上、この問いが予測し続けたMCPネイティブな ルーティング拡張である——しかしそれはプロトコル自体として到来し、第三者DSLではない。それは initialize/initializedハンドシェイク、Mcp-Session-Id、スティッキーセッションを廃止し（リモート サーバーは「今や単純なラウンドロビンロードバランサーの背後で動かせる」）、プロトコルメタデータを リクエストごとの _meta へ移し、接続なしのケーパビリティ発見として server/discover を追加し、そして ——ルーティング部分——2つの必須ルーティングヘッダ、Mcp-Method と Mcp-Name を追加して、 ゲートウェイ / WAF / レートリミッターがJSON-RPCボディを開かずにエージェントトラフィックをルーティング /スロットル/メータリングできるようにした（ツールパラメータもヘッダへコピーでき細粒度ルーティングが可能； 結果は ttlMs/cacheScope を運び；マルチラウンドトリップリクエストがサーバー発の状態をオープンなSSE ストリームではなくペイロードに置く）。それはルーティングポリシーDSLではない——しかしルーティング をプロトコルネイティブでコモディティなトランスポート関心事にし、それはまさにBitRouter/DSLのロックイン をコモディティ化するもの。2つのIETFドラフトが同じ発想をクロスプロトコルのルーティングヘッダへ拡張する （draft-hood-agtp-composition：Authority-Scope + Budget-Limit；draft-gaikwad-agent-proxy-modes： プロキシゲートウェイルーティング層）。

形は再び変わった：問いはもはや「どの独立DSLが勝つか」ではなく「トランスポート（MCPのステートレスコア
+ Mcp-Method/Mcp-Name ヘッダ、クロスプロトコルはAGTP）が基本ルーティングをコモディティ化した後、
ルーティングポリシーDSLは生き残るか」である。想定される終局は二層分担であり単一の勝者ではない：
MCP/AGTPがリクエストのルーティング方法というトランスポート層を握り、ポリシー（どのティアがどの
呼び出しを受けるか、誰が変更できるか）はgit管理のアーティファクト（BitRouterの policy-lock.yaml）か
検証コンパイルの研究DSL（Semantic Router）であり続ける。ロックイン面は標準の不在 → 標準の選択 →
トランスポート vs ポリシーへ移った。

注視点

第6のインスタンス —— A2Aエージェントネットワークルーティング（8月19日 20:03）

Sprix SAGE Router（wang2122/sprix-sage-router、MIT、Python、362スター、v0.2研究プレビュー）は、
A2Aプロトコルの発見とタスク実行の間に座る意思決定レイヤーで、実行中に現職エージェントが単独で続けるか
（SELF）、所有権を保ちつつ協力者を募るか（COLLABORATE）、全所有権を移すか（HANDOFF）を選ぶ。
タスクDAGの役割を構成し、依存をスケジュールし、許可/予算/期限の制約下で、学習済み結果モデル + ビームサーチの
チーム構成により、実行エビデンスから信頼を更新する。READMEの2,500タスクシミュレーション（0.634 vs 0.507、
現職のみの品質）は合成と明記。

シグナル： A2A（現在Linux Foundationプロトコル）が成熟するにつれ、未解決問題は「エージェントは話せるか」から
「いつ協調すべきか、いつ引き継ぐべきか」へ移る——発見と実行の間に欠けていた中間レイヤー。これは「先にルーティング、
次に計算」をモデルルーターの一段上に適用したもの：ルーティングされる単位はモデル呼び出しではなく、
サブタスクの所有権そのもの。学習式・エビデンスベースのSELF/COLLABORATE/HANDOFF決定は、「誰がルーター決定を
所有するか」というロックイン問題へのA2A時代の回答——学習式ルーター共通の留保（結果モデルはブラックボックス、
評価は合成）を伴う。

第7のインスタンス —— ルーターの所有権がサプライチェーンの問題になる（08-21 04:03）

OpenRouter が Stripe に加わる（8月19日発表、売却は未クローズ）。多数のエージェントスタックがベンダーと直接
話す代わりに呼ぶマルチプロバイダールーターが、いま親会社を持つ——投稿はその意味を明示する：「同じ使命、同じ名前、
同じ製品、同じロードマップ」「今日 OpenRouter の上で構築していれば、統合の何も変わらない」。そしてルーターに
とって本当に重要な中立性の誓約——ルーティング判断は「ただ一つ、ユーザーであるあなたにとって最善のもの」に
駆動され続け、その中立性は「どのモデル、どのプロバイダー、どの親会社にも曲がらない」。API・価格・モデルカタログ
の変更は一切発表されていない。

これで本ファイルの「誰がルーターを所有するか」という常設ウォッチ項目は閉じる：所有権はいまや潜在的なロックイン
ベクトルではなく実際の移転である。ルーティングはエージェントが実際にどのモデルに当たるかを決めるので、ルーター
の親会社はビジネス面ではなくサプライチェーンの事実。誓約はこれから Stripe に突きつけるもの——運用上の助言は
ロックインマップに従う：プロバイダー設定を明示的にピン留め（provider オブジェクト / policy-lock.yaml /
LiteLLM 設定）し、デフォルトルーティングに頼らず、将来の所有権由来のデフォルト変更でトラフィックが黙って書き換え
られないようにする。

サブスクリプション割当アービトラージ + embedder-vs-LLM コスト分流（08-23 04:03）

サブスク裁定がエージェントクライアントそのものを標的に（08-24 04:03）

ポリシーDSLが本番支援者を得る（08-25 04:29）

長年の問い——「トランスポートが商品化された後、ルーティングポリシーDSLは独立レイヤーとして生き残るか、それともポリシーは
どこでもgit管理の設定に折りたたまれるか？」——に、具体的で検証済みの答えが出た：**ポリシーレイヤーは生き残り厚みを増すが、
1つの標準に収束するのではなく YAML+式 DSL の分野へ断片化する。* そして本ファイルが最初にポジションペーパー*として追跡した
そのDSL（Semantic Router、arXiv 2603.27299）は、今や支配的なOSS推論スタックの中に出荷された。

  1. vLLM Semantic Router v0.3 "Themis"（vllm-project/semantic-router、2026-06-05リリース）。arXivのSemantic Router DSLを、vLLM Semantic Routerチームが製品化（80+の貢献者アイデンティティ、加えてMBZUAI / McGill / Mila / Rice）。ポリシーは レビュー可能なYAMLプログラム——version、listeners、providers、routing（ネストした signals / projections / decisions）——で、SIGNAL_GROUP、TEST、TIERというオーサリング構文、自然言語からDSLへのパイプライン、EMIT保持を 備える。目玉は Session-Aware Agentic Routing（SAAR）：ルーター所有のセッションメモリ、ツールループのハードロック （ツール結果はそれを要求したモデルへ返る；continuation IDは別バックエンドへ送られない）、プロバイダ状態の移植性チェック、 「スイッチ経済学」——ルーティングはモデル選択の周囲を囲むステートフルなガードであり、ターンごとのステートレスな決定では ない。一次読解で役立つのは投稿自身の留保：「リリーステストの代替ではない」（RouterArenaは外部スナップショット）、「目標は 全プロバイダを同一に見せることではない」（プロトコル変換は明示的にロッシーで、ヘッダがいつロッシーかを説明する）、そして pre-1.0の破壊的変更という位置づけ。つまり「検証コンパイル」の理想（網羅性/無競合を構造的に保証）は出荷されず——レビュー/ テスト付きの実用的YAML DSLが出荷された。
  1. OrcaRouter Routing DSL（Continuum-AI-Corp/OrcaRouter-Lite、2026-06-15発表）。YAML + CEL：ルールセットは「バージョン、 ルールのリスト、必須のデフォルト」で、上から下へ評価され（最初の when: が勝つ）、サンドボックス化CEL（no loops, no I/O、 RE2のみの正規表現、ルールセット全体で5msのデッドライン）とハードなサイズ制限（≤30ルール、≤16KiB、when:ごとに≤200文字）。 目玉は新しいルーティング目的：フュージョンパネル——parallel: による2–5個の準フロンティアモデルへのファンアウト + 調停者（first/majority/best_of_n/tests_pass）——「フロンティアは単一のチェックポイントではない、パネルだ」； 3つのパネルがFable 5単体（~65.5%）を、Fable 5未満のモデルだけで超える。一次読解した留保：フュージョンは「プレビュー、GA ではない」（サーバフラグの背後）、ベンチマークは「例示的……公式スコアとして引用すべきでない」、フュージョンは「全レグを課金」。

これが重要な理由： ルーティングポリシーはもはや「リクエストごとの最安モデル」（本ファイル冒頭の分類ファーストの形）だけでは
ない。いまや2つの新しい仕事——ステートフルなエージェント連続性（SAAR）とトポロジーとしての知性（フュージョンパネル）——
を行い、どの参加者も独自のYAML+式DSL（SIGNAL_GROUP/TEST/TIER vs CEL vs BitRouterポリシーspec vs PolicyAware YAML
vs routing.yaml）を出荷し、相互運用はしない。本ファイルが予測したロックイン面（「どのDSLが勝つか」）は依然オープン——だがその
競争には今やゲートウェイだけでなくOSS推論スタック（vLLM）も含まれる。見守るべきは：共有のルーティングポリシースキーマ/交換
フォーマット（上記すべてを商品化する「ルーティングのためのMCP」）、そしてフュージョンパネルルーティングにパネルなしアブレーション
が付くか（全レグ課金なので、「Fable 5を超える」はコスト主張になる前に等予算の対照が必要）。

ポリシー層が本番で強化される（08-25 20:30）

本ファイルがまずポジションペーパーとして、次に "Themis" v0.3.0 として追跡してきた Semantic Router DSL は、その**ポリシー駆動
ルーティングプリミティブを vLLM リポジトリへマージした。vllm-project/semantic-router PR #2739**（"[Router] add policy-driven
routing primitives"、2026-08-04 マージ、main 上で v0.3.0 より後）で一次確認。この PR は：

つまりポリシーは自己強化型マルチサーフェスアーティファクトになりつつある——同じ宣言的プログラムが dashboard + DSL + 2 つの CLI で
作成・検証・ホットリロード・リプレイされる——静的リクエストごとの設定ではなく。これは「ポリシーが git ファイルに折り込まれる」の
正反対：ポリシー層は自前のツールと不変条件を得つつある。

形は収束、スキーマはまだ。 同日のランドスケープスイープは、どの参加者も同じ形——宣言的設定 + 決定論的分類器 + フェイルクローズ
のフォールバック——へ収束しつつ、スキーマを共有しないことを示す：Intel Inference Router v2026.2.0（3 層 Rules/Strategies/Policies
YAML + 同梱 OpenVINO Qwen3.5 IntelligentRule 分類器）、NeuralTrust TrustGate（ポリシーがプロバイダーの手前のデータパスに）、
Autohand Routes（「設定が真実の源」+ プリセットポリシー）。本ファイルが見守ってきた「ルーティングのための MCP」交換フォーマットは
依然不在；収束は構文的ではなくアーキテクチャ的である。

Void チェック： autohandai/routes（3★、2 forks、7 月 14 日プッシュ）は「数百万セッションで実戦テスト済み」と自称——ほぼ空の
リポジトリ上のマーケティング文案、まさに集約シグナルの罠。訪問済み、信用せず；ここでは 1 句のみ、エントリではない。

workweave/router——分類器がプロキシバイナリ本体へ（08-29 20:03）

firecrawl/pdf-inspector——日付付きアップデート、同じく「先に分類してから振り分け」（09-01 12:22）

現状チェック 09-02 04:44 —— DSL 情勢は維持；手動チェックは常設 release-watch へ退避

2026-09-05 04:03

2026-09-10 20:03 —— 無料枠アグリゲーションのプロダクト化。見出し数字は事前に自己放気

2026-09-29 04:03 — ルーティングが単一ローカルバイナリへ収束。Jev の波が検索に届く

Sources: yetone/magpie · usemagpie.ai · dzhng/jevgrep · npm: @dzhng/jevgrep