文字起こしログの個人情報マスキング：ローカルLLM（Strands Agents × Ollama）による検証結果
本記事は、音声認識（ASR）によって生成された文字起こしログに含まれる個人情報（PII）を、従来のシステムでは対応が難しかった「崩れた表記」のデータから抽出・マスキングする技術的な検証記録である。特に、電話番号や会員番号などが「103、1」といった形で分割されているケースに対応することを目的としている。
筆者は、高性能なクラウドAPIではなく、ローカルLLM（Large Language Model）を活用するため、「Strands Agents」と「Ollama」を組み合わせた構成を採用した。モデルには日本語性能が高く、かつサイズダウンによるスコア劣化が少ないQwen3.5シリーズ（9Bおよび4B）を選定し、検証を行った。
設計上の工夫として、LLMに本文の生成や置換を行わせるのではなく、「個人情報の列挙」と「残すべき情報がないかのチェック」のみをさせ、実際のマスキング処理はPythonコード側で決定的に行うというアプローチを取った。これにより、原文の改変リスクを排除した。
検証の結果、まず9Bモデルを用いた場合、従来のPresidioなどでは取りこぼしが多かった6件（電話番号、会員番号、マイナンバーなど）すべてをLLMの文脈推論能力によって検出することに成功した。また、過剰なマスク処理を防ぐための「監査ループ」も機能し、合格ライン9/9、過剰マスク3/3という高い精度を示した。
次に本番環境に近い4Bモデルへ落とし込んだところ、当初は2件のリグレッション（取りこぼし・過剰検出）が見られたが、監査プロンプトに「金額はPIIではない」という除外の念押しと、「末尾の電話番号も報告する」というFew-shot例を追記しただけで、9Bと同等の性能（9/9・3/3）を取り戻すことに成功した。さらに、4Bモデルは生成速度が9Bモデルより約1.6倍速く、パイプライン全体で処理時間が大幅に短縮され、実用的な手応えが得られた。
背景
音声認識（ASR）ログは、話し言葉の特性上、正規表現や固有表現抽出（NER）が想定するクリーンな形式を保ちにくい。特に電話番号や会員番号などが「103、1」のように分割される場合、従来のデータマスキング技術では個人情報として検出することが困難であったため、LLMによる文脈推論能力の活用が求められた。
重要用語解説
- ASRログ: Automatic Speech Recognition（自動音声認識）によって生成された文字起こしテキスト。話し言葉特有の表記崩れや分割が含まれるのが特徴。
- ローカルLLM: 大規模言語モデルをクラウドAPI経由ではなく、自前のサーバー環境（ローカル）で動作させる仕組み。コスト削減とデータプライバシー保護に優れる。
- Strands Agents: AWSが提供するエージェント開発用SDK。少ないコード量で複雑なAIワークフローやツール呼び出しの管理を行うためのフレームワーク。
今後の影響
本技術は、音声データを扱うあらゆるサービス（コールセンターログ分析、議事録作成など）における個人情報保護対策を飛躍的に向上させる。特にローカルLLMを用いることで、機密性の高いデータも外部APIに送信することなくマスキング処理が可能となり、企業の実装障壁を下げる重要な知見となる。