テキストのメール・電話番号・カード番号をマスキング
文章がログや問い合わせ票に渡る前に、メール、電話番号、カード番号らしい数字列を伏せます。例では、メール2件、電話1件、カード1件が[EMAIL_1]、[EMAIL_2]、[PHONE_1]、[CREDIT_CARD_1]になり、合計は4件です。ブラウザで無料で使えます。
- 無料
- ブラウザで動作
- 登録不要
- データは端末の外に出ません
無料で実行
文章がログ、問い合わせ票、分析処理、共有文書へ渡る前に、一般的な個人情報のパターンを伏せます。この決定的なツールは、メールアドレス、よく使われる形式の電話番号、13~19桁のカード番号らしい数字列を検出します。各箇所は [EMAIL_1]、[PHONE_1]、[CREDIT_CARD_1] のような連番付きラベルに置き換えられます。処理済みの文章と分類別の件数だけを返し、外部サービスへの接続、本人の推定、送信文の保存は行いません。
文章が広がる前に一般的な識別情報を伏せます
業務上の文章は、作成者が想定する以上に多くのシステムを通ることがあります。サポートメッセージが問い合わせ票へコピーされ、検索用に索引化され、分析イベントへ含まれ、さらにチームの会話へ貼り付けられる場合があります。最初のやり取りでは必要だったメールアドレスや電話番号も、その後のすべての場所では不要な漏えい要因になり得ます。
この機能は、文章が移動する前に予測可能な整形工程を追加します。文章を1つ送ると、認識されたパターンが連番付きラベルへ置き換えられた同じ内容が返ります。連番によって構造も保たれます。
同じ分類の複数箇所を区別でき、実際の値を見ずに異なるメールが2件あったことを把握できます。分類別件数も返すため、機密値を出力せずに品質確認ができます。アルゴリズムは決定的でネットワークを使わないため、同じ入力には常に同じ結果を返します。
ログ、メッセージ、書き出したメモ、テストデータなど、迅速で説明可能なマスキングが必要な平文の前処理に適しています。
検出対象を正確に把握できます
検出器は実用的な3種類のパターンを対象にします。メールには一般的なローカル部、アットマーク、ドットを含むドメインが必要です。電話番号は、空白、ピリオド、ハイフン、括弧を使う一般的な国内・国際表記を認識します。
カード番号らしい候補は13~19桁で、途中に空白やハイフンを含められます。ここで「カード番号らしい」とするのは意図的です。発行会社への照会やチェックサム検証は行わないため、口座番号など別の長い数字列も伏せることがあります。
照合は順序付きの1回の走査で行い、長い数字列の一部が電話番号として置換されたり、挿入済みラベルが再検査されたりすることを防ぎます。氏名、住所、公的識別番号、生年月日、IPアドレス、文脈でのみ分かる秘密は検出しません。また、現実に使われるすべての表記を認識できる保証もありません。
出力は特定パターンを減らす手段であり、匿名化の証明や公開可能性の保証ではありません。
自動処理で出力を安全に利用します
マスキングは可能な限り早い段階、できれば信頼できない文章をアプリケーションが永続ログへ書く前、または別の処理へ送る前に配置してください。合計が0でも、対応パターンが見つからなかったという意味にすぎず、個人情報が存在しない証明にはなりません。
より強い保証が必要な場合は、この決定的な処理に、業務固有の検証、アクセス制御、保存期間の制限、別工程での確認を組み合わせてください。処理済み文章との比較だけを目的に原文を保存すると、マスキングの目的を損なうおそれがあります。連番付きラベルは問い合わせ票や報告書でも読みやすい一方、元に戻せるトークンではなく、復元情報を含みません。
空または空白だけの入力は無効として拒否されます。地域ごとの電話表記や特殊なメール構文は異なるため、実際の入力に近い例で確認してください。
活用例
アプリケーションログを整えます
メッセージが集中ログ・検索システムへ入る前に、連絡先や支払い番号の一般的なパターンを伏せます。
サポート履歴を共有用にします
研修や調査で問い合わせの抜粋を共有する前に、メール、電話、カード番号らしい値を取り除きます。
開発用データを安全にします
実環境に近い文章を、置換位置と分類を残したまま、より安全なテスト素材へ変換します。
よくある質問
どのパターンが伏せられますか?
一般的なメールアドレス、よく使われる形式の電話番号、空白やハイフンを任意で含む13~19桁の数字列が対象です。
カード番号が有効か確認しますか?
いいえ。 発行会社への照会やチェックサム検証は行わず、長い数字列をカード番号らしい候補として優先的に伏せます。
検出が0なら個人情報はないと判断できますか?
いいえ。 氏名、住所、地域固有の形式、文脈依存の識別子、未対応パターンが残る場合があります。完全な非識別化には追加対策が必要です。
ラベルから元の値を復元できますか?
できません。 ラベルが保持するのは分類と出現順だけで、検出値へ戻す対応表は結果に含まれません。
ラベルがすべて同じではなく番号付きなのはなぜですか?
文章の構造を残すためです。同じ種類が何度出ても区別でき、確認する人は中身を見ずに別々のメールが2つあったと分かります。種類ごとの合計で、値を見せずに品質も確かめられます。
関連ツール
開発者向け — APIアクセス
このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。
エンドポイント
Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。
お使いのスタックから呼び出す
curl -X POST https://api.kit.forhosting.com/data/remove-pii-patterns \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"Email alex@example.com, call +1 (415) 555-0198, or reference card 4111 1111 1111 1111."}'const res = await fetch("https://api.kit.forhosting.com/data/remove-pii-patterns", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "Email alex@example.com, call +1 (415) 555-0198, or reference card 4111 1111 1111 1111."
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/data/remove-pii-patterns",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "Email alex@example.com, call +1 (415) 555-0198, or reference card 4111 1111 1111 1111."
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/data/remove-pii-patterns", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"Email alex@example.com, call +1 (415) 555-0198, or reference card 4111 1111 1111 1111."}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"Email alex@example.com, call +1 (415) 555-0198, or reference card 4111 1111 1111 1111."}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/data/remove-pii-patterns", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)リクエスト例
{
"text": "Email alex@example.com, call +1 (415) 555-0198, or reference card 4111 1111 1111 1111."
}レスポンス例
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "data.remove_pii_patterns",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。
料金
単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。
制限
max_mb | 25 |
エラー
| HTTP | コード | 意味 |
|---|---|---|
401 | unauthorized | APIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。 |
402 | insufficient_balance | 残高が不足しています。チャージ後に再度お試しください。 |
404 | unknown_type | 指定されたタスクタイプは存在しません。タイプ名を確認してください。 |
429 | rate_limited | リクエストが多すぎます。しばらく待ってから再度お試しください。 |
技術的な注記
自動処理で出力を安全に利用します
変換済み文書は redacted_text、簡潔な監査指標は counts で確認できます。APIによる自動処理は文章1件につき $0.002 で、ブラウザー版では同じ純粋なロジックをローカル実行できます。
技術的な質問
入力が空の場合はどうなりますか?
空または空白だけの文章には、誤解を招く空の変換結果ではなく invalid_input エラーを返します。
APIリクエストの料金はいくらですか?
文章1件につき $0.002 です。ブラウザー実行では同じ決定的なロジックをローカルで使用します。