なぜPII-Fiが必要か
日本語のPII保護には、言語固有の構造的な難しさがあります。 多言語対応の汎用的なPII検出ツールだけではカバーしきれないこれらの課題に対して、 PII-Fiは日本語に特化した検出エンジンで本番品質の精度を実現します。
日本語PII検出が難しい理由
- 「田中様」「山田部長」── 敬称や役職が人名を特定する手がかりになる
- 「川崎」── 人名にも地名にも組織名にもなりうる曖昧性
- 住所の表記ゆれ ── 都道府県から建物名まで独自の階層構造と多様な書き方
- 電話番号のバリエーション ── 携帯・固定・フリーダイヤル × 半角・全角・区切りなし
- 文脈依存の金額情報 ── 「年収500万円」と「売上高500万円」は全く異なる機密度
自前でPII検出基盤を構築する開発・運用コストをAPI一本で解消し、 既存のDLP・SIEM・LLMワークフローに最短で組み込めます。
PII-Fiのアプローチ
- ログ・監査記録の個人情報を自動マスキング
- LLM連携時のリバーシブル仮名化で個人情報をLLMに渡さずAI活用
- 既存DLPシステムやプロキシサーバーへの組み込み
- 社内文書・チャットログ・顧客対応記録のPIIスキャン
日本語処理に特に深い強み ── 汎用ツールが100言語に対応するとき、各言語への投資は必然的に薄くなります。 PII-Fiは日本語のPII検出に特に深い強みを持ち、敬称の体系、漢字の多義性、住所の階層構造、電話番号の多様性、 和暦、マイナンバーの文脈検出など、日本語固有の課題ひとつひとつに専用の検出ロジックを組んでいます。
日本語特有の検出課題にどう対応するか
日本語のPII検出が難しい理由と、PII-Fiの対応
| 課題 | 入力例 | よくある誤検出・漏れ | PII-Fiの検出結果 |
|---|---|---|---|
| 敬称・役職付き人名 | 「山田部長に確認しました」 | 「山田」のみ検出、「部長」が欠落 | 山田部長 → PERSON_NAME |
|
英語なら "Mr. John Smith" と名前の境界は明確です。
日本語では「田中太郎」がそのまま地名の一部にも組織名の一部にもなり得ます。
PII-Fiは、様・さん・氏・殿・先生などの敬称、社長・部長・課長などの役職名を人名検出の手がかりとして積極的に活用し、
「山田花子様」の「様」まで含めた正確な検出範囲を返します。
|
|||
| 人名と地名の曖昧性 | 「川崎から届いた荷物」 | 人名として誤検出 | 川崎 → LOCATION（文脈判定） |
|
「川崎」は人名か、地名か、「川崎重工業」の一部か——英語には大文字・品詞という手がかりがありますが、日本語にはそれがありません。
PII-Fiは4層の検出エンジン（パターンマッチング・機械学習NER・辞書照合・文脈解析パイプライン）を並列に走らせ、
検出が競合した場合はエンティティの優先度と信頼度スコアに基づいて自動的に解決し、最も適切な分類を返します。
|
|||
| 表記ゆれ住所 | 「東京都渋谷区渋谷１丁目２−３」 | 全角数字・ハイフンで検出失敗 | 全角/半角自動正規化で検出 |
|
日本語は「都道府県 → 市区町村 → 丁目番地 → 建物名」と大から小へ。
しかも同じ住所に「1-2-3」「1丁目2番3号」「一丁目二番三号」という表記揺れがあり、ビル・タワー・マンション等の建物名が続きます。
PII-Fiは47都道府県を個別にリストしたパターンで住所を認識し、郵便番号（〒100-0001）から建物名（ABCビル15F）までを一体として検出します。
|
|||
| 電話番号バリエーション | 「０９０−１２３４−５６７８」 | 全角数字で検出失敗 | 全角/半角/区切りなし全対応 |
|
携帯（090/080/070）、固定電話（03/06/011…）、フリーダイヤル（0120）、ナビダイヤル（0570）、IP電話（050）、国際番号（+81）。
区切りもハイフン・スペース・全角ハイフン・区切りなし。さらに全角数字まであります。
PII-Fiは10種類以上のパターンでこれらを網羅し、前後の数字列への誤マッチを防ぐ境界チェックを組み込んでいます。
|
|||
| 文脈依存の金額 | 「年収500万円で審査」 | 金額として一律検出 or 未検出 | 500万円 → PERSONAL_INCOME |
|
金額それ自体はPIIではありません。しかし「年収500万円」は個人収入、「売上高500万円」は企業収益、「M&A金額500万円」は戦略的機密情報。
PII-Fiの文脈解析パイプラインは、周辺キーワードを解析し、金融PII・認証情報・人事労務・医療健康・経営戦略・法務契約・社内識別子の7ドメイン48カテゴリに自動分類します。
|
|||
| 敬称バリエーション | 「田中さま」「田中様」「田中氏」 | 一部パターンで漏れ | すべてPERSON_NAMEとして検出 |
※「よくある誤検出・漏れ」は汎用ツールで起こりがちな一般的なケースを示しています。特定の製品を指すものではありません。
※ のある行をクリックすると詳細を展開できます。
既存システムへの組み込みイメージ
組み込みパターン
| パターン | 説明 |
|---|---|
| LLMゲートウェイ | LLMへの送信前にPIIをマスキングし、応答後に復元。個人情報をLLMに渡さずにAI活用を実現 |
| ログパイプライン | アプリケーションログの保存前にPIIを検出・マスキングし、監査用途に安全なログを生成 |
| DLP補完 | 既存DLPの検出ルールでは対応が難しい日本語固有のPIIを補完的に検出・マスキング |
海外製ツールとの違い
海外製ツールでは実現が難しい、日本語に最適化されたPII処理
海外製ツールはそのままでは日本語の人名を十分な精度で検出できません。漢字・ひらがな・カタカナ・ローマ字が混在する日本人名には高度なチューニングが必要です。
- 約31万件の日本人名データベースを内蔵（姓 約13.9万件、名 約17.6万件）
- 漢字・カタカナ・ローマ字すべてに対応したデータベース
- 姓名の組み合わせをペアとして認識
- 自然言語処理と辞書マッチングのハイブリッド方式
山田 太郎 漢字の姓名ペア
ヤマダ タロウ カタカナの姓名ペア
Yamada Taro ローマ字の姓名ペア
同一文書内で3つとも出現しても、すべて正しく検出されます。
「株式会社○○」「○○株式会社」（前株・後株）、「有限会社」「合同会社」など日本独自の法人形式は、汎用ツールでは十分な検出精度を得ることが困難です。
- 株式会社・有限会社・合同会社・一般社団法人など日本の法人格を網羅的にパターン認識
- 前株（株式会社○○）・後株（○○株式会社）の両方に対応
- 全角文字の社名（例：「株式会社Ｑｕａｌｉｔｅｇ」）も検出可能
株式会社テクノソリューション
テクノソリューション株式会社
合同会社イノベーションラボ
一般的なPII検出ツールには「部署名」という検出カテゴリが存在しません。しかし日本のビジネス文書では、部署名も組織の内部構造を示す重要な情報であり、非識別化の対象とすべきケースが多くあります。
- 「○○事業部」「○○本部」「○○課」「○○室」など日本企業特有の部署名パターンを検出
- 番号付き部署（「第四営業部」「第二開発課」）にも対応
- 「全部」「一部」など部署名と同形の一般語との誤検出を回避する仕組みを搭載
営業推進本部
第四営業部
新宿六課
一般的なFakerライブラリでは、同じ人物の名前が出現するたびに異なるダミー名に置き換えられます。「山田太郎」が5回出現すると5つの別々のダミー名になり、文書としての意味が破壊されます。
- 同一人物は文書全体で同じダミー名に統一
- 漢字・カタカナ・ローマ字が混在しても、同一人物として紐付けて一貫した置換
- 組織名も同様に、複数回出現しても同じダミー名に統一
- 「山田 太郎」（1箇所目） → 「佐藤 健一」
- 「山田 太郎」（2箇所目） → 「佐藤 健一」
- 「山田 太郎」（3箇所目） → 「佐藤 健一」
- 「ヤマダ タロウ」 → 「サトウ ケンイチ」
- 「Yamada Taro」 → 「Sato Kenichi」
- 「山田 太郎」（1箇所目） → 「田中 次郎」
- 「山田 太郎」（2箇所目） → 「鈴木 三郎」
- 「山田 太郎」（3箇所目） → 「高橋 四郎」
- 「ヤマダ タロウ」 → 「ワタナベ ゴロウ」
- 「Yamada Taro」 → 「Suzuki Rokuro」
海外製のFakerライブラリは、日本語の電話番号形式・住所形式・日付表記などを正しく生成することが難しく、追加の対応が必要です。
- 電話番号：元の形式（03-xxxx-xxxx, 090-xxxx-xxxx）を保持してダミー生成
- 住所：日本の住所形式（都道府県・市区町村・番地）でダミー生成
- 日付：元の表記形式（YYYY/M/D, YYYY年M月D日）を保持
- 法人名：前株・後株の形式を保持（「株式会社○○」→「株式会社△△」）
03-5931-0437 03-8472-3156
090-1234-5678 090-8765-4321
東京都渋谷区代々木2-1-1 大阪府大阪市北区梅田3-1-5
2024/1/15 2023/8/22
1月15日(月) 8月22日(木)
パターンマッチングだけでは、数値が「金額」なのか「電話番号」なのか「単なる数字」なのかを区別できません。文脈によって意味が変わる情報を正しく検出するには、周囲のテキストを分析する必要があります。
独自のコンテキスト・パイプライン・レコグナイザー（CPR）を搭載。周囲のキーワードや文脈を分析して以下のような情報を検出します。
- 個人収入：「年収 650万円」「月給 35万円」
- 個人資産：「預金残高 1,200万円」「投資額 500万円」
- 企業機密：「売上高 12億円」「営業利益 3.5億円」
- 認証情報：APIキー、アクセストークン、秘密鍵
- 人事情報：評価ランク、懲戒記録、休職理由
日本語の日付表現は「2024年1月15日」「2024/1/15」「1月15日(月)」「令和6年」など多岐にわたり、汎用的な検出ツールでは網羅的に検出することが困難です。
- 和暦（令和・平成・昭和）に対応
- 曜日付き表記（「1月15日(月)」）に対応
- 複数のフォーマット（YYYY/M/D, YYYY年M月D日, M月D日）に対応
まとめ：PII-Fiが選ばれる理由
| 機能 | 一般的な海外製ツール | PII-Fi | 具体例 |
|---|---|---|---|
| 日本語人名（漢字） | そのままでは検出漏れが多く、高度なチューニングが必要 | 31万件の辞書 + 自然言語処理で高精度検出 | 山田太郎 → <人名> |
| 日本語人名（カタカナ・ローマ字） | そのままではほぼ未対応 | 全表記形式に対応 | ヤマダ タロウ / Yamada Taro も検出 |
| 日本の法人名 | 部分的な対応にとどまる | 前株・後株・全法人格に対応 | 株式会社○○ / ○○株式会社 両方検出 |
| 部署名 | 未対応 | 日本企業の部署パターンを網羅 | 第四営業部 / 営業推進本部 |
| 同一人物の一貫置換 | 出現するたびにバラバラのダミー名 | 文書全体で統一されたダミー名 | 「山田太郎」が3回 → すべて「佐藤健一」に統一 |
| 漢字・カタカナ・ローマ字の紐付け | 未対応 | 同一人物として認識し一貫した置換 | 「山田太郎」「ヤマダ タロウ」「Yamada Taro」→ 同一人物として処理 |
| 日本語日付形式 | 部分的な対応にとどまる | 和暦・曜日付きまで対応 | 令和6年 / 1月15日(月) |
| 文脈ベースの金額検出 | 未対応 | 独自エンジンで文脈を分析 | 「年収500万円」→ PERSONAL_INCOME として分類 |
| 置換後の表記形式保持 | 形式が変わってしまう | 元の形式を保持 | 03-5931-0437 → 03-8472-3156（形式保持） |
ユースケース
様々なビジネスシーンでPII-Fiを活用できます
PII検出・監査
文書内の個人情報を抽出・一覧化し、コンプライアンス対応を支援
機密情報スキャン
禁止ワード・社外秘情報を辞書マッチングで高速検出
データマスキング
個人情報をマスク・置換して安全にデータを二次利用
LLMプライバシー保護
LLMに送信前にマスキング、処理後に復元してプライバシーを保護
LLM情報持ち出し防止
認証情報、人事・医療情報、経営戦略、契約情報等をLLM送信前に検出・除去
コンプライアンス対応
個人情報の取り扱い状況を可視化し、規制対応を効率化
LLMワークフロー例
LLMに個人情報を渡さず、AI活用を実現するリバーシブル仮名化
# 1. 元のテキスト（PII含む）
text = "田中太郎様、090-1234-5678にご連絡ください"
# 2. PII-Fiでマスキング（仮名化）
result = pii_fi.detect(text, type="fake")
# → "山田花子様、080-9876-5432にご連絡ください"
# 3. LLMに送信（個人情報なし）
# result.deidentified_text にマスキング済みテキストが格納される
llm_response = openai.chat(result.deidentified_text)
# 4. 元の値に復元
restored = pii_fi.restore(llm_response, result.mapping)
# → "田中太郎様、承知いたしました。090-1234-5678に..."5種類の非識別化方式
用途に応じて最適な非識別化方式を選択できます
| 方式 | 説明 | 入力例 | 出力例 | 復元 |
|---|---|---|---|---|
replace |
タグ形式で置換 | 田中太郎 | <人名> | - |
mask |
部分マスク | 090-1234-5678 | 090-****-5678 | - |
full_mask |
完全マスク ※マスク文字は指定可能 |
田中太郎 | **** | - |
hash |
決定論的ハッシュ | 田中太郎 | JPII_PERSON_NAME_a1b2c3d4 | |
fake |
ダミーデータに置換 ※同一人物は一貫したダミー名に置換 |
田中太郎 | 山田花子 |
リバーシブル仮名化
hash と fake 方式は リバーシブル仮名化（トークン化） をサポートしています。
LLMに個人情報を送信せずにテキスト処理を行い、処理後に元の値に復元できます。
fake方式では、同一人物の漢字・カタカナ・ローマ字表記はすべて一貫したダミー名に置換されるため、LLM処理後も文脈の整合性が保たれます。
方式の選び方
| ログ出力・デバッグ表示 | replace |
| 部分的な秘匿（末尾4桁表示など） | mask |
| 完全な秘匿（監査ログ等） | full_mask |
| LLM処理後に復元が必要 | hash / fake |
| 自然な文章を保ちたい | fake |
※ ご利用にあたっての注意事項
PII-Fiが提供するマスキング・仮名化処理は、個人情報保護法上の「匿名加工情報」の作成を
保証するものではありません。匿名加工情報として取り扱う場合は、同法の定める加工基準・
公表義務・安全管理措置等の要件を別途満たす必要があります。
リバーシブル仮名化（復元可能な処理）は、法的には「仮名加工情報」に近い位置づけとなり、
匿名加工情報とは異なる義務が適用されます。詳細は
個人情報保護委員会のガイドラインをご参照ください。
3種類のカスタム認識器
パターンマッチ・辞書に加えて、PII-Fi独自の文脈解析パイプラインを搭載。
パターンでは捕捉できない文脈依存の機密情報まで、3方式であらゆる業務要件に対応します。
文脈解析パイプライン — PII検出の先へ
同じ「500万円」でも、年収なのか売上なのかM&A金額なのかを自動分類。
単なるパターンマッチでは実現できない、文脈を理解した機密情報分類。
# 7種の文脈解析パイプライン（48カテゴリ）
"年収は500万円" → PERSONAL_INCOME（個人収入）
"売上高500万円" → CORPORATE_EARNINGS（企業収益）
"M&A金額500万円" → STRAT_MA（M&A情報）
"sk-proj-abcd..." → CRED_API_KEY（APIキー）
"評価グレードS" → HR_REVIEW（人事評価）
"NDA条項に基づき" → LEGAL_NDA（秘密保持契約）
"契約番号CNT-001" → LEGAL_CONTRACT（契約情報）7種の文脈解析パイプライン（48カテゴリ）を標準搭載。 金融PII・認証情報・人事労務・医療健康・経営戦略・法務契約・社内識別子の7ドメインを 周辺テキストの文脈から自動分類します。 「極秘」「社外秘」などの修飾語があれば機密度スコアを自動ブーストします。
さらに、大量の自社ドキュメントからトレーニングさせ、 業界ドメインに特化した独自の文脈解析パイプラインを構築することも可能です。
ポリシー設定
検出するエンティティタイプをAPI単位で簡単にオン/オフ切り替え。
enabled_entities
→ 必要なPIIのみ
ホットリロード
認識器の追加・更新がサービス無停止で即座に反映。
POST /recognizers
→ 即時反映
優先度制御
認識器ごとに優先度を設定し、検出の優先順位を制御可能。 個別に優先度を設定したり、認識器の無効化することで自社用の検出ルールを設定可能
priority: 100
→ 禁止ワード最優先
PII-Fiだけの機能：7種の文脈解析パイプライン
同じ金額表現でも、文脈によって機密性はまったく異なります。
金融PII・認証情報・人事労務・医療健康・経営戦略・法務契約・社内識別子の7ドメインを標準搭載。
「田中さんの年収は500万円」
500万円 → PERSONAL_INCOME（個人収入）
「当社の売上は500万円」
500万円 → CORPORATE_EARNINGS（企業収益）
「M&A金額は500万円」
500万円 → STRAT_MA（M&A情報）
「sk-proj-abcd...」
sk-proj-... → CRED_API_KEY（APIキー）
「評価グレードS」
評価グレードS → HR_REVIEW（人事評価）
「NDA条項に基づき」
NDA条項に基づき → LEGAL_NDA（秘密保持契約）
PII-Fiの文脈解析パイプラインは、周辺テキストの文脈から7ドメイン48カテゴリに自動分類。 金額を一律マスキングするのではなく、 文脈に応じたポリシー適用を実現します。 認証情報、人事評価、医療データ、経営戦略——LLMに送ってはいけないあらゆる機密情報を自動検出します。
この機能は主要なPII検出サービスには見られない、PII-Fi独自のアプローチです。
運用イメージ
サービス稼働中に、REST APIを通じて検出ロジックをリアルタイムに更新できます
動的な検出ルール管理
管理画面 / CLI
- パターン追加
- 辞書追加
- 禁止ワード登録
- パイプライン変更
(無停止反映)
PII-Fi API
検出エンジン
- 組み込み認識器
- パターンマッチ認識器 動的追加
- 辞書認識器 動的追加
- 文脈解析パイプライン 動的追加
ユースケース例
| シナリオ | 操作 | 反映時間 |
|---|---|---|
| 新規取引先が決定 | 会社名辞書にエントリ追加 | 即時（ホットリロード） |
| 新プロジェクト開始 | 禁止ワード辞書にコードネーム追加 | 即時 |
| 社員番号フォーマット変更 | パターンマッチ認識器の正規表現を更新 | 即時 |
| M&Aで子会社追加 | 会社名辞書に一括インポート | 即時 |
| 金融検出ルール強化 | 文脈解析パイプラインのキーワード辞書を更新 | 即時 |
| 年度末の棚卸し | 不要になった辞書エントリを削除 | 即時 |
| 業界専門知識を反映 | 業務文書からトレーニングし、業界ドメインに特化した認識器を構築 | ご相談ベース |
主な特徴
エンタープライズ環境で求められる性能・セキュリティ・信頼性
日本語に特化した高精度検出
- AIベースの固有表現抽出 + ルールベースの4層アプローチで検出漏れを最小化
- 日本人名（漢字・カタカナ・ローマ字）、電話番号、住所、マイナンバー、組織名・部署名など日本固有のPII完全対応
- 7種の文脈解析パイプラインで認証情報・人事・医療・経営戦略・法務・社内識別子まで自動検出
高性能処理
- 1,000+ req/s のスループット、1-15ms のレイテンシ
- バッチ処理で100件/リクエストまで一括処理可能
- 10万語辞書でも1〜5msの検索速度
リバーシブル仮名化
fake方式で自然なダミーデータに置換し、LLM処理後に元の値へ復元- 漢字→漢字、カタカナ→カタカナ、ローマ字→ローマ字のフォーマット保持
- 同一人物の全表記に一貫したダミー名を割り当て（Fake名一貫性）
※ 測定条件: Ultra-Large-Highインスタンス、約500文字の日本語テキスト、replace方式、組み込み認識器のみ使用時。 カスタム認識器（大規模辞書追加等）使用時は結果が異なる場合があります。 詳細なベンチマーク条件はお問い合わせください。
企業別完全分離環境
データ漏洩リスクゼロ
- 企業ごとに物理的に独立した環境を提供
- 入力データが他社環境と混在することは一切なし
- 万が一の事態でも、他社へのデータ漏洩は構造上ありえない設計
オンプレミス提供
貴社環境で完全保護
- 貴社専用サーバーでPII-Fiを運用可能
- 入力データは貴社ネットワーク内で完結
- Qualitegを含む外部からのアクセスを完全遮断
データ取り扱いポリシー
入力データの処理と破棄
| 入力テキストの保存 | 処理完了後に即時破棄。保存・蓄積は行いません |
| モデル学習への利用 | 入力データをモデルの学習に使用することはありません |
| 通信の暗号化 | TLS 1.2以上で暗号化 |
| 処理環境 | 企業別の完全分離環境で実行 |
検出ログ
| ログ内容 | 検出されたPIIタイプ・件数・位置情報（offset）のみ |
| PII原文のログ記録 | デフォルトOFF（お客様の要件に応じて設定可能） |
| ログ保持期間 | お客様のセキュリティポリシーに合わせて設定 |
| ログ出力先 | お客様指定のSIEM・ログ基盤への連携が可能 |
API制限
| リクエスト最大サイズ | お問い合わせください |
| レート制限 | プランに応じて設定（詳細はお問い合わせください） |
| バッチ処理上限 | 100件/リクエスト |
| 対応テキストエンコーディング | UTF-8 |
よくあるご質問
PII-Fi APIに関するよくあるご質問にお答えします
いいえ、PII-Fiのマスキング処理だけでは、個人情報保護法上の「匿名加工情報」には該当しません。 個人情報保護委員会は、「個人データを単にマスキングしただけでは、 適切な加工基準を満たさない限り匿名加工情報ではなく個人データのまま」と説明しています。
匿名加工情報として取り扱う場合は、同法の定める加工基準（特定の個人を識別できず、 かつ復元できない状態にすること）、公表義務、安全管理措置等の要件を 別途満たす必要があります。
PII-Fiは、こうした要件を満たすための加工設計ガイドやテンプレートの提供を予定しています。
PII-Fiの hash 方式・fake 方式で提供するリバーシブル仮名化は、
処理後のデータから元の値を復元できる設計です。
このため、法的には「仮名加工情報」（他の情報と照合しない限り特定の個人を
識別できないよう加工した情報）に近い位置づけとなります。
仮名加工情報は、匿名加工情報とは異なり、原則として「個人情報に該当しうる」と 個人情報保護委員会のFAQで説明されています。 マッピング情報（復元用データ）の管理・廃棄方針を含め、 お客様の法務部門またはDPOと事前にご確認いただくことを推奨します。
PII-Fi APIに送信されたテキストデータは、検出・マスキング処理の実行のみに使用され、 処理完了後に破棄されます。
- 入力テキストの保存・蓄積は行いません
- モデルの学習データとして使用することはありません
- 企業別の完全分離環境により、他社データとの混在はありません
検出ログ（どのPIIタイプが何件検出されたか等の統計情報）の保持方針については、 ご契約時にお客様のセキュリティ要件に合わせて設定いたします。
はい、PII-Fi APIはREST APIとして設計されているため、 既存のDLPシステム、セキュアプロキシ、SIEM、LLMゲートウェイ等に 「PII検出・マスキングの部品」として組み込むことが可能です。
PII-Fi APIは既存のセキュリティ基盤を置き換えるものではなく、 日本語PII検出・マスキングのレイヤーとして補完する位置づけです。
はい、3種類のカスタム認識器で業務固有のPIIタイプを追加できます。
- パターンマッチ認識器: 社員番号、契約番号など正規表現で定義できるパターン
- 辞書認識器: 取引先名、製品名など固有名詞のリスト（ファジーマッチング対応）
- 文脈解析パイプライン: 周辺文脈から機密カテゴリを分類する独自認識器
いずれもAPI経由でサービス無停止（ホットリロード）で追加・更新できます。
御社の利用規模、セキュリティ要件、サポート体制に応じた 複数のプラン（Business / Enterprise / Enterprise Plus）をご用意しています。 まずは30日間の無料トライアルをご利用いただき、 その後、最適なプランをご提案いたします。
無料トライアルは30日間・月1万リクエストまでご利用いただけます。 トライアル期間中に追加費用が発生することはありません。 トライアル終了後に自動的に課金されることもありません。 継続をご希望の場合のみ、有料プランへの移行をご案内します。
現在は日本語に特化した検出エンジンを提供しています。 英語・中国語への対応は今後のロードマップに含まれています。
PII検出の先へ：LLM-Audit™
PII-Fiの検出エンジンは、包括的LLMセキュリティプラットフォーム 「LLM-Audit™」の基盤技術として採用されています。
PII検出に加えて、プロンプトインジェクション防御、 ハルシネーション検出、コンテンツフィルタ、コンプライアンスチェックなど、 LLM活用に必要なセキュリティ機能を統合的に提供します。
LLM-Audit™ について詳しく見るご利用料金
PII-Fi APIは、ご利用規模・要件に応じた複数のプランをご用意しています
有料プラン
Business / Enterprise / Enterprise Plus の
3プランをご用意しています。
御社の利用規模、セキュリティ要件、サポート体制に応じて最適なプランをご提案します。
専用環境の提供
お客様ごとに独立した専用環境を構築。他のお客様のデータと完全に分離された安全な環境でご利用いただけます。
セキュリティ対策
契約単位での環境分離により、データの漏洩リスクを最小化。エンタープライズレベルのセキュリティを確保します。
オンプレミス対応
Enterprise Plusプランではお客様のインフラ上にPII-Fiを構築可能。機密データを外部サービスに送信することなく、社内ネットワーク内で完結した運用を実現します。
カスタマイズ対応
お客様の要件に応じた認識器のカスタマイズなど柔軟に対応いたします。
クイックスタート
# デモ環境（本番環境では専用エンドポイントを提供）
curl -X POST https://api.pii-fi.com/api/detect \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_API_KEY" \
-d '{
"text": "田中太郎（090-1234-5678）のメールはtanaka@example.comです。",
"deidentification_type": "replace"
}'レスポンス例
{
"deidentified_text": "<人名>（<電話番号>）のメールは<メールアドレス>です。",
"entities": [
{
"entity_type": "JPII_PERSON_NAME",
"original_text": "田中太郎",
"start": 0,
"end": 4
},
{
"entity_type": "JPII_PHONE_NUMBER",
"original_text": "090-1234-5678",
"start": 5,
"end": 18
},
{
"entity_type": "JPII_EMAIL_ADDRESS",
"original_text": "tanaka@example.com",
"start": 24,
"end": 42
}
]
}検出可能なPIIタイプ
| タイプ | 説明 | 例 |
|---|---|---|
JPII_PERSON_NAME |
日本人名 | 田中太郎、山田花子 |
JPII_PHONE_NUMBER |
電話番号 | 090-1234-5678、03-1234-5678 |
JPII_EMAIL_ADDRESS |
メールアドレス | example@mail.com |
JPII_ADDRESS |
住所 | 東京都渋谷区渋谷1-2-3 |
JPII_ORGANIZATION |
組織名 | 株式会社ABC、○○大学 |
JPII_FINANCIAL_INFO |
金融・識別情報 | マイナンバー、口座番号 |
JPII_DATE |
日付 | 2024年1月1日、令和6年 |
JPII_CREDIT_CARD |
クレジットカード番号 | 4111-1111-1111-1111 |
JPII_IP_ADDRESS |
IPアドレス | 192.168.1.1 |
JPII_URL |
URL | https://example.com |
JPII_BUSINESS_INFO |
ビジネス情報 | プロジェクトコード、契約番号 |
| 文脈解析：金融PII（12種） | ||
JPII_PERSONAL_INCOME |
個人収入 | 年収500万円、月収30万円 |
JPII_PERSONAL_ASSET |
個人資産 | 貯蓄1000万円、投資額 |
JPII_PERSONAL_DEBT |
個人負債 | 借入金、ローン残高 |
JPII_TAX_INSURANCE |
税・保険情報 | 所得税、社会保険料、住民税 |
JPII_CORPORATE_EARNINGS |
企業収益 | 売上高500万円、営業利益 |
JPII_CORPORATE_BALANCE |
企業財務状況 | 総資産、純資産、負債比率 |
JPII_CORPORATE_INTERNAL |
企業内部情報 | 部門予算、社内コスト |
JPII_CORPORATE_STRATEGIC |
戦略的機密情報 | M&A金額500万円、出資額 |
JPII_HR_COMPENSATION |
人件費・報酬 | 役員報酬、賞与額 |
JPII_TRANSACTION |
取引・契約金額 | 取引金額、契約金額 |
JPII_ACCOUNT_IDENTIFIER |
口座・カード番号 | 口座番号1234567 |
JPII_FINANCIAL_AMOUNT |
金融金額（未分類） | 文脈から分類できなかった金額表現 |
| 文脈解析：認証情報・シークレット（6種） | ||
JPII_CRED_API_KEY |
APIキー | AWS Access Key、OpenAI APIキー |
JPII_CRED_ACCESS_TOKEN |
アクセストークン | Bearer Token、GitHubトークン |
JPII_CRED_PRIVATE_KEY |
秘密鍵 | PEM形式の秘密鍵 |
JPII_CRED_DATABASE |
データベース認証情報 | 接続文字列、DB接続パスワード |
JPII_CRED_CLOUD |
クラウド認証情報 | クラウドサービスのアクセスキー |
JPII_CRED_SECRET |
その他の認証情報 | パスワード、認証トークン |
| 文脈解析：人事労務情報（6種） | ||
JPII_HR_REVIEW |
人事評価 | 評価グレード、業績評価スコア |
JPII_HR_DISCIPLINARY |
懲戒情報 | 懲戒処分、厳重注意 |
JPII_HR_ATTENDANCE |
勤怠情報 | 出勤記録、残業時間 |
JPII_HR_LEAVE |
休職・医療情報 | 休職届、傷病手当 |
JPII_HR_PERSONNEL |
人事異動 | 異動辞令、昇進記録 |
JPII_HR_INFO |
その他の人事情報 | 分類されなかった人事関連情報 |
| 文脈解析：医療健康情報（6種） | ||
JPII_MED_DIAGNOSIS |
診断情報 | 診断名、ICD-10コード |
JPII_MED_TEST |
検査結果 | 血液検査値、血圧、HbA1c |
JPII_MED_PRESCRIPTION |
処方情報 | 処方薬名、投薬量 |
JPII_MED_INSURANCE |
保険情報 | 保険証番号、被保険者番号 |
JPII_MED_HISTORY |
病歴 | 既往歴、手術歴 |
JPII_MED_INFO |
その他の医療情報 | 分類されなかった医療関連情報 |
| 文脈解析：経営戦略情報（6種） | ||
JPII_STRAT_MA |
M&A情報 | 買収金額、合併条件 |
JPII_STRAT_EARNINGS |
業績予想 | 決算予想、収益見通し |
JPII_STRAT_BOARD |
取締役会決議 | 取締役会決定事項、役員人事 |
JPII_STRAT_PLAN |
戦略計画 | 中期経営計画、事業計画 |
JPII_STRAT_INSIDER |
インサイダー情報 | 非公開重要事実 |
JPII_STRAT_INFO |
その他の戦略情報 | 分類されなかった経営戦略関連情報 |
| 文脈解析：法務・契約情報（6種） | ||
JPII_LEGAL_CONTRACT |
契約情報 | 契約条項、契約番号 |
JPII_LEGAL_NDA |
秘密保持契約 | NDA条項、秘密保持義務 |
JPII_LEGAL_IP |
知的財産 | 特許契約、ライセンス条項 |
JPII_LEGAL_LITIGATION |
訴訟情報 | 訴訟内容、和解条件 |
JPII_LEGAL_PENALTY |
損害賠償・違約金 | 違約金条項、損害賠償額 |
JPII_LEGAL_INFO |
その他の法務情報 | 分類されなかった法務関連情報 |
| 文脈解析：社内識別子（6種） | ||
JPII_INTID_PROJECT |
プロジェクトID | 社内チケット番号、プロジェクトコード |
JPII_INTID_EMPLOYEE |
社員番号 | 従業員ID、社員コード |
JPII_INTID_CUSTOMER |
顧客番号 | 顧客コード、取引先番号 |
JPII_INTID_URL |
社内URL | イントラネットURL、内部システムURL |
JPII_INTID_DOC_REF |
文書参照番号 | 社内文書番号、稟議番号 |
JPII_INTID_INFO |
その他の社内識別子 | 分類されなかった社内識別子 |
7種の文脈解析パイプラインにより、同じテキストでも周辺文脈から金融PII・認証情報・人事労務・医療健康・経営戦略・法務契約・社内識別子を自動分類します。
カスタム検出器APIを使用して、業務固有のPIIタイプ（社員番号、顧客ID、プロジェクトコードなど）を追加することも可能です。
関連リソース
Qualiteg Blogで日本語PII検出に関する技術解説記事を公開しています。
お問い合わせ
PII-Fiの導入についてお気軽にご相談ください
デモAPIキー
デモ環境でAPIの動作を確認できます
技術相談
導入に関する技術的なご質問にお答えします