オンプレAI構築の現実

「機密が多いからオンプレでAIを」と決めてからが勝負です。GPUを買えば終わりではなく、電力・冷却・運用の稼働率が意思決定の成否を分けます。SaaSのChatGPTやClaude、Gemini、画像ならStable Diffusionのクラウド実行が十分強力な一方、オンプレは“常に同じ負荷が続く”前提と“データを出せない”制約が重なる時にだけ優位が出ます。

クラウドに残すか、オンプレに下ろすかの分岐点

オンプレの主因はデータ主権・レイテンシ・コスト安定性の3つです。規制や取引先契約で外部送信が不可、工場や倉庫でのサブ50ms制御、あるいはピーク偏差が小さい業務が対象になります。逆に、利用が季節や部署で大きく揺れる場合はクラウド従量が有利です。

損益ラインの雑算

月次トークン=同時接続数×1回の応答トークン×1人あたりの実行回数×営業日で概算します。例：同時30人×600トークン×150回×20日=54Mトークン/月。SaaS単価を掛ければ月額目安が出ます。一方オンプレはTCO=減価償却(GPU/サーバ/ラック)＋電力・保守＋運用人件費。経験則ではGPU稼働率が40〜60%を超え、負荷が年中一定ならオンプレが拮抗し始めます。利用の平準化(バッチ化、キューイング)ができるかが鍵です。

データを出さない以外の価値

プロンプト・ログの粒度制御、ドメイン特化の前処理、社内SLOの定義はオンプレの強みです。逆に、最新モデルへの乗り換え速度や多言語・音声など周辺機能はSaaSが先行します。両者をハイブリッドにする覚悟が現実解です。

現実的なアーキテクチャとサイズ感

推論専用ノード1〜3台から始め、用途に応じて水平展開します。7B〜13B級モデルはINT4量子化でVRAM 8〜20GB程度、単一GPU(24〜48GB)で実用に乗ります。70B級は80GB級GPUを複数枚で張り、並列化の複雑度が一気に上がります。

推論ノード

• サーバ: 2U/4U、GPU 2〜4枚、NVMe 8TB以上。電源は200V推奨、1台あたり1.5〜3kW。
• ソフト: vLLMやTensorRT-LLM、TGIのいずれか。トークン毎秒と同時実行のチューニング(バッチング、KVキャッシュ)が肝です。
• メトリクス: p50/p95レイテンシ、トークン生成速度、GPUメモリ/SM使用率、失敗率をPrometheusで収集し、SLO違反時に自動スケール。

RAGとデータ周り

• ベクトル: pgvectorやMilvusで十分。更新頻度が高いなら索引の非同期再構築キューを用意。
• 埋め込み: 小型モデルをCPU/GPUで分離実行。文書はチャンク化(500〜1000トークン)しメタデータで権限をフィルタ。
• ガバナンス: PIIマスキング、テナント/部署単位のログ分離、保存期間の明示。監査対応のためプロンプトと回答を署名付きで保存。

接続と認証

APIゲートウェイでレート制限とスロットリング。SSO連携、Slack/Teamsボット、社内ポータルUI。高難易度問い合わせはクラウド(例: Claude)へフェイルオーバーし、プロンプトから機密を自動除去するルールを定義します。

調達と運用の落とし穴

ハードは買って終わりではない

• 納期: GPUは12〜20週待ちも。先に電源・ラック・ネットワーク(100GbE)を整備。
• 冷却: ラックあたり10kW超なら熱密度の試算必須。吸排気の混在防止とホットアイル管理。
• 冗長化: PSU/NIC/スイッチは二重化。モデルサーバはローリング更新可能なKubernetes(KServe/Ray/Triton)で。
• ソフト更新: 脆弱性対応は月次。モデルもバージョン固定、A/Bテスト、ロールバック手順を標準化。

法務とコストの思い込み

• ライセンス: 商用可否と再配布条件を必ず精査。学習データのクリーンルーム化も検討。
• 人件費: MLOps/プラットフォーム/SRE/セキュリティの4職能が最低ライン。24/365は外部と分担が現実的。
• 電力単価: 電気代の上昇で損益が反転することがあります。再評価の前提を四半期ごとに更新。

身近な企業活用例：中堅食品メーカーの社内QAをオンプレ移行

最初はSaaSのChatGPTを部門限定で使い始めたものの、製造レシピや原料原価が扱えず伸び悩み。オンプレに振り切り、いきなり70B級を導入したところ、応答が重く、電源系の増設で数カ月停止という失敗に。利用ログも粗く、部門ごとの効果が見えませんでした。

再設計では「13B+RAG」に縮小。48GB GPU×2枚のノードを2台、vLLMでINT4運用。文書はSharePointからETLし、pgvectorに格納。プロンプトに部門タグを付与し、Keycloakで権限を強制。監視はPrometheus/Grafana、失敗時は一部問い合わせをClaudeへフェイルオーバー。Slackボットから利用し、回答は出典リンク付きに統一しました。

結果、平均応答は1〜2秒台に短縮、検索精度も「出典なし回答」の比率が大幅に減少。月間コストは当初想定より30%低減し、定常的なレシピ問い合わせや品質基準の参照といった“平準化された業務”に集中させることでGPU稼働率を50%超に安定化できました。画像生成(パッケージ案)はクラウドのStable Diffusion系で継続し、用途ごとに最適配置を使い分けています。

オンプレAIは単発導入ではなく、モデル・RAG・認証・監視・SLOをひとつの基盤として積み上げると成果が出やすいです。生成AIプラットフォーム事業としての視点でいえば、社内の多様なユースケースを同じガバナンスと運用で束ね、必要に応じてSaaSとハイブリッド連携できる設計が、現場にとって一番の“現実解”だと感じます。