Claudeへ渡すデータのライフサイクル：入力・保存・ログ・削除を分けて確認する

データの経路を一覧にする

元の文書、モデルへ送る抜粋、生成された回答、ツールの結果、監視ログを分けます。それぞれに目的、閲覧者、保存場所、保存期間を対応させます。実際の顧客情報が必要ない評価では、架空データや置換したデータを使う選択肢があります。

開発環境のログにも情報が残ることがあります。APIのリクエストだけを見て終わらず、例外ログや不具合報告に本文が含まれないかも確認します。

契約や機能ごとの条件を照合する

保存、学習利用、処理場所、データ所在地は別の論点です。利用する製品、API経路、契約、機能によって条件が違う場合があるため、最新の公式説明と組織の要件を対応させます。本記事は特定の契約条件や法令適合を保証するものではありません。

特定機能で必要な保持がある場合、他の機能と同じ条件を適用できるとは限りません。名称や宣伝上の説明だけでなく、利用予定の機能の条件を確認します。

削除の範囲を定める

元文書を消しても、その抜粋や生成物が別の保存先に残る可能性があります。削除要求に対してどのコピーを対象にするかを決め、監査用の識別情報と本文を分離します。何を保存しないかを先に決めると、後から消す対象を減らせます。

削除要求を一つのコピーで終わらせない

元文書を削除した後も、検索断片、要約、キャッシュ、障害報告の添付に内容が残る場合があります。データの経路図へ派生物も加え、どのコピーを誰が管理しているかを記録します。保存しない方針を採る場合も、例外時だけ本文をログへ出していないかを確認します。通常のリクエストと失敗時の処理を同じ条件で見直すことが必要です。

組織の要件を公式条件へ照合するときは、「保存しない」「学習へ使わない」「指定地域に置く」を別の確認欄へ分けます。これらは同じ意味ではなく、機能や提供経路で範囲が異なることがあります。条件が合わない場合は、設定を推測で補わず、利用するデータや機能の範囲を変更する判断が必要です。確認が終わっていない点を、運用開始済みの保証として記載しないようにします。

具体例で考える

架空のサポート分析では、分類の傾向だけが必要で、氏名や電話番号は不要です。

送信前：氏名と連絡先を分析用の記号へ置換。
結果保存：分類と件数を保持。
診断ログ：本文ではなく要求IDとエラー種別を記録。
復元表：別管理し、不要なら作らない。

置換しても内容から人物が分かる場合があるため、単なる名前の削除で匿名になったとは判断しません。分析に必要な文脈と、不要な識別情報を具体的に分けることが出発点です。

確認課題と合格の目安

自分の処理にあるデータのコピーを列挙し、保存目的と削除対象を確認してください。

• 提供者側と自分のアプリ側の管理を分けている。
• 機能と契約に適用される条件を確認する。
• ログや生成物も棚卸しに含めている。