またお会いできて嬉しいです
前回の投稿からすぐの投稿となりました。NissanのQiita、ニキータの娘1です。前回はE2E自動運転の内容を紹介しましたね。E2E自動運転は自動車xAIの筆頭かと思いますが、近い将来このE2E自動運転に乗り込んでいる風景をちょっと思い描いてみてください。おそらく最初は皆さん、
「おぉ！運転席に誰もいないのに走ってる！」
「誰もハンドル持ってないのに動いてる！」
と感嘆の嵐かと思いますが、20分程乗った後はどうでしょう？ほとんどの方がスマホ操作し出すのは想像に難くないかと思います。そこで私たちは、E2E自動運転に乗っている時間を楽しくするUI/UXの検討もしていますので、今回はそのひとつAIラジオシミュレータ”YAGURA・R（仮称：妖怪のように「ヤグラー」と呼んでください）”をご紹介いたします。
AIラジオシミュレータ”YAGURA・R”
”YAGURA・R”は、実は2025年7月2～4日に東京ビッグサイトで開催された自治体・公共Weekで一般展示（B2Bではありますが）デビュー済みでして、もしかしたら読者の皆さんの中でお越し頂いた方もいらっしゃるかもしれません。
ご参考）
自治体・公共Week
https://www.publicweek.jp/ja-jp.html
Moplus
※日産自動車と三菱商事の合弁会社で、”YAGURA・R”はここのブースでデビューしました
https://www.moplus.co.jp/
この”YAGURA・R”は、何をするものかというと、まず地域で走るモビリティサービスの中で流れるラジオ番組があります。このラジオはモビリティサービスが走るルートに合わせて毎回違った番組を流します。そんなことができるのは生成AIのおかげですね。どやってラジオ番組を生成しているかはまた別の記事で書くことにします。
そんな生成ラジオを載せたモビリティサービスが自分の街で走っていたらどんな番組が流れるんだろう？それを疑似体験できるのがこの”YAGURA・R”なわけです。日本（あるいは世界の）任意の地域を指定すると観光地を結んだルートとそのラジオが生成されます。ただ”YAGURA・R”ではラジオを耳から聴くだけでなく、モビリティサービス車両からのストリートビュー、衛星映像を使ったバードビュー、そして地図の上を動くモビリティ車両の3つのビューが連動して魅せてくれます。そしてこの動くモビリティ車両こそがミニカー、つまりtoioなわけです。
自分の街をモビリティサービス車両に見立ててミニカーが走るのを眺めながらラジオを聴くとまるで本当にモビリティサービスが始まっているような体験ができる、それが”YAGURA・R”の魅力です。
写真は自治体・公共Weekでの様子で、説明員は私達日産のモビリティ・AI研究所のメンバーです。自治体・公共Weekでは、本当にたくさんの来場者の皆さんに体験頂き、
「どんな場所でもシミュレートできてすごい！面白い！」
「このシステムをすぐにでも採用したい！」
と大好評でした。しかもこの”YAGURA・R”、実は製作期間約1か月で、AIを使ってプログラムを作成するバイブコーディングを駆使した大傑作です。このバイブコーディングについては、そのうちここでお話することになると思いますが、今回は”YAGURA・R”のハードシステムについてご紹介します。
”YAGURA・R”は、任意の地域の任意のPOIを選択すると、モビリティサービスのルートとGPSデータが生成され、そのGPSデータと連動して、プロジェクターから表示されたマップ上をミニカーが動く＆そのPOIに関するAIラジオが流れるシステムです。その構成は大きく３つに分かれています。
①好きな地域やPOIを選択できるUI部
②選んだPOIを結ぶルート上を走るミニカー部
③ルートに沿って話すAIラジオ部
今回は①と②について解説していきたいと思います。
好きな地域やPOIを選択できるUI部
今回はデモ用システムでしたので、基本は私達説明員が操作しました。そう聞くとUIのユーザビリティは二の次と思われがちですが、そうではありません。特に今回のようにいち日に何十回と操作する場合、デモ用とは言えユーザビリティを考えたUIにしておかないと、来場者の前でミスを連発し、デモ用システムで伝えたいことが十分に伝わらない可能性があります。そこで、今回は特に「誰が何回操作しても操作できる」UIを目指しました。
最初はGoogle等のネット検索のように「地域＋ジャンル」を入力して出てくるPOIを選択できるように、と考えていました。しかし、このジャンルが曲者で、Google mapのAPIをFunction callingして出てくるPOIと、想像していたPOIが乖離していることがよくありました。例えばジャンルで”レストラン”を選択した場合、美味しいラーメン屋さんや地域の特産物が食べられる和食屋さんなどが出てくると予想しますよね？しかし、ホテルや旅館の中にある小さな食堂も出てきてしまい、本当に行きたいPOIを選択するのが困難な状況でした。これは、Google mapのPOIに予め登録されているカテゴリーが広範囲すぎたためで、PythonのコードにPOIの名前の中に”ホテル”、”Hotel”、”旅館”が入っている場合は検索結果に出さないルールベースの処理を追加することで対策しました。
他にも、ジャンルで”観光地”を選択した時、横浜の山下公園のように有名な観光地公園が出てくるようにと、当初はGoogle mapのPOIカテゴリー”park”も入れていました。しかし、そうすると団地などにある小さな公園まで出てきてしまったため、カテゴリーから”park”を削除しました（秘密のデートルートを作成したい時には必要かもしれませんが♡）。
また、一番頭を悩ませたのは”歴史”のジャンルでして、最初は一般もマニア受けもすること間違い無し！と”歴史”がジャンルに入っていました。地域のお寺やお城が出てくると思っていたので、
「鎌倉の歴史を巡るオートクルーズに出発しましょう！源頼朝の存在を感じる旅になりそうですね♪」
「京都の歴史探索、ワクワクしますね☆ 小野小町の花の色は～なんて声が聴こえてくるかも？！」
と快調なAIラジオを期待していましたが、Google mapのPOIカテゴリー”histrical_landmark”を使用すると、なんと銀行や工場のPOIまで出てきてしまうのです。もちろん歴史的な銀行や工場はありますが、鎌倉を訪れるお客様が”歴史”と聞いて工場や銀行に行きたい、とはあまり思わないでしょう。。削除する工場や銀行リストを作り、前述のようにPythonにルールベースのコードを追加することも検討しましたが、今回は任意の地域なので、膨大な削除リスト作成は現実的ではないと判断し、泣く泣くジャンルから"歴史”を無くし、代わりに”観光地”と”自然”のジャンルにしました。図はUIの一部で、この泣きの結果が見えるかと思います。
最後に、操作UI部については、文字入力を極力減らし、タップタップタップ×n回操作で最後まで操作できるようなUIフレームとし、操作の負担とミスをなるべく減らしました（実は、北海道を選ぶと次のページで64個の郡名が出てきてたのですが、スクロールが大変なのと、絶対探し出せないので、ここは文字入力にしたりしています）。
開発者曰く、「今回のように操作性と品質を担保するためには、大量のテストをしてバグ出し＆対策のループを何周も回す必要がある」とのことです。その甲斐あり、本番の3日間で操作UIのエラーはほぼありませんでした。バイブコーディング等でプログラムが簡単に書けるようになっても、最後の完成度を高めるのは、人間のプロフェッショナルな目ということですね。
選んだPOIを結ぶルート上を走るミニカー部
私達の最近の研究では、もしこの世にディスプレイがなかったらどんなUIが実現できるだろう、という研究をやっています。あえてディスプレイが存在しないという制約を設けることで新しいUIを発明できないか、というチャレンジです。ようは、私達はディスプレイ【ではない】物体で、わかりやすく愛着のわきやすいUIを目指しています。”YAGURA・R”もストリートビューを表示するためのディスプレイはありますが、これがなくてもルート上を走っていることがわかる手段として、プロジェクターで投影したマップとルートの上をモビリティサービスのミニカーが走ります。このミニカー、前の記事のE2E自動運転実験車両のミニ版なんですよ！可愛いですよね！
そしてこのミニカー、どうやって動いているかわかりますか？デモ体験した方々からは、
「え？！下から磁石で動かしてるんでしょ？」
「こんな小さい（4cm立方くらい）のにどうやって動いているの？？」
等の質問がよく出ますが、そうです！ご存じの方は写真からわかると思いますが、Sony Interactive Entertainmentさんのキューブ型ロボットトイ・toio（トイオ）を使わせて頂いております。
ご参考）
小さなキューブ型ロボットトイ・toio（トイオ）
https://toio.io/
今回のミニカーは、任意の地域の任意のPOIを結んだルートを走行するため、無線通信可能でサイズが小さい必要がありました。開発者皆で何かないか。。と考えていた時に、ひとりのアイディアマンが「以前姪っ子にプレゼントしたプログラム学習用ミニカーが使えそう？！」と思い出してくれたのが、このtoioです。
toioは3×3×2.5cmくらいのサイズで、底面の光学センサーで、toio専用マットに印刷されているマイクロドット（肉眼ではほとんど見えません）を読み取ることでx座標とy座標、角度がわかります。このサイズでモータ２つとギア、バッテリー、光学センサー、通信用チップ等全ての部品が入ってるんです！すごいですよね！！さて、これで道具は揃いましたが、ご想像の通り？toioを用いてシステムを構築する、ここからが本番です。
まずはデータ通信方法について。今回のシステムは、GPSデータとtoioマット上の座標を対応させ、その座標を基にtoioを動かします。これだけでしたら、PCとtoioをBluetooth（BLE）で通信するだけで動作可能です。しかし、今回は操作UIで選択したPOIからGPSデータを生成し、さらにそのGPSデータからストリートビューやAIラジオを生成再生するので、複数のPCやデバイス間で遅延なくデータ通信する必要があります。そこで、今回は軽量かつ効率的なMQTTを使用しました。MQTTを使用することで、複数のPCやデバイス間で遅延なくデータ通信ももちろんできますが、システムをネット上に置きどこからでも操作できるようにすることも可能です。また、この通信システムを使えば、モビリティサービスの車とミニカーが連動して動く、なんてことも可能だったりします。
次にtoioマット上を不具合なく動作させるための工夫をご紹介します。toioが動けるtoioマットは、A4サイズとA3サイズのものがあり、A3サイズのtoioマットは、最大12枚（4×3）繋げて約1.2m×1.2mの絶対座標をもつマットとして使用可能です。今回は”YAGURA・R”のサイズに合わせて、A3サイズのtoioマットを2×2枚繋げて（x座標，y座標がx=34、y=35～x=644、y=466）使用することとしました。しかし、実際走らせてみると、toioのIdInformationがnot a numberで自分の位置を見失ってしまい停止してしまうことがありました。色々確認したところ、どうもマット間の隙間等で、光学センサーの読み取りがうまくいかない事象が発生しているようでした。そこで、toioのIdInformationがnot a numberになった時は、0.1秒ずつtoioのモータを動かし座標を取得するプログラムを追加しました。
if cube1.air: # ID information of Toio is NaN
await cube1.api.motor.motor_control(10, 10)
await asyncio.sleep(0.1)
await cube1.api.motor.motor_control(0, 0)
また、設定した座標以外の座標を間違えてマットから読み取ってしまうこともありました（例えばx=1600、y=600）。すると、toioがその座標目指して爆走しようとするので、その場合動かないようにするプログラムも追加しました。
if X < 1500 and X >0 and Y <500 and Y > 0 and cube1.reached_to_target == False:
await cube1.cubeMoveTo(X,Y,20)
最後に、GPSデータと連動してtoioを動かす時の工夫をご紹介します。toioに出す指示は、基本的に「x座標〇〇、y座標△△へ、速度◇◇で行け」となりますが、今回のシステムでは各POIでAIラジオがしゃべるので、POI周辺に留まる時間を長く、それ以外ではむしろ次のPOIに急いで行く必要があります（実車両の速度に換算すると、超高速で走ることになりますが、それは今回はシミュレータということで）。そこで、今回はtoioに随時送る目的地座標間距離を自動調整することで、この課題を解決しました。
toioに送った目的地座標と、随時光学センサでマットから読み取った座標から距離を算出し、その距離が5mm以上だったら目的地座標に移動し、その距離が5mm以下だったら今の場所に留まるシステムなので、目的地座標間が短いエリアでは留まる時間が増えAIラジオのおしゃべりをゆっくり聞くことができます。この5mmも最初は10mmでやってみて留まる時間が足りなかったり、1mmで試してみて隣の目的座標と干渉してしまったりと、try and errorで調整しました。また、次の目的地座標が遠すぎる時はtoioの速度を2倍にしたり、その速度も一気に上げるとtoioが転がってしまうので加速度を調整したりと、既製品で安定して動くモノでも、その使い方を色々と工夫する必要があることを身をもって体験した次第です。
最後に開発者に感想を聞いたところ、「今回は時間も無かったので、toioの左右モータを同じ速度にし直線でしか動いていないが、本当だったら道のカーブに沿って走れるように左右のタイヤ速度差まで考えたシステムにしたかった（カーブのRと左右タイヤ速度差計算式が激ムズ）」「今回は1点から1点へ一歩ずつカクカク進んでいるが、2点の目的地座標データから計算しdelayを入れることでもっとなめらかに走れるはず」等、今後のVer.UPが期待できそうな頼もしい感想がたくさん出てきました。そして、「今回は既に定義されたFunctionしか使わなかったのでできることが限られていたが、もっと勉強して時間をかけたらもっと色んなことができそう！」とのことでした。開発者が「もっともっと」と思えるシステム、素敵ですね♪
おわりに
さて、今回はUI/UX研究のひとつAIラジオシミュレータ”YAGURA・R”についてご紹介しました。このように書き出してみると、工夫や苦労したところがたくさんあることを思い出しました。また、今回の”YAGURA・R”でも、”YAGURA・R”以外でも、まだまだほかのUI/UX検討もしているので、次もお楽しみに！