何が起きたか
研究者グループが、AIタスクを適切なモデルへ動的に振り分ける枠組み「Agent-as-a-Router」と、その具体実装「ACRouter」を公開しました。コードはGitHub、オーケストレーターのモデル重みはHugging Faceで、いずれもApache 2.0ライセンスです。Claude Code、Codex、OpenCodeと互換性があり、既存の開発ワークフローにそのまま差し込めます。
中核は「Context-Action-Feedback（C-A-F）ループ」です。ルーターがプロンプトとタスクのメタデータ（プログラミング言語や難易度など）を見て、過去の類似タスクをメモリから検索し、モデルを選んで実行し、その結果の成否をメモリに書き戻す。この一巡が回り続けます。
なぜ重要か
従来のルーティングは、手書きルールによるヒューリスティクスか、過去データで学習した静的な分類器の二択でした。どちらも「入力テキストしか見ていない」という致命的な情報欠損を抱えます。選んだモデルが実際にタスクを完遂できたかどうかを、ルーターは永久に知らないのです。
論文はこの静的ルーターの弱点を3点に整理しています。運用開始後に新しい実行フィードバックを取り込めない情報の凍結、企業データやユーザー行動が変化したときの分布外（OOD）への一般化失敗、そして次々と登場する新モデルへの追随不能（モデルチャーン）です。
C-A-Fループはここを突きます。たとえばSQL生成タスクをKimiのような軽量モデルに振り、存在しないカラム名をハルシネーションしてコンパイルに失敗したとします。ループはそのコンパイルエラーをログに残し、次に似た問い合わせが来たときはClaude Opus 4.8のような上位モデルへ回す。失敗が資産に変わる設計です。
アーキテクチャと評価
ACRouterはOrchestrator（行動フェーズ＝モデル選択）、Verifier（フィードバックフェーズ＝出力の成否判定）、Memory（ベクトルストア上の文脈フェーズ）の3要素で構成されます。Verifierはツール層を介してPythonコードインタプリタ、エージェント用サンドボックス、データベースエンジンといった実行環境に接続され、「動いたかどうか」を現実世界から取ってきます。OrchestratorはQwen 3.5ベースの0.8Bパラメータという極小アダプターで、自社ホスティングが可能です。
評価用に約1万タスク・8つのフロンティアモデルの検証済みスコアを持つCodeRouterBenchも公開されました。ここで浮かび上がったのは「万能モデルは存在しない」という事実です。Claude Opus 4.6は平均性能こそ最高でしたが、アルゴリズム設計ではGLM-5に相対86%、テスト生成ではQwen3-Maxに111%の差で上回られています。しかもOpusのコストはKimi-K2.5のような小型モデルの約12倍。ACRouterはコストと性能のパレートフロンティア上に位置し、ID（分布内）タスクとOODのエージェント型プログラミングテストの双方で、最も低い累積リグレット（時間経過に伴う非最適な振り分けの少なさ）を記録しました。
効く領域と効かない領域
研究者自身が適用範囲を限定している点は誠実です。コーディングやデータ検索のように成否を機械的に検証できるタスク、分布シフトが起きる領域、モデルごとに得意分野が割れている領域で効果を発揮する一方、些末なタスクや低ボリュームな用途にはオーバースペック。創作のようにフィードバック信号を標準化できない主観的領域には使えません。
💼 事業会社視点：これは自社にどう効くか
まず見るべきは自社のLLM請求書の構成比です。同一ベンチマークで34.02ドルが13.21ドルになる、つまり検証可能なタスクなら最上位モデル一択の運用は6割方の無駄を抱えている可能性がある、ということです。月間数百万円規模でAPIを使っているSaaS事業者や、コード生成をプロダクトに組み込んでいる企業にとって、これは粗利率の話に直結します。
特に効くのは受託開発・SIerです。生成コードがコンパイルできるか、テストが通るかという成否シグナルが自動で取れるため、C-A-Fループがそのまま機能します。Orchestratorが0.8Bでセルフホスト可能かつApache 2.0という点も、顧客データを外に出せない案件では効きます。逆にECの商品説明文やマーケコピー生成のように「良し悪しが主観」の領域には、この仕組みは効きません。ここを混同して全社導入を掲げると失敗します。
経営判断としては二つ。第一に、モデル選定を「調達の一回きりの意思決定」から「継続的に最適化する運用パラメータ」に格下げすること。GLM-5がアルゴリズム設計でOpus 4.6を86%上回るような逆転が起きる以上、単一ベンダーへの固定は性能でもコストでも損です。第二に、自社タスクの成否を機械判定できる形に定義し直すこと。検証可能性こそが、この種の最適化を使えるかどうかの分水嶺になります。