データ所在地と削除請求への対応方針を docs に残す

[TinyKitten]

背景

MobileApp のテレメトリ本番オプトインにあたり、プライバシーポリシーへ書く内容を洗い出している（TrainLCD/MobileApp#6982 の docs/telemetry-production-optin-risk.md）。ポリシー側から引用できる形で、基盤側の docs に残しておきたい事項が 2 つある。

1. データ所在地

THQ は TinyKitten が管理する国内のサーバで動き、Cloudflare 経由で公開している。保管も国内で完結し、第三者への提供も無いため、外国にある第三者への提供（個人情報保護法 28 条）と、外国で取り扱う場合の「外的環境の把握」（安全管理措置）はどちらも論点にならない。

やることは、この事実を docs に書いてポリシー改定時に引用できるようにすること。稼働構成そのものは公開ドキュメントに詳細を書かず、「TinyKitten が管理する国内のサーバ」という粒度に留める。

2. 削除請求への対応方針

MobileApp は sessionId をプロセスごとの使い捨て UUID として生成しており、端末側に残らない。ただし「端末に ID が残らない」ことは「データ主体を特定できない」ことを意味しない。連続した移動軌跡・時刻・端末モデル・アプリバージョンが揃っているため、照合可能性を評価したうえで方針を決める必要がある。

取りうる方針は次のどちらか。

• A: 特定を要しない取扱いとして運用する — 匿名性の高い状態を維持し、個別特定ができない旨と、その場合の説明手順をポリシーに書く。保持期間満了による削除（位置ログ・ログイベントの保管期間を決めて自動削除を実装する #36）が唯一の消え方になる。請求者が特定に足る追加情報を出してきた場合は再評価する。
• B: 削除可能にする — installId など端末安定 ID に紐付けて削除 API を用意する。匿名性は下がり、「端末ごとの識別子で移動軌跡が追える」状態になるため、ポリシー上の説明も重くなる。

テレメトリの目的が個別追跡ではなく品質計測であることを踏まえると A を推したい。決めて docs に書き残す。

受け入れ条件

• データ所在地が docs に書かれている
• 削除請求への対応方針が A / B のどちらかで決まり、根拠つきで docs に書かれている
• 上記が MobileApp 側のプライバシーポリシー改定に引用できる状態になっている

優先度

本番オプトインの前提条件（ポリシー改定の文面が確定しない）。実装より先に決めの問題。