この記事はLITALICO Engineers Advent Calendar 2025 カレンダー2 の 9日目の記事です

はじめに

現在、多くの企業がLLMを活用したサービス開発に取り組んでいる。しかし、実運用において深刻な問題に直面している。

たとえば、カスタマーサポートシステムを考えてみよう。ユーザーからの問い合わせには「営業時間は何時ですか？」という簡単なものから、「複数の条件を満たす最適なプランを提案してほしい」という複雑なものまで含まれる。

従来のアプローチでは多くの場合、すべての問い合わせに対して同じ大型LLMを使用することが多くないだろうか。これは、近所のコンビニに行くのへスポーツカーを使い、高速道路のドライブにも同じ車を使うようなものだ。当然、燃費は悪く、コストは膨らむ。

本記事では、この問題を解決する「適材適所のモデル選択」という考え方を提示する。LLM（Large Language Model）とSLM（Small Language Model）を戦略的に組み合わせることで目的に応じたより最適なシステムを組めるのではないかと筆者は考えている。

非効率なアプローチをした場合と比較し、効果的なアプローチをした場合では、コストで70%削減しながら応答速度5倍ほどの差分が試算上では出る結果となった。適切に生成AIを組み込んだプロダクトを構築するために参考となれば嬉しい。

注記：本記事の数値は2024年時点のAPI価格に基づく概算である。実際の導入では、具体的な条件で試算されたい。

LLMとSLMの本質的な違い

まず、両者の特性を理解しておく必要がある。

LLM（Large Language Model）

能力: 高度な推論・創造的タスクに対応
コスト: 1回あたり数円〜数十円
速度: 1-10秒
代表例: GPT-4, Claude-3, Gemini Pro

SLM（Small Language Model）

能力: 特定タスクに特化した高速処理
コスト: 1回あたり数銭〜数円（LLMの1/10〜1/100）
速度: 0.1-1秒（LLMの1/10以下）
代表例: Phi-3, Gemma-2, Llama-3.2-3B

重要なのは、SLMは単なるLLMの縮小版ではないという点である。むしろ、特定領域に最適化された専門ツールとして設計されている。

なぜ単一アプローチは失敗するのか

多くの企業が陥る典型的な失敗パターンを見てみよう。

パターン1：すべてLLMで処理

問題の本質

簡単な「営業時間は？」という質問に、7Bパラメータのモデルをフル稼働
月間1,000クエリで月額9万〜24万円のコストが発生する試算
すべての処理に2.5秒以上かかり、ユーザー離脱率の増加する可能性が上がる

これは、オーバーエンジニアリングの典型例だ。例えば、タスクの40%はルールベースなど事前準備した回答で十分な可能性がある、40%は軽量処理で対応可能かもしれない、そのような状況でも100%を最重量級で処理していることになる。

パターン2：LLM + RAGのみ

追加される問題

RAGによる検索結果付与でトークン数が平均3倍に
ベクトル検索で0.2〜0.5秒の追加遅延
検索精度が回答品質に直結し、不安定性が増す

パターン3：ファインチューニングのみ

根本的な限界

訓練時点で知識が固定され、リアルタイム情報に対応不可
月1回の再訓練で年間1,440万円のメンテナンスコストがかかる試算（1人月120万円で試算）
未知パターンや、ドメイン外質問に対応できない可能性は残る
- 新しい事象に対しても全て回答できるよう、常にファイチューニングし続けるのは現実的でないため

結論: 単一アプローチでは、コスト・速度・柔軟性のトレードオフを解決できない。

LLMとSLMの戦略的連携

問題の本質は、すべてのタスクを同じレベルで扱っていることにある。では、どう解決するか。

4つの連携パターンを示す。それぞれ異なる状況で最適な選択となる。

パターン1：階層的処理

基本原理: SLMで前処理、LLMで高度処理

class HierarchicalProcessor:
    def __init__(self):
        self.slm = SLMClient()  # 前処理用
        self.llm = LLMClient()  # 高度処理用
    
    def process_document(self, document):
        # SLMで要約・構造化（トークン数を1/10に圧縮）
        preprocessed = self.slm.preprocess(document, max_tokens=512)
        
        # LLMで本質的な分析のみ実施
        return self.llm.analyze(preprocessed, context="business_intelligence")

期待効果: LLM単独で使う場合と比べ、LLMへの入力トークンを90%圧縮するので、コストが大幅に抑制

適用場面: 長文書の分析、大量データ処理

パターン2：インテリジェント・ルーティング

基本原理: 複雑度に応じたモデル選択

class IntelligentRouter:
    def route_query(self, query):
        complexity = self.classify_complexity(query)
        
        if complexity == "simple":
            return self.slm_processor.process(query)  # 0.3秒、¥0.5
        elif complexity == "complex":
            return self.llm_processor.process(query)  # 2.5秒、¥5
        else:
            # 中程度: SLMで試行、不十分ならLLMで補完
            result = self.slm_processor.process(query)
            return self.llm_processor.refine(result) if self.needs_refinement(result) else result

期待効果: 簡単なクエリが全体の40%、その簡単なクエリを0.3秒で処理すると想定すると、平均コストで最大80%の差分が生じる

適用場面: カスタマーサポート、FAQ対応

パターン3：段階的精緻化

基本原理: SLMでドラフト、LLMで品質向上

このアプローチは、人間の執筆プロセスに似ている。まず下書きを作り、推敲で洗練させる。

class ProgressiveRefinement:
    def generate_content(self, requirements, quality_target=0.8):
        # SLMで高速ドラフト生成
        draft = self.slm.generate(requirements)
        quality = self.evaluate(draft)
        
        # 品質が十分なら完了、不十分ならLLMで改善
        while quality < quality_target and iteration <= 3:
            draft = self.llm.improve(draft, focus=self.get_improvement_areas(quality))
            quality = self.evaluate(draft)
            iteration += 1
        
        return draft

期待効果: 必要な場合のみLLMを使用、平均コスト最大60%削減

適用場面: コンテンツ作成、文書校正

パターン4：専門化連携

基本原理: 分野別SLM + 統合LLM

class SpecializedCollaboration:
    def process_query(self, query):
        # 各専門SLMが並列処理（高速）
        tech_analysis = self.technical_slm.analyze(query)
        business_analysis = self.business_slm.analyze(query)
        legal_analysis = self.legal_slm.analyze(query)
        
        # LLMが専門知見を統合（深い理解）
        return self.general_llm.integrate([
            tech_analysis, business_analysis, legal_analysis
        ])

期待効果: 専門性と統合力を両立、処理速度で最大50%の差分が生じる

適用場面: 多分野統合コンサルティング、複合的意思決定支援

どのパターンを選ぶべきか

選択基準は明確だ。

重視する要素	推奨パターン	理由
コスト削減	ルーティング	最大80%のクエリをSLMで処理可能
応答速度	ルーティング	単純タスクを約0.3秒で完了できるように
品質優先	専門化連携	各分野の専門性を活用
柔軟性	段階的精緻化	要求に応じて動的調整
大量処理	階層的処理	前処理でトークン数削減

RAG（検索拡張生成）への応用

RAGにも同じ原理が適用できる。

従来のRAG: すべてのクエリで検索→LLM生成

最適化されたRAG: SLMでクエリ分析→必要な場合のみ検索→適切なモデルで生成

class OptimizedRAG:
    def process(self, query):
        # SLMで高速クエリ分析
        analysis = self.slm_analyzer.analyze(query)
        
        if analysis["type"] == "simple_factual":
            # 直接検索のみで回答
            return self.rag.search_and_retrieve(query)
        
        # 複雑なクエリは分解
        sub_queries = analysis["sub_queries"]
        results = [self.rag.search(sq) for sq in sub_queries]
        
        # LLMで統合・推論
        return self.llm.synthesize(results, original_query=query)

期待効果: 検索コストで最大40%の差分、応答速度で最大30%の差分が生じる

実装の3つの要諦

理論は分かった。では、実装で何に注意すべきか。

1. コスト管理の自動化

予算を超えないための仕組みを組み込む。

class CostManager:
    def __init__(self, monthly_budget=100000):  # 月額10万円
        self.budget = monthly_budget
        self.current = 0
        self.slm_cost = 0.5   # 円/回
        self.llm_cost = 5.0   # 円/回
    
    def select_model(self, complexity):
        remaining = self.budget - self.current
        
        # 予算残が少ない場合はSLM優先
        if remaining < self.budget * 0.1:
            return "slm"
        
        # 通常は複雑度ベース
        return "llm" if complexity > 0.7 else "slm"

2. 品質モニタリング

モデル選択が正しいかを継続的に検証する。

class QualityMonitor:
    def __init__(self):
        self.thresholds = {
            "accuracy": 0.9,
            "relevance": 0.8,
            "speed": 3.0  # 秒
        }
    
    def should_escalate_to_llm(self, slm_result):
        """SLMの結果が不十分な場合、LLMにエスカレーション"""
        return (
            slm_result.confidence < 0.7 or
            slm_result.completeness < 0.6
        )

3. 段階的導入

いきなり全機能を実装しない。以下の順で進める。

Phase 1: 単純なルーティング（簡単/複雑の2分類）
Phase 2: 3段階の複雑度分類
Phase 3: 専門化SLMの追加
Phase 4: 段階的精緻化の導入

各フェーズで効果を測定し、次に進む。

実践例：3つの典型的ユースケース

理論だけでは不十分だ。実際の適用例を見てみよう。

ケース1：カスタマーサポート

課題: 1日1000件の問い合わせ、90%は定型的、10%は複雑

検証方法: 90%は定型的、10%は複雑の割合で、LLMで1000件×30日分の問い合わせを用意し、LLMのみとルーティングシステムで実行し比較

解決策: ルーティングシステム

class SupportSystem:
    def handle(self, inquiry):
        # SLMで高速FAQマッチング（想定0.2秒）
        faq_match = self.slm.find_faq(inquiry)
        
        if faq_match.confidence > 0.9:
            return faq_match.answer  # 90%のケースで完了を想定
        
        # 複雑な問い合わせのみLLMへ（10%）
        return self.llm.resolve(inquiry, customer_history)

想定成果:

コスト削減: 月24万円 → 4.8万円（約80%の差）
応答速度: 平均2.5秒 → 0.5秒（約5倍の応答速度の差）
効果: 応答速度向上により、顧客満足度の向上が期待できるのでは

ケース2：コンテンツ生成

課題: ブログ記事を毎日10本作成、品質にばらつき

検証方法: 品質の確認のため自身がドメイン知識のある福祉分野のブログ記事を10本×30日分をLLMのみと後述のコンテンツ生成でそれぞれ作成し比較

解決策: 段階的精緻化

class ContentPipeline:
    def generate(self, topic):
        # SLMで構成案生成（想定5秒）
        outline = self.slm.create_outline(topic)
        
        # SLMで初稿執筆（想定30秒）
        draft = self.slm.write(outline)
        
        # 品質評価（品質スコア < 0.8の場合のみLLM使用）
        if self.evaluate(draft) < 0.8:
            return self.llm.refine(draft)  # 20%のケースを想定
        
        return draft  # 80%のケースで完了を想定

想定成果:

コスト削減: 月50万円 → 15万円（約70%のコストの差分）
生成時間: 平均120秒 → 40秒（約3倍の生成時間の差）
効果: コストを下げつつ、段階的精緻化で品質を一定水準担保

ケース3：データ分析レポート

課題: 週次レポート作成に8時間、専門性が必要

検証方法: エンジニアの作業報告に関してのデータ分析を12ヶ月分実行し、実際に人が作成したレポートと比較

解決策: 階層的処理

class ReportGenerator:
    def generate(self, raw_data):
        # SLMでデータ処理・基礎統計（想定1分）
        processed = self.slm.process_data(raw_data)
        
        # SLMでグラフ説明生成（想定2分）
        descriptions = self.slm.describe_charts(processed.charts)
        
        # LLMで高度な洞察生成（想定5分）
        # 入力トークンは90%削減済み
        insights = self.llm.analyze(processed.summary, descriptions)
        
        return self.compile_report(processed, insights)

想定成果:

作成時間: 8時間 → 10分（約48倍作成時間の差）
品質: Eng MGが作成したレポート比較し、リスク分析やスケジュール想定など、一定の分野で同等の水準とみなせる結果
- 他方で、ピープルマネージメントに関しては、良い結果が出なかった。改良の余地あり

本質は「適材適所」にある

ここまで見てきた連携手法の根底にある原理は単純だ。すべてのタスクを同じレベルで扱わない。

人間の組織を考えれば当然のことだ。簡単な事務作業を役員が処理しないし、重要な戦略判断を新入社員に任せない。AIシステムも同じである。

重要な3つの教訓

コストの大半は無駄から生まれる
- 多くのケースで80%程度のタスクは軽量処理で十分
- LLMは本当に必要な約20%に集中させる
速度は信頼につながる
- 0.3秒の応答は2.5秒より圧倒的に良い
- ユーザー体験の差は離脱率に直結する
柔軟性が長期的価値を生む
- 静的なファインチューニングより動的な連携
- 環境変化に適応できるシステムが生き残る

次のステップ

まず小さく始めよ。いきなり複雑なシステムを構築する必要はない。

Week 1: 簡単/複雑の2分類ルーティングを実装
Week 2-3: 効果測定、閾値の調整
Week 4: 中程度の分類を追加
Month 2-3: 専門化SLMの導入検討

重要なのは、継続的な測定と改善だ。データを見て、判断し、修正する。この繰り返しが最適なシステムを作る。

展望：業界特化SLMの時代

本稿で論じた連携手法は、現在利用可能な技術の最適な組み合わせである。しかし、より本質的な解は別のところにあるかもしれない。

それは、業界特化SLMの台頭だ。

なぜ特化SLMが重要なのか

汎用LLMは確かに優れている。しかし、専門領域では限界がある。

医療分野を考えてみよう。「この症状の鑑別診断は？」という問いに、汎用LLMは一般論を返すが、実臨床で必要なのは、最新ガイドライン、類似症例、薬剤相互作用を踏まえた具体的判断だ。

同じことが、法務、金融、製造、福祉など、あらゆる専門領域で起きている。

LITALICOで挑戦したい

私が所属するLITALICOは、福祉・教育領域のリーディングカンパニーだ。ここで、福祉特化SLMの開発を個人的には行っていきたい。

具体的には：

個別支援計画の自動提案（障害特性に応じた最適化）
療育記録の効率的作成（専門用語の正確な理解）
福祉制度の最新情報提供（複雑な行政手続きの支援）

汎用LLMでは、福祉用語の微妙なニュアンス、制度の地域差、個別性の高いケース対応が困難だ。特化SLMなら、これらを解決できる。

業界横断での可能性

各業界のリーディングカンパニーが特化SLMを開発すれば、何が起きるか。

医療×介護: 医療SLMと福祉SLMが連携し、退院後の包括的支援計画を生成

法務×金融: 法務SLMと金融SLMが協働し、コンプライアンス対応を最適化

製造×環境: 製造SLMと環境SLMが統合し、サステナブルな生産体制を設計

これは、単なる技術の進化ではない。知識の民主化だ。

中小企業や個人が、専門家レベルの支援を受けられる世界。それが、特化SLMの真の価値である。

技術者の役割

では、私たちエンジニアは何をすべきか。

効率的な開発基盤の整備: 特化SLMを迅速に開発できる環境
業界専門家との深い連携: ドメイン知識の正確な実装
オープンな知見共有: 成功パターンの業界間での交換
継続的な品質向上: 現場フィードバックによる改善

重要なのは、閉じないことだ。技術は共有され、改善され、進化する。その過程で、社会全体の課題解決能力が向上する。

最後に

AIの真価は、汎用性だけでなく専門性にもある。

本稿で示したLLMとSLMの連携は、現時点での最適解だ。しかし、業界特化SLMが普及すれば、さらに効率的で実用的なシステムが実現できる。

個人的には、各業界のリーディングカンパニーが、この挑戦に踏み出すことを期待しているし、自身がLITALICOで取り組みたいことの1つだ。

技術は進化する。重要なのは、その方向性だ。社会の課題を解決する技術こそ、真に価値がある。一緒に、その価値を磨き続けてみませんか。