プライバシーポリシー

oka-project（以下「当プロジェクト」といいます。）は、当プロジェクトが運営するWebサイト「oka-project」（https://oka-project.com/）、同一ドメイン配下で提供するWebページ、Webツール、コンテンツ、お問い合わせ機能、API、連携機能その他当プロジェクトが提供するサービス（以下、総称して「本サービス」といいます。）における利用者情報の取扱いについて、以下のとおりプライバシーポリシー（以下「本ポリシー」といいます。）を定めます。

当プロジェクトは、利用者の情報を必要以上に取得しないこと、ブラウザ内で完結できる処理は可能な限り利用者の端末内で完結させること、取得または処理する情報とその目的をできる限り明確にすること、外部サービスを利用する場合にはその役割を説明することを基本方針として本サービスを運営します。

本ポリシーは、個人情報の保護に関する法律その他適用される法令・ガイドラインを踏まえた本サービスの基本的な情報取扱方針です。特定のサービス、Webツール、販売、契約、キャンペーン、APIその他の機能について個別の規約、注意事項、同意画面、特定商取引法に基づく表示その他の条件が設けられている場合、その個別条件は当該範囲について本ポリシーと併せて適用されます。

第1条　目的

本ポリシーは、本サービスを利用する方に対し、当プロジェクトがどのような情報を取得または処理し、どのような目的で利用し、どのように管理し、どのような外部サービスへ送信される可能性があるかを明らかにすることを目的とします。

本サービス上で氏名、メールアドレスその他の個人情報を入力して送信する機能を利用する場合には、送信前に本ポリシーおよび当該機能上の案内をご確認ください。

第2条　適用範囲

本ポリシーは、原則として、oka-project.comおよび当該ドメイン配下で当プロジェクトが提供する本サービスに適用されます。

当プロジェクトが別ドメイン、第三者プラットフォーム、アプリストア、SNS、外部決済サービスその他の外部環境上でサービスを提供する場合、そのサービスについて本ポリシーが適用される旨を表示することがあります。

外部サイト、外部サービス、SNS、ストア、決済事業者その他当プロジェクトが管理しない第三者のサービスについては、当該第三者が定めるプライバシーポリシーその他の条件が適用されます。

第3条　個別条件との関係

特定のWebツール、サービス、キャンペーン、販売、契約、APIまたは外部連携について、本ポリシーとは別に個別のプライバシー表示、利用規約、販売条件、同意画面その他の条件を設ける場合があります。

個別条件と本ポリシーの内容が異なる場合には、当該個別サービスに関する範囲で個別条件を優先します。ただし、法令上認められない内容によって利用者の権利を制限するものではありません。

第4条　用語

本ポリシーにおける「個人情報」「個人データ」「保有個人データ」「個人関連情報」「要配慮個人情報」その他法令上定義される用語は、特段の定めがない限り、個人情報の保護に関する法律その他の適用法令における意味に従います。

Cookie、広告識別子、ブラウザ識別情報、閲覧履歴、アクセス履歴等については、それ自体で特定の個人を識別できない場合であっても、個人関連情報その他法令上の保護対象となる場合があります。

第5条　基本原則

当プロジェクトは、本サービスの運営にあたり、取得する情報を利用目的との関係で必要かつ合理的な範囲に抑えることを基本とします。

また、端末内で十分に実現できる処理については、技術的・運用上合理的な範囲でブラウザ内処理を採用し、利用者が入力した本文やファイルそのものを不必要にサーバーへ送信しない設計を優先します。

第6条　取得または処理する情報

当プロジェクトは、本サービスの提供・運営に必要な範囲で、氏名またはハンドルネーム、メールアドレス、お問い合わせ種別、本文、添付情報その他利用者が任意に送信した情報を取得する場合があります。

また、本サービスへのアクセスに伴うIPアドレス、アクセス日時、アクセス先URL、参照元URL、HTTPリクエスト情報、ブラウザ、OS、端末、言語、画面その他の利用環境、Cookieその他の識別情報、ページ閲覧、クリック、遷移、エラーその他の利用状況、セキュリティ判定に必要な情報を処理する場合があります。

第7条　お問い合わせ時に取得する情報

お問い合わせフォームまたはメールを利用した場合、当プロジェクトは、氏名またはハンドルネーム、メールアドレス、お問い合わせ種別、お問い合わせ内容その他利用者が任意に送信した情報を取得します。

これらの情報は、お問い合わせ内容の確認、本人への連絡、回答、調査、対応履歴の把握、不正利用への対応その他本ポリシーに定める目的のために利用します。

第8条　お問い合わせフォームの現在の処理方式

本サービスのお問い合わせフォームから送信された氏名、メールアドレス、お問い合わせ種別およびお問い合わせ本文は、当プロジェクトへのメールとして送信されます。

現在のシステムでは、問い合わせ本文、氏名およびメールアドレスを、oka-projectのコンテンツ用データベースへ問い合わせ記録として恒久的に保存することを目的とした処理は行っていません。

問い合わせ送信が正常に完了したことを確認するため、問い合わせ本文その他の個人情報を含まない送信成功日時等の運用記録を保持する場合があります。

第9条　Webツールへ入力するデータ

本サービスには、テキスト、Markdown、CSV、画像、ファイルその他のデータを入力または読み込んで利用するWebツールが含まれる場合があります。

当プロジェクトが「ブラウザ内で処理する」「端末内で処理する」「サーバーへ送信しない」その他これらと同趣旨の表示をしているWebツールについては、当該ツールの主要な処理対象となる入力データまたはファイルを利用者のブラウザ内で処理し、その処理目的のためにoka-projectのサーバーへ送信または保存しません。

ただし、ツールページへアクセスするために通常発生するHTTP通信、IPアドレス、アクセス解析、セキュリティサービスによって処理される情報等は、この説明の対象外です。

第10条　サーバー処理を行うWebツール

今後、AI処理、同期、共有、変換、保存、アカウント機能その他の理由により、利用者が入力したデータをサーバーまたは外部サービスへ送信する必要があるWebツールを提供する場合があります。

その場合、処理対象となるデータ、送信先、保存の有無、利用目的その他利用者の判断に必要な事項を、当該ツール上または関連する説明ページで明示するよう努めます。

第11条　ブラウザ内保存

本サービスでは、利用者の設定、作業状態その他の情報を保持するため、localStorage、sessionStorage、IndexedDBその他ブラウザ内の保存領域を利用する場合があります。

ブラウザ内に保存された情報は原則として当該ブラウザまたは端末内に保持され、ブラウザのサイトデータ削除機能その他の方法により削除できます。

第12条　アクセスログ

本サービスの配信、セキュリティ確保、障害調査その他運営上必要な目的のため、サーバー、CDN、セキュリティサービスその他のシステムにアクセスログが記録される場合があります。

アクセスログには、IPアドレス、アクセス日時、アクセス先、通信方法、User-Agent、リクエスト情報、エラー情報その他技術的な情報が含まれる場合があります。

第13条　Cookie等の利用

当プロジェクトまたは本サービスで利用する外部サービスは、アクセス解析、機能提供、設定保持、セキュリティ確保その他本ポリシーに記載する目的のため、Cookieその他これに類する技術を使用する場合があります。

利用者はブラウザの設定からCookieの削除、制限または拒否を行うことができます。ただし、一部の機能が正常に利用できなくなる場合があります。

第14条　Google Analytics

当プロジェクトでは、本サービスの利用状況を把握し、サイト、コンテンツおよびWebツールを改善するため、Google Analytics 4を利用しています。

Google Analyticsでは、閲覧ページ、アクセス日時、参照元、利用環境、おおよその地域、イベントその他の利用状況に関する情報がGoogleへ送信またはGoogleによって処理される場合があります。また、Google Analyticsのスクリプト読込時には、IPアドレス、閲覧ページのURLその他通信に必要な情報が送信される場合があります。

Googleによる情報の取扱いについては、Googleのプライバシーに関する説明をご確認ください。

第15条　Google Analyticsのイベント計測

本サービスでは、ページ閲覧だけでなく、サイト改善のために必要な範囲で、リンク、ボタンその他の操作に関するイベントをGoogle Analytics等で計測する場合があります。

イベント計測を行う場合であっても、利用者がWebツールへ入力した本文またはファイル内容を分析イベントとして意図的に送信することを目的としません。

第16条　Cloudflare

当プロジェクトでは、本サービスの配信、DNS、セキュリティ、キャッシュ、不正アクセス対策、性能改善その他本サービスの安定提供のため、Cloudflareのサービスを利用しています。

Cloudflareによって、IPアドレス、アクセス日時、アクセス先、HTTPヘッダー、端末またはブラウザに関する情報、通信およびセキュリティ判定に必要な情報その他サービス提供に必要なデータが処理される場合があります。

第17条　Cloudflare Turnstile

当プロジェクトでは、お問い合わせフォーム等へのスパム、自動送信、不正アクセスその他の濫用を防止するため、Cloudflare Turnstileを利用しています。

Turnstileの利用に伴い、ブラウザ、端末、通信環境、IPアドレスその他自動化された不正なアクセスであるかを判定するために必要な情報がCloudflareによって処理される場合があります。

第18条　外部送信

本サービスでは、アクセス解析、セキュリティ、コンテンツ配信その他の機能を提供するため、利用者の端末から第三者が提供するサービスへ情報が送信される場合があります。

現在の主要な送信先として、Google Analyticsに関連するGoogleのサービスおよびCloudflareに関連するサービスがあります。送信される可能性がある情報には、IPアドレス、閲覧URL、アクセス日時、参照元、ブラウザまたは端末に関する情報、Cookieその他の識別情報、セキュリティ判定に必要な情報等が含まれる場合があります。

電気通信事業法における外部送信規律その他の法令が本サービスまたは個別機能に適用される場合には、当該法令に従い必要な表示、通知その他の対応を行います。

第19条　外部サービス

当プロジェクトは、本サービスの運営に必要な範囲で、アクセス解析、ホスティング、CDN、DNS、セキュリティ、メール、エラー監視、決済、認証、AIその他の外部サービスを利用する場合があります。

外部サービスを新たに導入し、利用者情報の取扱いに実質的な変更が生じる場合には、必要に応じて本ポリシーまたは当該サービス上の説明を更新します。

第20条　外部リンク

本サービスには、第三者が運営するWebサイト、SNS、サービス、アプリ、ストアその他の外部ページへのリンクが含まれる場合があります。

利用者が外部リンクを選択し、本サービス外へ移動した後に行われる情報の取得、利用、保存その他の取扱いについては、当該外部サービスの運営者が定める条件が適用されます。

第21条　外部コンテンツ・埋め込み

本サービスでは、動画その他第三者が提供するコンテンツへのリンクまたは埋め込み機能を利用する場合があります。

当該コンテンツを表示、再生または操作することによって第三者サービスへの通信が開始され、IPアドレス、Cookieその他の情報が当該第三者によって取得または処理される可能性があります。

第22条　利用目的

当プロジェクトは、取得または処理する情報を、本サービスおよびWebツールの提供・維持・改善、お問い合わせへの対応、不具合や障害の調査、利用状況の分析、セキュリティ確保、不正利用への対応、重要事項の連絡、法令上の義務への対応、統計情報の作成その他これらに付随する目的で利用します。

第23条　利用目的の特定

当プロジェクトは、個人情報を取り扱う場合、その利用目的をできる限り具体的に特定するよう努めます。

個人情報をフォームその他の方法で本人から直接取得する場合、利用目的が本ポリシーその他の表示から合理的に認識できるようにします。

第24条　利用目的の変更

利用目的を変更する場合、変更前の利用目的との合理的な関連性を考慮し、法令に従い必要な通知または公表を行います。

利用者が合理的に予測できない新たな目的で個人情報を利用する必要が生じる場合には、法令上認められる場合を除き、必要に応じて本人の同意を取得します。

第25条　慎重な取扱いを要する情報

当プロジェクトは、通常の本サービスの利用において、要配慮個人情報その他特に慎重な取扱いを必要とする情報の提供を求めることを目的としていません。

お問い合わせその他自由記述欄には、問い合わせ対応に必要がない限り、病歴、犯罪歴その他の機微な情報、本人確認書類番号、金融口座情報、認証情報その他重要な情報を記載しないでください。

第26条　法定代理人の同意が必要となる利用者

法令または利用者の状況により法定代理人の同意が必要となる場合には、必要な同意を得たうえで本サービスを利用してください。

当プロジェクトは、通常のサイト閲覧において利用者の年齢情報を積極的に取得することを目的としていません。

第27条　情報の正確性

当プロジェクトは、利用目的の達成に必要な範囲で、保有する個人データを正確かつ最新の内容に保つよう合理的な対応を行います。

第28条　保存期間

当プロジェクトは、取得した情報を、利用目的の達成、問い合わせ対応、障害調査、セキュリティ確保、紛争対応、法令上の義務その他合理的に必要となる期間に限って保持することを基本とします。

保存の必要性がなくなった情報については、法令上保存が必要な場合、バックアップに含まれる場合その他正当な理由がある場合を除き、合理的な方法で削除、匿名化または整理します。

第29条　ログ・バックアップ

セキュリティ、障害対応、変更管理および事業継続のため、アクセスログ、監査ログ、バックアップその他の運用データを一定期間保持する場合があります。

削除対象となった情報がバックアップ等に一時的に残る場合がありますが、復旧その他本来の目的を超えて積極的に利用することを目的としません。

第30条　第三者提供

当プロジェクトは、法令上認められる場合を除き、本人の同意なく、当プロジェクトが保有する個人データを第三者へ提供しません。

本人の同意がある場合、法令に基づく場合、人の生命、身体または財産の保護のため必要な場合、公的機関への協力その他法令上認められる場合には、必要な範囲で情報を提供することがあります。

第31条　委託

当プロジェクトは、本サービスの運営上必要な範囲で、メール、ホスティング、データ配信、セキュリティ、アクセス解析、決済その他の業務を外部事業者へ委託する場合があります。

委託に該当する場合には、法令に従い必要かつ適切な監督その他の措置を講じます。

第32条　共同利用

当プロジェクトが個人データを法令上の共同利用として取り扱う場合には、共同利用する旨、共同利用する個人データの項目、共同利用者の範囲、利用目的、管理責任を有する者その他法令上必要な事項をあらかじめ公表します。

第33条　個人関連情報

Cookie、閲覧履歴その他の情報が個人情報に該当しない場合であっても、個人関連情報として法令上の規制対象となる場合があります。

個人関連情報を第三者へ提供し、当該第三者がそれを個人データとして取得することが想定される場合には、法令に従い必要な確認その他の措置を行います。

第34条　外国における処理

Google、Cloudflareその他国外に拠点を有する事業者のサービスを利用することに伴い、利用者に関する情報が日本国外に所在する設備、サーバーまたは拠点等で処理される可能性があります。

外国にある第三者への個人データの提供について法令上特別な対応が必要となる場合には、適用法令に従って必要な情報提供、同意その他の措置を行います。

第35条　個人情報の販売

当プロジェクトは、利用者から取得した個人情報そのものを名簿その他の形で第三者へ販売することを目的として個人情報を取得しません。

第36条　広告・アフィリエイト

本サービスに広告、アフィリエイトリンク、スポンサー表示その他商業的な掲載を導入する場合があります。

第三者へ情報を送信する新たな広告機能等を導入し、利用者情報の取扱いに実質的な変更が生じる場合には、必要に応じて本ポリシー、外部送信に関する表示その他を更新します。

第37条　自動化された処理

本サービスでは、スパム判定、セキュリティ判定、アクセス解析その他サービス運営のため一定の自動化された処理を利用する場合があります。

Cloudflare Turnstileその他のセキュリティ機能によって、アクセスまたはフォーム送信が自動化された不正な通信である可能性について技術的な判定が行われる場合があります。

当プロジェクトは、通常の本サービスの運営において、利用者の人格的評価のみを目的とした自動処理によって、利用者の法的権利その他これに準ずる重大な事項を決定することを目的としていません。

第38条　AI機能

今後、本サービスに生成AI、機械学習モデル、外部AI APIその他AIを利用する機能を導入する場合があります。

利用者が入力したデータを外部AIサービスへ送信する必要がある場合には、処理方式、送信先、保存その他利用者の判断に必要な事項を、当該機能上または関連する説明で明示するよう努めます。

ブラウザ内処理と表示しているツールの入力内容を、説明なく外部AIサービスへ送信することを意図しません。

第39条　API・外部連携

本サービスがAPI、Model Context Protocolその他外部アプリケーションとの連携機能を提供する場合、利用者が当該連携を有効化または利用することによって、指定された範囲の情報が外部サービスとの間で送受信される場合があります。

外部連携による情報の取扱いについては、本ポリシーに加え、当該連携先のプライバシーポリシー、利用規約、権限設定その他の条件が適用される場合があります。

第40条　安全管理措置

当プロジェクトは、取り扱う個人情報および個人データについて、漏えい、滅失、毀損、不正アクセス、不正利用、改ざんその他のリスクを防止するため、当プロジェクトの規模、情報の性質およびシステム構成に応じた合理的な安全管理措置を講じます。

第41条　組織的な安全管理

当プロジェクトは、個人情報を必要以上に保持しないこと、アクセスできる主体および手段を必要な範囲に限定すること、変更履歴または監査情報を必要に応じて確認できる状態にすることその他合理的な管理を行います。

第42条　技術的な安全管理

当プロジェクトは、通信の暗号化、アクセス制御、認証、重要情報の分離、入力値検証、スパム対策、不正アクセス対策、セキュリティサービスの利用、ソフトウェア更新その他合理的に必要な技術的措置を講じます。

安全管理措置のうち、公開することによって本サービスの安全性を損なう可能性がある具体的な認証情報、防御ルールその他の情報については公開しない場合があります。

第43条　情報セキュリティ上の限界

インターネット上の通信、ブラウザ、外部サービスその他の情報システムについて、すべての不正アクセス、障害、脆弱性その他のリスクを完全に排除することはできません。

当プロジェクトは合理的な安全管理に努めますが、本条は法令上当プロジェクトが負う責任を不当に免除することを目的とするものではありません。

第44条　漏えい等への対応

個人データの漏えい、滅失、毀損その他法令上対応が必要となる事象またはそのおそれを把握した場合、当プロジェクトは事実関係および影響範囲の確認、原因調査、被害拡大防止、再発防止その他必要な対応を行います。

法令上、個人情報保護委員会その他の機関への報告または本人への通知が必要となる場合には、適用法令に従って対応します。

第45条　公的機関からの要請

裁判所、警察、行政機関その他の公的機関から法令に基づく適法な情報開示その他の要請を受けた場合、当プロジェクトは法令に従い必要な範囲で対応する場合があります。

第46条　不正利用への対応

攻撃、不正アクセス、スパム、自動化された大量アクセス、脆弱性の悪用その他不正または不適切な利用が行われた場合、当プロジェクトは本サービスおよび利用者を保護するために必要な範囲でアクセスログその他の情報を確認し、アクセス制限、調査その他必要な対応を行う場合があります。

第47条　本人による管理

利用者は、ブラウザのCookie設定、サイトデータ削除、localStorage等の削除、Google Analyticsのオプトアウト手段その他利用するサービスが提供する設定を利用して、一定の情報の保存または計測を管理できる場合があります。

第48条　Do Not Track等

ブラウザその他のソフトウェアは、Do Not Trackその他プライバシーに関する設定または信号を送信する場合があります。

これらの信号の仕様、外部サービス側の対応状況および法的な取扱いは一律ではないため、本サービスがすべての種類の信号について同一の動作を行うことを保証するものではありません。

第49条　開示等の請求

当プロジェクトが保有する本人の保有個人データについて、本人は、適用される法令の範囲内で、利用目的の通知、開示、訂正、追加、削除、利用停止、消去、第三者提供の停止、第三者提供記録の開示その他法令上認められる請求を行うことができます。

請求を希望する場合は、本ポリシー末尾のお問い合わせ窓口までご連絡ください。

第50条　請求方法

開示等の請求を行う場合、対象となる情報、希望する対応、本人を特定するために必要となる情報その他当プロジェクトが合理的に求める事項をご提示いただく場合があります。

当プロジェクトは、利用者が容易かつ的確に請求できるよう、必要以上に複雑な手続を要求しないよう努めます。

第51条　本人確認

開示等の請求について、個人情報の漏えい、不正取得またはなりすましを防止する必要がある場合、当プロジェクトは請求者が本人または適法な代理人であることを確認するため、必要最小限の情報の提示を求める場合があります。

本人確認のために取得した情報は、本人確認および当該請求への対応に必要な範囲でのみ利用します。

第52条　請求に対応できない場合

法令上開示等を行う義務がない場合、本人または第三者の権利利益を害するおそれがある場合、本サービスの適正な運営に著しい支障を及ぼすおそれがある場合、他の法令に違反する場合その他法令上認められる場合には、開示等の全部または一部に対応しないことがあります。

利用者のブラウザ内のみに保存されている情報または外部サービス事業者が独自に管理している情報については、当プロジェクトから直接削除等を行えない場合があります。

第53条　開示等の手数料

開示等の請求について手数料を設定する場合には、法令に従い、その金額および支払方法を本人の知り得る状態に置きます。

第54条　統計情報

当プロジェクトは、本サービスの利用状況その他取得した情報を、特定の個人との対応関係を排斥した統計情報として集計し、本サービスの改善、調査、企画、活動報告その他の目的に利用する場合があります。

第55条　利用者自身による情報管理

共用端末を利用する場合、機密性の高いデータをWebツールで処理する場合その他必要な場合には、利用者自身でも端末のアクセス管理、ブラウザの更新、サイトデータの削除その他適切な対策を行ってください。

ブラウザ内処理であっても、利用者の端末、ブラウザ拡張機能その他当プロジェクトの管理外の要因によって情報が取得される可能性があります。

第56条　有料サービス・販売

当プロジェクトは、将来、本サービスの一部として有料Webツール、デジタルコンテンツ、ソフトウェア、継続課金サービス、受託サービスその他有償のサービスまたは商品を提供する場合があります。

有料サービスを提供する場合、価格、支払方法、提供条件、契約期間、解約条件、返金条件その他取引判断に必要な事項を、購入または申込み前に確認できるよう表示します。

第57条　特定商取引法に基づく表示との関係

当プロジェクトが特定商取引に関する法律上の通信販売その他の規制対象となる取引を行う場合には、法令に従い、必要事項を販売ページ、専用ページその他購入前に確認しやすい方法で表示します。

取引の内容に応じ、販売業者または役務提供事業者の氏名または名称、住所、連絡先、販売価格または役務の対価、利用者が負担する追加費用、支払方法・時期、提供時期、申込みの期間、返品・キャンセル・解除、ソフトウェアの動作環境、継続契約の条件その他法令上必要となる事項を表示します。

個人事業者として通信販売を行う場合に、通称、屋号またはサイト名のみでは法令上の氏名表示として足りない場合があることを前提に、販売開始時の法令および販売形態に応じて必要な表示を行います。

法令上、一定の表示事項について利用者の請求に応じて遅滞なく提供する方法による省略が認められる場合にその方法を利用するときは、申込みの意思決定前に情報を取得できる状態を確保します。

本ポリシーは、特定商取引法に基づく個別の表示そのものを代替するものではありません。

第58条　返品・解約・返金

有料サービス、デジタル商品その他の販売を開始した場合、返品、キャンセル、契約解除、返金その他の条件は、対象となる商品またはサービスごとに表示します。

通信販売では販売形態によって適用される制度が異なるため、申込み前に返品・解除条件を確認できる表示を行います。

不具合、契約不適合、サービス停止その他法令上または契約上対応が必要となる場合には、適用法令および個別条件に従って対応します。

第59条　決済サービス

有料サービスに外部決済事業者を利用する場合、決済に必要な情報が当該事業者によって直接処理される仕組みを採用する場合があります。

その場合、当プロジェクトが保持する情報と決済事業者が保持する情報の範囲が異なることがあります。決済事業者による情報の取扱いには、当該事業者のプライバシーポリシーその他の条件が適用されます。

第60条　利用規約等との関係

本ポリシーは利用者情報の取扱いを中心として定めるものであり、本サービスの利用条件、禁止事項、知的財産権、サービス停止、契約解除、免責、損害賠償その他について別途利用規約等を定める場合があります。

有料サービスその他契約関係が生じる機能を導入する場合には、利用規約、個別条件、特定商取引法に基づく表示その他必要な契約条件を、申込み前に確認できる形で整備します。

第61条　免責との関係

本ポリシー中の説明は、法令上当プロジェクトが負う責任を不当に免除することを目的とするものではありません。

利用規約等に責任制限に関する条項を設ける場合であっても、消費者契約法その他の強行法規により無効となる範囲まで責任を免除することを意図しません。

第62条　サービスの追加・変更

当プロジェクトは、新しいWebツール、コンテンツ、AI機能、API、外部連携、広告、決済、アカウントその他の機能を追加する場合があります。

現在の本ポリシーから合理的に予測できない情報の取得、保存、利用または第三者への送信が必要となる場合には、必要に応じて当該機能上で案内し、本ポリシーを改定します。

第63条　プライバシー・バイ・デザイン

当プロジェクトは、新しい機能またはWebツールを設計する際、必要なデータ量、サーバー送信の必要性、保存期間、外部サービスへの依存、安全性、利用者への説明可能性その他プライバシーに関する事項を考慮するよう努めます。

端末内で十分に実現可能な処理については、合理的な範囲でブラウザ内処理を優先し、不必要なデータ送信または保存を増やさないことを設計上の方針とします。

第64条　本ポリシーの変更

当プロジェクトは、本サービスの内容、システム構成、利用する外部サービス、法令、ガイドラインその他の事情の変更に応じ、本ポリシーを変更することがあります。

変更後の本ポリシーは、別途法令上必要な手続がある場合を除き、本ページに掲載した時点または別途定めた時点から適用します。

利用者への影響が大きい変更については、必要に応じて本サービス上のお知らせその他適切な方法で周知します。

第65条　改定履歴

本ページ上には、原則として制定日および最終更新日を表示します。

重要な改定について、必要に応じて改定内容の概要をお知らせ等で案内する場合があります。

第66条　日本語版と翻訳版

本ポリシーの英語版その他の翻訳版を提供する場合、翻訳版は日本語を使用しない利用者の理解を助けることを目的として提供します。

日本語版と翻訳版との間に内容の相違が生じた場合には、法令上別段の定めがある場合を除き、日本語版を基準とします。

第67条　準拠する法令

当プロジェクトは、個人情報保護、電気通信、消費者取引その他本サービスに適用される日本法および関連ガイドラインを踏まえて、本サービスおよび本ポリシーを運用します。

海外から本サービスを利用する場合、利用者の所在地、提供する機能その他の事情により日本国外の法令が適用される可能性があります。

第68条　運営者情報

本サービスは、個人プロジェクト「oka-project」により運営されています。

プロジェクト名：oka-project

運営：oka

Webサイト：https://oka-project.com/

連絡先：contact@oka-project.com

法令上、運営者の正式な氏名、住所その他の事項を本人の知り得る状態に置く必要がある場合には、適用法令に従って必要な方法で提供または公表します。

第69条　アカウント機能を導入する場合

将来アカウント機能を提供する場合、表示名、メールアドレス、認証に必要な情報、プロフィール、設定、利用履歴、契約状態その他アカウント運営に必要な情報を取得または処理する場合があります。

外部IDプロバイダを利用する場合には、当該事業者から提供される識別子その他必要な情報を処理する場合があります。

第70条　プロフィール・公開情報

プロフィール、投稿者情報、作品一覧その他公開を前提とする機能を提供する場合、利用者が公開設定した情報は第三者から閲覧、検索、保存、引用または再共有される可能性があります。

公開範囲、公開期間、削除方法その他は当該機能上の表示に従います。

第71条　共同利用型の機能

共有URL、共同編集、コメント、招待その他複数人で利用する機能を提供する場合、参加者の識別情報、編集履歴、コメント、共有設定その他機能提供に必要な情報を処理する場合があります。

共有相手に表示される情報については、当該機能上で合理的に確認できるようにします。

第72条　決済・注文に関する情報

有料サービスを提供する場合、注文番号、購入内容、金額、支払状態、請求情報その他取引管理に必要な情報を処理する場合があります。

外部の決済事業者を利用する場合、決済に必要な情報の全部または一部を当該事業者が直接取得する場合があります。

第73条　物品販売に関する情報

物品を販売する場合、氏名、配送先、連絡先、注文内容その他発送、返品、問い合わせ対応等に必要な情報を処理する場合があります。

配送事業者、倉庫事業者その他履行に必要な委託先へ必要な範囲で情報を提供する場合があります。

第74条　取引相手への情報提供

マーケットプレイス、予約、マッチングその他利用者と第三者との取引を支援する機能を提供する場合、取引成立、連絡、本人確認、配送、役務提供その他に必要な範囲で情報を取引相手へ提供する場合があります。

提供項目および目的については、当該機能上で必要な案内を行います。

第75条　投稿・コミュニティ機能

コメント、レビュー、掲示板、作品投稿その他のコミュニティ機能を提供する場合、投稿内容、投稿日時、アカウント識別子、通報情報、運営上必要な対応履歴その他を処理する場合があります。

公開投稿については、利用者自身が公開範囲を確認したうえで利用してください。

第76条　アンケート・調査

アンケート、インタビュー、テスト利用、モニターその他の調査を行う場合、回答内容、属性情報、連絡先その他調査に必要な情報を取得する場合があります。

回答を個人が識別できる形で公開または二次利用する場合には、必要な同意その他の手続を行います。

第77条　キャンペーン等

キャンペーン、抽選、プレゼント、紹介企画その他を実施する場合、応募情報、連絡先、当選履歴、配送情報その他企画運営に必要な情報を処理する場合があります。

法令上必要な保存、確認または連絡を行う場合があります。

第78条　メール・通知

サービス通知、お問い合わせ回答、重要なお知らせその他の連絡を行うため、メールアドレスその他必要な情報を利用する場合があります。

広告宣伝を目的とする連絡については、適用法令および利用者の選択に従い、配信停止その他必要な方法を用意します。

第79条　外部送信サービスの追加

今後、分析、広告、障害監視、A/Bテスト、決済、チャット、動画、地図その他のため新たな外部サービスを導入する場合、利用者の端末から当該事業者へ情報が送信されることがあります。

電気通信事業法その他の適用を受ける場合には、送信される情報、送信先、利用目的その他必要事項について、通知、公表、同意、オプトアウトその他法令上認められる方法で確認の機会を提供します。

第80条　広告技術を導入する場合

広告配信、広告効果測定その他の広告技術を導入する場合、閲覧履歴、識別子、端末情報その他が広告事業者等へ送信または処理される場合があります。

実際に導入する場合には、適用法令および当該サービスの仕様に応じ必要な表示または選択手段を設けます。

第81条　海外展開

日本国外の利用者を対象として本サービスを展開する場合、地域に応じた追加のプライバシー通知、同意、権利行使方法その他を設ける場合があります。

日本国外からの利用に強行法規が適用される場合、その適用を排除するものではありません。

第82条　外国にある事業者・サーバー

クラウド、分析、AI、決済その他の外部サービスの提供者またはサーバーが日本国外に所在する場合があります。

個人データの外国にある第三者への提供その他法令上特別な対応が必要となる場合には、必要な情報提供、同意取得、相当措置の確認その他を適用法令に従って行います。

第83条　事業承継

合併、会社分割、事業譲渡その他により本サービスの運営主体または事業が承継される場合、法令上認められる範囲で個人情報その他の情報が承継される場合があります。

承継後の取扱いは適用法令および公表された利用目的等に従います。

第84条　匿名化・統計化

利用状況の分析、品質改善、研究その他のため、個人を識別できない統計情報または法令上定義される加工情報を作成する場合があります。

匿名加工情報、仮名加工情報その他特別な法的取扱いが適用される情報を作成する場合には、必要な義務に従います。

第85条　サービスごとの追加通知

新しいサービス、機能または事業を開始する際、その性質上、本ポリシーだけでは利用者が情報処理を十分に予測できない場合には、個別のプライバシー通知、同意画面、FAQその他を追加する場合があります。

当該個別通知は、その対象範囲について本ポリシーを補完します。

第86条　安全管理措置に関する問い合わせ

当プロジェクトが講じている安全管理措置について、法令上本人の知り得る状態に置く必要がある事項を確認したい場合には、末尾のお問い合わせ窓口までご連絡ください。

安全性を害する可能性がある技術上の詳細については回答できない場合があります。

第87条　苦情・相談

当プロジェクトによる個人情報その他利用者情報の取扱いに関する苦情、相談または懸念がある場合には、末尾のお問い合わせ窓口までご連絡ください。

内容を確認し、適用法令および合理的な運営上の範囲で対応します。

第88条　お問い合わせ窓口

本ポリシー、個人情報の取扱い、開示等の請求、外部送信、安全管理措置その他プライバシーに関するお問い合わせは、以下よりご連絡ください。

お問い合わせページ：/contact

メール：contact@oka-project.com

本人確認が必要となる請求については、必要最小限の本人確認をお願いする場合があります。

第1編　情報の種類を異常に細かく分ける辞典

「個人情報」「ログ」など大きな箱だけではなく、実際の機能設計で遭遇する情報を細かく分けます。

この編はプライバシーポリシーの理解を補助する詳細説明であり、現在の実装について事実ではない取得・保存・共有を追加して見せるための文章ではなく、現時点の処理は実態に合わせ、将来機能については条件付きの想定として区別し、実際にその処理を開始するときに具体情報を更新することを前提とします。

第89条　氏名・表示名

氏名・表示名については、本人を示す名称が実名、ハンドルネーム、組織名等で意味を変えることという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば問い合わせでハンドルネームを書くという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ氏名・表示名でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第90条　メールアドレス

メールアドレスについては、連絡先、ログインID、請求連絡先等の役割を区別することという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば問い合わせ返信先として入力するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じメールアドレスでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第91条　識別子

識別子については、Cookie、セッションID、アカウントID等を用途別に見ることという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばログイン状態を維持する識別子が発行されるという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ識別子でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第92条　IPアドレス

IPアドレスについては、通信、セキュリティ、地域推定等との関係という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばページへアクセスするという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じIPアドレスでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第93条　アクセス日時

アクセス日時については、運用ログ、不正調査、分析等の用途という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば深夜に大量アクセスが発生するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じアクセス日時でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第94条　URL・参照元

URL・参照元については、閲覧ページと流入経路の情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば検索結果から記事へ来るという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じURL・参照元でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第95条　端末情報

端末情報については、OS、ブラウザ、画面等の利用環境という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばスマホとPCで表示が変わるという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ端末情報でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第96条　入力本文

入力本文については、ツールの主要処理対象と通常のアクセス情報を分けることという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばMarkdown本文を変換欄へ貼り付けるという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ入力本文でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第97条　ファイル

ファイルについては、ファイル名、内容、メタデータ等を分けることという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば画像をブラウザ内で変換するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じファイルでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第98条　設定情報

設定情報については、テーマ、言語、直前状態等の利便性情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばダークモードを選ぶという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ設定情報でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

この編の読み方

この編は、一語一句を覚えるためではなく、新しい機能を追加したときに「その機能で新しく生まれるデータは何か、そのデータはどこから来てどこへ行き、何のためにどれだけ残り、誰が見られ、利用者にはどのような選択肢が必要か」という問いを忘れないための長いチェックリストでもあり、文章が長いほど自動的に透明性が高くなるわけではないからこそ、具体的な機能上の表示と併用することを前提としています。

第2編　取得経路・発生源・入力のされ方

情報が何であるかだけでなく、どの経路から来たかを追います。

この編はプライバシーポリシーの理解を補助する詳細説明であり、現在の実装について事実ではない取得・保存・共有を追加して見せるための文章ではなく、現時点の処理は実態に合わせ、将来機能については条件付きの想定として区別し、実際にその処理を開始するときに具体情報を更新することを前提とします。

第99条　直接入力

直接入力については、フォームや入力欄から本人が送る情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば問い合わせ本文を送信するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ直接入力でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第100条　自動生成

自動生成については、通信やシステム利用に伴って生じる情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばアクセスログが残るという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ自動生成でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第101条　ブラウザ内生成

ブラウザ内生成については、端末内処理で生じサーバーへ送らない情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば変換結果をローカルで作るという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じブラウザ内生成でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第102条　外部サービス由来

外部サービス由来については、認証等で第三者から受け取る情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば外部ログインで識別子を受け取るという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ外部サービス由来でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第103条　他の利用者由来

他の利用者由来については、招待や共同編集等で第三者が入力する情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばチーム管理者がメンバーを招待するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ他の利用者由来でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第104条　公開情報由来

公開情報由来については、公開ページ等から参照する情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば公開プロフィールを表示するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ公開情報由来でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第105条　取引由来

取引由来については、注文や支払で生じる情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば購入状態を記録するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ取引由来でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第106条　サポート由来

サポート由来については、問い合わせ対応で追加される情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば不具合の再現環境を聞くという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じサポート由来でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第107条　セキュリティ由来

セキュリティ由来については、不正利用判定で生成する情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば高頻度アクセスを検知するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じセキュリティ由来でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第108条　統計化

統計化については、複数の利用状況から集計値を作ることという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばページ別利用回数を集計するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ統計化でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

この編の読み方

この編は、一語一句を覚えるためではなく、新しい機能を追加したときに「その機能で新しく生まれるデータは何か、そのデータはどこから来てどこへ行き、何のためにどれだけ残り、誰が見られ、利用者にはどのような選択肢が必要か」という問いを忘れないための長いチェックリストでもあり、文章が長いほど自動的に透明性が高くなるわけではないからこそ、具体的な機能上の表示と併用することを前提としています。

第3編　ブラウザ・端末内処理・ローカル保存

oka-projectの特徴であるブラウザ内処理を、単純な『送信しない』だけで終わらせず境界まで説明します。

この編はプライバシーポリシーの理解を補助する詳細説明であり、現在の実装について事実ではない取得・保存・共有を追加して見せるための文章ではなく、現時点の処理は実態に合わせ、将来機能については条件付きの想定として区別し、実際にその処理を開始するときに具体情報を更新することを前提とします。

第109条　メモリ上の処理

メモリ上の処理については、タブを閉じると消える一時データという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば変換中だけ文章を保持するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じメモリ上の処理でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第110条　localStorage

localStorageについては、ブラウザへ継続保存する設定等という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば前回の設定を残すという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じlocalStorageでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第111条　sessionStorage

sessionStorageについては、タブ等の単位で一時保存する情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば一時的な画面状態を持つという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じsessionStorageでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第112条　IndexedDB

IndexedDBについては、比較的大きな端末内データ保存という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば作業履歴を端末へ保存するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じIndexedDBでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第113条　キャッシュ

キャッシュについては、ブラウザや配信層の一時保存という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば静的ファイルを再利用するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じキャッシュでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第114条　クリップボード

クリップボードについては、コピー・貼り付けに関する権限という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば変換結果をコピーするという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じクリップボードでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第115条　ファイルAPI

ファイルAPIについては、利用者が選んだローカルファイルへのアクセスという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばローカル画像を読み込むという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じファイルAPIでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第116条　ダウンロード

ダウンロードについては、生成物を端末へ保存する動作という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば変換結果をファイル保存するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じダウンロードでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第117条　端末変更

端末変更については、ローカル保存が自動移行されないことという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば別PCで続きを開くという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ端末変更でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第118条　ブラウザ削除

ブラウザ削除については、サイトデータ消去による消失という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば履歴とサイトデータを消すという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じブラウザ削除でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

この編の読み方

この編は、一語一句を覚えるためではなく、新しい機能を追加したときに「その機能で新しく生まれるデータは何か、そのデータはどこから来てどこへ行き、何のためにどれだけ残り、誰が見られ、利用者にはどのような選択肢が必要か」という問いを忘れないための長いチェックリストでもあり、文章が長いほど自動的に透明性が高くなるわけではないからこそ、具体的な機能上の表示と併用することを前提としています。

第4編　通信ログ・セキュリティ・不正利用対策

何も入力しなくてもWeb通信に伴って発生し得る情報を、セキュリティ文脈で整理します。

この編はプライバシーポリシーの理解を補助する詳細説明であり、現在の実装について事実ではない取得・保存・共有を追加して見せるための文章ではなく、現時点の処理は実態に合わせ、将来機能については条件付きの想定として区別し、実際にその処理を開始するときに具体情報を更新することを前提とします。

第119条　HTTPリクエスト

HTTPリクエストについては、Webページ配信に必要な基本通信という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばHTMLを取得するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じHTTPリクエストでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第120条　User-Agent等

User-Agent等については、ブラウザや利用環境の情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば特定ブラウザの不具合を調べるという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じUser-Agent等でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第121条　エラー情報

エラー情報については、障害解析に必要な記録という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばJavaScriptエラーが発生するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じエラー情報でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第122条　アクセス頻度

アクセス頻度については、自動攻撃等の判定材料という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば短時間に大量アクセスするという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じアクセス頻度でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第123条　認証失敗

認証失敗については、アカウント導入時の防御情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばログインを何度も失敗するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ認証失敗でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第124条　レート制限

レート制限については、過剰利用を抑えるための状態という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばAPI上限へ達するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じレート制限でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第125条　Turnstile等

Turnstile等については、自動送信対策で第三者が処理する情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば問い合わせを送るという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じTurnstile等でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第126条　ブロック情報

ブロック情報については、危険なアクセスを制限するための情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば攻撃元を一時制限するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じブロック情報でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第127条　監査記録

監査記録については、重要操作の確認に使う履歴という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば設定変更の成功時刻を残すという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ監査記録でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第128条　インシデント調査

インシデント調査については、問題発生後に複数ログを突き合わせることという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば不審なアクセス経路を確認するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じインシデント調査でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

この編の読み方

この編は、一語一句を覚えるためではなく、新しい機能を追加したときに「その機能で新しく生まれるデータは何か、そのデータはどこから来てどこへ行き、何のためにどれだけ残り、誰が見られ、利用者にはどのような選択肢が必要か」という問いを忘れないための長いチェックリストでもあり、文章が長いほど自動的に透明性が高くなるわけではないからこそ、具体的な機能上の表示と併用することを前提としています。

第5編　アクセス解析・外部送信・第三者サービス

現在利用している分析・配信・安全性サービスと、将来追加する外部サービスを区別して考えます。

この編はプライバシーポリシーの理解を補助する詳細説明であり、現在の実装について事実ではない取得・保存・共有を追加して見せるための文章ではなく、現時点の処理は実態に合わせ、将来機能については条件付きの想定として区別し、実際にその処理を開始するときに具体情報を更新することを前提とします。

第129条　Google Analytics 4

Google Analytics 4については、利用状況分析と入力本文の処理を混同しないことという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば閲覧ページの利用状況を集計するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じGoogle Analytics 4でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第130条　Cloudflare

Cloudflareについては、配信、キャッシュ、セキュリティ等で通信を処理することという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばサイトへ通常アクセスするという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じCloudflareでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第131条　Cloudflare Turnstile

Cloudflare Turnstileについては、フォーム等の自動送信対策という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば問い合わせ送信前に判定するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じCloudflare Turnstileでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第132条　外部認証

外部認証については、将来IDプロバイダを利用する場合という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば外部アカウントでログインするという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ外部認証でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第133条　決済事業者

決済事業者については、将来支払情報を直接扱ってもらう場合という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばカード決済画面へ進むという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ決済事業者でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第134条　メール配送

メール配送については、問い合わせや通知の送信経路という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば問い合わせ返信を受け取るという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じメール配送でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第135条　障害監視

障害監視については、将来エラー監視サービスを導入する場合という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば例外情報を監視するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ障害監視でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第136条　A/Bテスト

A/Bテストについては、将来UI比較を行う場合の識別や計測という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば二種類の画面を比較するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じA/Bテストでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第137条　広告技術

広告技術については、将来広告を導入する場合の外部送信という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば広告効果を測定するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ広告技術でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第138条　埋め込み

埋め込みについては、動画、地図等の第三者コンテンツという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば外部動画を再生するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ埋め込みでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

この編の読み方

この編は、一語一句を覚えるためではなく、新しい機能を追加したときに「その機能で新しく生まれるデータは何か、そのデータはどこから来てどこへ行き、何のためにどれだけ残り、誰が見られ、利用者にはどのような選択肢が必要か」という問いを忘れないための長いチェックリストでもあり、文章が長いほど自動的に透明性が高くなるわけではないからこそ、具体的な機能上の表示と併用することを前提としています。

第6編　アカウント・認証・プロフィール・共同利用

将来アカウントや共同機能が加わった場合に、登録情報がどのように増えるかを具体的に想定します。

この編はプライバシーポリシーの理解を補助する詳細説明であり、現在の実装について事実ではない取得・保存・共有を追加して見せるための文章ではなく、現時点の処理は実態に合わせ、将来機能については条件付きの想定として区別し、実際にその処理を開始するときに具体情報を更新することを前提とします。

第139条　アカウントID

アカウントIDについては、内部識別子と公開表示名を分けることという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば内部IDでデータを紐づけるという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じアカウントIDでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第140条　認証情報

認証情報については、パスワード等を導入する場合の管理という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばログイン機能を追加するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ認証情報でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第141条　外部ログイン

外部ログインについては、第三者から受け取る識別情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばGoogle等でログインするという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ外部ログインでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第142条　プロフィール

プロフィールについては、公開情報と非公開情報を分けることという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば自己紹介を公開するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じプロフィールでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第143条　チーム情報

チーム情報については、組織、所属、役割等の情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばワークスペースを作るという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じチーム情報でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第144条　招待情報

招待情報については、第三者を招く際のメール等という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば共同編集者を招待するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ招待情報でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第145条　権限情報

権限情報については、閲覧、編集、管理等の状態という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば管理者だけ設定変更するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ権限情報でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第146条　共有履歴

共有履歴については、誰と何を共有したかの記録という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば共有リンクを発行するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ共有履歴でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第147条　共同編集

共同編集については、複数人の変更履歴やコメントという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば同じ文書を同時編集するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ共同編集でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第148条　退会・削除

退会・削除については、アカウント終了後の情報整理という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばアカウント削除を依頼するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ退会・削除でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

この編の読み方

この編は、一語一句を覚えるためではなく、新しい機能を追加したときに「その機能で新しく生まれるデータは何か、そのデータはどこから来てどこへ行き、何のためにどれだけ残り、誰が見られ、利用者にはどのような選択肢が必要か」という問いを忘れないための長いチェックリストでもあり、文章が長いほど自動的に透明性が高くなるわけではないからこそ、具体的な機能上の表示と併用することを前提としています。

第7編　AI・自動化・推薦・機械処理

AIという一語で処理内容を曖昧にしないため、入力、出力、外部送信、学習、推論、推薦等を分けます。

この編はプライバシーポリシーの理解を補助する詳細説明であり、現在の実装について事実ではない取得・保存・共有を追加して見せるための文章ではなく、現時点の処理は実態に合わせ、将来機能については条件付きの想定として区別し、実際にその処理を開始するときに具体情報を更新することを前提とします。

第149条　外部AI API

外部AI APIについては、入力を第三者AIへ送る場合という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば文章要約を外部AIへ依頼するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ外部AI APIでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第150条　端末内AI

端末内AIについては、外部送信なしで処理する場合という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばブラウザ内モデルで分類するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ端末内AIでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第151条　プロンプト

プロンプトについては、利用者がAIへ与える指示という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば長文指示を入力するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じプロンプトでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第152条　添付ファイル

添付ファイルについては、AI処理対象のファイルという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばPDFを要約させるという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ添付ファイルでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第153条　AI出力

AI出力については、生成結果と入力情報の関係という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば生成文を保存するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じAI出力でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第154条　学習利用

学習利用については、推論利用とモデル改善利用を分けることという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば外部事業者の学習条件を確認するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ学習利用でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第155条　推薦

推薦については、利用履歴等から順序を変える場合という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばおすすめ記事を表示するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ推薦でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第156条　自動判定

自動判定については、スパム等を機械的に判定する場合という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば問い合わせを自動分類するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ自動判定でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第157条　エージェント

エージェントについては、複数処理を自律実行する場合という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばAIが複数ツールを連続操作するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じエージェントでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第158条　人による確認

人による確認については、自動処理だけで完結させない場面という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば重要な問い合わせを人が確認するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ人による確認でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

この編の読み方

この編は、一語一句を覚えるためではなく、新しい機能を追加したときに「その機能で新しく生まれるデータは何か、そのデータはどこから来てどこへ行き、何のためにどれだけ残り、誰が見られ、利用者にはどのような選択肢が必要か」という問いを忘れないための長いチェックリストでもあり、文章が長いほど自動的に透明性が高くなるわけではないからこそ、具体的な機能上の表示と併用することを前提としています。

第8編　取引・決済・配送・マーケットプレイス

有料化や物販を始める場合に、サービス利用情報とは別の取引情報が増えることを整理します。

この編はプライバシーポリシーの理解を補助する詳細説明であり、現在の実装について事実ではない取得・保存・共有を追加して見せるための文章ではなく、現時点の処理は実態に合わせ、将来機能については条件付きの想定として区別し、実際にその処理を開始するときに具体情報を更新することを前提とします。

第159条　注文番号

注文番号については、取引を識別する情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば購入が一件発生するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ注文番号でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第160条　購入内容

購入内容については、何を購入したかの情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば有料プランを選ぶという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ購入内容でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第161条　支払状態

支払状態については、成功、失敗、返金等の状態という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばカード決済が失敗するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ支払状態でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第162条　請求情報

請求情報については、請求や領収に必要な情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば法人名義で請求するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ請求情報でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第163条　決済事業者

決済事業者については、第三者が直接取得する支払情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば外部決済画面へ移動するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ決済事業者でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第164条　配送先

配送先については、物品販売時の住所等という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば商品を発送するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ配送先でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第165条　配送事業者

配送事業者については、履行のため必要情報を渡すことという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば宅配便で送るという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ配送事業者でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第166条　販売者情報

販売者情報については、マーケットプレイスで相手方を識別することという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば第三者出品者から購入するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ販売者情報でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第167条　取引メッセージ

取引メッセージについては、購入者と販売者の連絡という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば配送について問い合わせるという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ取引メッセージでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第168条　不正決済対策

不正決済対策については、取引リスク判定に使う情報という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば通常と異なる購入を検知するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ不正決済対策でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

この編の読み方

この編は、一語一句を覚えるためではなく、新しい機能を追加したときに「その機能で新しく生まれるデータは何か、そのデータはどこから来てどこへ行き、何のためにどれだけ残り、誰が見られ、利用者にはどのような選択肢が必要か」という問いを忘れないための長いチェックリストでもあり、文章が長いほど自動的に透明性が高くなるわけではないからこそ、具体的な機能上の表示と併用することを前提としています。

第9編　保存期間・削除・開示・権利行使

情報を集める話だけでなく、いつまで残り、どう消し、本人がどのように確認できるかを細かくします。

この編はプライバシーポリシーの理解を補助する詳細説明であり、現在の実装について事実ではない取得・保存・共有を追加して見せるための文章ではなく、現時点の処理は実態に合わせ、将来機能については条件付きの想定として区別し、実際にその処理を開始するときに具体情報を更新することを前提とします。

第169条　保存期間

保存期間については、目的ごとに必要期間が違うことという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばアクセスログと問い合わせを別期間扱うという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ保存期間でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第170条　不要化

不要化については、目的が終わった情報を整理することという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば完了した問い合わせを整理するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ不要化でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第171条　削除

削除については、論理削除と物理削除の違いという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばアカウント削除を実行するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ削除でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第172条　バックアップ残存

バックアップ残存については、削除後の一時残存可能性という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばバックアップ更新まで残るという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じバックアップ残存でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第173条　法令保存

法令保存については、法的義務で残す場合という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば取引記録を一定期間保持するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ法令保存でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第174条　開示

開示については、本人が保有情報を確認する場合という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば保有データの開示を求めるという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ開示でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第175条　訂正

訂正については、誤情報を直す場合という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば登録メールを訂正するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ訂正でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第176条　利用停止

利用停止については、一定処理の停止を求める場合という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばマーケティング連絡を止めるという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ利用停止でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第177条　第三者提供停止

第三者提供停止については、法令上認められる範囲での請求という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば提供停止を求めるという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ第三者提供停止でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第178条　本人確認

本人確認については、請求時のなりすまし防止という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば開示請求者を確認するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ本人確認でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

この編の読み方

この編は、一語一句を覚えるためではなく、新しい機能を追加したときに「その機能で新しく生まれるデータは何か、そのデータはどこから来てどこへ行き、何のためにどれだけ残り、誰が見られ、利用者にはどのような選択肢が必要か」という問いを忘れないための長いチェックリストでもあり、文章が長いほど自動的に透明性が高くなるわけではないからこそ、具体的な機能上の表示と併用することを前提としています。

第10編　海外・事故・将来技術・プライバシーの果て

最後は外国処理、漏えい等、まだ存在しない技術、極端なケースまで含めて長く整理します。

この編はプライバシーポリシーの理解を補助する詳細説明であり、現在の実装について事実ではない取得・保存・共有を追加して見せるための文章ではなく、現時点の処理は実態に合わせ、将来機能については条件付きの想定として区別し、実際にその処理を開始するときに具体情報を更新することを前提とします。

第179条　外国にある事業者

外国にある事業者については、国外事業者を使う場合の確認という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば海外クラウドを利用するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ外国にある事業者でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第180条　国・地域別通知

国・地域別通知については、特定地域向け追加説明という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば海外向けサービスを積極展開するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ国・地域別通知でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第181条　漏えい等

漏えい等については、事故発生時の調査と通知という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば個人データが誤公開されるという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ漏えい等でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第182条　誤送信

誤送信については、正しい相手以外へ送る事故という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばメール宛先を誤るという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ誤送信でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第183条　内部誤操作

内部誤操作については、運営上の人為ミスという観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば公開設定を誤るという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ内部誤操作でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第184条　第三者侵害

第三者侵害については、外部サービス側の事故という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば委託先で問題が起きるという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ第三者侵害でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第185条　新しい端末

新しい端末については、将来のデバイスから取得される可能性という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえばウェアラブル向け機能を作るという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ新しい端末でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第186条　新しい通信

新しい通信については、現在一般的でない通信形態という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば将来のブラウザAPIを使うという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ新しい通信でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第187条　新しい識別技術

新しい識別技術については、Cookie以外の識別が一般化する場合という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば新しい標準技術を導入するという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ新しい識別技術でも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

第188条　想定外の組合せ

想定外の組合せについては、既存情報の組合せで意味が変わる場合という観点から、情報の名称だけではなく、その情報がどの機能で発生し、利用者が自ら入力したのかWeb通信に伴って自動的に発生したのか、ブラウザ内に留まるのかサーバーまたは第三者サービスへ送信されるのか、何の目的で利用され、誰がアクセスでき、どの程度の期間残り、削除や訂正その他の選択肢がどのように提供されるのかまでを一連のデータフローとして把握することを重視し、同じ文字列や識別子であっても利用場面が変われば意味と取扱いが変わる可能性があるため、単に「収集する情報一覧」に名前を一つ足すだけでは十分な説明にならない場合があります。

たとえば複数の匿名に近い情報から同一利用者が推測されるという場面では、画面上は利用者が一回クリックしただけ、あるいは何も入力せずページを開いただけに見えても、配信、認証、セキュリティ、分析、保存、問い合わせ、決済その他の目的に応じて異なる通信や保存が発生することがあり、逆に、入力欄へ大量の文章やファイルを入れたとしても、ブラウザ内処理として設計されている主要データはサーバーへ送信せず端末内だけで処理できる場合もあるため、「入力した量」と「外部へ出る情報量」は一致しません。

当プロジェクトは、この編に将来の可能性を記載したことだけを理由として、現在取得していない情報を既に取得しているものとして扱ったり、将来どのような情報処理でも無制限に行えるものと解釈したりすることを意図せず、実際に新しい取得、保存、共有、AI送信、広告技術、位置情報、端末権限その他を導入する場合には、必要に応じて当該機能上の表示、プライバシーポリシー、外部送信に関する説明、同意その他を具体化します。

少し物語として追うと、同じ想定外の組合せでも、最初は一時的な処理のためだけに生まれ、次に利便性のため保存され、さらに同期のためアカウントへ結びつき、共有のため第三者から見えるようになり、分析のため集計され、問い合わせや不正利用調査のため別の文脈で参照される、といったように時間と機能追加によって役割が増えることがあり、プライバシーの説明は一度書いて終わる静的な説明書ではなく、実装の変化に追随し続ける運用文書として扱います。

この編の読み方

この編は、一語一句を覚えるためではなく、新しい機能を追加したときに「その機能で新しく生まれるデータは何か、そのデータはどこから来てどこへ行き、何のためにどれだけ残り、誰が見られ、利用者にはどのような選択肢が必要か」という問いを忘れないための長いチェックリストでもあり、文章が長いほど自動的に透明性が高くなるわけではないからこそ、具体的な機能上の表示と併用することを前提としています。

第11編　データライフサイクル総覧

この章は、情報の流れを細かく想定して将来の実装変更時に見落としを減らすための本編の一部であり、ここに列挙した情報を現在すべて取得、保存、利用または第三者提供していることを意味しません。実際の取扱いは本文、機能上の表示、外部送信ページその他の現行実装に即した説明を基準とし、新しい処理を導入する場合には必要な具体化を行います。

第189条　取得前

取得前に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば取得前が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、取得前を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、取得前という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第190条　取得時

取得時に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば取得時が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、取得時を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、取得時という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第191条　利用

利用に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば利用が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、利用を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、利用という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第192条　保存

保存に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば保存が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、保存を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、保存という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第193条　参照

参照に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば参照が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、参照を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、参照という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第194条　更新

更新に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば更新が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、更新を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、更新という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第195条　共有

共有に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば共有が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、共有を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、共有という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第196条　委託

委託に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば委託が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、委託を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、委託という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第197条　削除

削除に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば削除が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、削除を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、削除という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第198条　バックアップ

バックアップに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばバックアップが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、バックアップを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、バックアップという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第11編のまとめ

この章の長さは「何でも取得できる」と主張するためのものではなく、実際の実装と説明の差を減らし、何か新しい処理を始めたときに利用者が合理的に予測できる程度まで具体化するための検討項目を残すことを目的としています。

第12編　識別子・端末・通信情報

この章は、情報の流れを細かく想定して将来の実装変更時に見落としを減らすための本編の一部であり、ここに列挙した情報を現在すべて取得、保存、利用または第三者提供していることを意味しません。実際の取扱いは本文、機能上の表示、外部送信ページその他の現行実装に即した説明を基準とし、新しい処理を導入する場合には必要な具体化を行います。

第199条　IPアドレス

IPアドレスに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばIPアドレスが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、IPアドレスを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、IPアドレスという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第200条　Cookie

Cookieに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばCookieが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、Cookieを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、Cookieという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第201条　ローカル識別子

ローカル識別子に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばローカル識別子が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、ローカル識別子を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、ローカル識別子という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第202条　端末情報

端末情報に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば端末情報が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、端末情報を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、端末情報という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第203条　ブラウザ情報

ブラウザ情報に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばブラウザ情報が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、ブラウザ情報を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、ブラウザ情報という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第204条　参照元

参照元に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば参照元が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、参照元を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、参照元という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第205条　URL

URLに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばURLが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、URLを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、URLという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第206条　通信ログ

通信ログに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば通信ログが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、通信ログを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、通信ログという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第207条　地域情報

地域情報に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば地域情報が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、地域情報を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、地域情報という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第208条　時刻情報

時刻情報に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば時刻情報が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、時刻情報を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、時刻情報という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第12編のまとめ

この章の長さは「何でも取得できる」と主張するためのものではなく、実際の実装と説明の差を減らし、何か新しい処理を始めたときに利用者が合理的に予測できる程度まで具体化するための検討項目を残すことを目的としています。

第13編　入力内容と慎重な取扱いを要する情報

この章は、情報の流れを細かく想定して将来の実装変更時に見落としを減らすための本編の一部であり、ここに列挙した情報を現在すべて取得、保存、利用または第三者提供していることを意味しません。実際の取扱いは本文、機能上の表示、外部送信ページその他の現行実装に即した説明を基準とし、新しい処理を導入する場合には必要な具体化を行います。

第209条　自由記述

自由記述に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば自由記述が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、自由記述を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、自由記述という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第210条　ファイル

ファイルに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばファイルが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、ファイルを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、ファイルという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第211条　画像

画像に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば画像が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、画像を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、画像という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第212条　音声

音声に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば音声が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、音声を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、音声という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第213条　慎重な取扱いを要する情報

慎重な取扱いを要する情報に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば慎重な取扱いを要する情報が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、慎重な取扱いを要する情報を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、慎重な取扱いを要する情報という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第214条　機密性の高い情報

機密性の高い情報に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば機密性の高い情報が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、機密性の高い情報を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、機密性の高い情報という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第215条　第三者情報

第三者情報に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば第三者情報が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、第三者情報を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、第三者情報という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第216条　年齢に応じた配慮が必要な利用者の情報

年齢に応じた配慮が必要な利用者の情報に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば年齢に応じた配慮が必要な利用者の情報が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、年齢に応じた配慮が必要な利用者の情報を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、年齢に応じた配慮が必要な利用者の情報という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第217条　公開情報

公開情報に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば公開情報が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、公開情報を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、公開情報という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第218条　誤送信

誤送信に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば誤送信が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、誤送信を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、誤送信という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第13編のまとめ

この章の長さは「何でも取得できる」と主張するためのものではなく、実際の実装と説明の差を減らし、何か新しい処理を始めたときに利用者が合理的に予測できる程度まで具体化するための検討項目を残すことを目的としています。

第14編　AI・自動化・推論

この章は、情報の流れを細かく想定して将来の実装変更時に見落としを減らすための本編の一部であり、ここに列挙した情報を現在すべて取得、保存、利用または第三者提供していることを意味しません。実際の取扱いは本文、機能上の表示、外部送信ページその他の現行実装に即した説明を基準とし、新しい処理を導入する場合には必要な具体化を行います。

第219条　外部AI送信

外部AI送信に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば外部AI送信が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、外部AI送信を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、外部AI送信という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第220条　端末内AI

端末内AIに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば端末内AIが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、端末内AIを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、端末内AIという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第221条　生成ログ

生成ログに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば生成ログが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、生成ログを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、生成ログという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第222条　モデル改善

モデル改善に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばモデル改善が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、モデル改善を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、モデル改善という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第223条　自動分類

自動分類に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば自動分類が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、自動分類を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、自動分類という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第224条　推薦

推薦に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば推薦が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、推薦を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、推薦という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第225条　不正判定

不正判定に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば不正判定が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、不正判定を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、不正判定という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第226条　傾向分析

傾向分析に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば傾向分析が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、傾向分析を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、傾向分析という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第227条　人による確認

人による確認に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば人による確認が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、人による確認を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、人による確認という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第228条　将来モデル

将来モデルに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば将来モデルが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、将来モデルを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、将来モデルという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第14編のまとめ

この章の長さは「何でも取得できる」と主張するためのものではなく、実際の実装と説明の差を減らし、何か新しい処理を始めたときに利用者が合理的に予測できる程度まで具体化するための検討項目を残すことを目的としています。

第15編　連絡・通知・サポート

この章は、情報の流れを細かく想定して将来の実装変更時に見落としを減らすための本編の一部であり、ここに列挙した情報を現在すべて取得、保存、利用または第三者提供していることを意味しません。実際の取扱いは本文、機能上の表示、外部送信ページその他の現行実装に即した説明を基準とし、新しい処理を導入する場合には必要な具体化を行います。

第229条　問い合わせ

問い合わせに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば問い合わせが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、問い合わせを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、問い合わせという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第230条　返信

返信に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば返信が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、返信を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、返信という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第231条　重要通知

重要通知に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば重要通知が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、重要通知を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、重要通知という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第232条　メール配信

メール配信に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばメール配信が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、メール配信を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、メール配信という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第233条　配信停止

配信停止に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば配信停止が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、配信停止を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、配信停止という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第234条　サポート履歴

サポート履歴に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばサポート履歴が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、サポート履歴を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、サポート履歴という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第235条　障害連絡

障害連絡に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば障害連絡が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、障害連絡を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、障害連絡という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第236条　アンケート

アンケートに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばアンケートが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、アンケートを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、アンケートという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第237条　キャンペーン

キャンペーンに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばキャンペーンが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、キャンペーンを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、キャンペーンという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第238条　苦情

苦情に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば苦情が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、苦情を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、苦情という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第15編のまとめ

この章の長さは「何でも取得できる」と主張するためのものではなく、実際の実装と説明の差を減らし、何か新しい処理を始めたときに利用者が合理的に予測できる程度まで具体化するための検討項目を残すことを目的としています。

第16編　分析・実験・セキュリティログ

この章は、情報の流れを細かく想定して将来の実装変更時に見落としを減らすための本編の一部であり、ここに列挙した情報を現在すべて取得、保存、利用または第三者提供していることを意味しません。実際の取扱いは本文、機能上の表示、外部送信ページその他の現行実装に即した説明を基準とし、新しい処理を導入する場合には必要な具体化を行います。

第239条　アクセス解析

アクセス解析に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばアクセス解析が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、アクセス解析を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、アクセス解析という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第240条　イベント計測

イベント計測に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばイベント計測が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、イベント計測を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、イベント計測という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第241条　A/Bテスト

A/Bテストに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばA/Bテストが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、A/Bテストを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、A/Bテストという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第242条　性能計測

性能計測に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば性能計測が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、性能計測を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、性能計測という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第243条　エラー監視

エラー監視に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばエラー監視が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、エラー監視を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、エラー監視という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第244条　不正検知

不正検知に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば不正検知が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、不正検知を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、不正検知という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第245条　レート制限

レート制限に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばレート制限が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、レート制限を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、レート制限という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第246条　監査ログ

監査ログに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば監査ログが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、監査ログを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、監査ログという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第247条　ボット判定

ボット判定に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばボット判定が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、ボット判定を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、ボット判定という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第248条　統計化

統計化に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば統計化が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、統計化を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、統計化という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第16編のまとめ

この章の長さは「何でも取得できる」と主張するためのものではなく、実際の実装と説明の差を減らし、何か新しい処理を始めたときに利用者が合理的に予測できる程度まで具体化するための検討項目を残すことを目的としています。

第17編　アカウント・共有・公開

この章は、情報の流れを細かく想定して将来の実装変更時に見落としを減らすための本編の一部であり、ここに列挙した情報を現在すべて取得、保存、利用または第三者提供していることを意味しません。実際の取扱いは本文、機能上の表示、外部送信ページその他の現行実装に即した説明を基準とし、新しい処理を導入する場合には必要な具体化を行います。

第249条　プロフィール

プロフィールに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばプロフィールが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、プロフィールを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、プロフィールという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第250条　認証

認証に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば認証が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、認証を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、認証という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第251条　設定

設定に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば設定が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、設定を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、設定という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第252条　共有URL

共有URLに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば共有URLが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、共有URLを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、共有URLという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第253条　共同編集

共同編集に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば共同編集が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、共同編集を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、共同編集という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第254条　公開投稿

公開投稿に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば公開投稿が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、公開投稿を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、公開投稿という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第255条　コメント

コメントに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばコメントが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、コメントを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、コメントという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第256条　招待

招待に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば招待が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、招待を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、招待という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第257条　削除

削除に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば削除が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、削除を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、削除という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第258条　アカウント終了

アカウント終了に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばアカウント終了が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、アカウント終了を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、アカウント終了という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第17編のまとめ

この章の長さは「何でも取得できる」と主張するためのものではなく、実際の実装と説明の差を減らし、何か新しい処理を始めたときに利用者が合理的に予測できる程度まで具体化するための検討項目を残すことを目的としています。

第18編　決済・販売・配送

この章は、情報の流れを細かく想定して将来の実装変更時に見落としを減らすための本編の一部であり、ここに列挙した情報を現在すべて取得、保存、利用または第三者提供していることを意味しません。実際の取扱いは本文、機能上の表示、外部送信ページその他の現行実装に即した説明を基準とし、新しい処理を導入する場合には必要な具体化を行います。

第259条　注文

注文に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば注文が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、注文を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、注文という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第260条　支払状態

支払状態に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば支払状態が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、支払状態を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、支払状態という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第261条　決済事業者

決済事業者に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば決済事業者が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、決済事業者を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、決済事業者という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第262条　請求

請求に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば請求が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、請求を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、請求という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第263条　返金

返金に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば返金が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、返金を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、返金という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第264条　配送先

配送先に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば配送先が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、配送先を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、配送先という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第265条　配送事業者

配送事業者に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば配送事業者が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、配送事業者を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、配送事業者という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第266条　購入履歴

購入履歴に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば購入履歴が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、購入履歴を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、購入履歴という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第267条　サブスク

サブスクに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばサブスクが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、サブスクを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、サブスクという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第268条　取引相手

取引相手に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば取引相手が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、取引相手を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、取引相手という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第18編のまとめ

この章の長さは「何でも取得できる」と主張するためのものではなく、実際の実装と説明の差を減らし、何か新しい処理を始めたときに利用者が合理的に予測できる程度まで具体化するための検討項目を残すことを目的としています。

第19編　委託・外国・第三者サービス

この章は、情報の流れを細かく想定して将来の実装変更時に見落としを減らすための本編の一部であり、ここに列挙した情報を現在すべて取得、保存、利用または第三者提供していることを意味しません。実際の取扱いは本文、機能上の表示、外部送信ページその他の現行実装に即した説明を基準とし、新しい処理を導入する場合には必要な具体化を行います。

第269条　CDN

CDNに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばCDNが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、CDNを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、CDNという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第270条　クラウド

クラウドに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばクラウドが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、クラウドを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、クラウドという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第271条　分析事業者

分析事業者に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば分析事業者が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、分析事業者を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、分析事業者という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第272条　認証事業者

認証事業者に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば認証事業者が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、認証事業者を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、認証事業者という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第273条　決済事業者

決済事業者に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば決済事業者が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、決済事業者を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、決済事業者という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第274条　AI事業者

AI事業者に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばAI事業者が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、AI事業者を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、AI事業者という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第275条　外国サーバー

外国サーバーに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば外国サーバーが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、外国サーバーを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、外国サーバーという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第276条　外国第三者

外国第三者に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば外国第三者が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、外国第三者を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、外国第三者という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第277条　事業承継

事業承継に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば事業承継が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、事業承継を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、事業承継という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第278条　共同利用

共同利用に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば共同利用が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、共同利用を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、共同利用という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第19編のまとめ

この章の長さは「何でも取得できる」と主張するためのものではなく、実際の実装と説明の差を減らし、何か新しい処理を始めたときに利用者が合理的に予測できる程度まで具体化するための検討項目を残すことを目的としています。

第20編　権利行使・事故・削除後

この章は、情報の流れを細かく想定して将来の実装変更時に見落としを減らすための本編の一部であり、ここに列挙した情報を現在すべて取得、保存、利用または第三者提供していることを意味しません。実際の取扱いは本文、機能上の表示、外部送信ページその他の現行実装に即した説明を基準とし、新しい処理を導入する場合には必要な具体化を行います。

第279条　開示

開示に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば開示が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、開示を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、開示という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第280条　訂正

訂正に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば訂正が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、訂正を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、訂正という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第281条　削除

削除に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば削除が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、削除を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、削除という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第282条　利用停止

利用停止に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば利用停止が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、利用停止を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、利用停止という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第283条　本人確認

本人確認に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば本人確認が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、本人確認を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、本人確認という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第284条　代理人

代理人に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば代理人が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、代理人を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、代理人という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第285条　漏えい

漏えいに関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば漏えいが将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、漏えいを利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、漏えいという一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第286条　本人通知

本人通知に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえば本人通知が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、本人通知を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、本人通知という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第287条　バックアップ残存

バックアップ残存に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばバックアップ残存が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、バックアップ残存を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、バックアップ残存という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第288条　ポリシー変更

ポリシー変更に関する情報処理を考えるときは、単に「取得するか、しないか」という二択だけではなく、どの画面または機能を使ったときに発生し、利用者が入力するのか自動的に生成されるのか、端末内だけで扱うのかサーバーへ送るのか、第三者サービスが直接取得するのか、保存するならどの目的でどの程度の期間必要なのか、削除後にバックアップや監査記録へ一時的に残るのかという流れ全体を確認します。

たとえばポリシー変更が将来必要になったとしても、その可能性をここへ書いたことだけを理由に現在から無条件で取得するわけではなく、実際に取得または処理を開始する段階で、利用目的、取得方法、外部送信、保存、共有、権利行使その他のうち当該処理に必要な事項を、本文、機能上の表示、個別通知その他適切な方法で具体化することを前提とします。

同じ情報であっても、単なる変換対象として利用者のブラウザ内を通過する場合、問い合わせ返信先として当プロジェクトへ送信される場合、アカウント識別子として保存される場合、決済事業者が取引処理のため直接取得する場合、公開プロフィールとして第三者から見える状態に置かれる場合では意味が異なるため、情報の名称だけでなく役割と流路を基準に考えます。

また、ポリシー変更を利用することによって別の情報が推測できる場合、あるいは複数の情報を組み合わせることで識別可能性や利用者への影響が大きくなる場合には、個々の項目を孤立させて見るのではなく、組合せによるリスクも含めて検討し、実際のサービス規模、利用目的、保存期間、アクセス権限その他に応じた安全管理を行う考え方を採ります。

かなり長く一文で言えば、ポリシー変更という一項目をポリシーへ書くときでさえ、その情報がページを開いた瞬間に自動的に生じるのか、利用者が任意に入力するのか、機能を使わなければ発生しないのか、ブラウザ内で完結するのか、サーバーへ届くのか、委託先が処理するのか、外国に所在する事業者が関与するのか、他の情報と組み合わせれば本人を識別し得るのか、どの目的の達成まで必要なのか、削除依頼を受けたとき何を消せるのか、セキュリティ上残す必要がある記録はあるのかという多数の問いが同時に存在し得るので、「取得する場合があります」という一行だけで全部を終わらせず、実装が具体化した時点で説明も具体化します。

第20編のまとめ

この章の長さは「何でも取得できる」と主張するためのものではなく、実際の実装と説明の差を減らし、何か新しい処理を始めたときに利用者が合理的に予測できる程度まで具体化するための検討項目を残すことを目的としています。