Optional型を拡張できるらしい

OptionalのBoolをfalseとして扱う

public extension Bool? {
    /// 未設定の場合は false として扱う。
    var valueOrFalse: Bool {
        self ?? false
    }
}

let isPurchased: Bool? = nil
print(isPurchased.valueOrFalse) // false

Optionalの文字列を空文字として扱う

public extension String? {
    /// 未設定の場合は空文字として扱う。
    var valueOrEmpty: String {
        self ?? ""
    }
}

let title: String? = nil
print(title.valueOrEmpty) // ""

Optionalの配列を空配列として扱う

public extension [Manga]? {
    /// 未設定の場合は空配列として扱う。
    var valueOrEmpty: [Manga] {
        self ?? []
    }
}

let mangaList: [Manga]? = nil
print(mangaList.valueOrEmpty) // []

Optionalのステータスにデフォルト値を設定する

enum ReadingStatus {
    case unread
    case reading
    case completed
}

public extension ReadingStatus? {
    /// 未設定の場合は未読として扱う。
    var resolvedForDisplay: ReadingStatus {
        self ?? .unread
    }
}

元のコードは、実質的には次の処理を共通化したものです。

let displayType = contentType ?? .chapter

これを各所で書く代わりに、

let displayType = contentType.resolvedForDisplay

と、用途が分かりやすい名前で呼べるようにしています。特に単なるデフォルト値ではなく、「表示上はnilをChapterとして扱う」というドメイン上のルールを表現するときに向いています。

DatadogでURLSession監視を行う

Datadog RUM（iOS SDK）で URLSession の通信を Resource として監視する方法メモです。

以前は Delegate の登録が必要でしたが、dd-sdk-ios 3.7.0 以降は Delegate なしでも自動計測できるようになっています。

参考:

• RUM iOS Setup（公式）
• dd-sdk-ios #2620
• dd-sdk-ios #2634

---

以前のやり方（Delegate 必須）

まず RUM を有効化し、urlSessionTracking を渡します。

import DatadogRUM

RUM.enable(
  with: RUM.Configuration(
    applicationID: "<rum application id>",
    uiKitViewsPredicate: DefaultUIKitRUMViewsPredicate(),
    uiKitActionsPredicate: DefaultUIKitRUMActionsPredicate(),
    urlSessionTracking: RUM.Configuration.URLSessionTracking()
  )
)

そのうえで、監視したい URLSession の Delegate 型に対して URLSessionInstrumentation を有効化し、その Delegate を渡して Session を作る必要がありました。

URLSessionInstrumentation.enable(
    with: .init(
        delegateClass: YourSessionDelegate.self
    )
)

let session = URLSession(
    configuration: .default,
    delegate: YourSessionDelegate(),
    delegateQueue: nil
)

自分で作った Session ならまだしも、サードパーティ SDK が内部で持つ Session など、Delegate を差し込めないケースでは手が届かないことがありました。

---

3.7.0 以降の変更点

リリースノートより:

[機能追加] URLSession のリクエストを、Delegate の登録なしで自動的にネットワーク計測できるようになりました。（#2620）

[機能追加] URLSessionInstrumentation.enable(with:in:) API を非推奨とし、代わりに URLSessionInstrumentation.enableDurationBreakdown(with:in:) を使用するよう変更しました。（#2634）

つまり、「Delegate を登録しなくても監視できるのか？」への答えは Yes です。

---

Delegate なしでの監視方法

SDK を 3.7.0 以降に上げたうえで、RUM.Configuration に urlSessionTracking を指定します。これで すべての Session が自動トラック されます。

ポイントは次の通りです。

• urlSessionTracking のデフォルトは nil
• nil の場合は収集されない
• 監視したいなら明示的に .init()（または同等の設定）を渡す

import DatadogRUM

let rumConfiguration = RUM.Configuration(
    applicationID: "<RUM_APPLICATION_ID>",
    urlSessionTracking: .init()
)

RUM.enable(with: rumConfiguration)

以前のように URLSessionInstrumentation.enable(with:) で Delegate を登録する必要はありません。

---

まとめ

項目	以前	3.7.0 以降
Delegate 登録	必要	不要（自動計測）
有効化の鍵	URLSessionInstrumentation + Delegate	urlSessionTracking: .init()
デフォルト	—	urlSessionTracking == nil だと収集されない

「RUM は有効なのに Resource が出ない」ときは、まず urlSessionTracking を渡しているかを確認するとよさそうです。

GDPR（第一条〜第二十三条を読む）

GDPRとは

GDPR（一般データ保護規則）は、EU（欧州連合）が定めた、個人のプライバシーとデータ保護に関する厳格なルールです。EU域内にいる人々の個人情報を扱うすべての企業に適用されるため、EUに拠点を持たない日本企業も対象になる場合があります。

GDPRを読んでみる

gdpr-info.eu

---

主題と目的

GDPR 第1条（Subject-matter and objectives） は、規則全体の「何のための法律か」を定める条文。

和訳

• 第1項 本規則は、個人データの処理に関する自然人の保護に関する規則、および個人データの自由な移転に関する規則を定める。
• 第2項 本規則は、自然人の基本的人権と自由を保護し、特に個人データの保護に関する権利を保護する。
• 第3項 EU（連合）内における個人データの自由な移転は、個人データの処理に関する自然人の保護に関連する理由によって、制限してはならず、また禁止してはならない。

要点

• 規則の目的
  • 個人データ処理における自然人の保護に関するルールを定めること
  • 個人データの自由な移転に関するルールを定めること
• 保護対象
  • 自然人の基本的人権と自由
  • 特に「個人データの保護に関する権利」
• データ移転の原則
  • EU内での個人データの自由な移転を妨げないこと
  • 個人保護を理由に、データ移転を不当に制限・禁止しないこと
  • ただし「ルールなしで自由」ではなく、GDPR という共通ルールに従う前提での自由である

---

材料範囲

GDPR 第2条（Material scope） は、「どんな個人データ処理に GDPR が適用され、どれが除外されるか」を定める条文。

和訳

• 第1項（適用される処理） 本規則は、全部又は一部が自動的手段により行われる個人データの処理、及びファイリング・システムの構成部分をなす、又はファイリング・システムの構成部分をなすことを意図する個人データについて、自動的手段以外の方法により行われる処理に適用する。
• 第2項（適用除外） 本規則は、次の個人データの処理には適用しない。
  • (a) 連合法の適用範囲外の活動の過程におけるもの
  • (b) 加盟国が TEU 第5編第2章の適用範囲内の活動を行う場合のもの
  • (c) 自然人が純粋に個人的又は家庭的活動の過程において行うもの
  • (d) 犯罪の予防、捜査、発見又は起訴、若しくは刑罰の執行（公的安全に対する脅威の防止及び予防を含む。）を目的として、管轄当局が行うもの
• 第3項（EU機関） 連合の機関、团体、事務局及び機関による個人データの処理については、規則 (EC) 第45/2001号が適用される。規則 (EC) 第45/2001号及び当該個人データの処理に適用されるその他の連合法は、第98条に従い、本規則の原則及び規則に適合するよう改正されなければならない。
• 第4項（電子商取引指令との関係） 本規則は、指令 2000/31/EC、特に同指令第12条から第15条における仲介サービス提供者の責任規則の適用を害してはならない。

要点

• GDPR が適用される処理
  • コンピュータ等の自動的手段で行われる個人データの処理（全部または一部）
  • 手作業の処理でも、個人データがファイル・名簿として体系的に管理されている（または今後そう管理する予定の）もの
• GDPR が適用されない処理（主な除外）
  • (a) 連合法の範囲外の活動（例: 国家安全保障など別法域の領域）
  • (b) 加盟国による TEU 第5編第2章（共通外交・安全保障政策）の活動
  • (c) 個人の私的・家庭内活動（個人の日記、家庭内連絡など）
  • (d) 警察・検察など管轄当局による犯罪捜査・起訴・刑罰執行
• 別規則が優先する場合
  • EU 機関・機関等の処理 → 規則 (EC) 第45/2001号（GDPR 原則への整合を第98条で求める）
  • 仲介サービス提供者の責任 → 電子商取引指令（2000/31/EC）第12〜15条は引き続き適用

開発者目線のポイント

• アプリでユーザーID・端末ID・閲覧履歴などを扱うなら、通常は第1項の「自動処理」に該当しうる
• 個人の趣味用途（家庭内）なら除外だが、商用サービスは対象外にならない
• 捜査機関向けの処理は別法（Law Enforcement Directive 等）の話であり、一般アプリ開発では通常触れない

---

地域的範囲

GDPR 第3条（Territorial scope） は、「どの国・地域の企業や処理が GDPR の対象になるか（ territorial reach ）」を定める条文。

和訳

• 第1項（EU内に拠点がある場合） 本規則は、管理者又は処理者の EU 内の事業所の活動の文脈における個人データの処理に適用する。当該処理が EU 内で行われるか否かを問わない。
• 第2項（EU外に拠点がなくても適用される場合） 本規則は、EU 内に事業所を有しない管理者又は処理者が行う、EU 内にいるデータ主体の個人データの処理について、当該処理活動が次のいずれかに関連する場合に適用する。
  • (a) EU 内の当該データ主体に対する財又はサービスの提供（データ主体による支払いの要否を問わない。）
  • (b) EU 内で行われるデータ主体の行動の監視
• 第3項（公的国际法が適用される場所） 本規則は、EU 内に事業所を有しない管理者が行う個人データの処理について、公的国际法により加盟国法が適用される場所において行われる場合に適用する。

要点

• EU 内に拠点がある場合（第1項）
  • EU 内に事業所がある管理者・処理者の活動に関わる個人データ処理は、処理の物理的な場所が EU 外でも GDPR が適用される
• EU 外に拠点がなくても適用される場合（第2項） ← 日本企業で特に重要
  • EU 内にいるデータ主体（ユーザー）の個人データを処理する場合で、かつ次のいずれかに該当するとき
    • (a) サービス提供 — EU 内のユーザーに商品・サービスを提供している（無料サービスも含む）
    • (b) 行動の監視 — EU 内で行われるユーザーの行動を追跡・分析している（Analytics、広告 SDK、行動プロファイリング等）
• 公的国际法が適用される場所（第3項）
  • EU 外の領事館・公館など、公的国际法により加盟国法が及ぶ場所での処理にも適用

開発者目線のポイント

• EU 拠点がなくても、EU ユーザー向けアプリを提供していれば第2項 (a) に該当しうる
• 「有料かどうかは問わない」→ 無料のマンガアプリでも対象になりうる
• Firebase Analytics、広告 SDK 等は第2項 (b)「行動の監視」に該当しうる
• 第2条で「個人データ処理」に該当し、かつ第3条で「EU ユーザーに関係する」→ 両方満たせば GDPR 対象

---

個人データ処理の原則

GDPR 第5条（Principles relating to processing of personal data） は、個人データを扱う際に守るべき 7つの基本原則 を定める条文。GDPR 全体の中核。

和訳

• 第1項 個人データは、次のとおり処理されなければならない。
  • (a) 合法性・公正性・透明性（lawfulness, fairness and transparency） データ主体に関して、合法的かつ公正な方法で、かつ透明性をもって処理されること。
  • (b) 目的限定（purpose limitation） 特定され、明示的かつ正当な目的のために収集され、当該目的と両立しない方法でさらに処理されないこと。ただし、公共の利益のためのアーカイブ目的、科学的又は歴史的研究目的、又は統計目的のためのさらなる処理は、第89条第1項に従い、当初の目的と両立しないものとはみなされない。
  • (c) データ最小化（data minimisation） 処理の目的に関連して、適切かつ関連性があり、必要な範囲に限定されること。
  • (d) 正確性（accuracy） 正確であること。必要な場合は最新の状態に保たれること。処理の目的を考慮し、不正確な個人データについては、遅滞なく消去又は訂正するために、合理的なあらゆる措置が講じられなければならない。
  • (e) 保存期間の限定（storage limitation） 個人データの処理目的に必要な期間を超えて、データ主体の識別が可能な形で保存されないこと。ただし、第89条第1項に従い、公共の利益のためのアーカイブ目的、科学的又は歴史的研究目的、又は統計目的のみのために処理される場合は、より長期間保存してもよい。この場合、データ主体の権利と自由を保護するため、本規則が要求する適切な技術的及び組織的措置が実施されなければならない。
  • (f) 完全性・機密性（integrity and confidentiality） 個人データの適切な安全性が確保される方法で処理されること。これには、許可されていない又は違法な処理、及び偶発的な喪失、破壊又は損害からの保護が含まれ、適切な技術的又は組織的措置を用いるものとする。
• 第2項（説明責任：accountability） 管理者は、第1項の遵守について責任を負い、その遵守を立証できなければならない。

要点

• (a) 合法性・公正性・透明性
  • 合法的な根拠（第6条）に基づいて処理すること
  • ユーザーに対して公正に扱うこと
  • Privacy Policy 等で処理内容を透明に説明すること
• (b) 目的限定
  • 収集時に目的を特定・明示すること
  • 当初の目的と両立しない二次利用をしないこと
  • 例: サービス提供のために集めたデータを、同意なく広告目的に流用しない
• (c) データ最小化
  • 目的達成に必要なデータだけを集めること
  • 「とりあえず全部取る」は原則違反になりうる
• (d) 正確性
  • データを正確に保つこと
  • 誤りが判明したら遅滞なく訂正・削除すること
• (e) 保存期間の限定
  • 目的に必要な期間だけ保存すること
  • 不要になったら識別可能な形で保持しないこと
  • 保存期間を Privacy Policy や内部ポリシーで定める
• (f) 完全性・機密性
  • 不正アクセス・漏洩・紛失から保護すること
  • 暗号化、アクセス制御、ログ管理等の技術的・組織的措置を講じること
• 第2項 説明責任（accountability）
  • 上記原則を守っていることを 立証できる 状態にすること
  • 処理記録、ポリシー、同意ログ、DPIA 等の文書化が求められる

開発者目線のポイント

• 第5条は「GDPRで気をつけること」の 2〜6 とほぼ対応している
• データを送る前に「目的・必要最小限・保存期間・セキュリティ」を決める
• Analytics や SDK に渡すデータも、原則 (b)(c) の対象
• アカウント削除・履歴削除は (d)(e) の実装
• 「やっているつもり」ではなく、記録で説明できる状態（第2項）が重要

---

処理の合法性

GDPR 第6条（Lawfulness of processing） は、「個人データを処理してよい条件（法的根拠）」を定める条文。第5条(a)「合法性」の具体的内容。

和訳

• 第1項 処理は、次のいずれかが適用される場合に限り、かつその範囲内でのみ合法的である。
  • (a) 同意（consent） データ主体が、1つ以上の特定の目的のためにその個人データの処理について同意した場合
  • (b) 契約（contract） データ主体が当事者である契約の履行、又は契約締結前にデータ主体の要求に応じて措置を講ずるために必要な場合
  • (c) 法的義務（legal obligation） 管理者が従う法的義務の遵守のために必要な場合
  • (d) 生命の保護（vital interests） データ主体又は他の自然人の生命の利益を保護するために必要な場合
  • (e) 公共の利益・公務（public interest / official authority） 公共の利益のために、又は管理者に委ねられた公務の遂行のために行われる業務の遂行に必要な場合
  • (f) 正当な利益（legitimate interests） 管理者又は第三者が追求する正当な利益のために必要な場合。ただし、個人データの保護を要するデータ主体の利益又は基本的人権と自由が優先される場合（特にデータ主体が子どもの場合）は除く。
  • 第1項 (f) は、公務の遂行において行われる公的主体による処理には適用されない。
• 第2項 加盟国は、第1項 (c) 及び (e) に基づく処理の適用について、より具体的な規定を維持又は導入し、合法かつ公正な処理を確保するための要件を定めうる（第9章の特定処理状況を含む）。
• 第3項 第1項 (c) 及び (e) に基づく処理の根拠は、連合法又は管理者が従う加盟国法によって定められなければならない。処理の目的は当該法的根拠において定められ、又は (e) の場合は公務遂行に必要でなければならない。当該法的根拠には、処理の合法性の一般条件、データの種類、対象者、開示先、目的限定、保存期間、処理手続等を定める規定を含めうる。連合法又は加盟国法は、公共の利益の目的を満たし、追求する正当な目的に対して比例しなければならない。
• 第4項（目的外利用の両立性） 収集時の目的以外の目的での処理が、データ主体の同意又は第23条第1項の目的を保障するための必要かつ比例した連合法・加盟国法に基づかない場合、管理者は、当初の収集目的と両立するかを判断するにあたり、次を考慮しなければならない。
  • 収集目的と意図するさらなる処理の目的との関連性
  • 個人データが収集された文脈（特にデータ主体と管理者の関係）
  • 個人データの性質（第9条の特別カテゴリ、第10条の犯罪関連データの有無）
  • さらなる処理がデータ主体にもたらしうる結果
  • 暗号化や仮名化等の適切な保護措置の有無

要点

• 基本ルール
  • すべての処理には 6つの lawful basis のいずれか1つ が必要
  • 「同意があれば全部 OK」ではない → 処理ごとに根拠を選び、目的と対応させる
• 6つの法的根拠（アプリ開発でよく使うもの）
  • (a) 同意 — 広告、マーケティング、任意 Analytics 等。特定目的ごとに取得。撤回可能であること（第7条）
  • (b) 契約 — アカウント作成、サブスク課金、サービス提供に 直接必要 な処理
  • (c) 法的義務 — 法令上の保存・報告義務（税務、会計等）
  • (d) 生命の保護 — 緊急時の生命・身体の保護（一般アプリでは稀）
  • (e) 公共の利益・公務 — 主に公的機関向け（民間アプリでは通常使わない）
  • (f) 正当な利益 — 不正防止、セキュリティ等。利益衡量（LIA） が必要。子どもには特に慎重。マーケティング目的の主根拠にはなりにくい
• 第2・3項
  • (c)(e) は連合法・加盟国法に根拠が明記されている必要がある
  • 加盟国ごとに追加要件がある場合あり
• 第4項 目的外利用
  • 収集目的と異なる目的で使う場合、同意・法令・両立性判断 のいずれかが必要
  • 例: サービス提供のために集めたデータを、同意なく広告プロファイリングに流用 → 原則として不可（両立性も疑わしい）

開発者目線のポイント

• データ種別 × 目的ごとに表を作る（例: ユーザーID＋閲覧履歴 × Analytics → 同意 or 正当な利益？）
• サービス提供に必要 → (b) 契約、広告・任意トラッキング → (a) 同意 が基本
• (f) 正当な利益 を使う場合は法務と LIA を確認（「便利だから」は根拠にならない）
• SDK に送るデータも、送るたびに根拠が要る
• 第5条(b)「目的限定」とセットで、根拠と目的の対応表を残す
• 同意が不要 ≠ 説明不要 — 契約ベースでも Privacy Policy での通知（第13条） は必要
• 同意と契約を混ぜない — 「利用規約に同意 = データ処理の同意」とは限りません。処理目的が広告などなら、別途の同意 が要る

---

同意の条件

GDPR 第7条（Conditions for consent） は、第6条 (a) 同意 を lawful basis として使うときに満たすべき 条件 を定める条文。

和訳

• 第1項（立証責任） 同意に基づく処理については、管理者は、データ主体がその個人データの処理について同意したことを 立証できなければならない。
• 第2項（他事項との混在） データ主体の同意が、他の事項も含む書面による宣言の文脈で与えられる場合、同意の求めは、他の事項と 明確に区別 され、理解しやすくアクセスしやすい形式で、明確かつ平易な言葉を用いて提示されなければならない。当該宣言のうち本規則に違反する部分は 拘束力を有しない。
• 第3項（撤回権）
  • データ主体は、いつでも 同意を撤回する権利を有する。
  • 同意の撤回は、撤回前の同意に基づく処理の合法性には影響しない。
  • 同意を与える前に、データ主体は撤回権について 告知 されなければならない。
  • 同意を与えるのと 同じくらい容易に 撤回できなければならない。
• 第4項（自由な同意） 同意が自由に与えられたかを判断するにあたり、とりわけ、契約の履行（サービスの提供を含む）が、当該契約の履行に必要でない 個人データの処理への同意を条件としていないかを最大限考慮しなければならない。

要点

• 第1項 立証
  • 同意があったことの 記録 が必要（ログ、タイムスタンプ、同意内容、バージョン等）
  • 「同意したはず」では足りない
• 第2項 混在禁止
  • 利用規約・会員登録と Analytics 同意を 1つのチェックボックスにまとめない
  • 同意文言は平易で、他の条項と視覚的にも区別する
  • 違反部分（例: 事前チェック ON）は 無効
• 第3項 撤回
  • 設定画面等から いつでも OFF にできること
  • 撤回前に処理していた分は違法にならないが、撤回後は該当処理を止める
  • 同意取得時に「後から撤回できる」ことを伝える
  • 撤回が同意より難しい UI は NG（電話必須、深い階層のみ等）
• 第4項 バンドル禁止（重要）
  • 「サービスを使うには広告トラッキングに同意」→ 契約に不要な処理の同意を条件にできない
  • 同意なしでも 基本機能は使える 設計が原則

開発者目線のポイント

• CMP（同意管理）・設定画面で 目的別 ON/OFF と 撤回 を実装
• 事前チェック ON、ダークパターン、撤回の困難化は第7条違反になりうる
• 第6条で「同意が根拠」の処理だけが第7条の対象（契約ベースの処理は第7条の同意要件は不要）
• 同意ログは SDK 側（Firebase 等）だけでなく 自社でも保持 できるようにする

---

子どもの同意

GDPR 第8条（Conditions applicable to child's consent in relation to information society services） は、情報社会サービス（アプリ・Web 等）を子どもに直接提供し、同意 を lawful basis とする場合の 追加ルール を定める条文。

和訳

• 第1項（年齢閾値） 第6条第1項 (a) が適用され、情報社会サービスを子どもに直接提供する場合、16歳以上 の子どもの個人データの処理は合法的である。 16歳未満 の場合は、親権者等 が同意した、又は同意を承認した場合に限り、その範囲内で合法的である。
• 第2項（加盟国による年齢引下げ） 加盟国は、これらの目的について 13歳未満には下げない 範囲で、より低い年齢を法律で定めうる。
• 第3項（確認義務） 管理者は、当該場合において、同意が親権者等により与えられた、又は承認されたことを、利用可能な技術を考慮し、合理的な努力 をもって確認しなければならない。
• 第4項（契約法との関係） 第1項は、子どもに関する契約の有効性・成立・効力等についての加盟国の 一般契約法 には影響しない。

要点

• 適用範囲
  • 対象: 情報社会サービス（ISS）を 子どもに直接 提供する場合
  • 根拠: 第6条 (a) 同意 に基づく処理のみ（契約ベースは第8条の対象外）
  • EU デフォルト: 16歳未満 → 親権者の同意 が必要
• 加盟国ごとの差
  • 各国は 13〜15歳 に引き下げ可能（例: 独16、仏15、英13 など）
  • どの国のユーザーかで要件が変わる → 法務確認が必要
• 第3項 確認義務
  • 年齢確認・保護者同意の 合理的な確認 が必要
  • 100% 完璧な本人確認までは求められないが、「何もしない」は NG
  • 利用可能な技術（年齢ゲート、保護者メール確認等）を使う
• 第4項
  • データ保護の同意年齢と、民法上の契約能力は 別問題

開発者目線のポイント

• 一般向けマンガアプリでも EU の子どもユーザー がいれば対象になりうる
• 年齢制限・Teen 向け機能があるなら 特に要確認
• 同意ベースの Analytics / 広告 SDK は、16歳未満（または各国の閾値未満）では 親同意なしに送らない 設計
• 契約ベース（アカウント・課金）の処理は第8条の親同意要件の外だが、同意を根拠にする処理 には第8条が上乗せされる
• 実装例: 年齢入力、各国閾値に応じた CMP 分岐、保護者メール確認（法務と要相談）

---

特定カテゴリの個人データ

GDPR 第9条（Processing of special categories of personal data） は、センシティブ情報（特別カテゴリ） の処理を原則 禁止 し、例外を限定的に定める条文。第6条より 一段厳しい ルール。

和訳

• 第1項（原則禁止） 人種若しくは民族的出自、政治的意見、宗教的若しくは哲学的信念、又は組合員資格を明らかにする個人データ、遺伝子データ、自然人を一意に識別する目的の生体認証データ、健康に関するデータ、又は自然人の性生活若しくは性的指向に関するデータの処理は 禁止 される。
• 第2項（例外） 第1項は、次のいずれかが適用される場合には適用されない。
  • (a) 明示的同意 — 特定目的のためデータ主体が 明示的同意 した場合（ただし、加盟国法で禁止を解除できないと定める場合を除く）
  • (b) 雇用・社会保障 — 雇用・社会保障分野の義務・権利行使のため、連合法・加盟国法又は労働協約により認可され、適切な保護措置がある場合
  • (c) 生命の保護 — データ主体が同意できない場合の生命利益保護
  • (d) 非営利団体 — 政治・宗教・組合目的の非営利団体が、会員等に限定し適切な保護措置の下で行う場合
  • (e) 自発的公開 — データ主体が 自ら公然と公開 したデータ
  • (f) 法的請求 — 法的請求の提起・行使・防御、又は裁判所の司法活動のため
  • (g) 重大な公共の利益 — 連合法・加盟国法に基づき、比例性・保護措置を満たす場合
  • (h) 医療・社会保障 — 予防医学、診断、医療・社会保障の提供等（連合法・加盟国法又は医療従事者との契約、第3項の条件付き）
  • (i) 公衆衛生 — 国境を越える健康脅威への対応、医療の質・安全確保等（連合法・加盟国法、守秘義務等）
  • (j) 研究・アーカイブ・統計 — 第89条第1項に従い、連合法・加盟国法に基づく場合
• 第3項 第2項 (h) の目的で第1項データを処理する場合、連合法・加盟国法上 守秘義務 を負う専門家の責任下で行われるときに限り処理できる。
• 第4項 加盟国は、遺伝子データ・生体認証データ・健康データの処理について、追加の条件や制限 を維持又は導入できる。

要点

• 基本ルール: 原則禁止
  • 通常の個人データ（第6条）より はるかに厳しい
  • 該当データを扱うなら、第6条の lawful basis に加え 第9条の例外 も必要
  • 同意の場合も通常の同意ではなく 明示的同意（explicit consent） が必要
• 特別カテゴリの例
  • 人種・民族、政治・宗教・哲学、組合、遺伝子、生体認証（識別目的）、健康、性生活・性的指向
• 民間アプリで現実的な例外
  • (a) 明示的同意 — 自ら該当情報を入力・提供させる場合（ただし収集自体を避けるのが無難）
  • (e) 自発的公開 — ユーザーがプロフィール等で公然公開した場合
  • その他 (b)〜(j) は主に医療・雇用・公共機関・研究向け
• 第4項
  • 健康・生体・遺伝子データは加盟国ごとに さらに厳しい 場合あり

開発者目線のポイント

• ユーザーID・閲覧履歴・端末IDは 第9条の対象外（通常の個人データ）
• 触れうる例: プロフィールの宗教・健康情報、サポート問い合わせの健康データ、Face ID 等の生体認証を 識別目的 で保存
• 該当データを 意図せず収集しない（フォーム項目・ログ・SDK を点検）
• 収集するなら 明示的同意 + DPIA + 厳格な保護 が必要になりやすい → 法務/DPO 必須
• 第6条第4項の目的外利用判断でも「第9条データか」が考慮因子になる

---

犯罪関連データ

GDPR 第10条（Processing of personal data relating to criminal convictions and offences） は、有罪判決・犯罪・関連する保安措置 に関する個人データの処理を、第6条の lawful basis だけでは足りず、さらに厳格な条件 の下でのみ認める条文。第9条と並ぶ 特別ルール。

和訳

• 第1項 第6条第1項に基づく、有罪判決及び犯罪又は関連する保安措置に関する個人データの処理は、公的機関の管理下 で行われる場合、又はデータ主体の権利と自由を保護するための 適切な保護措置 を定める連合法若しくは加盟国法により 認可 されている場合に限り行われうる。
• 第2項 有罪判決の 包括的な台帳 は、公的機関の管理下 にのみ保持されうる。

要点

• 基本ルール: 第6条だけでは不十分
  • 通常の個人データと同様に第6条の lawful basis が必要だが、それに加えて 第10条の条件も満たす必要がある
  • 民間企業が 自由に収集・保存できない カテゴリ
• 処理できる条件（第1項）
  • 公的機関の管理下 で処理する
  • または 連合法・加盟国法 により認可され、データ主体の権利・自由を守る 適切な保護措置 が定められている
• 包括的台帳（第2項）
  • 有罪判決の 包括的なレジスタ は 公的機関のみ が保持できる
  • 民間が「犯罪歴データベース」を持つイメージは原則 NG
• 第9条との関係
  • 第9条: 人種・健康等の 特別カテゴリ → 原則禁止 + 例外
  • 第10条: 犯罪関連データ → 第6条ベースでも追加制限
  • 第6条第4項（目的外利用）の判断でも、第9条・第10条データの有無が考慮される

開発者目線のポイント

• ユーザーID・閲覧履歴・決済情報は 第10条の対象外
• 触れうる例: 採用・業務委託の身元調査、ユーザー報告フォームで犯罪歴を入力させる、コンテンツモデレーションで「違法行為の記録」を個人と紐づけて長期保存
• 該当データを 意図せず収集しない（サポートフォーム・内部管理画面・ログ設計を点検）
• 収集・保存するなら 法令上の認可 + 保護措置 + 法務/DPO 確認 が必要
• 「犯罪歴チェック API」を自社 DB に蓄積する設計は、第10条・第2項の観点で ほぼ不可 に近い

---

識別不要の処理

GDPR 第11条（Processing which does not require identification） は、処理目的上 本人を特定する必要がない 場合、GDPR 遵守のためだけに 追加情報を取得・保持して特定し直す義務はない ことを定める条文。ただし GDPR 自体の適用除外 ではない。

和訳

• 第1項 管理者が個人データを処理する目的が、管理者によるデータ主体の 識別を要しない、又は もはや要しない 場合、管理者は、本規則の遵守のみを目的としてデータ主体を識別するために、追加情報を 維持・取得・処理する義務を負わない。
• 第2項
  • (1) 告知 第1項の場合で、管理者がデータ主体を 識別できない立場 であることを立証できるとき、可能な限りデータ主体に その旨を通知 しなければならない。
  • (2) 権利の適用制限 そのような場合、第15条〜第20条（アクセス、訂正、消去、処理制限、通知義務、データポータビリティ）は 原則適用されない。ただし、データ主体が当該権利を行使するために 本人特定に足る追加情報 を提供した場合は除く。

要点

• 趣旨: 「特定し直せ」義務の免除
  • 統計・集計など 匿名に近い形 で十分な処理では、GDPR 対応のためだけに再識別情報を集めなくてよい
  • GDPR が不要になるわけではない — 第5条・第6条等は引き続き適用
• 第1項の前提
  • 処理目的が そもそも本人特定を要しない、または もはや要さない
  • 「匿名化したつもり」では足りず、実際に特定不能 であることが重要
• 第2項 (1) 告知
  • 特定できないなら、可能な範囲でユーザーに 「あなたを特定できません」 と伝える
• 第2項 (2) 第15〜20条の適用制限
  • 特定不能なら、原則として アクセス権・削除権等は行使できない
  • ユーザーがメールアドレス等 特定に足る情報 を出せば、権利行使は再び可能
• 典型例（該当しうる）
  • 完全に集計化された利用統計（個人に紐づかない）
  • 仮名化後、鍵を破棄 し再識別不能になったデータ
• 典型例（該当しにくい）
  • ログインアカウント、ユーザーID、端末ID、メールアドレスが残る通常のアプリ

開発者目線のポイント

• ユーザーID 等で特定可能なことが多い
• 仮名化 ≠ 第11条適用 — 再識別キー（ユーザーID、ハッシュのソルト等）を保持していれば「特定不能」とは言いにくい
• 集計ダッシュボードだけ見る場合でも、生ログに識別子が残っていれば 第11条は使えない
• 「Analytics だから GDPR 外」という解釈は 誤り — 識別子付きイベント送信は通常 GDPR 対象
• 削除請求対応で 「特定できません」 と言うには、第2項 (1) の要件（特定不能の立証）を満たす必要がある → 安易な言い訳にならない
• 設計上、本当に特定不要な処理（集計のみ）と、アカウント紐づけ処理を 分離 しておくと説明しやすい

---

透明性と権利行使の手続

GDPR 第12条（Transparent information, communication and modalities for the exercise of the rights of the data subject） は、第13・14条の 情報提供 と第15〜22条の 権利行使 について、どの形式・手続・期限 で対応するかを定める条文。第5条(a)「透明性」の 手続面 の具体化。

和訳

• 第1項（情報提供の形式） 管理者は、第13条及び第14条に言及する情報、並びに第15条から第22条及び第34条に基づく処理に関する通信を、簡潔で、透明性があり、理解しやすく、アクセスしやすい 形式で、明確かつ平易な言葉 を用いて提供するための 適切な措置 を講じなければならない。とりわけ 子ども向け の情報についてはそのようにしなければならない。
  • (2) 情報は 書面 又は その他の手段（適切な場合は 電子的手段 を含む。）で提供する。
  • (3) データ主体の要求がある場合、口頭 で提供してもよい。ただし、データ主体の同一性が 他の手段で証明 されている場合に限る。
• 第2項（権利行使の円滑化）
  • (1) 管理者は、第15条から第22条に基づくデータ主体の権利行使を 円滑化 しなければならない。
  • (2) 第11条第2項の場合でも、管理者は第15条から第22条に基づく権利行使の要求に 応じることを拒否してはならない。ただし、管理者がデータ主体を 識別できない立場 であることを立証できる場合を除く。
• 第3項（対応期限）
  • (1) 第15条から第22条に基づく要求への対応内容は、遅滞なく、いずれにせよ要求受領から 1か月以内 にデータ主体に提供しなければならない。
  • (2) 要求の 複雑性・件数 を考慮し必要な場合、当該期間を さらに2か月延長 できる。
  • (3) 延長する場合、要求受領から 1か月以内 に、延長理由とともにデータ主体に 通知 しなければならない。
  • (4) データ主体が 電子的手段 で要求した場合、特段の要求がない限り、可能な限り電子的手段 で回答する。
• 第4項（不対応時） 管理者が要求に 措置を取らない 場合、遅滞なく、遅くとも要求受領から 1か月以内 に、不対応の理由、監督機関への 苦情申立て の可能性、司法上の救済 を求める可能性についてデータ主体に通知しなければならない。
• 第5項（無償原則）
  • (1) 第13・14条の情報提供、第15〜22条・第34条に基づく通信・措置は 原則無償。
  • (2) 要求が 明白に根拠がない 又は 過度（特に 反復的）な場合、管理者は次のいずれかを行える。
    • 情報提供・通信・措置に要する 管理的コスト を考慮した 合理的な手数料 を請求する
    • 要求への対応を 拒否 する
  • (3) 要求が明白に根拠がない又は過度であることの 立証責任 は管理者にある。
• 第6項（本人確認） 第11条を害しない範囲で、第15条から第21条の要求を行う自然人の 同一性について合理的な疑い がある場合、管理者はデータ主体の同一性を確認するために 必要な追加情報 の提供を求めうる。
• 第7項（標準化アイコン）
  • (1) 第13・14条に基づく情報は、意図する処理の 意味のある概要 を、見やすく理解しやすく明瞭に示すため、標準化されたアイコン と組み合わせて提供してもよい。
  • (2) アイコンが電子的に提示される場合、機械可読 でなければならない。
• 第8項 委員会は、第92条に従い、アイコンが示すべき情報及び標準化アイコンの提供手続を定める 委任法規 を採択する権限を有する。

要点

• 情報提供の原則（第1項）
  • 平易・簡潔・アクセスしやすい — Privacy Policy を専門用語だらけにしない
  • 子ども向け は特に平易な表現が必要
  • 書面・電子・（要求があれば）口頭
• 権利行使の円滑化（第2項）
  • 削除請求・アクセス請求等を ユーザーが行使しやすい 設計・窓口が必要
  • 第11条で特定不能でも、「特定できないから拒否」 は立証が必要（安易に拒否できない）
• 1か月ルール（第3・4項） ← 実務で重要
  • DSAR（データ主体の権利要求）への回答期限: 原則1か月
  • 複雑・大量なら +2か月延長可（1か月以内に延長通知）
  • 拒否・不対応も 1か月以内 に理由＋苦情・司法救済の案内
  • 電子で来た要求は 電子で返す
• 無償原則（第5項）
  • 通常は 無料 で対応
  • 反復・過度・根拠なし の要求のみ、手数料 or 拒否可（立証は管理者）
• 本人確認（第6項）
  • 削除請求等で なりすまし防止 のため追加情報を求めてよい
  • ただし第11条（特定不能）とのバランス
• 標準化アイコン（第7・8項）
  • Privacy Policy の視覚的サマリー（機械可読アイコン）— EU 共通仕様は委任法規で今後定められる

開発者目線のポイント

• Privacy Policy は第12条＋第13条の実装 — アプリ内・Web から アクセスしやすく、平易な言葉で
• DSAR 対応フロー を用意: 受付 → 本人確認 → 1か月以内回答（延長時は通知）
• アカウント削除・データエクスポート は第17・20条の権利行使 — 設定画面や問い合わせ窓口から 到達可能 に
• 内部チケット・SLA で 1か月期限 を管理（法務・CS・エンジニア連携）
• 拒否する場合も第4項どおり 理由・監督機関・司法救済 を文書で返す
• 同意撤回（第7条）と削除請求（第17条）の UI・バックエンド停止処理 を分けて設計
• 子ども向け文言・Teen 向け Privacy 説明は第1項で特に重視

---

収集時の情報提供義務

GDPR 第13条（Information to be provided where personal data are collected from the data subject） は、データ主体本人から 個人データを収集するとき、収集時点 に告知すべき 必須項目 を列挙する条文。Privacy Policy の チェックリスト そのもの。第12条の「どう伝えるか」に対し、第13条は 何を伝えるか。

和訳

• 第1項（収集時に必ず告知） データ主体から個人データを収集する場合、管理者は 個人データを取得した時点 で、データ主体に次の すべて の情報を提供しなければならない。
  • (a) 管理者の身元・連絡先 — 管理者及び（該当する場合）代表者の身元と連絡先
  • (b) DPO — （該当する場合）データ保護責任者（DPO）の連絡先
  • (c) 目的と法的根拠 — 個人データの処理目的及び処理の 法的根拠（第6条）
  • (d) 正当な利益 — 処理が第6条第1項 (f) に基づく場合、管理者又は第三者が追求する 正当な利益
  • (e) 受領者 — 個人データの受領者又は受領者の カテゴリ（存在する場合）
  • (f) 第三国移転 — （該当する場合）第三国・国際機関への移転の 予定、委員会の 十分性認定 の有無、又は第46条・第47条・第49条第1項第2段落に基づく 適切な保護措置 及びその写しの入手方法
• 第2項（追加の透明性情報） 第1項に加え、公正かつ透明な処理 を確保するために必要な次の情報も、収集時点 で提供しなければならない。
  • 保存期間 — 個人データの保存期間、又はそれが不可能な場合は当該期間を決定する 基準
  • データ主体の権利 — アクセス、訂正、消去、処理制限、処理への異議、データポータビリティ を管理者に要求する権利の存在
  • 同意の撤回 — 処理が第6条第1項 (a) 又は第9条第2項 (a) に基づく場合、いつでも同意を撤回 できる権利（撤回前の処理の合法性には影響しない旨）
  • 苦情申立て — 監督機関に 苦情を申し立てる 権利
  • 提供の要否 — 個人データの提供が 法令上又は契約上の要件 か、契約締結に 必要な要件 か、提供 義務 があるか、提供しなかった場合の 可能的結果
  • 自動化された意思決定 — 第22条第1項及び第4項の プロファイリング等を含む自動化された意思決定 の有無、該当する場合は ロジック、処理の 意義 及びデータ主体への 想定される結果 に関する意味のある情報
• 第3項（目的外処理） 収集目的と 異なる目的 でさらに処理する場合、当該処理の 前に、その他の目的及び第2項の関連情報をデータ主体に提供しなければならない。
• 第4項（既知情報の除外） データ主体が 既に当該情報を有している 場合及びその範囲では、第1項〜第3項は 適用されない。

要点

• 適用タイミング: 収集時点
  • 会員登録、初回起動、フォーム入力、Analytics 開始 前または同時 に告知
  • 「後から Privacy Policy を更新すれば OK」だけでは不十分な場合あり
• 第1項 = Privacy Policy の骨格
  • 誰が（管理者・DPO）
  • 何のため・なぜ合法か（目的 × lawful basis）
  • 誰に渡すか（受領者・SDK・委託先）
  • 海外に送るか（第三国移転・十分性・SCC 等）
• 第2項 = ユーザー権利と条件
  • 保存期間（または決め方）
  • 権利一覧（アクセス・削除・ポータビリティ等）→ 第15〜20条への入口
  • 同意撤回（同意ベースの処理がある場合）
  • 監督機関への苦情
  • 必須入力か（メール必須の理由と、拒否した場合の影響）
  • 自動プロファイリング の有無（広告・レコメンド等）
• 第3項 目的外利用
  • 新目的（例: 広告）を 後から追加 するなら、処理前に 追加告知（第6条第4項とセット）
• 第4項
  • 既に分かっている情報の 重複告知 は不要（ただしアクセスしやすさは第12条で依然必要）

開発者目線のポイント

• Privacy Policy 必須項目チェックリスト として第13条を使う（法務と照合）
• アプリ内 Privacy Policy リンク を Account 画面等から 1〜2タップ で開けるように（第12条のアクセスしやすさ）
• 処理ごとに 目的・lawful basis・受領者（Firebase、Singular 等 SDK 名）を 対応表 で整理 → Policy に反映
• 同意ベースの Analytics / 広告があるなら 撤回方法 を Policy と設定 UI の両方に記載
• 保存期間 を「未定」にせず、基準か期間を書く（閲覧履歴 X年、ログ Y日 等）
• 第三国移転（米国 SaaS 等）を Policy に明記 — SCC・十分性判断は法務
• 新 SDK 追加・新目的のデータ送信は 第3項 的に Policy 更新＋必要なら再同意
• CMP の同意画面も、第13条の 目的・根拠・受領者 を簡潔に示すとよい

---

第三者由来データの情報提供義務

GDPR 第14条（Information to be provided where personal data have not been obtained from the data subject） は、データ主体本人以外 から個人データを取得した場合に告知すべき項目と タイミング を定める条文。第13条の「本人から収集」と対になる 間接取得 向けルール。

和訳

• 第1項（告知内容） データ主体からではなく取得した個人データについて、管理者はデータ主体に次の情報を提供しなければならない。
  • (a) 管理者の身元・連絡先 — 管理者及び（該当する場合）代表者
  • (b) DPO — （該当する場合）DPO の連絡先
  • (c) 目的と法的根拠 — 処理目的及び 法的根拠（第6条）
  • (d) データのカテゴリ — 対象となる個人データの カテゴリ
  • (e) 受領者 — 受領者又は受領者のカテゴリ（存在する場合）
  • (f) 第三国移転 — （該当する場合）第三国・国際機関への移転、十分性認定の有無、第46条・第47条・第49条第1項第2段落に基づく保護措置及び写しの入手方法
• 第2項（追加の透明性情報） 第1項に加え、データ主体に対する 公正かつ透明な処理 のために必要な次の情報も提供しなければならない。
  • 保存期間 — 保存期間又は決定 基準
  • 正当な利益 — 処理が第6条第1項 (f) に基づく場合の 正当な利益
  • データ主体の権利 — アクセス、訂正、消去、処理制限、異議、データポータビリティ
  • 同意の撤回 — 第6条 (a) 又は第9条 (a) に基づく場合の 撤回権（撤回前の合法性には影響しない旨）
  • 苦情申立て — 監督機関への苦情申立て権
  • データの出所 — 個人データの 取得元、及び（該当する場合）公開されている情報源 から得たか否か
  • 自動化された意思決定 — 第22条の プロファイリング等 の有無、該当時はロジック・意義・想定される結果
• 第3項（告知タイミング） 第1項・第2項の情報は、次の いずれか早い時点 までに提供しなければならない。
  • (a) 個人データ取得後 合理的期間内、遅くとも 1か月以内（処理の具体的情況を考慮）
  • (b) データ主体への 連絡 に当該データを使う場合 → 最初の連絡時 まで
  • (c) 他の受領者への開示 を予定する場合 → 最初の開示時 まで
• 第4項（目的外処理） 収集目的と異なる目的でさらに処理する場合、当該処理の 前に、その目的及び第2項の関連情報を提供しなければならない（第13条第3項と同趣旨）。
• 第5項（適用除外） 第1項〜第4項は、次の場合及びその範囲では 適用されない。
  • (a) データ主体が 既に当該情報を有している
  • (b) 告知が 不可能 又は 過度の努力 を要する（特に第89条の研究・アーカイブ・統計目的）。この場合、権利保護のための 適切な措置（情報の 公表 等）を講じる
  • (c) 連合法・加盟国法で取得・開示が 明確に定められ、データ主体の正当な利益を保護する措置がある
  • (d) 連合法・加盟国法上の 守秘義務（職業上の秘密を含む）により個人データが 機密 でなければならない場合

要点

• 第13条との違い
  • 取得元: 第13条＝本人から / 第14条＝本人以外（第三者・公開源・パートナー等）
  • タイミング: 第13条＝収集時点 / 第14条＝取得後 1か月以内 等（第3項）
  • 第14条固有: データのカテゴリ、取得元・公開源 の告知
• 告知タイミング（第3項） ← 間接取得で重要
  • 原則: 取得後 1か月以内
  • ユーザーに 初めて連絡 する時（メール等）までに告知
  • 第三者に渡す前 に告知
• 第5項 適用除外
  • 研究・統計等で 全員に個別告知が非現実的 な場合 → 公表等の代替措置
  • 法令上 守秘義務 がある場合は告知不要なことも
• 目的外・権利・第三国移転 は第13条とほぼ同様

開発者目線のポイント

• 一般のマンガアプリ では、ユーザーが直接登録・利用するため 第13条が中心。第14条は 間接取得 があるときだけ意識
• 第14条が触れうる例: パートナー・広告ネットワークから取得した属性データ、公開プロフィールのスクレイピング、B2B で受け取ったメールリスト（通常は別問題）
• 自社アプリで ユーザーが入力したデータ は第13条。SDK が裏で収集する端末情報 も通常は「本人の端末経由」→ 第13条側で Policy 告知
• 将来 第三者データを結合 する設計（例: 外部 ID グラフ）なら第14条＋ 1か月以内告知 ＋ 出所・カテゴリ の記載が必要
• Privacy Policy に 「第三者から取得する場合」 条項を入れておくと、第14条対応時の土台になる
• 第13条と 重複する項目（目的・根拠・権利・第三国移転）は Policy で 統一記載 し、第14条固有（出所・カテゴリ・告知期限）だけ追加すればよい

---

アクセス権（開示請求権）

GDPR 第15条（Right of access by the data subject） は、データ主体が 自分の個人データが処理されているか確認 し、処理されている場合は データと関連情報の開示 を管理者に求められる権利を定める条文。DSAR（データ主体アクセス要求）の 中核。

和訳

• 第1項（確認・開示・付随情報） データ主体は、管理者から、自分に関する個人データが処理されているか否か の 確認 を得る権利を有する。処理されている場合は、当該個人データへのアクセス 及び次の情報を得る権利を有する。
  • 処理目的
  • 個人データのカテゴリ
  • 受領者又は受領者のカテゴリ — 個人データが開示された、又は開示される 受領者。とりわけ 第三国又は国際機関 の受領者
  • 保存期間 — 可能な限り、個人データが保存される 予定期間。不可能な場合は当該期間を決定する 基準
  • その他の権利 — 訂正、消去、処理制限、異議申立てを管理者に要求する 権利の存在
  • 苦情申立て — 監督機関に 苦情を申し立てる 権利
  • データの出所 — データ主体から収集していない場合、入手可能な範囲 での 取得元 に関する情報
  • 自動化された意思決定 — 第22条第1項及び第4項の プロファイリング等を含む自動化された意思決定 の有無、該当する場合は ロジック、処理の 意義 及びデータ主体への 想定される結果 に関する意味のある情報
• 第2項（第三国移転の保護措置） 個人データが第三国又は国際機関に移転されている場合、データ主体は、移転に関する第46条に基づく 適切な保護措置 について 告知 を受ける権利を有する。
• 第3項（データの写し）
  • (1) 管理者は、処理中の個人データの 写し を提供しなければならない。
  • (2) データ主体が 追加の写し を要求した場合、管理者は 管理的コスト に基づく 合理的な手数料 を請求してもよい。
  • (3) データ主体が 電子的手段 で要求した場合、データ主体が別途要求しない限り、情報は 一般的に使用される電子形式 で提供されなければならない。
• 第4項（第三者の権利との調整） 第3項の写し取得権は、他者の権利と自由 を不当に害してはならない。

要点

• 2段階の権利
  • (1) 処理の有無の確認 — 「私のデータを扱っていますか？」
  • (2) 処理がある場合 — データ本体 ＋ メタ情報（目的・カテゴリ・受領者・保存期間・権利・出所・プロファイリング等）の開示
• 第13・14条との関係
  • 第13・14条＝事前告知（Privacy Policy）
  • 第15条＝事後的な個別開示（ユーザーが要求したときの 実データ）
  • 開示項目は第13・14条と かなり重複 するが、第15条は 写し（コピー） まで含む
• 写しの提供（第3項） ← 実務で重要
  • 1回目の写しは原則無償（第12条第5項とセット）
  • 追加写し は管理的コストに基づく 手数料可
  • 電子で来た要求 → 電子形式 で返す（JSON/CSV 等が一般的）
• 第4項 他者の権利
  • 開示データに 第三者の個人情報 や 営業秘密 が含まれる場合、マスキング・部分開示 等で調整
  • 「全部丸ごとダンプ」が常に可能とは限らない
• 対応期限 — 第12条第3項どおり 原則1か月以内（延長可）

開発者目線のポイント

• DSAR 対応 の実装対象 — 「私のデータを見せて」要求に 1か月以内 で応答できる体制が必要（第12条とセット）
• データエクスポート機能 は第15条（写し）＋第20条（ポータビリティ）の 入口 — Account 画面や問い合わせ窓口から 到達可能 に
• 開示対象の整理: アカウント情報、閲覧履歴、My List、Analytics に送ったイベント（自社ログ）、同意ログ 等を どこに何があるか 把握しておく
• 電子形式 で返すなら、人間可読（PDF）だけでなく 機械可読（JSON/CSV）も検討 — 第20条ポータビリティとも接続
• 第三者データ（第14条）が混在する場合、出所情報 も開示対象
• 他者の権利（第4項）: 他ユーザーのデータがログに混ざる場合は マスキング が必要。サポート履歴・共有コンテンツ等に注意
• 追加写しの手数料 は第12条第5項「原則無償」と両立 — 通常は 初回無償、反復・大量要求のみ手数料 or 拒否可
• Privacy Policy には アクセス権の存在と行使方法（問い合わせ先・設定画面リンク）を記載（第13条第2項）
• 例:

✅ 渡す（例）
- プロフィール
- 閲覧履歴
- 購入履歴
- 同意設定
- 自社DBに残っている Analytics イベント

⚠️ 調整が必要（例）
- サポートログに他ユーザーのメールが混ざる → マスキング
- 内部の不正検知スコア → 営業秘密・他者への影響を考慮

❌ 渡さない／渡せない（例）
- 既に削除済みの古いログ
- 個人と紐づかない集計データ
- 他ユーザーのデータ

---

訂正権

GDPR 第16条（Right to rectification） は、データ主体が 不正確な個人データの訂正 と 不完全な個人データの補完 を管理者に求められる権利を定める条文。第5条(d)「正確性」の 権利行使面 の具体化。

和訳

• 第1項（不正確なデータの訂正） データ主体は、管理者から 不当な遅延なく、自分に関する 不正確な個人データの訂正 を得る権利を有する。
• 第2項（不完全なデータの補完） 処理の目的を考慮し、データ主体は 不完全な個人データの完成 を求める権利を有する。これには 補足説明の提供 による完成も含まれる。

要点

• 2つの権利
  • (1) 訂正 — 間違っているデータを 正しい内容に直す（例: 誤ったメールアドレス、旧姓のままの表示名）
  • (2) 補完 — 足りないデータを 埋める（例: プロフィールの必須項目が空、住所の一部のみ登録）
• 「不当な遅延なく」（第1項） ← 第12条の「遅滞なく」と接続
  • 明確な 即時性 が求められる
  • DSAR 対応期限（原則1か月）より 短い対応 が期待されるケースが多い
  • 内部 SLA では 数日以内 等を目安にすることが多い（法務判断）
• 補足説明による補完（第2項）
  • データベースのフィールドを直接編集できない場合でも、ユーザーの説明文を追記 して完成させる手段が認められる
  • 例: 「正式名称は ○○ です」という補足ステートメントをプロフィールに追加
• 処理目的との関係（第2項）
  • 補完の範囲は 処理目的に関連する範囲 に限定される
  • サービス提供に不要な追加情報の提供を 強制できない 側面もある
• 第15条・第17条との関係
  • 第15条: まず 現状を確認（アクセス権）
  • 第16条: 間違い・不足を直す（訂正権）
  • 第17条: 削除（消去権）— 訂正で足りない場合の選択肢

開発者目線のポイント

• プロフィール編集 UI は第16条の 自助手段 — ユーザーが自分で直せる項目（表示名、メール等）は、アプリ内編集を 用意しておく のが基本
• ユーザーが直せないデータ（課金履歴の誤記、バックエンドの属性データ）→ 問い合わせ窓口 で訂正要求を受け付けるフローが必要
• 訂正要求の反映 は、自社DBだけでなく 委託先・SDK 側 にも波及しうる — どこまで同期するかをデータマップで把握
• Analytics / 広告 SDK に送った誤データは、SDK 側で訂正・削除が難しい場合がある → Privacy Policy で 委託先への訂正依頼 フローを明記
• 第5条(d)「正確性」とセット — ユーザーから訂正連絡が来たら 遅滞なく 対応する運用（CS・エンジニア連携）
• アカウント画面の Edit Profile 等、既存の編集機能は第16条対応の 良い実装例 — 到達性（第12条）も確認

---

消去権（忘れられる権利）

GDPR 第17条（Right to erasure / right to be forgotten） は、データ主体が 個人データの消去 を求められる権利と、消去しなければならない条件 を定める条文。アカウント削除・同意撤回後のデータ停止と 直結 する。

和訳

• 第1項（消去権と消去義務） データ主体は、管理者から 不当な遅延なく 自分に関する個人データの 消去 を得る権利を有する。管理者は、次の いずれかの理由 に該当する場合、 不当な遅延なく 個人データを消去する 義務 を負う。
  • (a) 目的外不要 — 収集又はその他の処理の 目的に対して 個人データが もはや必要でない
  • (b) 同意の撤回 — 処理が第6条第1項 (a) 又は第9条第2項 (a) に基づき、データ主体が 同意を撤回 し、かつ 他の法的根拠がない
  • (c) 異議申立て — データ主体が第21条第1項に基づき 異議 を申し立て、処理を覆す 優先する正当な理由がない、又は第21条第2項に基づき異議を申し立てた
  • (d) 違法な処理 — 個人データが 違法に 処理された
  • (e) 法的義務 — 管理者が従う連合法又は加盟国法上の 法的義務 の遵守のために消去が必要
  • (f) 子どもの ISS — 第8条第1項の 情報社会サービス の提供に関連して収集された個人データ
• 第2項（公開データの連鎖消去） 管理者が個人データを 公開 しており、第1項に基づき消去義務がある場合、利用可能な技術及び実装コストを考慮し、当該個人データの リンク・写し・複製 の消去を、データ主体が他の管理者に要求した旨を 他の管理者に通知する ための 合理的措置（技術的措置を含む。）を講じなければならない。
• 第3項（消去義務の例外） 第1項・第2項は、次の目的で 処理が必要 な範囲では 適用されない。
  • (a) 表現・情報の自由 — 言論の自由及び情報を受け取る権利の行使
  • (b) 法的義務・公共の利益 — 連合法・加盟国法上の 法的義務 の遵守、又は公共の利益のための公務・公権力の行使
  • (c) 公衆衛生 — 第9条第2項 (h)(i) 及び第9条第3項に基づく公衆衛生分野の公共の利益
  • (d) 研究・アーカイブ・統計 — 第89条第1項に基づく目的。第1項の権利行使が当該処理の目的達成を 不可能又は著しく損なう 場合
  • (e) 法的請求 — 法的請求の提起・行使・防御

要点

• 「忘れられる権利」の中身
  • 単なる「アカウント無効化」ではなく、識別可能な個人データの消去 が求められる
  • 不当な遅延なく — 第16条と同様、第12条の DSAR 期限（1か月）より 早い対応 が期待されることが多い
• 消去が義務づけられる6つの理由（第1項） ← 実務で重要
  • (a) 不要になった — 保存期間経過、目的達成後
  • (b) 同意撤回 — 同意ベースの Analytics / 広告等。他の lawful basis がなければ消去
  • (c) 異議申立て — 第21条（後述）で処理に異議 → 優先理由がなければ消去
  • (d) 違法処理 — lawful basis なし、目的外利用等
  • (e) 法令上の消去義務
  • (f) 子どもの ISS — 第8条関連データ
• 同意撤回 vs アカウント削除
  • 同意撤回（第7条） = 当該目的の 処理を止める（第17条(b) で消去義務が発生しうる）
  • アカウント削除 = より広い 消去要求 — 契約ベースのデータも 不要になれば (a) で消去対象
  • ただし 課金・会計記録 等は第3項(b)(e) の 例外 で残ることがある
• 第2項 公開データ — SNS 的な公開機能がある場合、他社への 連鎖通知 義務
• 第3項 例外 — 「全部消せ」と言われても 全部消せない ケースがある（法務判断）

開発者目線のポイント

• アカウント削除機能 は第17条の 中核実装 — UI から到達可能に（第12条）、バックエンドで 全ストア横断削除 できる設計が理想
• 削除対象の整理: アカウントDB、閲覧履歴、My List、端末トークン、キャッシュ、自社 Analytics ログ、同意ログ（保持方針による）
• 同意撤回（CMP OFF） と アカウント削除 は 別フロー — 撤回は該当 SDK 停止＋関連データ消去、削除はアカウント全体
• 委託先・SDK（Firebase、Singular 等）への 削除依頼 も必要 — DPA・削除 API の有無をデータマップに記載
• バックアップ・レプリカ も消去対象 — 「本番DBだけ消した」では不十分なことが多い
• 匿名化 vs 消去 — 再識別可能なら第17条の「消去」要件を満たさない。本当に匿名化できるなら別論
• 例外データ（課金記録、不正調査ログ）は マスキング・保持 し、Privacy Policy で 保持理由・期間 を明記
• 削除後も CDN キャッシュ・検索インデックス に残る場合は第2項的な 合理的措置 を検討

---

処理制限権

GDPR 第18条（Right to restriction of processing） は、データ主体が 個人データの処理を一時的に「止める」 権利を定める条文。第17条（消去）と第21条（異議）の 中間的な救済 として機能する。

和訳

• 第1項（処理制限を求められる4つの場合） データ主体は、次の いずれか に該当する場合、管理者から 処理の制限 を得る権利を有する。
  • (a) 正確性の争い — データ主体が個人データの 正確性を争って おり、管理者が正確性を 検証するための期間
  • (b) 違法処理・消去拒否 — 処理が 違法 であり、データ主体が 消去に反対 し、代わりに 利用の制限 を要求した
  • (c) 法的請求のための保持 — 管理者が処理目的上 もはや必要としない が、データ主体が 法的請求の提起・行使・防御 のために必要とする
  • (d) 異議申立ての検証待ち — データ主体が第21条第1項に基づき 異議 を申し立て、管理者の 正当な理由がデータ主体の利益を上回るか の 検証が終わるまで
• 第2項（制限中の処理ルール） 第1項に基づき処理が 制限 された個人データは、保存を除き、次の場合を除いて 処理してはならない。
  • データ主体の 同意 がある場合
  • 法的請求 の提起・行使・防御のため
  • 他の自然人又は法人 の権利保護のため
  • 連合又は加盟国の 重要な公共の利益 のため
• 第3項（制限解除の事前通知） 第1項に基づき処理制限を得たデータ主体に対し、管理者は 処理制限が解除される前に その旨を 通知 しなければならない。

要点

• 消去 vs 処理制限
  • 第17条（消去） = データを 削除
  • 第18条（処理制限） = データは 残すが、処理を止める（保存のみ可）
  • 「消したくないが、使われたくもない」→ (b) 違法処理・消去拒否 の典型
• 4つのトリガー（第1項）
  • (a) 訂正争い中 → 検証が終わるまで 処理停止
  • (b) 違法だが証拠として残したい → 消去の代わりに制限
  • (c) サービス上不要だが裁判で必要 → 保持＋処理停止
  • (d) 第21条異議の 判断待ち 期間
• 制限中にできること（第2項）
  • 保存（storage） は OK
  • それ以外の処理（分析、共有、プロファイリング等）は 原則禁止
  • 例外: 同意、法的請求、他者の権利保護、重要な公共の利益
• 制限解除の通知（第3項） — 再び処理を再開する前に ユーザーに告知 が必要

開発者目線のポイント

• 一般マンガアプリでは 第17条（削除） や 第7条（同意撤回） の方が頻度が高い。第18条は CS・法務対応 の知識として押さえる
• (a) 正確性争い — ユーザーが「この閲覧履歴は違う」と申立て → 検証中は 当該データの表示・Analytics 送信を停止 しうる
• (b)(c) — 消去 vs 保持の判断は 法務主導。エンジニアは processing_restricted フラグ 等で「保存のみ」状態を実装できるとよい
• (d) — 第21条異議（マーケティング等）の LIA 検証中 に処理制限がかかりうる
• 制限中は SDK への送信停止、レコメンド除外、バッチ処理スキップ 等の 技術的ゲート が必要
• 制限解除時（第3項） — 再開前に メール / アプリ内通知 でユーザーに告知するフローを CS と設計
• アカウント削除と混同しない — 処理制限は アカウント存続＋処理停止 の状態

---

訂正・消去・制限の第三者通知義務

GDPR 第19条（Notification obligation regarding rectification or erasure of personal data or restriction of processing） は、第16条（訂正）・第17条第1項（消去）・第18条（処理制限）を 実行したとき、その変更を データの受領者（第三者） に伝える 管理者の義務 を定める条文。

和訳

• 第1項（受領者への通知義務） 管理者は、第16条、第17条第1項及び第18条に従って行った 個人データの訂正、消去 又は 処理の制限 について、当該個人データが 開示された各受領者 に 伝達 しなければならない。ただし、これが 不可能 である場合、又は 過度の努力 を要する場合は除く。
• 第2項（受領者一覧の開示） データ主体が要求した場合、管理者は 当該受領者 についてデータ主体に 通知 しなければならない。

要点

• 趣旨: 「自社だけ直しても意味がない」問題への対応
  • 第16〜18条で自社DBを訂正・消去・制限しても、既に渡した第三者 に古いデータが残りうる
  • 第19条は 受領者にも同じ変更を伝える 義務
• 通知が必要な操作（第1項）
  • 訂正（第16条）
  • 消去（第17条第1項）
  • 処理制限（第18条）
• 「受領者」とは
  • 個人データを 開示した 第三者 — 委託先（processor）、広告・Analytics SDK、パートナー等
  • 第13条の「受領者」告知と 対応する相手
• 適用除外（第1項ただし書）
  • 通知が 不可能、又は 過度の努力 を要する場合は義務なし
  • 全受領者への個別通知が非現実的な場合の 逃げ道（代替措置は法務判断）
• 第2項 — ユーザーが「誰に渡したか教えて」と要求 → 受領者一覧 を開示（第15条のアクセス権とも接続）
• 第17条第2項との関係
  • 第17条第2項: 自社が 公開 したデータの 連鎖消去（他管理者への通知）
  • 第19条: 一般的な受領者 への訂正・消去・制限の 通知 — より広い義務

開発者目線のポイント

• 第19条は DSAR ワークフローの「後半」 — 削除・訂正チケット完了時に 委託先通知 ステップが必要
• 受領者リスト をデータマップで管理: Firebase、Singular、課金基盤、CS ツール等 — 「誰に何を渡しているか」を 消去時に辿れる 状態に
• SDK への 削除依頼 API（Google Analytics User Deletion API 等）や DPA 上の連絡手順 を事前に把握
• 自社だけ消して SDK に残る → 第19条未履行 になりうる
• 処理制限（第18条） も通知対象 — 「このユーザーのデータを使わないで」と委託先に伝える必要あり
• ユーザーから受領者一覧を求められたら（第2項）→ Privacy Policy の受領者記載 ＋ 個別 DSAR 回答 で対応
• 実装より 運用・契約 が中心 — エンジニアは 削除パイプラインに「委託先通知」タスク を組み込む設計が現実的

---

データポータビリティ権

GDPR 第20条（Right to data portability） は、データ主体が 自ら提供した個人データ を 構造化・一般的・機械可読 な形式で受け取り、別の管理者へ移転 できる権利を定める条文。第15条（アクセス）より 移転・再利用 に焦点を当てた権利。

和訳

• 第1項（データの受領・移転） データ主体は、自分に関する、自分が管理者に提供した 個人データを、構造化され、一般的に使用され、機械可読 な形式で 受領 する権利を有する。又は、当該個人データを提供した管理者による 妨害なく、別の管理者 へ 移転 する権利を有する。ただし、次の 両方 を満たす場合に限る。
  • (a) 法的根拠 — 処理が第6条第1項 (a) 同意、第9条第2項 (a) 明示的同意、又は第6条第1項 (b) 契約 に基づく
  • (b) 自動処理 — 自動的手段 により処理されている
• 第2項（管理者間の直接移転） 第1項のポータビリティ権を行使するにあたり、技術的に可能 な場合、データ主体は個人データを 管理者から別の管理者へ直接送信 される権利を有する。
• 第3項（消去権との関係・適用除外）
  • (1) 第1項の権利行使は 第17条（消去権） を 害しない
  • (2) 管理者に委ねられた 公務 の遂行又は 公共の利益 のために必要な処理には 適用されない
• 第4項（他者の権利） 第1項の権利は、他者の権利と自由 を不当に害してはならない。

要点

• 第15条（アクセス）との違い
  • 第15条: すべての 処理中データの 写し・情報開示
  • 第20条: ユーザーが提供した データのみ、移転・再利用可能な形式 で — サービス乗り換え が目的
• 適用条件（第1項） ← 重要
  • lawful basis が 同意(a) 又は 契約(b) のみ（(f) 正当な利益 ベースの Analytics 等は 対象外 になりうる）
  • 自動処理 のみ — 手作業のファイルは対象外
  • 「提供した（provided）」 データ — 閲覧履歴・My List 等 ユーザーの操作で生じた データは該当しうる。推論・プロファイリング結果は 限定的
• 形式要件: structured, commonly used, machine-readable
  • JSON、CSV 等が一般的
  • PDF だけでは 不十分 なことが多い
• 直接移転（第2項） — A社→B社へ API 等で直接送る 権利。技術的に可能な場合のみ
• 第17条との関係（第3項） — ポータビリティを行使しても 消去権は残る（エクスポート後も削除請求可）
• 第4項 — 他ユーザーのデータが混ざる場合は マスキング 等が必要

開発者目線のポイント

• データエクスポート機能（JSON/CSV）が第20条の 実装例 — 第15条 DSAR でも共用しうる
• エクスポート対象の候補: プロフィール、My List、閲覧履歴、同意設定 — 契約(b)ベースの アカウント・課金 データも含みうる
• Analytics SDK に送ったイベント は「ユーザー提供」か要判断 — 自社ログに残る分のみエクスポートが現実的
• (f) 正当な利益 のみで処理しているデータは 第20条対象外 — lawful basis 表と連動
• 直接移転 API（第2項）は一般アプリでは 未実装が多い — まず ダウンロード提供 で足りるケースも（法務確認）
• エクスポート後も 第17条で削除可能 — エクスポート＝削除ではない
• Privacy Policy に ポータビリティ権の存在と行使方法 を記載（第13条第2項）
• Account 画面から 1〜2タップ でエクスポート要求できると第12条の「円滑化」にも合致

---

異議申立て権

GDPR 第21条（Right to object） は、データ主体が 特定の処理に異議を唱える 権利を定める条文。ダイレクトマーケティング への異議は 無条件で処理停止、その他は 利益衡量 が必要。

和訳

• 第1項（一般の異議 — 第6条(e)(f)）
  • (1) データ主体は、自己の特定の状況に関連する理由 に基づき、第6条第1項 (e) 公共の利益・公務 又は (f) 正当な利益 に基づく、自分に関する個人データの処理（当該規定に基づく プロファイリング を含む。）に いつでも異議 を申し立てる権利を有する。
  • (2) 管理者は、データ主体の利益・権利・自由を 上回る compelling な正当な理由 を立証する場合、又は 法的請求 の提起・行使・防御のために必要な場合を除き、当該個人データをこれ以上処理してはならない。
• 第2項（ダイレクトマーケティングへの異議） ダイレクトマーケティング目的で個人データが処理されている場合、データ主体は、当該マーケティングに関連する プロファイリング を含め、いつでも異議 を申し立てる権利を有する。
• 第3項（マーケティング異議の効果） ダイレクトマーケティング目的の処理に異議が申し立てられた場合、当該目的のための個人データの処理は 行ってはならない。
• 第4項（告知義務） 遅くともデータ主体との 最初の通信時 までに、第1項・第2項の権利を 明示的に データ主体の 注意に引き寄せ、他の情報から明確に分離 して提示しなければならない。
• 第5項（自動手段による異議 — ISS） 情報社会サービスの利用の文脈において、指令 2002/58/EC にかかわらず、データ主体は 技術的仕様を用いた自動的手段 により異議申立て権を行使してもよい。
• 第6項（研究・統計目的） 第89条第1項に基づき科学的・歴史的研究又は統計目的で個人データが処理されている場合、データ主体は 自己の特定の状況に関連する理由 に基づき異議を申し立てる権利を有する。ただし、公共の利益 の理由で行われる業務の遂行に 必要 な処理である場合は除く。

要点

• 2つの異議ルート
  • 一般異議（第1項） — lawful basis が (e) 公務 又は (f) 正当な利益 の処理。→ 利益衡量（管理者が上回る理由を立証しない限り 停止）
  • マーケティング異議（第2・3項） — ダイレクトマーケティング（関連プロファイリング含む）。→ 無条件で即停止（立証不要）
• 同意(a)・契約(b) ベースへの異議
  • 第21条の 直接の対象外 — ただし 同意撤回（第7条） や 消去（第17条） で対応
• 第1項の「特定の状況に関連する理由」 — 単なる「嫌だ」ではなく 個別事情 の提示が期待される（解釈は法務・判例）
• 第4項 告知 — Privacy Policy や 初回メール で異議権を 目立つ形で分離表示
• 第5項 — CMP・設定画面の オプトアウト が ISS における 自動行使 の実装例
• 第17・18条との接続 — 異議後も処理続行の根拠がなければ 消去（第17条(c)） 又は 処理制限（第18条(d)）

開発者目線のポイント

• マーケティング・広告トラッキング — 第21条第2・3項が 最も実務的。オプトアウト＝ 即 SDK 停止（Singular 等）
• CMP / 設定画面 の OFF スイッチは第21条第5項＋第7条（同意撤回）の 両方 に関係 — マーケ目的は 異議で止める 設計も有効
• (f) 正当な利益 の Analytics（不正防止等）— ユーザー異議 → LIA で続行可否判断 → ダメなら停止 or 匿名化
• 契約(b) のサービス提供処理（閲覧履歴保存等）— 第21条ではなく 消去請求・利用規約 の話。混同しない
• 初回通信時の告知（第4項） — マーケメール初回・CMP 初回表示で 異議権を明示
• バックエンド: 異議フラグ（marketing_opt_out 等）→ イベント送信ゲート、バッチ除外、委託先通知（第19条）
• 第21条第3項は 絶対停止 — 「オプトアウトしたのに広告 SDK が動く」は 明確な違反 リスク

---

自動化された意思決定権（プロファイリング）

GDPR 第22条（Automated individual decision-making, including profiling） は、自動処理のみ（プロファイリング含む）による意思決定で 法的効果 又は 同等の重大な影響 を受けることを拒否する権利を定める条文。

和訳

• 第1項（拒否権の原則） データ主体は、プロファイリングを含む自動処理のみ に基づき、自分に関する 法的効果 を生じさせる、又は 同等の重大な影響 を与える 意思決定の対象とならない 権利を有する。
• 第2項（適用除外 — 3つの例外） 第1項は、意思決定が次の いずれか に該当する場合には 適用されない。
  • (a) 契約の必要性 — データ主体と管理者の 契約の締結又は履行 に 必要 なもの
  • (b) 法令の認可 — 管理者が従う 連合法・加盟国法 により 認可 され、かつデータ主体の権利・自由・正当な利益を保護する 適切な措置 が定められているもの
  • (c) 明示的同意 — データ主体の 明示的同意 に基づくもの
• 第3項（保護措置 — 契約・同意の場合） 第2項 (a) 契約 又は (c) 明示的同意 の場合、管理者はデータ主体の権利・自由・正当な利益を保護する 適切な措置 を講じなければならない。少なくとも次の権利を含む。
  • 管理者による 人的介入 を求める権利
  • 自己の見解を述べる 権利
  • 当該決定に異議を唱える 権利
• 第4項（第9条データの禁止） 第2項の意思決定は、第9条第1項の 特別カテゴリ の個人データに 基づいてはならない。ただし、第9条第2項 (a) 明示的同意 又は (g) 重大な公共の利益 が適用され、かつデータ主体の権利・自由・正当な利益を保護する 適切な措置 がある場合は除く。

要点

• 第22条が問題にするケース
  • 自動処理のみ（人間の関与なし）
  • プロファイリング含む
  • 結果が 法的効果（契約拒否、料金決定等）又は 同等の重大な影響（信用スコア、採用落ち等）
• 3つの例外（第2項） — 例外でも 第3項の保護措置 が必要な場合あり
  • (a) 契約に必要 — 例: 自動与信が サブスク契約に不可欠 な場合（解釈は限定的）
  • (b) 法令認可 — 公的機関・特定業界向け
  • (c) 明示的同意 — 通常の同意より 厳格（第9条と同レベル）
• 第3項 最低限の保護 — 人的レビュー・異議申立て の導線が必要
• 第13・15条との関係 — Policy / DSAR で 自動意思決定の有無・ロジック・影響 を告知（第13条第2項、第15条第1項）
• 一般マンガアプリで該当しうるか
  • レコメンド・ホーム並び替え — 通常は 「同等の重大な影響」 には なりにくい（閲覧体験のパーソナライズ）
  • 広告ターゲティング — 第21条（異議）・第7条（同意）の方が中心。完全自動の 法的効果 がなければ第22条は副次的
  • アカウント BAN・不正検知の自動停止 — 重大な影響 になりうる → 人的レビュー導線 が必要
  • 料金・課金の完全自動決定 — 契約例外(a)の検討だが、争い時は 異議・人的介入 を用意

開発者目線のポイント

• まず 「完全自動でユーザーに重大な影響を与える処理」 があるか棚卸し — なければ第22条は 告知中心
• レコメンド Engine だけなら通常 第22条の核心外 — ただし Policy では プロファイリングの有無 を第13条どおり記載
• 不正検知・自動制裁 があるなら 人的介入・異議窓口（CS）を設計 — 第3項
• DPIA（第35条） — 自動意思決定＋プロファイリングは DPIA 必須 になりうる
• AI Act との関係 — 将来 AI による個別判定 を入れる場合は GDPR 第22条 ＋ AI Act の 両方 を確認

---

権利・義務の制限（立法による例外）

GDPR 第23条（Restrictions） は、連合法又は加盟国法 により 立法措置 をとることで、第12〜22条・第34条（及び対応する第5条）の 権利・義務の範囲を制限できる 条件と、その 立法に含めるべき事項 を定める条文。

和訳

• 第1項（制限の前提） 管理者又は処理者が従う 連合法又は加盟国法 は、立法措置 により、第12〜22条・第34条、及び第5条（第12〜22条に対応する部分）の 義務・権利の範囲を制限 できる。ただし次の すべて を満たすこと。
  • 基本的人権・自由の 本質 を侵害しない
  • 民主主義社会 において 必要かつ比例 な措置である
  • 次の いずれか を保護するためである
• 第1項 保護目的（10項目）
  • (a) 国家安全保障 (b) 国防 (c) 公共の安全
  • (d) 犯罪の予防・捜査・検知・起訴・刑罰の執行（公共の安全への脅威の防止含む）
  • (e) 連合又は加盟国の一般公共の利益上の重要な目的 — 特に経済・金融利益（通貨・予算・税制）、公衆衛生、社会保障
  • (f) 司法の独立・司法手続の保護 (g) 規制職業の倫理違反の予防・捜査等
  • (h) 公権力行使に付随する監視・検査・規制機能（(a)〜(e)(g) の場合）
  • (i) データ主体又は 他者 の権利・自由の保護 (j) 民事上の請求権の執行
• 第2項（立法措置に含める具体事項） 第1項の立法措置は、少なくとも 該当する場合 次を 具体的に定め なければならない。
  • (a) 処理の目的又は処理のカテゴリ
  • (b) 個人データのカテゴリ
  • (c) 導入する制限の範囲
  • (d) 濫用・違法アクセス・移転を防ぐ 保護措置
  • (e) 管理者又は管理者のカテゴリの特定
  • (f) 保存期間と、処理の性質・範囲・目的を考慮した保護措置
  • (g) データ主体の権利・自由への リスク
  • (h) 制限について データ主体に通知する権利 — ただし通知が制限の目的を害する場合は除く

要点

• 第3章（データ主体の権利）の「出口」 — 第12〜22条の権利は 絶対ではない が、恣意的に制限できない
• 制限の形式 — 立法措置（条例・法律）が必要。管理者の判断だけ では不可
• 3要件 — 本質的侵害なし ＋ 必要・比例 ＋ 10の公共目的のいずれか
• 第17条（消去権）との関係 — 第17条第3項でも 公共の利益 等で消去を拒否できるが、第23条は より広い権利制限の枠組み
• 第34条（漏えい通知）も制限対象 — 捜査中など 本人通知を遅延・省略 できる立法の根拠
• (i) 他者の権利保護 — DSAR 応答時に 第三者の個人データをマスキング する根拠の一つ（第15条との整合）
• (j) 民事請求権 — 係争中データの 処理制限・開示拒否 等
• 加盟国ごとに差 — 同一 GDPR でも 国内法による制限の幅 が国によって異なる

開発者目線のポイント

• 通常のマンガアプリ開発では直接触れない — 国安保・捜査等は 法務・コンプライアンス の領域
• DSAR 実装時は (i) を意識 — 開示データに 他ユーザーのメール・コメント が混ざる場合は マスキング（第23条＋第15条第4項）
• 漏えい対応フロー — 第34条の 遅延通知 は国内立法次第。Runbook は法務確認 後に確定
• 「権利行使を拒否する」判断はエンジニア単独不可 — 拒否理由・法的根拠を 法務が文書化 してから実装
• Privacy Policy への記載 — 国内法に基づく 権利制限の可能性 を一般論として触れることがある（第12〜14条の透明性）
• 第3章完結 — 次は 第4章（管理者・処理者の義務） 第24条から

SwiftUIのMenu内でTextの色は変えられない？

SwiftUIの Menu の中で、Button の文字色を変えたかった。

こんな感じで Text に色を指定しても、Menu 内だと反映されない。

private var clearButton: some View {
    Button {
        // Action
    } label: {
        Text("Clear History")
            .textStyle(
                font: .body,
                textColor: Color(.blue)
            )
    }
}

でも、role: .destructive を付けると赤にはなる。

private var clearButton: some View {
    Button(role: .destructive) {
        // Action
    } label: {
        Text("Clear History")
            .textStyle(
                font: .body,
                textColor: Color(.blue)
            )
    }
}

Menu 内ではこっちが指定した Text の色というより、OS標準のメニュースタイルが優先されるっぽい。

まあ、Menu の項目をカラフルにしたい場面はそんなに多くないのかもしれない。とはいえ、ちょっとだけ色を変えたいときにできないのは地味に不便。

参考

sarunw.com

Full Keyboard Access をサポートする

概要

Full Keyboard Access は、タッチ操作が難しいユーザーでも、キーボードだけでアプリを操作できるようにするアクセシビリティ機能です。

主なポイントは、すべてを独自実装するのではなく、Apple が提供しているアクセシビリティ・フォーカス・キーボード操作の仕組みに乗りつつ、足りない部分を補うことです。

---

Full Keyboard Access とは

Full Keyboard Access は、画面上の要素をキーボードで移動・操作できるようにする機能です。

ユーザーはキーボードを使って、以下のような操作ができます。

• 画面上の要素へ移動する
• ボタンやセルなどをアクティベートする
• アクションメニューを開く
• 画面上の要素を検索する
• ドラッグ操作などを行う

---

重要な考え方

Full Keyboard Access 対応で大事なのは、以下の3つです。

1. 操作できるものは、キーボードでも操作できるようにする
2. 操作できないものには、キーボードフォーカスを当てない
3. アイコンだけのボタンなどは、検索・音声・キーボード操作で見つけやすくする

つまり、単に isAccessibilityElement = true を付けるだけでは不十分です。

ユーザーがキーボードで移動したときに、そこが本当に操作できる要素なのか を意識する必要があります。

---

1. よく使う操作には Custom Action / Keyboard Shortcut を用意する

たとえば、カードやセルに対して以下のような操作がある場合、タップだけでなくキーボードからも実行できるようにします。

• 追加
• 削除
• 保存
• ピン留め
• 共有
• 既読 / 未読
• お気に入り追加

このような操作には、主に以下の2つの方法があります。

---

UIAccessibilityCustomAction

UIAccessibilityCustomAction を使うと、VoiceOver / Switch Control / Full Keyboard Access など、複数のアクセシビリティ機能から同じアクションを利用できます。

Full Keyboard Access では、アクションメニューから実行できます。

let addAction = UIAccessibilityCustomAction(
    name: "Add",
    image: UIImage(systemName: "plus.square")
) { _ in
    self.addCard()
    return true
}

cardView.accessibilityCustomActions = [addAction]

使うとよいケース

• セルに対する追加操作がある
• 長押しメニュー相当の操作がある
• スワイプアクション相当の操作がある
• 画面上にボタンとして常時表示されていない操作がある

ポイント

Custom Action を設定すると、タッチ以外の操作手段を使っているユーザーにも、その機能を提供できます。

---

UIKeyCommand

UIKeyCommand を使うと、物理キーボード向けのショートカットを定義できます。

これは Full Keyboard Access を使っているユーザーだけでなく、通常の外部キーボード利用者にも便利です。

let addCommand = UIKeyCommand(
    title: "Add",
    image: UIImage(systemName: "plus.square"),
    action: #selector(addFocusedCard),
    input: "A",
    discoverabilityTitle: "Add Card"
)

使うとよいケース

• よく使う操作がある
• キーボードショートカットとして提供したい操作がある
• Command キー長押しで表示されるショートカット一覧に出したい操作がある

ポイント

頻繁に使う操作は、タップだけではなくキーボードショートカットでも実行できると便利です。

---

2. 操作できない要素にキーボードフォーカスを当てない

VoiceOver 対応のために isAccessibilityElement = true を設定している要素があると、Full Keyboard Access のカーソルもその要素に移動することがあります。

しかし、その要素が実際には操作できない場合、ユーザーが Space や Enter を押しても何も起きません。

これはユーザーにとって混乱の原因になります。

---

accessibilityRespondsToUserInteraction

操作できない要素だけど、VoiceOver などでは読み上げ対象にしたい場合は、accessibilityRespondsToUserInteraction を使います。

itemView.isAccessibilityElement = true
itemView.accessibilityLabel = "Triangle"
itemView.accessibilityRespondsToUserInteraction = false

使うとよいケース

• 読み上げ対象にはしたい
• ただし、タップやキーボード操作の対象ではない
• 装飾的な情報ではないが、操作可能な UI でもない

例

• 説明用の図形
• 状態を示すだけのアイコン
• 読み上げたいが操作はできない画像
• 情報表示用のラベル

ポイント

キーボードフォーカスは、実際に操作できるものにだけ当たるべきです。

---

canBecomeFocused を安易に上書きしない

Full Keyboard Access のためだけに canBecomeFocused を無理に上書きするのは避けた方がよいです。

理由は、canBecomeFocused は Full Keyboard Access だけでなく、通常のフォーカスエンジンにも影響するためです。

その結果、Full Keyboard Access を使っていない通常の Tab ナビゲーションにも影響が出る可能性があります。

ポイント

Full Keyboard Access のために無理やりフォーカス対象を増やすのではなく、まずはアクセシビリティ要素として正しく整理することが大事です。

---

3. 画像だけのボタンには User Input Labels を設定する

Full Keyboard Access には Find 機能があり、画面上の要素を検索できます。

たとえば、歯車アイコンだけの設定ボタンがある場合、accessibilityLabel が "Settings" だけだと、ユーザーが以下のように検索しても見つからない可能性があります。

• prefs
• preferences
• gear

そのため、ユーザーが呼びそうな別名を accessibilityUserInputLabels に設定します。

settingsButton.accessibilityUserInputLabels = [
    "settings",
    "prefs",
    "preferences",
    "gear"
]

使うとよいケース

• アイコンだけのボタン
• 複数の呼び方がありそうな機能
• 見た目と機能名が一致しにくい UI
• Voice Control でも操作しやすくしたい UI

ポイント

accessibilityUserInputLabels は、Full Keyboard Access の Find だけでなく、Voice Control でも役に立ちます。

---

4. accessibilityPath でフォーカス範囲を調整する

ボタンや UI の形が四角ではない場合、accessibilityPath を設定すると、Full Keyboard Access のカーソル表示や VoiceOver のフォーカス範囲を実際の形に近づけられます。

たとえば、丸いボタンの場合は以下のように設定できます。

let rect = circleButton.convert(circleButton.bounds, to: nil)
circleButton.accessibilityPath = UIBezierPath(ovalIn: rect)

使うとよいケース

• 丸いボタン
• 三角形のボタン
• 不規則な形のタップ領域
• 見た目と実際の矩形領域が大きく違う UI

ポイント

フォーカス表示が UI の見た目と大きくズレていると、ユーザーがどこを操作しているのか分かりにくくなります。

---

スクロールビュー内の accessibilityPath / accessibilityFrame

スクロールビュー内の要素は、スクロールによって画面上の位置が変わります。

そのため、accessibilityPath や accessibilityFrame を固定値で設定すると、スクロール後に位置がズレる可能性があります。

スクロールビュー内で使う場合は、必要に応じて override し、常に正しい画面座標を返すようにします。

---

実装時のチェック観点

アプリで Full Keyboard Access 対応を確認する場合は、以下を見るとよいです。

観点	確認すること
キーボード移動	Tab / Shift + Tab で主要な操作要素に移動できるか
操作実行	Space / Enter でボタンやセルを実行できるか
不要なフォーカス	操作できないテキスト・画像・装飾にカーソルが当たらないか
Custom Action	長押し相当、削除、保存、ピン留めなどがアクションメニューから実行できるか
Keyboard Shortcut	よく使う操作に UIKeyCommand があるか
Find	Full Keyboard Access の検索で主要機能を見つけられるか
ラベル	画像ボタンに accessibilityLabel / accessibilityUserInputLabels があるか
フォーカス範囲	フォーカス表示が UI の見た目とズレていないか

---

シミュレーターでのテスト方法

物理キーボードが手元になくても、iOS Simulator / iPadOS Simulator 上で Full Keyboard Access の確認ができます。

基本的には、Simulator 内の Settings アプリから Full Keyboard Access を有効化し、Mac のキーボードを使って操作を確認します。

---

Full Keyboard Access を有効にする

Simulator で以下を開きます。

Settings > Accessibility > Keyboards > Full Keyboard Access

Full Keyboard Access を ON にします。

有効にすると、画面上の要素にキーボードフォーカスの枠が表示されるようになります。

---

Simulator のキーボード入力を有効にする

Mac のキーボード操作が Simulator に渡らない場合は、Simulator のメニューから以下を確認します。

I/O > Keyboard > Connect Hardware Keyboard

Connect Hardware Keyboard が有効になっている状態で確認します。

---

参考

• WWDC 2021: Support Full Keyboard Access in your iOS app
• Human Interface Guidelines: Keyboards

Dynamic Typeに対応する

Dynamic Type とは

Dynamic Type は、ユーザーが端末設定で変更した文字サイズに合わせて、アプリ内のテキストサイズも自動で拡大・縮小される仕組みです。

アクセシビリティの一部として提供されており、視認性を必要とするユーザーほど大きな文字サイズを利用する傾向があります。

Dynamic Type に対応していない場合、以下のような問題が起きやすくなります。

• 文字が小さすぎて読めない
• テキストが途中で切れる
• レイアウトが崩れる
• テキストやアイコンが重なる
• 一部のユーザーにとって操作しづらい、または操作不能になる

---

受け入れ条件・チェック観点

1. すべてのフォントサイズでレイアウトが成立していること

Dynamic Type 対応では、標準サイズだけでなく、アクセシビリティ用の大きな文字サイズでも画面が成立している必要があります。

確認すべきポイントは以下です。

• すべての文字サイズでテキストが読める
• レイアウトが崩れていない
• 文字やグリフが重ならない
• 重要な情報が見切れない
• 操作に必要な要素が画面内で認識できる

実機では以下の設定で確認します。

設定 > アクセシビリティ > 画面表示とテキストサイズ > さらに大きな文字

最大サイズまで上げた状態で、アプリが快適に読めるか確認します。

---

2. 重要なアイコンも文字サイズに応じて大きくすること

情報を伝えるためのアイコンは、文字サイズが大きくなったときにも見やすい必要があります。

例えば、以下のようなアイコンは Dynamic Type に合わせて拡大を検討します。

• 警告アイコン
• 情報アイコン
• ステータスを表すアイコン
• テキストとセットで意味を持つアイコン

SF Symbols を使うと、Dynamic Type に合わせたスケーリングがしやすくなります。

---

3. 大きなフォントでも省略を最小限にすること

フォントサイズが大きくなると、テキストが ... で省略されやすくなります。

Dynamic Type 対応では、省略をできるだけ減らすことが重要です。

特に注意するべきケースは以下です。

• 本文
• 説明文
• エラー文言
• 注意書き
• 操作に必要なラベル

別画面で全文を見せる導線がない場合は、スクロール領域内であっても安易に省略しないようにします。

SwiftUI では、必要に応じて以下のようにします。

Text(longText)
    .lineLimit(nil)
    .fixedSize(horizontal: false, vertical: true)

---

4. 大きいサイズではレイアウトの組み替えも検討すること

Dynamic Type は、単に文字サイズを大きくすればよいわけではありません。

大きな文字サイズでは、横並びの UI が詰まりやすくなります。そのため、アクセシビリティサイズではレイアウト自体を切り替えることも検討します。

例：

• 横並びの要素を縦積みにする
• 複数カラムを1カラムにする
• アイコンとテキストの配置を変更する
• タイムスタンプや補足情報を別行に逃がす
• 固定幅・固定高さを見直す

SwiftUI では、以下のように dynamicTypeSize を見て分岐できます。

@Environment(\.dynamicTypeSize) private var dynamicTypeSize

var isAccessibilitySize: Bool {
    dynamicTypeSize.isAccessibilitySize
}

---

5. 情報階層を維持すること

文字サイズが大きくなっても、画面内の情報階層は維持する必要があります。

例えば、重要なタイトルや主要アクションが極端に下へ流れてしまうと、ユーザーが画面の目的を見失いやすくなります。

意識するポイントは以下です。

• 重要な要素は上部付近に残す
• 主要アクションを見失わないようにする
• 画面の意味が文字サイズによって変わらないようにする
• 視線の流れが崩れすぎないようにする

---

実装のポイント

Text Style を使う

Dynamic Type に対応する基本は、固定サイズではなく Text Style を使うことです。

Text("本文")
    .font(.body)

.body、.headline、.title3 などの Text Style を使うことで、端末設定の文字サイズに追従しやすくなります。

一方で、以下のような固定サイズは注意が必要です。

Text("本文")
    .font(.system(size: 16))

固定サイズを使うと、Dynamic Type の恩恵を受けにくくなったり、アクセシビリティサイズで破綻しやすくなります。

---

ScaledMetric について

@ScaledMetric は、Dynamic Type の文字サイズに合わせて数値を自動スケールできる仕組みです。

テキスト以外のサイズ調整にも使えます。

例えば以下のような値に使えます。

• アイコンサイズ
• padding
• spacing
• cornerRadius
• 線幅
• 画像サイズ

基本例

struct RowView: View {
    @ScaledMetric(relativeTo: .body) private var iconSize: CGFloat = 16
    @ScaledMetric(relativeTo: .body) private var padding: CGFloat = 12

    var body: some View {
        HStack(spacing: 8) {
            Image(systemName: "info.circle")
                .resizable()
                .scaledToFit()
                .frame(width: iconSize, height: iconSize)

            Text("説明文")
                .font(.body)
        }
        .padding(padding)
    }
}

この場合、iconSize と padding が .body のスケールに合わせて大きくなります。

---

relativeTo とは

relativeTo は、どの Text Style のスケールに合わせるかを指定するものです。

例：

@ScaledMetric(relativeTo: .body) private var iconSize: CGFloat = 16

この場合、.body の Dynamic Type スケールに合わせて iconSize が変化します。

使い分けの例：

• 本文横のアイコン → .body
• 見出し横のアイコン → .title3
• 大きなタイトル周辺の余白 → .largeTitle

UI の意味に合わせて、近い Text Style を選ぶのがよいです。

---

カスタムフォントで Dynamic Type に対応する

Text Style が使えない場合や、カスタムフォントを使う場合は、@ScaledMetric をフォントサイズに適用できます。

struct CustomFontText: View {
    @ScaledMetric(relativeTo: .body) private var size: CGFloat = 16

    var body: some View {
        Text("カスタムフォント")
            .font(.custom("YourFontName", size: size))
    }
}

これにより、カスタムフォントでも Dynamic Type にある程度追従できます。

---

実装時に気をつけること

Dynamic Type 対応では、以下の実装に注意します。

• 固定フォントサイズを避ける
• 固定高さの frame を避ける
• 固定幅にテキストを詰め込みすぎない
• lineLimit(1) を安易に使わない
• 重要なテキストを省略しない
• 大きい文字サイズでは縦積みレイアウトを検討する
• アイコンや余白も必要に応じてスケールさせる
• Preview と実機の両方で確認する

---

確認方法

Preview で確認する

SwiftUI Preview では、Dynamic Type のサイズを指定して確認できます。

#Preview {
    ContentView()
        .environment(\.dynamicTypeSize, .accessibility1)
}

さらに大きいサイズでも確認します。

#Preview {
    ContentView()
        .environment(\.dynamicTypeSize, .accessibility5)
}

---

実機で確認する

実機では以下の設定で確認します。

設定 > アクセシビリティ > 画面表示とテキストサイズ > さらに大きな文字

確認時は、標準サイズだけでなく最大アクセシビリティサイズまで上げて確認します。

---

まとめ

Dynamic Type 対応では、単に文字を大きくするだけでは不十分です。

重要なのは、すべての文字サイズで以下を満たすことです。

• テキストが読める
• 重要な情報が省略されない
• レイアウトが崩れない
• 操作に必要な要素が見える
• 必要に応じてレイアウトを組み替える

---

参考

• Apple Human Interface Guidelines – Typography
  https://developer.apple.com/design/human-interface-guidelines/typography

• Apple Developer Documentation – Scaling fonts automatically
  https://developer.apple.com/documentation/uikit/scaling-fonts-automatically

• SF Symbols
  https://developer.apple.com/sf-symbols/

Eventually, time becomes worth more than money. Act accordingly.

読んだ記事

addyosmani.com

Eventually, time becomes worth more than money. Act accordingly.

20. いずれ、時間はお金よりも価値あるものになる。だから、それにふさわしく行動せよ。

キャリアの初期には、
時間をお金と交換する――それで問題ありません。
しかし、ある時点でその計算は逆転します。
時間こそが、取り戻せない資源だと気づくようになるのです。
私は、
次の昇進レベルを追いかけ、
報酬を数パーセント上げることに最適化し続けた結果、
燃え尽きていくシニアエンジニアたちを見てきました。
中には実際に目標を達成した人もいました。
けれど多くは、後になって
「それだけの犠牲を払う価値があったのか？」と自問していました。
答えは「頑張るな」ではありません。
「何と何を交換しているのかを理解し、
そのトレードオフを意識的に選べ」ということです。

最近案件を終えて、少し学ぶ意欲が前よりも薄れてきちゃったなとか思ったり。

燃え尽きって思ったより怖いかもと少し先回り。

1. 期待に応えようとする
   難しい案件、火消し役、やりたがらない仕事
2. 次第に選べなくなる
   断れない、代わりがいない、常に緊急対応
   → 自分の時間の主導権がなくなる
3. 数字や肩書きだけが残る
   次の昇進、ちょっとした昇給、評価コメント
   → でも、中身はこう思ってる。「これ、いつまで続けるんだろう」
4. 心が先に折れる
   学ぶ意欲が消える、好奇心が無くなる、「どうせ変わらない」が口癖になる、成果を出しても嬉しくない
   → まだ働いているけど、燃料がない
   → これは突然でなく、無意識に進む。それが怖い

“頑張るな”ではなく、無自覚に”時間を差し出し続けるな”

確かに、ただやれと言われた実装を短い期間内にバグなく生産し続けることに自分の意思はないから、時間をどう使うかを、ちゃんと選び続ける人でいようとか思ったり。会社に属している以上大変だけど、選べるように動きたいという願望だけ持っておく。