車の警告灯の意味を知りたい、長距離の前に状態を確かめたい、取扱説明書の該当ページをすぐ開きたい。こうした小さな確認に、いつもクラウドのアプリや検索画面が必要とは限りません。公開プロジェクトのCarWatchは、Raspberry Pi 5と車両のOBDデータ、ローカルAIを組み合わせ、車を「会話できる端末」に近づけようとしています。
面白いのは、AIを車へ載せることそのものより、何を読ませ、何をさせないかまで設計している点です。CarWatchは取扱説明書や実際に読める車両データを根拠に答える方針を掲げます。一方、車種を問わずすぐ使える完成品ではなく、実証済み・構築済み・将来可能な機能を分けて公開しています。
CarWatchは、車を自動運転化するプロジェクトではありません。
駐車中や安全に停止した状態で、車が読める情報と取扱説明書をローカルで扱う試みです。便利そうな機能ほど、走行中に使わないこと、車種ごとの差を先に意識したいところです。
車の中に置くAIは、何を読むのか
CarWatchの公開リポジトリによると、参照構成はRaspberry Pi 5（16GB）、能動冷却、USBマイク、Bluetooth接続のELM327アダプター、ダッシュカムなどです。Piがローカルのモデルと音声処理を担い、OBD経由で回転数、冷却水温、速度、ハイブリッド残量、12V電圧、故障コードといった読み取りを扱います。
ここで大事なのは、画面に表示される数値を何でもAIへ渡せばよい、という話ではないことです。CarWatchは、車が実際に検知できるものだけを答え、取扱説明書にない内容は答えない方針を示しています。会話を自然にするために、見えていない故障原因まで推測させる設計とは距離があります。
AIの役は、整備士や車両そのものの代わりではありません。読める状態と取扱説明書を、確認しやすい言葉へ置き換える入口として見ると、CarWatchの狙いをつかみやすくなります。
取扱説明書を参照するから、答えに根拠を残せる
CarWatchのREADMEでは、開発者の実車に積んだ構成が489ページの取扱説明書をSDカード上の検索対象として持ち、ページ参照付きで回答する仕組みを説明しています。例えば黄色いタイヤ警告灯を尋ねたとき、一般論を長く返すのではなく、その車の説明書と実測値を照らす方向です。
ローカル処理の利点は、電波の弱いガレージやトンネルでも、音声入力、説明書の参照、ダッシュボード、状態の記録を動かせることにあります。ただし、これは開発者が公開した参照構成での説明です。自分の車の説明書、OBDで取れる項目、言語、音声認識の精度まで同じになるとは限りません。
試す前に確認したいのは、まず車種で使えるOBD項目と、説明書を安全に扱える範囲です。車載ネットワークへ書き込む用途ではなく、最初は読み取りと駐車中の確認に限る方が、失敗の切り分けもしやすくなります。
「オフライン」は、どこまでを指すのか
CarWatchは、音声応答、ローカルモデル、取扱説明書の検索、車内で開くダッシュボード、状態の追跡を、通信がない状況でも役立つ機能として分けています。メッセージや動画クリップを送れないときは、端末内のアウトボックスへ保存し、接続が戻ってから届ける構成も説明されています。
その一方で、遠隔からの到達、リポジトリからの更新、より大きなモデルへの切り替えには接続が関わります。メーカーのクラウド情報を読む構成も別の経路です。つまり「オフラインAI」という言葉だけで、すべての機能がネットワーク不要になると受け取るのは早すぎます。
通信がないときにも動く機能と、外部サービスへつなぐ機能は分けて考えてください。
遠隔操作や更新まで含めた利便性を急ぐと、アカウント、通信、鍵、権限の管理が増えます。車に残してよいデータと、外へ送る必要がある情報を先に決めることが重要です。
車のすぐ近くへ必要な情報を出すという発想は、配達用スマートグラスの記事にも通じます。使う人の視界や手元に支援を置けるからこそ、いつ表示し、誰が確認するかを運用として決める必要があります。
できることと、できないことを同じ列に並べない
CarWatchはREADMEの中で、機能を `proven`、`built`、`enabled` と区別しています。取扱説明書へのページ参照、音声応答、OBDの読み取り、いくつかの車両状態の取得などは、開発者が実車で確認したものとして示されています。一方、到着通知やダッシュカム連携などには、実装済みでも車への接続はこれからという項目があります。
さらに、安全に関わる境界も明記されています。プロジェクトが実車で例示するのはドアロックや窓を閉じる操作で、解錠、窓を開ける操作、エンジン始動は意図的に実装しないとされています。機能表に書かれた「可能」と、日常で安心して任せられることは別です。
AIが答えを出しても、警告灯の対応、整備判断、走行の可否は人が決める領域です。説明書の案内、車両メーカーの注意、必要なら整備工場の判断を優先し、運転中に画面や音声操作へ注意を奪われない使い方を選びましょう。
車載AIを「全部つなぐ」前に、小さく確かめる
CarWatchが示す魅力は、既存の車を一気に未来の乗り物へ変えることではありません。まずは自分の車が読めるデータを知り、説明書のどこまでを参照させ、通信が切れたとき何が残るのかを見える形にすることです。
Raspberry Pi 5で35B級のモデルを動かす構成や、音声・OBD・説明書検索を一つにする設計は、後付けの車載AIがどこまで具体化しているかをよく表しています。ただし、参照実装は2021年式Mercedes E 300eを含む開発環境が中心です。部品をそろえる前に、車種の互換性、保証、電源・設置の安全、データの扱いを確認する方が、AIの回答を増やすより先の一歩になります。
CarWatchは、車へ何でも任せるための近道ではなく、車が確かに読める情報だけを人へ返すための実験です。便利さを増やすほど、止める線もはっきりさせる。その姿勢こそが、車の近くでAIを使うときの価値になりそうです。
