クラウド LLM に育てられた我々が、Local LLM と向き合うとき手放したい幻想 5 つ

Grace
2026-05-15

Graceです。
今回の記事では、ローカルLLMでつまずきやすいポイントと、クラウドLLMに慣れた人が手放したい思い込みを整理します。

この記事の内容

7. まとめ

はじめに

皆さん、こんにちは。
突然ですが、こんな経験はありませんか?
「案件の都合で、データを外に出せないが、AI は利用したい」
「セキュア環境での作業が必要だが、LLM で RAG を利用したい」
そういう事情で、Local LLM を触り始めた。で、いざ触ってみたら、思っていたのと違った。

私はてっきり、Claude のちょっと小さい版みたいなのが、自分の GPU の中にお行儀よく住んでいてくれるものだと思っていました。
が、実態は「GPU の中に住みついたよくわからない知的生命体に、毎日プロンプトでお伺いを立てる」みたいな、なかなかにスリリングな日々が始まったわけです。

違うんです。ダメだったのは、使い方だったんです。
私はこの 2-3 年、様々な企業が究極にチューニングしたクラウド LLM に激甘に育てられすぎました。
そしてその「激甘環境」で身につけたノリのまま、Local LLM という、ちょっと事情のちがう世界に乗り込んでしまった。

というわけでこの記事では、Local LLM を触り始めた我々が「クラウド LLM につけられたヘンな癖」をどう手放すかを、5 つの幻想に分けてお話しします。設計思想の話です。

幻想 1: 「とりあえず賢いでしょ」

クラウド LLM って、雑にプロンプトを投げても、なんとなくいい感じに返してくれませんでしたか?

「このエラーログ、変じゃない?」とコピペしただけで、原因の候補をいくつか挙げてくれる。
「これ翻訳して」と書いて文章を投げると、文脈に合った敬語レベルで訳してくれる。
こちらが「何を聞きたいか」をちゃんと言語化していないのに、勝手に汲み取って答えてくれる。
私たちはこれに完全に慣れきってしまっていた。

その勢いのまま、Local LLM に同じ感じで投げる。
「はい、このログは通常と異なる可能性があります」と、当たり障りのない返事が返ってきます。
何がどう変なのかは教えてくれません。「どこが変か教えて」とは指示していませんから。

これは別に Local LLM が劣っているという話ではなくて、「賢く察する」ためのモデルサイズ、チューニング、周辺のガードレールを、クラウド側がかなり肩代わりしてくれていたという話です。
そして、Local で動かせるサイズには、限界があります (GPU 的に)。

Local LLM は「賢く察してもらう」のではなく、「察してほしかったことを、ぜんぶこちらが言語化してあげる」ことで力を発揮します。

クラウド LLM 的な投げ方	Local LLM 向けの投げ方
「変じゃない?」とだけ聞く	「頻度・エラーコード・タイミングの 3 観点で異常を指摘して」と観点を渡す
「翻訳して」とだけ依頼する	「お客様向けのビジネス敬語で翻訳して」と文体まで指定する
答え方を相手に任せる	「3 つの箇条書きで」「100 字以内で」など、出力形式まで指定する

クラウド LLM が察してくれていた部分を、こちらがプロンプトと構造化出力でガチガチに固める。
タスク・入力・出力形式・評価基準を最初に渡す。これだけで、かなり付き合いやすくなります。
自分で設計できる範囲も増え、自由度も上がり、仕事も増えます。覚悟してください。

幻想 2: 「指示すれば動くでしょ」

最近のクラウド LLM は、JSON mode、structured output、function calling などのおかげで、出力形式をかなり制御しやすくなっています。
「JSON で返してください」だけでも、だいたい期待に近い形で返ってくることが多い。
「箇条書きで」と言えば、箇条書きになります。「日本語で」と言えば、日本語になります。
便利な世の中だなぁ、と思います。

そして我々は、クラウド LLM の「指示にちゃんと従う」を、なんとなく当たり前だと思っていました。
いま思うと、あれが贅沢だったんです。

Local LLM に同じリクエストをすると、そううまくはいきません。

こちらの指示	起きがちな出力
「JSON で返してください」	「了解しました! 以下、JSON でお返しします:」という前口上が入ってから JSON が出る
「箇条書きで」	各項目の前に、長々と説明が入る
「日本語で」	文中に英語がしれっと混ざる

JSON の前に挨拶を忘れません。丁寧ですね。
これも、Local LLM の知能だけの問題ではありません。
モデルサイズ、instruction tuning、RLHF、システムプロンプト、推論時のガードレールなど、いろいろな積み重ねの差が出ています。

取るべき方針は明確です。「お願いする」から「強制する」に、考え方を切り替える。

設計ポイント	具体的にやること
余計な出力を前提にする	「JSON だけ返して」と書いたうえで、後段でパースする
出力の形を固定する	出力スキーマを定義して、モデルが走れるレールを敷く
期待値を例で見せる	few-shot で「こう書いてほしい」のサンプルを 2-3 個提示する

JSON が必要なら、プロンプトだけでなく、スキーマ定義、パース、バリデーション、リトライまで含めて設計する。
そこまでやって、ようやく安定運用に近づきます。

「お願いしたらいい感じにやってくれるはず」と信じた瞬間に、裏切られます。
だから、指示を前提に設計する。これが Local LLM の作法です。

ちなみに、Anthropic は Claude のシステムプロンプトの一部を公開しています。
Local LLM のガードレールを作成する際にも参考になると思いますので、覗いてみてください。
クラウド LLM は、こちらが知らないところで、ものすごい量の作り込みをしてくれていたんです。

幻想 3: 「速いに決まってる」

「ネットワーク往復もないし、自分のマシンで動く。そりゃ速いでしょ」
私もそう思ってました。
でも、はじめて投げたリクエスト、応答までの時間は 30 秒。
ChatGPT で 10 秒で返ってきていたものが、20-30 秒、下手すると 1 分。

もちろん、小さいモデルをうまく動かせば、Local のほうが速いケースもあります。
ただ、「ローカルだから速い」とは限りません。速さは、PC スペック × モデル × サービング × プロンプト、ぜんぶのかけ算で決まるのです。

要素	速度への影響
GPU (性能・VRAM 容量)	処理できるモデル規模と速度の天井を決める
モデルサイズと量子化	tok/s (1 秒あたり何トークン作れるか) に直結する
サービング	vLLM、SGLang、Ollama、llama.cpp などの選択で捌き方が変わる
プロンプト設計	そもそも処理すべきトークン量を減らせる

クラウド LLM を使っていたときは、これ全部、誰かがチューニングしてくれていたんです。ありがたいことです。本当に。
Local LLM では、これを自分でやります。どこか一段でも手を抜くと、それがそのまま結果に響きます。
体感で「遅い」と言う前に、TTFT、tok/s、VRAM 使用量、プロンプト長を見る。
Local LLM では、まず測るところから始まります。「速くする責任が、ぜんぶ自分に移ってくる」のです。

幻想 4: 「文脈はぜんぶ飲み込んでくれるでしょ」

クラウド最強モデルは、100K、200K、果ては 1M のコンテキストを平然と扱います。
RAG で取ってきた候補をドカッと放り込んでも、「うん、必要なのこれね」と勝手に拾ってくれる。
我々は、それに慣れすぎてしまいました。

Local LLM に同じノリで 32K の context を放り込みます。すると、こんな現象が起こります。

起きる現象	何が困るか
後半に書いた指示が忘れられる	重要な制約ほど守られなくなる
同じことを繰り返し始める	回答が進まず、ノイズだけが増える
だんだん日本語が崩れる	出力品質を人間が直す前提になる
最初に渡したルールを、途中から無視する	system prompt や運用ルールの効きが弱くなる

「えっ、君、さっきまでちゃんとしてたのに……?」という気持ちになります。

公称コンテキスト長と、「実用上のコンテキスト長」は別物です。
これはクラウドでもそうなんですが、Local では特に顕著に出ます。
「対応コンテキスト 128K」と書いてあっても、品質を保てるのはその半分以下、ということがよくあります。

だから、こちらが渡す情報を絞ってあげる必要があります。

設計ポイント	Local LLM での考え方
RAG の候補数	取ってきた候補から、本当に必要な数件だけに絞る
会話履歴	全文を抱えず、要約 + キー情報の抽出で持つ
ノイズの扱い	「ノイズを混ぜると性能が下がる」ことを設計前提にする
system prompt	長ければいいわけではなく、必要なルールに絞る

Local LLM で RAG を使うときは、「たくさん詰める」より、「少なく正しく渡す」ほうが回答が安定することが多いです。
クラウド LLM が「過去の話を全部覚えている敏腕コンサルタント」だとすると、Local LLM は「本題に集中したい職人」です。
利用側の責務は、職人に「本題だけ」を渡すこと。冗長な情報は、職人に対して失礼にあたります。

冗長な情報を投げてくる発注者、嫌ですもんね。

幻想 5: 「定番モデル、あるでしょ」

クラウド LLM の頃、モデル選定はものすごく簡単でした。
OpenAI なら、上位モデルを使うか、軽量・低コストモデルを使うか。
Anthropic なら、上位モデルか、高速・低コストモデルか。
だいたい 3-4 個の選択肢から、用途と予算で選ぶだけ。
各社が “これを使ってくれ” と厳選した、いわばお店の “おすすめメニュー” を見て選ぶ感覚です。楽でした。本当に楽でした。

それくらいの軽い気持ちで、Local LLM を選びにいきます。
Hugging Face を開くと、モデルがあふれています。どれを選ぶべきかなんてわかりません。
Llama 系で何百、Qwen 系で何十、Mistral 系、Gemma 系、国産モデル、特化モデル、マージモデル……
さらに、それぞれに 7B / 8B / 14B / 32B / 70B のサイズ違い、Q4 / Q5 / Q8 の量子化違い、Base / Instruct / Chat のチューニング違い。
組み合わせで、選択肢は事実上無限です。そのうえ、毎日新しいモデルが追加されていきます。

これは Local LLM が悪いのではなく、むしろ “自由がある証拠” です。
クラウドはベンダーの厳選を享受する世界、Local は自分で選ぶ世界。

設計で持つべき考え方は、”モデルに依存しないこと” です。
Local LLM では、特定のモデルを前提にしすぎない。モデルは差し替わるものとして扱う。

選び方の観点	持っておきたい姿勢
用途との相性	特定の用途で必要最低限なものを選ぶ
将来の乗り換え	モデルを差し替えやすい設計にしておく
モデルの寿命	入れ替わる前提で、特定のモデルを深く愛しすぎない

食材は無限、レシピも無限、財布 (GPU) が許す範囲内で、調理は自分でやってください、という世界です。

まとめ — 「サービスの利用者」から「システムの設計者」に戻るということ

5 つの幻想を並べてみると、各社ベンダーの偉大さが身に沁みます。
クラウド LLM は、我々を巨人の肩の上に乗せてくれていました。
賢さ・指示追従・速度・コンテキスト・最新性、ぜんぶ「サービス側」がカバーしてくれていた。
我々はその上で「アプリケーションを書く」だけでよかった。気楽でした。

Local LLM に降りる、ということは、その肩から降りる、ということです。
責任が、ぜんぶ自分側に戻ってきます。

それはダウングレードではありません。
設計の自由度が桁違いに増えるということです。

Local LLM で得られること	何がうれしいか
データを外に出さない選択	セキュアな環境や制約の強い案件でも使いやすい
コストのコントロール	利用量や構成を自分で調整できる
ドメイン特化の設計	自分の業務やデータに合わせて最適化できる
量子化済みモデルや蒸留モデルの選択	GPU や用途に合わせた現実的な構成を組める

このどれかが効くなら、Local LLM は強力な選択肢になります。
Local LLM を選んだ瞬間、我々は システムの設計者に戻る んです。
実装のコストは確かに重いです。
でも、自分で組み上げた Local LLM が思い通りに動いた瞬間の “してやったり” は、クラウドではなかなか味わえない気分です。

半年後にこの記事を読み返したとき、
「あの頃自力で設定していた諸々、半分くらいモデル進化で勝手に解消されたな」
となっている可能性は、ぜんぜんあります。

それはそれで、Local LLM の進化が我々を救ってくれたという、めでたい話です。
もし本当にそうなったら、私はおとなしくこの記事を書き直します。