ローカルLLMとは｜クラウドAPIとの違い・必要な設備・費用の内訳と選び方

昔、大きな会社に出向していたとき、社内で使う道具はほとんど何も持ち込めませんでした。

便利なメモアプリも、速い翻訳サービスも、全部だめ。理由は「情報が外に出るから」の一点です。当時は正直、少し窮屈だと思っていました。こんなに便利なのに、なぜ使わせてくれないんだ、と。

いまになって、あの窮屈さの正体が分かる気がします。あれは意地悪ではなく、外に出た瞬間に、私が責任が取れなくなるものを、線の内側に留めていたんです。

先に一行だけ置きます。ローカルLLMとは、AIのモデルを外部のクラウドに預けず、自社が管理する環境の中に置いて動かす構成のことです。オンプレミスのAI、とも呼ばれます。基幹システムを自前で持つのと、発想は同じです。

題材は、ホテルの滞在客からの問い合わせに答えるAIです。タオルはどこか、荷物を送りたい、近くの観光地を知りたい。1日に何百件も来る、短い問い合わせの束です。

前置きはさておき、本題に入ります。

今日は、この仕組みを作るときにクラウドから自社へ持ってこようとして、持ってこられなかった話をしていこうと思います。結論から言うと、止めたのは性能ではありませんでした。見積書の一行です。

① 教科書どおりに、クラウドのAIで作る

ローカルLLMの基本と費用の考え方をすでにご存じの方は、② そのとおりに進めて、規約で詰まるから読み進められます。

ローカルLLMとは

ローカルLLMとは、AIのモデルを外部のクラウドに預けず、自社が管理する環境の中に置いて動かす構成のことです。オンプレミスLLM、自社ホスト型LLMとも呼ばれます。

動きは単純で、モデルのファイルを自社のサーバーやPCに置き、そこで計算（推論）させるだけです。入力した文章が社外に出ない——これが唯一にして最大の違いです。

LLMとSLM（小規模言語モデル）の違い

	規模	置き場所
LLM	数百億〜数兆パラメータ	クラウドが中心。自社に置くなら相応の設備が要る
SLM	数億〜数十億パラメータ	1台のPCやサーバーに載る。用途を絞れば実用になる

ローカルで動かすという話の多くは、実際にはSLMの話です。最上位の巨大モデルを自社に置くのは、設備の面で現実的でないことが多くなります。

RAGとの違い

RAGは答えの材料を検索して渡す仕組み、ローカルLLMはその計算をどこでやるかという構成の話です。対立する選択肢ではなく、組み合わせられます。

「社内データを使いたい」ならまずRAG、「社内データを外に出したくない」ならローカルLLM、と分けて考えてください。混同すると、必要のない設備投資に向かいます。

クラウド型LLM（API型）との違い

	ローカルLLM	クラウド型LLM（API型）
データの行き先	社内に留まる	外部の事業者へ送る
費用のかたち	設備と運用の固定費	使った量に応じた従量課金
性能	置ける規模の上限がある	最上位のモデルが使える
立ち上げ	設備の調達と構築が要る	その日から使える
統制	バージョンも挙動も自社で固定できる	提供元の更新に追随する
ネットワーク	オフラインでも動く	接続が前提

比べる軸は性能ではなく、統制とデータの行き先です。性能だけで比べると、ほぼ常にクラウドが勝ちます。

ローカルLLMが注目されている背景

生成AIを業務で使いたい企業が増えた — 試す段階から、業務に組み込む段階へ移った
データを外に出せない事情が明確になった — 取引先との契約、個人情報、業界規制
小さいモデルの性能が上がった — 用途を絞れば、1台の機械で実用になる水準に届いた
量子化などの軽量化技術が普及した — 必要な設備の敷居が下がった

2つ目が実務の引き金です。「なんとなく心配」ではなく、契約書に「第三者提供の禁止」と書いてあるという具体的な形で出てきます。

ローカルLLMのメリット1｜データが社外に出ない

入力も出力も自社の環境に留まるため、第三者提供にあたらず、学習に使われる心配もありません。

「使わない」と契約で約束させるのと、「そもそも届かない」構成にするのとでは、説明の重さが違います。監査や取引先審査では、後者のほうが通しやすくなります。

ローカルLLMのメリット2｜使った量に費用が比例しない

API利用料が発生しないため、処理量が増えても課金が増えません。

ただし、無料になるわけではありません。従量課金が固定費に置き換わるだけです。量が少ないほど、1件あたりは割高になります。

ローカルLLMのメリット3｜オフラインでも動く

閉じたネットワークの工場、店舗、車内、災害時。外部接続を前提にできない場所で使えます。

ローカルLLMのメリット4｜挙動を自社で固定できる

モデルのバージョンを自社の都合で保てます。

提供元の更新で出力が変わらないのは、判定や分類のように毎回同じ答えが要る処理では大きな利点です。

ローカルLLMのデメリット1｜高度な推論は苦手

自社に置ける規模のモデルは、クラウドの最上位モデルに及びません。

複雑な文章の組み立てや、長い文脈をまたぐ推論では差が出ます。一方で、分類・抽出・定型の書き換えなら実用になります。

ローカルLLMのデメリット2｜設備と処理速度

GPU、メモリ、電力、設置場所。特にGPUのVRAM容量が、載せられるモデルの上限を決めます。

同時に使う人数を先に見積もってください。1人で試すと快適でも、10人が同時に使うと待ち時間が出ます。

ローカルLLMのデメリット3｜初期費用が先に立つ

使い始める前に、設備の調達と構築が要ります。

従量課金と違い、使わなくてもかかります。「どのくらいの量を、どれだけの期間使うか」が読めていないと、判断できません。

ローカルLLMのデメリット4｜運用できる人が要る

モデルの更新、障害対応、性能の監視。クラウドなら提供元がやっていた仕事が、自社に移ります。

導入の可否より、この担い手がいるかで決まることが多いのが実情です。

必要なハードウェアとソフトウェア

GPU — VRAMの容量が、載せられるモデルの大きさを決める
メモリとストレージ — モデルのファイルは数GB〜数十GBになる
実行環境 — OllamaやLM Studioなど、モデルを動かす道具
利用する側の口 — チャット画面、API、既存システムからの呼び出し

まずGPUを買わずに、手元のPCで小さいモデルを動かしてみてください。用途に足りるかどうかは、設備を揃える前に分かります。

量子化とは

量子化とは、モデルの数値の精度を落として、必要なメモリと計算量を減らす技術です。

精度は多少落ちますが、動かせる機械の幅が大きく広がります。同じモデルでも量子化の度合いで必要なVRAMが変わるので、選ぶときはモデル名だけでなく量子化の種類まで見てください。

ローカルLLMのモデルの選び方

用途を決める — 会話か、分類か、要約か、コード補完か
機械のスペックに載るか — VRAMと、量子化後のサイズ
日本語の性能 — 英語の評価が高くても日本語で落ちるものがある
ライセンス — 商用利用の可否と、再配布の条件を必ず読む
更新が続いているか — 開発が止まったモデルは、脆弱性が残る

ライセンスの確認を飛ばさないでください。公開されているモデルにも、商用利用に条件が付くものがあります。

主な日本語対応モデルの系統

固有のモデル名は入れ替わりが速いので、系統で覚えるのが実務的です。

汎用・バランス型 — 会話も要約もこなす標準的な系統
日本語特化・高性能型 — 日本語の読み書きに強い系統
コーディング特化型 — コードの補完とレビューに寄せた系統
軽量・低スペック向け — ノートPCでも動く小さい系統
特定用途型 — 翻訳や要約だけに絞った系統

最初に試すのは、軽量系統からで十分です。足りないと分かってから、大きい系統へ上げてください。

実行ツール（OllamaとLM Studio）

	向いている人	特徴
Ollama	システムに組み込みたい	コマンドとAPIで扱う。自動化に載せやすい
LM Studio	まず試したい	画面で操作できる。設定の見通しがよい

ローカルLLM導入の3ステップ

1. 目的と要件を整理する — どの処理を、なぜ社内に置く必要があるのかを1行で書く
2. 環境を整える — 小さいモデルを手元で動かし、実用に足るかを確かめる
3. 検証と改善を続ける — 出力の質を測り、モデルと設定を入れ替える

1で「なぜ社内に置く必要があるか」が書けないなら、クラウドで済みます。

導入時の注意点

アクセス制御を設計する — 社内に置いても、誰でも何でも聞ける状態は別のリスクになる
ライセンスを確認する — 商用利用の可否、出力物の扱い
社内へ周知して定着させる — 置いただけでは使われない
更新の担当を決める — モデルも実行環境も、放置すると古くなる

1つ目を見落としやすいのが実務の落とし穴です。「社外に出さない」ことと「社内の誰でも見てよい」ことは別です。

ローカルLLMの主な活用シーン

社内文書の質問応答 — 規程や手順書を、外に出さずに引く
コードの補完とレビュー — ソースコードを外部へ送らずに済む
文書の作成と要約 — 議事録、報告書、ナレッジの整理
分類と抽出 — 問い合わせの振り分け、帳票からの項目取り出し
閉じた環境での利用 — 工場、店舗、車内、現場

4つ目が、いちばん費用対効果が読める使い方です。出力が短く、正解が決まっており、量が多いためです。

AI開発・導入にかかる費用の内訳

金額の相場より先に、どの工程で何にお金がかかるのかを押さえます。見積書は、だいたいこの並びで出てきます。

ヒアリング・構想 — 何を作るかを決める工程
コンサルティング・要件定義 — 実現方法と範囲を確定させる
実現可能性の検証（PoC）・プロトタイプ — 作れるかを確かめる
データ整備・アノテーション — 学習や検索に使う材料を作る
モデルの開発またはモデルの選定 — 自作するか、既存を使うか
周辺システムの開発 — 画面、連携、権限
運用・保守 — 監視、改修、モデルの入れ替え

見積書で比較すべきは総額ではなく、この7つのうちどれが入っていて、どれが入っていないかです。安い見積書は、たいてい4番目と7番目が入っていません。

費用を決める5つの要因

要因	効き方
規模と複雑さ	扱うデータの種類と、連携するシステムの数で増える
使う技術	既存モデルを使うか、自作するかで桁が変わる
体制と人数	人月で積まれる。専門性が高いほど単価が上がる
期間	短納期は人数を増やすことになり、総額が上がる
法規制・監査要件	証跡、権限、保管期間の要件が実装量を押し上げる

2行目がいちばん大きく効きます。モデルを自作する必要が本当にあるかを、最初に疑ってください。

見落としやすいランニングコスト

クラウドやGPUの利用料・電力
API利用料またはライセンス料
サーバーと実行環境の保守
モデルの入れ替えと再検証
セキュリティ対策と監査対応
法規制が変わったときの改修

ローカルLLMを選ぶと、上の1・3・4が自社に移ります。API利用料が消える代わりに、この3つが毎年かかる——これが「固定費に置き換わる」の中身です。

費用を抑える方法

範囲を絞って小さく始める — 1業務・1部署から
既存のモデルやAPIを使う — 自作しない
ノーコード・オープンソースを使う — 作らずに組み合わせる
データ整備を自社側で持つ — 外注の工数が最も減る箇所
必要な部分だけを自社環境で動かす — 全部を持たない
補助金・助成金を使う — IT導入補助金、ものづくり補助金など

5つ目が、この記事の後半で扱う考え方です。所有するか借りるかを、全か無かで決めないという話になります。

AIは「開発」と「導入」のどちらが費用対効果が高いか

	向いているとき	注意点
既製サービスの導入	やりたいことが一般的な業務	自社の業務に合わせる自由度が低い
個別開発	自社固有の業務やデータが中心	初期費用と期間がかかる。運用の担い手が要る

先に既製サービスを当ててください。合わない箇所が具体的に言えるようになってから開発を検討すると、作る範囲が大きく減ります。

発注先の選び方と見積書の見方

複数社から見積もりを取る — 金額ではなく、工程の分け方を比べる
実績を、同じ業種・同じ処理で確認する
納品後の保守が入っているかを確認する
「含まれないもの」を書いてもらう

安い＝コスパが良い、ではありません。安い見積書は範囲が狭いだけのことが多く、差額は後から追加見積もりとして出てきます。

最初は、教科書どおりに作りました。

→ 対話AIのサブスクリプションを契約する
→ 問い合わせをAPIに投げる
→ 返ってきた文章をそのまま返す
→ 難しいものだけ人に回す

きれいに動きました。 精度も速度も十分で、作るのに時間もかかりません。

社内データの扱いも、教科書どおりに手当てしました。一般向けの契約では入力が学習に使われる場合があるので、法人向けの契約に切り替える。これで「入力は学習に使わない」が契約で担保されます。

ここまでは、教科書どおりです。
このときの構成を数字で置いておきます。問い合わせは1日あたり数百件、応答は2秒以内、対応言語は3つ。 精度も速度も、要件を満たしていました。

ここまでが、ローカルLLMと、AIにかかる費用の教科書どおりの整理です。データの行き先で選び、小さいモデルから試し、固定費に置き換わることを承知のうえで判断する。

この記事の後半で扱うのは、その判断を実際にやってみた話です。教科書どおりにクラウドで作り、規約で詰まり、自社に持ってこようとして見積書の一行で止まりました。そこから何を見直したのかを見ていきます。

② そのとおりに進めて、規約で詰まる

ところが、詰まったのは性能でも精度でもありませんでした。規約です。

使っていた対話AIのサブスクリプションが、契約上、1アカウントの共有を禁じていることが分かりました。サーバー経由で複数人が使う構成を組むと、それが「認証トークンの共有」に当たるのではないか。あるいは「人格的な操作代行」とみなされるのではないか。

規約を読んでも、どちらとも読めます。

黒とは書いていない。白とも書いていない。判断がつかないまま、構成を変えるかどうかの議論になりました。

ここで気づきます。性能の話は、一度も出ていません。

法人契約で解決したのは「入力を学習に使われない」の一点だけでした。処理が向こうの環境で走ること自体は、何も変わっていません。 その事実が、規約という形で戻ってきただけです。

代替として、重みが公開されている別系統のモデルが候補に挙がりました。これなら自社で動かせます。ただ、そのモデルは中国発で、情報の扱いと倫理観の面で懸念が出ました。ここでも止まります。

では、自社の中で動かせばいい。 記事の前半に書いたとおりの結論です。そこで、見積もりを取りました。

③ そして、見積書を見て止まる

エンジニアが出してきた見積もりは、こういう構造でした。

→ ローカルLLMを動かすには、GPUを積んだサーバーが要る
→ その費用は、使っても使わなくても毎月出ていく固定費になる
→ 対してAPIは、使った分だけの従量課金で済む

金額そのものは伏せますが、構造だけで判断がつきました。

項目	自社で持つ	借りる
費用の出方	毎月固定	使った分だけ
使わない月	同額かかる	ほぼゼロ
必要な機材	GPU搭載サーバー	不要
立ち上げまで	数週間	即日

片方は毎月確実に出ていき、もう片方は使わなければほとんど出ていきません。

この差が決定的でした。

両者は、そもそも比較の土俵が違います。 単価を並べても意味がない。並べるべきは、自社の利用量が、両者の入れ替わる点のどちら側にあるかです。

サーバーの費用は、基本料と使った分に分かれます。小さい組織では基本料が重すぎて、大きくなるほどローカルが有利になる。 つまり、分岐点が実在します。

そして私たちは、その手前に立っていました。

「大企業ほどローカルに行き着く」というのは、思想の話でも意識の高さの話でもありません。単に、分岐点の向こう側に立っている、というだけの話でした。

④ 原因は「所有か、借りるか」を全か無かで考えていたこと

止まった原因を一つに絞ると、これでした。

私たちは、ローカルにするかしないかを、全部か全部でないかで考えていました。

問い合わせ対応という仕事を、ひとかたまりの箱として見ていた。だから「この箱を自社に持ってくると、いくらかかるか」という問いになり、答えは「固定費が重すぎる」になった。

けれど、実際の処理は一枚岩ではありません。

→ どの種類の問い合わせか判定する（タオル／配送／観光）
→ その種類に応じた答えを組み立てる
→ 判断がつかないものを人に回す

このうち、社内の機密に触れるのはどこか。 監査で挙動を固定したいのはどこか。提供側の都合で止まると事業が止まるのはどこか。

問いを分解した瞬間に、答えが変わりました。

⑤ 直してみる — 統制権が要る場所だけを、自社に持つ

やったことは3つです。

1. 処理を分解して、統制権の要否を1行ずつ書いた。
「この処理は、外に出た瞬間に自分で責任が取れなくなるか」を基準にしました。全部に○が付くわけではありません。観光地の紹介文を作るのに、統制権は要りません。

2. 振り分けだけを、自社の小型モデルに移した。
問い合わせがどの種類かを判定する部分だけを切り出し、専用の小さなモデルを作りました。容量は100MB程度。ルーティングの精度は95%から97%まで上がりました。 大きなモデルを借りて振り分けさせていたときより、速くて、安くて、外に出ません。

3. 残りは借りたままにした。
答えの文章を組み立てる部分は、クラウドのAPIのままです。ここを自社に持つ理由が無かったからです。

そして、この構成にした瞬間に、固定費の問題が消えました。 100MBのモデルはGPUを積んだサーバーを必要としません。

→ 所有すべき場所だけを所有する
→ 分岐点は、処理を分解すると手前に動く
→ 動かせる線だった

⑥ あとで知った — この作り方には、名前がついていた

素朴な対処のつもりでしたが、調べると同じものを指す言葉は、すでにありました。

1つ目。用途を絞った小さなモデルには名前があります。小規模言語モデル（SLM／Small Language Model）です。「小さい」が指しているのはパラメータの数で、少ないぶん速く、動かすのに要る資源も小さい。特定の仕事をこなすために作られる、と説明されています。

規模感も具体的です。Microsoft の Phi-3 系列は、Phi-3-mini が38億、Phi-3-small が70億、Phi-3-medium が140億パラメータという構成になっています。「小さい」と呼ばれる領域が、すでにこれだけ確立しているということです。

2つ目。難しさに応じてモデルを振り分ける組み方も、既に語られていました。問い合わせを受け取って評価し、適切なモデルへ振り分ける役割を置く。単純な依頼は小さなモデルが処理し、複雑なものは大きなモデルに回す。難易度・リスク・遅延・プライバシー・コストを見て自動的に選ぶ、と説明されています。

「プライバシー」が選択の基準として並んでいるのが要点です。 私が「統制権が要る処理だけ自社に置く」と呼んでいたものは、この振り分けの一項目でした。

3つ目。所有と賃借の分岐点は、昔からある損益分岐の話でした。固定費と変動費が入れ替わる点を探すという、それだけのことです。AIに限った新しい問題ではありません。

新しい理屈は、ひとつも要りませんでした。

⑦ 何が変わったか

判断の順番が、逆になりました。

“`
前：ローカルにするか？ → 見積もりを取る → 高いのでやめる
後：どの処理に統制権が要るか？ → その部分だけ見積もる → 持てる
“`

「ローカルLLMを導入するか」は、そもそも問いの立て方が間違っていました。 導入するのは製品ではなく、処理ごとの判断だからです。

⑧ 現場で使うなら、この2枚

表1：統制権の棚卸し（処理を1行ずつ書く）

処理	機密に触れるか	挙動を固定したいか	止まると事業が止まるか	判定
問い合わせの種類判定	入力に個人情報	監査対象	入口なので止まる	自社
回答文の生成	触れない	不要	代替可能	借りる
観光情報の紹介	触れない	不要	代替可能	借りる
決済に関わる確認	触れる	固定したい	止まる	自社

3列とも「いいえ」なら、借りてください。 1つでも「はい」が付いた処理だけを、自社に持つ候補にします。全部に○を付けると、固定費で止まります。

表2：分岐点を手前に動かす手

手	何をするか	効き方
処理を分解する	統制権の要否を処理ごとに判定	最も効く。箱のままだと必ず高い
モデルを小さくする	用途を絞ってSLMにする	GPUが不要になる規模まで落ちる
~~基本料を分ける~~	~~複数社でサーバーを共有~~	見送った。理由は次節

補：判断に使った数字

項目	値
検査が通る回数	1日あたり数千回
振り分けモデルの容量	100MB
ルーティング精度	95%から97%
常駐に使えるメモリ	16GB中の数百MB
1件あたりの判定	数十ミリ秒
対応言語	3件
応答の目標	2秒以内

ところで、この7行のうち5行は、処理を分解しなければ測れない数字です。箱のまま見積もると、1行目しか出てきません。

⑨ この考え方が効き続ける理由

モデルの値段は、これからも下がります。それでも、この判断は消えません。 値段の問題ではないからです。

→ AIが基幹に食い込む → 判断そのものを担うようになる
→ 事故が起きたとき、頭を下げるのは貸した側ではなく、組み込んだ側
→ 責任を持つ側が、判断の土台を所有していない → いずれ耐えられなくなる

賢さは借りられます。責任は借りられません。

大企業がローカルへ向かうのは、けちだからでも時代遅れだからでもありません。責任を持つ主体は、いずれ土台を所有したくなるという力学です。

ただし、正直に書いておきます。所有した瞬間に、運用の重さがまるごと自分に乗ります。

この記事を書いている途中で、社内の判断が動きました。サーバーを共有して基本料を割る案は、見送りになっています。

「ローカルLLMの運用における課題として、同時接続時の速度低下が挙げられました。特にMac環境ではNVIDIA CUDAのような最適化された計算資源が利用できないため、性能面で不利である現状が確認されました。」

「本格的なシェアホスティング事業を展開するには、接続数やアカウント管理、ルーティングなどの検証に多大なコストと手間がかかるため、スモールスタートは難しいとの認識が共有されました。」

「基本料を割れば手が届く」は、割る側の運用コストを数えていませんでした。 接続数の制御、アカウントの管理、どのモデルへ流すかの振り分け。共有するということは、その全部を自分が持つということです。

同じ日に、仮想マシンからの撤退も決まっています。当初はそこでローカルLLMを動かす想定でしたが、メリットが薄れたという判断でした。

一方で、明るい材料も同じ場で共有されています。小規模ながら高性能なモデルが出てきており、自社でのホスティングは現実的になりつつある、という見立てです。

分岐点は動きます。ただし、動かす方向は「共有して割る」ではなく「小さくして要らなくする」でした。

だから、全部を持たない。持つべき場所を決める。 そこだけが、今日の話です。

関連して、ファインチューニングで用途を絞ったモデルを作る話と、MCPで社内の文書をAIから引けるようにする話を別に書いています。社内RAGが現場で止まる場所話はすでに公開しています。あわせて読むと、同じ判断が別の場所でも効いていることが分かると思います。

この判断を実際の案件で使う場面については、社内GPT・RAG構築のページに整理しています。

手元に置きたい、といえば、電子で買った本を紙でも買い直したことが何度かあります。

置き場所はもうありません。それでも手元にある状態に、いくらか払っているわけです。

以上です。

ローカルLLMのよくある質問

ローカルLLMとクラウド型LLMは何が違いますか？

違いは6点です。データの行き先（社内に留まるか、外部の事業者へ送るか）、費用のかたち（設備と運用の固定費か、従量課金か）、性能（置ける規模の上限があるか、最上位モデルが使えるか）、立ち上げ（調達と構築が要るか、その日から使えるか）、統制（バージョンと挙動を自社で固定できるか、提供元の更新に追随するか）、ネットワーク（オフラインで動くか、接続が前提か）。比べる軸は性能ではなく、統制とデータの行き先です。

ローカルLLMに必要なスペックを教えてください。

決め手はGPUのVRAM容量で、これが載せられるモデルの大きさを決めます。加えてメモリとストレージ（モデルのファイルは数GB〜数十GB）、OllamaやLM Studioのような実行環境が要ります。ただし、まずGPUを買わずに手元のPCで小さいモデルを動かしてみてください。用途に足りるかは設備を揃える前に分かります。同時に使う人数も先に見積もってください。

量子化とは何ですか？

モデルの数値の精度を落として、必要なメモリと計算量を減らす技術です。精度は多少落ちますが、動かせる機械の幅が大きく広がります。同じモデルでも量子化の度合いで必要なVRAMが変わるので、モデルを選ぶときはモデル名だけでなく量子化の種類まで見てください。ローカルLLMの敷居が下がった理由のひとつです。

ローカルLLMのモデルはどう選べばよいですか？

5点で絞ります。用途を決める（会話か、分類か、要約か、コード補完か）、機械のスペックに載るか（VRAMと量子化後のサイズ）、日本語の性能、ライセンス（商用利用の可否と再配布の条件）、更新が続いているか。ライセンスの確認を飛ばさないでください。公開されているモデルにも、商用利用に条件が付くものがあります。

AI開発の費用は何で決まりますか？

工程はヒアリング・構想、コンサルティングと要件定義、PoC・プロトタイプ、データ整備とアノテーション、モデルの開発または選定、周辺システムの開発、運用・保守の7つです。金額を動かす要因は、規模と複雑さ、使う技術（既存モデルを使うか自作するかで桁が変わる）、体制と人数、期間、法規制と監査要件の5つ。見積書は総額ではなく、7工程のどれが入っていてどれが入っていないかで比べてください。

ローカルLLMとは何ですか？

AIのモデルを、外部のクラウドに預けて呼び出すのではなく、自社が管理する環境——自前のサーバーや閉じたネットワーク——の中に置いて動かす構成です。オンプレミスのAIとも呼ばれます。モデルもデータも自社の線の内側で完結するため、社内データを外に出さずにAIを使えます。基幹システムを自前で持つのと、発想は同じです。

エンタープライズ版を契約すれば、情報漏洩の問題は解決しますか？

入力を学習に使われない、という一点は解決します。しかし処理が提供側の環境で走ることは変わりません。モデルの更新や廃止も提供側の都合で起き、同じ入力への応答が変わることがあります。データの流出は防げても、挙動の主導権は戻ってきません。監査のために挙動を固定したい場合は、この差が効いてきます。

ローカルLLMとクラウドAPIでは、どちらが安いですか？

比較の土俵が違います。ローカルはGPUを積んだサーバーの費用が、使っても使わなくても毎月出ていく固定費になります。APIは使った分だけの従量課金です。したがって利用量が小さいうちはAPIが安く、量が増えるほどローカルが有利になります。両者が入れ替わる分岐点が必ず存在し、それが自社のどちら側にあるかで判断が決まります。

小さな組織でもローカルLLMを使う方法はありますか？

全部を自社で動かす必要はありません。処理を分解し、統制権が要る部分だけを小型モデルに任せる方法があります。分類や振り分けのような限定された仕事なら、数百MB規模のモデルでも実用精度が出ます。Microsoft の Phi-3-mini が38億パラメータであるように、用途を絞れば小さなモデルで足ります。