AIに渡す情報を、送る前に分ける

長い問い合わせメールを、AIに要約してもらいたい。名前とメールアドレスを消してから貼り付けました。これなら、相手の情報を渡さずに済んだでしょうか。

たとえば本文に、「来月開店する地域で一軒だけの店舗」「担当者の役職」「細かい注文内容」が残っていたら、組み合わせから相手が分かるかもしれません。名前を消す工夫は役立ちますが、それだけで判断できない場面もあります。

この記事は、仕事や個人開発で、顧客の文章・画面・ファイルをAIに渡す人に向けたものです。個人情報は一律に入力禁止、という意味ではありません。承認された業務で必要な実データを使う場合と、加工だけで目的を達成できる場合を分けて考えます。

個人情報は、一律に入力禁止ではない

会社が承認した用途・情報の種類・契約と設定・保存や共有の条件がそろえば、業務に必要な個人情報を使える場合があります。例えば、認められた配送先の照合では、必要な宛名や住所を使います。

企業向けの契約や学習への非利用は、その判断を支える条件です。一方、「有料版」「学習オフ」という表示だけで会社の許可まで決まるわけではありません。使える用途と実データの範囲は、企業向けAIと個人情報の解説で具体的に確認できます。

ここからの返信例は、実名を渡さなくても仕事ができる場面です。すべての業務で、同じ加工を必須にするものではありません。

名前を隠すことと、渡す情報を減らすこと

まず、AIにしてほしい仕事を一文にします。今回なら「日程変更をお願いする返信を、丁寧な口調で作る」です。その仕事に、顧客の実名や注文番号、実際のメール全文まで必要でしょうか。

仮名化は、実名を「顧客A」などに置き換えること。ほかの情報から元の相手へ結び付く可能性は残ります。ここでの「顧客A」は、法的に匿名化できたという判断ではありません。

情報を減らすのは、目的に不要な事情や細部をそもそも渡さないことです。実際の文面を直す必要がなければ、目的と必要な条件だけを、自分の言葉で説明し直せます。

もちろん、契約書の表現やエラーの分析など、細かい情報が必要な仕事もあります。その場合は、必要性だけでなく、情報の所有者、送信の許可、利用できるサービスと条件を確認します。判断できない仕事のデータを、個人アカウントへ移して済ませません。

「学習に使わない」と「保存しない」は別の条件

AIに渡す情報は、いくつかの場面で扱われます。入力を処理するサービス、会話の保存、連携ツール、結果の共有は、分けて考えます。

「モデルの学習に使わない」という条件だけでは、会話の保持期間や、接続した別サービスへの送信まで決まりません。逆に、ローカル保存の履歴があることだけで、すべてが外へ公開されたと判断することもできません。

使う製品・プラン・機能の公式資料と、組織で認められた利用条件を照合します。サービスの名前が同じでも、個人向け、業務向け、API利用では条件が異なる場合があります。

安全かどうかを、一つのスイッチで決めない。

「学習」「保存」「連携先」「共有する人」を別々に見ます。確認できない項目は、AIの返答で埋めず、公式資料や管理者へ確かめます。

架空のメールから、依頼に必要なものだけ選ぶ

次は、すべて架空のデータです。名前を置き換えただけのものと、目的に必要な項目だけ選んだものを比べます。ファイルの読み取りも、AIサービスへの通信もありません。

const original = {
  name: "架空商店",
  phone: "DEMO_PHONE",
  detail: "地域で一軒だけの店舗の特別な注文",
  task: "日程変更の返信案",
  tone: "丁寧",
};
const renamed = { ...original, name: "顧客A" };
const brief = { task: original.task, tone: original.tone };
console.log("名前を変えた後も電話項目がある:", "phone" in renamed);
console.log("必要な条件だけ:", JSON.stringify(brief));

名前を変えた後も電話項目がある: true
必要な条件だけ: {"task":"日程変更の返信案","tone":"丁寧"}

trueは、名前だけ変えても電話の項目が残るという結果です。電話番号の見た目を検出する万能なツールではありません。

この依頼なら、たとえば次のように書けます。

顧客へ日程変更をお願いする返信案を作ってください。丁寧な口調で、お詫び、変更のお願い、候補日の相談の順にしてください。実名と具体的な日付は、送信前にこちらで入れます。

できた返信が実際の事情に合うかは、送る人が確かめます。必要な条件を減らしすぎて意味が変わったら、実データを丸ごと戻す前に、欠けた条件だけを足せないか考えます。

文章以外にも、渡る情報がある

画面を共有するなら、相談したい部分の外に通知や顧客名が映っていないかを見ます。表計算や文書なら、別シート、コメント、変更履歴なども確認対象です。

添付の解析範囲は製品によって違います。「画面で表示されていないから読まれない」とは決めず、必要な部分だけ別の資料にする方法も考えます。画像の切り抜きも、加工後のファイルを開いて確認します。

さらに、回答の共有も一つの送信です。AIが元の情報を言い換えていても、顧客や案件が分かる内容が残っていないかを見ます。「入力を加工したから回答はそのまま公開できる」とは判断しません。

利用者の注意だけでは防げなかった過去の事故

分類：事故の公表。 OpenAIは2023年3月20日の不具合について、一部の利用者に別の利用者の会話タイトルなどが表示され得たと、3月24日に報告しました。不具合は修正されたと説明されています。OpenAIの当事者報告

これは、利用者が名前を消し忘れた事故ではありません。現在も同じ問題があるという意味でもありません。サービス側の不具合の可能性も含めて、仕事に不要な情報は最初から預けないという考え方につなげます。

自分の作業では、3つの視点で確かめる

利用する人：必要な条件を言葉にする

承認された用途と情報の範囲内なら、手順に沿って必要な実データを使います。AIに頼む目的と、必要な情報を分けます。実名や詳細を外した架空例で十分なら、その形を使います。相手の情報を加工したつもりでも、特徴の組み合わせが残っていないか読み直します。

アプリを作る人：実際に送る項目を見る

自作アプリなら、画面の入力だけでなく、裏側で追加する利用者情報やログ、連携ツールへの送信項目も確認します。「全文を送らず要約だけ」と説明するなら、コードやテスト結果でも同じになっている必要があります。会話の写しはログの教材へ。

管理する人：許可と契約を確認する

仕事の情報は、誰が持ち主で、どのサービスへ渡せるかを社内ルール・契約・提供元の資料で確認します。医療・法務など分野固有の条件がある場合も、一律に送ってよいとは判断しません。不明なときは、情報そのものを広めずに担当へ相談します。

AIが警告してくれることもある。でも、文脈までは分からない。

秘密らしい値への警告は助けになります。一方、案件の機密性や顧客との約束は、文字列だけでは判断できないことがあります。警告がなかったことを送信の許可にしません。

送る前と、共有する前に確かめること

• 許可： 使う業務・情報・作業場所・機能が、承認された範囲と一致している。
• 目的： AIに頼む仕事と必要な条件を言葉にし、実データが必要な理由を説明できる。
• 内容： 名前だけでなく特徴の組み合わせ、画像の周辺、添付の別シートや履歴も見直した。
• 送信先： 利用するサービス・機能と、外部ツールへの送信先を確かめた。
• 保存条件： 学習利用・保持・閲覧範囲を分け、公式資料と利用条件を確認した。
• 共有結果： 回答や共有リンクにも、元の秘密や個人を特定できる情報が残っていないか確認した。

次は、アプリの中の情報の動きを見る

業務で実データを使う人は企業向けAIの利用条件へ。AIでアプリを作る人はアプリの仕組みへ。すでに送ってしまった情報が気になる場合は、追加の共有を止め、異常時の対応で対象と相談先を整理します。会話を消すだけで送信先の扱いまで確定したとは考えません。

一次資料

情報確認日：2026年10月24日。入力・保持・共有条件は利用するサービスとプランの公式資料で確認してください。

• OpenAI：2023年3月20日の不具合報告 — 過去の事故と修正の当事者報告。
• OWASP：秘密情報の管理 — 情報や秘密を必要な範囲で扱う設計の参考。
• OWASP：ログ設計 — 記録する項目と、含めるべきでない情報。本文のメールとコードは独自の架空例です。

書いた人

月ねこ｜Tsukineko

マーケティングの現場から、AIをつくり、仕事で使う側へ。実際に試したことや、つまずいたことを、図解と具体例で伝えています。

プロフィール・発信先 →著作権・利用条件 →

この記事のURL：https://nekoai-lab.github.io/ai-security-playbook/learn/ai-data-boundaries/

続けて読む

シリーズ · 全14記事のうち1記事目

次に読む →「学習しない」AIなら、仕事の個人情報を使える？会社が認めたAIで、必要な実データを使うために。個人向け有料版との違い、許可の範囲、保存・閲覧・連携先を具体例で整理する。

読む順番・ルートを見る

AIで作って公開する基本

1. AIに渡す情報を、送る前に分ける
2. 「学習しない」AIなら、仕事の個人情報を使える？
3. AIで作ったアプリの、動く場所を知る
4. AIに「APIキーを設定して」と言われた。どこに入れるのが正解？
5. APIキーを替えたのに、古いキーが使われている？
6. ログインと、データを使う権限を分ける
7. 公開したのは、本当に見せたいファイルだけ？
8. コードには書いていない。名前やメールは、どこから公開される？
9. 緑のチェックが付いた。その変更を公開していい？
10. AIレビューが合格した。その結果を、どこまで信じていい？
11. AIにデプロイを頼んだ。その認証情報は、どこまでできる？
12. AIで作ったサービスを、公開する前に確かめる
13. 外部サービスが止まったら、自分のアプリはどうなる？
14. 漏えい・異常・消失に気づいたとき、最初にすること

関連する教材

コードには書いていない。名前やメールは、どこから公開される？ →約20分 · 解説

AIとの会話を閉じたあと、秘密はどこに残る？ →約12分 · 解説

AIに渡す情報の教材へ戻る →

この教材のソース・修正提案 ↗