Langfuse を用いて生成 AI アプリ・エージェント を運用することにより Trace の可視化や分析、評価などを行うことができ、大変便利です（むしろやらないと管理が不可能ではとも思います）、一方で、ユーザーが入力する際に PII (個人情報:Personal Identifiable Information) が混入し、そのままトレースとして保存されてしまうことがセキュリティポリシー上で許容できないケースもあるかもしれません。
そこで私たち（GAO）は、Langfuse の mask フックに組み込める 4 つの PIIマスキング手法 を検証し、ブログ連載として公開しました。本記事では各エントリを素早く俯瞰できるよう要点をまとめます。
各アプローチのサマリ
| 観点 | llm‑guard OSS | Guardrails for Bedrock | Gemini 2.5 Flash-Lite | Sensitive Data Protection (Google Cloud) |
|---|---|---|---|---|
| 日本語精度の印象 | ★★☆☆☆ | ★★★☆☆ | ★★★★☆ | ★★★☆☆ |
| 対応 PII 種類 | 8+ | 31+ | プロンプト次第 | 150+ （マイナンバー等を含む） |
| インフラ依存 | なし | AWS 必須 | Google Cloud/ or Gemmini API | Google Cloud 必須 |
| コスト感 | サーバー実行のみ | API 従量課金 | 低コスト LLM | アノテーション課金 |
| 実装難易度 | 低 | 中 | 中 | 中 |
選定の目安
- すばやく PoC ⇒ llm‑guard
- AWS ワークロード ⇒ Guardrails for Bedrock
- 日本語精度 & 柔軟運用 ⇒ Gemini 2.5 Flash-Lite
- 100+ InfoType が欲しい / Google Cloud ワークロード ⇒ Sensitive Data Protection
1. llm‑guard でマスキング
- Python ライブラリ。
mask()をフックするだけで導入可能 - Langfuse 公式例として記載あり
- 正規表現＋ルールベースで 8 種ほどの PII を自動マスク
- 課題: 日本語住所・人名は検出漏れが多い ブログ記事
2. Guardrails for Amazon Bedrock
-
bedrock_runtime.apply_guardrailで LLM を使わず検査 - 日本語で対応も正式にGAしており安心で、AWSユーザーにとって使いやすい
- 31 種類以上の PII タイプを MASK / BLOCK モードで制御
- 課題: AWS 依存 & 日本固有 PII は手動追加が必要 ブログ記事
3. Gemini 2.5 Flash-Lite で LLM マスキング
- プロンプト調整のみでルール変更でき、非エンジニアでも運用◎
- 高速＆低コストで日本語精度も高い
- 課題: プロンプト制御なので過剰マスク／誤変換のリスクは残る ブログ記事
4. Google Cloud Sensitive Data Protection (旧 Cloud DLP)
- 150+ InfoType を ML + RegEx で検出。マイナンバー や日本電話番号も対応
- 以前からある機能で安心感もある
- delidentity_content で検出・置換
- 課題: Google cloud依存 ブログ記事
Langfuse へトレースを書くときの 実践 Tips
PII フィルター自体の呼び出しも 同一トレースに記録しておくと、
「誰がいつフィルターを通し、コストがいくら掛かったか」を後から監査できます。
ただし mask フック内で再帰的に Langfuse を呼ぶと 無限ループになるので注意が必要です。
こちらの記事で詳細はご確認ください。
まとめ
Langfuse の mask フックをうまく活用すれば、ツール差し替えが容易 です。
まずは 小規模データで精度とパフォーマンスを比較 → 本番では二段構えのフェイルオーバー（例：Google Cloud Sensitive Data Protection / Guardrails for Amazon Bedrock → 検出漏れ時に Gemini）という構成にすると、 日本語特有の PII も漏れなくキャッチしつつコストを抑えられます。
生成 AI の可観測性とプライバシー保護を両立し、安心して Langfuse を運用 しましょう