モデルルーティングと決定論的ワークフロー：AIコスト削減に効くのはどちらか

要点

• RouteLLMはGPT-4の品質を95%保ちながら、MT Benchでコストを85%以上削減しました。ただしルーティングが下げるのは1回あたりのモデルコストであり、アーキテクチャ全体の費用ではありません。
• 本稿のコスト試算では、同じ処理量が完全に確率的な構成の月額約300ドルから、ルーティングの導入で月額約100ドルへ、さらに判断が不要な箇所でモデルを使わない決定論的ワークフローでは月額15〜50ドルへと下がります。
• ルーターによる削減効果は、トークンの膨張、キャッシュの無効化、品質低下の累積を覆い隠しがちです。導入を決める前に、完了したタスク単位のコスト、監査可能性、障害の影響範囲、保守の負担を評価してください。
• 定義が明確でコンプライアンスの比重が大きい業務には決定論的ワークフローまたは静的なモデル選択を、入力が変動し判断の比重が大きい部分にはルーティングやエージェント型AIを充ててください。
• 規制産業の企業はJinba Flowを使うことで、決定論的な処理を前提とした監査に対応できるワークフローをオンプレミスで構築し、エージェント型システムの月額1,000〜5,000ドルの推論費用を回避できます。

結論から言えば、モデルルーティングは推論費用を下げます。RouteLLMのベンチマークでは、GPT-4の品質を95%保ちながら、MT Benchで85%を超えるコスト削減が示されています。しかし、それは下げるべき数字を取り違えています。

ルーティングが最適化するのは、確率的なアーキテクチャにおける1回あたりの単価です。そのアーキテクチャは本番規模では依然として月額1,000〜5,000ドルのLLM API費用を発生させます。決定論的ワークフローはアーキテクチャそのものに手を入れます。同じ量の処理がインフラ費用の月額50〜200ドルで動き、そもそもモデルを必要としない経路では推論コストがゼロになります。

予算の制約を受けるプラットフォームチームにとって、ルーティングはエージェント型システムの内部で有効な最適化です。しかし、それが到達点ではありません。到達点だと考えてしまうことが、自動化プロジェクトが予算を超過する最も一般的な原因です。

Forresterは、エージェント型AIのアーキテクチャを自社だけで構築する企業の75%が失敗すると予測しています。GartnerはAIプロジェクト全般の失敗率をおよそ85%としています。この2つの数字の背後にある構図は同じです。ルーティングを含むエージェント型のアプローチが、決定論的ワークフローならより安く確実に処理できたはずの業務に適用されているのです。逆の事態も起きています。適応的な業務に硬直したロジックを押し付けてしまう場合です。だからこそ、これは一律の推奨ではなく判断基準として扱う必要があります。

モデルルーティングとは何か、実際にどう動くのか。

モデルルーティングは、LLMの呼び出しの手前に置かれる振り分けの層です。ルーターは入力されたクエリごとに、どのモデルが答えるべきかを判断します。易しいクエリは小型で安価なモデルへ、難しいクエリはフロンティアモデルへ送られます。狙いは、応答品質を落とさずにコストを下げることです。

最もよく公開されている実装はLMSYSのRouteLLMで、GPT-4（高価）とMixtral 8x7B（1回あたりほぼ無償）の間で振り分けを行います。ここで扱われているトレードオフは現実のものです。すべてを最良のモデルに送れば品質は高くなりますが費用も高くなり、すべてを安価なモデルに送れば費用は下がるものの、難しいクエリでの信頼性も一緒に下がります。

RouteLLMは、類似度による重み付けランキング、行列分解、BERT分類器、因果型LLM分類器という4種類のルーターを、公開されているChatbot Arenaの選好データで学習させました。オープンソースであり、評価の方法も適切です。ベンチマークの成績（MT Bench、MMLU、GSM8K）を、高価なモデルへ送った呼び出しの割合に対してプロットしています。

AIゲートウェイとモデルルーターの違いは何か。

ベンダーのマーケティングはこの区別を絶えず曖昧にします。本番環境でルーターを4か月運用した実務者は、はっきりとこう述べています。「モデルルーティング」とはスマートな振り分け、つまり与えられたプロンプトにどのモデルが必要かをその場で予測することを指します。フォールバック、リトライ、可用性の処理はまったく別のソフトウェアです。それはプロバイダールーティング、あるいはゲートウェイと呼ぶべきものです。

この混同が問題になるのは、ゲートウェイ製品がスマートな振り分けに属するコスト削減の言葉で売られているためです。実際に提供されるのは信頼性と複数プロバイダーへの接続であり、コスト曲線ではありません。「モデルルーティングのプラットフォーム」を検討するときは、その製品がタスクの難易度を予測してリクエストごとにモデルを切り替えるのか、それとも単にプロバイダー間でフェイルオーバーするだけなのかを確認してください。推論費用に効くのは前者だけです。

モデルルーティングは本当にコストを下げるのか。

下げます。RouteLLMの数値は、公開されている中で最も明快な根拠です。GPT-4とMixtral 8x7Bの間で振り分けたところ、すべてをGPT-4に送る場合と比べて、MT Benchで85%超、MMLUで45%、GSM8Kで35%コストが下がり、GPT-4の性能の95%が維持されました。「ルーティングで80%削減」という主張の多くはこの数字に行き着きます。伝聞の統計ではなく一次情報であるため、根拠としても持ちこたえます。ルーティングツールはLLMのコスト削減手法という広い全体像の一部にすぎません。その大半は、モデル選択の層にはまったく触れないものです。

本番環境では、この見出しの数字を複雑にする要素が3つあります。いずれもベンチマークのグラフには現れません。

トークン単価は実際のコストを過小評価します。安価なモデルは、強力なモデルが一度で出す結果に並ぶために、より多くのトークンを必要とすることが少なくありません。リトライが増え、推論の連鎖が長くなり、やり取りの回数も増えます。1回あたりでは節約できているように見えるルーターも、タスク全体のトークン量を数えると、かえって多く費やしていることがあります。この差は、実際の請求額とルーターの見積もりを突き合わせて初めて表面化します。

ルーティングはキャッシュの効果を損ないます。セマンティックキャッシュは、繰り返されるクエリに保存済みの結果を返すことで機能します。似たクエリのたびにモデルを行き来するルーターは、そのキャッシュを無効にしてしまいます。キャッシュされたMixtralの応答は、新たなGPT-4の呼び出しの代わりにはならないからです。クラウド利用者7,000人規模で本番のルーターを4か月運用したのちに停止した実務者は、率直でした。コスト削減という点ではキャッシュがルーティングに勝る、議論の余地はない、というのがその結論です。

品質の低下は積み重なります。適さない安価なモデルが返した不適切な応答は、エージェントのループの中で後続のコンテキストを汚染し、スレッド全体を脆くします。後のターンでより強力なモデルにエスカレーションしても、回復には時間がかかります。この種の障害はベンチマークのグラフには現れません。グラフが測っているのはルーターの判断であって、誤った判断のあとに何が起きるかではないからです。

ルーティングは確かにコストを下げます。しかしその効果はベンチマークの計算によって実際より大きく見え、エンジニアリングの工数、評価、保守、品質の後始末といった隠れたコストは、提案資料から抜け落ちている部分です。

コーディングエージェントにモデルルーティングが欠かせない理由と、それが機能しない場面。

コーディングは、ルーティングの利点と限界が最も鮮明に出る領域です。経済的な理屈は分かりやすく見えます。コード生成の依頼の多くは難しいものではないのに、定型的な処理にフロンティアモデルの価格を払う理由はない、というわけです。しかし実務では、コーディングでSonnet相当を下回るモデルを選ぶと、たいてい後悔することになります。小型のモデルが成功した場合でも、そこに至るまでに強力なモデルが直接処理するより多くのトークンを消費することが多く、ルーティングが生むはずだった削減分を目減りさせます。

より興味深いのは、主要なコーディングエージェントがターン単位のルーティングの代わりに何をしているかです。Claude Codeは、リポジトリの情報収集といった特定のサブタスクを、Haikuのような小型モデルへ単一のエージェントコンテキストの内側で委譲します。ターン全体を複数のモデルに振り分けるのではありません。これはエージェント内部での委譲であって、モデルルーティングではありません。判断を要する部分では制御役のモデルを固定したまま、安価で範囲の限られた処理だけを外に出しているのです。

エージェントシステムを構築するプラットフォームチームにとっては、こちらのほうが学ぶところの多い型です。リクエストごとにターン全体でフロンティアモデルが必要かどうかを予測しようとするのではなく、狭くリスクの低いサブタスクを、安定した制御層の内側で安価なモデルに委ねるという考え方です。

モデルルーティングに代わる現実的な選択肢は何か。

「モデルルーティングのプラットフォーム」を並べた記事の多くは、競合するルーターを列挙するだけで、競合するアプローチを比べてはいません。ルーターを購入する前に費用を比べておくべき手法が3つあり、さらに次の節でもう1つのアーキテクチャ上の選択肢を扱います。

セマンティックキャッシュ。リクエストごとに安価なモデルと高価なモデルのどちらが答えるべきかを予測するのではなく、セマンティックキャッシュは過去の似たクエリへの応答を保存して再利用します。実務者のデータははっきりしています。キャッシュは動的なモデル予測よりコストとレイテンシの比率が良好で、処理の途中でモデルが切り替わることによる後続の解析の破綻も起こしません。しかも効果が積み上がります。トラフィックが増えるほどキャッシュのヒット率は上がりますが、ルーティングの削減幅は1回あたりで一定のままです。

ワークフローごとの静的なモデル選択。そのワークフローで確実に動く最も安価なモデルを検証して固定します。リクエストの種類ごとにモデル、パラメータ、プロンプトを分けて持たせます。処理の途中でモデルが切り替わらないため動的なルーティングより出力が安定し、ルーターという障害点と保守対象そのものをなくせます。ある実務者はこう表現しています。「ルーティングは、各タスクに対して最も効率的で、なおかつ十分に有効なモデルを評価して使うようエンジニアに徹底させられないときに行うことです。エンジニアリングの問題ではなく、マネジメントの問題への対処にすぎません」。静的な選択のほうが、エンジニアリングとしての答えです。

決定論的ワークフロー。ルーティングの比較記事がどれも触れない選択肢です。そもそもモデル選択の戦略ではなく、もとからモデルを必要としなかった工程からモデルそのものを取り除く方法だからです。

決定論的ワークフロー：ルーティングの比較記事が挙げない選択肢

決定論的ワークフローとは、固定された条件分岐（if-then-else）の手順です。同じ入力からは毎回同じ出力がミリ秒単位で得られ、その経路にLLMの推論費用は発生しません。エージェント型のワークフローは、ルーターの有無にかかわらず動的に計画を立て、出力は毎回変わり、実行には数秒から数分かかり、LLM費用は1回あたり0.01〜0.50ドル以上になります。

監査可能性の差はこの違いから生まれます。決定論的ワークフローでは、すべての分岐と条件を実行せずに確認できます。この性質があるため、追加の文書化なしにSOC 2やISO 27001、業界固有のコンプライアンス要件を満たせます。エージェント型ワークフローの監査証跡は部分的です。経路が実行時のモデルの判断に左右されるからです。

決定論的ワークフローに保守の負担がないわけではありません。理想化しすぎるべきではありません。（あわせて参照：コスト削減の手段としてプロンプト最適化より決定論的ワークフローが優れる理由）固定ルールのシステムは、想定していた範囲から入力がずれ始めると脆くなり、ルール群そのものが保守の対象へと育ちます。ここで選ぶのは「保守が軽いか重いか」ではありません。LLMの推論コストとルールロジックに対するエンジニアリング上の保守のどちらを負うか、という選択です。処理量の多いワークフローでは、たいてい有利な取引になります。実行頻度が低く件数の少ないものでは、そうならないことが多くなります。

判断基準は両方向に働きます。決定論的な方式が向くのは、業務プロセスの定義が明確で、コンプライアンスが再現性を求め、想定外の挙動が高くつく場合です。エージェント型が向くのは、入力が変動し、最適な経路をあらかじめ決められず、推論が必要な場合です。データにはどちらの失敗も現れています。推論の比重が大きい業務に固定ルールを押し付けて失敗する企業は、もともと決定論的だった処理にエージェント型のパイプラインを走らせて失敗する企業と同じくらい多いのです。「常に決定論的に」は「常にルーティングを」と同じくらい誤っています。

本番では、決定論的ワークフローは汎用のオーケストレーション基盤の上に構築されるのが普通です。Zapier、n8n、Apache Airflow、AWS Step Functionsなどです。エージェント型の側はLangGraphやCrewAI、あるいは独自のエージェントループで動きます。この分かれ方には意味があります。決定論的な側はもともとAI製品を必要としてこなかったため、推論コストの問題をAIで解こうと探し始めたチームからは見落とされやすいのです。

コストの試算：300ドルから100ドル、そして15ドルへ

同じ処理量の1つのワークフローを、3つのアーキテクチャで順に見ていきます。

完全に確率的な構成は、すべてのリクエストを高性能なモデルが処理し、コスト管理を一切行いません。本番規模（1日あたり約10万回の実行）では、エージェント型ワークフローのLLM API費用は月額1,000〜5,000ドルになります。説明のために規模を落とすと、月額約300ドルです。

ルーターを追加する場合は、RouteLLM型で難しい部分だけを高価なモデルへ送る形になります。同じ処理量は月額100ドル前後まで下がります。GPT-4の品質を95%保ちながら85%削減したというRouteLLMの結果と整合します。実際の削減であり、多くのルーティング製品の説明はここで止まります。

決定論的なアーキテクチャへ移行すると、文書の受け取り、項目の抽出、承認の振り分け、既知の基準に照らしたコンプライアンス確認が、すべてLLMを呼ばない固定ロジックとして動きます。コストの下限は月額15〜50ドルまで下がり、規模を持つ決定論的ワークフローのインフラ費用のみの水準である月額50〜200ドルの下端に対応します。

月額100ドルと15ドルの差を生むのは、優れたルーターではありません。もともと判断を必要としなかった工程からモデルがなくなったことです。

比較：ルーティング、キャッシュ、静的選択、決定論的ワークフロー

企業の購入担当者が実際に使うべき評価基準は何か。

プラットフォームチームが特定のワークフローに何を選ぶにせよ、評価は4つの軸で行うべきです。本当のコスト削減と、本番で通用しないベンチマークの数字を分けるのがこの4つです。

コストは呼び出し単位ではなく、完了したタスク単位で見る。ルーターの1回あたりの削減は、安価なモデルでのトークンの膨張や、モデルの切り替えによるキャッシュの無効化で相殺されることがあります。リトライや後始末も含めて、タスク全体で費用を見積もってください。

監査可能性。実行せずに経路を確認できるか。ここで規制対応の可否が決まります。決定論的な経路は書面のうえで確認できます。エージェント型の経路は、ルーティングの有無にかかわらず部分的にしか確認できません。実際の経路が実行時のモデルの判断に左右されるからです。

障害の性質。影響はどこまで広がるか。決定論的な障害は、誤った分岐が静かに通るか、明示的なエラーになるかのどちらかで、見つけて直せます。エージェント型の障害は、特にルーティングを伴う場合、後続のコンテキストを汚染してスレッド全体の品質を落とします。事後にしか気づけず、元に戻すのに費用がかかります。

保守コストは、双方について正直に測る。決定論的なシステムは、業務プロセスの変化に応じて開発者の手当てが要るルールを積み上げていきます。ルーティングやエージェント型のシステムは、評価、品質の監視、キャッシュの調整といった作業を積み上げます。どちらも保守が不要ということはありません。問うべきは、どちらの負担が自チームの人員配置とワークフローの変化の速さに合うか、です。

この4つの軸を合わせると、「ルーティングでコストは下がるのか」という問いは、ベンチマークの話からアーキテクチャの意思決定へと変わります。そして多くの場合、文書処理やコンプライアンスの比重が大きい企業のワークフローは決定論的な側に寄り、ルーティングは本当にモデルが必要な変動部分に限定される、という結論に向かいます。

Jinbaのような決定論的処理を前提としたプラットフォームが適する領域

規制産業の企業、たとえば従業員2万人以上の銀行、保険、医療、法務、製薬にとって、ここまでの判断基準は机上の話ではありません。日々の前提条件そのものです。コンプライアンスは再現性を最低条件として求めます。そしてそのことが、規制産業の企業がLLMのコスト最適化に取り組む方法を根本から変えます。

Jinbaは、その制約を前提に作られています。このプラットフォームは約80%をルールで実行するワークフローを動かし、判断が必要な工程にだけAIを呼び出します。契約書の条項の解釈や、KYC書類の曖昧な項目などです。すべての工程をモデルに通したうえで、どのモデルが答えるかを最適化するのではありません。もともとモデルを必要としなかった工程から、モデルを取り除くという考え方です。

本番規模では、このアーキテクチャがコストの差を生みます。同等の確率的なエージェント処理が月額300ドル超であるのに対し、月額5〜20ドルです。おおよそ15〜60分の1の開きです。

SOC 2に準拠し、決定論的な処理を前提としたJinbaの設計からは、2つのことが導かれます。

• オンプレミスでの導入により、外部遮断環境にも対応できます。データの所在地や規制の定めによって文書を外部の推論APIへ送れない場合、どれほど賢く振り分けても解決にはなりません。ルーティングもまた外部のモデルを呼び出す必要があるからです。
• 監査ログ、RBAC、SSO、AD連携は、追加の計装なしにワークフローへ付随します。ルールで動く分岐がすべてあらかじめ定義されているためです。

Jinbaは2つの製品に分かれています。Jinba Flowは、技術者や準技術者のチームがチャットまたはビジュアルエディタでワークフローを構築し、API、バッチジョブ、MCPサーバーとして公開する場です。Jinba Appは、技術者でない利用者が、自動生成されるフォームを備えた対話型のインターフェースからそのワークフローを実行する場です。一度作れば、運用チーム全体が同じ権限設定のもとで実行できます。個々のAIツールでは、規制対象のワークフローがチーム単位で必要とする監査証跡や共通のガバナンスを、コンプライアンス部門に提供できません。

この用途でJinbaだけが選択肢というわけではありません。Airflow、Zapier、n8n、Step Functionsは決定論的なロジックを組む標準的な部品であり、エンジニアリングの体制があるチームは自前で構築できます。Jinbaの位置づけは、決定論的処理とAIを組み合わせた仕組みを社内で作ると数か月がかりで数十万ドル規模になりがちな、規制産業の企業に特化しています。これは、従来のRPAを作り直すときに各社が思い浮かべる期間と同じです。ワークフロービルダー方式であれば、ルールのロジックとAIの工程を同じツールの中で組み立てられるため、それを数日にまで短縮できます。

どれを選ぶべきか

モデルルーティングは、処理の難易度が変動し、あらかじめ定義できない判断が求められ、評価の実行と品質の変化の監視にあてられるエンジニアリングの体制がある場合に向きます。クエリの複雑さが予測できない顧客向けのチャットが、その典型例です。

セマンティックキャッシュまたは静的なモデル選択は、クエリの型が大きく重複する場合や、そのワークフローに必要なモデルが十分に分かっていて、リクエストごとに予測せず一度固定できる場合に向きます。毎回違うモデルが要るのではなく、一度のモデル選定を誤ることが本当の問題であるチームにとっては、負担が軽い方法です。

決定論的ワークフローは、業務プロセスの定義が明確で、コンプライアンスが再現可能な経路を求め、モデルの想定外の挙動による損失が柔軟性の価値を上回る場合に向きます。文書処理、KYCの確認、保険金請求の受付、引受審査などです。銀行に絞った例としては、決定論的ワークフローによるAIコストの削減が参考になります。

決定論的処理を前提としたプラットフォーム（Jinbaなど）は、そのコンプライアンス要件が企業規模と重なる場合に向きます。外部遮断環境への導入、監査とアクセス制御の要件があり、ルールロジックを人手で作って保守すること自体（18か月で200〜500件まで積み上がるルール）が独立したエンジニアリング業務になってしまうほどワークフローが多い場合です。

規模のある組織の多くは、これらを複数組み合わせて使うことになります。変動する部分にはルーティングやキャッシュを、それ以外にはすべて決定論的なロジックを充てるという形です。高くつく誤りはルーティングを使うことではありません。もともと決定論的だった大部分の業務にエージェント型のアプローチを適用することです。Forresterは、エージェント型AIを自社だけで構築する企業の4分の3が失敗すると見ています。ルーティングは、モデルを必要とする部分の内側では優れた最適化です。しかし、どの部分がそれにあたるのかを見極める作業の代わりにはなりません。

よくある質問

モデルルーティングはAIゲートウェイと同じものか。違います。ゲートウェイが提供するのは複数プロバイダーへの接続とフェイルオーバー、つまりプロバイダーが停止したときの動作です。スマートなモデルルーティングは、タスクの難易度に基づいてどのモデルが答えるべきかを予測します。「ルーター」として売られている製品の多くは実際にはゲートウェイであり、コスト削減の主張がそのまま当てはまるわけではありません。

ルーティングと決定論的ワークフローは併用できるか。できますし、実務ではたいてい併用されています。決定論的なロジックが定義の明確な再現可能な部分を担い、ルーティング（または静的なモデル選択）がモデルの判断を要する部分を担います。両者は競合する買い物ではありません。ルーティングはエージェント型の層の内側で働き、決定論的ワークフローはそもそも工程からモデルの必要性をなくします。

小型で安価なモデルなら必ず費用は安くなるのか。そうとは限りません。安価なモデルは、強力なモデルが一度で出す結果に並ぶために、より多くのトークンやリトライ、推論の手順を必要とすることがあります。不適切な出力を直すエンジニアリングの工数まで含めると、見かけ上の削減幅は急速に縮まります。

ルールで動くシステムがいずれ作り直しを必要とするのはなぜか。決定論的なロジックは実行のコストこそ安いものの、保守が無償というわけではありません。業務プロセスが変われば、ルールもそれに合わせて変える必要があります。一般に18か月で200〜500件のルールが積み上がります。トレードオフは、実行時のコストが低く監査可能性が完全である代わりに、ルールそのものへ継続的にエンジニアリングの手を入れる、という形になります。