ローカルLLMの比較記事を何本か読み、ベンチマークの表を眺めて、それでも決められない——検討が止まるのは、たいていこの段階です。しかも比較表の顔ぶれは数か月で入れ替わります。読み込むほど「今決めても、すぐ古くなるのでは」という迷いが増えていきます。本記事の結論はシンプルです。モデルの優劣を比べる前に、用途と精度要件・動かす環境・社内データの通り道という3つを先に決める。この順番で考えれば、候補は自然に数個へ絞れ、モデルが世代交代しても選び直しは小さく済みます。なお、そもそもクラウドAPIとローカル（自社・オンプレ）のどちらで生成AIを使うかという分かれ道は、生成AIはクラウドAPIか自社・オンプレLLMかで整理しています。本記事は「ローカルで動かす」方向で検討している方向けです。
目次
ローカルLLMの比較が難しいのは、モデルの性能差よりも「自社の条件」の影響が大きいからです。 公開ベンチマークで上位のモデルが、自社の業務文書では期待した回答を返さないことは珍しくありません。逆に、ひと回り小さいモデルでも、渡すデータを整えれば実用になるケースがあります。比較表は出発点にはなりますが、決め手にはなりません。決め手は自社側にあります。
公開モデルの世界では、有力な新モデルやその改良版が数か月ごとに登場します。2026年時点の比較記事でも、前年の「定番」が顔ぶれから消えていることは普通です。つまり「今いちばん良いモデル」を時間をかけて特定しても、その優位は長く続きません。選定で本当に固定すべきは、モデル名ではなく選ぶ基準と、入れ替えられる構成のほうです。ここが決まっていれば、世代交代はむしろ歓迎できる出来事になります。
社内の問い合わせ対応や文書の要約といった業務用途では、モデルは社内データを参照して答えます（いわゆるRAG構成）。このとき回答の質を左右するのは、モデルの地力に加えて何を渡すかです。たとえば、規程集の古い版と新しい版が両方保管されていれば、どんなに優秀なモデルでも古い規程を根拠に答えることがあります。モデルを入れ替えて改善する幅より、渡すデータを整えて改善する幅のほうが大きいケースが多く見られます。RAGと追加学習のどちらで社内知識を持たせるかはRAGとファインチューニングの違いで解説しています。
モデル比較の前に、自社の条件を3つ確定させます。この3つが決まると、候補モデルは「規模と系統」でほぼ絞られ、あとは実データで試すだけになります。順に見ていきます。
まず、ローカルLLMに何をさせるかを1つに絞ります。社内文書のQA、議事録の要約、帳票からの項目抽出、コード補助では、要求される精度も応答速度も違います。あわせて「間違えたときの影響」を決めておきます。たとえば社内FAQの一次回答なら人が確認してから使うため多少の誤りは許容できますが、顧客向け文面の生成なら要求水準は上がります。この許容度が、必要なモデル規模と検証の深さを決めます。
ローカルLLMはGPUメモリの制約から逃げられません。目安として、7〜8Bクラスのモデルは4ビット量子化なら8GB前後のGPUメモリから動かせ、量子化しない場合は十数GB以上が必要です。70Bクラスになると複数GPUの構成が前提になります。必要な投資規模はこの選択で大きく変わります。最初から大型モデルを狙わず、「まず7〜8Bクラス＋データ整備で足りるか」を試すのが定石です。足りなければ上位モデルへ。この判断は、後述する「入れ替えられる構成」にしておけば低コストでできます。
見落とされがちですが、成否を分けるのはここです。ローカルLLMは社内に置いた時点では何も知りません。ファイルサーバーの文書、基幹システムやデータベースの業務データを、参照できる形で届けて初めて業務の役に立ちます。誰が・どのデータを・どの頻度で届けるのか。この「通り道」の設計を後回しにすると、環境構築が終わったのに使いものにならない、という手戻りが起きます。通り道はモデルに依存しない資産なので、先に作っておけばモデルをいくら入れ替えても無駄になりません。
3つの条件が決まったら、モデルを比較します。見るべき軸は次の4つに絞れます。
| 比較軸 | 見るポイント | 注意点 |
|---|---|---|
| 規模（パラメータ数） | 7〜8B／13〜30B／70B〜でGPU要件と精度の傾向が変わる | 大きいほど良いとは限らない。量子化で必要メモリは下げられる |
| 日本語性能 | 日本語ベンチマークの結果と、自社データでの試行 | 英語中心のベンチ上位が日本語でも強いとは限らない |
| ライセンス | 商用利用の可否・条件 | 「オープン」でも利用条件付きのモデルがある |
| 更新と継続性 | 開発元の更新頻度・改良版の系譜 | 更新が止まった系統は乗り換え前提で |
候補としては、Llama系・Qwen系・Gemma系などの公開モデルと、その日本語強化版が挙がることが多く、日本語性能の評価も公開されています。ただし公開ベンチマークは一般的な問題での測定です。業務で使う言い回し（たとえば自社の製品名、略語、帳票の項目名）での正確さは、自社データで試すまで分かりません。想定問答を数十件用意し、候補モデル2〜3個に同じ質問をぶつけて比べるのが、遠回りに見えて確実です。
ローカルLLMの多くは「公開されている」ことと「商用で自由に使える」ことが別です。利用規模による条件、生成物の扱い、再配布の可否はモデルごとに異なります。選定の最終段階ではなく、候補を絞る段階でライセンス条件を確認しておくと、検証をやり直す無駄がありません。法務確認には時間がかかるため、候補が2〜3個に絞れた時点で並行して進めるのが実務的です。
モデルを動かす実行基盤（OllamaやvLLMなどが広く使われています）は、モデルとは独立に選べます。実行基盤を標準的なAPI形式で公開しておくと、モデルを差し替えても呼び出し側の改修が最小で済みます。ここでも「入れ替え前提」の考え方が効いてきます。
モデル選定と並行して、3つ目の条件「データの通り道」を具体化します。ここはツールの話になるため、設計の要点を3つ挙げます。
RAGで参照させる文書やデータは、一度入れて終わりではありません。たとえば人事規程が改定されたのに参照データが半年前のままなら、ローカルLLMは自信を持って古い規程を答え続けます。ファイルサーバーやデータベースから参照先へ、変更を自動で反映する経路を最初から用意しておくことが、「導入直後は便利だったのに信用されなくなった」を防ぎます。この更新経路は、スクリプトの自作でも作れますが、接続先の追加や担当交代を考えると、データ連携基盤で定期実行の形にしておくのが保守しやすい選択です。
「ローカルだから何でも入れてよい」わけではありません。社内には部門外秘や役員限りの文書があり、全社員が使うAIがそれを答えてしまえば、社外漏洩でなくても事故です。元のシステムでのアクセス権や機密区分を、AIに渡すデータの絞り込みに反映する設計が要ります。どのデータをどこまで渡すかを、人の注意力ではなく仕組みで制御するのが原則です。
データの供給層をモデル・実行基盤から切り離しておくと、モデルの世代交代のたびに作り直す必要がなくなります。7Bクラスで始めて力不足なら上位へ、逆に用途が軽ければ小型へ。モデルは交換部品になり、供給層だけが資産として残ります。冒頭で「モデルの優劣より先に決める」と述べた理由はここにあります。データ連携基盤を供給層に置く構成は、この入れ替え耐性を作る現実的な方法です。
ここまでの内容を、進め方に落とすと次のようになります。
この順で進めると、高価なGPU投資やモデルの本選定は、実データでの手応えを得た後に回せます。最初の2週間で「モデルよりデータの整備が効く」ことを体感できれば、その後の投資判断も説得力を持ちます。
データ連携について詳しく学ぶ（無料ダウンロード）
3つ目の条件「データの通り道」は、データ連携基盤「ASTERIA Warp」（累計10,000社超が導入）で作れます。ファイルサーバー・データベース・各種SaaSからデータを取り出し、変換・マスキングして、ローカルLLMが参照するデータストアへ自動で届けるフローを、ノーコードで構築できます。更新の定期実行やエラー時の通知など、運用に必要な機能も揃っています。なお、クラウドAPI側の生成AI（OpenAI・Gemini・Claude・Amazon Bedrock・Azure OpenAI）とは専用の生成AIアダプターで直接連携できます。供給層をWarpに寄せておけば、モデルや実行基盤を入れ替えても、社内システム側の接続はそのまま使い回せます。ローカルLLMの構成例は社内AIチャットボットの作り方でも紹介しています。
Q. 評価の2週間で、何から手を付ければよいですか？
A. 想定問答づくりからです。現場に「実際にAIに聞きたいこと」を出してもらい、模範解答と根拠文書を紐付けます。この数十件が、モデル比較から公開後の品質確認まで共通の物差しになります。
Q. GPUはどのくらいのものを用意すべきですか？
A. 7〜8Bクラスなら、4ビット量子化で8GB前後のGPUメモリから動かせるため、まず1枚構成で試せます。70Bクラスは複数GPUが前提になるため初期評価では推奨しません。力不足と分かってから増強するほうが投資の根拠も明確です。
Q. ローカルLLMなら情報漏洩の心配はありませんか？
A. 社外送信は避けられますが、部門外秘の文書を全社員向けAIが答える「社内での見せすぎ」はローカルでも起きます。元システムのアクセス権を参照データの絞り込みに反映してください。
Q. モデルの入れ替えはどのくらいの頻度で発生しますか？
A. 有力モデルの世代交代は数か月〜1年単位ですが、業務で問題なく動いているなら急いで替える必要はありません。「替えたいときに低コストで替えられる構成」を先に作っておけば、頻度は心配せずに済みます。
ローカルLLMの比較は、モデルの優劣からではなく、用途と精度要件・動かす環境・データの通り道という自社側の3条件から始めると決められます。モデルは数か月単位で世代交代するため、固定すべきはモデル名ではなく選定基準と入れ替えられる構成です。候補は7〜8Bクラスから、自社の想定問答で試す。業務での精度を最後に決めるのは、渡すデータの質と鮮度です。この供給層の構築には「ASTERIA Warp」が使えます。
▼ モデル選定と並行して、データの通り道を作ってみる ASTERIA Warpは全機能を試せる無料体験版をご用意。ファイルサーバーやデータベースからAIへデータを届けるフローを、ノーコードで確かめられます。 |
PM・SE・マーケティングなど多彩なバックグラウンドを持つ「データ連携」のプロフェッショナルが、専門領域を超えたチームワークで「データ活用」や「業務の自動化・効率化」をテーマにノウハウやWarp活用法などのお役立ち情報を発信していきます。
ASTERIA Warp製品の技術情報やTips、また情報交換の場として「ADNフォーラム」をご用意しています。
アステリア製品デベロッパー同士をつなげ、技術情報の共有やちょっとしたの疑問解決の場とすることを目的としたコミュニティです。
