AI導入を検討している企業の情報システム部門から、homulaが最も頻繁に受ける質問がある。「LLMは社外のサービスに社内データを送るんでしょう？うちはセキュリティ的に無理です」というものだ。
この発言には正しい認識も含まれている。しかし問題は、「社内データを出したくない」という一文が、実際には4つの全く異なる懸念を混在させている点にある。それぞれの懸念は技術的に独立しており、解法も異なる。懸念の種類を特定せずに「うちはLLMが使えない」と判断すると、実際には対応可能な課題を乗り越えられずにAI活用の機会を逃すことになる。
エンタープライズ企業がLLMをクローズドで利用する方法は、学習利用制御・データ保存リージョン選択・完全ローカル化・入力マスキングの4類型に整理できる。 どの組み合わせが自社の要件に合致するかを判断するために、以下の4つの質問に順番に答えてほしい。
Q1. 「入力したデータが、AIの学習に使われることが心配」ですか？
最も多い懸念がこれだ。社員が入力したプロンプトや社内文書が、AIベンダーのモデル改善に使われ、他社に流出するかもしれないという不安である。
結論から言えば、エンタープライズ向けのAPI利用・有償プランでは、この懸念はほぼすべてのメジャーベンダーで制度的に解消されている。
主要ベンダーの学習利用ポリシー比較
| ベンダー | 学習利用（デフォルト） | ポリシーの根拠 |
|---|---|---|
| Anthropic Claude API | ❌ 使用しない | 商用製品は入出力を学習に使わない旨を明記。フィードバック送信経路は別途 |
| OpenAI API | ❌ 使用しない | API経由データはデフォルトで学習対象外。ChatGPT Enterpriseも同様 |
| Google Vertex AI（Gemini） | ❌ 使用しない | プロンプト・レスポンスを基盤モデルの学習に使用しないことをCloud CDPA（Data Processing Addendum）で法的に定義 |
| Azure OpenAI Service | ❌ 使用しない | Abuse Monitoring目的の一時保持はあるが学習には不使用。契約でゼロ保持オプションも選択可 |
注意すべき例外が1点ある。OpenAIはAPIデータを最大30日間、不正利用監視（Abuse Monitoring）を目的として一時保持するデフォルト設定がある。これはモデル学習ではないが、「データが一切サーバーに残らない」と思っている場合は認識の齟齬が生じる。ゼロ保持（Zero Data Retention）オプションへの申請が可能だが、エンタープライズ契約が前提となる。
「個人情報を含むプロンプトを入力する場合、学習利用しないことを提供事業者で十分確認すること」——これは個人情報保護委員会が2023年に示した注意喚起の核心でもある。API利用であればこの確認は完了できる状態にある。
コンシューマー版（無料のChatGPT、Gemini.google.com等）では学習利用されるケースがある。企業の業務利用では必ず有償のエンタープライズプランまたはAPIを使うこと。コンシューマー版との混同が「LLMは学習に使う」という誤解の最大の発生源になっている。
→ Q1の懸念が解消された場合、Q2へ。
Q2. 「データが日本国内に保存・処理されることが必要」ですか？
学習利用の問題は解決できても、次に出てくる懸念がデータレジデンシーだ。ISMAP対応、金融庁・個人情報保護委員会の規制対応、あるいは社内ポリシーとして「データの処理は国内サーバーに限定」という要件がある企業で頻出する。
主要なLLMサービスは、2026年時点で東京リージョンへの対応を完了している。
日本リージョン対応状況
| ベンダー / サービス | 東京リージョン | 大阪リージョン | ISMAP登録 |
|---|---|---|---|
| Google Cloud Vertex AI | asia-northeast1 ✅ | asia-northeast2 ✅ | ✅（Vertex AI含む） |
| AWS Bedrock（Claude / Llama） | ap-northeast-1 ✅ | — | ✅ |
| Azure OpenAI Service | Japan East ✅ | Japan West ✅ | ✅ |
| Anthropic Claude API（直API） | データセンターは米国 | — | — |
Anthropic Claudeを使いたい、かつ日本リージョンに処理を閉じたい場合は、AWS Bedrock経由（ap-northeast-1）またはGoogle Cloud Vertex AI経由（asia-northeast1） でClaudeを呼び出すことで実現できる。Claude 3.7 SonnetおよびClaude 3.5 Haikuは東京・大阪リージョン双方でGA（一般公開）済みだ。
リージョン設定の落とし穴
Google Vertex AIを利用する際に多いミスが、グローバルエンドポイント（us-central1などに自動ルーティングされる設定）を使ってしまうケースだ。リージョン限定エンドポイントを明示的に指定しなければ、データが日本国内に留まる保証はない。TerraformやOrganization Policyで asia-northeast1 のみを許可する設定を標準化することを強く推奨する。
VPC閉域構成はQ2の発展形として機能する。VPC内にエンドポイントを閉じることで「日本リージョン内でかつインターネットへの露出なし」を同時に満たせるが、設計コストは高くなる。この構成の詳細はQ3で扱う。
ISMAPについては、Google Cloud・AWS・Azureいずれも登録済みであり、Vertex AIを含む主要AIサービスが評価範囲に含まれていることが2026年3月時点で確認されている。金融機関向けのFISC安全対策基準（第13版）への対応も、Google CloudはSOC 2 Type IIや国際認証（ISO 27001/27017/27018）と組み合わせたコントロールマッピングドキュメントを提供している。
→ Q2の懸念も解消した場合、Q3へ。
Q3. 「外部のクラウドAPIそのものを使用することを禁止したい」ですか？
「どのリージョンかに関係なく、LLMを外部のクラウドサービスとして呼び出すこと自体が禁止されている」という要件だ。通信事業者・防衛省関連・一部の金融機関など、インターネット経由の外部通信自体が社内規定で制限されている環境が該当する。
この場合、選択肢は大きく2つになる。VPC閉域網でのプライベート接続、またはオンプレミスLLMのデプロイだ。ただし、どちらも相応のコストと制約を伴う。
選択肢1: VPC閉域構成（現実解として最有力）
多くのエンタープライズで採用されているのが、クラウドのVPC内にLLMエンドポイントを閉じ込める構成だ。インターネットを経由せずにLLMを呼び出せるため、「外部API通信禁止」要件の実質的な充足手段になる。
- AWS Bedrock: PrivateLink経由のVPCエンドポイントで、ap-northeast-1のBedrockにインターネット経由なしでアクセス可能
- Azure OpenAI: Virtual Network統合と Private Endpoint で社内VNet内に閉じる構成がサポート済み
- Google Vertex AI: VPC Service Controls（VPC-SC）でサービス境界を設定し、インターネットからのAPIアクセスを完全遮断。Private Service Connect（PSC）経由のプライベート接続も推奨構成として提供されている
選択肢2: オンプレミスLLM
2026年3月時点で、エンタープライズで実用レベルとなるオープンソースLLMの筆頭は Meta LLaMA 3.3（70B） および LLaMA 4 シリーズだ。しかし、自社データセンターに70BパラメータのLLMをデプロイするには以下のリソースが必要になる。
- GPU: NVIDIA A100（80GB）またはH100 × 2〜4枚（fp16推論で70B稼働に必要）
- ハードウェアコスト: A100 × 4枚のサーバー構成で初期投資3,000万円〜
- 推論速度: クラウドのGPTやClaude比で2〜5倍のレイテンシが一般的
- 運用負荷: モデルのバージョン管理、セキュリティパッチ、GPUドライバ管理が継続的に発生
オンプレミスLLMは「データが確実に外部に出ない」メリットの反面、最新モデルへのアップデートが遅れること、クラウドの主要モデルと比較してタスクによっては精度が15〜30%低下するケースがあること、GPU運用コストがクラウドAPIの数倍になることを織り込んで判断する必要がある。VPC閉域で要件を満たせるなら、オンプレより先に検討すべき構成だ。
→ Q3の要件が「VPC閉域で可」なら主要クラウドで実現可能。「真のオンプレ」ならLLaMA系のGPUサーバー構築が必要。
Q4. 「個人情報・機密情報をLLMに直接渡したくない」ですか？
Q1〜Q3とは性質が異なる懸念だ。「外部に出したくない」のではなく、「LLMのコンテキストに入力される情報そのものを制御したい」という要件である。個人情報保護委員会の注意喚起が明示するように、「個人情報を含むプロンプト入力は、利用目的達成に必要な範囲内かを確認」することが求められている。
この問題の解法が**入力マスキング（DLP: Data Loss Prevention）**だ。
DLPの動作パターン
| アクション | 動作 | 適用例 |
|---|---|---|
| Warn（警告） | 送信は通すが管理者に通知 | 社員番号の業務フロー利用 |
| Redact（マスク） | 機密部分を *** に置換してLLMに送信 | 氏名・クレジットカード番号 |
| Block（遮断） | 送信自体を停止 | 社外秘指定ファイルの丸ごと送信 |
従来のDLPは正規表現によるパターンマッチング（「16桁の数字パターン = クレジットカード」）が中心だった。LLM時代のDLPに求められるのはそれに加えて文脈に基づく機密判断だ。「弊社の原価率32%に基づく差額算出の結果…」という文面には「社外秘」という文字列は含まれないが、文脈的に外部に出すべきでない情報だとAI判断型DLPは検知できる。
個人情報保護法との関係
個人情報保護委員会は「本人同意なく個人データをプロンプト入力する場合、個人データが『応答生成以外』の目的で取り扱われないことを提供事業者について十分確認すること」を明示している。API利用でQ1の確認が完了していれば学習利用の問題は解消しているが、個人情報の入力自体を必要最小限にとどめる設計は独立した要件として求められる。入力マスキングはこの要件への直接的な技術的回答になる。
なお、経産省・総務省の「AI事業者ガイドライン」（2024年）も、プロンプト入力（個人情報・機密情報を含み得る）を「データ流通」として扱い、用途・体制・委託関係と一体で設計することを実務上の要請として位置づけている。
まとめ：4つの質問で自社の要件タイプを特定する
以下のマトリクスで、自社が直面している懸念の種類と対応技術を整理してほしい。
| 懸念の種類 | 技術的対応 | 難易度 | 実装コスト目安 |
|---|---|---|---|
| Q1: 学習に使われたくない | エンタープライズAPIを利用（規約確認） | ★☆☆ | ほぼゼロ（契約確認のみ） |
| Q2: 日本国内で処理したい | 日本リージョン指定エンドポイントの設定 | ★★☆ | 構成変更工数（1〜2週） |
| Q3: 外部API通信自体を禁止 | VPC閉域構成 or オンプレLLM | ★★★ | 数百万〜数千万円規模 |
| Q4: 機密情報を入力させたくない | DLP/入力マスキングの実装 | ★★☆ | 設計〜実装で2〜4週 |
多くのエンタープライズにとっての現実解は、Q1+Q2の対応（リージョン指定API）にQ4（DLP）を組み合わせた構成だ。これはクラウドベースで実現可能であり、数千万円のGPUサーバー投資なしに本番運用が始められる。
Q3（完全外部遮断）が真の要件として確認された場合のみ、VPC閉域またはオンプレLLMの設計に進む。ただしその際は、「最新モデルへのアクセスと精度を犠牲にする判断」であることを経営層・セキュリティ部門・現場部門が共通認識として持った上で意思決定することが重要だ。
「うちはセキュリティ的に無理」という判断が、実際には「Q1とQ2の懸念だけで、適切な設定をすれば解決可能だった」というケースが、homulaがエンタープライズと向き合う現場で圧倒的多数を占める。
4つの懸念を整理する前に「LLMは全部無理」と結論づけてしまうと、競合他社がAIで業務効率を高めている間に自社だけが停滞するリスクがある。まず要件の種類を特定することが、最初の一歩になる。
各質問の技術的な詳細——ゼロ保持の設定手順、VPC-SCの具体的な構成方法、DLPのエンタープライズ実装パターン——については、homulaのセキュリティガイドシリーズで体系的に解説している。
ブートキャンプで要件を3〜5日で整理する
homulaは、エンタープライズ企業向けにAIエージェントの戦略策定・PoC・実装・運用・内製化までを一気通貫で支援するAIインテグレーターです。
セキュリティ要件の整理は、適切な技術選択と業務実装の土台になります。ブートキャンプでは業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で完結させます。「うちの環境で本当に使えるか」を最短で検証したい場合は、以下からご相談ください。
関連記事