保有個人データの台帳を作り、公表項目と実態の食い違いを洗い出す

処理の起点を決める

トリガーは3つです。

1つ目は、定期の棚卸です。四半期ごとに対象を選び、処理を走らせます。年1回の一斉棚卸にしないでください。 45件を一度に見ると、担当者の負荷が集中し、形だけの確認になります。

2つ目は、新しいシステムを導入するときです。導入の申請が出た時点で、どんな個人データを扱うかを整理します。 事後の棚卸で見つけるより、はるかに手間が少なくなります。

3つ目は、業務委託先を追加するときです。委託契約の締結時に、委託する個人データの範囲を台帳に登録します。

2つ目と3つ目が、この構成の本当の価値です。 増えたときに記録する仕組みがないから、棚卸が重くなります。

入力データを集める

「個人データの項目の定義」を先に作ってください。

氏名やメールアドレスは明らかですが、判断が分かれるものがあります。

この判断は法務が行うべきものです。 社内の基準を決めて文書にしてください。AIに判断させないための前提です。

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

文書の収集： SharePointのフォルダから取得します。仕様書が存在しないシステムがあることが、多くの企業の実態です。 その場合は、データベース定義（テーブル定義書）だけでも大きな手がかりになります。

データベース定義： テーブル名とカラム名、コメントを取得します。user_name、tel、birth_date といったカラム名から、個人データの所在が分かります。 ただし、カラム名が col_01 のような命名の場合は手がかりになりません。

SaaSの一覧： 情報システムの契約台帳から取得します。部門が個別に契約しているSaaS（いわゆるシャドーIT）は、この一覧に載っていません。 経費精算のデータから、SaaSへの支払いを洗い出す方法もあります。

プライバシーポリシー： 自社サイトの公表内容をそのまま取得します。改訂履歴も残してください。 「いつからこの記載になっているか」が、後から問われることがあります。

AIへ渡す前に整形する

1. 文書の種別判定 … 仕様書／画面定義／DB定義／手順書／契約書を分けます。それぞれ読み取り方が違います
2. 対象システムの特定 … 文書がどのシステムのものかを紐づけます
3. 個人データの項目の候補の抽出 … 社内基準に照らして、候補となる項目を拾います
4. 公表しているプライバシーポリシーの構造化 … 利用目的の記載を1件ずつに分けます
5. 既存台帳の読み込み … 前回の棚卸結果を用意し、差分を見られるようにします
6. 委託先の一覧の整理 … 契約書から、委託する個人データの範囲を取ります

AIに処理させる

AIに次のことをさせないでください。

「問題ありません」と書かせないことが、特に重要です。 個人情報の取扱いは、少しの条件の違いで結論が変わります。AIが「適法です」と書いた記録が社内に残ると、後から「知っていたのに対応しなかった」と評価される材料になり得ます。

指示内容を固定する

あなたは、個人データの棚卸を支援する担当者です。
文書から、個人データに当たる項目とその取扱いの記載を抜き出してください。

【厳守事項】
- ある項目が個人データに当たるかを、あなたが判断しないでください。
  下記の社内基準に載っている項目名・パターンに一致するものだけを拾ってください。
  判断に迷う項目は candidates_to_review に入れ、理由を書いてください。
- 要配慮個人情報に当たるかを断定しないでください。
  健康・病歴・信条・犯罪歴などに関係しうる項目には
  sensitive_flag を true にし、「該当の可能性あり」とだけ書いてください。
  「要配慮個人情報に該当します」と書かないでください。
- 法令に適合しているかを判断しないでください。
  「問題ありません」「適法です」「同意が必要です」と書かないでください。
- プライバシーポリシーの改訂案を書かないでください。
- 文書に書かれていないことを補わないでください。
  利用目的・保管期間・委託の記載が見つからない場合は null とし、
  missing_information に項目名を入れてください。
  「通常は〜と考えられます」と書かないでください。
- 抽出した記載には、出典（文書名と該当箇所）を必ず添えてください。
  出典のない記載を出さないでください。
- 公表しているプライバシーポリシーとの対応は、
  「この記載に対応すると考えられる」という候補として示してください。
  対応する記載がない場合は "no_matching_purpose" とし、
  「対応する記載が見つかりません」と書いてください。
  それが違反であるとは書かないでください。

【個人データの項目の社内基準】
{personal_data_criteria}

【公表しているプライバシーポリシーの利用目的（1件ずつ）】
{privacy_policy_purposes}

【対象システム・業務】
{target_name}

【参照する文書】
{documents}

【前回の棚卸結果】
{previous_inventory}

「個人データに当たるかを判断しないでください」の1行が、この構成の安全装置です。 これを書かないと、AIは学習内容に基づいて「これは個人情報に該当します」と判断します。個人情報保護法の解釈は改正やガイドラインの更新で変わるため、学習時点の理解に基づく判断は危険です。

「対応する記載がないことを違反と書かない」も必ず入れてください。 利用目的の公表方法は複数あり、プライバシーポリシー以外で対応している場合もあります。違反かどうかは法務が判断します。

出力形式を固定する

{
  "target_id": "",
  "target_name": "",
  "target_type": "system | business_process | outsourcing | paper_record",
  "data_items": [
    {
      "item_name": "",
      "found_in": "",
      "source_quote": "",
      "matched_criteria": "",
      "sensitive_flag": false,
      "purpose_of_use": { "text": "", "source": "" },
      "retention_period": { "text": "", "source": "" },
      "outsourced_to": { "text": "", "source": "" },
      "storage_location": { "text": "", "source": "" }
    }
  ],
  "policy_matching": [
    {
      "item_name": "",
      "extracted_purpose": "",
      "matched_policy_purpose": "",
      "match_status": "matched | partial | no_matching_purpose"
    }
  ],
  "missing_information": [],
  "candidates_to_review": [],
  "changes_from_previous": [],
  "questions_to_department": [],
  "extraction_warnings": []
}

source_quote（文書の原文）を必ず残します。 「氏名を扱っている」とだけ書かれても、担当者は確かめられません。どの文書のどこにそう書いてあるかが必要です。

missing_information が、この構成でもっとも価値のある出力です。 「この項目について、保管期間の記載がどこにもない」という事実が分かります。これが、担当部門に聞くべきことです。

match_status: no_matching_purpose は、公表内容との食い違いの候補です。 違反の断定ではありません。法務が評価します。

changes_from_previous には、前回の棚卸からの変化を入れます。 「新しい項目が3つ増えている」「委託先が1社追加されている」といった差分です。

なお、Claude API には出力をJSONスキーマに沿わせる構造化出力の機能があります（2026-09-17時点ではベータ機能として提供）。項目が多い出力なので、利用できると形の崩れを防げます。

システムへ連携する

プライバシーポリシーの改訂を自動化しないでください。 公表文書であり、改訂には法務の確認と、場合によっては経営の承認が必要です。

台帳の更新は、担当部門の確認を経てから行ってください。 文書から抽出しただけの内容を台帳に入れると、「文書には書いてあるが実際には使っていない項目」が台帳に残ります。

人が確認する

すべての抽出結果を、担当者と法務が確認します。

3〜5と7は、法的な評価です。 この構成の外側にあります。材料をそろえることで、法務がそこに時間を使えるようにする、というのが狙いです。

例外に対処する

記録を残す

• 参照した文書の一覧（版数と日付つき）
• 抽出結果と、その原文
• 担当部門の確認結果（実際に扱っているか）
• 法務の評価と、その判断日
• 台帳の更新履歴
• プライバシーポリシーの改訂履歴
• 次回の棚卸の予定日

「法務の評価と判断日」を必ず残してください。 個人情報保護委員会からの照会や、本人からの開示請求があったときに、「いつ、何を確認して、どう判断したか」を説明する必要が生じることがあります。

台帳そのものが機密情報です。 「どのシステムに、どんな個人データがあるか」の一覧は、攻撃者にとって価値の高い情報です。 閲覧権限を厳しく設定してください。