Runtime Burden Allocation for Structured LLM Routing in Agentic Expert Systems: A Full-Factorial Cross-Backend Methodology

本論文は、構造化 LLM ルーティングを単なるプロンプトエンジニアリングの問題ではなく、生成コスト、遅延、正確性のバランスを異種バックエンド間で最適化するシステムレベルの負担配分問題として再定義し、48 の構成と 1 万 5,552 件のリクエストによる包括的なベンチマークを通じて、バックエンド固有の相互作用が性能を支配し、普遍的な最適解が存在しないことを実証するフレームワークを提示しています。

要約

🎭 タイトル：AI 司令塔の「重荷」をどう分担するか？

この研究の核心は、**「AI に何を任せるか、そして人間（システム）が何を自分でやるか」**という「重荷の分け方」によって、AI の性能が劇的に変わるという発見です。

1. 背景：AI は「おしゃべり」ではなく「指示出し」をする

昔の AI は、質問に答えるだけの「おしゃべり」でした。しかし、最新の AI は、**「この質問は誰に任せるべきか？」「メモ帳を見るべきか？」「ツールを使うべきか？」**といった「指示（ルート）」を出す司令塔として使われています。

• 例え話：
  想像してください。ある大きなホテルのフロントに、AI という「万能なコンシェルジュ」がいます。
  客が「部屋で夕食が食べたい」と言ったら、AI は「レストランに電話する」か「ルームサービスを手配する」か「料理のレシピを教える」かを判断し、指示を出さなければなりません。
  もし AI が「レストランに電話して」と言っているのに、システムが「レシピを教えて」と誤解して動けば、ホテルは混乱します。

2. 問題点：AI に「完璧な指示書」を書かせるのは大変

これまで、研究者たちは「AI に『JSON（機械が読みやすい形式）』という完璧な指示書を書いてくれ」と頼むことが多かったです。
しかし、これには2 つの大きな問題がありました。

1. 重すぎる： AI は「意味を理解する」ことと「完璧な形式で書く」ことの両方を同時にやらなければなりません。
2. 遅い： 完璧な形式を作るのに時間がかかり、客は待たされます。

そこで、**「AI には『簡単なメモ』だけ書いてもらい、残りの『指示書への書き換え』は人間のシステム（プログラム）がやる」**という方法が試されました。これを「圧縮・再構築」と呼びます。

3. 実験：48 通りの組み合わせで試してみた

著者たちは、3 種類の異なる AI（Gemini, OpenAI, Llama）を使って、以下の 48 通りのパターンをテストしました。

• AI に任せる量：
  • A 方式：AI に完璧な指示書（JSON）を書かせる。
  • B 方式：AI に簡単なメモを書かせ、システムが指示書に直す。
• AI の種類： 3 社（それぞれ性格が違う）。
• 制限： 制限あり／なし、ストリーミング（途中表示）あり／なし。

合計 15,552 回のテストを行いました。

4. 驚きの発見：「正解」は AI によって違う！

ここが論文の最大のポイントです。

• 結論： 「これ一番！という完璧な方法は存在しない」
• 発見：
  • A 社（Gemini/OpenAI）の場合： 「完璧な指示書を書いて（A 方式）」が一番正確でした。メモだけ書いてシステムに任せる（B 方式）と、指示が間違える確率が跳ね上がりました。
  • B 社（Llama）の場合： 「完璧な指示書を書いて（A 方式）」は遅いですが正確でした。しかし、「メモだけ書いてシステムに任せる（B 方式）」にすると、指示が完全に崩壊しました。 速くなった代わりに、ほとんど意味をなさなくなりました。

🍎 果物の例え：

• A 社（Gemini）は「熟したリンゴ」：そのまま食べても美味しいし、皮をむいても美味しい。
• B 社（Llama）は「硬い桃」：皮をむいて（システムが処理して）食べると美味しいが、そのまま丸ごと食べさせようとすると（AI に完璧な指示書を書かせると）固くて食べられない。
  • 逆に、B 社（Llama）を「皮をむいて（メモだけ書いて）」食べさせると、中身が崩れて汁だらけになり、食べられなくなります。

つまり、「どの AI を使うか」によって、「AI に何を任せるか」という戦略を全く変えなければならないということです。

5. 重要な教訓：3 つのルール

この研究から、システムを作る人への 3 つのアドバイスが生まれました。

1. 正確性が命なら、AI に完璧な指示書を書かせる（A 方式）
   • 特に Gemini や OpenAI なら、AI 自身に完璧な形式で出力させるのが安全です。
2. スピードとコスト重視なら、AI にメモだけ書かせてシステムが直す（B 方式）
   • ただし、「その AI がメモを理解できるか」を事前に確認してください。 Llama などの一部の AI では、この方法だと大失敗します。
3. 「途中表示（ストリーミング）」はあまり意味がない
   • 会話アプリなら「途中表示」は快適ですが、「指示を出す司令塔」の場合、指示が完成するまでシステムは動けないため、途中表示は時間の節約になりません。

6. まとめ：「万能薬」は存在しない

この論文が伝えたいことは、**「AI の性能は、AI 自体の能力だけでなく、私たちが AI にどう『重荷』を分担させるかによって決まる」**ということです。

• 間違った分担の仕方（重荷の配分）をすると、どんなに高性能な AI でも失敗します。
• 正しい分担の仕方を見極めるためには、「どの AI を使うか」に合わせて「指示の出し方」を変える必要があります。

一言で言うと：
「AI に『何』をさせるか（指示の内容）と同じくらい、『どう』させるか（指示の形式と分担） が重要だ」という、システム設計の新しい指針を示した論文です。

技術概要

論文要約：構造化 LLM ルーティングのためのランタイム負担配分

〜エージェント型エキスパートシステムにおけるフルファクトリアル・クロスバックエンド手法〜

1. 問題提起

大規模言語モデル（LLM）がエージェント型 AI システムの制御コンポーネントとして中心的な役割を果たすようになっています。しかし、従来の研究では「構造化されたルーティング（例：JSON 形式での出力）」は主にプロンプトエンジニアリングの問題として扱われてきました。

本論文は、構造化ルーティングは本質的に**「ランタイムにおける負担配分（Runtime Burden Allocation）」の問題**であると再定義します。具体的には、出力構造をモデルが直接生成するか、転送中に圧縮するか、生成後にローカルで再構築するかというシステムレベルの設計選択が、正解率、遅延、実装コストに決定的な影響を与えるという点に焦点を当てています。

既存のベンチマークは単一のモデル比較に留まりがちですが、実運用では「どのバックエンド（モデル提供者）に対して、どのランタイムパッケージ（出力形式や処理フロー）が最適か」という**互換性（Compatibility）**が重要であるにもかかわらず、これが十分に研究されていませんでした。

2. 手法と実験設計

本研究は、構造化ルーティングを「ランタイム負担配分問題」として定式化し、これを検証するための包括的なフルファクトリアル（完全因子）ベンチマークを提案・実施しました。

2.1 負担配分の次元

ランタイムの設計は以下の 3 つの次元で定義されます。

1. シリアライゼーション負担: モデルが最終的な構造化データ（JSON など）を直接生成するか、中間コードを生成して後で再構築するか。
2. トランスポート意味論: ストリーミング（逐次出力）か、非ストリーミング（完全出力）か。
3. 構造実現の場所: 最終的な構造化アセットをモデルが直接生成するか、決定論的なローカルソフトウェアが再構築するか。

2.2 実験設定

• バックエンド: OpenAI, Google Gemini, Llama（オープンソースモデル）の 3 種類。
• ランタイムモード: 4 種類（MJ: 最小 JSON, SJ: 高予算 JSON, MJS: ストリーミング JSON, MCLR: 圧縮出力＋ローカル再構築）。
• 条件: 制約設定（制限あり/なし）とトランスポート設定（ストリーミング/非ストリーミング）の組み合わせ。
• 規模: 48 のデプロイメント構成 × 324 リクエスト = 合計 15,552 リクエスト。
• タスク: 4 つのルート（チャット、タスク、開発、ドキュメント）への分類と、メモリフラグ、ツールフラグ、理由などの構造化フィールドの出力。

2.3 評価指標

• フォーマット準拠 (FC): 構造化された出力がパース可能か。
• ルーティング精度 (RA): 正しいルートが選択されたか。
• 状態保持 (SR): 中断や状態依存の対話において正しく処理されたか。
• レイテンシ (LAT): 完全応答までの時間。
• トークン消費 (TOK): コスト指標。
• WLC (Workflow Lower-bound Completion): フォーマット準拠、正解、状態保持のすべてを満たす確率の下限（実用上のワークフロー成功率の代理指標）。

3. 主要な結果

3.1 バックエンドとモードの相互作用が支配的

最も重要な発見は、**「普遍的な最良のルーティングモードは存在しない」**という点です。

• 相互作用効果: 統計分析（ANOVA）により、バックエンドとランタイムモードの相互作用項（Backend × Mode Interaction）が、ルーティング精度や状態保持において非常に大きな効果量（Partial Eta Squared ≈ 0.96）を持つことが示されました。
• バックエンド依存性:
  • Gemini / OpenAI: 高忠実度の直接 JSON 生成（MJ, SJ）が最も高い正解率（RA 85% 以上）を維持。圧縮モード（MCLR）は効率化されるが、正解率が 20〜27 ポイント低下。
  • Llama: 直接 JSON 生成でも高い正解率を維持するが、圧縮モード（MCLR）への移行は壊滅的な性能低下を招く（RA が 82% から 22% へ、フォーマット準拠が 53% へ）。
  • 結論: 効率化のための構造の圧縮やローカル再構築は、バックエンドがその圧縮された意味を安定的に扱える場合にのみ有効であり、モデルごとに結果が全く異なります。

3.2 効率性と正解性のトレードオフ

• MCLR（圧縮＋再構築）: トークン数とレイテンシの面で最も効率的ですが、正解性の低下という代償を伴います。特に Llama においては、効率化のメリットが正解性の崩壊によって無効化されます。
• ストリーミングの限界: 制御タスクにおいては、完全な制御レコードが揃うまで下流の処理が進まないため、ストリーミングによる「最初のトークンまでの時間」の短縮は、実用的なレイテンシ改善や正解率向上にはほとんど寄与しませんでした。

3.3 ルートごとの脆弱性

集計された精度だけでなく、特定のルート（特に「開発者向け」などの専門ルート）に注目すると、圧縮モードではこれらのルートが特に脆弱になることが明らかになりました。 aggregate（集計）データでは隠れる「特定の重要な経路での失敗」が、実運用において深刻なリスクとなります。

4. 主要な貢献

1. 概念の再定義: 構造化 LLM ルーティングを「プロンプト調整」ではなく、「システムレベルの負担配分問題」として再定義しました。
2. 方法論的フレームワーク: 「ランタイム負担配分フレームワーク」を提案し、モデルと周辺ソフトウェア間で構造生成の負担をどう配分するかを設計変数として扱う手法を提供しました。
3. クロスバックエンド評価手法: 単一モデルの比較ではなく、異なるバックエンドファミリーにおけるランタイムパッケージの互換性を評価するためのフルファクトリアルベンチマークと分析プロトコルを確立しました。
4. 実用的なデプロイメント指針: 正解性、コスト、レイテンシのトレードオフを、バックエンドごとの互換性に基づいて最適化する具体的なルールを提示しました。

5. 意義と示唆

本研究は、LLM を活用したエージェント型エキスパートシステムの実装において、単に「どのモデルが賢いか」ではなく、「どのモデルとどの出力形式の組み合わせが、特定のタスクに対して最も信頼性高く動作するか」を設計段階で決定する重要性を浮き彫りにしました。

• 設計原則:
  • 正解性が最優先される場合（特に専門ルートや高コストな処理）、バックエンドが安定している限り、高忠実度の直接 JSON 生成を採用すべき。
  • 圧縮モード（MCLR）は、特定のバックエンドでその意味的安定性が検証された場合のみ、効率化のために採用すべき。
  • ストリーミングは、完全な制御レコードが必要なタスクでは二次的な要素に過ぎない。

この研究は、AI システムの構築において、モデルそのものだけでなく、その「ランタイムパッケージング（実行時の処理フロー）」を第一級の設計変数として扱うべきであることを示しており、産業応用における信頼性の高いシステム構築に重要な指針を提供します。