ML Kit と Gemini Nano を使用して Android でフォーミュラ E のコ・ドライバーを構築する

お問い合わせいただきありがとうございます。

私の名前は Alastair です。本日は、昨年 Formula E と共同で実施したプロジェクトについてお話しできることを大変嬉しく思います。

本日は、Oli にも参加してもらい、私たちが共同で行ったことについて少し話してもらいます。

私は Google Cloud の CTO オフィスで働いており、モバイルとクラウドで現在可能なことの限界を押し広げ、それらを連携させる方法を模索しています。

短い動画で、私たちが取り組んだことを簡単にご紹介します。

第 4 世代の車は 600 kW のレーシング モンスターです。

完全な電力、常時全輪駆動。

とにかく速い。

車から送信されるテレメトリー データに接続された Google Pixel のエージェントを使用することはできますか？

ドライバーがグッドウッドの丘を登る際、実際に車と会話することができます。

これは良い方法です。

Gemma、タイヤの状態はどう？

タイヤの空気圧は 1.4 bar 前後で良好です。

ECU に直接接続されたスマートフォンがあり、ドライバーとしての私の行動に関する多くのデータポイントを読み取っています。

レーシングカーでこのようなことが起きたのは初めてです。

YouTube ほど、それを披露するのに適した場所はないと思います。

Gemma、準備はいい？

こちらは準備 OK です。

そこで、私たちは、コ・ドライバー エージェントをドライバーと一緒にコックピットに連れて行くことを試みるプロジェクトを立ち上げました。

そして、私たちがここでやろうとしているのは、エッジでのエージェントの可能性の限界を押し広げることです。これは、本当に難しい課題の好例です。

レーシングカーで直面する課題は、明らかに高熱です。

レーシングカーは熱くなることで有名で、それが最大の課題の一つです。

接続が不安定。

そこで、私たちはグッドウッド フェスティバル オブ スピードで実際にこれを行っています。このイベントには、何十万人ものモータースポーツ ファンが集まり、車が丘を駆け上がるレースを観戦します。

ご想像のとおり、1 つの場所に何十万人もの人が集まると、接続性が非常に難しくなります。

Bluetooth も同様です。

この車は基本的にファラデーケージのようなものなので、レーシング ドライバーのヘルメットに接続するだけでも、どのような課題があるか想像がつくでしょう。

最後に、低レイテンシの要件です。

このドライバーは時速 200 km 以上で走行しているため、コドライバー エージェントから得られる回答が非常に迅速かつ機敏であることが非常に重要です。

そして根本的に、私たちはこのことに非常に興味を持っています。なぜなら、エージェントはどこにでも存在するようになると考えているからです。

すでにその兆候が見られ始めています。

コンピュータの中だけではなく

スマートフォン、スマートウォッチ、スマートグラス、スマートホーム、そして今や自動車にも搭載されています。

そこで、このような困難なシナリオで何が達成できるかを根本的に確認したいと考えました。

これをどのように構築するかをブレインストーミングしていたとき、小さなアクセラレータを搭載した小さなマイクロコンピュータを構築して、そこにモデルを搭載するかどうかを検討しました。

必要な要素はすべてすでに存在していることに、私たちは突然気づきました。それが Android でした。

Android は、Google の Agent Developer Kit（ADK）を備えているため、この目的に最適なホストです。

これは、エージェントをアプリケーションに直接組み込むことができる、非常に優れたライブラリです。

数十億人のユーザーがいて、さまざまなフォーム ファクタで簡単に実行できるため、テストやコード自体の配布が非常に簡単です。

デベロッパー ツール。デバッグやさまざまなテストを行い、問題の原因を特定できます。

オンデバイス AI。Google Pixel スマートフォンには、スマートフォンに搭載されているオンデバイス モデル向けに最適化された TPU が搭載されており、ML Kit などの API を使用して、非常に強力なモデルに簡単にアクセスできます。

また、テキスト読み上げや音声認識などの完全にオフラインの API もあり、非常に強力な会話機能を実現できます。

そして最後に、当然ながら接続性です。

スマートフォンは、モバイル ネットワーク、Wi-Fi、その他の手段を問わず、接続性を重視して作られています。

しかし、課題の一つとして、エッジのエージェントはすべてを実行できるわけではないため、クラウドのエージェントとどのように連携するかが重要になります。

ハイブリッド ソリューションの場合はどうでしょうか。

スマートフォンに搭載されたエージェントが、クラウドのエージェントと直接会話して、より複雑なアクションを実行できるとしたらどうでしょうか。

たとえば、ドライバーが自分のレース順位を知りたいとします。

車自体はレースでの順位を把握できませんが、クラウド内のエージェントは把握できるかもしれません。

また、エージェント間プロトコルと呼ばれるプロトコルがあります。これにより、エッジとクラウドでエージェントを作成し、それらのエージェントが相互に通信して、より複雑なアクションを実行できます。

では、どのように構築したのでしょうか。

このシステムの構成要素について説明します。

ハーネスから始めます。

このハーネスは、基本的に Agent Developer Kit for Android を実行する Android アプリケーションです。

2 つ目の部分はモデルです。

それにはモデルが必要ですが、私たちは ML Kit を介して Gemini Nano を使用していました。これは、すぐに利用できる非常に強力なオンデバイス モデルです。

次に、データです。

これについては、オリが後ほど少し説明しますが、車からデータが送られてくるだけでなく、ドライバーの音声認識も行われる可能性があります。

最後に、エージェントが実行できるアクションもあります。

たとえば、テキスト読み上げ機能を使用してドライバーに返答し、フォローアップの質問をしたり、必要な情報を提供したりできます。また、前述のように、エージェント間通信を使用してクラウド内のエージェントと通信し、より複雑なアクションを実行することもできます。

それでは、Oli をステージに招いて、Formula E で実際にどのようにこれを行ったのかについて少し話してもらいたいと思います。

Alastair さん、ありがとうございました。

材料は揃いました。ここからが難しいところです。AI エージェントをフォーミュラ E カーに実際に統合するにはどうすればよいでしょうか。

まず、VCU（車両制御ユニット）から始まります。

現在、車両のすべてのセンサーとコンポーネントは、CAN バスと呼ばれるものを介して車両に報告します。

車は、速度、加速、スロットル、ブレーキなど、1 秒あたり数千ポイントのテレメトリーを生成しています。

このテレメトリーを読み取るために、Raspberry Pi を CAN 接続経由で車の VCU に直接接続することにしました。

Raspberry Pi は、いくつかの異なる処理を行います。

まず、未加工の信号をデコードして変換し、約 10 Hz にダウンサンプリングします。これは、コ・ドライバーにとって十分な情報です。

次に、Raspberry Pi は、この精製されたデータを MQTT 経由で車のコックピットにある Google Pixel 10 Pro にパブリッシュします。

これは、エージェント アプリケーションをホストするアプリが受け入れることができる入力の 1 つです。

2 つ目は Android の音声認識です。

そのため、ドライバーが話すと、アプリがその入力をテキストに変換し、Gemini Nano はこれら両方の入力を推論できます。

エージェントは 2 つの決定を下すことができます。1 つ目は、Android のテキスト読み上げエンジンを使用してドライバーに返答することです。

2 つ目は、Alastair が先ほど述べたように、A2A プロトコルを介してクラウド エージェントと通信できることです。

このエージェントのフローは非常にシンプルです。起動ワード（この場合は「Hey, Gemma」）を言って、質問すると、回答が返ってきます。

エージェントはその後約 5 秒間、聞き取りを続けます。そのため、実際のレース エンジニアと話すときのように、最初からやり直すことなく、続けて質問できます。

このアプリはマルチターン エージェントでもあります。つまり、会話履歴にアクセスして、より会話を自然にすることができます。

このコードは少し複雑に見えるかもしれません。

実は、とても簡単です。

最初の数行で、ML Kit を使用して onDeviceModel を呼び出し、Gemini Nano としてラップします。

val generativeModel: GenerativeModel = Generation.getClient()
val onDeviceModel = GenaiPrompt.create(
    generativeModel = generativeModel,
    name = "gemini-nano",
)
val agent = LlmAgent(
    name = "race_engineer",
    model = onDeviceModel,
    staticInstruction = /* System prompt */,
    instruction = Instruction {
        /* Dynamic context */
    },
    tools = listOf(
        /* Custom tools */
    )
)

次に、ADK を使用してエージェントを定義します。

名前と 2 種類の指示を指定します。1 つ目は静的な指示で、これはエージェントのパーソナリティとアイデンティティです。

これには、ドライバーへの応答方法やレーストラックに関する情報などが含まれます。

2 つ目は動的指示です。

この要約は、最新のテレメトリー要約とともにクエリごとに生成されるため、エージェントはドライバーがいつ何をしているかを常に把握できます。

前述のように、現在の会話履歴も含まれます。

さらに、いくつかのツールも定義します。たとえば、以前のセッション データに返信する機能、クラウド エージェントに返信する機能、テキスト読み上げを使用してドライバーに返信する機能などです。

では、Formula E のオフィスにあるシミュレーターでエージェントが動作する様子を簡単なデモで見てみましょう。

Gemma、私のステアリング操作はどれくらいアグレッシブ？

滑らかで落ち着いたトーン。

ピークロックは 48 度で、ハンドルを 1 秒あたり平均 11 度動かしていました。

Hey Gemma、私の最大 G フォースは？

コーナーでの最大 G フォースは 2.2 G でした。

Gemma、私のランニングはどうだった？

いい走りだったよ、ダン。

最高速度は時速 306 km、35 秒間の平均速度は時速 186 km。

全開走行の割合は 58% で、最大 G は 2.2 G でした。

ここまでです。

これは、スマートフォン上の Gemini Nano がドライバーと会話して、リアルタイムで質問に答えているところです。

シミュレーターとフォーミュラ E のマシンはまったくの別物です。

では、これらをどのように組み合わせたのでしょうか。

まず、私たちの車が製造されているパリの Spark Racing Technology に行く必要がありました。

左の写真では、私が Raspberry Pi を Formula E カーの実際の VCU に配線しています。

これまで構築したものはすべて、エミュレートされたデータで実行され、テスト セッションから再生されたため、実際に動作するかどうかはわかりませんでした。

そこで、デバイスを接続して電源を入れ、しばらく待つと、デバイスにテレメトリーが表示され始めました。データが想定どおりにシステムを移動していることが証明されたのです。

右側は完成したシステムです。スマートフォンが実際に運転席のすぐ横に設置されているのがわかります。

これで、グッドウッドの準備はすべて整いました。

では、当日は実際に何が起きたのでしょうか。

先ほど Alastair が説明した 4 つの課題を覚えていますか？

グッドウッドでは、そのうちの 2 つが本当に試されました。

1 つ目は熱です。

英国では、通常、晴れ以外の天候に備えます。

当然ながら、その週は記録的な猛暑となり、熱波の真っ只中でした。

フォーミュラ E カーにコンピュータを搭載するのに最適なタイミングです。

しかし、ここでひねりがあります。

スマートフォンは実際には問題ありませんでした。

Android はまったく影響を受けませんでした。

最も苦労したのは Raspberry Pi でした。

車に直接接続できなかったため、UPS と呼ばれるものを使用する必要がありました。これは、ご存じないかもしれませんが、基本的には Raspberry Pi の下部に多数のバッテリーが取り付けられているように見えます。

幸い、1 日を通して断続的に充電することでこの問題を解決できました。充電しなければ、AI エージェントなしで車が坂を上ることはできなかったでしょう。

次は Bluetooth です。

その時点では、Bluetooth 経由でアプリに接続するドライバーのヘルメットを使ったテストはまだ行っていませんでした。

そして、それは少し難しいことがわかっていました。

そこで、これをテストするために、私たちは芝生の上に座りました。とても楽しそうに見えますよね？

ノートパソコンを取り出して、楽しくおしゃべりしています。

実際には、これまでのキャリアの中で最もストレスの多い時期の一つでした。

私たちは、午後に車が丘を登る前に、コードをうまく動作させて Bluetooth ヘルメットをアプリに接続しようと必死になっていました。

しかし、直前のホットフィックスと Android の優れたデバッグツールのおかげで、なんとか間に合わせることができ、AI エージェントが正常に動作して車は坂を上ることができました。

では、Alastair に戻して、このプロジェクトから得られた教訓についてもう少し詳しく説明してもらいます。

よろしくお願いいたします。

ありがとう、Oli。

このプロジェクトから学んだことは何でしょうか？

1 つ目は、Android がエージェントにとって最適なホストであるということです。

Android の汎用性、利用可能な API、オンデバイス モデル、ADK をぜひ活用してください。

ぜひお試しください。このようなシンプルなことで、どれほど強力なエクスペリエンスが得られるかに驚かれることでしょう。

統合の難しさは依然として存在します。

この部屋にいるほとんどの人が、キャリアのどこかでこれを経験したことがあるでしょう。

すべてのサブコンポーネントを個別にビルドし、最後にそれらを接続すると、何かがうまく機能しません。

ドライバーのレーシング ヘルメットはまさにこれでした。

幸いにも、その日のうちに修正することができ、テストが依然として非常に重要であることが証明されました。

そして最後に、Gemini Nano です。

Gemini Nano はここで真価を発揮しました。

これは非常に効果的なモデルであり、デバイス上で非常に高速に動作し、非常に複雑なタスクを実行できますが、すぐに実行できるわけではありません。

その背後には、真の思考があります。

プロンプト エンジニアリングを行う必要があります。

テストする必要があります。

動的指示と静的指示をどのように提供するかを考える必要があります。

エージェントに提供するツールと、そのツールを使用するようエージェントに指示する最適な方法を考える必要があります。

しかし、適切なテストと評価を行えば、Gemini Nano のようなモデルをデバイス上で最大限に活用できます。

皆様、ありがとうございました。

後ほどブースにいますので、ぜひお越しいただき、ご質問ください。