前提：Model Y L を契約したため、納車前にログ基盤が必要だった
本記事の構成は、2026年7月3日に Tesla Model Y L を契約し、 納車前からログ基盤を準備する必要があったため採用したものです。
技術的な理由としては、 Teslamate は「車両がオンラインになった瞬間からログを記録できる」ため、 納車前に環境を整えておくと初期ログを取り逃さないというメリットがあります。
Teslamateとは何か？
Teslamate は Tesla 車両のテレメトリを自動収集し、 Grafana で可視化するオープンソースのログプラットフォームです。
記録できる主なデータは以下の通り：
- 走行ログ（距離・速度・消費電力）
- 充電ログ（開始・終了・料金・電力量）
- バッテリー劣化（Projected Range）
- スリープ状態・起床回数
- 位置情報・訪問地点・ルート履歴
- 気温・効率・電費
- ソフトウェアアップデート履歴
これらを 自動で記録し、時系列で可視化できます。
なぜハイブリッド構成（OCI＋オンプレ）なのか？
今回の記事では、Teslamate を クラウド（OCI）＋オンプレ（Raspberry Piクラスタ） の ハイブリッド構成で運用します。
技術的な理由は3つあります。
1. Tesla API の負荷をクラウド側に逃がすため
Tesla API をローカルの Raspberry Pi だけで叩くと、 車両が頻繁に起きてしまい、スリープが不安定になります。
そのため、OCI側に API Proxy を置くことで：
- 車両のスリープが安定
- ローカル側の負荷が激減
- 納車センターでもログ取得可能
というメリットが得られます。
2. ローカル側でログ解析を高速に行うため
Teslamate の解析はローカルのほうが高速です。
総帥の環境では Pi5 Proxmox の VM が中枢となり、
- Teslamate
- Grafana
- PostgreSQL
を快適に処理できます。
3. SeaweedFS で長期ログを安全に保存するため
クラウドストレージは無料枠が少なく、 長期ログには向きません。
そこでオンプレ側に SeaweedFS fast/cold tier を構築し、
- SSD（fast）
- HDD（cold）
- replication
- 永続化
というストレージ基盤を作ります。
今回の記事のゴール
この記事では、以下の3部構成で Teslamate のハイブリッド環境を構築します。
- 第1部：OCI編 Tesla API Proxy をクラウド側に構築する
- 第2部：Pi5編 Teslamate / Grafana / PostgreSQL をオンプレ側に構築する （Proxmoxルート / Raspberry Pi単体ルートの2ルート構成）
- 第3部：SeaweedFS編 fast/cold tier のストレージ基盤を構築する
この3つを順番に進めることで、 誰でも Teslamate のハイブリッド環境を再現できるようになります。
コメント