6月28日、Towards Data Scienceが「We Built a Routing Layer to Cut Our AI Costs. It Broke the Product.」と題した記事を公開した。AIコスト削減を目的としたルーティングレイヤーの導入が品質劣化を招き、コスト削減分を大幅に超える顧客損失を生んだ実例を詳細に報告している。
月10万ドルのコスト削減が、40〜50万ドルの損失を生んだ
月間アクティブユーザー約400万人のSaaSプロダクト向けカスタマーサポートAIエージェントを運営するチームは、推論コストの削減を目的に「ルーティングレイヤー」を構築した。
仕組みはシンプルだ。約20万件の過去サポートクエリで学習したカスタム分類モデルが各クエリを「シンプル」か「コンプレックス」に分類し、シンプルなクエリ（アカウント照会、請求確認、パスワードリセットなど）は安価なモデルへ、複雑なクエリ（返金交渉、プラン変更、統合トラブルシュートなど）は高性能モデルへルーティングする。分類器自体は30ミリ秒未満で動作し、コストオーバーヘッドは無視できるレベルだった。
安価なモデルのトークン単価は高性能モデルの4分の1。本番トラフィックの約65%がシンプル判定され、そこに安価なモデルを当てた。5,000クエリのホールドアウト評価では94%のケースで品質が同等と確認された。段階的なロールアウト（5%→10%→25%→50%→全量）で各フェーズの品質指標はグリーンのまま推移した。
8週間のエンジニアリング工数で、推論コストは従来比約40%まで圧縮。 CFOから感謝のメールが届き、全社ミーティングで成果として発表された。
3ヶ月後、何が起きていたか
問題が顕在化したのはロールアウト完了から3ヶ月後だった。顧客満足度が下がり始め、チャーン（解約率）が上昇した。さらに1ヶ月かけてようやくその原因がルーティングレイヤーに帰因されたが、そのときには4ヶ月が経過し、顧客への影響は既に積み上がっていた。
原因究明に2週間を要した。ルーティング決定ログとフィードバックイベントを結合し、ルーティング層ごとの品質ビューを初めて構築したところ、問題の構造が浮かび上がった。
安価なモデルは分類器が送ってきたクエリの約80%では問題なく機能していた。しかし残り20%は、ホールドアウト評価時とは構造的に異なるクエリだった。
典型例が請求クエリだ。「この請求は何ですか」というクエリは、分類器には「シンプル」に見える。しかし実際の本番トラフィックでは、このフレーズの裏に「不正請求への疑い」「2システム間の決済タイミングのズレ」「通知なしの請求サイクル変更」といった複雑な意図が隠れていた。高性能モデルは会話の中でその複雑性を追う余力があり、正しく対処していた。安価なモデルは表層の意図にだけ答え、顧客が実際には聞いていない質問に回答した。
さらに深刻だったのは、失敗が「見えにくい形」で起きていたことだ。誤答を受け取った顧客の多くはサムズダウンを押さず、ただエージェントから離脱して人間のサポートラインに電話した。AIエージェントの「問い合わせ対応率（deflection rate）」指標は横ばいのまま、別コストセンターの人間サポート件数が静かに増え始めていた。
2つのチームが別々のダッシュボードで別々の予算を管理していたため、この接続は誰の視野にも入らなかった。
最終的に試算された数字が衝撃的だ。ルーティングレイヤーによる推論コスト削減額は月約10万ドル。一方、品質劣化に起因する顧客維持コストと追加サポートコストは月40〜50万ドル。差し引き、約4〜5倍のコスト損失を生んでいた。
なぜ分類器は失敗するのか
この失敗は特定のモデルや分類器の選択ミスではなく、問題空間の幾何学的な構造に起因すると記事は指摘する。
本番クエリの難易度はべき乗分布に従う。大多数は「易しい中心」に集まり、少数が「難しいロングテール」に分布する。フロンティアモデルは易しい中心に対してオーバースペックであり、そこを安価なモデルに置き換えるコスト削減の機会は本物だ。
問題は、分類器が意思決定時点でロングテールを確実に分離できないことにある。分類器はクエリの「表層形式」しか見られない。難しいクエリは易しそうな表層形式の下に隠れている。
分類器が最も正確に機能するのは、モデル選択がほぼ無意味な易しいクエリに対してだ。分類器が最も不正確になるのは、モデル選択が最も重要な難しいクエリに対してだ。
さらに2つのメカニズムが問題を悪化させる。
小規模モデルは「自信を持って」誤答する。 フロンティアモデルは不確実な場合にヘッジしたり確認を求めたりする。小規模モデルは表面上は完全に見えるが意図を外した回答を生成する。その回答は顧客にとって「誤りと気づきにくい」。
分布ドリフト。 分類器が学習した過去データと、本番での実際のクエリ分布は時間とともにずれていく。ユーザーの使い方が変われば、かつて「シンプル」と分類されていたパターンがより複雑な意図を持つようになる。分類器の再学習なしにこのドリフトを検知する仕組みは、多くの実装では存在しない。
※編集部の考察：LLMルーティングはOSSツールとしても活発に開発されており、たとえばRouteLLM（LMSYSによるオープンソースのルーティングフレームワーク）や商用サービスのMartianなどが知られている。これらは分類器の設計やフォールバック戦略に工夫を凝らしているが、本記事が指摘する「計測アーキテクチャの分断」という問題はツール選定とは独立して発生しうる点に注意が必要だ。
計測アーキテクチャの盲点
記事が強調するのは、計測設計の失敗でもある。チームは以下の3点で観測の穴を作ってしまった。
- ヒューマンレビューサンプルをルーティング層別に分離しなかった。 65%が安価なモデルのクエリで占められた集計値は、易しいクエリでの高品質が難しいクエリの劣化を希薄化した。
- オフライン回帰スイートのクエリセットが古かった。 ルーティング導入の6ヶ月前に構築されたもので、実際の本番分布を反映していなかった。
- フィードバックウィジェットのS/N比が低すぎた。 サムズダウンは1,000インタラクションに3件程度で、大きな回帰以外は検出できなかった。
これらの盲点はルーティングレイヤー固有のものではなく、既存の計測アーキテクチャに潜在していた問題だった。単一モデル運用時は問題が表出しなかったが、2つの品質分布が生まれた瞬間に露呈した。
チームが取るべきだったアーキテクチャ
記事は「ルーティングするな」とは言っていない。ルーティングを行う場合に必要な計測・設計の変更として以下を挙げている。
- ルーティング層別の品質計測を最初から組み込む（集計値だけ見ない）
- コストと品質の指標を同じダッシュボードで可視化する（チームをまたいでも）
- 分類器の信頼スコアに閾値を設け、低信頼クエリは高性能モデルにフォールバックする
- 分布ドリフトを検知する仕組みを持つ（分類器の定期的な再評価）
- 人間サポートへのエスカレーション数を、AIエージェントのコストと同じフレームで追跡する
コスト最適化の成果は推論チームのダッシュボードに現れ、品質劣化のコストは顧客体験・サポート・リテンションのチームに分散する。この構造的な「計測の分断」こそが、このパターンが繰り返される根本原因だ。
詳細はWe Built a Routing Layer to Cut Our AI Costs. It Broke the Product.を参照していただきたい。
