生成AIに入力してよいデータ・止めるデータの判断基準｜情シス向け実務ガイド

生成AIの社内利用で最初に詰まるのは、「このデータを入力してよいか」を現場が判断できないことです。問い合わせメール、管理画面のスクリーンショット、契約書PDF、帳票OCRの結果などは、便利に処理できる一方で、個人情報、認証情報、顧客固有情報、契約上の秘密が混ざりやすい領域です。

結論から言うと、生成AIに入力するデータは「公開情報で判断できるもの」「サービス公式仕様で確認するもの」「自社契約・社内規程で決めるもの」に分けて管理します。特にログ保存期間、DPA、SLA、学習利用の可否、国外移転の扱いは、公開ページだけでは自社に適用される条件を断定できない場合があります。そのため本記事では、入力してよいデータ、止めるデータ、条件付きで使うデータを分けたうえで、契約書、DPA、管理画面、社内規程で確認すべき項目まで整理します。

まず分けるべき3種類のデータ

「個人情報をマスクしたから安全」と考えると危険です。個人情報保護委員会のガイドラインでは、匿名加工情報を作成する際、特異な記述の削除や、データベースの性質を踏まえた追加措置が必要になる場合があるとされています。つまり、氏名やメールアドレスを消すだけでは、部署、役職、地域、購買履歴、病歴、問い合わせ内容の組み合わせから本人が推測される可能性が残ります。

迷った場合は、黄ではなく赤として扱います。生成AI導入を止めないためには、現場が勝手に判断する余地を減らし、「赤は入力禁止」「黄は承認付き」「緑は通常利用」という線引きを先に決めることが重要です。

サービスごとに確認すべきポイント

生成AIサービスは、同じ提供元でも個人向け、法人向け、APIでデータの扱いが異なります。たとえばOpenAIは、APIに送信されたデータについて、2023年3月1日以降、明示的にオプトインしない限りモデルの訓練・改善に使わないと公式ドキュメントで説明しています。また、ChatGPT Business、ChatGPT Enterprise、ChatGPT Edu、API Platformなどのビジネスデータも、既定では訓練に使わないと説明されています。

Anthropicも、Claude for WorkやAnthropic APIなどの商用製品では、既定で入力・出力をモデル訓練に使わないと説明しています。一方、Claude Free、Pro、Max、およびそれらのプランでClaude Codeを使う場合は、ユーザーが許可した場合や安全性レビューに該当する場合など、利用条件が異なるため、個人向けアカウントを業務利用する設計は避けるべきです。

場面別の入力ルール

1. 問い合わせメール・チャット履歴

問い合わせ対応で最も危ないのは、本文を丸ごと貼り付ける運用です。氏名や連絡先だけでなく、注文番号、顧客ID、過去の対応履歴、地域、契約プラン、障害発生日の組み合わせから顧客が特定されることがあります。

• 赤：顧客名、メールアドレス、電話番号、住所、顧客ID、注文番号、契約番号
• 黄：問い合わせカテゴリ、発生時期、製品名、利用環境、エラー内容
• 緑：公開FAQ、個人・契約を含まない一般的な回答案

運用ルールは「原文を入力しない」「必要箇所だけを要約して入力する」「回答案は人が確認してから送信する」の3点を最低ラインにします。

2. 管理画面のスクリーンショット

スクリーンショットは、見落としが発生しやすいデータです。画面の端にユーザー名、メールアドレス、セッションID、APIキー、管理者権限の表示が写るだけで、送信不可になります。

• 送信前に、マスク対象フィールドの一覧を画面単位で作る
• パスワード、トークン、Cookie、セッションID、APIキーは例外なく赤にする
• 管理者画面は、画面所有部署と情報セキュリティの承認を必須にする

3. PDF・帳票・OCR結果

PDFや帳票は、氏名・住所・口座情報・取引先名・契約条件が混在しやすいため、OCR後のテキストをそのまま生成AIに渡さない設計が必要です。要約や抽出に使う場合でも、原票ID、抽出フィールド、確認者をログに残し、出力結果を原票と突合します。

送信してよいのは「AIに処理させる目的に必要な最小限の情報」だけです。原本、全文、全画面、全履歴を渡す運用は、便利でも監査に耐えにくい運用です。

PoC前に決める承認フロー

PoCは「小さく始める」だけでは不十分です。開始前に、対象業務、入力データ、除外データ、利用サービス、評価指標、ログ項目を決めます。総務省・経済産業省のAI事業者ガイドライン第1.2版では、AIの開発・提供・利用に関する取組の基本的な考え方が示されています。社内利用でも、リスクを見える化し、関係者が同じ基準で判断できる状態にしておくことが重要です。

そのまま使える申請テンプレート

申請業務名：＿＿＿＿＿＿
利用目的：＿＿＿＿＿＿
利用する生成AIサービス名・プラン：＿＿＿＿＿＿
対象データ：＿＿＿＿＿＿
入力禁止データ：＿＿＿＿＿＿
データ分類：赤／黄／緑
黄の場合の条件：マスク／一般化／トークン化／人手確認／その他＿＿＿＿＿＿
利用者範囲：＿＿＿＿＿＿
出力結果の確認者：＿＿＿＿＿＿
ログ項目：入力日時、利用者ID、利用サービス、入力分類、出力分類、承認者ID、原票ID（該当時）
ログ保存期間：問い合わせ対応、監査対応、事故調査、契約上の保存義務をもとに設定した保存期間を記載
DPA・契約条件：学習利用の有無、保存期間、削除方法、データ所在地、サブプロセッサ、管理者の閲覧範囲を確認して記載
承認者：業務責任者＿＿＿／法務＿＿＿／情シス＿＿＿

PoCチェックリスト

• 個人情報・契約情報・認証情報を赤として定義したか
• 黄データのマスク、一般化、トークン化の方法を決めたか
• 利用するサービスの公式ドキュメントで、学習利用とデータ保持の説明を確認したか
• 個人向けアカウントを業務データ処理に使わない方針にしたか
• 出力結果を誰が確認するか決めたか
• ログ項目、保存期間、閲覧権限を決めたか
• 誤回答、情報混入、規約変更、障害時の停止条件を決めたか

まとめ：生成AIのデータ基準は「入力前」に決める

生成AIのデータ取り扱いで重要なのは、便利な使い方を禁止することではありません。現場が迷わず使えるように、入力禁止データ、条件付きデータ、通常利用できるデータを先に分けることです。

特に、匿名化やマスクは万能ではありません。個人情報保護委員会のガイドラインが示すように、特異な記述やデータベースの性質によっては、追加の加工が必要になる場合があります。サービス仕様も、個人向け、法人向け、APIで異なります。したがって、情シスは「ツールを許可するか」だけでなく、「どのデータを、どの条件で、誰が承認して、どのログを残して使うか」までをセットで設計する必要があります。

最初の一歩は、赤・黄・緑の分類表を社内の申請書に組み込み、PoC開始前に業務責任者、法務、情シスの3者で確認することです。ここまで決めておけば、生成AI活用は止めずに、監査に耐える形で進められます。