「セキュリティが心配ならオンプレ、そうでなければクラウドAPI」——この二分法で決めた構成は、たいてい途中でどちらかに寄せ直すことになる。 理由は単純で、実際の選択肢は2つではなく3つあり、しかも「決めること」は一度きりの二択ではなく、順番に決まっていく一連の判断だからだ。
生成AIの利用を始めた企業の多くが、次の一段で立ち止まる。私有LLM（プライベートLLM）を自社で建てるべきか、それともOpenAIやAnthropic、Googleといったフロンティアモデルのプロバイダーへ、API経由で任せておけば十分なのか。この記事では、その分岐点をどう決めるかを、実際に存在する3つの構成と、決める順序に沿って整理する。
「オンプレは安全、クラウドは手軽」では決まらない理由
この二分法が雑なのは、「安全」と「手軽」という言葉が指すものが曖昧だからだ。私有LLMを建てても、ネットワークの境界設計やアクセス制御をおろそかにすれば安全とは言えないし、フロンティアAPIを使っていても、送信するデータの範囲や保持設定を契約で縛れば、多くの業務では十分な統制がかかる。
本当に効いているのは「安全」か「手軽」かではなく、プロンプトに載せるデータがどこへ流れ、誰のサーバーで処理されるかという一点だ。この軸で見ると、選択肢は実は3つある。
選択肢は2つでなく3つある
企業が生成AIを使う構成は、実務上ほぼ次の3パターンに収まる。
- プライベートLLM——自社が管理する、またはベンダーが代理で運用するインフラの上でモデルを動かす。プロンプトと生成結果は自社の環境内で処理され、公開のAIサービスへは送信されない。
- フロンティアAPI——OpenAI・Anthropic・Googleといったプロバイダーのモデルを、API経由でそのまま利用する。プロンプトはそのプロバイダーのサーバーへ実際に送られる。データ保持設定の調整や送信範囲の限定、契約上の取り決めで統制をかける形になる。
- ハイブリッド——機密度の高い処理はプライベート経路へ、それ以外はフロンティアモデルへ振り分ける構成。
3つとも「データがどこへ流れるか」がそれぞれ異なり、その違いこそが選ぶ理由になる。この整理は当社のAI開発サービスのデータプライバシーFAQでも扱っている（AI開発サービス）。3つのうちどれを選ぶかは、まず「何が流れるか」を分類しないと決められない——これが次の順番の話につながる。
決める順番：まずデータを分類する
3構成のうち何を選ぶかを、機材の予算やベンダーの営業トークから決め始めるのは順番が逆だ。決める順序は次のようになる。
- プロンプトに載る可能性があるデータを洗い出す——社内文書、顧客データ、ソースコード、契約書など、第三者へ渡せない機密保持義務の対象になり得るものはどれか。
- その中に、公開AIサービスのサーバーへ送信したくないものがあるかを判定する——1件もなければ、フロンティアAPIだけで足りる可能性が高い。一部にあるなら、その部分だけプライベート経路に振り分けるハイブリッドが選択肢に入る。大半、あるいは業務の中核がそれに該当するなら、プライベートLLMを本格的に検討する価値がある。
- ここで初めて、インフラの規模やモデルサイズの検討に進む——「自社でAIを持ちたい」という気分から入り、後から機密データの有無を後付けで正当化する順番だと、過剰投資か過小投資のどちらかに寄りやすい。
この順番を踏まえると、「私有LLMを建てるかどうか」自体は、実はセキュリティポリシーの選択ではなく、データ分類の結果としてほぼ自動的に決まることが多い。悩みどころは、むしろこの先——私有LLMを選んだ場合に何を決めることになるか、にある。
私有LLMを選んだら、次に決まる2つのこと
データ分類の結果、私有LLMが視野に入ったとする。ここから先の判断は大きく2つに分かれる。「どう動かすか」という提供形態の話と、「どのサイズを積むか」というモデル構成の話だ。この2つを一緒くたに議論すると、判断がぶれる。
どう動かすか——3つの提供形態
私有LLMには「これが正解」という単一のデプロイ形態はない。3つの形態それぞれに、最も安く済む利用規模がある。
- セルフホスト（自社設置）——GPUハードウェアを自社の建物に設置する。機材は初日から自社の資本資産になる。継続的・高負荷・予測可能な利用では最も安くなりやすいが、前提として建物側が電源・冷却負荷に対応できる必要がある。
- マネージドホスティング——ベンダーがハードウェアを預かって運用する。電源・冷却・UPS・接続・監視を月額費用に含む。ハードウェアの所有権は保ちながら、設備面の負担だけを外に出せる。
- 共有インフラ——ハードウェア購入は一切不要。GPU/VRAM容量を単位課金でレンタルする。利用が軽い、あるいはまだ様子見の段階に向く。
どれか一つが常に有利ということはなく、利用規模によって最適解が入れ替わる。この3形態の詳しい比較はプライベートLLM基盤にまとめている。
どのサイズを積むか——精度の下限と同時利用の上限は、別の軸
モデルサイズの検討でよくある勘違いは、「大きいモデルほど良い」という一本のはしごとして考えてしまうことだ。実際には、モデルサイズを押し上げる理由は2つあり、それぞれ別の軸にある。
軸1：精度の下限。業務で使い物になる回答品質を確保するための最小サイズという軸だ。
- **32Bクラス（Dense）**が、業務利用として実用に耐える下限に位置する。これより小さくしようとすると、精度面で業務利用として厳しくなる場面が増える。
- **70Bクラス（Dense）**が既定・推奨の位置づけになる。理由は抽象的な「余裕を見て大きめ」ではなく、1台のマシンで、全社共通で使うChatGPT相当のアシスタントを近似できるサイズという、具体的な基準に基づいている。多くの企業にとって、この規模が「まず立てる1台」の答えになる。
軸2：同時利用の上限。これは精度ではなく、同時に何人・何リクエストをさばけるかというスループットの軸だ。
- 122B-A10B（MoE、アクティブ10B）や400Bクラス（MoE、アクティブ17B）は、精度を追加で底上げするためというより、より高い同時利用に対応するための選択肢として位置づく。
この2つの軸を混同すると、「精度が足りないから」という理由で同時利用向けの大型モデルに手を伸ばしてしまったり、逆に「同時アクセスが増えてきたから」という理由で精度重視のモデルに乗り換えてしまったりと、サイジングを誤りやすい。困っているのが回答の質なのか、さばける量なのかを先に切り分けるのが、ここでの実務上のコツになる。
もう一つ、位置づけが異なるモデルクラスがある。35B-A3B（MoE、アクティブ3B）は、トリアージやガードレールといった役割専用で、回答モデルとしてのサイズ・位置づけではない。アクティブパラメータが小さい分、リクエストの振り分けや安全性チェックのような軽い判定を高速・低コストでこなすのに向いているが、業務の主要な回答をこのモデル単体に任せる設計にはしない、という区別だ。
量子化はどこまで下げていいか——FP8を下限にする理由
ハードウェアコストを下げる手段として、量子化をさらに進める（たとえば4bit/INT4まで下げる)という選択肢は技術的には存在する。当社の標準構成ではFP8を下限とし、それより下へは既定では踏み込まない。
理由は理論ではなく実測にある。当社のテストでは、FP8より量子化を進めると、日本語のビジネスタスクにおける精度低下が明確に確認されている。ハードウェア費用を抑えられる可能性がある一方で、それを既定の推奨として提供することはしていない——これは「安全側に倒した保守的な方針」というより、測定結果に基づく線引きだ。
決める前に確かめる:ハードウェアを買う前に測る
ここまでの3つの決めごと——構成（プライベート/API/ハイブリッド)、提供形態（セルフホスト/マネージド/共有)、モデルサイズ(精度の下限と同時利用の上限、量子化の下限)——は、いずれも「自社の場合はどうか」を測らずに一般論だけで決め切れるものではない。
GPU一式をそろえるフルビルドの機材投資は、規模によっては小さくない金額になる。それを、精度も速度も測っていない段階でコミットするのはリスクが大きい。そこで、機材投資の前に自社のドキュメント・ワークロードに対して実際に検証する30日間の私有LLM PoCという選択肢がある。70Bクラスの既定モデルを起点に、必要であれば32Bクラスまで下げる、あるいは122B-A10Bや400Bクラスまで上げるといった判断を、推測ではなく実測の精度・レイテンシに基づいて行い、どの提供形態が自社の利用パターンに合うかまで含めて、書面のレポートとして受け取る形になる。
まとめ:分岐点の決め方
私有LLMかAPIかを、雑な二分法ではなく、実際の順序で決めるなら次のようになる。
- プロンプトに載るデータを洗い出し、公開AIサービスに送りたくないものがあるかを判定する。これで、プライベートLLM・フロンティアAPI・ハイブリッドのどれが土台になるかが、ほぼ決まる。
- プライベートLLMが視野に入ったら、「どう動かすか」（セルフホスト/マネージド/共有)と「どのサイズを積むか」(精度の下限・同時利用の上限・量子化の下限)を、別の判断として分けて検討する。
- 一般論での見積もりだけで機材投資に進まず、自社のワークロードで測ってから確定する。
この順序を踏めば、「オンプレは安全、クラウドは手軽」という雑な二分法に頼らずに、自社にとって妥当な分岐点を選べるはずだ。