Azure OpenAI からローカルLLMへの移行は、コスト削減やデータプライバシーの観点から非常に魅力的な選択肢です。しかし、いざ「エンドポイントを書き換えるだけ」と思ってプロジェクトを始めると、現場では想定外のトラブルが次々と発生します。

実務で直面した「生々しい課題」をベースに、ブログ形式でまとめました。

Azure OpenAIからローカルLLMへ：現場で起きた「想定外」のトラブルと評価の盲点

こんにちは。AIエンジニアリングチームです。
昨今、プライバシー保護やコスト最適化を目的として、Azure OpenAI（以下AOAI）で構築したシステムを、社内サーバーやエッジ環境の「ローカルLLM」にリプレースする動きが加速しています。

「APIを叩くコードを少し書き換え、モデルをLlama 3やMistralに変えるだけ」——。
当初、私たちはそう楽観視していました。しかし、実際に運用を開始してみると、クラウドの「至れり尽くせり」な環境では見えてこなかった地雷が数多く埋まっていました。

本記事では、私たちのチームが実際に検証・運用時に直面した課題を、評価項目と併せてレポートします。

1. 「プロンプトの互換性」という幻想

現場で起きたこと：
AOAI（GPT-4）で完璧に動いていたプロンプトをそのままローカルLLM（7B〜70Bクラス）に流し込んだところ、回答がJSON形式を無視したり、出力が急に英語になったりする事象が多発しました。

• 評価の盲点: 「モデルの知能指数（IQ）」の差です。
• 教訓: GPT-4は、多少曖昧な指示でも「汲み取って」くれますが、ローカルLLMは非常に「実直」です。
• 評価項目: プロンプト遵守率（Format Adherence）。
• 対応: モデルごとの「Prompt Template（Instuct/Chat形式）」の厳密な適用と、Few-shot（例示）の追加が不可欠です。

2. 誰も予測できなかった「VRAM消費のスパイク」

現場で起きたこと：
開発環境で1人でテストしている時は快適でしたが、複数人が同時にAPIを叩き始めた途端、Out of Memory (OOM) でコンテナがクラッシュしました。

• 評価の盲点: コンテキスト長とKVキャッシュの関係。
• 教訓: ローカルLLMは、入力テキストが長くなればなるほど、GPUのメモリ（VRAM）を指数関数的に消費します。
• 評価項目: 最大コンテキスト入力時のVRAM占有量。
• 対応: vLLMなどの推論エンジンを導入し、PagedAttention によるメモリ最適化を行う必要があります。

3. 「レイテンシー」は良いが「スループット」が壊滅的

現場で起きたこと：
「ローカルだから爆速だろう」と期待していましたが、1ユーザーあたりの応答速度（Latency）は速いものの、5人同時に使うと、6人目のリクエストがAOAIより遥かに遅くなる（あるいはタイムアウトする）現象が起きました。

• 評価の盲点: クラウドのような「動的スケーリング」の欠如。
• 教訓: 1枚のGPUで処理できる並列数には限界があります。
• 評価項目: スループット（tokens/sec）と、同時リクエスト時の待機時間。
• 対応: 負荷状況に応じてリクエストをキューイングする仕組みや、モデルの「量子化（4bit/8bit）」による軽量化が必須です。

4. 「量子化」による知能指数の低下

現場で起きたこと：
GPUメモリを節約するためにモデルを4bitに圧縮（量子化）したところ、それまで解けていた論理パズルや、複雑な日本語の文脈理解でミスが目立つようになりました。

• 評価の盲点: 「モデル名」が同じでも、重みの精度で回答の質が変わる。
• 教訓: FP16（無圧縮）とQ4_K_M（4bit量子化）では、特定のタスクで明確な精度の乖離が出ます。
• 評価項目: 量子化レベル別のベンチマーク。
• 対応: 業務上「絶対に外せない判断」が含まれるタスクでは、8bit以上の精度を確保するなどの妥協案が必要です。

5. ライブラリとドライバーの「地獄の依存関係」

現場で起きたこと：
OSのアップデートやCUDAドライバーの更新を行った際、それまで動いていた推論ライブラリ（PyTorch/bitsandbytes等）が突然動かなくなり、半日かけて環境再構築を強いられました。

• 評価の盲点: 運用フェーズでの「再現性」。
• 教訓: AOAIはMicrosoftがバックエンドを管理してくれますが、ローカルは「OSからドライバーまで」が自分たちの責任です。
• 評価項目: 環境構築の自動化（Infrastructure as Code）の容易性。
• 対応: Docker（NVIDIA Container Toolkit）による環境完全固定が「鉄則」です。

結論：ローカルLLM移行時に追加すべき評価チェックリスト

既存の評価項目に加えて、以下の項目を検証することをお勧めします。

1. Instruction Following: 特定のフォーマット（JSON/Markdown）を何回連続で維持できるか。
2. Long Context Stability: 最大トークン付近での回答精度とメモリ消費の推移。
3. Throughput vs. Users: 同時接続数が増えた際の、1ユーザーあたりの待ち時間の増加率。
4. Security/Filter: AOAIにあった「コンテンツフィルター」がなくなるため、不適切発言の検知を自前でどうやるか。
5. Maintainability: モデルのアップデート（Llama 3 → 4など）にかかる工数。

ローカルLLMは、一度構築してしまえば「API代を気にせず回し放題」という夢のような環境を提供してくれます。しかし、その裏側にある「運用コスト」と「品質管理」を正しく評価することが、プロジェクト成功の鍵となります。

鋭いですね！確かに、LM StudioやOllamaといったツールの登場で、ローカルLLM導入のハードルは劇的に下がりました。開発者個人のPCで「とりあえず動かす」だけなら、先ほど挙げた苦労の8割は解消されます。

ただ、**「個人のPC（プロトタイプ）」から「本番運用（システムへの組み込み）」へ移行しようとすると、LM Studioだけでは解決できない「壁」**が再び現れます。

エンジニア仲間と雑談しているような感覚で、LM Studioの「守備範囲」と、それでも残る「課題」を整理してみましょう。

ちなみにですが、LM Studioが「解決してくれる」こと

LM Studioは、いわば「ローカルLLM界の魔法の杖」です。以下の点は、これ一つで解決します。

• 依存関係の地獄: CUDAやPyTorchのバージョン管理、Python環境の構築は一切不要。アプリをインストールするだけで動きます。
• モデルの入手と最適化: Hugging Faceからモデルを探し、自分のPCで動く最適な量子化（GGUF）を選んでダウンロードする作業をUI上で完結できます。
• API互換性: ボタン一つで「OpenAI互換サーバー」が立ち上がるので、コード側のURLを書き換えるだけで接続できます。

---

それでも「現場の問題」として残るもの

しかし、システムを「運用」するとなると、LM Studioはあくまで**「デスクトップアプリ」**であるという限界に突き当たります。

1. 「同時リクエスト」に耐えられない（スループットの限界）

LM Studioのバックエンドは主に llama.cpp です。これは「1人のユーザーが手元のPCで使う」には最適ですが、Webサービスなどで**「10人が同時にアクセスする」ような状況は想定されていません。**

• 問題: 複数のリクエストが来ると、一つずつ順番に処理（キューイング）されるため、2人目以降の待ち時間がとんでもないことになります。
• 現場の評価: 「同時実行性（Concurrency）」のテストをすると、LM Studioでは厳しい結果が出ることが多いです。

2. 「サーバー運用」に不向き

LM StudioはGUI（画面）があることが前提のアプリです。

• 問題: 実際の運用では、Linuxの黒い画面（CUI）しかないサーバーや、クラウド上のDockerコンテナで動かす必要があります。GUIベースのLM Studioをサーバーで24時間365日安定稼働させるのは、リソース効率も悪く、管理が困難です。
• 現場の評価: 「可用性」や「自動復旧（ヘルスチェック）」の観点で、本番環境では vLLM や TGI (Text Generation Inference) といったヘッドレスな推論エンジンが選ばれます。

3. 「モデルの知能」自体は変わらない

LM Studioはあくまで「入れ物（推論エンジン）」です。

• 問題: 中に入れるモデル（Llama 3など）が、GPT-4に比べて「指示を守れない」「嘘をつく」という根本的な問題は、LM Studioを使っても解決しません。
• 現場の評価: 先ほど挙げた「回答精度」や「プロンプトの互換性」の評価は、どのツールを使おうが絶対に避けて通れません。

結論：LM Studioは「検証のスタート地点」として最強

LM Studioで解決するのは、主に**「フィージビリティ（とりあえず動くか）」と「環境構築の容易性」**です。

しかし、業務システムとしてリリースするためには、以下の2ステップで考えるのが現実的です。

1. フェーズ1（LM Studio）: 「そもそもこのサイズのローカルLLMで、やりたいタスクがこなせるか？」をサクッと検証する。
2. フェーズ2（vLLM / Ollama / LocalAI等）: サーバーにデプロイし、複数のユーザーが叩いても壊れないか、安定して速度が出るかを検証する。

現場からのアドバイス:
「LM Studioで動いたから明日リリースしよう！」と言うと、インフラ担当者に泣かれます（笑）。
LM Studioでモデルの感触を掴んだら、次は**「本番環境と同じスペックのLinuxサーバーで、APIとして叩いた時のスループット」**を測定することをお勧めします。