- 公開日
オンプレミスLLMが適するのは、情報を自社管理の範囲に置く必要があり、その範囲で必要な品質と運用体制を維持できる場合です。閉じるべきデータ経路を定め、クラウドが要件を満たせるかを確認したうえで、機器・更新・人材・障害対応の負担を同じ期間で比較します。
オンプレミスとは、自社の施設や管理設備にシステムを設置して運用する形です。外部ネットワークから完全に隔離されていることまでは意味しません。構内にあるサーバーでも、監視や保守のために外部へ接続する設計は可能です。反対に、専用の通信経路でクラウドへ接続しても、事業者の設備で処理する事実は変わりません。自社設備への配置と、通信経路の制限を分けて判断します。
最初に「外へ出せない情報」を定める
まず、対象データ、利用目的、利用者、許可される処理場所を一組にして整理します。「機密だからオンプレミス」とだけ決めると、顧客契約で禁止されている処理と、社内判断で制限している処理が混ざります。契約の該当箇所、情報管理規程、責任者の承認を確認し、要件の根拠を残してください。
ここでは架空の製造会社が、機密の不具合報告を要約する場面を考えます。入力は「装置甲の停止原因は調査中。交換部品は候補段階。次回会議で対応を決める」という報告と、その根拠ページです。品質担当者が「判明事項、未確定事項、次の確認」を作成し、原文と照合してから社内会議で使います。外部送信や設備の自動操作は含めません。
比較する条件は二通りです。一つは、顧客との架空の合意により、原文と要約を自社管理の閉域設備内で扱う条件です。この条件では、クラウド事業者への送信を伴う案は、契約の変更が認められない限り候補から外れます。もう一つは、指定した事業者での処理を顧客が認め、保存・アクセス・再利用の条件も照合できる場合です。この場合はクラウドと自社運用を比較できます。
同じ入力、利用者、出力項目、確認責任を固定し、変えるのは認められるデータ経路です。後者への変更には実際の権限者の判断が必要で、利用部門が費用だけを理由に条件を書き換えるものではありません。この例は法令による一律の国内処理義務を示したものでもありません。
閉域性は要約処理の前後まで追う
閉域の要件を確かめるときは、文書をモデルに渡す部分だけでなく、取得から廃棄までを追います。スキャン文書を文字へ変えるOCR、関連資料を探す検索索引、入力を記録するログ、監視サービス、バックアップ、保守担当者への障害情報にも、本文や機密情報が含まれ得るためです。
架空の会社なら、情報管理担当者と運用担当者が次の三点を照合します。
- 契約：対象情報と利用目的について、委託先・再委託先、保存期間、サポート時の閲覧、利用終了時の返却・削除を確認できるか
- 設定：接続先、認証、アクセス範囲、ログ内容、保存先が、承認した構成と一致しているか
- 実際の経路：文書取得、要約、監視、障害調査、復旧で、承認外の送信先へ情報が流れないか
たとえば監視サービスの送信内容が分からなければ、その経路の適合は未確認です。図に外部接続が描かれていないことを理由に合格にはしません。設定と通信記録、保守手順を調べ、機密情報を含む送信を止めるか、承認された範囲へ構成を変えます。確認が済むまでは、機密文書を投入する対象から外します。
クラウドについても「学習に使われない」という説明だけでは、保存や保守時の条件までは判定できません。たとえばMicrosoftのModels sold by Azureのデータ保護説明は、保存と処理を分け、配置方式や状態を保持する機能による違いを示しています。これは対象サービスの説明であり、別のサービス、契約、機能へ同じ条件を移せません。
自社で持つ責任を担当者の仕事へ置き換える
Microsoftの共有責任モデルでは、オンプレミスとクラウドの各サービス形態で、顧客と提供者の責任範囲が異なります。クラウドへ移しても、データ、エンドポイント、アカウント、アクセス管理の責任はどの形態でも顧客に残るとしています。以下はこの考え方を要約業務の比較へ落とした整理で、全ベンダーに共通する契約条項ではありません。Open Weightモデルを自己ホストする場合とAPIを使う場合の責任分担は「Open Weightの自己ホストとAPI利用で責任分担を比べる」で扱っています。
自社運用では、サーバーや電源の故障対応、OSや推論ソフトウェアの更新、監視、バックアップ、復旧を誰が担当するかを決めます。保守会社へ委託するなら、担当範囲、連絡時間、現地作業までの時間、機密情報を見せる条件を確認します。委託後も、契約どおりに保守され、業務が復旧したかを確認する自社の担当を残します。
モデルの更新も作業になります。新しい版を取得して動かすだけでは、元と同じ要約品質を保てるかは分かりません。報告書の否定表現、未確定事項、ページ参照が保たれるかを、業務担当者が決めた例で確かめます。運用担当だけに意味の正しさまで背負わせず、基盤を直す人と業務合格を判断する人を分けます。
NIST SP 800-40 Rev.4は、更新物の真正性・完全性や適用後の確認を含むパッチ管理を扱います。閉域でも更新作業はなくなりません。モデルと関連ソフトウェアを搬入する経路、確認担当、更新できない間の暫定対策を運用計画へ含めるのは、この業務で採る設計です。NISTの一般ガイドを、日本企業への一律の法的義務とは扱いません。閉域環境へ更新を搬入する手順と署名・版の確認は「Air-Gapped環境でモデル・脆弱性情報をどう更新するか」で詳しく扱っています。
担当者が一人しかいなければ、不在時に障害対応や更新が止まる条件も見積もります。代替担当への引き継ぎ、手順の演習、連絡先の維持まで予算に入れると、設備だけを比較した場合との違いが見えてきます。
費用は同じ三年間と同じ業務量でそろえる
次の金額は説明用の仮定であり、市場価格、見積書、実測した費用ではありません。比較期間を三年間、利用量を月一万件、合計三十六万件の要約とします。入力文書の長さ、ピーク時の件数、保存期間、応答まで待てる時間、復旧の目標も同じと仮定します。
| 三年間の費用項目 | 自社運用案 | クラウド案 |
|---|---|---|
| 機器・初期構築 | 400万円 | 70万円 |
| 電力・設置・保守、またはAPI・接続の利用費 | 180万円 | 360万円 |
| 更新・監視・利用管理の担当工数 | 450万円 | 240万円 |
| 品質再評価・復旧演習 | 120万円 | 100万円 |
| 合計 | 1,150万円 | 770万円 |
合計は各列の四項目を加算しています。この仮定なら自社運用案が380万円多くなりますが、これはオンプレミスの相場や一般的な優劣ではありません。担当工数は社内人件費を含む費用として置き、外注保守と二重に計上しない前提です。税と資金調達費用は双方とも含めず、機器の三年後の売却価値はゼロと仮定しています。
原文と要約の人による確認は両案に同じ仕事として残り、この表の比較対象から除いています。モデルによって修正件数が異なるなら、その差は追加の費用です。また、障害による損失額は未見積もりです。両案とも同じ復旧目標を満たせる根拠が得られなければ、表の金額だけで採用しません。
自社運用の費用を下げるために小さいモデルや量子化を選ぶ場合も、品質条件を変えずに再評価します。量子化は数値表現の精度を下げる手法で、Transformers v5.19.0の概念説明は、容量・計算と精度のトレードオフを扱っています。機器容量を減らせる見込みを、そのまま要約の正確さや総費用の改善に置き換えないでください。
利用量が半分になった場合、APIなどの従量部分と購入済み機器の費用は同じようには変わりません。一方、ピーク負荷が増えると追加設備や契約変更が必要になる可能性があります。月間平均だけでなく、繁忙時間の待ち行列や増強の単位を確認し、現状・減少・増加の条件で見積もりを作り直します。
採用を決めるときに残す判断
機密文書の例では、期待する出力は「停止原因は調査中」「部品交換は未決定」「次回会議で対応を確認」と、原文の確定度を保った要約です。閉域の条件を満たしても「部品交換が決定した」と出せば、業務品質は不合格です。原文、出力、参照ページを照合し、モデルや設定を変えても直らなければ、その用途での利用を見送ります。この例の比較・品質試験は未実施です。
判断記録には、データ経路への適合、品質、三年間の費用、更新と障害対応の担当、未確認事項を並べます。閉域必須でクラウド案が合わず、自社運用案は品質と担当体制を満たすなら、費用差を引き受ける案として説明できます。反対に、自社運用の担当が確保できないなら、承認された外部保守、扱う資料の縮小、従来の手作業などを検討し、閉域という条件だけで導入を急ぎません。
採用後は、要件、モデル、保守契約、利用量が変わった時点で判断記録を更新します。閉域性を維持できる構成と、その構成を支える担当・予算を一緒に見直してください。
ローカルLLMのモデルファイルを照合する方法は「ローカルLLMのモデルファイルをハッシュで照合し、提供元を別に確かめる」、国内リージョン固定が必要な業務でのモデルとデータ経路の選び方は「国内リージョン固定が必要な業務で、モデルとデータ経路を選ぶ」で解説しています。
出典・参考資料
- Microsoft「Shared responsibility in the cloud」（確認日：2026年10月27日）
- Microsoft「Data, privacy, and security for Models sold by Azure in Microsoft Foundry」（確認日：2026年10月27日）
- NIST「Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology, NIST SP 800-40 Rev.4」（確認日：2026年10月25日）
- Hugging Face「Quantization concepts」（確認日：2026年10月19日）
