Tesla Tech Terrace
技術記事

Fleet API の紹介

Tesla が初めて公式提供する開発者向け API、Fleet API を解説。Owner API との違い、セキュリティの仕組み、できること、開発ツールまで詳しく紹介します。

はじめに：サードパーティアプリが増えた今、Fleet APIを押さえる

Tesla関連のアプリやサービスは、ここ数年で一気に増えました。 充電の記録をまとめたり、出発前にエアコンを自動で入れたり、家の電気料金に合わせて充電を制御したり。公式アプリだけでは届かない「あと一歩」を埋めるものが多いです。

この裏側にあるのが、Teslaが公式に提供している Fleet API です。ざっくり言うと、車やエネルギー製品（Powerwall/太陽光など）の情報を取得したり、リモート操作の指示を送ったりするための“公式の窓口”です。

Teslaのドキュメントでは、Fleet APIを「Teslaの車両とエネルギーデバイスへのアクセスを提供する、データ取得とコマンドのサービス」と説明しています。

出典: Tesla Fleet API docs（What is Fleet API?） https://developer.tesla.com/docs/fleet-api/getting-started/what-is-fleet-api

この記事では「Fleet APIとは何か」「なぜFleet APIが必要になったのか」「Fleet APIで何ができるのか」を、分かりやすく整理します。

一方で、実際にアプリを登録してトークンを発行して…という“手を動かす”部分は、別の記事でまとめます（ここでは扱いません）。OAuth 2.0などの細かい仕様も、必要以上には踏み込みません。

まず結論だけ先に言うと、Fleet APIのポイントは次の3つです。

  • 公式: 仕様が公開され、サードパーティが正規の手順で連携できる
  • 安全: 操作コマンドは「署名付き」が前提になり、不正な操作をしにくい設計
  • 現実的: 常時監視はポーリングではなくテレメトリ（ストリーミング）へ誘導し、車のwakeやバッテリー消費を抑える

次のセクションから、まずは「APIって何？」からいきます。

そもそもAPIって何？

APIは、すごく雑に言うと「アプリ同士の受け渡し窓口」です。

例えば、あなたがスマホのアプリでTeslaを操作するとき、アプリは車そのものと直接しゃべっているわけではありません。 途中にTeslaのサーバーがいて、アプリはサーバーに対して「この車の状態を教えて」「空調を開始して」といった“お願い”を決まった形式で送ります。 その「決まった形式」や「入口（URL）」「渡していい情報の範囲」などをまとめたものがAPIです。

大事なのは2点です。

  • APIがあると、公式アプリ以外のサービスでも同じ仕組みで連携できる
  • 逆に言うと、APIの設計次第で「できること」「できないこと」「安全の強さ」が決まる

TeslaはFleet APIを、まさにその“公式の窓口”として用意しています。

広告

Tesla Fleet APIとは：公式の“データ取得とコマンド”の窓口

Fleet APIは、Teslaが開発者向けに公開している公式APIです。 車両に限らず、Powerwallや太陽光などのエネルギー製品にも触れられるのが特徴です。

Teslaのドキュメントでは、Fleet APIは車両とエネルギーデバイスに対するデータ/コマンドのサービスで、アプリは「自分のデバイス」または「ユーザーが許可したデバイス」を扱える、と説明しています。

出典: Tesla Fleet API docs（What is Fleet API?） https://developer.tesla.com/docs/fleet-api/getting-started/what-is-fleet-api

ここで押さえておきたいのは、APIが「何でもできる魔法」ではないことです。 Fleet APIは、

  • 取得（データ）: 車の状態や充電状態を“読む”
  • 操作（コマンド）: ロック、空調、充電、スケジュールなどを“動かす”

この2つを柱にしつつ、ユーザーが許可した範囲でだけ動くように作られています。

そして近年は「常に車の状態を監視したい」用途に向けて、ポーリング（定期的に取りに行く）ではなく、車両からデータが流れてくる仕組み（Fleet Telemetry）も用意しています。

Fleet APIができた経緯：Owner API時代の終わりと“署名付きコマンド”への移行

Fleet APIの話をするとき、避けて通れないのが「昔はOwner APIと呼ばれる仕組み（非公式）が使われていた」という話です。 いまサードパーティ連携がFleet APIへ寄っていくのは、単なる“公式化”だけが理由ではありません。

Tesla自身が、車両コマンド（遠隔操作）を エンドツーエンドで認証する 方向へ舵を切ったことが大きいです。 Teslaの公式GitHubでは、次のように明記しています。

"Some developers may be familiar with Tesla's Owner API. Owner API will stop working as vehicles begin requiring end-to-end command authentication."

出典: teslamotors/vehicle-command README https://github.com/teslamotors/vehicle-command

要するに、「車が“ちゃんと正規の手順で出された操作か”を厳密に確かめるようになっていく。だから、昔のやり方はそのままでは動かなくなる」という話です。

この流れは、TeslaのFleet APIドキュメントの告知（Announcements）にも時系列で出ています。特に大きいのは次の2点です。

1) RESTコマンドの廃止と、新しいコマンド方式への移行

Fleet APIの告知では、車両のRESTコマンド（/command）の段階的な廃止スケジュールを示し、最終的にVehicle Command Protocolが前提になっていくことも説明しています。

2) “未サポートな車両API” の段階停止

さらに2024年の告知では、Fleet APIがTeslaの公式なサードパーティAPIとして位置づけられ、リスト外の車両APIは段階停止する、と案内しています。 言い方は柔らかいですが、要は「公式の入口はこっち。別ルートは閉じていく」という宣言です。

このあたりをまとめると、Fleet APIが必要になった理由はだいたい次の3つに収束します。

  • セキュリティ: 遠隔操作を“署名付き”にして、なりすまし・不正操作を減らす
  • プライバシー: 位置情報などを含むデータアクセスを、より明示的な同意や権限で制御する
  • 運用: 常時監視はポーリングではなくテレメトリに寄せ、車のwakeやバッテリー消費、コストを抑える

次は、Fleet APIで実際に何ができるのかを、機能の分類で整理します。

Fleet APIで何ができる？（大枠）

Fleet APIでできることは、大きく4つに分けると理解しやすいです。

  1. 取得（data）: 車や充電、エネルギー製品の状態を読む
  2. 操作（commands）: ロックや空調、充電などを動かす
  3. 常時監視（telemetry）: 車からデータをストリーミングで受け取る
  4. エネルギー（energy/charging）: Powerwallや太陽光、Wall Connectorや充電履歴を扱う

「毎分この車のSOCを見たい」みたいな用途が出てくると、2よりも3の重要度が上がってきます。 逆に「たまに確認するだけ」なら、1だけでも十分です。

次のセクションからは、まず車両（data/commands）で“何がうれしいか”を具体例で見ていきます。

できること（車両）：状態確認と遠隔操作

Fleet APIの“いちばん分かりやすい使いどころ”は、車の状態確認と遠隔操作です。 ここは、普段Teslaアプリで触っている機能とイメージが近いので、理解もしやすいと思います。

状態確認（data）

たとえば次のような情報を取って、アプリ側で見やすくまとめられます。

  • SOC（バッテリー残量）や航続の目安
  • いま充電中か、完了見込みはどれくらいか
  • 施錠状態、エアコンの状態
  • 近くの充電スポット
  • リリースノートやサービス関連の情報

「朝、家を出る前に“いま何%？”だけサッと知りたい」とか、「家族の車もまとめて見たい」といった用途と相性がいいです。

ただし、ここで注意がひとつ。 車両のライブデータ（vehicle_data）を高頻度で取り続ける運用はおすすめされていません。 常時監視や通知が目的なら、後で触れるFleet Telemetry（ストリーミング）の方が設計として素直です。

遠隔操作（commands）

遠隔操作の代表例はこのあたりです。

  • ドアのロック/アンロック
  • エアコンの開始/停止（出発前のプレコン）
  • 充電の開始/停止、充電上限の変更
  • 充電やプレコンのスケジュール設定

“押したら動く”体験は分かりやすい反面、コマンドはセキュリティが重要です。 Fleet APIの車両コマンドは、エンドツーエンドで認証（署名）する方向に寄っています。 車両やファームウェア、コマンドの種類によって前提は変わりますが、署名が必要な環境では、署名がないリクエストを車が拒否する設計です。

Teslaのドキュメントでも、コマンドは署名が重要で、署名が前提のコマンドでは署名なしのリクエストを車両が拒否する、という考え方が説明されています。

出典: Tesla Fleet API docs（Vehicle Commands） https://developer.tesla.com/docs/fleet-api/endpoints/vehicle-commands

この仕組みのおかげで、サードパーティ連携でも“操作系は特に慎重に守る”方向に進んでいます。

できること（充電/エネルギー）：充電履歴、Powerwall/太陽光、Wall Connector

Fleet APIは「車のAPI」と思われがちですが、対象はそれだけではありません。 ドキュメント上でも、車両に加えてエネルギー製品へのアクセスが含まれることを明記しています。

出典: Tesla Fleet API docs（What is Fleet API?） https://developer.tesla.com/docs/fleet-api/getting-started/what-is-fleet-api

使う側から見ると、この「エネルギー/充電」側が効いてくるのは次の2パターンです。

1) 充電履歴をまとめたい（家計簿・経費精算）

たとえば充電履歴（charging history）やインボイス（請求書）に関するエンドポイントがあります。 「スーパーチャージャーの利用分を月末にまとめる」みたいな用途だと、アプリ側で集計・出力がしやすくなります。

2) 家の電気と一緒に最適化したい（Powerwall/太陽光）

Powerwallや太陽光がある家庭だと、Energy siteとして“家側の状態”も扱えます。 ざっくり言えば、家庭の消費・発電・蓄電の状況を見える化して、運転モードやバックアップ率の設定を切り替える、という方向です。

3) Wall Connectorの充電履歴も取れる

自宅充電をWall Connectorでやっている場合、Energy site側の履歴（telemetry history）として充電の記録を追えるケースがあります。 車両側の充電履歴と組み合わせると、「自宅分」「外出先分」を分けて見せる、といった整理もやりやすくなります。

ここは「車のデータだけ」よりも生活に近い話になりやすいので、連携アプリを選ぶときの判断材料にもなります。

できること（Fleet Telemetry）：ポーリングを減らして“起こさない・減らす”

Fleet APIをちゃんと理解したいなら、Fleet Telemetryは外せません。 理由はシンプルで、車の状態を“頻繁に取りに行く”運用には、車のwake（スリープから起こす）やバッテリー消費がついて回るからです。

TeslaはFleet Telemetryを「車からデータを集めるのに効率がいい方法」と説明しています。

あわせて、vehicle_data のポーリングを減らし、不要なwakeやバッテリー消費を避ける狙いも書かれています。

出典: Tesla Fleet API docs（Fleet Telemetry） https://developer.tesla.com/docs/fleet-api/fleet-telemetry

言い換えると、

  • vehicle_data を定期的に叩いて監視するより
  • 車両から“流れてくる”データ（ストリーミング）を受ける方が

車に優しく、コスト面でも有利になりやすい、ということです。

もう一つ安心材料になるのが、「許可したアプリに対して、車両から直接テレメトリを送れる」と明記している点です。

"Owners can allow registered applications to receive telemetry securely and directly from their vehicles."

出典: teslamotors/fleet-telemetry README https://github.com/teslamotors/fleet-telemetry

日常の感覚だと、

  • 「朝の通知」「帰宅時の通知」「充電完了の通知」みたいな“イベント駆動”
  • “常に見ている”系のダッシュボード

このあたりはFleet Telemetry前提で作られていく、と見ておくと分かりやすいです。

使う前に知っておきたい注意点：権限、位置情報、課金、そしてアプリ選び

Fleet APIが公式に整備されたことで、サードパーティ連携はやりやすくなりました。 ただ、利用者側にも「最低限ここは知っておくと安心」というポイントがあります。

1) 権限は“許可した範囲だけ”。そして後から取り消せる

Fleet APIは、ユーザーが許可したデバイス／アプリだけがアクセスできる、という前提で作られています。 だからこそ、アプリに与える権限は「必要な分だけ」に絞るのが基本です。

2) 位置情報はセンシティブ。UIに影響する場合もある

車の位置情報は便利ですが、同時にセンシティブです。 Teslaは告知で、ファームウェアによって位置情報がデフォルトで返らなくなったり、明示的な取得指定が必要になったり、といった変更を案内しています。 位置情報を扱う連携アプリは、何のために必要なのか（到着通知なのか、ジオフェンスなのか）を説明してくれる方が安心です。

3) 課金と制限がある（アプリ側の都合が、ユーザー体験に直結する）

Fleet APIは従量課金です。 Teslaのドキュメントでは、利用量に応じて段階的に課金される、と説明しています。

さらに、支払い方法が未設定だったり上限を超えたりすると、アプリが自動的に無効化され得ることも案内しています。

出典: Tesla Fleet API docs（Billing and Limits） https://developer.tesla.com/docs/fleet-api/billing-and-limits

利用者としては「なんか最近このアプリ不安定だな」の原因が、裏側の課金や制限にあるケースもあり得る、くらいは覚えておくと腹落ちしやすいです。

4) “車を起こし続ける”設計のアプリは避ける

前に触れた通り、vehicle_dataを頻繁に取りに行く運用は、車のwakeやバッテリー消費に効きます。 通知や常時監視が売りのアプリなら、Telemetryを前提に設計しているか、少なくともポーリング間隔やwakeへの配慮が説明されているか、を見るのがおすすめです。

5) 最後は「そのアプリに、どこまで渡すか」

ロックや空調のような操作系は便利です。 一方で、権限を渡すほど“できること”も増えます。 便利さと引き換えに何を預けるのかを一度意識しておくと、連携アプリ選びで失敗しにくくなります。

まとめ：Fleet APIは『公式に、許可した範囲で、安全に』Teslaを連携させる仕組み

Fleet APIは、Teslaが公式に用意した「データ取得と操作」の窓口です。 Owner API時代の延長で見てしまうとややこしく感じますが、流れとしてはシンプルで、

  • 公式のAPIに寄せる
  • 権限は必要最小限で渡す
  • 操作コマンドは署名付きで守る
  • 常時監視はTelemetryで、車を起こし続けない

この方向に揃ってきています。

次回は、実際にFleet APIを使う側の手順（アプリ登録、必要な準備、最小構成での動作確認）を、スクリーンショット込みでまとめる予定です。