「学習しない」AIなら、仕事の個人情報を使える？

この記事の目次

会社が契約したAIで、顧客からの問い合わせを整理しています。利用手順には「この業務では顧客情報の利用可」。契約上も、入力をモデルの学習には使わないと確認されています。

それでも毎回、すべての名前や住所を消さないといけないのでしょうか。

一律にそうとは限りません。会社が承認した用途と取扱条件に合い、必要な確認が済んだ範囲で、業務に必要な個人情報を使える場合があります。 学習への非利用は、その判断を支える条件の一つです。

この記事は、会社や個人事業で、顧客の文章・表・文書をAIで扱う人に向けたものです。仕事に必要な個人情報を、認められた範囲で使うための確認を整理します。

個人情報を使える業務はある。許可の単位をそろえる

「このAIを使ってよい」という案内には、範囲があります。まず、利用目的、つまり何の仕事のために情報を使うのかを確かめます。同じ問い合わせメールでも、文章の分類と、実際の配送先の照合では必要な情報が違います。

ワークスペースは、組織のメンバーや設定をまとめる作業場所です。会社の契約が適用される場所と、自分の個人アカウントを区別します。会社メールでログインできることだけで、目的の契約や設定が適用されているとは判断しません。

許可の範囲を、同じ単位でそろえる

何の仕事？
問い合わせ分類、配送先照合などの目的。
何をどこで使う？
情報の種類と、契約対象の作業場所。
誰に渡る？
利用者、連携先、回答の共有先。

サービスの利用可だけで、すべてのデータ・用途・送信先が許可されたとは考えません。

例えば、会社が「会社ワークスペースで、通常の配送問い合わせを整理し、担当部署内で共有する」と承認しているなら、必要な宛名や配送先を扱う運用を設計できます。一方、人事の健康情報、別の目的への転用、社外ツールへの転送まで認められたとは限りません。

これは架空の承認例です。実際には、用途・情報の種類・サービスと機能・利用者・出力先が、自社の手順に合っているかを見ます。毎回ゼロから許可を取り直すより、承認された業務と、その範囲を利用者が確認できる形にしておくと判断しやすくなります。

「この仕事で使える」が分かる案内へ

サービス名だけでなく、使える業務と情報、使う場所、共有する相手をそろえます。範囲内なら手順に沿って進み、変わる部分だけを確認します。

企業向けと、個人向け有料版を混同しない

製品名や料金だけで、同じ契約条件とは決まりません。既定は、特に変更していないときの扱い。オプトアウトは、対象の利用をしない設定を選ぶことです。

料金・学習設定・会社の承認は別の条件

利用条件を照合
実際の製品・プラン・機能を確認する。
企業向けの既定
対象の契約で、非学習の既定や例外を確認。
個人向けの設定
有料かどうかとは別に、対象と設定を見る。
業務で使う許可
目的と情報に対する会社の案内を確認。

企業向けだけを唯一の条件にせず、個人の設定だけで会社の許可とも判断しません。

2026年10月24日に確認した公式説明では、次のように対象が分かれています。ここは、各社の全機能や個別契約を同一条件と評価する比較ではありません。

ChatGPT Business・EnterpriseなどとAPI： OpenAIは業務データを既定で学習に使わないと説明しています。明示的に提供するフィードバック等は別に確認します。OpenAI：企業データの取扱い
個人のChatGPT Free・Plus・Pro： 「Improve the model for everyone」をオフにすると、新しい会話は学習に使われません。履歴を消す設定ではなく、フィードバック送信にも別の扱いがあります。Plus・Proの料金を払うこと自体は、この設定と同じ意味ではありません。 ChatGPTのデータコントロール
Claudeの商用製品： AnthropicはClaude for WorkやAPIの入出力を既定で学習に使わないと説明し、フィードバック等の例外も示しています。個人のPro・Maxとは区別します。Anthropic：商用製品の学習利用
Microsoftの企業データ保護が適用されるCopilot： プロンプト・応答・Microsoft Graph経由のデータを基盤モデルの学習に使わないと説明しています。適用条件と利用できる管理機能は契約・アカウント・機能を照合します。Microsoft：企業データ保護

同じ画面のように見えても、個人と会社の作業場所を切り替えると条件が変わる場合があります。自分の画面に表示される所属先と、会社が指定した入口を見比べてください。アプリからAPIを使う場合も、そのアプリ自身のログや保存先は別に確認します。

個人向け有料版でも、設定や契約等の条件を確認し、組織がその用途を認める場合はあります。 企業向けという名前だけを唯一の許可条件にする必要はありません。反対に、個人で学習をオフにしたことだけでは、会社の顧客情報を移す許可までは得られません。

同じ「学習しない」でも、確認は変わる

承認済み業務で使う

必要な実データを使える場合がある

対象の情報・機能・出力先も範囲内なら、決めた手順で進めます。

個人の有料版で学習オフ

会社の許可は別に確認

設定は非学習の条件。仕事の情報を移してよいかは、それだけで決まりません。

新しい外部ツールを追加

増える経路を確認

元の作業が承認済みでも、新しい送信先が同じ条件とは限りません。

承認範囲を考える例です。入力の可否や法令適合を判定する機能ではありません。

学習の外にも、保存・閲覧・送信の条件がある

モデルの学習は、データの扱いの一部です。回答を作る処理、会話やファイルの保存、管理や安全対策のためのアクセス、他のツールへの送信は別に考えます。

学習以外の扱いも、目的に合わせる

承認された入力
必要なデータを、認められた作業へ使う。
モデルの学習
対象データ、非利用の既定や設定、例外。
保存と保持
会話・添付・ログの保存先と期間。
閲覧と監査
利用者・管理者・運用側の権限と目的。

非学習と、無保存や全員に閲覧不能という条件は同じではありません。

例えば、会話を保存して担当者が引き継ぐ運用なら、保存は業務に必要な機能です。保存があることを直ちに危険とするのではなく、誰が使い、いつまで残し、何のために閲覧できるかが合っているかを見ます。

会社の管理者が、プランや設定に応じた監査・記録の仕組みを使える場合もあります。「学習しない」から、会社の管理やサービス運用を含むすべての人に閲覧不能、と読み替えません。一方で、すべての管理者が全会話を自由に見られるとも決め付けず、実際の権限と機能を確認します。

DPAは、データの処理について定める契約です。学習への利用だけでなく、委託先、保持、削除、事故時の連絡などについて、自社に適用される契約や管理者の案内を確認する材料になります。契約名称があるだけで、あらゆるデータの利用を認める証明にはなりません。

連携やフィードバックを使うと、経路が増える

社内資料を読むコネクタ、外部の処理を呼ぶツール、Web検索、回答の共有などを使うと、入力した会話だけでは見えない経路が加わります。

機能を足した先の経路を見る

会社の作業場所
契約と設定が適用される範囲。
追加の機能
検索、外部ツール、フィードバック。
別の取扱条件
誰へ何が送られ、どう使われるか。

AI本体で確認した条件だけで、接続先や別の送信操作も確認済みにはしません。

例えば、社内での問い合わせ整理は承認されていても、その内容を未審査の外部アプリへ渡してよいとは限りません。連携する機能がどの情報を取得し、どこへ送るかを確認します。Microsoftの公式説明も、Web検索やエージェントを含む機能の条件を区別しています。企業データ保護の対象と留意点

また、「役に立った」「問題がある」といったフィードバックの送信は、通常の会話とは扱いが変わる場合があります。業務データを使った会話で送信する前に、提供元の説明と会社の運用を見ます。利用者が毎回迷わないよう、管理機能で制御できる範囲も担当者が検討します。

追加した機能の先まで見る

AI本体で確認した条件が、接続先にもそのまま適用されるとは限りません。機能を増やすときは、情報の行き先が増えるかを確かめましょう。

必要な実データを、用途に合わせて残す

次は、承認された業務に応じて項目を選ぶ架空の設計例です。すべてのデータはダミーで、個人情報を取得したり、AIへ送信したりしません。自分のPCのNode.jsで動かせます。実行しない人も、結果から違いを追えます。

「問い合わせ分類」には内容と案件IDを使い、「配送先照合」には案件ID・宛名・住所を使う、という架空のルールにします。法令や社内の許可を自動判定するコードではありません。 実運用では、認められた目的と項目を確認してから、このような設計へ落とします。

const fieldsByTask = {
  "問い合わせ分類": ["caseId", "body"],
  "配送先照合": ["caseId", "recipient", "address"],
};
function selectFields(task, record) {
  if (!Object.hasOwn(fieldsByTask, task)) throw new Error("用途が未登録");
  const fields = fieldsByTask[task];
  if (fields.some((key) => !Object.hasOwn(record, key))) {
    throw new Error("必要な項目が不足");
  }
  return Object.fromEntries(fields.map((key) => [key, record[key]]));
}
const demo = {
  caseId: "DEMO-014",
  body: "配送日の相談",
  recipient: "架空の受取人",
  address: "架空の配送先",
  internalNote: "この作業では不要な社内メモ",
};
console.log("分類:", JSON.stringify(selectFields("問い合わせ分類", demo)));
console.log("照合:", JSON.stringify(selectFields("配送先照合", demo)));

分類: {"caseId":"DEMO-014","body":"配送日の相談"}
照合: {"caseId":"DEMO-014","recipient":"架空の受取人","address":"架空の配送先"}

同じ元データでも、使う項目が変わります。分類では宛名・住所を外し、照合では必要な項目として残しています。両方とも、今回不要な社内メモは送りません。

同じデータでも、必要な項目が変わる

問い合わせの分類
案件IDと内容。宛名・住所は今回使わない。
配送先の照合
案件ID・宛名・住所。今回不要なメモは外す。

承認済みという架空の業務例です。項目の中身や法令・契約への適合を自動判断する図ではありません。

このコードは項目名だけを選びます。bodyに住所や病歴が書いてあれば、その文字まで自動で除去するわけではありません。IDがあれば個人へ結び付く場合もあり、匿名化されたという結果でもありません。実際には、選んだ項目の中身と、利用目的への適合も確認します。

実データを使えることと、AIの結果が正しいことも別です。例えば配送先の抽出結果は元の依頼と照合し、欠けた住所をAIが推測で補っていないかを見ます。読み取り・下書きまで認めた手順を、実際の発送や顧客情報の更新までの許可に広げません。

未登録の用途や必要項目の不足でエラーになったら、全項目を送る処理へ切り替えません。用途の追加や項目の変更が適切かを見直します。ここまでの例はデータ選択の練習であり、提供元の処理を再現するものではありません。

個人情報保護の注意喚起も、一律禁止とは違う

個人情報保護委員会は2023年6月2日の注意喚起で、事業者が入力する場合の利用目的との関係や、提供者による機械学習への利用等の確認を示しています。個人情報を含む入力を、すべて禁止するという書き方ではありません。個人情報保護委員会の注意喚起

ただし、「学習に使わない」ことだけで、個別の法令・契約・会社のルールをすべて満たすとは判断できません。必要な手続はデータ、利用目的、契約関係などで異なります。すべての利用に本人同意が必須とも、同意が不要とも一律に決めず、担当者が条件を確認します。

個人事業主の場合も、顧客の情報を扱う側として確認します。会社の管理者がいないからといって、サービスの非学習設定だけを判断根拠にはしません。必要なら取引先の管理担当や、個人情報の取扱いを相談できる専門家へ、情報を広めずに相談します。

学習とは別の経路で、公表された脆弱性

分類：脆弱性の公表。 Microsoftが2025年6月11日に公表したCVE-2025-32711は、当時のMicrosoft 365 CopilotにおけるAIへの命令の混入により、情報がネットワーク経由で開示され得る問題です。Microsoftが登録したCVE記録 / 提供元の対応情報

この公表から考えるのは、モデルの学習とは別に、読む権限や外へ出す経路も確認する必要があるということです。個人情報を入力した全利用者が被害を受けたという意味ではありません。Microsoftは対策済みで利用者の対応は不要と説明し、公表時の悪用評価も「なし」としています。現在も同じ問題が未修正だと示すものではありません。

企業向けサービスを使うことを否定する事例ではありません。契約上の保護、サービス側の対策、接続先や権限の設計を組み合わせ、認められた範囲で使うための教訓です。