Weaveは、Claude Code・OpenAI Codex・Cursorなどのコーディングエージェントに対応したモデルルーター「Weave Router」をElastic License 2.0のもとでソース公開した。AIエージェントが発行する各推論リクエストを自動的に最適なモデルへ振り分けることで、品質や開発速度を維持したまま、トークンコストを40%削減できると報告している。

Weave Routerとは何か

Weave Routerは、コーディングエージェントとAIプロバイダーのAPIの間に挟まるプロキシサーバーだ。開発者は今まで通りClaude CodeやCursorを使い、APIの向き先をlocalhost:8080に変えるだけでよい。ルーターがAnthropicのMessages API・OpenAIのChat Completions API・Gemini APIのいずれの形式でも受け付け、裏側で最適なモデルへ転送してくれる。

対応モデルはフロンティアモデル（Claude Opus 4.8、GPT-5.5）からOSSの軽量モデル（DeepSeek V4 Flash、GLM 5.2、Kimi K2.6）まで幅広い。OpenRouter経由でほぼあらゆるOpenAI互換エンドポイントにもつなげられる。

強化学習（RL）で実現した賢い振り分け

「どのモデルにどのリクエストを送るか」の判断が本プロジェクトの肝だ。Weaveはルーティングモデル自体を強化学習で訓練した。数万件のエージェントトレースを学習データとし、「選んだモデルがタスクを正常に完了できたかどうか」を報酬として与えることで、最適な振り分けポリシーを習得させている。

具体的な挙動の例が公式情報で紹介されている：

  • 複雑な変更の計画立案 → Claude Opus 4.8（高い推論力が必要）
  • コードベースの文脈収集（サブエージェントの探索フェーズ） → DeepSeek V4 Flash（速度・コスト優先）
  • 確定した計画の実装 → GLM 5.2（速くて安いモデルで十分）

エージェントが一連のタスクを処理するなかで、フェーズに応じてモデルを使い分けるのがポイントだ。重い判断が必要な場面だけ高性能モデルを使い、定型的な処理は安いモデルに流す。

セットアップは30秒

ホスト版を使う場合、コマンド1本で導入できる。

npx @workweave/router

インタラクティブなウィザードが起動し、Claude Code・Codex・opencodeのどれに接続するかを選ぶと、対応する設定ファイルを自動で書き換えてくれる。Node.js 18以上が必要。

自分の環境でセルフホストしたい場合はDockerとPostgreSQLを使った構成も提供されており、make full-setup 1コマンドで立ち上げられる。ルーターのWebダッシュボードからOTLPトレースを確認でき、HoneycombやDatadog・Grafanaとの連携も可能だ。プロバイダーAPIキーは自分のマシン上に暗号化して保持される（BYOK方式）。

ライセンスの注意点

Elastic License 2.0（ELv2）はソースコードを公開しているが「オープンソース」ではない。マネージドサービスとして第三者に提供する用途は制限されており、内部利用・セルフホストは可能という位置づけだ。商用展開を検討する場合はライセンス条文を確認することを勧める。

実務への影響

AIコーディングエージェントを業務に導入している日本のエンジニア・IT管理者にとって、コストは無視できない課題だ。Claude Opus 4.7→4.8のバージョンアップでトークナイザーが変更され、同じ作業でも請求額が跳ね上がったという声は実際に聞こえてくる。

導入を検討する際のポイント：

  • まず計測から — 自社のエージェント利用ログを取り、どのフェーズで何トークン使っているか把握することが前提。大半がコード探索・文脈収集に費やされているなら効果が高い
  • セルフホストが安全 — 社内コードをホスト版に通すのはデータガバナンス上リスクがある。社内環境での検証にはセルフホスト構成を選ぶべきだ
  • OSSモデルの品質を見極める — DeepSeek・GLMは強力だが、コードの品質やセキュリティ要件によっては使えないケースもある。A/Bテストで自社タスクへの適合性を確認したい
  • Cursor利用者はまず試す価値あり — CursorはデフォルトでOpenAI互換APIを使うため、ルーターの向き先変更が比較的容易に設定できる

筆者の見解

AIエージェントが1つのタスクを実行するなかで、何十回もLLMへのリクエストが発行されるのは今や当たり前だ。その全リクエストをOpusなどの最高性能モデルへ投げ続けるのは、電気代を気にせず全ての家電を最大消費電力で動かし続けるようなもので、そもそも設計として筋が悪い。

Weave Routerが面白いのは「ルーティングの判断を人間が書いたルールではなく、エージェントトレースから強化学習で習得させた」という点だ。フェーズを人間が分類するのではなく、何万回もの試行から「このコンテキストにはこのモデル」を機械に学ばせた設計は、エージェントの動作実態に即した現実的なアプローチだと思う。

エージェントが自律的にループして仕事をこなす「ハーネスループ」的な使い方が広がるほど、リクエストの種類と量は爆発的に増える。そこで総コストを抑えながら全体の品質を保つための仕組みとして、モデルルーターというレイヤーは今後ますます重要になるはずだ。

一方で、自前で運用するならルーター自体のメンテナンスコストと、複数モデルプロバイダーへの契約管理が発生する。費用対効果は利用規模に比例するため、月に数万円以上のAPIコストが出ていないチームには過剰投資になりかねない。まずは計測し、コスト構造を把握してから検討するのが正しい順序だ。

出典: この記事は Show HN: Smart model routing directly in Claude, Codex and Cursor の内容をもとに、筆者の見解を加えて独自に執筆したものです。