プライバシーのケース集

このページは、プライバシーポリシーを「条文の順番」ではなく「利用者が実際に何をするか」の順番で読み直すためのケース集です。

プライバシーの話は、取得項目を一覧にするだけだと実際の感覚とずれやすく、利用者から見れば「このボタンを押したら何が起きるのか」「この欄へ書いた文字はどこへ行くのか」「この機能を使わなければその情報は処理されないのか」の方が重要なことが多いため、ここでは入力、保存、問い合わせ、AI、アカウント、公開、決済、海外利用といった場面ごとに追いかけます。

ケース1　ページを開いただけ

利用者がoka-projectのページを開いた時点では、まだフォームへ何も入力していなくても、Webページを取得するための通信は発生します。

その通信を成立させるため、IPアドレス、アクセス日時、アクセス先URL、ブラウザや通信に関する情報その他が、サーバー、CDN、セキュリティサービス等で処理される場合があります。

これは「入力した文章を取得している」という話とは別です。ページを見るための通信と、ツールへ入れたデータの処理は分けて考える必要があります。

ケース2　ブラウザ内ツールへ文章を貼る

ブラウザ内処理型のツールへ文章を貼り付け、その文章を端末内で変換するだけであれば、その主要な入力本文を変換目的のためにoka-projectのサーバーへ送信しない設計にできます。

ただし同じページでアクセス解析、CDN、セキュリティその他の通信が存在する可能性までなくなるわけではありません。

「入力本文を送信しない」と「端末外へ一切通信しない」は別の意味です。

ケース3　作業状態を保存する

作業状態をlocalStorageやIndexedDBへ保存する場合、その保存先は原則として利用者のブラウザ内です。

この場合、ブラウザデータを削除すると消える可能性があり、別端末へ自動同期されるわけではなく、サーバーバックアップでもありません。

同じ「保存」という言葉でも、ブラウザ内保存とクラウド保存では情報の流れがまったく違います。

ケース4　問い合わせを送る

お問い合わせフォームへメールアドレスや本文を入力して送信すると、その時点で入力内容はブラウザ内だけでは完結せず、問い合わせ対応のため外へ送信されます。

現在の設計では、問い合わせ本文等をコンテンツ用データベースへ恒久的な問い合わせ記録として保存することを目的とした処理は行っていませんが、メール配送、通信経路、送信成功に関する運用記録その他の処理は発生します。

ケース5　アクセス解析を見る

oka-projectでは、利用状況の把握と改善のためGoogle Analytics 4を利用しています。

閲覧ページ、アクセス日時、参照元、利用環境、おおよその地域、イベントその他がGoogleによって処理される場合があります。

この分析と、利用者がツールへ入力した本文そのものを分析対象として送ることは同じではなく、入力本文やファイル内容そのものを分析イベントとして意図的に送信することを目的としていません。

ケース6　ログイン機能が追加されたら

将来アカウント機能を導入すると、メールアドレス、認証に必要な情報、設定、利用履歴、契約状態その他、現在の登録不要ツールには存在しない情報が増える可能性があります。

ここで外部ログインを使えば、第三者のIDプロバイダとの通信が増え、クラウド保存を使えばサーバー上の保存対象と期間を決める必要があり、退会機能を作れば削除対象と残るログを決める必要があります。

ケース7　共有URLを作る

共有URL、公開プロフィール、共同編集その他を追加すると、それまで利用者本人しか見なかった情報が第三者へ表示される可能性があります。

利用者が公開した情報は、第三者に保存、引用、再共有される可能性があり、削除後も第三者が保有する複製まで当プロジェクトが消せるとは限りません。

このため公開範囲は、できる限り利用者が操作時に理解できる形で示す必要があります。

ケース8　AIへ送る

AI機能には、ブラウザ内モデルで処理できるものと、外部AI事業者へ入力データを送る必要があるものがあります。

外部AIへ送る場合、何を送るか、どの事業者へ送るか、保存や学習利用についてどの条件が適用されるかは、利用者が入力前に判断するため重要です。

そのため、将来AIを追加する場合には「AI機能があります」という説明だけでなく、データフローを具体化します。

ケース9　月額プランを買う

有料サービスでは、注文番号、購入内容、金額、支払状態、請求情報その他、サービス利用だけでは発生しなかった取引情報が増えます。

外部決済事業者を使う場合、決済に必要な情報の全部または一部を当該事業者が直接取得する方式を採ることがあります。

この場合、当プロジェクトが持つ情報と決済事業者が持つ情報は一致しないことがあります。

ケース10　物を送る

デジタルサービスだけだったサイトが物品販売を始めると、配送先、連絡先、注文内容その他が必要になります。

さらに配送事業者や倉庫事業者へ必要な情報を渡す場面が生まれます。

「販売する」という一言でも、デジタル商品と物品では扱う個人情報が違います。

ケース11　マーケットプレイスを始める

利用者と第三者事業者をつなぐ場を作ると、取引相手へどの情報を渡すかという問題が増えます。

連絡、本人確認、配送、役務提供その他のため、必要な範囲で情報を取引相手へ提供する場合があります。

その場合、誰が何を見るのかを機能上でも分かるようにする必要があります。

ケース12　海外利用者が増える

海外クラウドや海外事業者を使う場合、単にサーバーが外国にあるというだけで一律に同じ法的扱いになるわけではありません。

一方で、外国にある第三者への個人データ提供等に該当する場合には、追加の情報提供、同意その他の対応が必要になることがあります。

特定地域を積極的に対象とする場合には、その地域向けの追加通知や権利行使方法を設けることがあります。

ケース13　削除ボタンを押したあと

利用者がアカウント、投稿、保存データその他を削除した場合でも、すべてが同じ瞬間に物理的に消えるとは限りません。

バックアップ、監査ログ、不正利用対策、法令上の保存義務その他の理由で一定期間残る場合があります。

そのため「削除」と「全システムから即時に完全消去」は同じではありません。

ケース14　同じデータでも場所で意味が変わる

たとえばメールアドレスという同じ文字列でも、単なる変換対象のテキストとしてブラウザ内で処理される場合と、問い合わせ返信先として送信される場合と、ログインIDとして保存される場合と、請求連絡先として利用される場合では、情報の役割が異なります。

プライバシーを考えるときは「何のデータか」だけでなく、「どの機能で」「何の目的で」「どこへ」「どのくらいの期間」処理されるかを見る必要があります。

まとめ

プライバシーポリシーは、これらの場面を法的な基本条件としてまとめる文書です。

より通信そのものを追いたい場合はデータの旅、現在利用している第三者サービスを確認したい場合は外部送信についてをご確認ください。

このケース集は、機能の見た目と裏側のデータ処理が必ずしも一致しないことを、利用者と開発者の両方が思い出すためのページです。

一文で全部つなぐと

利用者がページを開いて何も入力していない時点ではページ配信のための通信があり、そこへ文章を貼り付けてもブラウザ内処理なら主要な入力本文はサーバーへ送られず、しかし保存ボタンが付けばブラウザ内保存なのかクラウド保存なのかを区別する必要が生まれ、問い合わせを送ればその本文は外へ出て、ログインが付けば認証情報が増え、共有が付けば第三者閲覧が生まれ、AIが付けば外部AIへ送るかどうかを決める必要が生まれ、決済が付けば注文と支払状態が増え、物品販売が付けば配送先が増え、マーケットプレイスが付けば取引相手への情報提供が増え、海外展開すれば国や地域ごとの追加対応が増え、削除ボタンを付ければどこまで消えるかを決める必要が生まれるため、結局プライバシーというものは「何のデータを持っていますか」という静止画ではなく「利用者がどの画面で何をして、その結果として情報がどこへ移動し、どこに残り、誰が見られる状態になるのか」という動画に近いものとして見た方が実態に近く、このページはその動画を文章で無理やりコマ送りにしているようなものです。