「クラウドのLLM APIを検討したが、情報セキュリティ部門の審査で止まった」

製造業、金融、医療、公共。この4分野からの相談は、ほぼこの一文から始まります。技術検証は済んでいる。効果も見えている。しかし外部へのデータ送信が社内規程で許可されない。

規程を変える交渉は現実的ではないことが多いので、データを出さずに動かす構成を考えることになります。ここでは、実際にやってみて何が難所だったかを書きます。

難所は「モデルが動くか」ではない

先に結論を書くと、オンプレLLMの難所はモデルではありません。オープンウェイトのモデルを1台のGPUサーバで動かすこと自体は、いまや技術的にほぼ解決済みです。

実際に苦労するのは次の3つです。

  1. どの規模のハードウェアを買うべきかの判断
  2. 外部接続のない環境で、ソフトウェアをどう供給し続けるか
  3. 「クラウドの最新モデルと比べて実用になるのか」への回答

順に書きます。

1. ハードウェア選定 — 見積の妥当性を検証できない問題

GPUサーバの見積は取れます。しかし、その構成が過剰なのか不足なのかを検証できない。これが多くの企業で起きています。数千万円の投資判断を、提案元の説明だけを根拠に行うことになる。

判断は、次の3つから逆算します。

扱うモデルのメモリ要件

パラメータ数と量子化の程度から、必要なGPUメモリはおおむね決まります。ここは計算できる部分です。重要なのは、推論時にはモデル本体だけでなくKVキャッシュがメモリを食うことで、これは同時利用者数とコンテキスト長に比例して増えます。モデルサイズだけで見積もると、同時アクセス時に落ちます。

同時利用者数とレイテンシ要件

社内50名が「時々使う」のと、バッチ処理で数万件を回すのとでは、必要な構成がまったく違います。前者は1枚のGPUで足りることが多く、後者は台数を並べる話になります。

ここで効くのが、要件を「ピーク」ではなく「許容できる待ち時間」で表現し直すことです。「即座に返ってほしい」と「5分待てる」では、必要な投資額が一桁変わります。バッチ用途なら夜間に流せばよく、その場合は最小構成で足ります。

電源・冷却・ラック

見落とされがちですが、既存のサーバルームに入らない、電源容量が足りない、という理由で構成をやり直すケースが実際にあります。ハードウェアの見積と同時に、設置環境の確認を必ず行ってください。

当社では、この構成診断だけを2週間・定額で提供しています。既存ベンダー提案のセカンドオピニオンとしてのご依頼も承っています。

2. 閉域環境でのソフトウェア供給 — ここが本当の難所

これが最も過小評価されている部分です。

インターネットに繋がっていない環境では、次のものが全て取得できません。

  • コンテナイメージ
  • Python パッケージ（pip / conda）
  • OS のセキュリティアップデート
  • モデルの重みファイル
  • ドライバ・CUDA ライブラリ

つまり、構築時に一度持ち込めば終わりではなく、更新し続ける経路を設計する必要があるということです。これを設計せずに構築すると、半年後に「脆弱性が見つかったが更新できない」という状態になります。

現実的な解は、閉域内に以下を持つことです。

  • 内部コンテナレジストリ
  • 内部パッケージミラー
  • モデルリポジトリ

そして、DMZ に置いた中継サーバから定期的に同期する運用フローを作ります。同期の頻度と承認フローは、情報システム部門と事前に握っておく必要があります。

この設計を含めずに出された見積は、後から必ず追加費用になります。 提案を受け取ったら、ここが書かれているかを確認してください。

3. 「クラウドの最新モデルと比べて実用になるのか」

正直に書きます。用途によります。

汎用的な対話性能や、複雑な推論を要するタスクでは、依然としてクラウドの大規模モデルが明確に優位です。ここを曖昧にして「オンプレでも同等です」と言うベンダーは信用しないほうがいいと思います。

一方で、次のような限定されたタスクでは、オープンウェイトモデルで十分な精度が出ることが多くあります。

  • 社内文書を検索して該当箇所を要約する
  • 決まった形式で情報を抽出する（帳票、報告書、ログ）
  • 定型文書の分類・振り分け
  • 議事録の要約

共通しているのは、タスクが狭く、正解の形が決まっていることです。逆に言えば、オンプレLLMの導入を成功させる鍵は、モデル選定よりも用途を狭く切ることにあります。

判断方法はひとつです。貴社の実データで検証する。 一般的なベンチマークのスコアは、業務データでの性能をほとんど予測しません。当社では、まず数百件の実データで評価し、実用に足るかどうかを定量的にお示しします。足りない場合は、その事実をそのままお伝えします。

ハイブリッドという選択肢

最後に、見落とされがちな選択肢を書いておきます。

全てをオンプレに置く必要はありません。

データの機密度は一様ではないはずです。真に外に出せないデータと、マスキングすれば出せるデータ、そもそも公開情報を扱う処理が混在しているのが普通です。

  • 機密データの処理 → 閉域内のローカルLLM
  • マスキング後の処理 → クラウドAPI
  • 公開情報の処理 → クラウドAPI

このように振り分けると、投資額を抑えながら、必要な部分ではクラウドの高性能モデルを使えます。「オンプレか、クラウドか」ではなく「どのデータをどちらで処理するか」という設計問題として捉え直すと、選択肢が広がります。

まとめ

  • オンプレLLMの難所は、モデルではなくハードウェア選定・ソフトウェア供給経路・用途の切り方
  • GPU構成は、モデルサイズだけでなくKVキャッシュと同時利用者数から逆算する
  • 閉域では更新し続ける経路の設計が必須。ここが抜けた見積は後で膨らむ
  • 用途を狭く切れば、オープンウェイトモデルで十分実用になる領域は広い
  • 「オンプレか、クラウドか」ではなく「どのデータをどちらで処理するか」

当社は、オンプレミスKubernetesクラスタの構築、GPUサーバ選定、閉域ネットワーク設計、LTOテープストレージの運用設計まで、物理層から手掛けてきました。構成の妥当性検証だけのご依頼にも対応しています。