なぜAIではなく正規表現なのか？
規制コンプライアンスのためには、説明可能で再現可能な結果が必要です。私たちの決定論的アプローチはまさにそれを提供します—ブラックボックスなし、驚きなし。
詳細な比較
We use the best tool for each job: deterministic regex patterns for structured data, and proven ML models for names and entities. Built on Microsoft Presidio.
| Entity Type | Detection Method | Examples |
|---|---|---|
| 構造化データ | 正規表現パターン | メール、SSN、クレジットカード、IBAN、電話番号 |
| 名前と組織 | MLモデル（spaCy、Stanza） | 人名、会社名、場所 |
| 48言語 | XLM-RoBERTa | クロスリンガルエンティティ認識 |
| 再現性 | 100%再現可能 | 同じ入力 = 同じ出力、毎回 |
| 名前検出 | 高精度のML | 信頼度スコアを持つ実証済みのNLPモデル |
| 監査可能性 | +完全に監査可能 | 各エンティティの位置、タイプ、信頼度 |
パターンマッチングの仕組み
各エンティティタイプには特定のフォーマットにマッチするように慎重に作成された正規表現パターンがあります。
メールアドレス
[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}標準的なメールフォーマットにマッチします：local-part@domain.tld
クレジットカード番号
\b(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|...)\bVisa、Mastercard、Amex、その他のカードフォーマットにマッチし、Luhn検証を行います
ドイツのIBAN
DE[0-9]{2}\s?[0-9]{4}\s?[0-9]{4}\s?[0-9]{4}\s?[0-9]{4}\s?[0-9]{2}オプションのスペースを含むドイツのIBANフォーマットにマッチします
コンプライアンスのために構築
監査人が「なぜこれが検出されたのか？」と尋ねたとき、明確な回答が必要です。私たちの正規表現ベースのアプローチはまさにそれを提供します。
- GDPR第25条：説明可能な処理によるプライバシー設計
- ISO 27001：文書化された再現可能なプロセス
- 監査トレイル：すべての検出は特定のパターンに追跡可能
監査回答の例
Q: なぜ「john.smith@company.com」がフラグ付けされたのですか？
A: 位置45-68でメールパターンにマッチし、信頼度0.95。パターン：標準メールフォーマットの検証。