YORIRUNを配信する手続きに入り、プライバシー申告と実装を1項目ずつ突き合わせました。そこで、自分では書いていない経路から、正確な位置情報が分析目的で出ていたことが分かりました。地図SDKのテレメトリが既定で有効だったためです。何を見落とし、どう切り、申告をどう直したかを書きます。 気づいたのは部品側の申告を読んだときでした。自分のコードには、送る処理を一行も書いていません。切り方と、申告を実態のほうへ合わせた判断を書きます。
申告を書く段になって、方針と実装が噛み合っていないと気づいた
YORIRUNは、走りたい距離や時間から周回コースを探すアプリです。コースを作るときには出発地点と条件をサーバーへ送ります。そこは設計として決めたことなので、送る先も、何に使うかも説明できます。
一方で私は「分析のログに位置情報は入れていない」とも考えていました。アプリの中に分析SDKを入れていないからです。ところが配信の手続きでプライバシー申告のファイルを見直したところ、この前提のほうが成り立っていませんでした。
地図の描画に使っている Mapbox Maps SDK は、テレメトリが既定で有効でした。SDKが起動時に指標送信の既定値を有効として登録し、SDK自身が同梱しているプライバシー申告にも、正確な位置情報を分析の目的で収集すると書かれていました。2026年9月17日時点で私が確認した版での話です。
つまり、コース生成で私が送っている出発地点とはまったく別の経路で、こちらのログやデータベースとは無関係に位置情報が出ていました。アプリ側にそれを切る記述は1行もありませんでした。
「入れていない」と「出ていない」は別のことだった
私が確認していたのは「自分が書いた行」でした。分析SDKを追加していない、ログに座標を積んでいない、データベースに座標の列を作っていない。どれも事実です。
しかし利用者から見れば、端末から外へ何が出ていくかがすべてです。自分が書いていない依存先の既定値も、アプリの挙動に含まれます。依存しているものの既定値は、自分で決めたことと同じ重さで説明する責任がある、というのが今回いちばん効いた気づきでした。
同じ問題は、位置情報に限りません。課金、クラッシュ収集、画像読み込みなど、入れた覚えのある部品のほうが多いはずです。私の場合は地図でしたが、探す場所は「自分が書いた行」の外側でした。
それ以来、依存先を足したときに見る場所を決めました。名前で当たりをつけるのではなく、部品が自分で何を申告しているかを読むところから始めます。
- 部品が同梱しているプライバシー申告を開き、収集すると書かれた種類と目的を読む
- 既定で有効になっている送信があるか、部品のコードとドキュメントの両方で確かめる
- 切る手段があるか、切ったあと利用者が自分で戻せるかを調べる
- 版を上げたときは同じ確認をやり直す
読む側の立場でも同じことが言えます。何が外へ出ているかは、アプリの説明文ではなくプライバシーポリシーとストアの申告に書かれています。どこを見ればよいかはアプリのプライバシーポリシーはどこを見る？探す五つの項目に整理しました。
切り方を間違えると、利用者の選択まで奪ってしまう
対処は、起動時に既定を無効へ倒すことにしました。地図が1つも作られる前、データの入れ物を用意するより先に置いています。順番を後ろにすると、最初の地図が作られる瞬間に間に合いません。
ここで気をつけたのは、利用者の選択を奪わないことです。地図のⓘメニューには Mapbox 自身の切り替えがあり、利用者が自分でONに戻すこともできます。もし起動のたびにこちらから切り戻していたら、アプリが利用者の決定を毎回打ち消すことになります。
そのため、既定値を登録する書き方ではなく、値を直接書き込む書き方を選びました。既定値どうしで上書きし合う形だと、SDKとこちらのどちらが先に走るかで結果が変わります。起動のたびに違う挙動になるものを、プライバシーの約束の土台にはできません。
- 地図が作られる前に切る
- 利用者が自分でONに戻したら、それは尊重する
- 既定値の登録合戦にせず、実際の値として書き込む
- 新規インストールと、ONに戻したあとの両方を実機で確かめる
テストのほうが、私の思い違いを先に捕まえた
最初に書いたテストは通りませんでした。「利用者が自分で決めたかどうか」を調べるつもりで、保存された値をそのまま読む書き方をしていたためです。
この読み方は、SDKが登録した既定値まで一緒に拾います。結果として、SDKが登録した有効という値を「利用者が自分でONにした」と読んでしまい、切るべき場面で切らなくなります。利用者が実際に書き込んだ値だけを見る形へ直しました。
このときは実機でも確かめました。新規インストールで無効が書かれること、利用者がONに戻したあとは起動しても切り戻さないこと。設定ファイルの中身まで開いて見ています。テストが思い違いを捕まえた例としては、テストは全部通った。それでもアプリの公開後に6つ問題が出たの逆のパターンでした。
申告は、推測ではなく実態のほうへ合わせた
テレメトリを切ったうえで、プライバシー申告も書き直しました。それまで収集するデータの種類は空でしたが、実際には正確な位置情報のほか、利用者の識別子、購入、メールアドレスが外へ出ています。認証と課金の仕組みを使っている以上、これらは出ていきます。
一方で、走った軌跡そのものは端末の外へ出ません。ここは申告に入れませんでした。どこまでを収集と呼ぶかは、機能の説明ではなく、実際にどのテーブルへ何を保存しているかで決めています。判断の根拠はアプリ側のリポジトリに文書として残しました。
同梱している部品も全部数え直しました。申告が本当に通るかは、実際に1本アップロードして警告が返るかどうかでしか分かりません。だから審査へ出す前にやりました。データをどこへ置くかという判断そのものは、会話をサーバーに置かないと決めた。Resuruのデータ設計と機種変更でも同じ考え方で書いています。
同じ手続きの中で、もう一度「見えないまま通る」に遭った
審査へ出したあと、提出の中身をあらためて機械的に数えました。すると、審査に含まれていたのはアプリの版だけで、購入まわりの商品が一緒に入っていませんでした。そのまま承認されていたら、アプリは公開されるのに加入できない状態になっていたはずです。
厄介なのは、押した本人からは何も見えないことです。提出の完了画面は普通に出ますし、版の状態も審査待ちになります。ストア側も注意は出していたのですが、下書きの画面を開かないと読めない場所にありました。
このときは版を審査から一度外し、商品と版をまとめて入れ直して出し直しています。直せたので実害はありませんでしたが、気づけた理由はテレメトリのときとまったく同じでした。完了したという表示を信じず、中身を数えたからです。
そこで、提出の中身を数える手順も記録として残しました。次に同じ作業をするとき、私は必ず忘れているからです。失敗をそのつど手順へ変える考え方は、個人開発で失敗を記録する六項目。却下と障害から残した形式にまとめています。
公開前に気づけたのは、期限を切って突き合わせたから
この見落としを見つけられたのは、能力ではなく手順のおかげです。配信の手続きの中に「申告と実装を1項目ずつ突き合わせる」という工程を置いていたので、そこで引っかかりました。置いていなければ、そのまま出していたはずです。
位置情報を扱うアプリでは、外へ出す範囲と、画面で見せる範囲の両方が約束になります。見せる側の判断は位置情報アプリなのに、正確な現在地を見せないことにした理由にまとめました。走ったルートを人に見せるときの注意は走ったルートをSNSで共有する前に確認したい四つの項目と隠し方にあります。
プライバシーポリシーは、書いた時点の実装に対する説明でしかありません。依存先を足したとき、依存先の版を上げたときには、また噛み合わなくなります。だからこれは一度やって終わる作業ではなく、出すたびに通す工程として残しました。
公開したあとのほうが、この作業は難しくなります。使っている人がいる状態では、直すまでのあいだも実態と説明が食い違ったままになるからです。今回は出す前だったので、申告を直してから並べられました。次に地図の部品の版を上げるときには、同じ突き合わせをもう一度やります。
ひとりで作っていると、実装も説明も同じ人間が書きます。だから食い違いに気づける人が私しかいません。その前提で手順を先に決めておくことが、私にとっては唯一の歯止めになっています。
公開中YORIRUN距離や時間から周回コースを探して、走った道を記録するiPhoneアプリ。
