ストリーミングはほとんどのブラウザと
Developerアプリで視聴できます。
-
目的文字列を明確に記述する方法
Appからカメラや位置情報、ヘルスケアデータなどの保護されているリソースにアクセスする必要がある場合、その理由をユーザーに容易に理解してもらえるように、明確かつ簡潔な目的文字列の書き方を紹介します。簡潔な目的文字列の作成に役立つベストプラクティスと、許可のリクエストの文言を改善する方法を具体的に説明します。
リソース
- Data Collection and Storage - App Store Review Guidelines
- Explore the Human Interface Guidelines for privacy
- Requesting access to protected resources
関連ビデオ
Tech Talks
-
ダウンロード
App Storeのデベロッパの皆さん こんにちは App Store ReviewチームのGregです 今日は私たちのチームから 明確かつ簡潔な目的文字列を 書く上で役立つヒントを紹介します
Appleはプライバシーを 基本的人権であると考えています そのためApple製品は プライバシーを保護するよう設計され ユーザーが自分の情報を 管理できるようになっています 製品設計にプライバシー保護を 取り入れるだけでなく App Store Reviewガイドラインでも プライバシーを重視しています 特にガイドライン5.1.1には Appleエコシステムにおける ユーザーのプライバシー保護に 重要な要件として 収集するデータを 必要最小限に留めることなどが 明記されています 今日は そうした要件の1つを 取り上げます デベロッパの誰もが 苦労していることですが 保護されているリソースへの アクセス許可を求める際には 透明性の高い明確な説明が必要です ここでは ガイドライン5.1.1で 却下となることが多い 目的文字列の不備を避けるための ヒントと例を紹介します まず 許可のリクエストの 背景情報とそれが ユーザーのプライバシー保護に 果たす役割を 確認するところから始めましょう その上で目的文字列について説明します 目的文字列とは Appによる アクセスが必要な理由を示す 短い説明文のことです また App Store Reviewが 審査で確認する 内容についてもお話します 最後に 審査を通過できない 目的文字列の例を紹介し どうすれば明確で 具体的な文字列になるよう 書き直すことができるのか説明します まずは許可のリクエストについて お話しましょう 私たちのデバイスは 生活の重要な一部分です デバイスから何を共有するかは ユーザー自身が決めるべきです そのため AppleのOSでは 保護されているデータやリソースへの アクセスがデフォルトで 制限されています
この情報にAppからアクセスするには まずユーザーの 許可を得る必要があります こうすることで どのAppが何にアクセスできるかを ユーザーが決めることができます しかし ユーザーが 情報に基づく判断をするには なぜAppによるアクセスが必要なのか アクセスを許可すると 何が行われるのかを 明確に知る必要があります そのために 目的文字列があります これは「用途に関する説明」 ともいいます 目的文字列はデベロッパが 提供する短いメッセージであり 許可のリクエストの際に 必ず表示されます Appによるアクセスが 必要である理由と ユーザーのデータで何を 行うかを説明します このメッセージはAppの 情報プロパティリストである Info.plistで定義します このリストで文字列値に リソース固有のキーを設定します これは AppleのOSにおいて デベロッパとAppのユーザーの間の 重要なやり取りです Appで何をしようとしているのかを 明確かつ具体的に示すことで 信頼関係を築く チャンスとなります なぜこれが重要なのでしょうか Appの許可のリクエストと 皆さんもおそらく 経験したことがある 現実のシナリオとの 比較をしてみましょう 地元のカフェでコーヒーを 買う場合を考えてみます コーヒーを手にして お金を払う段階で レジ係に電話番号を 聞かれたとします さて今までは聞かれたことがなかったのに なぜ必要なのでしょうか ここからは2つの流れが考えられます たとえば レジ係がこう言います 「お客様の電話番号を活用して より良いカフェ体験を提供いたします」 すばらしい話のようですが 具体性に欠け 意味が明確ではありません これに対して 次のように 言われたらどうでしょう 「電話番号を使用して お客様の購入履歴を確認し コーヒーのご購入5杯ごとに 1杯無料になるサービスを 提供いたします」 どちらの場合も どうするかはあなた次第です ただし 情報に基づいた 判断をするのに 必要な情報が伝えられたのは 2番目の場合だけです App Store Reviewが 目的文字列の審査で 求めるのは このようなポジティブな ユーザー体験です ユーザーが情報に基づく 判断をするために必要な情報が 目的文字列に含まれていることを 確認しています 私たちがAppを審査する際 そのAppを初めて使う ユーザーの視線で行います つまり 通常のユーザーと同じように 保護されているリソースに アクセスする機能を使用するときに 許可を求めるメッセージを確認します これにより実際の ユーザー体験を理解でき ユーザーが情報に基づいて判断する上で 何を知る必要があるかを 予測できます そのため 審査では 目的文字列について重要な 2つのポイントを確認します そのAppでのデータの用途が 具体的に説明されているか そして データの使用方法の例が 示されているかです
いくつかの例を見てみましょう この2つの基準を満たす 目的文字列とは どのようなものでしょうか 基準を満たしていないと ユーザーにとって どうなるのでしょうか 1つ目はナビゲーションAppです おすすめの観光ルートを 提案してくれます ユーザーがナビ機能を 使用しようとすると このように表示されます 「位置情報を使用するため」 十分な説明とは言えません Appのデベロッパは リソースを何に使用するのか 正確に分かっています しかし ユーザーは同じように Appの仕組みを理解している わけではありません ユーザーはデベロッパから 目的文字列で提供される 情報をもとに判断します この例の場合 ユーザーは必要な情報を 得られていません このデベロッパが信頼を得るには データをどう使用するのか 具体的に説明して 例を示す必要があります 一方こちらは良い例です 「目的地までのおすすめルートを判定し 右折や左折など詳細の 経路案内を提供するために 位置情報が使用されます」 目的文字列が具体的になり ユーザーの位置情報で 何ができるようになるかの例が 明確に示されています 地域ごとのローカリゼーションに 対応するAppでは ローカライズした目的文字列も 用意する必要があることに 注意してください 地域ごとの様々な設定で Appをテストして 適切なローカライズ版コンテンツが 表示されることを確認してください 別の例を見てみましょう こちらは ソーシャルネットワークAppです デベロッパはAppで収集したデータを サードパーティと共有して ターゲティング広告を配信します しかし トラッキングに使用する データを収集する前に Appによるトラッキングの透明性機能で 許可を求める必要があります ユーザーが初めてAppを開くと Appによるトラッキングの透明性の 許可がリクエストされます 現在のメッセージはこうです 「お客様のデータはより良い体験を お届けするために使用されます」 これは本当かもしれませんが これではユーザーが知るべき 情報が伝わりません 具体的にどのように データが使用されるのでしょうか 許可した場合に期待される 「より良い体験」の具体的な例が 示されていません 改善案を見てみましょう 「お客様のデータは お客様に最適な商品の 広告をお届けするための パーソナライズに使用されます」 今度は この情報で デベロッパが何を行うのか アクセスを許可するとユーザーに どのようなメリットがあるかが 明確に示されています トラッキングを許可しない場合は どうなるのかについて さらに情報を 提供することもできます 「お客様のデータは パーソナライズされた広告をお届け するために使用されます トラッキングを許可されない場合でも 広告は表示されますが お客様にとって 関連性が低い広告が 表示される可能性があります」 どちらのメッセージも このAppには適しています 目標とするのは 許可を求める時点で 透明性の高い明確な 説明を示すことです もう1つ注意が必要なことは App Storeの多くのAppに サードパーティのSDKやライブラリが 組み込まれていることです これらのSDKやライブラリでは アカウントの認証など 様々な機能やサービスが提供されますが このようなSDKで参照される APIによって 位置情報などの 保護されているリソースへの アクセスが行われることに デベロッパが気付いていない場合もあります Appからそれらのリソースに アクセスする理由がある場合は Info.plistでAppの 具体的な用途に応じた 目的文字列を定義します アクセスする理由がない場合は Appのバイナリから それらのAPIへの参照を削除します サードパーティ製のSDKやライブラリ その他のコードも含め Appのすべては開発した デベロッパの責任です Appの開発では 保護されているリソースに Appからアクセスする 可能性があれば よく確認し Appの審査を申請する前に それらのリクエストが意図的で あることを確認してください
お気付きかと思いますが ここまでの例は 目的文字列の情報が 少なすぎるケースでした 逆の場合はどうでしょうか 情報が多すぎることは あるでしょうか どのようなものか見てみましょう こちらのAppは 園芸好きのためのAppで 友人の庭の写真を 見ることができます しかし このAppで 初めて写真を撮る際には 許可のリクエストに デベロッパが指定した 長い説明が表示されます 一息で読めるでしょうか 「園芸の楽しさに 気付いた初心者から 庭いじりのベテランまで ガーデニングへの思いを 共有できるAppです カメラへのアクセスを許可すると お気に入りの多肉植物と一緒に ポーズを取ったプロフィール写真や 午後の日差しに輝く レイズドベッドの写真など 様々な写真を撮影できます」 少し長すぎますね 通常はユーザーに 必要な情報を伝えるには 1文か2文で十分です このガーデニングAppなら こちらの方がよいでしょう 「このAppでは カメラを使用することで 写真を撮影してプロフィールの 更新や共有ができます」 目的文字列が具体的になり このAppでのカメラの 様々な用途の例が 示されています 長すぎず 短すぎず 目的文字列は 適切な長さにしましょう 言葉を重ねた長い目的文字列は 内容が正確になり 審査は通るかもしれませんが ユーザーにとって 理想的とは言えません 説明は的を絞って簡潔にし Appで見たときに 読みやすく わかりやすくしましょう それでは まとめです 架空のAppを例にとって 許可のリクエストの 流れを見てみましょう Appが機密性の高いデータに アクセスする必要がある理由について 正確かつ簡潔に ユーザーに説明します ユーザーが情報に基づいて 判断できるようにして アクセスを許可して もらいやすくすることで デベロッパの意図したとおりに Appを機能させることができます デベロッパはApp独自の体験を 伝えることができ ユーザーは自分の個人情報を 自分で管理できます ユーザーはデベロッパの 記述をもとに アクセスの可否を判断します このことを理解しておくと 適切な背景情報を付加して 関連性が高く わかりやすく 有益な目的文字列を 書くことができます
今後のApp Storeの申請に 向けて これらの例を 覚えておいてください ユーザーに適切な情報を 提供することで Appの機能を十分に活用して もらえるようになれば幸いです 以上 ご視聴ありがとうございました 許可のリクエストや プライバシーに配慮した 開発については Apple Developer Webサイトと Human Interface Guidelinesに 役立つガイドや情報が 掲載されています App Storeへの皆さんからの App申請をお待ちしています
-
-
特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。
クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。