テスラをコードで制御するとはどういうことか
API とは、人がアプリ画面を操作する代わりにプログラムがサービスへ話しかける窓口だ。テスラはこの窓口を Fleet API として公式に提供している。アプリで押していたロック、空調オン、充電開始といった操作がそれぞれコマンド名として開かれており、プログラムがその名前を呼べば車が実際に動く。
かつてはテスラアプリの通信を解析した非公式 API が広く使われていたが、いまは正規の経路がある。オーナーが自分のテスラアカウントでログインし、特定のアプリへ権限を委任すると（OAuth）、そのアプリがオーナーの代わりにコマンドを送る。サードパーティが言う「テスラアカウントを連携」とはこの委任のことだ。
最近の車両にはもう一層加わる。コマンドには電子署名が必要で、その署名を検証する公開鍵をオーナー自身が車両へ登録しなければならない。これを virtual key と呼ぶ。車両のロック画面からいつでも削除できるため、権限を渡したあとも取り消しはオーナーの手に残る。
整理すると三層だ。アカウントの委任（OAuth）、車両に登録された公開鍵（virtual key）、そしてその鍵でコマンドに署名する自分のサーバー。これが揃えば、あとはごく普通の HTTP リクエストにすぎない。
何が開かれ、何が開かれないのか
開かれている範囲は思ったより広い。下表は、テスラ公式のコマンドプロキシ実装（teslamotors/vehicle-command）に実際に定義されている名前を分類したものだ。
逆に開かれていない側も明確だ。ステアリングや加減速といった走行制御、オートパイロットや FSD の操作、スマートサモン、カメラ映像やセントリークリップの閲覧は API にない。ドアも解錠までで、物理的に開くわけではない。つまり「AI が運転する」ではなく「車まわりの反復作業を人の代わりに押す」が正確な表現だ。
もう一点、車がスリープ中はコマンドがすぐには通らない。wake_up で起こしてから送る必要があるが、この呼び出しは高い（費用の節を参照）。状態を繰り返し尋ねるポーリングより、車から信号が届く Fleet Telemetry のストリーミングを使うほうが安く速い。
| 分類 | コマンド名（一部） |
|---|---|
| 空調 | auto_conditioning_start · auto_conditioning_stop · set_temps · set_climate_keeper_mode · set_preconditioning_max · remote_seat_heater_request |
| ドア・収納 | door_lock · door_unlock · actuate_trunk(front/rear) · charge_port_door_open · window_control(vent/close) |
| 充電 | charge_start · charge_stop · set_charge_limit · set_charging_amps · add_charge_schedule · add_precondition_schedule |
| セキュリティ・モード | set_sentry_mode · set_valet_mode · guest_mode · speed_limit_activate · parental_controls_activate · set_pin_to_drive |
| 利便機能 | navigation_request · trigger_homelink · flash_lights · honk_horn · set_vehicle_name · schedule_software_update · wake_up |
なぜアフターブローが最初の自動化に向くのか
アフターブローとは、走行を終えて降りたあとに空調をもう少し回してエバポレーターを乾かす動作だ。冷房中は空気中の水分がその表面に結露し続け、濡れたまま残るとカビが育ち、次にエアコンを入れたときに酸っぱい臭いとして戻ってくる。フィルターを替えても臭いが変わらないことが多いのはこのためだ。
ところがテスラの車両メニューにアフターブローの項目はない。そのため、この機能だけを作って月額で売るサービスが実際に存在する。テレグラムのボットにテスラアカウントを連携すると自然乾燥と温風乾燥を代行してくれ、14 日間の無料体験のあと月 1,000 ウォンほどから、という具合だ（価格は sla-ai-bot.smartstream.kr の案内による）。
最初の自動化に向く理由は三つ。必要なコマンドが二つか三つだけで、失敗しても危険がない。結果が鼻で確認できるのでログを漁る必要がない。そしてここで身につける認証・署名・スケジュールの構造は、充電時間帯の最適化、出発前の予熱、駐車後の自動ロックにそのまま再利用できる。
準備 1 — 開発者アプリ登録と公開鍵のホスティング
まずテスラ開発者サイト（developer.tesla.com）でアプリケーションを登録する。個人が自分の車だけに使う場合でもこの登録は必要だ。登録するとクライアント ID とシークレットが得られ、アプリが要求する権限範囲（空調・充電・ロックなど）を選ぶ。
初心者が最も引っかかるのはドメイン要件だ。アプリごとに自分が所有するドメインを一つ登録し、そのドメインの決められたパスに公開鍵ファイルを置く必要がある。パスは固定で /.well-known/appspecific/com.tesla.3p.public-key.pem だ。テスラがこのアドレスから直接鍵を読みにくるため、ローカルファイルではなくインターネットから開けるアドレスでなければならない。
鍵は EC（prime256v1）方式で作る。秘密鍵は自分のサーバーだけに置き、決して公開しない。上のアドレスに載せるのは公開鍵だけだ。秘密鍵が漏れればその鍵で自分の車にコマンドを送れてしまうので、保管場所と権限は最初から設計しておく。
最後にオーナーが車両へ鍵を登録する。アプリが案内する https://tesla.com/_ak/<自分のドメイン> のリンクをスマートフォンで開くとテスラアプリが起動し、承認すれば車両に鍵が追加される。このとき車両はオンラインである必要がある。消したくなったら車両のロック画面でその鍵を削除すればよい。
# 1) 秘密鍵の生成（EC prime256v1）— 自分のサーバーだけに保管
openssl ecparam -name prime256v1 -genkey -noout -out private-key.pem
# 2) 公開鍵の抽出
openssl ec -in private-key.pem -pubout -out public-key.pem
# 3) 自分のドメインの固定パスに公開鍵を置く（パスは変更不可）
# https://<自分のドメイン>/.well-known/appspecific/com.tesla.3p.public-key.pem
# 4) 開けるか確認する
curl -s https://<自分のドメイン>/.well-known/appspecific/com.tesla.3p.public-key.pem
# 5) オーナーがスマートフォンでこのリンクを開き車両に鍵を登録する
# https://tesla.com/_ak/<自分のドメイン>準備 2 — コマンド署名プロキシを立てる
最近の車両は署名されたコマンドしか受け付けない。署名を自前で実装する必要はない。テスラが公式オープンソースとして tesla-http-proxy を出しており、これを自分のサーバーで動かせば、普通の HTTP リクエストを受け取って秘密鍵で署名し、車へ転送してくれる。つまり自分のコードはプロキシに curl を一行投げる程度に単純になる。
インストールは Go か Docker イメージのどちらでもよい。同時に入るツールは四つ。tesla-keygen はコマンド認証用の秘密鍵を作りシステムキーチェーンへ入れ、tesla-auth-token は OAuth トークンを保存し、tesla-control はターミナルからそのままコマンドを試せるツール、そして tesla-http-proxy が今必要な REST プロキシだ。
プロキシ自身も TLS で待ち受ける。そのため起動時にはプロキシ用の証明書と鍵、そして車両コマンドの署名に使う秘密鍵ファイルをそれぞれ渡す。自己署名証明書なら curl に --cacert でその証明書を教える。
ここまで来たら試しにライトを点滅させてみる。失敗する場合、原因はたいてい三つのいずれかだ。車がスリープしている（wake が必要）、virtual key がまだ車両に登録されていない、トークンの権限範囲にその機能が含まれていない。
# インストール（どちらか）
go install github.com/teslamotors/vehicle-command/cmd/...@latest # Go 1.23+
docker pull tesla/vehicle-command:latest # Docker
# 鍵・トークン名と車両 VIN を環境変数に置く
export TESLA_KEY_NAME=$(whoami)
export TESLA_TOKEN_NAME=$(whoami)
export TESLA_CACHE_FILE=~/.tesla-cache.json
export TESLA_VIN=<自分の車の VIN>
# コマンド認証用の秘密鍵を生成（公開鍵は標準出力へ）
tesla-keygen create > public_key.pem
# REST プロキシを 4443 番ポートで起動
tesla-http-proxy -tls-key config/tls-key.pem -cert config/tls-cert.pem \
-key-file config/fleet-key.pem -port 4443curl --cacert cert.pem \
--header "Authorization: Bearer $TESLA_AUTH_TOKEN" \
--data '{}' \
"https://localhost:4443/api/1/vehicles/$TESLA_VIN/command/flash_lights"アフターブロー用スクリプトを書く
本題だ。アフターブローはコマンド三回で終わる。空調を入れ（auto_conditioning_start）、温度を上げ（set_temps）、決めた時間が過ぎたら止める（auto_conditioning_stop）。温度を上げるのは、冷風ではなく温風で乾かさないとエバポレーターが実際には乾かないからだ。
時間は 10 分前後で十分だ。長く取りすぎると駐車場で空調が回り続けバッテリーを使う。まずは 5 分から始めて臭いが取れるか見て、そこから延ばすほうがよい。
実行のきっかけは二通り。簡単なのは降車時刻がだいたい決まっている場合で、スケジューラ（cron や macOS の launchd）に時刻を入れておく。正確なのは Fleet Telemetry のストリーミングで駐車状態の信号を受け取り、実際に駐車したらスクリプトを呼ぶ方式だ。状態を尋ね続けるポーリングは wake のコストゆえに勧めない。
下のスクリプトはプロキシがすでに動いている前提の最小版だ。ハードコードした値を自分の環境に合わせるだけでそのまま動く。
#!/bin/bash
set -euo pipefail
PROXY="https://localhost:4443/api/1/vehicles/$TESLA_VIN/command"
AUTH="Authorization: Bearer $TESLA_AUTH_TOKEN"
CA="--cacert cert.pem"
DRY_MIN=10 # 乾燥させる時間（分）
send() { # send <コマンド名> <JSON 本文>
curl -s $CA --header "$AUTH" --header "Content-Type: application/json" \
--data "$2" "$PROXY/$1"
echo
}
# スリープ中なら起こす（必要なときだけ — wake は高い）
send wake_up '{}'
sleep 5
# 1) 空調オン 2) 運転席・助手席の温度を最大に
send auto_conditioning_start '{}'
send set_temps '{"driver_temp": 28, "passenger_temp": 28}'
# 3) 乾燥のあいだ待って停止
sleep $((DRY_MIN * 60))
send auto_conditioning_stop '{}'# 平日 19 時 10 分に実行
10 19 * * 1-5 /Users/me/tesla/afterblow.sh >> /tmp/afterblow.log 2>&1費用 — 個人利用なら実質無料、ただし罠が二つ
Fleet API は 2025 年 1 月から従量課金だ。ただしアカウントごとに毎月 10 ドルのクレジットが付くため、車一、二台の自動化はこのクレジット内で収まる。テスラが挙げる例は、車両二台でストリーミング＋一日 100 コマンド＋wake 2 回。アフターブローは一日三、四コマンドなので余裕は大きい。
一つ目の罠は支払い方法だ。クレジット内だけで使う場合でも、支払い方法を登録していないアプリは自動的に無効化される。アカウントの既定の支出上限は 0 で、支払い方法を登録して初めて上限を引き上げられる構造でもある。逆に上限を低く（例えば 1〜5 ドル）設定しておけば、うっかり高額請求を受ける事故も防げる。
二つ目の罠はポーリングだ。コマンドは安いが、スリープ中の車を起こす wake と REST で車両状態を繰り返し取得する呼び出しは高い。1 分ごとに状態を尋ねるループを書くと、数日でクレジットが尽きる。状態が必要ならポーリングではなく Fleet Telemetry のストリーミングを使うのが定石だ。
| 項目 | 目安 | 注意 |
|---|---|---|
| 月額クレジット | アカウントごとに 10 ドル | 車一、二台の個人自動化はこの中で収まる |
| コマンド | 1,000 件で 1 ドル | セント単位で丸め（1,211 件なら 1.21 ドル） |
| wake | コマンドの約 20 倍 | 必要なときだけ。ループに入れない |
| 車両データのポーリング | 最も高い部類 | Fleet Telemetry のストリーミングで代替 |
| 支払い方法 | 未登録だとアプリが無効化 | 支出上限を低く設定して事故を防ぐ |
AI コーディングエージェントに何を任せるか
ここまで読んで「手順が多い」と感じたなら、その感覚は正しい。難しいのはコードではなく登録・認証・署名という付随手続きであり、こうした作業こそ Claude Code や Codex のようなコーディングエージェントが得意とする領域だ。ドキュメントを読み、コマンドを実行し、結果を見て次の手順を選ぶ反復だからだ。
任せるときは目標ではなく確認できる条件で指示するほうが結果がよい。「テスラ自動化を作って」より「公開鍵がこのアドレスで 200 を返すか確認し、プロキシを 4443 番ポートで立て、flash_lights が成功するところまで見せて」のほうがはるかによい。各段階の成否を人が目で判定できるからだ。
注意が一つ。秘密鍵とアクセストークンを画面やリポジトリに残さないルールを最初に与える。エージェントには鍵ファイルのパスを伝えつつ内容は出力しないよう指示し、環境変数と .gitignore を先に用意してから作業を始めるのが安全だ。
1. https://github.com/teslamotors/vehicle-command の README を読んでインストールせよ。
2. openssl で EC（prime256v1）鍵ペアを作れ。秘密鍵は ~/.tesla/ に置き、
内容は決して出力するな。パスだけ報告せよ。
3. 公開鍵を public/.well-known/appspecific/com.tesla.3p.public-key.pem にコピーし、
デプロイ後にそのアドレスが 200 を返すか curl で確認せよ。
4. tesla-http-proxy を 4443 番ポートで起動し、flash_lights の成功まで見せよ。
失敗したら原因が wake・virtual key・scope のどれか判別せよ。
5. 最後に afterblow.sh を書き、crontab に平日 19:10 で登録せよ。
トークンと鍵は .env に分離し .gitignore に入れよ。まとめ — 手順チェックリスト
一つ、developer.tesla.com でアプリを登録し必要な権限範囲を選ぶ。二つ、EC 鍵ペアを作り公開鍵を自分のドメインの /.well-known/appspecific/com.tesla.3p.public-key.pem に置く。三つ、https://tesla.com/_ak/<自分のドメイン> のリンクで車両に virtual key を登録する（車両はオンラインであること）。
四つ、tesla-http-proxy を立て flash_lights で接続を確認する。五つ、afterblow.sh を作り auto_conditioning_start → set_temps → 待機 → auto_conditioning_stop の順を入れる。六つ、スケジューラに登録し、支払い方法と低めの支出上限を設定する。
ここまでが最初の自動化だ。同じ構造の上に充電時間帯の最適化、出発前の予熱、駐車後の自動ロックを載せるのは、コマンド名を変える程度の作業でしかない。逆に走行制御と FSD はこの道では開かないという点は、最初にはっきりさせておくほうがよい。