ルーティング設計：問い合わせを専門家に振り分ける（混同行列まで）

問い合わせが「正しい専門家」に届かなければ、どんなに優秀なAIでも的外れな回答を返します。 本記事では、マルチエージェントの要となる「振り分け（ルーティング）」を、7つの専門家ルートの定義・50件の評価データ・混同行列による精度分析まで一貫して解説します。ラベル設計から改善サイクルまで、再現可能な形で整理しました。

この記事の前提と使い方

本記事は、AIエージェントの4設計要素（TMPE）を前提知識とし、複数の専門家エージェントへ問い合わせを振り分ける設計パターンを扱います。

使い方: まず「ルーティングとは何か」の全体像を掴み、7つのルート定義を参照して自社の振り分け設計に応用してください。50件データと混同行列のセクションは、評価・改善の具体的な進め方として活用できます。

なぜ「振り分け」がマルチエージェントの要なのか

マルチエージェントシステムでは、各専門家（サブエージェント）が「専用のプロンプト」「専用のツール」「専用の評価基準」を持っています。問い合わせがどの専門家に届くかで、回答の質・コスト・安全性がすべて変わります。

ルーティング設計とは、次の4つを同時に最適化する分類問題として捉えることです。

ルーティングの4つの型

実務では「何を選ぶか」によって、ルーティングは4つの型に分解できます。

型の分類

型ごとの特徴

• 意図分類型: 問い合わせの「目的」で振り分ける。最も直感的で、本記事のメインテーマ
• ツール選択型: LLMが「どの関数を呼ぶか」を判断する。構造化出力（JSON形式の指示）で精度を上げる
• 専門家選択型: 単一の専門家に渡す場合と、複数の専門家へ同時に渡す（ファンアウト）場合がある
• モデル選択型: 簡単な質問は軽量モデル、難しい質問は高性能モデルへ。コスト最適化が主目的

MoE（Mixture-of-Experts）との関係

LLMモデルの内部にも「ルーター」は存在します。Mixtral等のMoE（Mixture-of-Experts）モデルでは、入力トークンごとにどの専門家ブロックを通すかを決める「ゲーティング」が働いています。アプリ層のルーティング設計と着眼点が似ており、負荷分散、専門化、誤ルーティングのコストという観点を借りることができます。

7つの専門家ルートの定義

ここからが本記事の核心です。問い合わせを振り分ける先として、7つのルートを定義します。

ルート定義の3原則

ルートを設計するときに守るべき原則は以下の3つです。

1. ラベルが互いに排他的（原則として1つの問い合わせは1つのルートへ）
2. 境界ケースを明文化する（曖昧な問い合わせの判断基準を事前に決める）
3. TRIAGE（安全弁）を必ず持つ（判断できないものを安全に受け止める先がある）

ルート定義表

代表的な境界ケースの判断基準

境界ケースは 「主目的」「成果物」「失敗コスト」 の3軸で判断すると、運用中にブレにくくなります。

ルーティングフローの設計

ルーティングは「一発で当てる」のではなく、安い判定から高い判定へ段階的に進め、判断できないときの逃がし先（fallback）を必ず用意するのが実務の鉄則です。

3段階の判定プロセス

確信度（Confidence）とfallbackの設計

確信度は「当てにいく」ためではなく、「危ないときに止まる」ために使います。

再ルーティングの仕組み

専門家が回答を作成する途中で「この問い合わせは自分の担当ではない」と判断した場合に、ルーターへ差し戻す仕組みも重要です。これにより、ルーターの初期判断が間違っていても、最終回答の品質を保てます。

50件の評価データセット

なぜ50件から始めるのか

大規模なデータセットを用意する前に、まず50件の小規模データで「最初の混同行列を回す」ことが重要です。目的は3つあります。

1. 誤ルーティングの典型パターンを可視化する
2. ラベル定義の曖昧さを早期に発見する
3. 改善施策の効果を定量的に確認できるベースラインを作る

データ作成の手順

50件の一覧

以下が評価用の50件データセットです。各ルート6〜8件で構成し、境界ケースを意図的に含めています。

TECH（技術実装）— 8件

DATA（データ分析）— 7件

RESEARCH（調査・要約）— 8件

WRITING（文章作成・編集）— 7件

BUSINESS（戦略・企画）— 7件

LEGAL（法務・リスク）— 6件

TRIAGE（トリアージ）— 7件

混同行列による評価

評価パイプライン

ルーターの品質を測る流れは、以下の6ステップで構成されます。

混同行列とは

混同行列は「正解のルート（行）× ルーターの予測（列）」を表にしたものです。対角線上（左上→右下）の数字が正解数、対角線から外れた数字が誤分類です。どのルート同士が混同されやすいかが一目で分かります。

仮想実行例：router_v0 の結果

50件のデータに対してルーター（router_v0）を実行した仮想結果です。一部を意図的に誤分類させ、混同行列の読み方を解説します。

混同行列（件数）

行が「正解ルート」、列が「ルーターの予測」です。

精度指標（ルート別）

指標の読み方ガイド

誤ルーティングの分析と改善

混同行列から読み取れる3つの問題

上の混同行列から、典型的な誤りパターンが3つ浮かび上がります。

問題1: RESEARCHへの流入過多（Precision 0.636）

RESEARCH列に他ルートからの流入（TECH→RESEARCH、DATA→RESEARCH、WRITING→RESEARCH、LEGAL→RESEARCH）が集中しています。「調べる」「整理する」「まとめる」といった表現が含まれると、本来の主目的（実装、文章作成、法務判断）を無視してRESEARCHに引き寄せられるパターンです。

改善策: ルート説明文に「成果物」を強調する。例：RESEARCHの説明に「成果物は"調査レポート・比較表"であり、設計案・法務観点は含まない」と明記。

問題2: WRITING ↔ RESEARCH の混同

文章を「書く」のか「調べる」のかが曖昧な問い合わせで混同が発生します。特に「要約」は両方に該当しうるため、判断基準を厳密にする必要があります。

改善策: 「入力が既に手元にある → WRITING」「入力を外部から集める必要がある → RESEARCH」という判断基準を追加。

問題3: TRIAGEの取りこぼし（Recall 0.714）

本来はTRIAGE（追加質問が必要）なのに、TECHやBUSINESSに押し込まれるケースです。ルーターが「とりあえず近いルートに入れる」動作をしており、「判断を保留する」選択肢を十分に活用できていません。

改善策: 確信度の閾値を調整し、低確信度の問い合わせを積極的にTRIAGEへ逃がす。

改善の3本柱

運用モニタリングと改善サイクル

監視すべき6つの指標

ルーティングの品質を維持するために、以下の指標を定常的に監視します。

継続的改善ワークフロー

週次改善の5ステップ

ログ保存の設計ポイント

ルーティングのログは「後から再現・分析できること」が最も重要です。

主要OSSとサービスの整理

ルーティングに関連する主要なOSS・サービスを、型ごとに整理します。

まとめ：ルーティング設計の5つのポイント

FAQ

5〜7個が実務の目安です。少なすぎると1つのルートが広くなりすぎて専門性が下がり、多すぎるとルーター（＝分類器）の精度が落ちます。まず5〜7個で始め、混同行列を見ながら「分割すべきか」「統合すべきか」を判断してください。

はい。本記事の50件のように、想定される問い合わせをテンプレートで作成し、正解ラベルを手動で付けることで評価を始められます。実ログが溜まったら、匿名化して差し替えてください。

「誤ルーティングのコスト」で判断します。LEGALの見逃しは高コストなので高精度を求めますが、TECH↔RESEARCHの混同は比較的低コスト（再ルーティングで回復可能）です。全ルート一律に高精度を目指すより、高リスクルートの精度を優先してください。

ルールベースからです。LEGALのキーワードマッチやWRITINGの定型パターンなど、高精度で拾える部分をまず分離し、残りをLLMに渡すハイブリッド構成が推奨です。安い判定から始めることで、コストと精度のバランスが取りやすくなります。

最初はシングルラベルで十分です。複数ルートにまたがる場合はTRIAGEに分類し、TRIAGEが「追加質問して分解する」または「複数専門家へファンアウトする」設計にすれば、シングルラベルのまま対応できます。マルチラベルは評価設計が複雑になるため、運用が安定してから検討してください。

この記事の著者

Agentic Base 編集部

AIエージェントとWebメディア運用の知見を活かし、実践的なナレッジを発信しています。