車をチャットルームの一員にする──Raspberry Pi 5に35BのQwenを載せて完全オフラインで動かすCarWatch
OSSプロジェクトCarWatchは、約300ユーロのRaspberry Pi 5上でQwen3.6-35B-A3Bをローカル実行し、OBDと自動車メーカーのクラウド（Mercedes me）両方に接続して、車をチャットルームのエージェント参加者にする。実測値として3.5 tok/s・65℃常用・489ページの取扱説明書を根拠に「分からないことは分からない」と答える設計をREADMEから確認した。
目次
3行まとめ
- CarWatchは、約300ユーロのRaspberry Pi 5（16GB）にQwen3.6-35B-A3Bをローカルで載せ、クラウドも通信契約も使わずに車をGroupMindのチャットルームに参加するエージェント（
@gleのような名前）にするOSSプロジェクト。- 実測値として生成3.5 tok/s・プロンプト処理25+ tok/s・65℃で安定動作、と公式READMEに明記されている。
- 車体489ページの取扱説明書をページ引用付きで参照し、説明書に書かれていないことには「分からない」と答えるよう設計されている、という一人称制御の作り込みが特徴的だ。
「車のローカルAIは来る。問題は誰がそれを所有するか」
READMEの「Why CarWatch」セクションは率直だ。自動車各社は自社のローカルAIを開発しているが、その先にあるのは「あなたのデータを自社クラウドに、自社のサブスクリプションで、自社ブランドに縛り付ける」という結末だ、とREADMEは断じる。CarWatchはその逆を行く——データは車の中に留まり、ブランドを問わず動き、電波が入らない場所でも機能し、サブスクリプションもロックインもない。車データ層はベンダー非依存のインターフェース（carwatch/cloudcar.py）として実装されており、Mercedesは最初のアダプタに過ぎず、Tesla・BMW・VWのアダプタも3メソッドを実装すれば差し込めるとREADMEは説明している。
実測値：3.5 tok/s、65℃、Pi 5 16GBで約300ユーロ
READMEに「Live and measured, on real hardware（実機で計測済み）」として明記されている数字は次の通り。
- Qwen3.6-35B-A3B（Unsloth UD-Q3_K_S動的量子化、14.3GB）で生成3.5 tok/s・プロンプト処理25+ tok/s、65℃で安定動作。クラウドなし・インターネット接続なし・サブスクリプションなし
- 車の489ページの取扱説明書（SDカードに同梱）をページ引用付きの語彙検索RAGで参照し、説明書に書かれていないことには回答を拒否する
- グラウンデッドな自己認識：温度・スロットリング状態・ファン・メモリ・ディスク・ネットワーク・現在ロードされているモデルを、質問のたびに機械から直接読み取る。感知できないことは「感知できない」と答え、不明な値が黙って事実として扱われることがないようシステムプロンプトが設計されている
- ハンズフリー音声：常時稼働のリスナー（エネルギーVAD → whisper.cpp、すべてPi上）が発話を検出し、同じグラウンデッドなパイプラインに通してルームへ返答する。ウェイクワードもクラウド音声認識も不要
- 依存ゼロ：CarWatchの全コードはPython標準ライブラリのみで書かれており、pip install・venvは不要。全モジュールのAST走査で検証済みとREADMEにある
- 自律起動：systemdサービスがモデルサーバー・ルームエージェント・音声リスナー・電話用ダッシュボード・エンジン監視の全スタックを起動時に自動で立ち上げる
- どこからでもメンテナンス可能：車自身がこのリポジトリから更新を取得（1時間ごと＋ダッシュボードの「update now」ボタン）し、トンネルを自ら発信して外側へ接続を保つため、駐車場でのラップトップ作業が不要
- 3段階の接続性：スマホのテザリング→自宅Wi-Fi→独自のフォールバックアクセスポイントの順で試すため、ガレージなど電波ゼロの環境でもスマホからは常に到達できる
「証明済み・未検証」を機能ごとに正直に区別するステータス表
READMEには「Status — what is proven vs. built vs. planned（証明済み／構築済み／計画中）」という表があり、開発者自身の運用ポリシーとして「実車で動いて初めて“proven（証明済み）”とラベルを付ける」と明記されている。主要な項目を抜粋すると次の通り。
| 機能 | ステータス |
|---|---|
@gleルームエージェント（メンション対応・根拠付き回答・生存確認） |
証明済み（日次で稼働中） |
| 取扱説明書RAG（ページ引用付き） | 証明済み |
| 電話用ダッシュボード（車が自ら配信） | 証明済み |
| ハンズフリー音声（VAD→whisper→根拠付き回答→ルーム投稿） | 証明済み（実車での音声書き起こしを確認） |
| リポジトリからの自己更新 | 証明済み |
| NAT越しの外部到達性（cloudflared tunnel） | 証明済み（インターネット経由での到達を確認） |
| OBDエンジン読み取り（Bluetooth ELM327、RPM・冷却水温・速度・ハイブリッド%・12V） | 証明済み（毎日実車から読み取り。DoIP/ENETケーブル経由は先に試したが、このMercedesではゲートウェイが応答せず失敗、既知のデッドエンドとして記録） |
| メーカークラウド読み取り（Mercedes me経由、ロック・ドア・窓・タイヤ・充電・航続距離・燃料・走行距離） | 証明済み（実車2台＝ヘルシンキ1台・ベルリン1台で、読み取り専用として稼働） |
| 安全な範囲のクラウドコマンド（ドアロック・窓閉め） | 証明済み（ダッシュボードからの窓閉めコマンドで実際に開いていた窓が閉まった。解錠・開扉・エンジン始動は意図的に実装していない） |
| 生のCANバスキャプチャ＋デコードツール | キャプチャのみ証明済み（2,518フレーム・エラー0件）。信号の意味づけには相関ドライブが必要で、現状は「候補」としてのみ扱われ、正直に未ラベルのまま |
| ドラレコのクリップ取得（WOLFBOX G900） | 疎通確認のみ、パイプライン未接続 |
| MBUXダッシュボード表示・ミラーアイコン | 計画中 |
「一度でも実車で動くまでは“proven”と書かない」という開発者自身のルールが、この表の粒度に表れている。
最初の一言は「エンジンは正常」という嘘だった
このグラウンディング設計がなぜここまで厳格なのかについて、開発者が別途投稿したGitHub Discussion（#9）に、設計の出発点となった具体的なエピソードが書かれていた。
"The very first message the car agent generated said: 'the 489-page manual confirms my engine is purring just fine.' It had consulted nothing, and the engine was off."
（車エージェントが最初に生成したメッセージはこうだった。「489ページの取扱説明書によれば、私のエンジンは正常に稼働しています」。実際には何も参照しておらず、エンジンはそもそも切れていた）
この失敗がcarwatch/grounding.pyという、事実の扱いを制御するモジュールの直接のきっかけになったという。開発者は設計原則を「1本のタイヤにつき1原則」という比喩で4つにまとめている。①感知できることだけを主張する（感知できないことは明示的に「感知できない」と扱われ、黙って作り話にならないようにする）、②検証されたことだけを主張する（“proven”と“built + tested”を意図的に別の言葉にする）、③暫定的なものは大きく表示する（生のCANキャプチャは本物だが、相関ドライブで裏取りされるまでは信号名を1つも確定しない）、④失敗はそのまま報告する（前向きな言い換えをしない）。
クラウド経由のコマンドについても、Discussionでは踏み込んだ説明があった。
"The cloud module is read-only by construction: it can only issue GETs. The two commands that exist (lock doors, close windows) are the make-safe direction and need no security PIN, and they live behind a hard allowlist. Unlock, open, engine-start and sunroof are not 'disabled' by a flag you could flip; they are simply not expressible in the code."
（クラウドモジュールは構造的に読み取り専用で、GETリクエストしか発行できない。存在する2つのコマンド（ドアロック・窓閉め）は「安全な方向」であり、セキュリティPINを必要とせず、厳格な許可リストの内側にある。解錠・開扉・エンジン始動・サンルーフ操作は、フラグを反転させれば有効化できる「無効化」ではなく、コードの中にそもそも存在しない）
Hacker News・Redditの実名の質問に答えるFAQ
CarWatchはHacker News・Reddit（r/raspberry_pi）で話題になったようで、開発者は実名の質問者を明記したFAQを公開している。技術的な設計判断についての回答をいくつか拾うと、次のような内容だった。
- なぜGemma 4 E4BではなくQwen 35B-A3Bなのか（dofmさんの質問）: 「35B」という総パラメータ数よりも「A3B」（Mixture-of-Expertsで1トークンあたり約30億パラメータしか使わない設計）の方が重要で、量子化してもPiのメモリに収まり、実用的な速度で動く。同等品質の密なモデルは、そもそも収まらないか極端に遅い、という回答
- 車種・年式ごとの違いにはどう対応するのか（jiangriver66さんの質問）: マニュアルRAGはページを引用し、ライブ値は「読み取ったまま」引用され、システムプロンプトは「分からないことは分からないと明言する」ことを要求している、という回答
- Piサイズのローカルモデルの発言を信用すべきか（trouthatさん、AllRealityIsVirtua1さんの質問）: 「信用すべきではないし、設計自体もそれを前提にしている」という回答。モデルは真実の情報源として扱われておらず、OBDの数値はそのまま素通しされ、マニュアルの回答にはページ引用が付き、未検証のものにはラベルが付く
- 「これは広告っぽい」という批判（lostrouterosさんのコメント）への対応方針: FAQの中で自らこの批判に触れたうえで、「このFAQをこのまま素っ気なく保つことで応えるべきだ」という開発者自身のメモが残されている
また、実際に音声で1問1答するまでにかかる時間についても、FAQには「発話・グラウンディングされた回答1回あたり、おおむね1.5〜4分（質問内容とキャビン内の温度による概算レンジ）」という、README本文のトークン/秒の数字だけでは分からない体感速度の記載があった。音声版の候補として、マルチモーダルなGemma 4 12Bもベンチされたが生成1.5 tok/sと遅すぎて不採用となり、記事執筆時点では「Ornith-1.5-35B-A3B」という別モデルがベンチ中だとFAQに記載されている。
リモートアクセスとGroupMind連携
自動車メーカーのクラウド経由のデータ（Mercedes me等）は自宅のHome Assistantインスタンス経由で読み込む設計になっている。走行中はPiが自宅ネットワークに到達できないため、READMEはTailscaleの利用を勧めている——PiとHome Assistantマシンが同じ暗号化メッシュに参加し、Piは安定したプライベートIPでHome Assistantに到達できる。自宅Wi-Fiをインターネットに晒すことも、サブスクリプションも、外部サービス経由のルーティングも不要という設計だ（なおOBDの読み取り自体はこの仕組みを必要とせず、車から直接取得される）。
CarWatchは「GroupMind」というルームにエージェントとして参加し、承認・返信はスマホや腕時計上の「CodeWatch」から行える。開発元ThinkOffAppは、腕時計上でエージェントを操作する「CodeWatch」、腕時計上で健康管理を行う「ClawWatch」という姉妹プロダクトも公開しており、CarWatchはこのファミリーの「車を見る」担当という位置づけだ。ライセンスはAGPL。
実車で再現して確かめたわけではない
- 本記事はThinkOffApp/CarWatchのGitHub README・Discussion #9・FAQ.mdを2026年8月29日にcurlで取得した内容にもとづく。実際にRaspberry Pi 5を用意し、Qwen3.6-35B-A3Bをロードして車載環境で動作を検証したわけではない
- 「3.5 tok/s」「65℃常用」「1.5〜4分/回答」という数値は開発者自身が自分の車（Mercedes E 300e）・自分のPiで計測したものであり、他の車種・気温環境での再現性は確認できていない
- ステータス表の「証明済み」というラベルは開発者自身の自己申告であり、第三者がREADMEの主張通りに動作することを検証したという記述はDiscussion内では見当たらなかった。「Strangers are now cloning this and pointing it at their own cars（見ず知らずの人がこれをクローンして自分の車に向け始めている）」という記述はあるが、その結果の報告までは本記事の確認範囲に見当たらなかった
- GroupMind・CodeWatch・ClawWatchという周辺プロダクトについても、CarWatchのREADME・FAQからのリンク先情報以上には裏取りしていない
- Zenn・Qiitaともに「CarWatch」という言葉での言及はゼロだった。Raspberry PiでローカルLLMを動かす記事自体は日本語圏にもあるが、「自動車のOBDとメーカークラウドの両方に接続し、完全オフラインで車をエージェント化する」という組み合わせはまだ紹介されていない
関連記事
出典・参照資料
AIニュースの解説を動画でも
YouTubeでは注目ニュースの背景を解説し、Xでは新着記事をお知らせしています。
コメント
まだコメントはありません。最初のコメントを書いてみませんか？
AIについて聞きたいことはありますか？
質問箱で無料で受け付けています。回答は公開され、他の方の参考にもなります。
質問箱を見る →新しい記事をメールで受け取る
AIの新しい発表を、出典付きで整理して届けます。
関連記事
巨大MoEモデルを「誰も全部持たない」まま動かす──P2Pスワーム推論エンジンLumabri
ローカルAIの画像生成は単体グラボなしでも動くのか──条件で見る判定
Macで動くモデルサイズの計算式──「コンテキスト窓が広い」の裏でVRAMが消えていく仕組み
DeepSeekはローカルで動かせるのか──パラメータ数とVRAM要件で判定する
gpt-ossをローカルで動かすと何ができるか──20Bと120Bの違いを整理する
OfflineでもParakeet TDT V3が使えるLinuxネイティブ音声入力ツール「hyprwhspr」
Unsloth Desktopの「Auto Compaction」──古い会話を消さずに検索可能なアーカイブへ逃がす設計
