プライベートGPT（機密データ対応LLM）の設計パターン4選
「社外秘データをAIに渡してはいけない」という社内ルールを、根拠を確かめないまま運用していませんか。
この禁止の背景には3つの異なる問題が混在しています。(a) データがモデルの学習に使われるか、(b) データが外部サーバーを物理的に経由するか、(c) ログとしてどれだけの期間保持されるか——この3軸を分けて考えると、「渡してはいけない」の正確な意味は変わります。
結論: 商用APIでモデルの学習に使われることは契約上ありません。問題は “経路” と “ログ保持期間” です。そこを設計で制御する4つのパターンがあります。
以下では、クラウドAPI直接利用・VPC閉域型・完全セルフホスト・ハイブリッドルーティングの4パターンを、各社の公式ポリシーと公式ドキュメントをもとに比較します。
「データが学習される」「データが外に出る」を分けて考える
LLMにデータを送信するときのリスクは、すべて同じではありません。3つの軸に分解すると判断の整理が進みます。
軸1: モデルの学習に使われるか
「渡してはいけない」の根拠として最も多く挙げられる懸念です。ただし主要な商用APIプロバイダーは現在、契約上の保証を明文化しています（Pattern 1で詳述）。
軸2: データが物理的に外部サーバーを経由するか
APIを呼び出す以上、プロンプトはネットワークを通じてプロバイダーのインフラへ送信されます。「学習に使われない」という保証と、「物理的に社外に出ない」はまったく別の話です。HIPAA・金融・官公庁など規制が厳しい業種では、この軸が設計の起点になります。
軸3: ログとしてどれだけの期間保持されるか
不正利用（アビューズ）監視のため、多くのAPIはリクエストをログとして一定期間保持します。「学習には使わない」と「ログには残る」は共存する状態です。情報漏洩インシデントが発生した場合、ログ保持期間がリスクの範囲を決めます。
この3軸に対して、設計の選択肢は4つあります。
Pattern 1 — クラウドAPI直接利用（OpenAI API / Anthropic API）
最も導入ハードルが低い構成です。既存のコードベースにAPIキーを追加するだけで動作します。ただし、その実態をポリシー原文で確認しておく必要があります。
「学習に使われない」の根拠——公式ポリシーの原文
Anthropic Commercial Terms には次の記述があります。
“Anthropic may not train models on Customer Content from Services.”
対象はClaude for Work、Anthropic API、Amazon Bedrock経由のClaude等の商用製品です。Anthropic Privacy Center（2026年3月16日時点） では次のように補足されています。
“By default, we will not use your inputs or outputs from our commercial products (e.g. Claude for Work, Anthropic API, Claude Gov, etc.) to train our models.”
OpenAI - How we use your data も同様の方針を明記しています。
“As of March 1, 2023, data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us).”
どちらも「契約上の保証」です。物理的にはデータが外部サーバーを経由するという事実は変わりません。
ポリシーが保証しないこと——アビューズ監視ログとZDR
学習には使われなくても、ログに残ることは別問題です。
OpenAI APIは、不正利用監視のためにリクエストを一定期間ログ保持します（保持期間の詳細は OpenAI - How we use your data で確認してください）。この保持期間をゼロにするオプションがZDR（Zero Data Retention: OpenAIがアビューズ監視ログからもCustomer Contentを排除するオプション。事前申請・承認制）です。ZDRはOpenAIへの事前申請と承認が必要で、すべての利用者が自動で取得できるわけではありません。審査基準は非公開のため、取得可否についてはOpenAI - How we use your data を直接確認してください。
医療・金融・法務データを扱う場合は、このログ保持期間について法務部門との確認が必要です。
向く組織: スタートアップ〜中規模、処理量がそれほど大きくない、コンプライアンス要件が比較的緩やかな業種。
Pattern 2 — クラウド閉域型（Amazon Bedrock + PrivateLink / Google Vertex AI + PSC）
「データがパブリックインターネットを経由することは避けたい。ただし社内にGPUサーバーを置くのも難しい」という要件に対応する構成です。クラウドのマネージドモデルを使いながら、ネットワーク経路を完全にプライベート化できます。
プロンプトがパブリックインターネットを経由しない仕組み
AWS PrivateLink（VPCとAWSサービス間をパブリックインターネットを経由せず接続するサービス）を使うことで、VPC内のリソースからAmazon Bedrockへのリクエストをインターネットに出さずに送信できます。Amazon Bedrock公式ドキュメント には次の記述があります。
“You can use AWS PrivateLink to create a private connection between your VPC and Amazon Bedrock. You can access Amazon Bedrock as if it were in your VPC, without the use of an internet gateway, NAT device, VPN connection, or Direct Connect connection. Instances in your VPC don’t need public IP addresses to access Amazon Bedrock.”
AWS Machine Learning Blog でも次のように補足されています。
“The Amazon Bedrock service API endpoint receives the API request over PrivateLink without traversing the public internet.”
構成の基本形は「Lambda → VPCエンドポイント（com.amazonaws.{region}.bedrock-runtime）→ Bedrock」です。FIPSコンプライアンスが必要なリージョンでは、専用のFIPSエンドポイントが用意されています。
Google Cloud側では、PSC（Private Service Connect: VPCを出ることなくGoogleマネージドサービスにアクセスするGCPの機能）が対応します。Google Cloud PSC公式ドキュメント には次の記述があります。
“With Private Service Connect, consumers can use their own internal IP addresses to access services without leaving their VPC networks. Traffic remains entirely within Google Cloud.”
Google Cloud セキュアAIエンタープライズガイド では、Vertex AIのリソースをプライベートVPCサブネットにデプロイする方法としてPSCを推奨しています。
コンプライアンス対応の強度と追加コスト
Amazon Bedrock Security & Compliance では次の点が明記されています。
“When you tune a foundation model, we base it on a private copy of that model. This means your data is not shared with model providers, and is not used to improve the base models.”
BedrockはISO/SOC/HIPAA/GDPR/FedRAMP Highのコンプライアンス認定を取得しており、規制業種での採用実績があります。
費用面では、VPCエンドポイントはモデル推論のAPI料金とは別に、インターフェース型の時間課金とデータ処理料が発生します。コスト試算には必ずこれらを含めてください。詳細はAmazon Bedrock 料金ページで確認してください（2026年7月時点）。
VPCネットワーク設計とエンドポイント設定の工数も初期に必要です。既存のAWS/GCPインフラへの追加設定のみで完了するケースもありますが、ゼロから設計する場合は設計工数を別途見込んでください。
向く組織: 既存AWS/GCPインフラあり・中〜大規模・医療/金融/官公庁などデータ経路のコントロールが要件になる業種。
Pattern 3 — 完全セルフホスト（Ollama / vLLM + オンプレGPU）
データが物理的に社外に出ることを一切許容しない要件に対応する選択肢です。推論はすべて社内（またはプライベートクラウド）のGPUサーバーで実行します。コンプライアンス上の自由度は最大ですが、初期投資と運用負荷も最大になります。
推論サーバーの選び方——OllamaとvLLMの使い分け
Ollama（ローカルでLLMを動かすためのオープンソースランタイム）は、開発・検証フェーズに適しています。デフォルトでポート11434にOpenAI互換APIを公開するため、既存コードのエンドポイントURLを localhost:11434 に変えるだけで動作確認が始められます。ただし並行リクエスト処理に上限があり、複数ユーザーが同時に使う本番環境では性能が頭打ちになります。
本番環境ではvLLM（PagedAttentionアルゴリズムを使ったオープンソースの高速LLM推論サーバー）の採用を検討してください。Alpacked - Self-Hosted LLM Guide では次のように評価されています。
“The selection logic is straightforward: Ollama for getting started and prototyping… The moment real users appear, vLLM without compromise: its PagedAttention algorithm delivers 19x higher throughput and keeps P99 latency below 100ms at 128 concurrent requests.”
OllamaとvLLMの最大の差は並行リクエスト処理能力です。vLLMのPagedAttentionはGPUのKVキャッシュを細粒度に管理することで、多数のリクエストを同時処理できます。Ollamaは小規模な検証には十分ですが、実際のユーザーが使い始めた段階でvLLMへの移行を検討してください。
VRAMサイジングの目安——モデルサイズ別の必要GPUメモリ
モデルをGPUに収容するために必要なVRAMは、量子化（モデルの精度を落としてサイズを圧縮する手法）の設定によって変わります。
Q4_K_M（メモリ削減と品質のバランスが良い量子化設定）を使う場合、Alpacked - Self-Hosted LLM Guide に基づく目安は以下の通りです。Q4量子化では1Bパラメータあたり約0.5 GBのVRAMが必要です。
| モデルサイズ | 必要VRAM目安（Q4_K_M） | 対応GPU例 |
|---|---|---|
| 7〜8B | 4〜6 GB | RTX 4060以上 |
| 13B | 8〜10 GB | RTX 4070以上 |
| 32〜34B | 16〜20 GB | RTX 4090 / A100 40GB |
| 70B | 35〜40 GB | A100 80GB / H100 |
VRAMが不足するとCPU推論にフォールバックします。CPU推論はGPU推論と比べて大幅に遅くなるため、本番用途では事実上使えません。モデル選定の前にGPUのVRAM容量を確認してください。
損益分岐点——日次何tokenから採算が合うか
Alpacked - Self-Hosted LLM Guide によると、GPUサーバーへの投資が採算に乗り始めるのは日次200万token超からです。日次1,000万token以上になると、6〜12ヶ月での投資回収が見込めます。
同ガイドでは、以下のコスト削減実績が示されています。
- フィンテック企業: 月次LLM費用 $47,000 → $8,000（83%削減）
- テレヘルス企業: 月次LLM費用 $48,000 → $32,000（33%削減）
処理量が少ない段階では、GPU購入費用と運用人件費が比較対象のAPI費用を上回るため採算が合いません。社内Q&A・文書解析・コーディング支援など複数のアプリケーションで同一のGPUサーバーを共用することで固定費を分散できます。
向く組織: 日次処理量が大きい・規制業種（HIPAA/金融/官公庁）・MLOpsエンジニアが社内にいるか採用する意思がある組織。
Pattern 4 — ハイブリッドルーティング（機密度で自動分岐）
機密データはローカル推論、非機密データはクラウドAPIへルーティングする構成です。コンプライアンスとコストを同時にコントロールできる点で、中〜大規模組織での採用が増えています。
3段階ルーティングの設計原則
ルーティングの判定軸は3つです。
軸1（機密度）: PIIや規制対象データ、内部文書を含むリクエストはローカル推論へ転送します。SitePoint - Hybrid Cloud-Local LLM Architecture Guide (2026) には次の記述があります。
“If data cannot leave the organization’s infrastructure, the request never touches a cloud endpoint.”
軸2（複雑度）: 単純な分類や短い要約はローカルモデルで十分です。長文生成や高度な推論が必要なタスクはフロンティアモデル（クラウド側）へ転送します。タスク種別ごとにルールを定義し、ローカルモデルの限界を把握したうえで振り分け条件を決めます。
軸3（可用性）: ローカルGPUが高負荷や障害で応答できない場合のフォールバックチェーンを事前定義します。ただし機密データのフォールバック先については、次のセクションで説明する重要な原則があります。
fail-closedの原則——機密リクエストはクラウドにフォールバックしない
ハイブリッド設計で見落とされやすいのが、機密リクエストのフォールバック設定です。
SitePoint - Hybrid Cloud-Local LLM Architecture Guide (2026) では次の原則が明記されています。
“Critically, sensitive requests must fail closed: if the local model is unavailable, the request must return a controlled error, never fall back to a cloud provider.”
fail-closed（フェイルクローズド）とは、ローカルモデルが応答できない場合にクラウドへ迂回するのではなく、エラーを返すという設計です。「ローカルが落ちたらクラウドに流す」という設定は、機密データをクラウドAPIへ送信するルートを誤って開くことになります。機密リクエストに対しては必ずfail-closedを選択してください。
実装スタック例とコスト削減実績
一般的な実装例として、LiteLLM（複数のLLMプロバイダーを統一インターフェースで扱えるオープンソースのプロキシライブラリ）をゲートウェイに置く構成があります。
クライアント → LiteLLM ゲートウェイ
├─ 機密リクエスト → Ollama / vLLM（ローカル）[fail-closed]
└─ 非機密リクエスト → Anthropic Claude API / OpenAI APIPII（個人識別情報）の検出はサーバーサイドで実装します。正規表現ベースの検出か、構造化タグによるマーキングが一般的です。オーケストレーションにはLangChainのRunnableBranchなどが使えます。
コスト削減の効果はPattern 3で示した通りです（フィンテック企業83%削減・テレヘルス企業33%削減。出典: Alpacked - Self-Hosted LLM Guide）。機密度にばらつきがある組織では、すべてをセルフホストするよりも運用コストを下げながらコンプライアンスを確保できます。
向く組織: 機密度にばらつきがある中〜大規模、既存のクラウドLLMを使っていてコンプライアンスとコストの両立に課題がある組織。
4パターンの比較と選定フロー
4つのパターンを主要な判断軸で比較します。
| Pattern 1（API直接） | Pattern 2（VPC閉域） | Pattern 3（セルフホスト） | Pattern 4（ハイブリッド） | |
|---|---|---|---|---|
| データ経路 | パブリックインターネット経由 | VPC内・インターネット非経由 | 社内のみ | 機密: 社内 / 非機密: クラウド |
| モデル学習利用 | 契約上なし | 契約上なし | なし（自社管理） | なし（自社管理 + 契約上なし） |
| ログ保持 | プロバイダー依存（ZDR取得で回避可） | プロバイダー依存（AWS/GCPポリシー準拠） | 自社管理 | 機密: 自社管理 / 非機密: プロバイダー依存 |
| 初期費用 | 低 | 中（エンドポイント設定工数） | 高（GPU購入・環境構築） | 高（ローカル環境 + ルーティング実装） |
| 月次費用 | 従量課金（Bedrock料金等参照） | 従量課金 + VPCエンドポイント費用 | GPU電力・保守の固定費 | 混合（ローカル固定費 + クラウド従量） |
| 運用負荷 | 低 | 中 | 高 | 高 |
| 規制対応強度 | 基本（ZDR取得で強化） | 高（ISO/SOC/HIPAA/GDPR/FedRAMP対応） | 最高（完全自社管理） | 高（機密部分のみ最高） |
| 向く組織規模 | 小〜中 | 中〜大 | 大・規制業種 | 中〜大 |
選定フロー
データが物理的に社外に出ること自体がNG → Pattern 3（完全セルフホスト）、またはPattern 4の機密リクエストのみローカル化
↓ 社内にGPUを置けない / パブリックインターネット経由はNG
→ Pattern 2（Amazon Bedrock + PrivateLink、またはVertex AI + PSC）
↓ コンプライアンス要件が比較的緩やか / 社内GPU不要
→ Pattern 1（クラウドAPI直接）。ZDRが取得できるかOpenAIに確認する
↓ 機密度にばらつきがある / クラウドLLMのコストも下げたい
→ Pattern 4（ハイブリッドルーティング）。fail-closedの設計を最初に固める
設計前に確認しておくべき注意点
各パターンには、設計後に気づくと手戻りが大きくなる落とし穴があります。
Pattern 1（クラウドAPI直接）
OpenAI APIはZDR未取得の場合、アビューズ監視のログがデフォルトで一定期間残ります（保持期間は OpenAI - How we use your data を参照）。医療・金融・法務データを扱う場合は、ZDRの取得可否を法務部門と事前に確認してください。ZDRは申請・承認制のため、取得できるかどうかが先にわかっていないと、コンプライアンス審査の段階で構成変更を迫られるケースがあります。
Pattern 2（VPC閉域型）
VPCエンドポイントはAPI費用とは別に、インターフェース型の時間課金とデータ処理料が発生します。初期のコスト試算にこの費用を含めておかないと、運用後に予算超過が起きます。ゼロからVPCネットワークを設計する場合は、設定工数を別途見込んでください。
Pattern 3（完全セルフホスト）——Ollamaのデフォルトバインド
Ollamaはデフォルトで全インターフェース（0.0.0.0）にバインドします。本番環境では必ずプライベートサブネットに配置し、内部APIゲートウェイまたはVPN経由でのみアクセスを許可してください。デフォルトのままインターネットに公開されたOllamaエンドポイントが外部から利用される事故が実際に起きています。
Pattern 3（完全セルフホスト）——RAGのベクトルDB権限管理
RAG（Retrieval-Augmented Generation: 外部ドキュメントを検索してLLMの回答に組み込む手法）のベクトルDBで単一の共有インデックスを使う構成は、ドキュメントレベルの権限管理なしに機密文書が横断的に参照されるリスクがあります。部門間で検索対象を分離するか、行レベルのアクセス制御を実装してください。
Pattern 4（ハイブリッド）——PII分類ミス
機密度の分類ロジックが機密データを「非機密」と誤判定した場合、クラウドAPIへ意図せず送信されます。正規表現ベースのPII検出は、フォーマットが想定外のデータや多言語テキストで精度が落ちる場合があります。分類ロジックのテストケースに「意図的に検出を迷わせるサンプル」を含めておくことを推奨します。
全パターン共通——MLOps人材の要件
Pattern 3とPattern 4を本番で運用するには、推論サーバーの設定・GPUドライバ管理・モデル更新・監視・障害対応を担うMLOpsエンジニアが必要です。初期構築には専任で1〜2名が必要な規模感です。既存のインフラエンジニアが兼務するケースもありますが、GPU運用特有の知識は別途習得が必要になります。
要件が整理できたとしても、どのパターンが実際に合うかは組織の制約（規制・予算・人材・既存インフラ）と処理量次第で変わります。設計の整理からご相談いただけます。