LLM活用における段階的PIIマスキング

LLM活用における段階的PIIマスキング

こんにちは、Qualitegプロダクト開発部です!

前回の技術解説では、「三沢」が人名なのか地名なのか判断できない日本語の曖昧性から始まり、正規表現からLLM統合まで5段階のPII検出アプローチをご紹介しました。今回は、これらの技術を搭載した LLM-Audit™ PII Protector が実際のLLM活用シーンでどのように動いているのか、実際のプロダクト処理の観点で、もう一歩踏み込んで解説します。

ファイルの中に潜む、見えないPII

LLM Audit™ PII Protectorをご紹介した際、多くの方から「テキスト入力のPII検出は分かったけど、ファイルをまるごとLLMに投げる場合はどうなるの?」というご質問をいただきました。

確かに現在のLLM活用は、単純なテキスト入力から、PowerPoint、Excel、PDF、画像ファイルなど、様々な形式のファイルを直接処理する段階に進化しています。「この提案書を要約して」「このExcelから傾向を分析して」といった使い方が当たり前になってきました。

PowerPointの「スピーカーノート」を見たことがありますか?

営業担当のAさんが、重要な提案書のレビューをLLMに依頼したとします。スライド本体は「当社のプロダクトについて」「ご提案内容」といった一般的な内容。一見、機密情報は含まれていないように見えます。

ところが、そのPowerPointファイルのスピーカーノートには

  • 「〇〇部長から内々に聞いた予算は3億円」
  • 「競合のB社は2.5億で提案予定との情報あり」
  • 「キーマンは企画部の山田氏(趣味:ゴルフ)」

といった、表には出せない生々しい情報が記載されていることがよくあります。

前回ご紹介した高度なPII検出技術は、まさにこういった「隠れた場所」にある日本語特有の機密表現を見つけ出すために開発されました。しかし、ファイル形式ごとに「どこを見るべきか」は大きく異なります。

今回は、日本企業でよく使われる各ファイル形式について、「ここが危ない」というポイントと、それに対する段階的な対策を具体的に解説していきます。

LLM活用における段階的PIIマスキングの実施

第1段階:リアルタイム入力チェック(全プロンプト対象)

LLMへの入力時に、超高速なスクリーニングを実施します。明確なパターン(電話番号、メールアドレス、マイナンバー等)を瞬時に検出し、LLMへの送信前に自動的にマスキングします。人名、会社名などやや複雑なパターンも高速で処理するため、ユーザーは遅延を感じることなく作業を継続できます。

例えば「田中太郎さん(090-1234-5678)から問い合わせ」という入力は、「[顧客A]さん([電話番号])から問い合わせ」に自動変換されます。

第2段階:文脈考慮型マスキング(ビジネス文書)

議事録、報告書、提案書などの構造化された文書をLLMで処理する際は、高度な言語処理技術を活用し、企業名、役職、金額などを高精度に識別します。「ABC(株)の山田部長より、X社との共同プロジェクトについて相談」のような文章では、企業名と個人名を適切に識別し、ビジネス文脈を保ちながら機密情報をマスクすることが可能です。

第3段階:セマンティックマスキング(機密文書)

契約書、財務報告書など、高度な機密性を持つ文書には、より高度な技術を使用します。文書の構造や意味的関係を理解した上で、LLMが必要とする情報の粒度を保ちながら、個人を特定できる情報を除去します。

第4段階:高度な分析への対応

専門的な分析タスクでは、用途に最適化したマスキングを実施します。必要な情報を保持しながら、機密情報のみを適切に保護する高度な処理を行います。

第5段階:継続的な改善

テスト用に作成した自社ドキュメント(実際の業務でやりとりしそうな内容を含むもの)を使って、システムの精度を検証し、継続的に改善します。マスキング漏れや過剰なマスキングを検出し、より実用的なシステムへと進化させています。

ファイル形式別PIIマスキング戦略

PowerPointファイルの多層的PII検出

PowerPointファイルは表面的には安全に見えても、実は多くの隠れた個人情報を含んでいます。

スライド本体以外の見落としがちな箇所

1. スピーカーノート

プレゼン時の話者用メモは、まさに「本音」の宝庫です。「田中部長から内々に聞いた予算は5000万円」といった、表には出せない重要情報が記載されていることがよくあります。

2. コメント・校閲履歴

レビュープロセスの痕跡が、そのまま組織構造を露呈します。実際のケースでは、コメント作成者として「営業企画部 山田太郎」、コメント内容に「この価格では赤字です。最低でも3000万は必要」といった情報が含まれ、部署名、個人名、価格戦略が一度に流出するリスクがあります。

3. 埋め込みオブジェクト

スライドに埋め込まれたExcelに、詳細な顧客リストが潜んでいることがよくあります。PowerPointファイル内部には埋め込みファイルが格納されており、これらも含めて包括的なPII検出を行う必要があります。

4. 画像内のテキスト

スクリーンショットに映り込んだ情報は、意外な盲点です。

  • Teamsの画面キャプチャに参加者リストの実名
  • システム画面のスクショにURLバーの内部システムアドレス
  • ホワイトボードの写真に手書きの電話番号やメールアドレス

5. マスター/レイアウト

全スライドに適用されるフッターに、気づかぬうちに個人情報が含まれていることがあります。

営業提案書の典型的なリスク分布:

  • スライド本体:低リスク(一般的な提案内容)
  • スピーカーノート:高リスク(人名、金額、戦略情報)
  • 埋め込みExcel:最高リスク(詳細な顧客データ)
  • コメント:中リスク(組織情報、内部議論)

Excel/スプレッドシートの深層PII検出

Excelファイルは構造化データの宝庫であり、個人情報の密度が最も高いファイル形式です。

日本企業のExcel特有のPII検出ポイント:

1. 列ヘッダーパターン認識

日本語特有のヘッダー(「氏名」「担当者」「連絡先」など)から、その列の性質を推定する技術が重要です。

2. 非表示領域の検査

  • 可視シート:集計結果のみ(一見安全)
  • 非表示シート「給与マスター」:全社員の給与データ
  • 非表示列:個人の携帯番号、緊急連絡先

3. 数式に潜む参照情報

VLOOKUP関数などで外部ファイルを参照している場合、その参照先に機密情報が含まれている可能性があります。

4. データ検証リスト

ドロップダウンリストの選択肢に、全社員の名前が設定されているケースは珍しくありません。

5. ピボットテーブルの元データ

集計表は匿名化されていても、元データには詳細な個人情報が含まれていることがあります。

PDFドキュメントの複合的PII検出

PDFは「完成された文書」というイメージから、最も油断されやすいファイル形式です。

PDF特有の隠れたPIIリスク

1. テキストレイヤーと画像レイヤーの二重構造

表面的にはスキャンされた画像でも、裏側にOCR処理されたテキストレイヤーが存在することがあります。両方をチェックしないと見逃すリスクがあります。

2. フォームフィールド

PDF内のフォームには、過去の入力履歴が残されていることがあり、申請者の氏名や部署情報が蓄積されている場合があります。

3. 注釈・コメント

Adobe Acrobatで追加されたコメントは、PDFリーダーによっては表示されないことがあり、見落としがちです。

4. メタデータ

作成者名、会社名、使用ソフトのライセンス情報など、文書のプロパティに個人情報が含まれています。

5. 添付ファイル

PDFには他のファイルを添付できます。契約書PDFに、交渉履歴のExcelが添付されているケースもあります。

画像ファイルの高度なPII検出

デジタルトランスフォーメーションの進展により、スクリーンショットや写真による情報共有が増加しています。

画像ファイルの典型的なPII漏洩パターン

1. 会議画面のキャプチャ

  • 参加者リスト:実名と所属組織
  • チャット欄:「田中さん、さっきの見積もり3000万でOKです」
  • 画面共有:機密資料が丸見え
  • 通知ポップアップ:プライベートメッセージ

2. ホワイトボード撮影

  • 印刷体の名前:比較的検出しやすい
  • 走り書きの電話番号:OCR精度が課題
  • 図の中の略称:文脈理解が必要

3. システム画面キャプチャ

  • ブラウザのタブ:個人のGmail、社内システム名
  • ファイルパス:ユーザー名を含むフォルダ構造
  • タスクバー:起動中のアプリから業務内容が推測可能

4. メタデータ

GPS情報から撮影場所(自宅や顧客先)が特定されるリスクがあります。

LLM時代のファイル処理ベストプラクティス

リスクベースの処理優先順位

すべてのファイルを同じレベルで処理するのは非効率です。当社のLLM-Audit™ PII Protectorでは、組織の特性に応じた設定により、ファイルのリスクレベルを適切に判定できます。

リスクレベル別の処理例

  • 最高リスク:人事フォルダの給与計算Excel → 詳細スキャン必須
  • 高リスク:最近更新された顧客リスト → 標準スキャン+確認
  • 中リスク:一般的な業務文書 → クイックスキャン
  • 低リスク:テンプレート、公開資料 → 最小限のチェック

処理速度とセキュリティのバランス

用途に応じて処理モードを選択可能にすることで、実用性を保ちながらセキュリティを確保します。

  • 高速モード(1秒以内):チャットボット応答、リアルタイム支援
  • 標準モード(5-10秒):文書要約、一般的な分析
  • セキュアモード(30秒程度):契約書分析、顧客データ処理
  • 最高セキュリティモード(1分以上):M&A文書、役員会資料

まとめ
~包括的なPII保護でLLMを安全に活用~

LLM時代において、単なるテキスト入力のPII検出だけでなく、PowerPoint、Excel、PDF、画像など、あらゆるファイル形式に対応した包括的なPIIマスキングが不可欠です。

重要なのは、各ファイル形式特有のリスクを理解し、適切なレベルで処理することです。前回ご紹介した技術的アプローチは、まさにこのような複雑な要求に応えるために設計されました。

日本企業の文書作成文化や情報共有の特性を深く理解した上で、実用的なソリューションを提供することが、LLMを安全に活用する鍵となります。


LLM-Audit ™のご紹介

Qualiteg では、LLMのセキュリティソリューション「LLM-Audit™」を開発・提供しております。
LLMがビジネス活用されるにつれ、LLMへの各種攻撃が活発化しています。
一方で、これまでのWebセキュリティとはまた異なったLLMへの攻撃についてはまだ知見も乏しく防衛手段も確立していません。

(株)Qualiteg では、LLMサービス開発・運営を通して得た経験・知見を集めた LLM防衛ソリューション 「LLM-Audit™」をご提供しています。


また、悪意ある入力プロンプトのブロック、LLMによる不適切な出力の監査を強力に実行しLLMの安全、安心を実現することができます。

OpenAI API 互換サーバーとして貴社LLMをラッピングするだけで利用できますので非常に小さな導入コストで高度化したLLMセキュリティを実現することが可能です。

LLMセキュリティやLLM-Audit™ にご関心がおありの場合は以下までご連絡くださいませ。またLLMセキュリティコンサルティングや製品デモについてもどうぞお気軽にこちらのお問い合わせフォームまでご連絡くださいませ。

Read more

楽観的ロック vs 悲観的ロック:実際のトラブルから学ぶ排他制御

楽観的ロック vs 悲観的ロック:実際のトラブルから学ぶ排他制御

こんにちは! Qualitegプロダクト開発部です! 「楽観的ロックを実装したのに、まだ競合エラーが出るんですけど...」 これは私たちが実際に経験したことです。 本記事では、楽観的ロックと悲観的ロックの違いを、実際に発生したトラブルを通じて解説します。 抽象的な説明ではなく、 「なぜそれが必要なのか」「どんな問題を解決できるのか」 を実感できる内容を目指します。 目次 1. 問題の背景:並列処理で謎のエラー 2. ロックなしの世界:なぜ競合が起きるのか 3. 楽観的ロックの導入:期待と現実 4. 楽観的ロックの限界:解決できなかった問題 5. 悲観的ロックによる解決 6. 実装時のハマりポイント 7. どちらを選ぶべきか:判断基準 8. まとめ 1. 問題の背景:並列処理で謎のエラー 1.1 システムの概要 私たちが開発していたのは、 複数のワークスペースを切り替えて使用するAPIサーバー でした。 当社AI関係のプロダクトの一部だったのですが、結合テスト兼負荷テストを実行すると、まれに発生してしまっていました。 ユーザーは複数のワーキン

By Qualiteg プロダクト開発部
企業セキュリティはなぜ複雑になったのか? 〜AD+Proxyの時代から現代のクラウド対応まで〜

企業セキュリティはなぜ複雑になったのか? 〜AD+Proxyの時代から現代のクラウド対応まで〜

こんにちは! ChatGPTやClaudeといった生成AIサービスが業務に浸透し始めた今、 「AIに機密情報を送ってしまうリスク」 が新たなセキュリティ課題として浮上しています。 この課題に向き合う中で、私たちは改めて「企業のセキュリティアーキテクチャはどう変遷してきたのか」を振り返る機会がありました。 すると、ある疑問が浮かんできます。 「なんでこんなに複雑になってるんだっけ?」 企業のセキュリティ担当者なら、一度は思ったことがあるのではないでしょうか。 アルファベット3〜4文字の製品が乱立し、それぞれが微妙に重複した機能を持ち、設定は複雑化し、コストは膨らみ続けています。 当社ではAIセキュリティ関連プロダクトをご提供しておりますが、AI時代のセキュリティを考える上でも、この歴史を理解することは重要ではないかと考えました。 本記事では、企業ネットワークセキュリティの変遷を振り返りながら、「なぜこうなったのか」を整理してみたいと思います。 第1章:観測点を集約できた時代 ― オンプレAD + Proxy(〜2010年代前半) 統制しやすかったモデル かつ

By Qualiteg コンサルティング, Qualiteg AIセキュリティチーム
【IT温故知新】WS-* の栄光と黄昏:エンタープライズITはいかにして「実装」に敗北したか

【IT温故知新】WS-* の栄光と黄昏:エンタープライズITはいかにして「実装」に敗北したか

こんにちは。 —— 2003年のSOAから、2026年のAIへ —— この記事は、過去の技術動向を振り返り、そこから学べる教訓について考察してみたものです。 歴史は常に、後から見れば明らかなことが、当時は見えなかったという教訓を与えてくれます。 そして、今私たちが「正しい」と信じていることもまた、20年後には違う評価を受けているかもしれません。 だからこそ、振り返ることには意味があるとおもいます。同じ轍を踏まないために。 はじめに:20年前の熱狂を覚えていますか 2000年代初頭。 私はSOA(サービス指向アーキテクチャ)に本気で取り組んでいました。 当時、SOAは「次世代のエンタープライズアーキテクチャ」として、業界全体が熱狂していました。 カンファレンスに行けば満員御礼、ベンダーのブースには人だかり、書店にも関連の書籍がちらほらと。 SOAP、SOAP with attachments、JAX-RPC、WS-Security、WS-ReliableMessaging、WS-AtomicTransaction... 仕様書の山と格闘する日々でした。 あれから

By Qualiteg コンサルティング
DockerビルドでPythonをソースからビルドするとGCCがSegmentation faultする話

DockerビルドでPythonをソースからビルドするとGCCがSegmentation faultする話

こんにちは!Qualitegプロダクト開発部です! 本日は Docker環境でPythonをソースからビルドした際に発生した、GCCの内部コンパイラエラー(Segmentation fault) について共有します。 一見すると「リソース不足」や「Docker特有の問題」に見えますが、実際には PGO(Profile Guided Optimization)とLTO(Link Time Optimization)を同時に有効にした場合に、GCC自身がクラッシュするケースでした。 ただ、今回はDockerによって問題が隠れやすいという点もきづいたので、あえてDockerを織り交ぜた構成でのPythonソースビルドとGCCクラッシュについて実際に発生した題材をもとに共有させていただこうとおもいます 同様の構成でビルドしている方の参考になれば幸いです TL;DR * Docker内でPythonを --enable-optimizations --with-lto 付きでソースビルドすると GCCが internal compiler error(Segmentati

By Qualiteg プロダクト開発部