開発プロセスへのプライバシーの統合

こんにちはAppleのプライバシーエンジニア Joey Tysonです 人々のデータに依存する アプリを構築する場合 データには力があるため 開発プロセスにプライバシーを 組み込むことが不可欠です Appleではプライバシーは 単なる流行語ではないと考えています 誰のデータでも慎重かつ敬意を持って 取り扱われるに値します このビデオではアプリ構築における 重要なフェーズをおさらいし すべてのステップでプライバシーを組み込む 実用的な方法を説明します 最初に「プライバシー」が何を 意味するのかを確認します 2010年の会議でSteve Jobsは プライバシーとは平易な言葉でユーザーに 何にサインアップしているのかを 繰り返し 知らせるものだと説明しました つまりユーザーはデータがどう扱われるかを 理解し信頼することができます ユーザーの期待や意図と 皆さんが実際に行うこととの間に 整合性があるからです Steveは楽観的な見方として この理解が築かれれば人々は自分の データについて正しい選択を行えるように なると表明しました

Steveは人よりも多くのデータを共有しても 良いと思う人がいると指摘しました こうした選択にはそれぞれの事情があり 他の人のために決めることはできません 実際人々の意図に対する一貫性を 保つための最良の方法の1つは 尋ねることです プライバシーをどう定義するにせよ 3つの重要な概念が一貫して登場します プライバシーとはユーザーの テクノロジーの操作方法と それによる影響のことです 具体的に言うと ユーザーに関するデータの処理の影響です ユーザーのアプリ使用により得られた情報を どう扱うかということです 最後に取り扱い方法を 決定する際にはその情報の 内容を考慮する必要があります 特にその情報からわかる ユーザーの期待や好みなどです プライバシーとは誰かの データを預けられたときに その内容に敬意を払うことです ユーザーの情報がわかれば 個人に合わせた優れた体験を 作成できるようになります しかしその情報がその人が 思いもよらない方法で 利用されたり別の状況で 共有されたりしたら 生活に重大な影響が 及ぶ可能性があります 人々が自分の目的を叶えるために アプリを使うときは アプリは期待または選択した方法で 機能するべきです これには目標達成のための データの使用方法も含みます Tim CookはAppleの プライバシーに対するアプローチは 収集データをできるだけ少なくし 注意深く敬意を払って 管理することだと言いました 単に何ができるかだけでなくではなく ユーザーの最善の利益のために 何をすべきか自分自身に 問うことだと強調しました この視点はAppleのプライバシーの 柱である データ最小化 オンデバイス処理 透明性と制御 セキュリティ保護に生かされています ではより実用的にするため プライバシーの考え方をアプリ開発の場面に 適用してみます Appleのすべての プラットフォームには多くの テクノロジーがありアプリで 優れたプライバシーを実現できます このビデオでは開発プロセスに プライバシーを組み込む方法ための ツールのほんの一部を紹介します

ソフトウェア開発ライフサイクルは どのモデルでも 簡単に言うと次の5つのフェーズを たどります 計画、設計、開発、テスト 展開です 各ステージにおいて どの場面で優れたプライバシーを 構築できるか説明します またプライバシー目標やプライバシー要件を サポートするために Appleプラットフォームで利用できる ツールを説明します

まず計画のフェーズです ここでアプリのプライバシーの ストーリーを書き込みます アプリで最高のプライバシーを提供し ユーザーの 個人データを扱う際にその意図に最も沿った 対応を実現するためには 開発の最初からプライバシーを 組み込む必要があります セキュリティやローカリゼーションと同様 プライバシーは後付けするほうが はるかに困難です Appleで計画を始める際は まずプライバシーの保証 つまりプライバシーに関して ユーザーは私たちの製品に 何を期待できるか 高いレベルの声明を定義します

こうした製品説明は皆さんの プライバシー目標を実装するための 具体的なエンジニアリング要件を 伝えるだけでなく これらの目標をアプリの ユーザーに伝えるのに 役立ちます

Appleでは前述のプライバシーの柱を 私たちが作成するプライバシー保証の 指針としています このプロセスと説明します Pal Aboutというアプリを 構築するとします 近くのスポットを見つけて その写真を友達と共有するアプリです

データの最小化とは人々の期待を 最大限に満たすために 必要なデータのみを使用することを 意味します これにより効率と信頼が築かれます 特に分析のためにデータを収集する場合 解決しようとしている問題や 答えようとしている質問を慎重に考え データ収集がこのユースケースに 比例するようにします 私のアプリで定義する1つの保証は 「集約された使用状況データのみを 保持する」ということです データの最小化はプライバシーに関する ユーザーの選択について 最小限の仮定から始める体験を 構築するという強いデフォルトの アプローチを反映しています 私のアプリではユーザーに「近くの場所を 検索するときにデフォルトでは 現在地は保存されない」ことを 保証することにします 先ほどプライバシーには誰かの 情報という意味があると述べました オンデバイス処理はそのことを 尊重するための主要な方法です データがデバイスからサーバへ または2つの異なるアプリ間など 1つの状況から別の状況に 移動するたびに その流れが必要かどうか それがユーザーのプライバシーに どう影響するか慎重に考えてください Pal Aboutアプリでは 「ミートアップの推奨場所は オンデバイスデータを使用してローカルで のみ生成されます」と書き込めます 適切なデフォルトと保持する 内容の計画を作成したら データの使用方法がわかるようにし 体験をカスタマイズするための オプションを提供します デフォルト以上にデータを共有する オプションを提供する場合は こうした選択の見返りとして 明確な価値が提供されるようにします 特にAIで機能を構築する場合 ユーザーにAIの使用のタイミングを 知らせると モデルのトレーニング目的の データ使用を許可するかどうかなど 関連するデータフローに関する 意思決定に役立ててもらえます 私のアプリのプライバシー保証では 「アップロードした写真は インテリジェンス機能の改善を目的に オプトインした場合にのみ 生成モデルのトレーニングに使用されます」 とします 最後にセキュリティ保護は データフローの限度を維持して 害を回避するのに役立ちます これは可能な限り 技術的な制御でプライバシーが サポートされるべきだということです つまり他の部分が期待どおりに 機能しなくなったとしても プライバシーをネイティブに 保持するシステムということです サンプルアプリでは「友達へのメッセージが デバイス間で転送中は 読み取りできません」と書いて エンドツーエンドで暗号化を使用する アーキテクチャを使い この目標をサポートできます 次に設計に焦点を当て ユーザーによる商品の実際の 操作方法を構築します 優れた設計があればアプリの ユーザーに面倒だと感じさせずに ユーザーとコミュニケーションを取り アプリの仕組みを理解してもらえます アプリによるデータの使用方法を 信頼できれば ユーザーはアプリを使い データを共有する可能性が高くなります ここではその信頼を築くための いくつかの一般的な 設計原則を紹介します まず積極的に期待を設定します アプリが収集するデータの種類や 使用方法でユーザーが不意を突かれたと 感じることがあってはなりません たとえばAppleアプリでは 最初の起動時に プライバシー面の簡単な概要が 詳細情報へのリンクとともに 表示されます アプリのオンボーディングフローを 使用してデータの 使用方法をユーザーに 理解してもらうこともできます

最初にユーザーの理解を得ることに加えて 状態の変化を明確にします つまりプライバシーに影響を与えたり 行動を変えたりする可能性がある データフローの変更を その場で理解できるようにします 例としてiOSではSiriが 呼び出されたことを示すアニメーションを マイクが有効になるといつも 画面上部に現れる システムインジケーターと共に表示します

最後にデータに関する選択は意味があり 状況に応じたものであるべきです 各オプションはアプリの動作に 具体的な違いをもたらすもの または影響の明確な説明を 含むものである必要があります これらの選択肢は最も関連性の 高いタイミングで表示されるようにし どのレベルのきめ細かさにするか調べ 利用者に適切な バランスを提供するようにします 例えばmacOSのPal Aboutに ストリーミングメディアデバイスと 接続する機能がある場合 誰かがその機能に アクセスしようとするまで ローカルネットワーク接続を 試行しません これによりこの接続が必要となった理由と システムが接続を 有効にするプロンプトを 表示する理由が明確になります

プライバシーを考慮した 設計に関する詳細は Apple Developer向けドキュメントの 「ヒューマンインターフェイスガイドライン」をご覧ください プライバシーのための計画と設計が 完了したらコードを記述します プライバシー目標は多くのツールや テクノロジーを使って達成できます このセクションではアプリを構築する際の このツールの使用方法を いくつか紹介します

まずアプリのUIでプライバシーの選択を 効率化する方法です カレンダーや現在地などの デバイスリソースにアクセスすると 異なる状況の間で機密データを 共有することになります そのためAppleのプラットフォームは ユーザーの意図に 沿った時にのみこのデータを 共有するように設計されています 幅広いアクセスはプライバシーに 最も大きな影響を与えるため 通常それを要求すると明示的な 権限プロンプトがトリガーされます このフォトライブラリ プロンプトなどです 数枚の写真だけを共有する場合に ライブラリ全体へのアクセスを許可すると ユーザーの 意図よりもはるかに多くの 情報が開示される可能性があります そのため「アクセスを制限する」ことで 一定の写真だけを 選択させるようにします しかし必要なデータのみを リクエストする ツールを使うことで より快適な体験を作成できます ユーザーはこのフローで 何を共有するか選択するため ユーザーの操作により その意図は暗黙で示され さらなるプロンプトは表示されません 私のアプリでユーザーが写真を アップロードするのに ユーザーのライブラリ全体への アクセスは必要ありません 代わりにPhotosPickerを使い フォトライブラリへの プロンプト全体を回避します システムはピッカーをプロセス外に レンダリングするため アプリはユーザーが実際に選択した 写真のみを受け取り 許可のプロンプトは表示されません ピッカーをアプリのUI内に埋め込み 外観をカスタマイズができるほか ユーザーは非表示の写真から 選択することもできます ピッカーのバージョンはmacOSや visionOSなど他のプラットフォームでも 利用できます 詳細はWWDC23の 「Embed the Photos Picker in your app」 のビデオをご覧ください Appleではデータアクセスを効率化する その他の安全なUI要素も提供しています サンプルアプリに戻り 近くの場所を簡単に検索できる ようにしたいとします ボタンを追加すると ワンタップで現在地を共有できます システムはユーザーのインタラクションで ボタンがトリガーされたことを検証し 位置情報の共有が ユーザーの意図に沿ったもので あることを再度保証できます ボタンの外観と操作性は カスタマイズできるので アプリのUIに合うようにできます

ユーザーがアプリのボタンを 初めてタップすると 意思確認のプロンプトが表示され ボタンの機能が説明されます 他のAPIで位置情報が 共有された時と同じように 位置インジケーターも 画面上部に表示されます ただし一度を選択するとその後の タップ時にはプロンプトがトリガーされず 現在地がすぐに共有されます 詳しくはWWDC21のビデオ 「Meet the Location Button」をご覧ください

プライバシーUIの 認知的負荷を減らすための ツールを2例を紹介しました 他には連絡先のプロセス外のピッカー ボタン ハードウェアアクセサリの効率的な セットアップフローがあります より広範なAPIを使用する前に 必要なデバイスデータのみに アクセスするためのオプションを 確認しましょう 場合により許可プロンプトが 必要になることもあります それらを有意で状況に 適したものにするために それらをトリガーするアクションは こうした質問が表示されると ユーザーが想定しているときに実行します ユーザーがアプリを初めて開いたときには このような選択肢を表示しないようにし そのプロンプトが表示される理由を 明確に説明する 目的文字列を記述します 次にクライアントとサーバの インタラクションの一部として バックグラウンドで機能する プライバシーのテクノロジーを説明します 特に機密性の高いデータを サーバに漏洩させずにサーバ側のリソースを サーバ側のリソースを使用する いくつかの方法を紹介し 次に一般的なデータ収集 シナリオに対処するため 識別可能データの必要性を 減らす方法を説明します Appleプラットフォームでは 高度なデータ保護は iCloudに保存された大部分のデータを ユーザーがエンドツーエンドでの 暗号化を有効にできる機能です CloudKitを採用することで ユーザーが高度なデータ保護を 有効にするたびにアプリがCloudKitに 保存するデータを エンドツーエンドで暗号化できます これはインフラストラクチャの変更や 暗号化キーの追加管理なしに実現できます まずCloudKitスキーマの全フィールドに 対して暗号化された データ型を使用するようにします これにはデフォルトでCKAssetフィールドが 含まれ CloudKitのほとんどのデータ型では EncryptedStringなどの 暗号化済みのバリアントがあります

その後encryptedValues APIを 使用して CloudKitレコードとの間で データの取得や保存を行います すべての暗号化操作と復号操作は このAPIによって抽象化されます CloudKitは暗号化フィールドで インデックスをサポートしないので CKQueryやCKQueryOperationを 使用してレコードを取得する時 プレディケートやソート記述子に 含めないようご注意ください 詳しくはWWDC21の「What’s new in CloudKit?」を ご覧ください Appleで使用している別の暗号化技術は 準同型暗号といいます 生データで計算するのではなく 暗号化されたペイロードを計算でき 結果を復号するときと同じ出力を得られます 計算中のどの時点でも データは復号されません 準同型暗号は加算などの 簡単な計算演算を 組み合わせて個人情報取得など 高度なテクノロジーを 可能にします PIRを使用すると 復号フォーマットの クエリや結果がサーバで 利用可能にならなくても サーバからデータを検索できます PIRを使うとデバイスはクエリの 暗号化されたペイロードを サーバに送信し サーバは準同型暗号を使用して 暗号化された結果を計算します 計算自体は暗号化されているので クエリに一致する結果は リクエストのライフタイムの どの時点でもサーバには 白文で利用可能ではありません 最後にサーバは暗号化された結果を デバイスに送り返し デバイスがローカルで復号して処理します サンプルのPal Aboutでは PIRを使用するとサーバがユーザーの 検索履歴をトラッキングできなくても ミートアップの場所に関する 現在の情報をサーバから 取得できます 一部のユーザーにとってはアプリで 検索した場所が知られることは 安全性に影響があるため アプリにPIRを使用するかどうかという 技術的な選択は プライバシーに関する重要な 決定事項になります PIRはAppleプラットフォームと デベロッパの皆さんが開発する 人気アプリの両方の機能で使われています PIRの実装の詳細についてはGitHubの Swift準同型暗号ライブラリと アプリケーションをご覧ください 当初識別可能データの収集が 必要だと思われた2つの 一般的なシナリオで不正行為や 広告アトリビューションが減っています 皆さんがこの分野で 目標を達成するとともに ユーザーIDやIPアドレスに 対するデータ収集の 必要性を減らすためにAppleが構築した 機能の一部を紹介します 不正防止については プライベートアクセストークンにより ユーザーを特定せずに リクエストが正当な デバイスから行われたことを 確認できます デバイスは検証後に匿名トークンを 受け取るので 追加のID情報を必要とせずに トークンを検証することができます 詳細は WWDC22の「Replace CAPTCHA with Private Access Tokens」をご覧ください またプロモーションを複数回 引き換えようとするなどの アプリに固有の不正行為を 防ぐ必要もあります DeviceCheck APIを使うとデバイスの 識別子をトラッキングする必要なしに 任意のデバイスの最大2ビットの情報を 関連付けることができます これらの状態はAppleによって管理され 再インストールまたは デバイス転送後も保持されます WWDC21の 「Mitigate fraud with App Attest and DeviceCheck」で 設定と取得の詳細を確認してください 広告パフォーマンスには AdAttributionKitがプライバシーを 保持しながら広告キャンペーンの 成果を測定する強力なツールです 署名付きポストバックシグナルでユーザーの デバイスからアプリのインストール数と 再エンゲージメント数を特定の キャンペーンにアトリビュートします AdAttributionKitを使うと プロンプトをさらに削減できます AdAttributionKit APIの呼び出しには App Tracking Transparencyの 表示は必要ありません パブリッシャーアプリの場合の 主な実装手順は 登録された広告ネットワークから Info.plistに識別子を追加し 次にそれらのネットワークが署名した 広告を表示します AdAttributionKitと ポストバックシグナルの仕組みの詳細は WWDC24の「Meet AdAttributionKit」を ご覧ください 広告対象のアプリには アプリ内でコンバージョンイベントと 関連する 再エンゲージメントを 登録する必要があります さらにポストバックシグナルのコピーを取得 するためのエンドポイントを指定できます これらのアップデート関連のすべてのAPIは Apple Developer向けドキュメントの AdAttributionKitセクションにあり 「What’s new in AdAttributionKit」のビデオでは iOS 26での新機能が説明されています 最後にオンデバイスのAIモデルや バンドルされたフレームワーク アプリプロセスなど ローカルのリソースを管理し 同時にプライバシーを保持することに 関するヒントをいくつか紹介します

まず機械学習モデルの実行 トレーニングや微調整を デバイス上で完全に行う Core MLの機能をお伝えします これはさまざまなオープンソースモデルや Create MLを使用してカスタム構成した モデルで機能します 最適化と圧縮技術により サーバを呼び出さずに 一般的な大規模言語モデルを 実行することもできます WWDC24の「Deploy machine learning and AI models on-device with Core ML」 または「Bring your machine learning and AI models to Apple silicon」で Core MLについて確認してください アプリグループコンテナは 構築した様々なアプリ間で データを共有できるだけでなく そのデータの保護にも役立ちます macOSでは他のアプリはユーザーの許可なく アプリグループコンテナ内のデータに アクセスできません これらのコンテナを使用するには 証明書、ID、プロファイルの下の Developerポータルで アプリグループ識別子を登録します 次に対応するエンタイトルメントを アプリで採用し ユーザーデータを保存する 必要があるときは常に コンテナディレクトリを リクエストする必要があります

詳しくはWWDC24の 「What’s new in privacy」か Apple Developer向けドキュメントの 「Configuring app groups」をご覧ください macOSではユーザーがアプリを 終了する時にすべてのアプリプロセスを 終了する必要があります fork、execまたはPOSIX spawnを 使用してプロセスを読み込むと 終了時にクリーンアップされます macOS Tahoeではこうしたプロセスが 実行され続けているかを発見的に検出でき これがユーザーの意図に沿ったものか 確認するプロンプトが表示されます ユーザーにはその後自分で プロセスを終了するオプションがあります 最後にサードパーティSDKを含む アプリの中のすべてのコードに 責任を負うことを忘れないでください App Storeに提出する前にSDKは 収集するデータと使用するAPIの必要性を 説明するプライバシーマニフェスト ファイルを要求することがあります Apple Developer向けドキュメントの 「Privacy manifest files」で この要件が適用される場合の 詳細について確認してください 次のビデオでも詳細を確認できます WWDC23の 「Get started with privacy manifests」です これらのテクノロジーは プライバシーが開発の 一部であることのほんの一例です 今から次のテストのフェーズを説明します ここでもプライバシーは このステップの一部です エラーを回避するためまたは パフォーマンスの低下を検出するために テストを構築したいと思うのと同様 アプリのプライバシー保証の遵守を 確認するためのテスト構築も 重要なベストプラクティスです Appleではピラミッドモデルの テストにより 小規模なテストが形成する基礎の上に アプリユーザーの実務的目標を より詳しく反映する広範なテストが あると考えます 単体テストは一般的に 単一のコードの個々の機能の 検証に役立ちます プライバシーについてはプライバシー制御を サポートするアプリロジックを検証できます 統合テストの対象は個別のサブシステム またはクラスのクラスタで 様々なコンポーネントが正しく連携して 動作することを確認します これによりプライバシーの観点から システム間のデータフローが 想定どおりに機能するか確認します 最後にUIテストではアプリの ユーザー向けの動作を観察し 想定通りに機能することを確認します これにはオンボーディングの 一般的なシナリオや プライバシー設定の変更が含まれます Pal Aboutではユーザーが インテリジェンス機能の向上のために オプトインしたときにのみ 写真のトレーニングを行うという プライバシー保証にしました そこでオプトイン設定の変更のたびに 関連のデータフローが更新されることを 確認するUIテストを作成します Appleはより効率的に プライバシー機能がテストできるような 多くのツールを提供しています たとえばiOS 15.2では の を有効化し データアクセスやセンサーアクセス ネットワークアクティビティを アプリから迅速に検査し それらがアプリのユーザーの期待と 一貫していることを確認できます 最後に展開を説明します 実際にアプリを世に送り出すプロセスです ここまで構築した機能で 優れたプライバシーを 提供するために多くの作業を行ってきたので プライバシーに関するストーリーを 発表します アプリを宣伝するコンテンツを作成する際 プライバシーの保証を活用して 興味を引き付けたり アプリを際立たせたりできます

App Storeへの展開においても アプリで何ができるかを ユーザーに理解してもらうための いくつかの必須手順があります 特にPrivacy Nutrition Labelsは App Storeでユーザーがアプリの プライバシー方針を確認するための 重要な方法です ラベルはアプリがデバイス外に 送信するデータの種類と その使用方法について 簡潔な情報を提供します Nutrition Labelsの設定場所は App Store Connectの アプリのプライバシーのセクションです データの種類や「トラッキング」などの 用語はApple Developer向けドキュメントの 「App Storeでのアプリのプライバシー に関する詳細情報の表示」で 必ず確認してください

Xcodeでビルドをアーカイブする場合は アーカイブのコンテキストメニューから を選択し プライバシーマニフェストファイルで 宣言されている データ使用の集計レポートを取得します Nutrition Labelsではユーザーがアプリ体験の 中でそのデータの収集を許可するかを 選択したとしてもデータの潜在的な 使用をすべて文書化する必要がある ことに注意してください ただしフィードバックやレポートフローなど 例外は Apple Developer向け ドキュメントを確認してください Nutrition Labelsは アプリの更新がなくてもいつでも 更新できます WWDC22の 「Create your Privacy Nutrition Labels」で 詳細を確認してください

Nutrition Labelsに加え 展開時の他のプライバシー要件も 確実に満たします アプリには明確なプライバシーポリシーが 必要です アプリのプライバシーマニフェストと すべてのサードパーティSDKは Xcodeに含める必要があります デバイスリソースにアクセスするには すべてのアクセス許可 プロンプトで 目的文字列が必要です App Storeリスティングに 「プライバシー選択」のリンクを含めて ユーザーにデータへのアクセス その削除や更新のためのポータルなど アプリでのデータの管理を詳しく 理解してもらうこともできます 計画、設計、開発、テスト、展開 プロセスのすべてのステップで プライバシーを組み込むことで アプリのユーザーに最高の体験を 提供できます これらのアイデアを皆さんの プロセスに適用しましょう まずアプリでの明確な プライバシーの保証を定義します 設計の基本原則を使い データの使用と選択について ユーザーに理解してもらいます プライバシーに関する目標を 強力な技術的基盤で実装します テストすることでプライバシーの保証を 確実に提供します 最後にプライバシーに関する ストーリーを世界に発表するときに 適切なNutrition Labelsを 準備します 今回は何度かデータの 最小化について言及しましたが 優れたプライバシーを構築した 皆さんには最大の感謝を申し上げます ありがとうございました