車両の状態を確認するだけなのに、なぜ通信の仕方を気にする必要があるのでしょうか。
理由は、車がスマートフォンやサーバーのように常時待ち受けているわけではないからです。駐車中の Tesla は、電力消費を抑えるためにスリープします。車両の状態を取得する API の中には、車が起きていることを前提とするものがあります。呼び出し方によっては、情報を読むだけのつもりでも車を起こし、余分な電力を使わせることがあります。
だからといって、「車への通信は一切しない」が正解ではありません。大事なのは、どの通信なら車を起こしてよいのか、その境界を決めておくことです。
境界は「読み取り」か「操作」かではない
API の種類だけを見て、「読み取りなら安全」「コマンドなら起床」と分けることはできません。読み取りでも車両への到達が必要な場合があります。一方、車がスリープ中だと分かっているときに、起床させずにその状態だけを確認して終わる処理もあります。
判断の軸は、誰が、何のためにその通信を始めたかです。
バックグラウンドの都合では起こさない
たとえば、ユーザーが画面を開いていない間の定期更新や、通知のための状態確認。こうした処理の目的は、表示を新しく保つことです。そのためだけにスリープ中の車を起こすと、利用者が求めていない電力消費につながります。
車両から送られてくるテレメトリを受信し、保存してアプリへ届ける処理も同じです。すでに届いたデータを扱うことと、最新データを得るために車へ問い合わせることは別の行為です。後者が必要でも、車がスリープ中なら無理に起こさず、次に車が通信できる機会を待つ選択肢があります。
ダッシュボードを開いたときも、画面を見ることと車を起こすことを自動的に結び付ける必要はありません。保存済みの値を表示し、「最終更新時刻」を添えれば、データがいつのものかを利用者に伝えられます。
ユーザーが明示した操作なら起こす
一方、ユーザーがロック解除やエアコン操作などのボタンを押した場合は、車に操作を届けること自体が目的です。車がスリープ中で、操作の実行に起床が必要なら、車を起こす理由は明確です。
この場合も、ボタンを押した瞬間に操作完了と表示してはいけません。起床や通信には時間がかかることがあり、API が操作を受け付けたことと、実車に操作が反映されたことは別だからです。処理中、成功、失敗を分けて伝えることで、「押したのに動かない」という不安を減らせます。
通信が届いていることは、車が起きている証拠ではない
ストリーミング接続が続いていても、車がスリープ中のことがあります。車両からメッセージが届いたという事実だけで、車の状態を「起きている」と更新すると、状態表示が実態とずれることがあります。
「データを受信した時刻」と「車が起きていると確認できた時刻」は、同じ意味ではありません。状態を更新するときは、どの情報を根拠にしたのかを分けて考える必要があります。
起床の判断を、呼び出しごとに任せない
この境界を各機能の担当者に任せると、ある定期処理だけが知らないうちに車を起こす、といった抜けが生まれます。車両への到達が必要な通信では、共通の判定処理を通すようにします。
設計では、少なくとも次の点を確認します。
- その通信はユーザーが今頼んだ操作か、それともバックグラウンド処理か。
- 車がスリープ中と分かっている場合、呼び出しを止めるか、車を起こさない方法で状態だけを確認するか。
- データを更新できない場合、古い値と最終更新時刻を正しく表示できるか。
- 再試行が、意図しない起床や過剰な API 呼び出しにつながらないか。
- API による操作の受付と、車両への反映を別の状態として扱っているか。
まとめ
車両アプリでは、通信を増やせば表示がよくなるとは限りません。利用者が求めていない通信で車を起こさず、必要な操作では意図を尊重して起こす。その線引きを一貫して守ることが、バッテリーへの配慮と、安心して使える操作の両方につながります。
車両データがアプリへ届く仕組みについては、Teslife は車両のデータをどう受け取っているのかで紹介しています。
