保有個人データの開示請求対応をClaudeで整える — Projectsに判断表を置く

保有個人データの開示請求が届いたとき、社内で迷うのは「誰の請求か」「どこまで出すか」「出さないなら何と返すか」の3点です。この3点は請求ごとに変わりません。変わるのは請求者と対象データだけです。

そこで、判断の基準と回答文案の型をClaudeのProjectsに置き、請求者の個人情報は置かない設計にします。基準は共有し、個別の請求は1件ずつ別のチャットで処理する、という分け方です。この記事は、その土台になる条文の整理と、Projectsの組み方、請求ごとの回し方をまとめます。

開示請求を「受ける側」の話です。自分のデータをClaudeの運営側に請求する方法はClaudeに自分の個人情報の開示を請求する手順で扱っています。

Projectsに置くものと、置かないもの

Projectsは、ナレッジに入れた資料と指示を、そのProject内の全チャットで使い回せる仕組みです。ナレッジは文書・テキスト・コードなどをアップロードして作り、指示は「Set project instructions」から保存します。Project内のチャットは、ナレッジに入れた情報しか共有しません。

この性質を開示請求に当てはめると、置いてよいものと置いてはいけないものが分かれます。

請求者の個人情報をナレッジに入れない理由は、Projectsの共有範囲にあります。Team・Enterpriseプランでは、Projectを組織全体や特定メンバーに共有でき、「Can view」の権限でもナレッジと指示を閲覧できます。ナレッジに請求書面を入れると、共有先の全員に見えます。

受付の前に決めておく手続

開示等の請求を受ける側は、受け付ける方法を定められます。法第37条第1項と政令第12条が、定められる事項を4つ挙げています。

定めた手続は、本人の知り得る状態(本人の求めに応じて遅滞なく回答する場合を含む)に置く必要があります。合理的な方法を定めて公表していれば、その方法に従わない請求は拒否できます。ただし、必要以上に煩雑な書類を求めたり、窓口を不便な場所に限ったりして、本人に過重な負担を課してはなりません(法第37条第4項)。

手続を定めていない場合は、自由な申請を認めることになる点にも注意が必要です。まず規程の有無を確かめることが、判断表の1行目になります。

代理人からの請求も受けられます。政令第13条が認める代理人は、未成年者または成年被後見人の法定代理人と、本人が委任した代理人の2種類です。

請求ごとの判断表を6つの問いに分ける

請求を受けた担当者が上から順に答えれば、結論まで進める形にします。条文の順序に合わせると次の6つです。

本人確認は「必要以上に求めない」が条件

ガイドラインは、確認方法の事例を受付方法ごとに挙げています。来所なら運転免許証やマイナンバーカード表面など、オンラインならあらかじめ登録済みのIDとパスワードや公的個人認証による電子署名、電話なら登録済みの生年月日とコールバック、郵送なら公的証明書のコピーの送付を受けて、そこに書かれた住所へ書留郵便で文書を送る方法です。

同じ箇所に、本人確認のために事業者が保有している個人データに比べて必要以上に多くの情報を求めない、という配慮も書かれています。たとえばメールアドレスしか保有していない会員に、運転免許証の提出を一律に求める設計は、この配慮に合うか見直す余地があります。判断表の本人確認欄は、受付方法ごとに「ここまでで足りる」線を決めて書いておくと、担当者が過剰な書類を求めずに済みます。

対象の特定は、範囲を絞らせる権利ではない

法第37条第2項は、対象の特定に足りる事項の提示を求められるとしています。ガイドラインはこの規定を、開示を請求する範囲を本人に一部に限定させる権利を事業者に認めるものではない、と説明しています。「全部」と書かれた請求を、勝手に「会員情報だけ」と読み替えることはできません。

開示の方法と期限

法第33条第1項は、電磁的記録の提供による方法その他の規則で定める方法による開示を請求できると定めています。規則第30条の方法は、電磁的記録の提供、書面の交付、事業者の定めた方法です。電磁的記録の事例は、媒体の郵送、メール添付、会員サイトからのダウンロードの3つです。

本人が請求した方法での開示が難しい場合(大規模なシステム改修が要る、書面管理の小規模事業者が電磁的対応できないなど)は、その旨を通知したうえで書面の交付で開示します。

応答の期限は、条文上は「遅滞なく」とあるだけで、日数の定めはありません。社内で目標日数を置くかどうかは、自社の判断になります。一方で、法第39条は、本人が開示請求に関する訴えを起こすには、請求の到達から2週間が経過してからでなければならないとしています。ただし、事業者が請求を拒んだときはこの限りでありません。理由を説明せず単に拒む旨を通知した場合も「拒んだとき」に含まれるとガイドラインは述べているため、拒否の通知の書き方は軽く扱えません。

不開示にできるのは3つの事由だけ

法第33条第2項は、開示により次のいずれかに当たる場合に、全部または一部を開示しないことができると定めています。判断表の5行目は、この3つを選択肢にして、当てはまる根拠をメモする形にします。

2つ目の事由は「単なる支障ではなく、より重い支障を及ぼすおそれがある例外的なとき」に限られる、とガイドラインは念を押しています。「量が多くて大変だから」は根拠になりません。

不開示と決めたとき、対象データが存在しないとき、請求された方法で開示できないときは、遅滞なく本人に通知します(法第33条第3項)。あわせて、措置をとらない旨を通知する場合は理由を説明するよう努める義務があります(法第36条)。回答文案には、この理由の欄を必ず設けます。

自社の取引先から預かった帳票のように、他の個人の情報が同じ書面に混在する場合は、本人分だけを開示し、残りを一部不開示とする判断になりえます。この「第三者の権利利益」の線引きこそ、人の判断が要る部分です。

Projectsの組み方

ナレッジに入れる資料

次の4種類を、請求者の情報を含まない形で作って入れます。

1. 自社の開示等の請求の受付手続(申出先、様式、本人確認方法、手数料)
2. 判断表(上の6つの問いと、不開示3事由の選択肢、自社のデータ項目ごとの保管先)
3. 条文とガイドラインの該当箇所の抜粋(法第33条・第36条・第37条・第38条、政令第12条・第13条、通則編3-8-2・3-8-6・3-8-7)
4. 回答文案の雛形(開示する場合、一部不開示、不存在、方法の変更、手続不備の補正依頼)

条文の抜粋は、出典の条番号と確認日を各ファイルの先頭に書いておきます。法令やガイドラインは改正されるので、Claudeが古い抜粋を根拠に答えることがないよう、更新日が見える形にする運用です。

有料プランでは、ナレッジが容量の上限に近づくとRAGモードが自動で有効になり、容量が最大10倍まで広がります。判断表と雛形だけなら、ここに達する量にはなりません。

プロジェクト指示の例

指示には、口調や役割を指定できます。開示請求向けに組んだ例が次です(自社に合わせて書き換えます)。

あなたは当社の個人情報の開示請求対応を補助する担当者です。
- 回答は、このプロジェクトのナレッジにある判断表と条文抜粋だけを根拠にする。
- 判断表の6つの問いを順に確認し、各問いの結論と根拠(ナレッジのファイル名と箇所)を表で示す。
- 根拠がナレッジにない場合は、推測で埋めず「ナレッジに記載なし」と書く。
- 不開示の可否は結論を断定せず、該当しうる事由と、人が確認すべき事実を挙げる。
- 請求者の氏名・住所・会員番号などは回答に繰り返さず、「請求者」と書く。

最後の行が、個別の個人情報を出力に広げない工夫です。出力に請求者名が並ぶと、それをコピーした文書が社内で流通しやすくなります。

請求ごとに回す手順

Project内のチャットは、ナレッジと指示を共有しますが、他のチャットの会話内容は共有しません。この性質を使い、1件の請求を1つのチャットで完結させます。

入力の例は次のとおりです。ここに氏名や会員番号は入りません。

請求番号: R-0042
受付方法: 会員サイトのフォーム(ログイン済みのIDとパスワードで確認済み)
請求内容: 会員情報と購入履歴の開示。方法は電磁的記録を希望
対象データ: 会員DBの基本情報、ECの購入履歴、問い合わせ対応履歴
気になる点: 問い合わせ履歴に、他の利用者が登場するやり取りが含まれる
判断表の6つの問いについて、結論・根拠・人が確認する事項を表にしてください。

問い合わせ履歴の例は、第三者の権利利益に関する不開示の判断が出る典型的な場面です。Claudeには「他の利用者が登場する部分を特定し、本人分と分けられるか」を確認事項として挙げさせます。結論は担当者が、実データを見て決めます。

個人情報をProjectsに残さないための設定

判断表と雛形を共通ナレッジにしても、運用の途中で個人情報がProjectに入り込む経路があります。

• メモリ: プロジェクトごとにメモリがあり、プロジェクト外のチャットとは分かれています。Team・Enterpriseではオーナーが有効にした場合に使えます。個別のチャットは、最初のメッセージを送る前に「+」メニューのMemoryをオフにすると、そのプロジェクトのメモリを使わず、追加もしません。請求の処理チャットは、この設定で始めます。
• 共有範囲: Team・Enterpriseでは、作成時にプライベートか組織全体かを選べます。判断表のProjectは、請求対応の担当者と法務に絞ります。管理者が共有を無効にしている場合、組織全体への共有は選べません。
• 削除: アーカイブしたProjectは削除できません。削除するにはアーカイブを解除してから操作します。Projectごと消すか、個別のチャットだけを消すかは、残してよい共通ナレッジがあるかで決まります。

また、請求者の情報をClaudeに入力する行為そのものが、個人データの取扱いになります。提供・委託のどちらとして整理されるかは個人情報を含むプロンプト入力は第三者提供にあたるかで扱っています。要配慮個人情報が含まれる請求(病歴や信条など)は、要配慮個人情報をClaudeに入力してよいかで確認した上でないと、入力の範囲を決められません。

つまずきやすい場面

Claudeの条文引用が、ナレッジの抜粋と食い違う。指示に「根拠はナレッジの箇所を示す」と書いても、抜粋にない内容を補って答えることがあります。出力の根拠欄にナレッジ内の箇所が書かれていない結論は、そのまま使いません。

判断表が古くなる。通則編は改正のたびに新旧対照表が公表されています。抜粋を入れ替えるときは、判断表の問いの順序や事例が変わっていないかも確認します。

開示後に漏えいが起きた。誤って別人のデータを開示した場合などは、開示請求の話ではなく漏えい対応の話になります。報告の下書きは個人情報の漏えい報告をClaudeで下書きする際の注意点にあります。

この記事の手順は現行のチャット版Projects向け。公式のヘルプには、会話がスレッドを束ねる新しい版のProjectsがClaude Codeから段階的に展開されていること、既存のチャット版Projectsは従来どおり動くことが書かれています。ここで使ったナレッジ、指示、メモリの区分は、従来のチャット版のものです。

まとめ

開示請求対応は、判断の型と個別の事実を分けると回しやすくなります。型は6つの問いと不開示3事由、回答文案の雛形としてProjectsに置き、個別の事実は請求ごとのチャットに限って、メモリをオフにして処理します。

Claudeに任せられるのは、判断表に沿った整理と文案の下書きまでです。本人確認の合否、不開示事由への該当、第三者の情報の切り分けは、担当者と法務が実データで決める部分になります。