GMが400万台にGeminiを載せてきた話と、自分が考えること

GMが約400万台の車にGoogleのGeminiを載せると発表した。
キャデラック、シボレー、ビュイック、GMCの2022年モデル以降が対象で、OTA（Over-the-Air）アップデートで数ヶ月かけて順次展開されるらしい。
GMはこれを「業界最大規模のGeminiデプロイのひとつ」と表現している。

正直、最初この記事を見たとき「車か、自分には関係ないな」と思いかけた。
でも少し読み進めていくうちに、視点が変わってきた。

OTAでLLMを400万台に届けるというスケール感

ソフトウェアエンジニアとして気になったのは「どうデプロイしているか」の部分だ。
インフォテインメントシステムへのOTAアップデートでGeminiを展開するというのは、単純に技術的な難易度が高い。
ユーザーごとに異なるネットワーク環境、古いファームウェアとの互換性、ロールバックの設計…自分がやったら確実に詰まるポイントが山積みだ。

自分がLLMのAPIを自分のアプリに組み込むとき、まずつまずくのはレイテンシとコストだ。
GeminiのAPIを直接叩く場合、トークン数の管理をちゃんとしないとすぐコストが膨らむ。
GMのケースだと400万台から同時にリクエストが飛ぶ可能性があるわけで、バックエンドのスケーリング設計はどうなっているのか純粋に興味が湧く。

「コマンドを覚えなくていい」UIの設計哲学

GMのアナウンスで「特定のコマンドを暗記しなくてもいい、より自然な会話体験」という表現があった。
これ、自分がLLMを使ったUI設計を考えるときに毎回ぶつかるテーマとまったく同じだ。

ユーザーに何かを「覚えさせる」インターフェースは、思っているより摩擦が大きい。
自分の個人開発でもチャット形式のUIを作ったとき、プロンプトをどこまでシステム側で吸収するかの設計で相当悩んだ。
Geminiが「よりスマートで直感的」と言われているのは、モデル性能だけでなくシステムプロンプト側の設計も相当作り込まれているはずだ。

ここで自分がいま実装でやっていることを少し整理すると、

• ユーザー入力をそのままAPIに流さず、前処理でインテント分類を挟む
• 会話履歴をどの範囲でコンテキストに含めるか動的に調整してトークンを節約する
• 曖昧な入力には確認を返すのではなく、最も確率の高い解釈で処理してフィードバックを求める

この辺りはGMの車のユースケースとほぼ構造が同じだと思う。
ドライバーが「次の音楽かけて」と言ったとき、曖昧さを処理するロジックをどう書くか。
自分のコードで解いている問題と地続きだと感じた。

Super Cruiseの10億マイルと、積み上げることの意味

GMはこの発表と同時に、Super Cruise搭載車両でのハンズフリー走行距離が10億マイルを超えたとも報告している。
約75万台のユーザーが積み上げた数字だ。

これを見て思ったのは、LLMの本当の強化ってオフラインのデータの積み上げで起きるということだ。
車のアシスタントも、実際の使われ方のデータが増えるほどシステムプロンプトやファインチューニングに反映できる。
APIを叩いて「動いた」で終わるのと、デプロイ後のフィードバックループを設計するのとでは全然違う。

自分のアプリでもログをちゃんと取って、どこでユーザーが離脱しているかを追う仕組みを先に作っておくべきだと、この記事を読んで改めて思った。
来週、まずロギングのパイプラインを整理するところから手をつけるつもりだ。