LLMに渡す前にPIIを外す｜マスキング処理をパイプラインとして設計する

問い合わせメールの要約、社内チケットの分類、通話メモの整形。業務でLLMを使おうとすると、扱いたいテキストにはたいてい人の名前と連絡先が入っています。「個人情報は入れない」と社内ルールに書くところまでは多くの組織がやりますが、次に来るのは「では入っているものをどう外すのか」という実装の問題です。人が毎回消すのは続きませんし、消し忘れは必ず起きます。そこで、LLMに渡す前に個人情報(PII)を機械的に落とす処理をパイプラインとして組み込むことになります。この記事では、その設計で必ずぶつかる判断ポイントを、できること・できないこと・向かない場面に分けて整理します。

この記事の守備範囲#

このサイトには近いテーマの記事が三本あります。「そもそも何を入力してよいか」という線引きと社内運用については

、「閲覧権限を検索側にどう持ち込むか」については

あわせて読みたい

RAGのアクセス制御設計｜社内文書の閲覧権限をベクトル検索にどう持ち込むか

、「入力・出力・挙動の3層でどう検査するか」というアーキテクチャについては

あわせて読みたい

LLMガードレールの設計｜入力・出力・挙動の3層で安全境界をつくる実務ガイド

で扱っています。

この記事はそのどれとも違い、「入力テキストからPIIを機械的に外す処理そのものをどう作るか」に主題を絞ります。つまり、ルールで「顧客名は入れない」と決めたあとに残る、実装側の設計判断だけを扱います。

どこで落とすか:3つの配置#

最初の分岐は、マスキング処理をシステムのどこに置くかです。選択肢は大きく3つあり、守れる範囲と抜け道がそれぞれ違います。

クライアント側で落とす#

ブラウザ拡張やデスクトップアプリの中で、送信ボタンを押した時点でPIIを置換します。ネットワークに出る前に落とせるため、自社のサーバにすら生データが渡らないのが最大の利点です。個人向けプランのチャットUIを社員が使っている、という現実に対しては、ここでしか手を打てない場面もあります。

抜け道は、端末ごとに実装が分散することです。検出ルールを更新しても行き渡るまで時間がかかり、更新されていない端末が残ります。利用者が拡張を無効化する、別ブラウザを使う、APIを直接叩くといった迂回も容易です。加えて、検出用の辞書(役員名簿や顧客名リストなど)を端末に配布する設計にすると、辞書そのものが持ち出される新しいリスクを作ります。

APIゲートウェイ・プロキシ側で落とす#

社内のすべてのLLM呼び出しを1つのゲートウェイ経由に寄せ、そこでマスキングを強制します。アプリの実装漏れに関係なく一律に適用でき、何が送信されたかの監査も一箇所に集まります。統制の観点では最も筋のよい配置です。

抜け道は3つあります。第一に、ゲートウェイを経由しない呼び出しです。開発者がSDKで直接エンドポイントを叩けば素通りしますし、社員がWebのチャットUIを使えばそもそも通りません。ネットワーク側で外向きの直接通信を塞ぐ、といった別の統制とセットにしないと形骸化します。第二に、ゲートウェイに全社の平文が集まるため、そこ自体が新しい集約リスクになります。第三に、ゲートウェイは業務文脈を知らないため、どこまで消してよいかの判断が保守的になりがちで、過剰マスクが起きやすくなります。ストリーミング応答に対してプレースホルダを戻す処理も、チャンク境界をまたぐ関係で実装が面倒になります。

アプリケーション側で落とす#

個々のアプリのコードで、LLMに渡す直前に処理します。そのアプリが扱うデータの構造と業務要件を知っているので、精度を上げやすく、「この項目は残さないと機能が成立しない」という調整も入れられます。

抜け道は、実装がアプリごとにばらつくことと、新しいアプリで実装が漏れることです。既存アプリでも、リファクタリングの際にマスキングを通さない経路が生まれる、といった回帰が起きます。加えて、アプリ内では生データを保持したままなので、アプリのログに生データが出やすいという別の問題を抱えます。

検出手法の使い分け#

検出には大きく3つのアプローチがあります。実務ではどれか1つを選ぶのではなく、対象の種類ごとに使い分けます。

正規表現・辞書#

書式が決まっているものに強い手法です。メールアドレス、郵便番号、クレジットカード番号(桁数に加えてチェックディジットで確度を上げられる)、社内で採番規則が決まっている社員番号や会員IDなどが該当します。判定根拠が明示的なので、なぜ消したか・なぜ消さなかったかを説明でき、監査にも耐えます。辞書は、役員名・取引先名のような「絶対に外したい固有名詞の有限リスト」がある場合に有効です。

弱点は、書式が揺れるものに追従できないことです。電話番号は市外局番の桁数が可変で、ハイフンあり・なし・括弧付き・全角・国番号付きが混在します。桁数だけで拾おうとすると、注文番号や金額を電話番号と誤検知します。

固有表現抽出(NER)モデル#

文脈から人名・組織名・地名などを推定する手法です。書式で表現できない氏名や住所には、これしか手がありません。オープンソースのPII検出フレームワークであるPresidioも、NERに加えて正規表現・ルールベースのロジック・チェックサム・文脈情報を組み合わせて認識する構成を取っています。

弱点は、辞書やモデルの学習範囲を外れた表記に弱いこと、そして誤検知の理由を説明しにくいことです。稀な姓、ひらがな表記の氏名、社名の一部が人名と重なるケースなどで崩れます。

Presidioの公式リポジトリには「because it is using automated detection mechanisms, there is no guarantee that Presidio will find all sensitive information」と明記されています。自動検出は取りこぼす前提で設計する、という点はツール提供側自身が述べていることです。なお同プロジェクトはMicrosoft配下からdata-privacy-stackへ移管され、リポジトリとドキュメントのURLが変わっています(2026年9月4日時点でmicrosoft/presidioは新URLへリダイレクトされます)。

LLM自身に検出させる#

「この文章に含まれる個人情報を抽出して」とLLMに問い合わせる方式です。文脈依存の判断(「この数字は電話番号ではなく注文番号」など)や、想定していなかった種類の機微情報を拾える点が利点です。

ただし、PIIを外す目的でPII入りの原文を外部LLMに送るのは、目的と手段が矛盾します。この方式を採るなら、検出用のモデルは自社環境内で動かす(ローカルLLMや自社テナント内のデプロイ)ことが前提になります。加えて、出力が毎回同じとは限らず、監査の際に「なぜこの箇所が残ったのか」を再現できない問題もあります。

再現率と適合率、業務影響の非対称性#

3手法に共通するのが、取りこぼし(再現率の低下)と過剰マスク(適合率の低下)のトレードオフです。重要なのは、この2つが業務に与える影響がまったく非対称だという点です。

• 取りこぼしは、外部にPIIがそのまま送られる事故になります。取り消せません。
• 過剰マスクは、回答品質が落ちる形で現れます。取引先の社名まで消えれば要約は使い物になりませんし、地名が消えれば配送に関する問い合わせは処理できません。

そして過剰マスクには、もう一段先の副作用があります。使えないと感じた利用者は、社内の仕組みを迂回して手元のチャットUIに原文を貼るようになります。安全側に倒しすぎた設計が、結果としてシャドーITを生んで最も危険な状態を作る、という逆転が起きます。

Presidioの評価ドキュメントは、PII検出では再現率が適合率より重視される場面が多いとして、再現率に重みを置いたFβスコア(β=2)の利用を挙げています。ただしこれは指標選びの一般論であり、どこに閾値を置くかは扱うデータと業務要件で決める必要があります。

「取りこぼしが怖くて検出を厳しくしたら、問い合わせ本文の商品名や店舗名まで軒並み伏せ字になってしまい、要約から状況がまったく読み取れなくなりました。安全にはなったのですが、誰も使わない機能になりました。」

日本語特有の難しさ#

日本語のテキストからPIIを外す作業は、英語よりはっきり難しい部分があります。設計時に見積もりを外しやすいポイントを挙げます。

氏名#

同じ人物が、漢字・ひらがな・カタカナ・ローマ字・旧字体で書かれます。敬称も「様」「さん」「氏」「殿」が混ざり、姓だけ・名だけの言及もあります。さらに日本語は分かち書きをしないため、どこからどこまでが名前かの境界判定自体が難しく、形態素解析やトークナイザの結果に検出精度が引きずられます。地名や一般名詞と同じ表記の姓(福島、本田、青木など)は、辞書でもNERでも判断が割れます。

住所#

住所は粒度の選択が必要です。都道府県まで残すのか、市区町村まで残すのか、丁目番地から消すのか。全部消すと配送や地域別集計の業務が成立せず、残しすぎると番地とビル名・部屋番号で世帯が特定できます。表記も、住居表示の「1丁目2番3号」、省略形の「1-2-3」、漢数字の「一丁目二番三号」、地番系の「2番地」が混在し、ビル名・階数・部屋番号は書式が決まっていません。さらに「駅前の本社ビル」「北関東の主力工場」のような間接的な言及は、書式マッチでは一切拾えません。

準識別子#

単体では個人を特定しないが、組み合わせると特定できてしまう情報群です。所属部署、役職、入社時期、性別、年齢、担当地域、契約プラン、来店日時など。これらは業務上ほぼ必ず残したい情報で、機械的なマスキング処理の対象にしにくい一方、再識別の主要因になります。

マイナンバーは「マスクして送る」対象ではない#

この表の中でマイナンバー(個人番号)だけは、扱いの性質が他と違います。個人番号を含む個人情報は特定個人情報と呼ばれ、番号法(行政手続における特定の個人を識別するための番号の利用等に関する法律)による上乗せの保護措置がかかります。個人情報保護委員会の「特定個人情報の適正な取扱いに関するガイドライン(事業者編)」は、特定個人情報の提供制限(番号法19条)について「何人も、番号法で限定的に明記された場合を除き、特定個人情報を『提供』してはならない」と述べ、提供を求められた場合も番号法19条各号に該当するかをよく確認し、該当しなければ提供してはならないとしています。本人の同意があれば提供できる、という一般の個人データの発想がそのままは通じない領域です。

そのため設計上の分岐は「うまくマスクして送れるか」ではなく、「その処理を外部LLMに投げないで済ませるか」に置いてください。検出ロジックは、消すためというより、その経路に個人番号が流れ込んでいること自体を検知して止めるために持ちます。

プレースホルダ方式と復元#

外し方には、大きく分けて可逆と不可逆があります。

プレースホルダに置換する#

氏名を[PERSON_1]、住所を[ADDRESS_1]のように、型と連番を持つトークンに置き換える方式です。単に伏せ字にするより優れている点が2つあります。1つは、文の構造が保たれるためモデルが文意を読みやすいこと。もう1つは、同じエンティティに同じトークンを割り当てれば、「AさんがBさんに依頼した」という関係が壊れずに残ることです。要約や関係抽出のようなタスクでは、この整合性が結果の質を大きく左右します。

一方で、トークン自体が情報を漏らす場合があります。[PERSON_1]から[PERSON_37]まで並んでいれば、その文書に何人が登場するかは分かります。型を細かくしすぎると(たとえば[DISEASE_NAME_1]のような型)、型名そのものが機微な文脈を示唆します。

応答を受け取ってから戻す(リハイドレーション)#

LLMの応答に含まれるトークンを、保持しておいたマッピング表で元の値に戻します。ここで実務的にはまるのは、モデルがトークンを素直に維持してくれないことです。[PERSON_1]を「Person 1」「人物1」「PERSON1」と書き換えられると、単純な文字列置換では戻せません。復元漏れのトークンがそのまま利用者に見えるだけならまだ被害は小さいのですが、複数のプレースホルダが混同されて別人の名前に復元されるのは実害のある事故です。

不可逆にする(削除・ハッシュ)#

復元が不要なら、削除するかハッシュ化します。Presidioのanonymizerも、置換(replace)、削除(redact)、文字マスク(mask)、ソルト付きハッシュ(hash)、暗号化(encrypt)、任意の関数の結果で置き換えるcustomといった操作を用途別に持ちますが、組み込みのDeanonymizer(復元用の操作)として用意されているのは、暗号化を戻すdecryptだけです。customで独自の可逆変換を組むことは可能でも、戻す側は自前で用意することになります。

ハッシュ化には注意が要ります。電話番号やメールアドレスのように値の空間が狭いものは、ソルトなしのハッシュだと総当たりで元の値を復元できてしまいます。かといって呼び出しごとに違うソルトを使えば、同じ人が同じハッシュにならず、名寄せや重複排除といった「ハッシュ化する目的」が失われます。固定ソルトを使う場合、そのソルトは復元の鍵と同じ重さで管理する必要があります。

マッピング表が新しい機微情報になる#

可逆方式を選んだ時点で、「トークンと実データの対応表」というデータが生まれます。これは元データの中から個人識別性の高い部分だけを抜き出した縮約版であり、元データと同等かそれ以上に機微です。ここを軽く扱うと、入口を塞いだつもりが横に穴を開けたことになります。

個人情報保護委員会のガイドライン(仮名加工情報・匿名加工情報編)でも、仮名加工情報については削除した記述や加工方法に関する情報(削除情報等)の安全管理措置が求められ、匿名加工情報については加工方法等情報の安全管理措置が義務とされています。対応表を厳重に扱うという考え方は、法制度の側でも明確に置かれています。

マスキングが向かない業務#

正直に書いておくと、PIIを外すと成立しなくなる業務は確実に存在します。無理にマスキングを適用するより、その業務ではLLMに外部送信しない設計(自社環境内で完結させる、そもそもLLMを使わない)を選ぶほうが早い場面があります。

• 宛名や個別文面の生成。顧客名を伏せた状態では目的そのものが果たせません。復元前提のプレースホルダで回避できる場合もありますが、復元失敗が誤送信に直結します。
• 住所の正規化・名寄せ・突合。突合したい値そのものを消してしまうと処理が成り立ちません。
• 本人確認・与信・資格判定のように、個人の識別が業務の中身である処理。
• 医療・福祉・人事の記録要約で、年齢・既往・経歴といった情報を落とすと文書の意味が失われるもの。
• 発言者の帰属が重要な議事録や通話ログ。整合性のあるプレースホルダである程度は救えますが、社外の参加者と社内の参加者の区別が消えると使えません。

マイナンバーを含む書類の処理も、この「向かない」側に置くのが無難です。前述のとおり特定個人情報は番号法で限定列挙された場合を除き提供が禁止されるため、マスキングの精度を上げて外部に送る方向ではなく、その業務では外部LLMを使わない、あるいは個人番号を含む項目が入ってこない前段で処理を分ける、といった設計にしてください。

入口を塞いでも横から漏れる#

マスキングの設計で最も見落とされるのが、二次的な流出経路です。LLMへのリクエストボディだけを綺麗にしても、同じ生データが別の場所に残っていれば意味が薄れます。

アプリケーションログ#

デバッグ目的でリクエストとレスポンスをそのまま出力している箇所が、たいてい1つは残っています。マスキング処理の入力側をログに出していたら、ログ基盤が生PIIの倉庫になります。

トレース・オブザーバビリティ基盤#

LLMアプリのトレースは、プロンプトと応答の中身が見えてこそ価値があるため、設計上どうしてもPIIと相性が悪くなります。OpenTelemetryのGenAI向けセマンティック規約では、メッセージ内容を持つ属性(gen_ai.input.messages、gen_ai.output.messages、gen_ai.system_instructionsなど)の要求レベルをOpt-Inとし、計装は既定ではこれらを取得すべきでなく、利用者がオプトインできる手段を提供すべきだとしています。同ドキュメントは別の属性の注記で、明示的なオプトインの例としてOTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENTという環境変数名を挙げています。属性の注記でも、gen_ai.input.messagesとgen_ai.output.messagesには「This attribute is likely to contain sensitive information including user/PII data.」と書かれています(gen_ai.system_instructionsは「This attribute may contain sensitive information.」と、やや弱い文面です)。なお、これらの属性はいずれも現時点ではDevelopment(開発中)ステータスで、仕様は今後動きうる前提で読んでください。

規約がそうなっていても、実際に使う自動計装ライブラリやSaaSのSDKが既定でどう振る舞うかは別問題です。導入時に、送信されるスパンの中身を自分の目で確認してください。トレース側にマスキングフックを持つ製品もあり、たとえばLangfuseはSDKにmask関数を渡して、観測データの入力・出力・メタデータを送信前に変換する仕組みを提供しています。

あわせて読みたい

LLMアプリのオブザーバビリティ｜トレーシングとログ設計で「なぜこの出力になったか」を後から追えるようにする

プロンプトキャッシュとセマンティックキャッシュ#

コスト削減のために導入したキャッシュに、平文のプロンプトがそのまま残っている構成はよくあります。自前のセマンティックキャッシュを持つ場合、キャッシュキーの元になる埋め込みベクトルと本文の保存場所も含めて、保持期間とアクセス制御の対象に入れる必要があります。

評価用データセット#

本番トラフィックからサンプリングして評価セットを作る運用は品質改善に有効ですが、そのデータがリポジトリにコミットされたり、評価用の外部サービスに送られたりする経路が生まれます。評価セットは「長く残る」「多くの人が触る」という性質があるため、本番リクエスト以上に厳しく扱うべき対象です。

エラー通知とサポート経路#

例外監視サービスにリクエストペイロードが添付される設定、障害調査のためにログをチャットに貼る運用、ベンダーサポートへの問い合わせに実データを添付する行為。いずれも技術的な対策の外側で起きるため、手順書とレビューで抑える領域です。

会話履歴を保持するサーバ側機能#

ステートフルな会話機能を使うと、その場のリクエストを投げているだけのつもりでも履歴が保存されます。そして、どこに何日残るかは、同じ名前の機能でも提供形態によって変わります。

Microsoftの公式ドキュメントでは、Responses APIやAssistants APIのスレッド、保存済み完了(stored completions)といった機能について、サービスがデータストアを作成してメッセージ履歴などを保持すると記載されています。同じドキュメントによれば、この保存先は顧客のAzureテナント内のFoundryリソース(リソースと同一のgeography)で、既定でMicrosoftのAES-256により保存時に暗号化され、顧客がいつでも削除できるとされています(プレビュー段階のモデルや機能はこれらの条件をすべて満たさない場合がある、との注記も付いています)。ただしこれはAzure AI Foundryで提供される場合の整理であり、そのまま他の提供形態には持ち込めません。

一方、OpenAI自社プラットフォームのドキュメントは、これとは違う整理になっています。Responses APIについては、記載された例外を除き、既定で、またはstoreパラメータをtrueにした場合に30日のApplication State保持期間があり、その場合データは少なくとも30日保存されると説明されています。さらにエンドポイント別の表では、/v1/conversationsと/v1/assistantsのApplication State保持が「Until deleted」(利用者が削除するまで)、ゼロデータ保持の対象可否(Zero Data Retention eligible)が「No」と記載されています。つまり、削除しない限り会話オブジェクトは残り続け、ゼロデータ保持の設定でも消せません。

ステートレスに使っているつもりでも、機能の選び方次第で保存が発生し、保持期間とアクセス制御を考える対象が1つ増えます。マスキングの設計に入る前に、自分が使う経路について「保存先はどこか」「既定の保持期間は何日か」「削除の責任は誰にあるか」をドキュメントで確認してください。

再識別リスクと、法制度上の位置づけ#

マスキングを通したテキストが、法的な意味で「個人情報ではなくなった」とは限りません。ここは技術と法制度の理解がずれやすいところです。

最初の分岐:そもそも「提供」にあたるのか#

マスキングの精度を議論する前に、実務では手前の分岐があります。外部のLLMに個人データを含むプロンプトを送る行為は、本人の同意が必要な第三者提供(法27条1項)なのか、委託(法27条5項1号)なのか、それともそもそも提供に該当しないのか、という切り分けです。

個人情報保護委員会のQ&A(Q7-53)は、クラウドサービスの利用について、判断の基準は保存データに個人データが含まれるかどうかではなく、クラウドサービスを提供する事業者において個人データを取り扱うこととなっているのかどうかだとしています。そのうえで、当該事業者が個人データを取り扱わないこととなっている場合には個人データを提供したことにならず、本人の同意も、法25条に基づく委託先の監督義務も不要としています。ここでいう「取り扱わないこととなっている場合」の例として挙げられているのは、契約条項によって外部事業者がサーバに保存された個人データを取り扱わない旨が定められており、かつ適切にアクセス制御を行っている場合です。さらに別のQ&A(Q7-54)では、提供に該当しない場合でも、利用する事業者は自ら果たすべき安全管理措置の一環として適切な安全管理措置を講じる必要があるとされています。

注意したいのは、この「クラウド例外」を生成AIのAPIにそのまま当てはめてよいとは限らない点です。生成AIのAPIは、事業者側が入力されたプロンプトを実際に取り扱って応答を生成する形態であり、「保存するだけで中身を取り扱わない」ストレージ的な構図とは前提が異なります。契約条項の書きぶりと、実際の取扱い(学習利用の有無、保持期間、事業者側の従業員がどこまで参照しうるか)を突き合わせて個別に判断すべき論点だと考えたほうが安全です。どちらの整理を採るかで、必要になる手続き(同意取得、委託先の監督、安全管理措置の設計)が変わるため、検出ロジックを作り込む前に法務と決着させておく価値があります。

再識別と、仮名加工情報・匿名加工情報#

技術面では、準識別子の組み合わせによる再識別が問題になります。氏名と連絡先を消しても、「先月に本社から関西支社へ異動した経理担当の課長」という記述が残っていれば、社内の人間には誰か分かります。NISTのde-identificationに関する文書(SP 800-188)でも、単に個人情報をマスクするだけのツールがde-identificationとして十分な機能を提供するとは限らない、と述べられています。マスキングと、統計的な開示リスクを制御するde-identificationは別の営みだ、という整理です。

制度面では、日本の個人情報保護法に仮名加工情報と匿名加工情報という区分があり、両者は要件も使い道も異なります。個人情報保護委員会のガイドラインの整理を大まかに要約すると、仮名加工情報は「他の情報と照合しない限り特定の個人を識別することができない」ように加工したもので、原則として第三者提供が制限され、内部での分析利用が想定されています。匿名加工情報は「特定の個人を識別することができない」ようにし、かつ「当該個人情報を復元することができない」ようにしたもので、一定の公表等を行えば本人の同意なく第三者提供ができます。どちらにも法令で定められた加工基準があり、識別行為の禁止や、加工に関する情報の安全管理措置といった義務が伴います。

ここで実務上重要なのは、自動マスキングを1回通しただけで、これらの類型に自動的に該当するわけではないという点です。加工基準を満たしているか、義務を果たす体制があるかは別の検討が必要で、判断は自社の法務や外部の専門家と行うべき領域です。

個人情報保護委員会は、生成AIサービスの利用に関する注意喚起を公表しています(令和5年6月2日公表。注意喚起の本体は別添1、OpenAIに対する注意喚起の概要は別添2)。個人データを含むプロンプトの入力を検討する場合は、この注意喚起と、通則編・仮名加工情報・匿名加工情報編のガイドライン、およびクラウドサービス利用に関するQ&A(Q7-53、Q7-54)を原文で確認したうえで法務判断を仰いでください。この記事の記述は制度の要点を要約したものであり、法的助言ではありません。

精度をどう測るか#

マスキングは「入れた」で終わらせられません。検出ルールもモデルも、扱うデータが変われば劣化します。測る仕組みを最初から一緒に作ります。

評価コーパスを作る#

自社のテキストに似た評価データを用意し、PIIの箇所をスパン単位(開始位置・終了位置・種別)で人手アノテーションします。作り方は2通りあり、実データを匿名化して使う方法と、業務文書の構造を真似た合成データを作る方法があります。実データを使う場合、評価コーパス自体が機微データになるため保管場所とアクセス権を先に決めてください。合成データは安全ですが、実際の表記ゆれを再現しきれない弱点があります。両方を混ぜるのが現実的です。

評価コーパスには、通ってほしくない難例を意図的に入れます。

指標を決める#

エンティティ単位の再現率・適合率を測り、取りこぼしを重く見るならFβ(β=2)のように再現率に重みを置いた指標を主指標にします。加えて、種別の取り違え(人名を組織名と判定した等)を別カウントで持つと、置換ポリシーの設計に活きます。過剰マスクの影響を測るため、PIIを含まない文書での誤検知件数も必ず見てください。

リリース前チェックと定期監査#

ベンダー側の設定と併用する#

最後に線引きをはっきりさせておきます。マスキングは「送る内容を減らす」対策であり、ベンダー側の設定は「送ったあとの扱いを縛る」対策です。層が違うので、片方だけでは足りません。

主要なLLM提供事業者の公式ドキュメントは、おおむね次のような構造になっています(いずれも2026年9月4日時点の記載で、条件は変わりうるため導入時に原文を確認してください)。

• 学習利用: APIで送ったデータを既定でモデルの学習に使わない、と明記している事業者が複数あります。OpenAIは、明示的にオプトインしない限りAPIに送られたデータをモデルの学習・改善に使わないと記載しています。Microsoftも、Foundryで提供するモデルについて、プロンプトと生成結果がベースモデルの学習・再学習・改善に使われないと記載しています。なお、この確認は「やっておいたほうがよい運用上の心得」ではありません。個人情報保護委員会の令和5年6月2日の注意喚起(別添1)は、個人情報取扱事業者について、個人情報を含むプロンプトを入力する場合には特定された当該個人情報の利用目的を達成するために必要な範囲内であることを十分に確認すること、そして、あらかじめ本人の同意を得ることなく個人データを含むプロンプトを入力し、当該個人データが応答結果の出力以外の目的で取り扱われる場合は個人情報保護法の規定に違反することとなる可能性があるため、提供事業者が当該個人データを機械学習に利用しないこと等を十分に確認すること、を明記しています。監督官庁が名指しで挙げている確認事項なので、確認した内容と時点を記録に残しておくことをおすすめします。
• 保持期間: 既定では一定期間の保持がある場合があります。OpenAIは不正利用監視のログを最大30日保持すると記載し、AnthropicはAPI利用者について受領・生成から30日以内にバックエンドの入出力を自動削除すると記載しています。ただし、どちらも例外が併記されている点が重要です。Anthropicの場合、Files APIのように保持期間を利用者側で長くできるサービスを使ったとき、ゼロデータ保持などの個別合意があるとき、利用規約(Usage Policy)の執行に必要なとき、法令遵守に必要なときが例外として挙げられ、さらに自動検知で規約違反と判定された場合は入出力を最大2年・分類スコアを最大7年保持すること、Covered Modelsについては安全性業務の一環として限定的なデータ保持とレビューを求めることが別に記載されています。「既定で30日」だけを見て設計すると、この長期保持の分岐を見落とします。
• ゼロデータ保持: 事前承認が必要な設定として提供される場合があります。OpenAIのZero Data Retentionは事前承認を要し、対象外のエンドポイントがあること、有効時はstoreパラメータがtrueを指定しても常にfalseとして扱われることが記載されています。Anthropicもゼロデータ保持の合意がある場合を保持期間の例外として挙げています。
• 処理リージョン: Microsoftのドキュメントでは、Global・DataZoneといったデプロイ種別によって処理される地域が変わり、保存データは顧客が指定した地域に置かれると説明されています。

言い換えると、マスキングは万能の免罪符ではありません。取りこぼしは必ず起きるので、取りこぼした分がどう扱われるかを契約と設定で決めておく必要があります。そしてどうしても外部に出せないデータについては、マスキングして送るのではなく、自社環境内で完結させるか、LLMを使わない選択をするのが正解になる場面があります。

あわせて読みたい

LLMガードレールの設計｜入力・出力・挙動の3層で安全境界をつくる実務ガイド

よくある質問#

まとめ#

PIIマスキングは、うまく作れば地味に効き続ける仕組みですが、期待しすぎると危険な仕組みでもあります。機械的な検出は必ず取りこぼしますし、外しすぎれば業務が壊れて利用者が迂回します。「どこで落とすか」「何を残すか」「どこに残るか」「どう測るか」の4つを最初に決め、取りこぼしを前提に契約と設定で被害を抑える。この組み合わせで初めて、LLMを業務データに向けて使い続けられる状態になります。