Claudeにログを渡す前に確認する個人関連情報の線引き — Cookie・広告IDと31条

アクセスログやアドテクのログには、Cookie IDや広告IDが並んでいます。氏名もメールアドレスも入っていないので、そのままClaudeに貼って集計を頼みたくなる場面です。

結論から言うと、IDだけのログは「個人情報」ではなく「個人関連情報」に当たることが多く、扱いは軽くなります。ただしこの線引きは、手元の顧客台帳などと容易に照合できるかどうかで動きます。照合できる状態なら、同じログが個人情報に変わります。

個人関連情報には、個人情報保護法の第31条という独自の規制もあります。ログを外部に出す側が確認すべきことは何か、Claudeに渡すログをどう作ればよいかを、法令と個人情報保護委員会(PPC)の資料に沿って確認します。

個人関連情報とは何か — 個人情報との違い

個人関連情報は、法第2条第7項で定義されています。生存する個人に関する情報であって、個人情報・仮名加工情報・匿名加工情報のいずれにも該当しないものです。

つまり「個人に関する情報だが、特定の個人を識別できないもの」を指します。PPCの通則編ガイドラインは、個人関連情報に当たる例として次を挙げています。

ここで見落としやすいのが、統計情報は含まれない点です。ガイドラインは、特定の個人との対応関係が排斥されている統計情報は「個人に関する情報」に当たらず、個人関連情報にもならないとしています。ページ別・時間帯別の件数のように、個人との対応が切れた集計値は、この規制の外側にあります。

もう一つ、個人関連情報であることと個人情報であることは両立しません。個人情報に当たる場合は、個人関連情報には当たらなくなります。ガイドラインは位置情報を例に、単体では個人情報でなくても、連続的に蓄積されて特定の個人を識別できるようになれば個人情報になると説明しています。

Cookie IDと広告IDは個人情報か個人関連情報か

PPCのQ&A(Q8-1)は、Cookie等の端末識別子について次のように整理しています。

• 個人情報に該当しない場合、通常は端末の利用者に関する情報として「個人に関する情報」になり、個人関連情報に当たる
• 家族などの特定少数で端末を共用していても、共用者それぞれとの関係で個人関連情報に当たる
• 他の情報と容易に照合して特定の個人を識別できる場合は、その情報とあわせて全体として個人情報になる

最後の項目は、法第2条第1項第1号のかっこ書き(他の情報と容易に照合でき、それにより特定の個人を識別できることとなるもの)に対応します。

つまり、冒頭の疑問に答えると次のとおりです。

• Cookie IDだけが並ぶログは、通常は個人関連情報
• 同じCookie IDを会員ID・メールアドレス・氏名と結び付ける表を自社が持ち、すぐに突合できる状態なら、そのログは個人情報

広告ID(端末に割り当てられる識別子)は、Q&Aが名指ししているわけではありません。端末識別子という点で同じ整理になると考えられますが、個別の事案ごとの判断になります。

ここで押さえたいのは、突合を実際に行ったかどうかより、容易に突合できる状態にあるかが判断の軸になる点です。ガイドラインも、提供先が個人データに直接紐付けて利用しない場合は、容易照合性が排除しきれなくても直ちに「個人データとして取得する」には当たらない、と書いています。第2条の個人情報該当性と第31条の適用は、別々の問いです。

第31条が止めているのは何か

第31条は、個人関連情報をデータベースとして持つ事業者に向けた規定です。提供先の第三者が、その個人関連情報を個人データとして取得することが想定されるとき、次の確認なしに提供してはならない、という内容です。

1. 提供先が、本人が識別される個人データとして取得することを認める本人の同意が得られていること
2. 提供先が外国にある場合は、その国の個人情報の保護に関する制度などの参考情報が本人に提供されていること

誤解されやすいのですが、この条文は個人関連情報の第三者提供一般を禁じるものではありません。Q&A(Q8-3)は、提供先が個人データとして取得することが想定される場合に限って第31条第1項が適用される、と明記しています。

「個人データとして取得する」とは

ガイドライン(3-7-1-1)は、提供先が個人データに個人関連情報を付加するなど、個人データとして利用しようとする場合をいうとしています。提供を受けたIDを介して、提供先が持つ他の個人データに付加する場合は該当します。

「想定される」とは

ガイドライン(3-7-1-2)は、2つの場合を挙げています。

• 提供元が現に想定している場合。例えば、顧客情報を持つ提供先に、IDを使えば個人データと紐付けて取得できると説明している場合や、提供後に紐付けると告げられている場合
• 一般人の認識を基準に通常想定できる場合。例えば、氏名等と紐付けて使う前提で、そのためのIDも併せて提供する場合

契約と提供時点の基準

提供先との契約等で「個人データとして利用しない」と定めてあれば、通常は想定されず、第31条は適用されません(3-7-1-3)。ただし、実際には個人データとして使っている事情がうかがわれるなら、取扱いの確認が必要になります。

判断の基準時点は、提供時点です(Q8-4)。事後に提供先が個人データとして使ったと分かっても、提供元が直ちに第31条第1項に違反するわけではありません。一方で、利用意図を隠して本人同意なく取得した提供先の側は、法第20条第1項(不正の手段による取得の禁止)に違反することになります。

なお、委託・事業承継・共同利用のように個人データの第三者提供で使える例外(法第27条第5項各号)に相当する規定は、第31条にはありません(Q8-8)。「委託先だから確認不要」とはならず、あくまで個人データとして取得されるかどうかで決まります。

Claudeに渡すログを3つに分けて考える

では、分析用ログをClaudeに渡す場面にこれを当てはめます。ログの持ち主(自社)は、第31条でいう提供元になりえます。Claudeの提供側は第三者です。次の3段階で考えると整理しやすくなります。

Bの場合、第31条の適用は「Claudeの提供側が、渡したIDを使って個人データとして取得するか」で決まります。顧客台帳を持たない提供先が、渡されたログだけで本人が識別される個人データとして取得する、という状況は通常は想定しにくいと考えられます。ただしこれは一般論で、提供するIDの種類や使い方によって個別に判断することになります。なお、第31条の確認をする場合は、確認の記録に関する第30条第2項から第4項の規定も準用されます(第31条第3項)。

Cで注意したいのは、突合を自社の側で済ませてから渡すケースです。この場合、第31条ではなく、個人データの外部提供の規律が掛かります。Claude APIを委託として使う構成で何が必要になるかは、越境移転と外的環境の把握の記事で扱っています。

自分でつなぐ前に気づきたいこと

実務で起きやすいのは、Claudeに分析を頼む過程で、Claude自身にSQLを書かせてログ表と顧客表を結合させる流れです。BigQueryなどに接続して実行すると、結合結果は自社環境の中で個人情報になります。その結果をさらにClaudeの会話へ貼ると、Cの扱いになります。

結合を許す設計かどうか、結果をどこまで会話に出すかは、あらかじめ決めておく必要があります。

分析用ログの作り方 — 列を落として集計する

方針は単純です。個人との対応が切れる形にしてから渡します。IDの値を伏せるだけでなく、列ごと落とし、時刻を粗くし、少数のセルを除きます。

下のスクリプトは、JSON Lines形式のアクセスログを「時間帯 × パス × イベント」の件数表に変換します。IDや生のIPアドレスは出力に残りません。

import collections, csv, json, sys
 
MIN_COUNT = 5  # 少数セルは出さない(目安であり、法令上の数値ではない)
 
counts = collections.Counter()
with open(sys.argv[1], encoding="utf-8") as f:
    for line in f:
        row = json.loads(line)
        path = row["path"].split("?")[0]   # クエリ文字列を落とす
        hour = row["ts"][:13]              # 時間単位まで丸める
        counts[(hour, path, row.get("event", "view"))] += 1
 
out = csv.writer(sys.stdout)
out.writerow(["hour", "path", "event", "count"])
for (hour, path, event), n in sorted(counts.items()):
    if n >= MIN_COUNT:
        out.writerow([hour, path, event, n])

実行は、Claude Codeの外側で自分で行います。理由は次の節で述べます。

python3 mask_log.py logs/raw/access.jsonl > logs/masked/access.csv
grep -cE '[0-9a-f]{8}-[0-9a-f]{4}|@' logs/masked/access.csv

2行目は、UUID形式のIDやメールアドレスらしき文字列が残っていないかの簡易確認です。結果が0なら、少なくとも典型的な形のIDは出力に含まれていません。検出できるのは形が決まったものだけなので、列の設計そのものを見直す代わりにはなりません。

IDをハッシュにすればよいのか

Cookie IDをハッシュ値に置き換えれば安全、とは言い切れません。台帳側にも同じ変換のキーがあり、ハッシュ同士で結合できる状態なら、容易照合性は残りえます。ガイドラインもID等を介して付加する場合を「個人データとして取得する」場合に挙げています。

ハッシュ化は、列として残す必要があるときの次善策です。分析の目的がページ別の傾向なら、ID列は最初から要りません。

Claude Code側で生ログを読ませない設定

Claude Codeを使うなら、生ログのあるディレクトリをReadの拒否ルールに入れておくと、ファイルツールでの誤読を防げます。.claude/settings.json に次のように書きます。

{
  "permissions": {
    "deny": ["Read(./logs/raw/**)"]
  }
}

公式のドキュメントは、Claudeのファイルツールに読ませたくないファイルやディレクトリには、このようにReadの拒否ルールを置くよう案内しています。ただし適用範囲には限りがあります。Read・Editの拒否ルールが及ぶのは、組み込みのファイルツール、Bash内で認識される cat や head などのファイルコマンド、リダイレクトの対象です。

一方で、ファイル名を指定せずに読むコマンド(ディレクトリ内で実行する grep -r など)や、PythonやNodeのスクリプトがファイルを自分で開く場合は対象外です。OSレベルで全プロセスのアクセスを止めたいときは、サンドボックスを有効にする必要があります。

このため、前処理スクリプトはClaudeに実行させず、人間が自分で動かすほうが確実です。Claudeに任せるのは、マスク済みのCSVを読んだ集計や、前処理スクリプト自体のレビューにとどめます。

CLAUDE.mdには、次のような規約を書いておくとよいでしょう。

## ログの取り扱い
- 分析対象は logs/masked/ の件数表のみ。logs/raw/ は読まない
- Cookie ID・広告ID・IP・ユーザーIDの列を含むデータを見つけたら、
  処理を止めて報告する
- 顧客テーブルとログ表を結合するSQLは書かない

CLAUDE.mdの記述は指示であって、強制力のある制限ではありません。強制したい部分は上のパーミッション設定で担保します。

取り違えたときに起きること

個人関連情報を提供する事業者が第31条第1項に違反した場合、個人情報保護委員会は勧告や命令を行えます(法第148条)。命令に違反すると、1年以下の拘禁刑または100万円以下の罰金です(法第178条)。

いきなり刑事罰に至る条文ではなく、まず勧告・命令を経る構造です。それでも、広告・分析の外部提供でIDをやり取りしている事業者は、提供先が個人データとして使う前提がないかを契約で確認しておく意味があります。

判断に迷いやすい点

外部ツールのタグはどうなるか

PPCのQ&A(Q8-10)は、A社のサイトにB社のタグが設置され、A社がそのタグで集まる閲覧履歴を取り扱っていないなら、A社がB社に提供したことにはならない、としています。この場合B社が直接ユーザーから取得した扱いになり、第31条は適用されないと考えられます。なお、B社が個人情報として取得するなら、不正の手段による取得の禁止(法第20条第1項)と、利用目的の通知・公表(法第21条第1項)は引き続き必要です。

同意はどう取るか

第31条の同意は、提供先が個人データとして取得することを認める旨の本人の意思表示です。ウェブサイトで取る場合は、事項を掲載するだけでは足りず、ボタンのクリックなどを求める方法が必要とされています(ガイドライン3-7-2-3)。同意は提供のたびに取る必要はなく、本人が予測できる範囲で包括的に取ることもできます。

個人情報が混ざっているときは

ログに病歴や信条にあたる記述が紛れている場合は、要配慮個人情報にあたり、取得に原則として本人の同意が必要になるなど規律が重くなります。詳しくは要配慮個人情報の入力にあります。マイナンバーを含む場合は、さらに別の厳しい制限が掛かります(特定個人情報の入力)。

Claudeにどこまで任せるか

マスク済みの件数表の集計と、前処理スクリプトのレビューまでが目安です。顧客表との結合や生ログの読み取りは任せません。一次資料の探し方はClaudeに個人情報を入力する前の一次資料にまとめています。

まとめ

Cookie IDや広告IDは、単体なら個人関連情報で、顧客台帳などと容易に照合できる状態なら個人情報です。第31条が止めるのは、提供先が個人データとして取得することが想定される場合の提供に限られます。

Claudeに分析用ログを渡すなら、次の3点を先に確認します。

• ログが台帳と突合できる状態にないか
• ID列・IP・クエリ文字列を落とし、集計値にできないか
• 生ログを置く場所を、Readの拒否ルールとサンドボックスで分けているか

IDの値を伏せるより、列ごと落として集計する前処理のほうが、個人との対応を確実に切れます。