社内データをLLM（大規模言語モデル）に読み込ませたいが、プロンプトが外部に漏れる経路を作りたくない。そんな要件を抱えるアーキテクトやセキュリティ担当者に向けて、プライベートLLMの選択肢を整理します。
「プライベート」という言葉は曖昧に使われがちです。自社サーバーに置くことなのか、クラウドでも契約上守られていれば十分なのか、定義を詰めないまま調達を進めると後戻りが発生します。本記事では構成の選び方を、物理的な隔離・契約上の保証・技術的な隔離という3段階に分けて整理し、判断基準を示します。
プライベートLLMが問題になる場面
典型的には、医療・金融・法務など機密情報を扱う業務でLLMを使いたいが、コンプライアンス部門やセキュリティ部門が「プロンプトの行き先」を明確に説明できないと承認を出さない、という場面です。
もう一つは、社内の複数チームでAIエージェント（自律的にタスクを遂行するAIの仕組み）を共有する場合です。誰のプロンプトがどこに保存され、誰が読めるのかという権限管理の問題も絡んできます。
判断軸1: 誰がプロンプトを読めるか（信頼の形）
プライバシーの保証には3つの異なる種類があります。
物理的プライバシーは、プロンプトが自社が管理するマシンの外に出ないことを指します。GPU（画像処理用演算装置、LLM推論にも使われる）を自社で購入し、ネットワーク的に隔離されたサーバーで動かす構成がこれにあたります。
契約上のプライバシーは、プロンプトが外部のクラウドに送られるものの、提供者が「学習に使わない」「一定期間後に削除する」と契約書で約束している状態です。AWS Bedrock・Azure OpenAI Service・Google Cloud Vertex AIの企業向けプランが該当します。
技術的プライバシーは、プロンプトが外部ハードウェアで処理されるものの、その処理環境自体を運営者が覗き見できない構造になっている状態です。TEE（Trusted Execution Environment、CPUやGPU内部に設けられた隔離実行領域）を使った機密推論（Confidential Inference）がこれにあたります。重要なのは、この3つのどれであっても検証可能かどうかという点です。「約束」なのか「仕組み上不可能」なのかを、調達時に区別して確認する必要があります。
判断軸2: 同時実行性能とコストの関係
自前ハードウェアを検討する際、よく見落とされるのが並行処理の限界です。
公開されているハードウェア比較によると、RTX 5090（MSRP 1,999ドル、VRAM 32GB）で70BパラメータモデルがおよそTPS（1秒あたりの生成トークン数）25〜30を出せます。128GBのMac Studio（3,500〜4,000ドル）でも同程度の速度です。
これは1人が使う分には十分な性能ですが、1枚のカードが出せるのは1本の会話分のスループットです。エージェントが10並列でAPIを呼び出すような構成だと、同じカードの上で処理待ちのキューが積み上がります。チームでLLMを共有する設計を考えているなら、GPU台数とスループット要件を先に見積もる必要があります。
判断軸3: モデルの陳腐化と技術的負債
ハードウェアを購入する判断は、実質的に4年以上の運用コミットメントになります。
オープンウェイトモデル（重みファイルが公開され自由にダウンロードできるモデル）は急速に進化していますが、最前線のクローズドモデルに匹敵する性能にはまだ届かない領域もあります。1年後に「最新モデルが自社のVRAM容量に収まらない」事態になれば、追加投資か妥協かの二択を迫られます。
これはクラウドのEOL（End of Life、サポート終了）管理とは異なる種類の負債です。クラウド側はモデルのアップグレードを提供者側が吸収しますが、自前ハードウェアは物理的な上限をチームが背負い続けます。アーキテクチャ選定の場では、この「将来のモデル追従コスト」を初期費用の比較表に含めずに議論してしまうケースが見受けられます。
判断軸4: 運用負荷と可用性のオーナーシップ
自前運用は、ドライバー更新・推論サーバーの保守・土曜日に落ちたボックスの復旧まで、すべて自チームの責任になります。
クラウド契約であれば、可用性SLA（Service Level Agreement、サービス品質保証）と運用負荷の両方を提供者に移管できます。ただし移管できるのは運用負荷であって、プロンプトの扱いに関する信頼は契約文書の精読が前提です。
例えばAWS Bedrockのデータ保持ドキュメントでは、ゼロデータ保持モードにおいて「AWSまたはモデル提供者によってリクエスト・レスポンスデータが永続化されない」と明記される一方、一部の最新フロンティアモデルには「AWS境界内で最大30日間保持されレビューされ得る」レビューモードが適用されると書かれています。どのモードが適用されるかはモデル選択に依存するため、契約前にモデルごとのモードを確認する作業が必須です。
3つの選択肢を比較する
| 観点 | 自前ハードウェア | クラウド契約 | 機密推論(TEE) |
|---|---|---|---|
| プライバシーの種類 | 物理的 | 契約上 | 技術的 |
| 初期費用 | 高い(数千ドル規模) | 低い(従量課金) | 中程度 |
| 並行処理性能 | GPU台数に直結 | プロバイダ側でスケール | プロバイダ側でスケール |
| モデルの陳腐化リスク | 高い(4年単位の縛り) | 低い(随時更新) | 低い(随時更新) |
ケース別の推奨
- 単独または少人数での利用で、プロンプトが物理的に建物の外に出てはいけない規制下にあるなら、自前ハードウェアを選びます。RTX 5090クラスのGPU1枚でも70Bモデルを現実的な速度で動かせます。
- 複数チームでエージェントを共有し、最前線モデルの性能を使いたいが監査要件があるなら、クラウド契約のゼロデータ保持モードを選びます。AWS・Azure・GCPいずれも設定または申請によって有効化する仕組みのため、デフォルト設定のままにしないことが条件です。
- 契約上の約束ではなく技術的な検証可能性が監査部門から求められるなら、TEEベースの機密推論を検討します。運営者自身が覗けない実行環境であることを第三者が検証できる点が、契約ベースの保証と決定的に異なります。
あえて見送るべき条件
- チームの誰もGPUサーバーの運用経験がない状態で自前ハードウェアに踏み切るのは避けます。土曜日の障害対応要員を確保できないなら、運用負荷をクラウド側に移管した方が可用性は安定します。
- 「プライバシー」という言葉だけでクラウド企業向けプランを選び、ゼロデータ保持モードの設定を確認しないまま本番投入するのは避けます。デフォルトでは一部モデルにレビューモードが適用される場合があるため、
ContentLoggingのような設定項目の値を必ず確認します。 - 1年以内に用途やモデル要件が大きく変わる見込みがあるのに、4年償却前提のハードウェア投資を決定するのは避けます。要件が流動的なフェーズでは、従量課金のクラウド契約の方が技術的負債を抱えにくい構成です。
まとめ
プライベートLLMの選定は、コストの比較表だけでは終わりません。
誰がプロンプトを読めるか、同時実行性能はチームの規模に見合うか、モデルの陳腐化リスクをどちらが背負うか、この3点を自社の要件に当てはめて整理することが出発点になります。
次の一歩として、クラウド契約を検討しているなら、利用予定モデルのデータ保持ドキュメントを開き、ゼロデータ保持モードの適用条件を確認してみてください。自前ハードウェアを検討しているなら、想定する同時接続数とGPUのTPS値を掛け合わせて、実際のスループット要件を満たせるか試算することから始められます。