個人情報をAIでぶん回したい——Amazon Bedrockで「学習されない・外に出ない」構成を作る

• カテゴリ: AWS / 生成AIセキュリティ
• 対象読者: 個人情報や社外秘を含むデータをAIで処理したい中小企業の経営者・情シス担当・エンジニア
• SEOキーワード: Amazon Bedrock, 個人情報, PII, PrivateLink, Guardrails, ゼロデータ保持

「顧客名簿をAIで整理したい」「問い合わせメールの個人情報を含んだまま要約したい」——でも、ChatGPTに顧客の氏名や住所を貼り付けるのは怖い。そう感じている中小企業の経営者・情シス担当の方は多いはずです。

実際、その感覚は正しいと考えています。無料・個人向けの生成AIサービスの多くは、入力内容がサービス改善（つまりモデル学習）に使われる可能性があり、規約上もそう明記されています。一方で、PII（個人識別情報）を安全にAIで処理できる構成は、すでに実用レベルで存在します。本記事では、AWSのAmazon Bedrockを軸に、「PIIが学習されない・外に出ない」ことの公式な裏付けを出典付きで整理し、VPCエンドポイント（AWS PrivateLink）やGuardrailsを組み合わせた実践的なアーキテクチャを解説します。最後にGoogle CloudのVertex AIとの比較も行います。

1. そもそも何が怖いのか——3つのリスクに分解する

「AIに個人情報を入れるのが怖い」を分解すると、実は3つの別々のリスクです。

1. 学習リスク: 入力したデータがモデルの学習に使われ、将来、他人への回答に混ざって出てくるかもしれない
2. 保持リスク: 入力データがサービス側のサーバーに保存され、漏洩や目的外利用の対象になるかもしれない
3. 経路リスク: データがインターネットを経由する途中で盗聴・傍受されるかもしれない

このうち1と2は契約と規約の問題、3はネットワーク設計の問題です。Bedrockはこの3つすべてに公式な回答を持っています。順に裏を取っていきましょう。

2. 裏取り①: Bedrockはプロンプトを学習に使わない

まず最重要の学習リスクについて。AWSの公式ドキュメント「Data protection in Amazon Bedrock」には、プロンプトと生成結果をAWSのモデル学習に使用せず、サードパーティ（モデル提供元）にも配布しないことが明記されています。ファインチューニング用のトレーニングデータも同様で、利用日時などのメタデータすらモデル学習には使われないとされています。

• 出典: Data protection in Amazon Bedrock（AWS公式）
• 解説記事: Amazon Bedrockの規約周りの情報を読んでみる（DevelopersIO）

3. 裏取り②: モデル提供元（Anthropic等）もデータに触れない

「AWSは学習しなくても、モデルを作っているAnthropicやMetaには渡るのでは？」という疑問も、AWS re:Postの公式ナレッジで明確に否定されています。ポイントは仕組みです。

• Bedrockは顧客の入力・出力データを保存せず、サードパーティのモデルプロバイダーと共有せず、モデル学習にも使用しない
• 各モデルプロバイダーごとに専用のモデルデプロイアカウントを用意し、モデルはAWS内部にデプロイされる。モデル呼び出しの通信はAWSネットワーク内で完結し、モデルプロバイダーはそのデプロイアカウントにアクセスできない
• 不正利用検知の仕組みは自動化されており、人間が入出力データにアクセスすることはない

「規約でそう書いてある」だけでなく、モデル提供元が物理的にデータへ到達できない配置になっている点が、顧客への説明材料として大きいところです。

• 出典: Learn how Amazon Bedrock uses model input and output data（AWS re:Post公式）
• 出典: Amazon Bedrockによる生成AIデータの保護（AWSセキュリティ成熟度モデル） — どのモデルプロバイダーも顧客のデータやプロンプトから学習できないこと、転送中・保存時の暗号化が必須であることが記載されています

4. 裏取り③: データ保持も制御できる（ゼロデータ保持）

保持リスクについては、Bedrockはアカウントレベルのデータ保持モードで制御できます。2026年のAWS公式ブログでは、保持モード（none / default / inherit / provider_data_share）の仕組みと、SCP（サービスコントロールポリシー）を使って組織全体でモデルプロバイダーとのデータ共有を禁止し、ゼロデータ保持を強制する方法が解説されています。「規約で守られている」だけでなく、「技術的に強制できる」段階まで来ているということです。

• 出典: Amazon Bedrockのゼロデータ保持の強制方法（AWS公式ブログ）

なお同記事には重要な注意点もあります。CSAM（児童虐待コンテンツ）対策として、フラグが付いたコンテンツはモードがnoneでも保存・確認され得ること、そしてコンプライアンス要件に合うモデルを選ぶ責任は利用者側にあることです。「絶対」を主張する際は、この例外の存在まで含めて顧客に説明するのが誠実な設計だと思います。

5. 経路リスクへの回答: VPCエンドポイント（AWS PrivateLink）で「インターネットに出ない」

契約面がクリアになったら、次はネットワークです。Bedrockはインターフェイス型VPCエンドポイント（AWS PrivateLink）に対応しており、インターネットゲートウェイ・NAT・VPNを一切使わずに、VPC内からプライベート接続でBedrockを呼び出せます。EC2やECS FargateのタスクにパブリックIPがなくても呼び出せるため、PIIを含むリクエストが一度もインターネットを通らない構成が組めます。

構築のポイントは以下の通りです。

• エンドポイントのサービス名は com.amazonaws.region.bedrock-runtime（推論用）。管理系は bedrock、エージェント系は bedrock-agent / bedrock-agent-runtime を別途作成
• プライベートDNSを有効化すると、アプリ側はコード変更なしで通常のリージョンDNS名（bedrock-runtime.ap-northeast-1.amazonaws.com 等）のままプライベート経路を通せる
• エンドポイントポリシーで、そのエンドポイント経由で許可するアクション・リソースを絞り込める（デフォルトはフルアクセスなので、本番では必ず絞る）

• 出典: インターフェイスVPCエンドポイントを使用したBedrockへのプライベート接続（AWS公式）

さらにIAM条件キー（bedrock:GuardrailIdentifier）でガードレール適用を強制したり、エンドポイントポリシーとSCPを組み合わせてマルチアカウントで統制する設計パターンも整理されてきています。

• 参考: Amazon Bedrock Security and Governance（hidekazu-konishi.com）

6. もう一段の防御: Guardrailsの機密情報フィルターでPIIをマスクする

「そもそもLLMに生のPIIを渡したくない」という要件には、Bedrock Guardrailsの機密情報フィルター（Sensitive Information Filters）が使えます。

• 氏名・住所・メールアドレス・電話番号・クレジットカード番号など、多数の定義済みPIIタイプに対してブロックまたはマスク（{NAME}や{EMAIL}といったタグへの置換）を設定できる。カスタム正規表現の追加も可能
• 重要なのは処理の順序で、入力の評価はガードレール側の機械学習ベースの処理が基盤モデルに渡る前に行うこと。ブロック判定なら基盤モデルの推論自体が破棄されるため、「生のPIIをLLMに渡さない」要件に正面から応えられる
• ApplyGuardrail APIを使えば、モデル呼び出しなしでフィルタリングだけを独立実行できる。つまりBedrock以外のLLM（OpenAIやGemini、ローカルLLM）の手前に置くPIIフィルタ層としても機能する

• 出典: Bedrock Guardrails 機密情報フィルター（AWS公式）
• 出典: 機密情報フィルターの内部処理（DevelopersIO）
• 出典: Bedrock Guardrailsで日本語PIIをどこまで検知できるか（AWS Japan / Zenn）

日本語での注意点（ここが実務の肝）

• 日本語のPII検知にはStandardティア＋クロスリージョン推論の設定が必要になるケースがあります。クロスリージョン推論を使うと、処理が指定地理圏（APAC等）内の別リージョンに回る可能性があるため、「データは東京リージョンから出ない」という要件がある顧客には設計段階で確認が必要です
• 組み込みのPII検知は確率的なML処理であり、日本語では検知漏れ（住所や年齢など）の報告もあります。カスタム正規表現やNER（固有表現抽出）による補完を前提に精度検証をすべきです
• モデル呼び出しログを有効にしていると、ブロックされたコンテンツもプレーンテキストでログに残ります。PII案件ではログの保存先（CloudWatch/S3）のアクセス制御と暗号化まで含めて設計してください

7. 参考アーキテクチャ

小規模SaaS・社内ツールを想定した最小構成はこうなります。

[社内アプリ / SaaS (ECS Fargate, private subnet)]
        │  (VPC内通信のみ・パブリックIPなし)
        ▼
[Interface VPC Endpoint: bedrock-runtime (PrivateLink)]
        │  エンドポイントポリシーで呼び出し可能なモデル/アクションを制限
        ▼
[Bedrock Guardrails] ─ 入力: PIIをマスク or ブロック(モデル到達前)
        ▼
[基盤モデル (Claude等)] ─ プロンプト/出力は学習・保持・第三者共有なし
        ▼
[Guardrails] ─ 出力側でも再フィルタ
        ▼
[アプリへ返却]  ※RAGを組む場合、S3/Auroraは暗号化+プライベート配置

「学習されない（規約＋専用デプロイアカウント）」「保持しない（ゼロデータ保持）」「インターネットに出ない（PrivateLink）」「そもそも生PIIを渡さない（Guardrails）」の4層で、冒頭の3リスクをすべて塞いだ形です。

8. Vertex AI（Google Cloud）との比較

「同じことがGoogleでもできるのか？」——結論、Vertex AI経由なら学習面の保証はBedrockと同水準です。

• Google CloudのService Specific Termsの「Training Restriction（トレーニングの制限）」条項により、顧客の事前の許可・指示なしに顧客データをAI/MLモデルの学習やファインチューニングに使わないことが規約で保証されています。Vertex AIでは追加設定不要でこれが適用されます
• ゼロデータ保持のためのドキュメントも整備されており、キャッシュ等の一時保持を無効化する手順が公開されています
• ネットワーク境界はVPC Service Controls、暗号鍵はCMEK（顧客管理の暗号鍵）で統制でき、思想としてはPrivateLink＋KMSに対応します

• 出典: Vertex AIとゼロデータ保持（Google Cloud公式）
• 参考: Vertex AIにおけるGemini APIのデータ利用について（Qiita）

ただし重大な落とし穴が1つ: 同じGeminiでも、Google AI Studio（無料枠のGemini API含む）は別物です。無料サービスの規約では、送信したコンテンツと生成結果がGoogleのプロダクト・サービス・機械学習技術の提供・改良・開発に使われることが明記されており、品質向上のための人間によるレビューが行われる場合もあります。「Geminiを使っています」という一言の中に、規約上まったく別のサービスが同居しているわけです。業務でPIIを扱うなら、必ず課金プロジェクトのVertex AI経由に統一してください。

• 参考: Gemini APIはモデル学習に使われるの?（iret.media）

比較まとめ

なおMicrosoftのAzure OpenAI Serviceにも同種のエンタープライズ保証がありますが、不正利用監視の既定動作や適用除外申請など固有の論点があるため、採用検討時は最新の公式規約を直接確認することをおすすめします（本記事では出典を確認したBedrock/Vertexに絞っています）。

9. まとめ——「怖いからやらない」から「構成で担保する」へ

PII×AIは、もはや「入れていいか/ダメか」の二択ではありません。規約（学習・保持）とアーキテクチャ（経路・フィルタ）の両面で担保するフェーズに入っています。Bedrockなら、公式ドキュメントで裏の取れた非学習・非共有の保証に、PrivateLinkとGuardrailsを重ねることで、「個人情報が外に出ない」ことを顧客に出典付きで説明できる構成が作れます。

弊所では、AWS上でのPII対応AI基盤（Bedrock＋閉域構成＋RAG）の設計・構築を支援しています。「顧客データをAIで活用したいが社内稟議が通らない」という段階のご相談も歓迎です。

本記事の規約・仕様に関する記述は2026年8月時点の公開情報に基づきます。契約判断の際は必ず一次情報（各社公式ドキュメント・利用規約）をご確認ください。