個人情報の開示・訂正・利用停止の請求を、期限内に回して記録に残す

処理の起点を決める

トリガーは2つあります。 性質がまったく違うので、1本にまとめないでください。

受付を即時にするのは、請求かどうかの判断が早いほど、その後の日程に余裕ができるからです。届いた当日に「これは利用停止等の請求かもしれない」と分かれば、本人確認の案内をその日のうちに出せます。

書面や電話で届いたものは、担当者が問い合わせ管理システムに登録します。登録する先を1か所にそろえることが、この構成の前提です。 窓口が4つあっても、案件の置き場所は1つにします。

入力データを集める

「照会先の一覧」がこの構成の質を決めます。 どのシステムにどんな個人データが入っているかを、あらかじめ表にしておきます。ここが無いまま始めると、照会先を人の記憶から出すことになり、元の問題が残ります。

データの取得方法を決める

請求の文面： 問い合わせ管理システムから、新規案件の本文を取得します。フォーム経由なら項目が分かれているので、自由記述の欄をまとめて1つのテキストにします。

書面： 受け付けた担当者が文面を書き起こして登録します。画像のまま扱わないでください。 後段の切り分けも、記録の検索も、テキストでないとできません。

電話： 通話の内容を担当者が要約して登録します。このとき、本人の言葉をそのまま残す欄を分けて作ります。 担当者が「配信停止の依頼です」と要約してしまうと、利用停止等の請求だった可能性が消えます。

AIへ渡す前に整形する

1. 窓口ごとの体裁をそろえる … フォーム、メール、書面の書き起こし、電話の記録を、同じ形のテキストにします
2. 署名や定型文を除く … メールの末尾の署名やお知らせの文面は、判断に使いません
3. 本人が書いた部分と、担当者が補った部分を分ける … 電話と書面では担当者の記述が混ざります。どちらが本人の言葉かを区別できる形にします
4. 過去の案件との突き合わせ … 同じメールアドレスや会員番号で過去の請求があれば、その要約を添えます
5. 長い文面の扱い … 経緯が長く書かれていることがあります。要約せずにそのまま渡します。請求の意思は、本文の途中や末尾に書かれていることが多いためです

AIに処理させる

「どちらとも取れるものの識別」が、この構成でもっとも重要な処理です。 「もう連絡しないでほしい」という一文は、メール配信の停止の依頼かもしれませんし、利用停止等の請求かもしれません。AIに一つに決めさせると、決めた側に倒れます。 倒れた先が「通常の問い合わせ」だった場合、手続が始まらないまま案件が閉じます。

そこで、どちらとも取れるものには専用の区分を置き、必ず人が読む設計にします。件数は多くありません。その代わり、そこに手続の取りこぼしが集まります。

指示内容を固定する

あなたは、本人から届いた個人情報の開示等の請求を受け付ける担当者を支援する立場です。
届いた文面を読み、請求の種類を切り分け、対応に必要な情報がそろっているかを整理してください。

【厳守事項】
- 請求の種類は次の区分から選び、必ず配列で返してください。
  disclosure（開示）／ third_party_record（第三者提供記録の開示）／
  correction（訂正等）／ suspension（利用停止等）／
  other（請求ではない問い合わせ）／ ambiguous（どれとも取れる）
- 1つの文面に複数の種類が含まれることがあります。
  「登録内容を見せてほしい。間違っていたら直してほしい」は
  disclosure と correction の2つです。単一で返さないでください。
- どちらとも取れる文面は ambiguous にしてください。
  可能性の高いほうを選ばないでください。
  「もう連絡しないでほしい」のように、配信停止の依頼とも
  利用停止等の請求とも読める文面が該当します。
- 請求の対象範囲は、文面に書かれている場合だけ scope に書いてください。
  書かれていなければ not_specified としてください。
  「すべて」と書いてあるのか、特定のサービスだけなのかを推測で補わないでください。
- 本人を特定できる情報は、文面に記載があるものだけを true にしてください。
  記載がなければ不明として false にしてください。
- そう判断した根拠となる記述を、原文のまま quote に入れてください。
  要約しないでください。
- 法令の要件の判断、請求に応じるかどうかの判断はしないでください。
  判断が難しいものは needs_legal_review を true にしてください。
- 本人への回答文をここでは書かないでください。

【請求の文面】
{request_text}

【受付情報】
{intake_info}

【同じ本人からの過去の請求（あれば）】
{past_requests}

「可能性の高いほうを選ばないでください」という一文が、この指示の要です。 ふつうの分類では、迷ったときに最も近い区分を選ばせます。この業務ではそれが逆効果になります。 迷ったことが分かるほうが、後の処理が正しくなります。

「回答文をここでは書かない」も必要です。 切り分けと回答文の作成は別の処理にします。回答文は、関係部門から回収した結果がそろってから作るものだからです。

出力形式を固定する

{
  "request_types": ["disclosure", "correction"],
  "subject_identifiers": {
    "name": true,
    "member_id": false,
    "email": true,
    "phone": false,
    "address": false
  },
  "identity_verification": "not_started",
  "scope": "not_specified",
  "quote": "",
  "needs_legal_review": false
}

request_types を配列にすることが設計の中心です。 「登録内容を見せてほしい。間違っていたら直してほしい」という1通は、開示と訂正等の2つを含みます。単一選択にすると、片方が落ちます。落ちた側は誰にも気づかれません。

identity_verification は not_started／documents_requested／verified／insufficient の4つを持ちます。このうち documents_requested と insufficient が、待っている状態です。 ここを案件の項目として持つことで、（c）の「本人確認で止まっていることが見えない」が解けます。一覧で絞り込めば、待っている案件が全部出ます。

scope を推測で埋めさせないことも重要です。回答の範囲を決めるのが scope だからです。 書かれていなければ not_specified にして、本人に確認します。ここを推測で「すべて」と埋めると、本人が求めていない範囲まで集めることになります。

quote には、そう判断した元の記述をそのまま入れさせます。確認する人は、この1行を読めば判断の当否が分かります。 文面全体を読み直す必要がなくなり、確認の時間が縮みます。

システムへ連携する

照会の送信は自動で行い、回答の送付は人が行います。 社内への照会は、決まった先に決まった内容を送るだけなので自動化できます。本人への回答は、会社としての判断の表明です。自動送信にしません。

日次のスケジュールでは、回収状況と期限を見て、期日が近い案件の担当者に通知を出します。通知の宛先は、案件の担当者と、照会を受けている部門の両方です。 片方だけだと、どちらかが「相手が動いているはず」と思ったまま日が過ぎます。

人が確認する

全件、人が確認します。 確認の場面は3つあります。

ambiguous と needs_legal_review が付いた案件は、その日のうちに人が読みます。 ここを翌日に回すと、取りこぼしの発見が遅れます。件数は月40件のうち数件です。

確認を速くするための設計として、次を用意します。

• quote を切り分け結果のすぐ下に表示する（文面を開かせない）
• request_types が複数のものを目立たせる（照会先が増えるため）
• scope が not_specified のものを上に出す（本人への確認が要る）
• identity_verification で絞り込める一覧を作る（待ち状態の可視化）

例外に対処する

最後の行が重要です。 処理が失敗したときに案件が静かに閉じると、手続が始まらないまま期限が過ぎます。失敗は必ず人に見える形で残します。

記録を残す

• 受付日、受付経路、請求の文面（原文）
• 切り分けの結果と quote、人が直した場合は直した内容
• 本人確認の経過（依頼した書類、到着日、不備の内容、確認した日）
• 照会先と依頼日、回収日、回収した内容の所在
• 回答書の下書きと、確定した回答、回答日
• 督促を出した日時と宛先

2つ目の「人が直した内容」を残すと、この構成の弱点が見えます。 特定の言い回しが毎回 other と判定されて人が直しているなら、指示文を直せます。

対応の記録は、案件単位で1か所にまとめます。 受付から回答までが1つのレコードでたどれる状態が、（d）の「記録が残らない」への答えです。