クラウドLLMとオンデバイスSLMを組み合わせ、タスクの性質に応じて処理先を切り替える設計手法を「ハイブリッドLLM設計」と呼ぶ。

単一モデルへの依存はコスト・レイテンシ・データ保護の三方向でトレードオフを生む。クラウドLLMは高精度だが通信コストと遅延が伴い、機密データの外部送信が問題になるケースもある。一方、オンデバイスSLMはプライバシーと応答速度に優れるが、複雑な推論には力不足になりやすい。

本記事では、AIエンジニアやシステムアーキテクトを対象に、コスト・レイテンシ・コンプライアンスの観点からタスクをルーティングする具体的な戦略を解説する。読み終えると、自社システムに適したハイブリッド構成の選び方と実装上の注意点が把握できる。

クラウドLLMとオンデバイスSLMを組み合わせて使う設計思想を、ハイブリッドLLM設計と呼ぶ。単一モデルに全タスクを任せるのではなく、処理の性質に応じて最適なモデルへ振り分けることがコアコンセプトだ。

コスト・レイテンシ・データ保護の三要件を同時に満たすことは、クラウド単独でもオンデバイス単独でも難しい。この現実が、ハイブリッド構成を実用的な選択肢として押し上げている。

以降のセクションでは、単独運用との違い、ルーティング判断軸、代表的な実装パターンを順に整理する。

クラウドLLMとオンデバイスSLM（Small Language Model）を組み合わせる「ハイブリッド設計」は、単純な「どちらを使うか」という選択とは根本的に異なる。それぞれを単独運用する場合との最大の違いは、タスクの性質に応じて処理先を動的に振り分ける「ルーティング層」が存在する点にある。

単独運用では、すべてのリクエストが同一のモデルに流れる。これに対しハイブリッド設計では、タスクを受け取った時点でその特性を評価し、最適なモデルへ送る仕組みを持つ。

主な違いを整理すると以下の通りだ。

• 処理先の多様化: 軽量タスクはデバイス上のSLMで完結させ、複雑な推論や長文生成はクラウドLLMへ委譲する
• データの流通制御: 機密性の高い情報はオンデバイスで完結させ、外部ネットワークに出さない経路を確保できる
• コスト構造の分散: トークン消費量の大きいリクエストだけをクラウドに集約し、全体のAPI費用を抑制できる

共存が「必然」となる背景には、現実のアプリケーションが均質なタスクだけで構成されていないという事実がある。たとえば、スマートフォン上の業務アプリでは、入力補完のような即応性が求められる処理と、複合AIシステム（Compound AI System）として複数ステップの推論が必要な処理が混在する。一律にクラウドへ送れば遅延とコストが増大し、一律にオンデバイスで処理すれば品質が低下するケースが生じる。

ハイブリッド設計はこの非均質性を前提とした構造であり、単独運用では得られないトレードオフの最適化を可能にする。

クラウドLLM単独で運用する場合、まずコストとレイテンシの問題が顕在化しやすい。大量のトークンを毎回クラウドへ送信すると、APIコストが累積しやすく、ネットワーク往復の遅延も避けられない。モバイルアプリや製造ラインの端末など、応答速度がUXに直結する場面では、この遅延が致命的になるケースがある。

さらにデータ保護の観点も見逃せない。医療・金融・法務といった規制業種では、個人情報や機密情報を外部サーバーへ送信すること自体が、EU AI ActやGDPR、各国のデータローカライゼーション規制に抵触するリスクを生む。クラウド単独構成では、このコンプライアンス要件を満たすために設計が複雑化しやすい。

一方、オンデバイスSLM単独に頼ると、今度は能力の天井にぶつかる。

• 複雑な推論・長文生成: コンテキストウィンドウが狭めの構成も多く、マルチステップ推論を要するタスクでは精度が落ちやすい
• 多言語対応: マルチリンガルNLPの品質はモデル規模や学習データ量の影響を受けやすく、SLMでは限界が生じやすい
• モデル更新コスト: デバイス側のモデルを最新に保つには、配布・管理の運用負荷がかかる

つまり、クラウドとオンデバイスはそれぞれ異なるトレードオフを抱えており、一方だけで全タスクをカバーしようとすると、必ずどこかで妥協が生まれる。次セクションで解説するルーティング判断軸は、この「どちらも最適解にならない」構造を前提に、タスク特性に応じて両者を使い分けるための思考フレームだ。

タスクをどちらのモデルに送るかを決める「ルーティング」は、ハイブリッド設計の核心だ。判断を誤ると、コスト削減のはずがレイテンシ悪化を招いたり、利便性を優先した結果コンプライアンス違反が生じたりする。

本セクションでは、**コスト・レイテンシ・コンプライアンス（データ保護を含む）**の3軸を整理する。それぞれの軸は独立ではなく、実際のルーティング設計では複数の軸を同時に考慮する必要がある。各軸の詳細は以降のH3で掘り下げる。

コスト最適化はハイブリッド設計の最も直接的な動機のひとつだ。クラウドLLMはトークン単価が高く、大量リクエストが積み重なると月次コストが急増する傾向がある。一方、オンデバイスSLMは推論コストがほぼゼロに近いため、トークン量が多いタスクや反復頻度の高いタスクはSLMに任せることで費用を大幅に抑えられる。

振り分けの基本指標

• 入力トークン数: 数百トークン以内の短い分類・抽出タスクはSLMが得意。数千トークンを超える長文要約や複雑な推論はクラウドLLMへ
• 呼び出し頻度: 1日数万回以上のバッチ処理や定型フォーム解析はSLMで吸収し、クラウドへの呼び出し回数自体を削減する
• 精度要件: 誤答コストが高い契約審査・医療文書などは、コストが高くても精度優先でクラウドLLMを選択する

実践的な考え方

まずタスクを「短文・定型・低リスク」と「長文・非定型・高リスク」に二分し、前者をSLMのデフォルトレーンに割り当てるのが出発点になる。次に、クラウドへの月次トークン消費量を計測し、SLMで代替できた割合をAI ROIの指標として追跡すると改善サイクルが回しやすい。

レイテンシとオフライン対応は、クラウドLLMとオンデバイスSLMの振り分けを決める最も直感的な軸だ。ネットワーク往復だけで数百ミリ秒のオーバーヘッドが生じるクラウドと、ローカル推論で即応できるSLMでは、ユーザー体験に明確な差が出るケースがある。

レイテンシ要件による判断基準

• 200ms以下の応答が必要なシーン（音声アシスタント、リアルタイム字幕、ゲーム内NPCなど）→ オンデバイスSLMを優先
• 1〜3秒程度の応答が許容されるシーン（文書要約、コード補完の候補提示など）→ クラウドLLMも選択肢に入る
• バッチ処理・非同期タスク（夜間レポート生成、大量翻訳など）→ レイテンシより精度・コストを優先しクラウドLLMへ

オフライン・接続不安定環境での要件

工場フロアや航空機内、山間部の現場など、ネットワーク接続が保証されない環境ではクラウドLLMへのルーティング自体が成立しない。このようなシーンではSLMをエッジAIとしてデバイスに常駐させ、接続回復後にクラウドLLMで結果を検証・補完するアーキテクチャが有効だ。

設計上の注意点

レイテンシ要件は「平均値」ではなく「P95〜P99の外れ値」で評価することが重要だ。クラウドAPIは混雑時にレスポンスタイムが跳ね上がる傾向があるため、SLA要件が厳しいシーンではオンデバイスSLMをフォールバックとして組み込むことでサービス品質を安定させられる。

なお、コンプライアンス観点での振り分けについては次のセクションで詳しく扱う。

データの機密度と規制要件は、クラウドLLMとオンデバイスSLMの振り分けにおいて最も優先度の高い判断軸となるケースが多い。

クラウド送信を避けるべきデータの類型

• 個人識別情報（氏名・住所・マイナンバー等）
• 医療・金融・法務に関する機密文書
• 社内の未公開情報や営業秘密
• EU AI ActやGDPR、国内の個人情報保護法が適用される処理対象データ

これらをクラウドLLMに送信すると、データが第三者インフラを経由するリスクが生じる。コンプライアンス上、処理場所の明示的な管理が求められる場面では、オンデバイスSLMによるローカル処理が原則となる。

規制・ポリシーによる振り分けの考え方

プライバシー・バイ・アイソレーションの考え方を取り入れ、機密データはデバイス境界の外に出さない設計が推奨される。

一方、クラウドLLMを利用する場合でも、契約上のデータ処理条件（DPA）やモデルの学習利用オプトアウト設定の確認が不可欠だ。ガードレールの設定と合わせ、送信前にPIIを検出・マスクするパイプラインを組み込むと、クラウド活用の幅を安全に広げられる傾向がある。

ルーティング戦略には、設計の複雑さと運用コストのトレードオフに応じた複数のアプローチが存在する。大きく分けると、タスクの種類を事前に定義して振り分ける「静的ルーティング」、モデルの出力信頼度を見て動的に切り替える「カスケード型」、そしてSLMが下書きを生成しクラウドLLMが検証する「SLM下書き＋クラウド検証型」の3パターンが代表的だ。それぞれ適合するユースケースや実装難易度が異なるため、自社の要件に合ったパターンを選ぶことが設計の出発点となる。

タスクの種類をあらかじめ定義し、ルールテーブルに従って処理先を固定する手法が静的ルーティングだ。判断ロジックがシンプルなため、実装コストが低く、動作の予測可能性が高い点が最大の強みとなる。

振り分けの基本ロジック

• SLMへ送るタスク例: 定型フォームの入力補完、FAQ応答、短文の感情分類、オフライン環境でのキーワード抽出
• クラウドLLMへ送るタスク例: 長文要約、複数ドキュメントをまたぐ横断分析、多言語翻訳、コード生成

分類軸は「入力トークン数」「タスクカテゴリID」「ユーザーロール」の3つを組み合わせるケースが多い。例えば、入力が256トークン以下かつカテゴリが「FAQ」であればSLMへ、それ以外はクラウドLLMへ、という形でルールを記述できる。

実装上の注意点

静的ルーティングは設計時の分類精度に依存する。タスクカテゴリの粒度が粗いと、本来SLMで十分な処理がクラウドLLMへ流れ、コストが膨らむ傾向がある。逆に分類が細かすぎると、ルールテーブルの保守負荷が増大する。

運用開始後は**AIオブザーバビリティ**ツールでルート別のレイテンシと品質スコアを継続的に計測し、分類ルールを定期的に見直すことが望ましい。

静的ルーティングが最も効果を発揮するのは、タスク種別が安定しており、品質要件が明文化されている場面だ。要件が流動的な場合は、次に紹介する動的ルーティングとの組み合わせを検討するとよい。

信頼度ベースの動的ルーティング（Cascade）は、SLMが出力した結果の確信度スコアを閾値として、クラウドLLMへのエスカレーションを自動判断する方式だ。静的ルーティングと異なり、タスク種別ではなく「その推論がどれだけ確かか」を基準にするため、想定外の入力にも柔軟に対応できる。

仕組みの概要

1. SLMが推論を実行し、トークンの確率分布から信頼度スコアを算出する
2. スコアが閾値（例：0.85）を超えればSLMの回答をそのまま返す
3. 閾値を下回った場合のみ、同じプロンプトをクラウドLLMへ転送する
4. クラウドLLMの回答を最終出力として返却する

メリットと注意点

• コスト効率：高頻度の単純クエリはSLMで完結するため、クラウドAPIコールを削減できる傾向がある
• 品質の担保：曖昧・複雑なクエリだけを自動的に上位モデルへ回すため、ハルシネーションリスクを抑えやすい
• レイテンシの二重化リスク：エスカレーション発生時はSLMとLLMの両推論時間が加算されるため、タイムアウト設計に注意が必要

実装上のポイント

閾値設定は固定値ではなく、AIオブザーバビリティツールで収集した実運用ログをもとに継続的に調整するのが望ましい。また、信頼度スコアだけでなく出力の一貫性チェック（同一入力を複数回サンプリングして分散を見る手法）を組み合わせると、スコアが過信頼になるケースを補完できる。

次のセクションで紹介する「SLM下書き→クラウドLLM検証」パターンは、このCascadeをさらに発展させた構成と位置づけられる。

オンデバイスSLMが高速に下書きを生成し、クラウドLLMがその内容を検証・補完する二段階構成のパターンだ。レイテンシとコスト、品質を同時に最適化したい場面で特に有効となる。

仕組みの概要

1. SLMがユーザー入力を受け取り、数百ミリ秒以内に初稿を生成する
2. 初稿の信頼度スコアや文字数・複雑度に基づき、クラウドLLMへの送信要否を判定する
3. 送信が必要と判断された場合のみ、初稿をコンテキストとしてクラウドLLMに渡し、検証・加筆を行う

このパターンが適するシーン

• 契約書の要約など、精度要求が高いが応答速度も求められるタスク
• カスタマーサポートの一次回答生成で、複雑なクレームのみ上位モデルにエスカレーションしたい場合
• ネットワーク帯域が不安定な環境で、オフライン時はSLMのみで完結させたい場合

コスト面の効果

クラウドLLMへのリクエストをSLMで事前フィルタリングすることで、送信するトークン量を削減できる傾向がある。単純な問い合わせや定型応答はSLMで完結するため、クラウドAPIの呼び出し回数を抑制できる。

設計上の注意点

• SLMの下書き品質が低すぎると、クラウドLLMへの転送率が高くなりコスト削減効果が薄れる
• 初稿をそのままプロンプトに含めるとコンテキストウィンドウを消費するため、要約・圧縮の前処理が有効
• ハルシネーションの検出ロジックをガードレールとして組み込み、誤情報が下流に流れないよう設計する

次セクションの実装詳細と連携し、各パターンの運用コストを比較することで、自社環境への適合度を判断できる。

ルーティング戦略を「設計する」だけでなく「動かし続ける」には、実装の複雑さと運用負荷を事前に把握しておく必要がある。静的・動的・ハイブリッドの各パターンは、それぞれ初期構築コストとメンテナンス工数が大きく異なる。どのパターンが自社のチーム規模や技術スタックに適合するかを見極めることが、持続可能な設計の出発点となる。

静的ルーティングは、タスクの種類をあらかじめルールで分類し、処理先（SLMまたはクラウドLLM）を固定する手法だ。分岐ロジックが単純なため、実装コストが低く、動作の予測可能性が高い点が最大の強みとなる。

実装の基本構造

• タスクラベルを入力時に付与（例：task_type: summarize / translate / reason）
• ラベルとモデルのマッピングテーブルをコードまたは設定ファイルで管理
• ルーターは条件分岐のみ。LLMを使わないため追加レイテンシがほぼゼロ

適合シーン

静的ルーティングが力を発揮するのは、タスク種別が業務フローで事前に確定しているケースだ。

• 製造・現場系アプリ: 設備アラートの一次解析はSLMでオフライン処理し、異常判定のエスカレーションだけクラウドへ送る
• カスタマーサポート: FAQ応答はSLMに任せ、クレーム対応や複雑な問い合わせのみクラウドLLMへルーティング
• コンプライアンス要件が明確な業種: 個人情報を含む入力は常にオンデバイスへ固定し、データの外部送信を構造的に防止する

注意点

タスク境界が曖昧な入力が混入すると、誤ルーティングが発生しやすい。「どちらにも当てはまらない」ケースへのフォールバック先を必ず定義しておくことが重要だ。また、ラベル付けをユーザー入力に依存する設計は、意図しない操作のリスクがあるため、システム側でラベルを自動付与する仕組みを推奨する。次のセクションで扱う動的ルーティングへの移行を見据え、ログにタスクラベルと実際の処理結果を記録しておくと、後の精度評価に役立つ。

動的ルーティングは、SLMの信頼度スコアをリアルタイムに評価し、閾値を超えない場合のみクラウドLLMへエスカレートする仕組みだ。実装の核心は「信頼度判定ロジック」と「フォールバックトリガー」の2点にある。

実装の基本フロー

1. SLMが推論を実行し、ソフトマックス出力やログ確率から信頼度スコアを算出する
2. スコアが設定閾値（例：0.85）を下回った場合、同一プロンプトをクラウドLLMへ転送する
3. クラウドLLM応答をキャッシュし、類似クエリへの再エスカレートを抑制する

なお、閾値の具体的な数値はシステム構成やタスク特性によって大きく異なるため、自社環境での検証が必要だ。閾値の設定は、タスク種別ごとに分けるのが現実的だ。要約や分類など誤りの影響が小さいタスクは閾値を低めに、契約書レビューや医療要約など高精度が求められるタスクは高めに設定する。

監視すべき主要メトリクス

• エスカレーション率：クラウドへ転送される割合。急増はSLMの劣化やデータドリフトのサインとなる
• レイテンシ分布：SLM単独処理とエスカレーション後の応答時間を分離して計測する
• コスト対精度トレードオフ：エスカレーション率とトークン消費量を掛け合わせ、AI ROIを週次で確認する
• ハルシネーション検出率：グラウンディングチェックを組み込み、SLMとクラウドLLM双方の出力品質を比較する

AIオブザーバビリティツールを導入し、エスカレーション率が一定期間で基準値を超えた場合に自動アラートを発する設計が望ましい。基準値は自社のユースケースに応じて設定・検証する必要がある。閾値自体も定期的に再キャリブレーションし、モデルのバージョンアップやドメインデータの変化に追従させることが運用継続の鍵となる。

ハイブリッド設計を実際に導入する前に、いくつかの判断軸を整理しておくと後工程のやり直しを減らせる。コスト試算・レイテンシ目標・データ保護要件を同時に満たすルーティング方針を選ぶことが、設計品質を左右する。次のH3では、既存のガードレールやガバナンスポリシーとの整合という、見落とされがちながら重要な観点を掘り下げる。

ハイブリッド設計を導入する際、既存のガードレールやガバナンス体制との整合を事前に確認しないと、運用後に深刻なコンプライアンス上の問題が生じやすい。クラウドLLMとオンデバイスSLMでは適用すべきポリシーの範囲が異なるため、一元管理の仕組みが不可欠となる。

確認すべき主なポイント

• データ分類ポリシーとの整合: 社内で定めた機密レベル（例：極秘・社外秘・公開）に対応するルーティングルールを明文化する。機密レベルの高いデータはオンデバイスSLMのみに送るよう、ルーターの設定に反映する
• EU AI ActやNISTガイドライン（NIST AI RMF）への対応: 高リスク用途と判定されたタスクは、クラウドLLMを経由する場合でも監査ログの保持が求められるケースがある。ログ保存先とアクセス権限を事前に設計する
• AIガバナンス委員会への報告ライン: ルーティング判断基準の変更は、ガバナンス委員会の承認フローに組み込む。変更管理を怠ると、シャドーAIに近い状態が生まれるリスクがある
• ガードレールの二重適用: SLMとLLMそれぞれにプロンプトファイアウォールやグラウンディングチェックを設けると、処理コストが増す。共通ガードレール層をルーターの前段に置き、重複を最小化する設計が有効とされている

整合作業は設計初期に行うほど手戻りが少ない。既存のAI TRiSMフレームワークや社内セキュリティポリシーを参照しながら、ルーティングロジックを文書化しておくことが、後の監査対応を大幅に簡略化する。

ハイブリッド設計を実際に検討・導入しようとすると、「ルーターはどう作るのか」「SLMが判断を誤ったときの対処は」といった疑問が次々と浮かぶ。このセクションでは、設計・運用の現場でとくに多く寄せられる問いを取り上げ、簡潔に回答する。細かい実装の前に疑問を整理しておくことで、後続の意思決定をスムーズに進められる。

ルーター自体の実装方式は、大きく「ルールベース」と「LLMベース」の2種類に分かれる。それぞれに適した場面があるため、一律に決める必要はない。

ルールベースルーター

• トークン数・エンドポイント・キーワードなどの条件分岐で振り分ける
• 実装が軽量で、ルーター自体のレイテンシがほぼゼロに近い
• 条件が固定化されており、新しいタスク類型への対応に手動更新が必要

LLMベースルーター

• 小規模な分類モデルやSLMを使い、入力の意図・複雑度・機密性を推定して振り分ける
• 未知のタスク類型にも柔軟に対応できる
• ルーター自体が推論コストと遅延を生むため、軽量モデルの選定が重要

実際の設計では、まずルールベースで大まかに振り分け、判断が難しいケースのみSLMに渡す「二段構え」 が有効とされる。たとえば「トークン数が一定以下かつ機密フラグなし」という条件を満たした場合は即座にオンデバイスSLMへ、それ以外はSLMベースの分類器が意図を評価してからクラウドLLMへ送る、という構成だ。

選択の目安を整理すると以下のとおりだ。

なお、ルーター自体もAIオブザーバビリティの監視対象に含めることが重要だ。誤分類が蓄積するとコスト増や品質劣化につながるため、定期的なルーティングログのレビューを運用フローに組み込んでおきたい。

クラウドLLMとオンデバイスSLMのハイブリッド設計は、コスト・レイテンシ・コンプライアンスという三つの軸を同時に最適化するための現実的なアプローチだ。どちらか一方だけに頼る構成では、必ずいずれかの軸で妥協が生じる。

本記事で解説したルーティング戦略を振り返ると、選択肢は大きく三つに整理できる。

• 静的ルーティング: タスク種別でクラウド／オンデバイスを事前に固定。運用が単純で導入コストが低い
• 動的ルーティング（Cascade）: SLMの信頼度スコアを見てクラウドLLMへエスカレーション。精度とコストのバランスを自動調整できる
• SLM下書き → クラウドLLM検証: 速度を稼ぎながら品質を担保したい生成タスクに向く

設計の出発点として、まず「どのタスクが機密データを扱うか」を洗い出すことを推奨する。コンプライアンス要件が明確になれば、オンデバイス処理の範囲が自然に決まり、クラウドへ送るトークン量も絞れる。

次に、ガードレールとAIガバナンスポリシーをルーターの上流に組み込む。ルーティング判断そのものが新たなリスク面になり得るため、AIオブザーバビリティの仕組みで判断ログを常時モニタリングする体制が欠かせない。

ハイブリッド構成は「完成形を一度作れば終わり」ではない。モデルのアップデートや業務要件の変化に合わせてルーティングルールを継続的に見直す運用サイクルを設計段階から織り込んでおくことが、長期的なAI ROI向上につながる。