INSIGHT
データの行き先が分からない。そのまま顧客情報を入れるな
試作品に実データを入れる前に、その情報がどこへ渡り、どこに残るかを誰が確認したかを問い直します。
AIで作った受注管理の試作品に、架空の顧客情報を入れた。過去のやり取りを踏まえた返信案が返り、使い勝手もよい。次は実際の顧客一覧を読み込ませようとしている。
そのファイルを入れる前に、情報の行き先を確かめてください。
画面に入力した情報が、どの仕組みを通り、誰が管理する場所で処理され、どこに残るのか。開発中の相談や障害調査では、別の場所へ複製されないか。これが分からないままでは、自分がどの情報をどこへ渡すのか確認できていません。
便利に動いたという確認は、情報の送信先と取扱条件を確認したことにはなりません。
一枚の経路図から始める
ここで必要なのは、複雑な構成図ではありません。一つの入力がどこを通るかを、左から右へ並べた図です。
「利用者の画面 → 自社の仕組み → 外部の処理先 → 保存先 → 回答画面」。添付文書を読むなら、その保管場所も足します。記録が残るなら、会話履歴、操作履歴、障害調査用のログも足します。そして各地点に、扱う情報、管理する会社、保存期間、閲覧できる人を書き込みます。
データフローとは、情報が入力されてから、処理、保存、出力、削除に至るまでの道筋です。AIで作ったプログラムが常に外部のAIへ通信するわけではありません。外部へ通信すれば直ちに漏えいするわけでもありません。だから製品名や印象で判断せず、設定、契約、実際の通信、ログの設計を対応させます。
図の空欄は欠陥の証明ではなく、確認先を示します。「外部処理先は提供者へ」「障害ログは運用担当へ」「利用目的は業務責任者へ」と分ければ、自分で調べる範囲と、判断を依頼する範囲が見えてきます。
稼働時だけを描くと、開発中の複製を落とす
経路図は、稼働時と開発・保守時の二本に分けます。
稼働時には、利用者の入力、検索する文書、外部連携、生成結果、操作履歴があります。開発・保守時には、不具合の説明として会話へ貼る本文、試験用ファイル、画面の画像、エラー記録、問い合わせ先へ渡す調査資料があります。日常利用では入力しない情報が、修正作業では丸ごと渡されることもあります。
確認したいのは、顧客名だけではありません。商談メモ、問い合わせ本文、契約番号、購買履歴のように、単独では本人が分からなくても、組み合わせると顧客や取引を特定できる情報があります。自由記述欄やログは、予定していなかった情報が混ざりやすい場所です。
送信する情報だけでなく、開発、稼働、障害対応で生まれる複製まで、同じ管理対象に置きます。
「学習に使わない」だけでは、条件が一つ埋まっただけ
個人情報保護委員会の生成AIサービスの利用に関する注意喚起 は、利用目的、入力する情報、提供先での取扱い、学習利用などの確認を促しています。2023年の注意喚起であり、個人情報の入力を一律に違法とする資料ではありません。「学習に使われない設定なら、あらゆる用途で安全・適法」と示すものでもありません。
取扱条件は、経路図の地点ごとに読みます。処理する地域、保存期間、再委託、提供者側で閲覧できる人、削除方法、契約終了後の返却・削除、事故時の連絡を確認します。同じサービスでも、契約、機能、設定、利用地域によって説明が分かれるなら、自社が使う条件へ結び付けて残します。
NISTのGenerative AI Profile は、情報管理、第三者への依存、役割、継続的な評価、停止・廃止などを整理した任意の枠組みです。日本企業の個別業務へ法的義務を定める資料ではありません。ここでは、入力設定だけで確認を終えず、提供先との分担や利用終了までを見るための補助線として使えます。
実データを使う前に、情報を減らした試験へ戻す
経路と条件を確認している間も、試作を捨てる必要はありません。顧客情報を含まない試験データで操作性を確かめる。自由記述を外し、分類だけを試す。外部送信や保存を伴わない範囲へ戻す。確認済みの経路だけで、次の判断材料を作れます。
ただし、匿名らしく見えるデータも、契約番号、日時、地域、問い合わせ内容の組み合わせで相手を推測できることがあります。「氏名を消した」だけで試験データと決めず、誰が作り、どこへ置き、いつ消すかまで決めます。
情報を減らす目的は、入力者へ注意責任を押しつけることではありません。業務側が「返信案に氏名は必要か」「過去の全文が必要か」「契約条件だけで足りるか」を決め、仕組み側がその範囲を越えて送れないようにすることです。
OWASPのLLM Top 10 2026 は、機密情報、指示注入、過剰な権限、検索基盤などの論点を整理しています。事故件数の順位や個別サービスの判定表ではありません。経路図で、情報と機能と権限の組み合わせを見落とさないために参照できます。
入れてよい情報かを、経路と条件を添えて確認する
実データへ切り替える前に、次の四点を記録し、情報を管理する担当者と利用条件を確認します。経路図を埋めただけで、個別の契約や法的可否まで自分で判断し終えたことにはしません。
- 稼働時と開発・保守時の経路があり、入力、参照、処理、保存、出力、削除を追える。
- 提供先と連携先の取扱条件を、利用する契約、機能、設定、目的に結び付けている。
- 入力する情報、利用者、許可する操作を限定し、業務責任者が確認している。
- 条件変更や事故の際に、利用を止め、調べ、連絡する担当と手順がある。
一つでも欠けるなら、実データでの利用拡大と旧手順の廃止を保留します。試験用データによる検証や、情報を送らない部分の改善は続けられます。再開は「大丈夫そうだ」という感触ではなく、経路、条件、範囲、停止担当を記録で示せたときに決めます。
実データを入れる前に、送信先とログに残る情報を確かめる
顧客一覧を読み込ませる前に、試験用の一件が通る経路をたどってください。「このログには何が残るか」に答えられなければ、そこを空欄のまま管理担当へ渡します。実データを入れてから調べるのではなく、使ってよい情報と条件を確認できた範囲から、利用を始めてください。