- 公開日
個人情報をAIへ渡す量は、元の資料に何が含まれているかではなく、今回AIに何を判断してもらうかから決めます。回答案の作成に氏名や連絡先が必要なければ削除し、案件の区別だけが必要なら一時的な符号へ置き換えます。ただし、氏名を消しても、日時、勤務先、珍しい出来事の組み合わせから本人が分かることがあります。送信前には、仕事に必要な意味が残っていることと、不要な識別の手掛かりが残っていないことを別々に確認します。
ここでは、日本の事業者が顧客への回答案を作る場面を中心に、入力を減らす手順を説明します。法令に関する説明は2026年10月12日に確認した個人情報保護委員会の資料に基づきます。個別サービスへの入力が許されるかは、加工した内容だけでなく、組織の利用目的、契約、実際の送信先を合わせて判断する必要があります。
まず「回答案」と「顧客を特定する作業」を分ける
担当者の仕事には、問い合わせの意味を理解する、適用する規約を選ぶ、顧客へ連絡する、といった異なる処理が含まれます。この一連の仕事をすべてAIに渡すと、連絡のために保有している情報まで文章生成に使いやすくなります。
回答案だけを作るなら、AIに必要なのは、問い合わせの論点、適用する条件、案内できる選択肢です。宛名やメールアドレスは、担当者が確認した後、顧客管理システム側で付けられます。返金対象かを判断する場合も、生の購入履歴を丸ごと渡す前に、必要な期間や対象商品について社内で判定し、「保証期間内」といった結果だけを渡せないかを検討します。
この分担は、AIに事実を隠して答えさせるためではありません。誰がどの事実を確認し、AIにはどの文章化を任せるかを決めるためです。判断に必要な条件まで取り除けば、回答は一般的になり、例外を見落とします。削除できない項目は、残す理由と、その情報を扱えるサービスであることを確認します。
個人情報保護委員会の生成AIサービスに関する注意喚起は、事業者による入力が特定した利用目的を達成するために必要な範囲かを確認するよう求めています。また、本人同意なく個人データを入力し、応答の出力以外の目的で取り扱われる場合には、法違反となる可能性があるとしています。単に「問い合わせ対応に便利」という理由では、入力範囲や提供者による利用まで確認したことにはなりません。
問い合わせを、送れる材料へ組み直す
次は架空の通販会社で、未使用商品の返品案内を作る例です。実在する顧客情報やサービスの処理結果ではありません。
元の問い合わせには、氏名、メールアドレス、住所、注文番号、商品名、到着日、未使用であること、サイズが合わないこと、過去の購入履歴、家族の事情が含まれているとします。社内規程には「到着後14日以内の未使用品は、対象外商品を除き返品を受け付ける」とある仮定です。AIには返品の可否を確定させず、担当者が確認した条件から案内文を作らせます。
| 元の項目 | 今回の回答案での扱い | 判断の理由 |
|---|---|---|
| 氏名、メールアドレス、住所 | 送信材料から削除 | 返品手順の文章化には不要。宛先は社内で付与する |
| 注文番号 | 削除。複数案を区別するときだけ一時符号に置換 | 注文照会をAIにさせないため、生の番号を渡す理由がない |
| 商品名 | 規程上必要な商品区分へ置換 | 対象外商品かどうかを判断する条件は残す |
| 到着日 | 社内確認済みの「到着後5日」へ置換 | 仮定の14日条件との関係を保つ。時点は担当者が確認する |
| 未使用、サイズ不適合 | 必要な事実として残す | 返品条件と問い合わせ理由に直接関係する |
| 過去の購入履歴、家族の事情 | 削除 | 今回の案内条件に関係しない |
この表は、すべての返品業務に適用できる固定ルールではありません。商品名が安全上の注意や返品除外条件に関係するなら、商品区分への置換では足りません。その場合は、社内で条件を確定してから結果を渡すか、必要な情報を取り扱える別の処理経路を選びます。
入力例は、次のように組み直せます。
「未使用の通常商品について、サイズ不適合を理由に返品方法を尋ねられています。担当者が、到着後5日であり、返品対象外商品ではないと確認しました。添付する承認済みの返品手順に基づき、案内文の下書きを作ってください。返金日や送料負担が資料にない場合は、確定せず確認事項として残してください。宛名、連絡先、注文番号は付けません。」
差し替えるのは、担当者が確認した日数、商品条件、承認済みの手順です。例の14日という期間は、この架空会社の仮定であり、法定の返品期間を示しません。生成後は規程と照合し、返品を認める範囲や送料などを勝手に補っていないかを人が確認します。
削除、仮名への置換、概要化を使い分ける
削除は、項目を送らない方法です。回答に使わない氏名や履歴は、伏字を残すより、項目そのものを入力材料から外す方が管理しやすくなります。「詳細は元メールを参照」と書いて元メールを添付すれば、削除した効果は失われます。
仮名への置換は、同じ案件について複数の情報を結び付ける必要がある場合に使います。たとえば「案件A」とすれば、回答候補と確認事項を対応させられます。ただし、日付や顧客番号の一部を符号へ埋め込むと、符号自体が手掛かりになります。対応表は、AIへ送るファイルとは分け、必要な担当者だけが参照する設計にします。今回一件しか扱わず、対応付けも不要なら符号を作る必要はありません。
概要化は、必要な意味を保ちながら、細部を減らす方法です。「何月何日に、どの住所へ届いた」という文を「到着後5日」に変えれば、期限の判断に使う情報を残せます。一方、「長年購入しているので今回だけ特別扱いすると約束された」という内容を「返品希望」に縮めると、過去の約束という重要な条件を落としてしまいます。概要化では、本人を示す細部と、判断を変える事実を分けて読みます。
これらの加工を、法制度上の匿名化と同一視しないことも重要です。個人情報保護委員会のFAQは、法定の匿名加工情報と仮名加工情報を区別し、仮名加工情報は作成した事業者にとって原則として個人情報に当たると説明しています。氏名を案件Aに変えただけで、いずれかの法定区分の要件を満たしたと判断することはできません。本記事の置換は入力範囲を減らす実務上の方法であり、法定の加工・管理義務への適合を認定するものではありません。
残した情報の組み合わせを読む
加工後の文章は、一項目ずつ点検するだけでなく、受け手が何と結び付けられるかを考えて読み直します。「地方の小規模な施設の唯一の担当者」「公開イベントの翌日に起きた珍しい故障」といった表現は、氏名がなくても対象を絞り込む手掛かりになります。特定の人に結び付くかどうかの法的評価と、組織として送信を控えるべきかという実務判断は、同じ結論になるとは限りません。
日本の通則編ガイドラインでは、個人情報の定義や利用目的の特定・制限が示されています。実務では、その定義を確認したうえで、本文、添付、ファイル名、会話履歴を一つの送信単位として見ます。本文を減らしても、ファイル名に氏名がある、前の会話に住所がある、画像の隅に送り状が写る、といった状態なら、送信材料全体は減っていません。
外部AIに元の個人情報を全部送り、「まず匿名化してください」と頼む方法は、送信前の最小化にはなりません。加工は、元データを扱うことが認められた社内の環境や手順で行います。別のAIを加工に使う場合も、そのAIへの入力許可と経路を先に確認します。
減らした後は、仕事の成立と送信条件を別々に確かめる
架空の返品例では、担当者が元資料と加工後の入力を照合し、商品区分、期限、未使用という条件が残っているかを確認します。次に、生成された案内を承認済み手順と比べます。必要な案内が欠ける場合は、元メールを丸ごと戻すのではなく、欠けた条件を特定して一項目ずつ追加します。これにより、何のために追加したかを説明できます。
送信条件の確認は、回答品質とは別です。選んだ法人契約や機能で、対象データを扱えるか、提供者の学習利用や保持条件はどうなっているか、接続先や運用ログにも送られないかを確認します。「学習に使わない」という条件が確認できても、入力許可、保存、外部接続の確認がすべて済んだことにはなりません。重要な条件が不明なら、実顧客の情報ではなく、公開可能な一般的質問や架空例に切り替えます。
運用記録には、作業目的、残した項目と理由、除いた項目の種類、適用するサービスと設定、確認者を残すと見直しに使えます。記録のために削除前の全文を新しい管理表へ複製する必要はありません。目的が回答案から顧客分析へ変わったときや、検索・外部連携を追加したときは、同じ入力テンプレートをそのまま使わず、項目選択からやり直します。
入力した情報が会話履歴・検索用の索引・ログなどに残る場合の管理は「AIに渡したデータはどこに残るか 分類から削除までの管理」で解説しています。
海外のAIサービスへ個人データを送る前の確認は「海外AIサービスへ個人データを送る前に、越境移転の条件を確認する」で解説しています。
