ローカルLLMとクラウドLLM APIの選び方：コスト・プライバシー・品質・運用・オフラインの5観点で比較

選ぶ前に答えておく5つの問い

ここでいうローカルLLMは、公開されたモデルの重み（オープンウェイト）を手元のPCや自社サーバーに置き、OllamaやTllama.cppなどの推論ソフトで動かす方法を指す。クラウドのLLM APIは、事業者が運用するモデルをインターネット経由で呼び出す方法を指す。

どちらを選ぶかは、次の5つの問いへの答えでほぼ決まる。1つ目は、外部に送れないデータを扱うか。2つ目は、どの程度の回答品質が必要か。3つ目は、利用量が多くて安定しているか、少なくて変動しやすいか。4つ目は、ネットワークのない環境で動かす必要があるか。5つ目は、十分なハードウェアと、それを保守する人手があるか。

データを外に出せない、オフラインで動かしたい、という条件が強いほどローカルが有利になる。最高水準の品質が必要、利用量が読めない、運用に人を割けない、という条件が強いほどクラウドAPIが有利になる。両方の条件が混ざるなら、組み合わせる構成を検討する。

5つの観点で比べる

コスト構造：固定費型と従量課金型

クラウドAPIの料金は、テキストを細かく分けた単位である「トークン」の入力量と出力量で決まることが多い。少量の利用なら安く済み、使わない月は費用がかからない。一方で、利用量に比例して費用が増える。長い文書を毎回渡す処理や、モデルを何度も呼び出すエージェント型の処理は、想定より高額になりやすい。単価は頻繁に改定されるため、試算には各社の公式料金ページで執筆時点の値を確認してほしい。

ローカルは固定費型だ。十分なGPUやメモリを積んだマシンを用意すれば、処理量が増えても追加で増えるのは主に電気代になる。ただし、使わない時間もハードウェア費はかかり続け、数年で性能不足になる可能性もある。すでに適したPCを持っているなら、試すだけの費用はほぼゼロになる。

データの扱いとプライバシー：規約で守るか、物理的に閉じるか

ローカルの最大の利点は、入力したデータが外部に出ないことだ。社外秘の文書や個人情報を扱う場面では、社内の審査を通しやすくなる。ただし、ローカルなら自動的に安全になるわけではない。サーバーへのアクセス制御やログの管理は自分の責任になる。モデルファイルも信頼できる配布元から入手する必要がある。

クラウドAPIでは、データは事業者のサーバーに送られる。法人向けAPIでは、入力を学習に使うかどうかや保存期間が規約で決められていることが多い。条件は事業者や契約プランごとに違う。データ保存期間、処理される地域、学習への利用の有無を公式の規約で確認してから判断する。

性能と品質：上限の高さはクラウドにある

複雑な推論、長い文書の読解、難しいコード生成では、一般にクラウドの大規模モデルが有利だ。ローカルで動かせるモデルの規模は、GPUのメモリ（VRAM）やApple Siliconの統合メモリの容量で決まる。多くの場合は「量子化」を使う。量子化とは、重みの精度を下げてメモリ使用量を減らす手法で、品質が多少落ちることがある。

とはいえ、要約、分類、情報抽出、決まった形式への変換といった範囲の限られたタスクなら、ローカルの中規模モデルでも実用になることが多い。速度の面でも違いがある。ローカルの速度はハードウェアで決まり、APIの速度は通信状況や事業者側の混雑、利用回数の上限（レート制限）に左右される。また、オープンウェイトモデルはモデルごとにライセンスが違い、商用利用に条件が付くものもある。

導入と運用の手間：ローカルは手軽になったが保守は残る

Ollamaを使うと、モデルのダウンロードから実行までを少ないコマンドで済ませられる。OpenAI互換のAPIも用意されているため、既存のコードから呼び出しやすい。llama.cppはC/C++で書かれた軽量な推論エンジンで、GGUF形式のモデルを細かい設定で動かせる。導入のハードルは下がったが、GPUドライバの管理、メモリに合わせたモデル選び、複数人で同時に使うための構成、モデルの更新は自分で行う必要がある。

クラウドAPIは始めるのが簡単で、インフラの保守もいらない。弱点は外部への依存だ。事業者側で障害が起きれば止まる。古いモデルの提供が終われば移行作業が発生する。特定の事業者のAPIに合わせて作り込むほど、他へ移りにくくなる。

オフライン利用：ローカルだけが選べる

モデルをダウンロードした後は、ローカルLLMはネットワークなしで動く。移動中の作業、通信環境が悪い現場、インターネットから切り離された閉域網でも使える。クラウドAPIは通信が前提なので、この条件がある場合は選べない。

手持ちのハードウェア別の向き不向き

GPUのない一般的なノートPC

小さなモデルなら動くが、応答が遅く、品質にも限界がある。仕組みを学ぶための試用には向く。業務の本番用途ではクラウドAPIが現実的だ。

独立GPUを積んだPC、またはメモリの多いApple Silicon機

中規模のモデルを実用的な速度で動かせる。個人開発や少人数での定型処理、機密文書の要約などはローカルで十分に回せる。難しいタスクだけAPIに任せる使い分けがしやすい構成だ。

自社のGPUサーバー

複数人や社内システムに向けてLLMを提供できる。ただし、同時アクセスへの対応、監視、障害対応を担当する人が必要になる。運用の体制がないなら、ハードウェアがあってもAPIの方が安く済むことがある。

用途と予算別の向き不向き

個人の学習や試作で予算が少ない場合は、少量のAPI利用が最も安く手軽なことが多い。手持ちのPCで十分なら、ローカルで試してもよい。顧客に見せる機能で最高水準の品質が必要なら、クラウドAPIが第一候補になる。機密データを扱う社内業務では、ローカルが有力だ。ただし、データを保存しない条件の法人契約でAPIを使う方法もあるので、社内規程と照らし合わせて比べる。大量の定型処理が長く続く場合は、ローカルが割安になる可能性がある。ただし、ハードウェア費と人件費を含めた試算をしてから決める。

組み合わせる構成が向く場合

組み合わせが効くのは、主に次の3つの場面だ。1つ目は、データの機密度が混ざっている場合だ。個人情報の伏せ字化や文書の分類をローカルで行い、外に出してよい部分だけをAPIに送る。2つ目は、タスクの難しさに差がある場合だ。簡単な処理はローカルで安く済ませ、難しい処理だけをAPIに回す。3つ目は、止められない業務の場合だ。API障害時やオフライン時に、ローカルを予備として使う。

この構成の弱点は、2つの仕組みを保守する手間と、モデルによって出力の品質や書式が揃わないことだ。OpenAI互換のような共通の呼び出し方にそろえ、どの処理をどちらに回すかの基準を文書にしておくと、切り替えと検証が楽になる。

判断するための次の一手

まず、扱うデータを「外部に送れるもの」と「送れないもの」に分ける。送れないデータがあれば、ローカルか、データ非保持の条件で契約したAPIに絞られる。次に、実際の業務で使う入力を数十件用意し、ローカルとAPIの両方で出力を比べる。品質が要件を満たすのがAPIだけなら、答えはAPIになる。両方とも満たすなら、月々のトークン量から計算したAPI費用と、数年分のハードウェア費・電気代・運用の人件費を比べる。最終的には、品質・データ・費用の3つの条件をすべて満たす方を選ぶ。どちらか一方では満たせない条件があるときに、組み合わせる構成を選ぶ。