LLM APIに個人情報を送る前に｜データの行き先と保存範囲の整理

1. どこまでをデータフローに含めるか

本稿では、問い合わせ文から返信案を作る業務Webアプリを例に、入力・送信・出力・ログの4段階を分けて整理することを提案する。入力には画面の文章と添付ファイル、送信には整形済み文章とRAGで選んだ資料、出力には回答と引用、ログには処理記録と保存対象を置く。担当者が画面へ入力した内容だけを調べて終わらず、処理途中に追加する項目も記入する。まず通常の返信作成を一本の経路として描き、その後にエラー時、再実行時、外部通知時の分岐を加えると、確認対象を切り分けやすい。

経路ごとに、送信元、送信先、扱う項目、利用目的、保存先、閲覧できる役割を記録する。例えば問い合わせ番号は進捗管理に使い、本文は返信案の生成に使うとしても、両方をすべての保存先へ渡す設計にはしない。OWASPはプライバシー保護の指針として通信中と保存時の暗号化、保存情報への厳格なアクセス条件を挙げている。[2] 本稿の設計例では、これらを経路単位の確認項目に置く。暗号化の設定確認とは別に、その経路へ情報を渡す必要があるかを業務担当者が判断する。

• 正常処理だけでなく、エラー、再実行、通知の経路を図に含める。
• 各保存先の閲覧者と、設定を変更できる担当を分けて記録する。

2. 入力時に何を残し、何を除くか

入力段階では、作業に必要な情報を先に定義する。本稿では、返信の文体を整える用途なら、問い合わせの要旨、希望する対応、回答の条件を中心に入力する設計を提案する。発送先の住所や支払情報を使わない作業であれば、それらを送信対象から除く。逆に、記録の照合が必要な場合は、内部の管理番号で照合してから必要な結果だけを文章に反映する。この設計例では、氏名の置換だけで送信可とは判断せず、所属、日付、出来事など残った項目も確認し、用途に必要かどうかを個別に決める。

自由記述欄や添付資料を許す場合は、入力者への注意書きだけでなく、送信前に内容を確認する工程を設ける。例えば本文と添付ファイルを別々に表示し、除外対象を検出した場合は修正へ戻すか、担当者の確認を待つ設計にする。OWASPは利用者入力や外部コンテンツの検証、指示とデータを分けた構造化、対策の限界を考慮することを挙げている。[1] ここでは検出結果を送信許可の唯一の根拠にせず、入力欄の制限と業務上の確認を組み合わせる。扱えない形式の添付は、黙って通さず保留にする。

• 用途別に必須項目、任意項目、送信しない項目を決める。
• 添付や長文を確認できなかった場合の扱いを決める。

3. RAGとAPIはどの権限で動かすか

RAGを使う場合、本稿では検索結果を追加の送信データとして扱い、利用者が閲覧できる資料だけを検索候補にする設計を提案する。例えば複数部門の手順書を同じ検索基盤へ登録するなら、所属部門や資料の公開範囲をアプリ側で判定し、許可した候補から必要な箇所を選ぶ。選定時には本文だけでなく、資料名や引用に添える識別情報も確認する。検索件数を減らすことと閲覧権限を制御することは別の判断とし、検索順位が高いという理由では、利用者の対象外の資料を送らない。

外部資料にはモデルへの指示を装った内容が含まれる可能性があり、OWASPは間接的なプロンプトインジェクションと、連携ツールやAPIを通じた不正操作を説明している。[1] 本稿では、検索した文章は参考データとして扱い、モデルの回答を理由にAPIの権限を広げない設計を提案する。記録の参照だけが必要なら、更新操作を使わせない。更新が必要な用途では、操作対象、許可する項目、実行者の権限をアプリ側で確認する。文章に書かれた指示と、実行を許可する業務ルールを分けて管理する。

• 権限の異なる利用者で同じ検索を行い、送信候補の違いを確認する。
• モデルが提案する操作と、アプリが許可するAPI操作を分離する。

4. 出力を誰に、どの形式で渡すか

出力段階では、回答を作った担当者と、回答を受け取る相手を分けて考える。本稿では、内部向けの判断材料と、外部へ送る返信案を別の出力用途として設計することを提案する。内部用の回答に参照資料の記述を含める場合でも、外部用では必要な説明だけを残す。画面で閲覧できる回答を、そのままメールやWebhookへ送る共通処理にはせず、配信先ごとに含めてよい項目を決める。初期公開では担当者が配信内容と宛先を確認する方式とし、自動配信の採否は別の要件として判断する。

OWASPはLLMの出力監視と検証、表示時のHTMLやMarkdownのサニタイズを推奨している。[1] 本稿の設計例では、回答の本文検査と画面表示の処理を別の確認対象にする。例えば、内部資料の引用を外部返信へ残してよいかを内容面で確認し、リンクや装飾をどの形式で表示するかを実装面で決める。確認で問題が見つかった場合は、文章を修正する、引用を除く、配信を止めるという分岐を用意する。表示処理が正常だったことを、宛先や記載内容も適切だったという評価へ置き換えない。

• 内部画面、外部返信、Webhookごとに出力項目を定義する。
• 本文の確認と、表示形式・リンクの確認を別々に行う。

5. ログと再実行に何を残すか

OWASPはLLMとのやり取りに関するセキュリティログから機微な情報を除外することを挙げている。[1] 本稿では、通常の運用ログには処理番号、日時、成否、適用した設定の識別子などを残し、入力全文や回答全文の保存は別途必要性を判断する設計を提案する。使用するSDKや監視ツールについても、本文を保存する設定・機能の有無を確認する。障害対応のために一時保存する場合は、対象、閲覧者、終了条件を限定する。問い合わせ対応用の記録と技術調査用の記録を、同じ保持方針にそろえる必要はない。

再実行については、この設計例では送信結果を判定できない状態を想定する。その際に同じデータを自動で送り直すかは、連携先の受信確認、重複処理、再送に関する公式仕様を確認して決める。問い合わせ文を再利用する場合も、初回の本文を保存する方式と、元データから作り直す方式を区別する。前者は保存範囲を、後者は内容変更や権限変更の扱いを定める。Webhookの再通知も含め、再実行ボタンを押せる役割、判断待ちの表示、再送を止める条件を設け、担当者が状態を確認してから進められるようにする。

• SDK、監視、バックアップを含め、本文保存の設定・機能を確認する。
• 結果不明を失敗確定と分け、再送判断の担当と条件を定める。

6. 公開前の確認表をどう使うか

本稿では、公開判断に使う確認表を、設定の宣言ではなく確認結果と証拠を記録する場所として提案する。下表の状態はすべて確認前であり、採用済みの設計や合格を示すものではない。担当者は実際の構成に合わせて行を分割し、設定画面、試験記録、参照した公式仕様を対応づける。例えばAPI側の保存範囲を確認できても、アプリ側のログ確認が未完了なら別の未確認事項として残す。提供者の説明と、自社環境で実際に確認した設定を同じ欄に混ぜず、どちらが根拠か追えるようにする。

試験には実在の個人情報ではなく、用途を再現したダミーデータを使う。OWASPは、ダミー情報が試験用の送信先へ到達したかなど目的別の観測を求め、観測不足やエラーを攻撃が阻止された結果として数えないよう説明している。[1] この確認表でも、画面に問題のある文章が出なかったことだけで送信経路全体を合格にしない。送信内容を観測できない場合は未確認、対象機能がない場合は対象外として理由を残す。確認済みの項目と残る不確実性を分け、公開範囲を決める材料にする。

7. 公開後の変更と引継ぎをどう管理するか

公開後は、最初に確認したデータフローから何が変わったかを管理する。本稿では、モデル、検索対象、外部送信先、ログ設定の変更を再確認の起点として扱う設計を提案する。例えば新しい文書群をRAGへ追加する変更では、回答品質だけでなく、その文書を誰が検索できるかと、何を送信するかを確認する。障害対応でログ保存を増やした場合は、対応終了後の設定復帰も変更記録に含める。OWASPは継続的なテスト、ログ確認、対策更新、緊急制御の整備を挙げており、保守の検討根拠になる。[1]

引継ぎでは、設定値だけでなく判断理由と未確認事項を渡す。本稿では、業務担当には送信を認めた項目と例外条件、開発担当には経路図と試験記録、運用担当には停止手順と再開判断の窓口を渡す整理を提案する。担当交代時に、過去の検証用データや一時保存した本文も引継ぎ対象かどうかを確認する。通常の問い合わせ先と、外部送信を止める判断者を明示しておけば、判断が必要なときの連絡経路を追いやすい。再開は停止原因に対応する確認の完了を条件とし、担当者の交代だけで未確認事項を解消した扱いにはしない。

• 変更内容と、再確認する経路・項目を対応づける。
• 判断理由、未確認事項、停止・再開の窓口を引き継ぐ。

よくある質問

送信可否を判断する業務担当者が不在なら、開発側で進めてよいですか。

本稿では、用途や項目の必要性を判断する担当が不在の場合、新しい送信範囲の承認は保留することを提案します。既に承認された範囲で継続できる機能と、判断待ちの機能を分けます。代理の判断者を事前に定め、技術的に送れることを業務上の承認に置き換えない運用にします。

確認用環境がなく、本番でしかAPIを使えない場合はどうしますか。

実データを投入して確認する方法へ直ちに切り替えず、利用先が提供する検証手段と、本番でダミーデータを扱う際の保存範囲を調べます。本稿では、対象者と機能を限定した確認計画を提案します。必要な観測ができない項目は未確認として残し、その機能の公開延期や、外部送信を伴わない代替手段を検討します。

障害調査のため、期限付きで入力本文を保存してもよいですか。

期限だけで判断せず、本文が必要な調査目的、対象範囲、閲覧者、削除方法を先に決める設計を提案します。まずダミーで再現できるか、項目名や処理状態だけで調査できるかを検討します。例外を認める場合も、延長には再承認を求め、終了時に保存設定の復帰と対象記録の扱いを確認します。

API提供者の保存仕様が確認できないまま、公開日を迎えたらどうしますか。

仕様が不明な部分を、保存されない、学習に使われないなどと推定して公開条件にしません。本稿では、その送信を必要とする機能を保留するか、個人情報を使わない用途に限定する判断を提案します。機能を縮小する場合も、添付やRAGから対象情報が加わらないことを確認し、残る制約を運用担当へ伝えます。

参考・関連資料

• [1] LLM Prompt Injection Prevention - OWASP Cheat Sheet Series ↗
• [2] User Privacy Protection - OWASP Cheat Sheet Series ↗

公式資料の確認日：2026-10-14。業務例は説明用で、顧客の実績ではありません。編集：株式会社N2i。執筆にAI支援を使用し、別のAIによる出典・品質確認に合格した記事を公開する方針です。