公開：2026年9月11日, 最終更新：2026年9月11日
30秒サマリー
- AWSがAmazon Bedrock上で動作するLLMベースの個人情報（PII）検出ツールの実装方法を公式ブログで詳説した
- モデルを問わず差し替え可能な設計で、新PII種別の追加もプロンプト編集のみで対応できる
- 5つの公開データセット・49,365件を用いてOpenAI PrivacyFilterを含む9つの検出器と比較評価
何が起きたか
AWS Machine Learning Blogは、Amazon Bedrock上の任意のLLMで動作する個人情報（PII）検出ツール「pii-detector」の実装方法と評価結果を公式ブログ記事として公開した。ツールはGitHub上のサンプルリポジトリ「sample-llm-pii-detection」にパッケージとして公開されており、実際に動作させる手順も記事内で詳細に解説されている。
同ツールの特徴は「モデル非依存（model-agnostic）」の設計にある。PII検出ロジックはシステムプロンプトのテンプレートとして実装されており、氏名・住所・メールアドレス・電話番号・社会保障番号・銀行口座・生年月日など15カテゴリのエンティティ定義がテキストとして管理される。新たなエンティティ種別（例：社員IDや暗号資産ウォレットアドレス）を追加する場合、モデルの再学習や再デプロイは不要で、プロンプトの1行を編集するだけで対応できるとしている。バックエンドはAmazon Bedrockの管理型モデル（MistralやOSS-GPTなど）のほか、自社のVPC内にホストするオープンモデルにも対応しており、エアギャップ環境での利用も想定されている。
評価はHugging Face上の5つの公開PIIコーパス（計49,365件、222,114件の正解スパン）を使用し、8言語（英・独・仏・西・蘭・伊・ヒンディー・テルグ）をカバー。OpenAI PrivacyFilterを含む9つのLLMベース検出器と精度・再現率・F1スコアで比較された。ただし、各データセットや検出器間でラベル体系が異なる（例：「PRIVATE_NAMES」対「NAME」）ため、横断的な比較には正規化の工夫が必要だと記事内で言及されている。
原典ハイライト
「検出ロジック全体がプロンプトに収まっているため、特定モデルの固有仕様に依存しない。エンティティセットの変更はプロンプトへの1行編集であり、再学習も再デプロイも不要」という設計思想が記事の核心。LLMが文字オフセットを確実に返せないという制約は後処理で補完し、ハルシネーションによる誤ラベルも別名テーブルで吸収する仕組みを採用している。
出典: AWS Machine Learning Blog（公式ブログ）
So What?（なぜ重要か）
従来のトークン分類モデル（BERTなど）によるPII検出は、学習時に定義したエンティティ種別しか対応できず、新カテゴリ追加のたびに再学習が必要だった。LLMベースのプロンプト駆動型アーキテクチャはこの制約を取り除き、業務固有の個人情報定義を即座に反映できる柔軟性をもたらす。Amazon Bedrockの完全マネージド環境を使えばサーバー管理が不要で、従量課金制となる点も運用負荷の軽減につながる。
日本企業への示唆
日本企業にとって最も直接的な示唆は、LLMのファインチューニング前に行うべきデータクレンジングの自動化手段として、このアーキテクチャが応用できる点だ。社員番号・マイナンバー・顧客ID等、自社固有の識別子をPIIとして検出させる場合も、プロンプト編集のみで対応できるため、個人情報保護法対応やGDPR準拠が求められる越境データ活用においても迅速に適用できる。社内に閉じた環境（VPC内のオープンモデル）でも動作するため、機密性の高いデータを外部APIに送れない金融・医療・官公庁系のシステムでも検討余地がある。まずはAWSが公開しているサンプルコードを検証環境で試し、自社データセットに対する精度を把握することが現実的な第一歩となる。
背景・経緯
LLMのファインチューニングに使う訓練データには、顧客対応記録やHRデータなど自由記述テキストが多く含まれ、PIIが混入しやすい。モデルがPIIを記憶・再現するリスクはプライバシーリスクとして認識されており、学習前のデータクレンジングが重要とされている。従来の固定スキーマ型トークン分類器では多様な業務固有PIIへの対応に限界があり、LLMを活用した柔軟な検出手法への関心が高まっている背景がある。
