まず「追跡されない」を分解する定義

「スマートカーのアプリに追跡されないようにする 4」という問いは、実務上は“何をどの範囲で、どう観測されることを避けたいのか”に分解すると整理しやすくなります。追跡には複数の形があります。たとえば、アプリが位置情報を継続的に取得してクラウドへ送る場合は、行動のパターンが推定されやすくなります。また、ログインや端末情報によって、同じユーザーや端末として紐づけられることも追跡の一種です。

そこで本稿では、「追跡されない」を“アプリが第三者や外部サービスに対して行動・識別を紐づけられる可能性を、利用者側で下げる”という目標として扱います。目標をこのように定義すると、制限や例外も含めて現実的に説明できます。

簡単なモデル：追跡が成立する流れ

追跡は、概ね次の流れで成立します。

  1. アプリが情報を取得する（位置情報、利用状況、端末に関する情報、操作履歴など）
  2. アプリがその情報を送信する（通信経路、サーバ、提携先への転送）
  3. 受け手が情報を紐づける（アカウント、端末識別子、時系列パターンなど）
  4. まとめられたデータが分析・保存される（目的に応じた利用）

「追跡されないようにする」には、(1)〜(3)のどこを弱めるかが鍵になります。たとえば取得の段階で抑えれば、後段で紐づける材料が減ります。一方、取得を止められない場合は、送信量や送信先の見え方を抑える方向に寄せます。

4つの“制御ポイント”：できること・できないこと

ここでは実践に直結する4つの制御ポイントを挙げます。

1) アプリの権限：位置情報・バックグラウンド動作

まず重要なのは、位置情報やバックグラウンド実行に関する権限です。アプリが「常に」位置情報を使える状態だと、走行の有無に関わらず情報が収集されやすくなります。権限を「使用時のみ」へ下げられる場合、継続的な取得の可能性が減ります。

ただし、車両の機能（遠隔操作、セキュリティ通知、ルート推定など）によっては、ある程度の継続データが必要になる場合があります。つまり“権限を切れば完全に止まる”とは限りません。

2) 端末側の識別：通知・ログイン・復元

アプリは多くの場合、アカウントでログインして利用します。ログインがある以上、同一人物または同一端末として再認識される余地は残ります。また、端末の復元機能や端末識別子の仕組みにより、再インストール後もある程度の紐づけが起こることがあります。

3) 通信の見え方：送信先・送信頻度の観察

追跡の有無を“気分”ではなく“観測”で判断するなら、通信の傾向を見ます。具体的には、通信量が急に増えたタイミング（車に近づいた直後、アプリを開いた後、ログイン直後など）を記録し、想定外の頻度がないかを確認します。

注意点として、一般利用者がすべての送信先や目的まで断定できるとは限りません。