LLM業務利用のデータ主権：
学習利用・保存リージョン・ローカル化・マスキングの4類型
「データを外に出したくない」という懸念は、実は4つの異なる課題を意味しています。懸念を類型化して正確に把握することが、コスト・精度・運用負荷の最適な技術選択への第一歩です。
Definition
エンタープライズLLMのデータ主権（Data Sovereignty）とは、業務データがLLMベンダーによる学習利用・国外リージョンへの転送・ネットワーク外への送信から保護されることを指し、「完全に制御されている」状態を意味します。この保護水準は4つの類型に分解でき、類型ごとに適切な技術的対策が異なります。
課題の実態
30%
homulaへの相談のうち、「データをクローズドで使いたい」が主要な懸念として挙がった割合。しかし、詳細をヒアリングすると、同じ発話が4つの異なる懸念を意味していることが多い。
よくある誤解
「クラウドLLMを使えばデータが学習に使われる」という誤解が広まっています。実際には、OpenAI / Anthropic / Googleのエンタープライズ契約・APIでは、デフォルトでプロンプトデータは学習利用されません。この前提を正確に把握することで、不要なオンプレ投資を避けられます。
「データを外に出したくない」は4つの異なる懸念を意味する
「自社データでモデルが学習されたくない」
→ ポリシーを確認すれば多くのエンタープライズ契約で学習利用は行われない
「データが海外サーバーに保存されると困る」
→ 日本リージョン指定エンドポイントを強制すれば国内に限定できる
「ネット経由でどこにも送信したくない」
→ オンプレLLM または VPC閉域網構成が技術的選択肢になる
「PII・機密情報をLLMに渡したくない」
→ プロンプトレイヤー or 前処理でのPIIマスキング実装で対処できる
類型 01 — 学習利用
「自社データでモデルが学習されたくない」
エンタープライズ向けの有償プランおよびAPIでは、主要3社ともプロンプトデータをモデル学習に使用しないことを契約で保証しています。無料版との混同が誤解の主な原因です。
重要な前提
以下の比較はエンタープライズ契約・APIの条件です。無料版（ChatGPT無料プラン / Google AI Studio）は異なるポリシーが適用されます。業務利用には必ず有償プラン・APIを使用してください。
主要LLMベンダー：学習利用ポリシー比較（エンタープライズ契約 / API）
| ベンダー / サービス | 学習利用 | データ保持期間 | 主要認証 |
|---|---|---|---|
OpenAI ChatGPT Enterprise / API | × 学習利用なし エンタープライズ契約・API利用では学習に使用しないことを利用規約で明記 | 30日（API）/ 設定変更可 API利用でデフォルトOpt-out | SOC 2 Type II / ISO 27001 |
Anthropic Claude API / Claude for Enterprise | × 学習利用なし APIを通じて送受信されたデータはモデル学習に使用されない。Enterprise契約では保持期間ゼロのオプションあり | 設定可能（最短即時破棄） デフォルトOpt-out | SOC 2 Type II / HIPAA対応 |
Vertex AI Gemini API ISMAP認定 | × 学習利用なし Vertex AI APIを通じたプロンプト・レスポンスは基盤モデルの学習・改善に一切使用されない（CDPA契約で法的に規定） | 24時間インメモリキャッシュのみ（ディスク保存なし）。ゼロデータリテンションオプションあり デフォルトOpt-out（CDPAで保証） | ISMAP / ISO 27001 / SOC 2 / FISC / ISO 42001 |
homula's Insight
「学習利用の懸念」については、主要3社とも契約・APIで学習利用しないことをデフォルトで保証しています。この類型の懸念は、適切な契約確認と社内ポリシー整備で解消できます。homulaのブートキャンプでは、初日に契約レビューと社内LLM利用規定のドラフト作成を実施し、情報システム部門・法務との承認を早期に得る支援を行っています。
類型 02 — 保存リージョン
「データが海外サーバーに保存されると困る」
日本リージョンを正しく指定・強制すれば、処理・保存ともに国内に限定できます。ただし、設定ミスによってグローバルエンドポイントを経由するケースが多発しており、技術的な強制設定が重要です。
Microsoft Azure
Azure OpenAI Service日本リージョン
Japan East（東日本）/ Japan West（西日本）
対応モデル（主要）
GPT-4o / GPT-4o mini / o1 / o3-mini
プライベート接続
Private Endpoint（VNet統合）
コンプライアンス認証
ISMAP / FISC / SOC 2 / ISO 27001
実装上の注意点
日本語処理の最適化が進んでいる。Azure Government同等の閉域設定が可能
Google Cloud
Vertex AI日本リージョン
asia-northeast1（東京）/ asia-northeast2（大阪）
対応モデル（主要）
Gemini 2.5 Pro / Gemini 2.5 Flash / Claude 3.7 Sonnet / Llama 4
プライベート接続
VPC Service Controls + Private Service Connect
コンプライアンス認証
ISMAP / FISC（第13版）/ SOC 2 / ISO 42001
実装上の注意点
グローバルエンドポイントではなくリージョン限定エンドポイントの強制が必須。Organization Policyで制御可能
AWS
Amazon Bedrock日本リージョン
ap-northeast-1（東京）/ ap-northeast-3（大阪）
対応モデル（主要）
Claude 3.7 Sonnet / Titan / Llama 3.3 / Mistral
プライベート接続
VPC Endpoint（PrivateLink）
コンプライアンス認証
ISMAP / ISO 27001 / SOC 2
実装上の注意点
Bedrock Guardrailsで出力フィルタリングやPII検知が統合で利用可能
Google Cloud：リージョン限定エンドポイント強制の構成例
AIアプリケーション
Organization Policy
constraints/gcp.resourceLocations
→ asia-northeast1 のみ許可
Vertex AI
asia-northeast1
グローバルEP
BLOCKED
VPC Service Controls
Private Service Connect
データは東京リージョン内に完全閉鎖
類型 03 — 完全ローカル
「ネット経由でどこにも送信したくない」
完全オフライン要件は、特定の規制環境（重要インフラ、防衛関連、特定の金融等）に限定されます。この選択肢を取る前に、本当にオンプレが必要かを精査することが重要です。
判断の前提
「オンプレLLMが必要か」の判断は、実際の業務要件・規制要件に基づくべきです。多くの場合、日本リージョン + VPC閉域網でコンプライアンス要件は充足できます。GPT-4 / Claude 3.7クラスの精度が業務上必要な場合、オンプレLLMは現時点では代替になりません。
完全ローカル vs VPC閉域 vs クラウド：選定基準
| 選定基準 | クラウドLLM （日本リージョン） | VPC閉域網 （クラウド内） | オンプレLLM （完全ローカル） |
|---|---|---|---|
完全オフライン要件 インターネット接続が一切許可されない環境（重要インフラ、防衛関連等） | × | × | ◎ |
国内リージョン限定で十分 多くの金融・製造・医療企業はこちらで要件充足 | ◎ | ◎ | ◎ |
推論精度の最大化 オンプレ小規模モデルはGPT-4 / Claude 3.7クラスの精度に未到達 | ◎ | ◎ | × |
GPU/インフラ運用コスト A100/H100クラスのGPUサーバー維持コストは月数百万円規模 | ◎ | ◎ | × |
モデル更新・管理の柔軟性 オンプレはモデル更新サイクルが遅れがち | ◎ | ◎ | × |
コンプライアンス証明の容易さ ISMAPなど第三者認証済みクラウドの方が監査対応しやすい | ◎ | ◎ | × |
LLaMA / Mistral（オープンソース）
適用シーン：完全オフライン環境、ファインチューニングが必要な特定業務
主要モデル：Meta LLaMA 3.3 70B / Mistral Large 2
インフラ要件：NVIDIA A100 / H100（70Bモデルに最低4枚必要）
注意：GPT-4o / Claude 3.7と比較して、日本語の複雑なタスクで精度差あり
VPC閉域網（推奨）
適用シーン：多くのエンタープライズ（金融・医療・製造）
構成：VPC Service Controls + Private Service Connect + リージョン限定EP
利点：最新GPT-4 / Claude 3.7クラスの精度を維持しながらデータを閉鎖
認証：ISMAP / FISC対応クラウドでコンプライアンス証明が容易
類型 04 — 入力マスキング
「PII・機密情報をLLMに渡したくない」
クラウドLLMに送信するプロンプトから個人情報・機密情報を除去・仮名化するアプローチです。リージョン制約を超えて対処できる唯一の方法であり、2つの実装パターンがあります。
前処理マスキング（推奨）
生データ（PII含む）
PII検出エンジン（Presidio / spaCy）
仮名化済みデータ → LLMへ送信
例: 「田中太郎」→「顧客ID:C00123」
LLM処理後、逆マッピングで再同定
最終出力（再同定済み）
LLMには仮名化済みデータのみが渡る
個人情報保護委員会のガイドラインに沿った設計
逆マッピング表の管理が必要（セキュリティ設計必須）
プロンプトレイヤーマスキング
生データ（PII含む）
システムプロンプトで「PII出力禁止」を指示
生データがそのままLLMに渡る ⚠️
LLMは受け取っているが出力しない設計
出力段階でPIIを除去
PII除去済み出力
LLMのコンテキストにPIIが入る点は残る
プロンプトインジェクションで迂回される可能性
実装は簡易。PoC段階の暫定策として有効
# PIIマスキング実装例（前処理パターン — Python）
from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine
analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()
def mask_pii(text: str) -> tuple[str, dict]:
# PII検出
results = analyzer.analyze(
text=text,
language="ja",
entities=["PERSON", "EMAIL", "PHONE_NUMBER", "JP_MY_NUMBER"]
)
# 仮名化（逆マッピング保存）
anonymized = anonymizer.anonymize(text=text, analyzer_results=results)
return anonymized.text, build_reverse_map(results, text)
# LLMへは仮名化済みテキストのみ送信
masked_text, reverse_map = mask_pii(user_input)
llm_response = call_llm(masked_text)
# 出力を再同定
final_response = reidentify(llm_response, reverse_map)homula's Insight
PIIマスキングの実装はパターンAを推奨します。実装工数は2〜4週間が一般的ですが、業務プロセスへの統合（入力パイプライン改修・逆マッピング管理・監査ログ連携）の設計が品質を左右します。homulaでは、業務要件に応じたマスキングルールの設計からMicrosoft Presidio / spaCyを活用した実装まで支援しています。
Decision Matrix
要件別 技術選定マトリクス
懸念の深刻度と業務要件に応じて、最適な対策を選択してください。多くのケースで類型1〜2の対策で十分であり、オンプレLLMが必要なのは特定の規制環境のみです。
学習利用が心配
推奨対策
エンタープライズ契約 + ポリシー確認
追加コスト
追加コストなし
トレードオフ
なし（デフォルトで保護済み）
データが国外に出ることが懸念
推奨対策
日本リージョン指定エンドポイント + Organization Policy強制
追加コスト
わずか（設定変更のみ）
トレードオフ
一部モデルが未対応のケースあり
PII・機密情報を含む入力がある
推奨対策
PIIマスキング（前処理 or プロンプトレイヤー）
追加コスト
中（実装工数2-4週）
トレードオフ
文脈情報が一部失われる可能性
金融・医療など規制業界
推奨対策
日本リージョン + VPC閉域 + ISMAP/FISC対応クラウド
追加コスト
中高（設計・実装が必要）
トレードオフ
一部機能制限の可能性（バッチ等）
完全オフライン必須
推奨対策
オンプレLLM（LLaMA / Mistral）または非接続環境へのデプロイ
追加コスト
高（GPU/インフラ投資 + 運用）
トレードオフ
最新GPT-4クラスの精度には到達しない
homula Support
ブートキャンプでの要件マッピングセッション
homulaのブートキャンプ（3〜5日）では、初日にデータ主権要件の棚卸しと技術選定を行います。「どの懸念が本当の問題か」を特定し、過剰なオンプレ投資を回避します。
要件マッピングセッション
対象業務・データ種別・既存規制要件を4類型フレームワークで整理。「本当の懸念」を特定し、技術選定の方向性を決定。
アーキテクチャ設計
要件に合ったクラウド選定・リージョン設定・VPC構成・PIIマスキング実装方針を設計。情報システム部門・法務への説明資料も作成。
プロトタイプ構築 + ROI試算
実際の業務データ（マスキング済み）を使ったプロトタイプを構築。セキュリティ要件充足を確認しながら、投資対効果を試算。
LLMセキュリティ完全ガイド — シリーズ記事
データ主権
学習利用・リージョン・ローカル・マスキングの4類型
本記事エージェント固有リスク
プロンプトインジェクション・権限スコープ・HITL・出力フィルタリング
準備中ガバナンスフレームワーク
監査ログ設計・日本規制対応・モデルサプライチェーン管理
準備中FAQ
よくある質問
出てきません。ChatGPT Enterprise契約およびOpenAI APIでは、ユーザーが入力したデータはモデルの学習に使用されないことが利用規約で明記されています。無料版のChatGPT（ChatGPT.com）では異なるポリシーが適用されるため、業務利用には必ずEnterprise契約またはAPIを使用してください。Vertex AI / Azure OpenAI Serviceも同様に、プロンプトデータは学習利用されません。
リージョン限定エンドポイントを適切に設定すれば、処理・保存ともに指定リージョン内に限定されます。ただし、Google Cloud の場合はグローバルエンドポイントを使用するとデータの所在を保証できないため、必ずasia-northeast1（東京）などのリージョン指定エンドポイントをOrganization Policyで強制することが重要です。Azure OpenAI ServiceでもリソースをJapan Eastに作成し、Private Endpointを設定することでVPC内に閉じた通信が可能です。
2026年3月時点で、オープンソースLLM（LLaMA 3.3 70B / Mistral Large等）はGPT-4o / Claude 3.7に比べて日本語の複雑なタスクで10〜30%程度の精度差があります。コーディング・英語タスクでは差が縮まっています。ただし、専門ドメインへのファインチューニングや特定業務への最適化により、その差を埋めることが可能です。完全オフライン要件がない限り、homulaでは日本リージョンのクラウドLLMを基本推奨としています。
「前処理（プロンプト生成前）」での実装を推奨します。理由は2点あります。①プロンプトレイヤーでのマスキングはLLMへの入力自体を変えないため、元のPIIがLLMに渡るリスクが残る。②前処理で匿名化・仮名化を行い、LLMへは「顧客ID:C12345」のような代替表現を渡すことで、後段で再同定する設計が安全です。実装上はPII検出ライブラリ（Microsoft Presidio / spaCy等）を入力パイプラインに組み込む形が一般的です。
ブートキャンプの初日に「データ主権要件マッピングセッション」を実施します。対象業務・データ種別・規制要件・既存インフラを整理し、4類型のどれが実態の懸念かを特定。その上で技術選定マトリクスに基づき、コスト・精度・運用負荷のバランスを取った最適構成を提案します。5日間のブートキャンプ終了時には、要件定義書・アーキテクチャ設計書・ROI試算を成果物として納品します。
Next Step
自社のデータ主権要件を正確に把握したい
「4類型のどれが自社の懸念に該当するか」をブートキャンプの初日に整理します。過剰なオンプレ投資を避け、最適なコスト・精度・運用バランスで構築するための要件定義セッションを提供します。