結論：必要な項目だけに減らし、全経路を確認してから送る
先に答えると、Claude APIへ個人情報を送れるかは「Anthropicが学習に使うか」だけでは決まりません。処理目的、法的根拠、本人への説明、最小化、契約、保持、再委託、アクセス、削除、事故対応を確認し、不要な氏名、住所、連絡先、識別子は送信前に削除または置換します。
読者の具体的な困りごとは、問い合わせ本文をそのままAPIへ送り、後からどの項目が必要だったか、どこへ保存されたかを説明できないことです。読了後は、項目ごとに削除、マスキング、送信可を判断し、実装レビュー表を作れます。次の行動は、APIへ入る全項目を一列に並べ、それぞれの目的と保存先を書くことです。
「学習に使われない」と「送ってよい」は別の判断
Anthropicは商用製品について、既定では入力と出力をモデル学習に使わないと案内しています。Commercial Termsでも顧客コンテンツを学習に使わないことが示されています。一方、明示的なフィードバックや許可がある場合は例外になり得ます。運用ではフィードバック機能の設定と、従業員が誤って会話全体を報告しないための説明が必要です。
学習に使われなくても、サービス提供、セキュリティ、法令対応、ログ、バックアップ、第三者機能のために処理や保持が発生する可能性があります。また、送信する会社側には個人情報を取得・利用する根拠と説明責任があります。したがって「学習されないから安全」という一文を承認理由にせず、データの入口から削除までを確認します。
最初に作るデータフローは7地点
- 取得：フォーム、メール、CRM、ファイルのどこから来るか。
- 前処理：削除、マスキング、分類をどこで行うか。
- 送信：どのAPI、モデル、地域、エンドポイントへ送るか。
- 応答：出力に個人情報が再掲・推測されないか。
- 保存：アプリ、ログ、監視、分析、バックアップへ何が残るか。
- 閲覧：開発者、運用者、委託先の誰がアクセスできるか。
- 削除：本人請求、契約終了、保存期限でどこを消すか。
API本体だけを図にしても不十分です。プロキシ、クラウドログ、エラー監視、分析基盤、開発端末へ入力が複製されることがあります。特にエラー時に本文全体を記録する実装は、通常処理より長く個人情報を残す原因になります。ログには業務ID、時刻、モデル、成否、トークン数などを残し、本文は原則残さない設計を検討します。
削除・マスキング・送信可を項目ごとに決める
問い合わせ分類が目的なら、氏名や電話番号は不要な場合があります。回答文の宛名が必要でも、分類工程では仮IDへ置換し、最終出力を社内側で氏名と結合できます。郵便番号の地域分析なら番地を削除し、生年月日が不要なら年代へ集約します。業務目的に必要な粒度まで落とすことが最小化です。
単に伏字へ変えるだけでは再識別を防げないことがあります。勤務先、役職、具体的な事件、日時の組み合わせから人物を推測できるためです。自由記述には、氏名、住所、電話、メール、顧客番号、口座、健康、苦情内容などが混在します。正規表現だけに頼らず、代表データと例外データで除去率を確認し、見逃し時の停止方法を決めます。
出力側も確認します。モデルが入力を要約する際に、不要な個人情報をそのまま再掲する場合があります。出力スキーマを「分類、理由、信頼度、要確認」に限定し、自由文を減らします。最終的に人へ表示する前に、禁止項目検査と人間確認を置きます。
契約とDPAで責任分界を読む
AnthropicのDPAは、顧客を管理者、Anthropicを処理者とする関係、文書化された指示、再委託先、データ主体請求、セキュリティ、事故通知等を定めています。自社が別企業から処理を受託している場合は、自社が処理者となる契約とのつながりも確認します。DPAがあること自体ではなく、今回のデータ、目的、地域、委託関係に適用できるかを法務・プライバシー担当と照合します。
Commercial Termsでは、出力の正確性を独立して確認し、人間レビューの必要性を判断する責任が顧客側にあることも示されています。個人に影響する採用、審査、医療、与信、懲戒などでAPI出力を自動決定に使う場合は、プライバシー以外の法令、差別、説明、異議申立てまで別途確認します。
実装前の10項目チェックリスト
- 処理目的と期待出力を一文で定義した。
- 本人への説明と適用法令を担当者が確認した。
- 入力項目を削除、マスキング、送信可へ分類した。
- 自由記述の再識別リスクを代表データで試した。
- Commercial Terms、DPA、対象サービス条件を確認した。
- 再委託先、地域、第三者接続を確認した。
- APIキーと閲覧権限を最小化した。
- 本文を残さないログ設計と保存期限を決めた。
- 本人請求、契約終了、障害時の削除手順を試した。
- 漏えい、誤出力、規約変更時の停止責任者を決めた。
十項目のうち一つでも答えられない場合は、本番データを送らず、架空データまたは十分に匿名化したデータで設計を検証します。特に「保持期間はベンダーが決める」「削除は後で考える」という状態では、本人請求や事故時に対応できません。自社システム側のログとバックアップも削除対象に含めます。
APIキーと環境を分け、送信範囲を技術的に止める
ルール文書だけで個人情報の誤送信を防ぐのは困難です。開発、検証、本番でAPIキーとプロジェクトを分け、開発環境は架空データだけに制限します。本番キーはサーバー側の秘密管理へ置き、ブラウザ、共有シート、ソースコード、チャットへ貼りません。呼び出せるサービス、担当者、月額上限を絞り、不要になったキーは失効させます。
送信直前には許可項目の一覧と照合し、禁止項目を検出したらAPIを呼ばず保留キューへ送ります。失敗時も本文を例外メッセージへ出さず、業務IDとエラー分類だけを記録します。監視画面には件数、失敗率、削除・マスキング件数を表示し、本文を見なくても異常を検知できる状態を目指します。
段階導入と事故時の止め方
最初は公開情報または架空データで疎通し、次にマスキング済みデータ、最後に承認された実データへ進みます。各段階で入力例、出力、ログ、権限、費用を確認します。個人情報の見逃し、出力への再掲、想定外ログ、第三者送信を検知したらAPIキーを停止し、キューを止め、対象IDと時刻から影響範囲を特定できるようにします。
入力情報の一般ルールはClaudeへ入力してはいけない情報、APIモデル選定はClaude API最新モデルの選び方、費用とログ設計はClaude API料金の削減手順、会社全体の確認は企業利用のセキュリティ確認も参照してください。
公開直前にはAnthropic Commercial Terms、Anthropic DPA、商用データの学習利用案内、Trust Centerを確認します。Miraigentの無料診断では、七地点のデータフローと十項目チェックを自社のAPI構成へ落とし込みます。