kimura512.dev のプライバシーポリシーを実装に合わせて直した話

結論

kimura512.dev のプライバシーポリシーは、実装と食い違っていた部分を直すために何度か書き直しました。広告を載せる前に整えたかったのは「審査用の文章」ではなく、問い合わせフォーム・解析・広告で実際にデータが流れる先と、ポリシーの説明を一致させることです。

1. サイトとアプリを分けて書く

以前の文面は、ポートフォリオサイトと別アプリ（酔愛マップ）を一つの「本サービス」として説明しており、アカウント登録やパスワードの保存まで書かれていました。kimura512.dev 単体にはアカウント機能は無く、問い合わせフォームとブログ閲覧が中心です。ポリシーは「このドメインで起きること」と「別アプリで起きること」を節で分け、読者が自分に関係する部分だけ追えるようにしました。

2. 第三者提供の見直し

実際に使っているのは Cloudflare Workers、問い合わせメール送信、Vercel Analytics、Google AdSense です。使っていないサービス名をポリシーに残すと、実装と説明がずれた状態になります。一覧はコードと設定を見ながら一つずつ照合し、載せるサービスだけに絞りました。

3. ads.txt とドメイン

public/ads.txt を apex で配信し、掲載者 ID がメールの運営者 ID と一致することを確認しました。サブドメインにだけ置いて apex で見えない、といったミスは認証で詰まりやすいので、本番 URL で直接開いて確認する習慣をつけました。

4. 広告スクリプトの置き場所

AdSense の読み込みスクリプトはブログ一覧・記事の layout にだけ入れています。チャットや画像生成は noindex の機能ページで、そこに広告コードを入れない方針です。利用者が操作している画面と、広告の表示範囲を分けるためです。

5. Cookie の説明

ブログ閲覧では Google AdSense による Cookie が使われる可能性があるため、ポリシー第12節で広告 Cookie に触れています。同意バナーを必須にするかは施策次第ですが、少なくともポリシー上で AdSense と Cookie の関係を書いておく必要がありました。設定を変えたときは最終更新日も更新します。

6. 問い合わせフォーム

Contact から送られた名前・メール・本文は、Workers 経由で info@kimura512.dev に届きます。フォームに honeypot を入れ、スパム送信には返信しない運用です。ポリシーでは「問い合わせのために提供された情報」の利用目的を、サポート対応に限定して書きました。

7. 更新のしかた

ポリシーを変えたら最終更新日を必ず変え、変更前後の差分を読み直します。音読して違和感がある文は、実装と合っていないサインだと感じています。英語版も主要な節は日本語と同じ内容に揃えています。

第三者提供の一覧は、サービス名と「何のために使うか」を一行で書く形に揃えました。リンクだけ並べるより、審査員が kimura512.dev 単体で何が動くかを追いやすくなります。プライバシーを直したあと、About とフッターのリンク表記もあわせて見直しました。運営者名・メール・サイト URL がページごとに違うと、ポリシーだけ直しても全体の信頼感は上がりません。変更は小さくても、関連ページをセットで更新する方が手戻りが少ないです。

Cookie の節は、ログイン機能が無いページでも広告用 Cookie だけは書く必要があると学びました。実装に無い認証 Cookie の説明は削り、AdSense と解析だけに絞りました。

英語版は日本語と同じ構成に揃え、他言語は英語を参照する形にしています。翻訳を全部手で揃えるより、矛盾が出にくい運用です。更新日はポリシー本文とフッター表記を同じ日付に揃えています。小さな修正でも日付を更新すると、古い説明が残っていると誤解されにくくなります。

まとめ

ポリシーは「あるべき姿の宣言」ではなく、今の実装の説明書として保守するものです。サイトを変えたらポリシーも同じ PR で直す、というルールにすると、あとから読み返しても矛盾が少なくなります。

補足

Q. バナーは？

現状はポリシーへの記載が中心です。必要になれば、同意 UI を別途検討します。

Q. 英語ポリシーは？

日本語版を正とし、英語版は主要な節を同じ内容に揃えています。