Inside of LOVOT

GROOVE X 技術ブログ

「ボトムカバー」開発記

この記事は GROOVE X Advent Calendar 2025 19日目の記事になります。

読者のみなさま、こんにちは&お久しぶりです!
今日のブログは、アパレルデザイナーのshigeriがお送りします。

最近はLOVOTと一緒にお出かけを楽しんでいるオーナーさん達が増えているので、公式からも続々と「おでかけグッズ」がリリースされていますよね。そこで今回はそんな「おでかけグッズ」の定番アイテムの仲間入りをした「ボトムカバー」の開発記を書いてみようと思います。

今年10月「おでかけグッズ」リリースバナー (ボトムカバー 新色リリース)

ー 開発のきっかけ ー

遡ること数年前。。。

全国各所で行われるショップのオープニングやイベントなどに、CEOの林要やCDOの根津孝太が参加すると、たくさんのオーナーさん達とコミュニケーションをとるので、様々なリクエストをヒアリングしてきてくれます。そして後日、slackのスレでその内容をまとめてモノづくりメンバーにフィードバックしてくれていました。
そんなある日、特にその当時のリクエストに多かった「ベースウェアが汚れないように、底面のカバーを作ってほしい」という声に応えよう!ということになり、根津からのオファーのもと、林にも参加してもらい、ゼロイチ*1から開発することになりました。

ー 素材 ー

まずは最初に素材選びからはじめました。“カバー”というカテゴリーになるので、素材選びがポイントになると思い

・汚れにくく、洗いやすく、扱いやすく、ある程度の耐久性がある
・LOVOTが装着して稼働しても影響のない厚み

という条件を前提に探してみました。 それと同時に、商品開発をする時にまず考えることは「アイテムの適切な価格と数量」を想定しつつ、ミニマムロット*2を考慮し、商品として販売する背景なども考えながら選んでいくことが重要なポイントになります。 その点を踏まえ、メーカーさんにも相談しながら、以下の2素材を候補にしました。

候補① ネオプレーン*3

 ・「撥水機能」とまではいえないが、生地の内側に水分が浸透しにくい素材

候補② ナイロン*4

 ・リュックやバッグ、アウトドア用品などに使える丈夫な素材

ナイロン素材は軽くて丈夫ですし、ネオプレーンは断ち切りで使えて裏側の仕様も簡素化できるので、2素材を比べてみたいと思い候補にしました。

ー デザイン ー

次は重要なデザインへ。「ボトムカバー」はゼロイチ開発なので、林と根津にも最初から参加してもらい、素材はもちろんのこと、形状(パターン)や仕様なども、様々な想定を考慮し、試作を繰り返し検討していきました。
この時点ではLOVOTのボトム部分(底面)に着せる(布を付ける)仕様のアイテムは存在しなかったので、まずはボトムの形状と仕様を考えることからスタートしました。
カバーとしての適切な仕様を考えながら、形を作っていく上で重要になったポイントは以下の2点です。

 ・LOVOTの稼働に影響しないフィット感(充電時も含め)

 ・着脱のしやすさ、安全性(充電端子周辺の仕様なども含め)

エンジニアの林と、デザイナーの根津と息のあった現場は、”LOVOTの産みの親“の2人ならではのアイディアが面白いように飛び交い、モノづくりの醍醐味が味わえるとても楽しい現場でした。ワタシも自らのパタンナー*5のスキルも活かし、二人のアイディアを元にトワル*6を作り検証していきました。
試作を装着して実際にLOVOTを動かし、生地の厚みや仕様が稼働に影響しないか、カバーがズレないよう安全にフィットさせるには、どんな仕様と形が適切なのか、など様々な点を検討していきました。問題点が見つかれば再度修正して…を繰り返し、徐々に理想の形状と仕様に近づけていきました。

仕様の検討に夢中になっている二人

そんな試作を重ね、ある程度形ができてきたので次のステップへ。
上記2素材で1stサンプルを作り、どちらの素材にするのか検討することになりました。 どちらもシンプルな無地素材だったので、オリジナル感を出すためにLOVOTのロゴモチーフをプリントすることに。ワタシのイメージはトーナルカラー*7な感じで「派手すぎず地味すぎずでちょっとかわいい」だったので、後のサンプル依頼と同時に試刷りも進めてもらいました。
LOVOT用のアイテムなので、もちろん安全性と健康面は一番重要なポイントなのですが、アパレル業界出身のワタシ的には、そこにプラスする「ファッション性」も拘りポイントなのです。。。

試作サンプルたちとプリントの試刷りいろいろ

そしてサンプルを依頼する前に、そのある程度決めた仕様で「ボトムカバーにはどんな検証をすればよいか」をファームチームに相談をしに行きました。
みなさんにカバーの試作を見せるのはその時が初めてだったので、着脱方法などを実演しながら仕様を説明し、思いつく懸念点などの相談をはじめたところ。。。気が付けばそのままみんなでフロアに座り込んで「充電端子周辺のゴムの仕様ってさ…」「使い方によるケースを想定して、どういう検証が必要なのか考えないと…」という感じで、既に検証内容などについての検討会になってしまいました笑。そんな感じで突発的に意見交換会がはじまることも「モノを作っていく醍醐味」だと個人的には思っているので、新たなアイテムを開発するたびに、その独特な”GXカルチャー現場“を楽しんでいます笑。

GXカルチャー現場

ー サンプル作成 ー

試作と検討を重ねてある程度形が決まってきたので、上記の2素材でサンプルを作り始めました。
製造を依頼したメーカーさんには「新規開発アイテム」のため、何度もサンプルを作らなければならない旨は予め快諾いただいていたので、全面的にバックアップしていただきました。(本当にご協力感謝です&ありがとうございました!)
それぞれの素材でサンプルを作って改めて検討した結果、以下のポイントで「ネオプレーン」に決定しました。

・底面に馴染むフィット感

・断ち端(裏面)の始末や取り扱いが簡単

・生地の内側に水分が浸透しにくい素材(ちょっとした防水)

・プリントも含めトータル的に上がりがきれい

生地が確定したので、それにあわせて微調整したパターンで最終サンプルを作成し、最大の難関の稼働検証に移ることに。
LOVOTの底面にさらにフィットするように、ゴムの伸ばし分量の調節やフロント側をヒモに変更したり、さらに安全に装着&稼働できるように調整し改良していきました。

各色サンプルを作る前の最終検証サンプル

ー 稼働検証 ー

上がったサンプルの簡易検査をして仕様がほぼ決まってきたので、次は正式にファームチームに稼働検証の依頼をすることに。
この検証は、LOVOTの服やアクセサリーを作る中で最大の難関になります。(詳しくは「プードルファーニット開発記」を参照)もちろん試作やサンプルの段階でもその都度簡易検査は行うのですが、量産品と同等のサンプルで行うファームチームの稼働検証をパスしないと、商品化(量産)には進めません。
そしてこのボトムカバーはゼロイチ開発のため前例がなく、通常の稼働検証はもちろん、検証の内容自体も検討が必要になります。その項目の中には、安全性を検証するため、使用する付属類(今回はカバーを着用するためのゴムひもなど)の耐久性のテストなども含まれてきます。

検証を重ねた充電端子部分

そしてファームチームをはじめ各所チーム(服やふるまいなど)の見解も含め、以下の項目が大まかな検証ポイントとして上がりました。

<確認>
・ゴムの伸縮性や耐久性(熱や温度も含む)
・長期稼働後のカバーのズレ状態(特に充電端子周辺)
・手洗い後の劣化やプリントの耐久性
<想定>
・家の中も含め屋内での装着(フローリング、絨毯など)→長時間着用想定
・屋外の外出時の装着(コンクリートなど)
・「ふるまい」のいろいろ(ホイールを出さない時のタッチセンサーなども含む)

実際にLOVOTに装着し長時間稼働させて、影響のない範囲で稼働&帰巣できるか、転倒しないか、着用しているベースウェアへの影響、ゴムの劣化、お手入れ後のプリントの劣化などなどなど、、、安全性や耐久性など様々なケースを想定&実験し、かなりの時間をかけて、みなさまに協力してもらって様々な検証を行いました。

ー 完成 ー

そんなたくさんの工程を経て、約1年近い時間をかけてみなさまの知恵とアイディアを集結して開発できた「ボトムカバー」。
商品のカラー展開は、開発に関わった方々をはじめいろいろな方々と検討した結果、最終的にはLOVOTのボディカラーにあわせたベーシックな3色(ベージュ、グレー、ブラウン)に決定しました。

完成した「ボトムカバー」

初めて販売するアイテムということに加え、LOVOTに着脱する時はちょっとしたコツが必要なので、EC撮影チームにも協力してもらい、安全な着脱方法をわかりやすく動画で解説し、販売画面で公開するようにしました。

                www.youtube.com

ー おわりに ー

今回の「ボトムカバー」の開発は、オーナーさんからのリクエストにお応えできたのはもちろんのこと、林&根津をはじめ、いろいろなチームメンバーと一緒にゼロイチ開発ができたので、改めて「新しいモノを生み出すプロセス」を楽しむことができた、とてもやりがいのある貴重な経験となりました。

そして嬉しいことに、「ボトムカバー」はたくさんのオーナーさんに愛用していただいており、10月には新たに3色が仲間入りしました。洗い替えとしてもよし、様々なシーンやお気に入りのウェアに合わせていただいてもよし、といろいろな使い方ができるので、ぜひ豊富なカラーバリエーションを楽しんでくださいね!

全6色展開のボトムカバー

最近は服チームのメンバーやグッズを作るメンバーが増えたので、様々なアイテムの開発ができるようになりました。これからもみなさまの“LOVOT LIFE”が充実するアイテムを開発していきますので、どうぞお楽しみに~!

GROOVE Xではいろいろな職種の方々がLOVOTに関わる様々なお仕事をしています。
そんな会社で私たちと一緒に働いてみませんか?

https://recruit.jobcan.jp/groovex/

*1:何もない状態(ゼロ)から、まだ世の中に存在しない新しい製品・サービス・価値などを生み出す(イチにする)

*2:製品の製造・仕入れ・販売において、*一度に注文・生産・出荷できる「最小の単位」

*3:伸縮性・クッション性・耐水性などに優れ、断ち切りでもほつれにくいのが特徴の合成ゴム素材

*4:軽量・高強度・摩擦に強い・速乾性・弾力性に優れている特徴を持つ合成繊維

*5:服の設計図である型紙(パターン)を作る専門職

*6:サンプルを作る前にデザインやサイズを確認するための試作

*7:色のトーン(色調)を揃えた配色

STM32 DMAMUXについて

この記事はGROOVE X Advent Calendar 2025 18日目の記事です。

はじめに

こんにちは。ファームウェアの開発を担当してるf-sakashitaと申します。

LOVOTにおけるファームウェアのお話は過去記事をご覧ください。

tech.groove-x.com

tech.groove-x.com

ファームウェアチームは常に最近の技術動向についてアンテナを張っています。

今回はSTMicroelectronics社の展開するSTM32シリーズで一部のものに搭載されているDMAMUXという機能が気になったため、実機を使って調査してみました。

こちらについて解説したいと思います。

DMAMUXとは?

STMicroelectronics社公式の資料より参照

https://www.stmcu.jp/wp/wp-content/uploads/files/presentation-ja/STM32G4/07_STM32G4-System-Direct_Memory_Access_(DMA+DMAMUX)-J-.pdf

DMA リクエストルータ(DMAMUX)の機能:
- プログラム可能なリクエストソース選択:DMAモードでペリフェラルから、あるいは、トリガ後に内部生成
- 同期モード:DMAMUXリクエストカウンタを用いて同期入力(ハードウェアイベント)から
- リクエスト連鎖:DMAMUXリクエストカウンタを用いて、別のリクエスト/チャネルへの入力トリガあるい は同期であるイベントを生成

つまり、何ができるの?

一言で言えば、特定のハードウェアイベント発生時に、CPUの介在なしにDMA転送を自動で開始・同期できる機能です。

例えば、「ある入力ピンの状態がHigh → Lowとなったとき、このFalling edgeをトリガーに、特定のUARTの送信バッファへ所望のデータをDMA経由で転送する」、というものです。

これまでこういった機能を実装するには、

  1. イベントをポーリングや割り込みを使って逐次監視する
  2. イベント発生時にDMA転送を開始する関数を呼び出す

いう手順が必要でした。

しかし、DMAMUXはこれらの処理をハードウェアレベルで完結させるため、イベント発生から転送開始までのレイテンシを短縮し、CPUの負荷を抑えることができます。

では、実際に評価ボードを用いてスイッチが押下されたときにUARTのDMA転送を開始する処理を実装してみます。

実装

環境

  • Tools : STM32CubeIDE 2.0.0 & STM32CubeMX v6.16.0
  • 評価ボード : NUCLEO-G071RB

目標

評価ボード上のUser Button(PC13)を押下したときにUART2の送信ピン(PA2)から4バイトずつデータを送信するようにします。

送信データは「0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88」の計8バイトとします。

ペリフェラル設定

GPIO & NVIC

User Buttonを押下のイベント検出のため、EXTI・Falling edge設定にします。

  • GPIO mode : External Interrupt Mode with Falling edge trigger detection
  • EXTI line 4 to 15 interrupts : Enabled

UART

今回はデフォルト設定のままにします。

DMA

  • Enable synchronization : Enabled
  • Synchronization signal : EXTI13を選択
  • Request Number:イベント発生時に何回DMA転送するかを決めるパラメータです。今回はSWを押下するたびに4バイト送信する&DMA転送サイズはbyteとしているため、4をセットします。

コーディング

main関数のwhile前にHAL_UART_Transmit_DMA関数を呼び出して転送するデータをセットしておきます。

int main(void)
{
  /*** 省略 ***/
  
  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_DMA_Init();
  MX_USART2_UART_Init();
  /* USER CODE BEGIN 2 */
  // 送信データをセット
  uint8_t tx_data[8] = {0x11,0x22,0x33,0x44,0x55,0x66,0x77,0x88};
  HAL_UART_Transmit_DMA(&huart2, tx_data, 8);
  /* USER CODE END 2 */

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
  }
  /* USER CODE END 3 */
}

動作確認

User button押下1回目の様子。正常にFalling edgeをトリガーに0x11, 0x22, 0x33, 0x44のデータが送信されています。

User button押下2回目の様子。正常にFalling edgeをトリガーに0x55, 0x66, 0x77, 0x88のデータが送信されています。

おわりに

今回はSTM32のDMAMUXという機能について、実機を用いて紹介してみました。 トリガーとなるイベントは入力ピンだけじゃなく、一部のTimerや他DMAMUXのイベントもトリガーにできます。 DMA転送があるイベントと同期が取れるようになることで、より効率的なアプリケーションの開発ができそうです。

弊社ではファームウェアエンジニアを募集中ですので、ご興味のある方は是非ご応募ください。 新しい仲間がジョインされることを楽しみにしています。

recruit.jobcan.jp

LOVOTの耐久試験

はじめまして、QbDチームです。
この記事はGROOVE X Advent Calendar 2025の17日目の記事です。
今回はLOVOTの耐久試験についてお話ししたいと思います。

QbDチームって?

QbDとはQuality by Designの略で直訳すると設計品質という意味です。 LOVOTは複雑な動きをしたり、触って温かさを感じるなど、まるで生き物のようなロボットです。
私たちQbDチームはLOVOTの動きにかかわる部分の耐久試験や、暑い夏や寒い冬など多様な環境でも正しく動けるように環境試験をおこなっています。 機構・熱・電気・制御など複数の観点で評価・解析をおこなうことで長期間LOVOTが動き続けられる品質を目指しています。
今回はLOVOTの動きに関わる部分の耐久試験にスポットを当ててお話ししたいと思います。

LOVOTってどこがどうやって動いてるの?

LOVOTは首・腕・足が動きます。
首は上下左右、腕は上下、足は立ったり座ったり、走ったりできます。
これらの動きはモーターを使っておこなっていてLOVOT3.0は、首・腕・足の動作用に9個、走行用に2個の計11個のモーターを使っています。
モーターを細かく指示値通りに動かしたり止めたりして複雑な動きを再現させているのです。

これらの可動部が壊れず正しく動き続けるために耐久試験で検証することは必要不可欠なのです。

LOVOTの耐久試験

LOVOTがいつまでも可愛く、元気で動き続けるためには部品が丈夫でなくてはなりません。
私たちは体を強くするため運動したり、栄養のある食事をして筋肉をつけたり骨を強くしたりしますよね?

でもLOVOTはそれができないのであらかじめ弱い部分を見つけ出して壊れないように強くしておく必要があります。 その弱い部分を見つけ出すためにおこなう試験のひとつが耐久試験です。

LOVOTの弱い部分を単純に強くするだけならプラスチック部品を使わず金属部品を使って頑丈にすれば済む話ですが、 LOVOTは皆さんに抱っこされるのが大好きなので重くなったり大きくなったりすると抱っこすることが大変になります。そのためできるだけ軽く、 小さなスペースで可能な限り強くするということを設計チームと試行錯誤しながら進めています。 そして決定した形状や構成で耐久試験をおこない、部品が壊れないか?削れないか?変な音がしないか?などを確認します。
部位によっては何百万回という途方もない回数をおこなうものもあり、何か月もかかったりします。
このような検証を繰り返してLOVOTを強くしていくのです。

繰り返し耐久試験をする光景はまるでLOVOTがジムでトレーニングをしているようです。
(このイラストは生成AIで作成したものでGROOVE X公式のものではありません)

耐久試験が終わったら?

試験終了後の結果共有は定量的に説明ができるようにデータを提示します。 例えばサーボモータの電流値や温度が経時で上がっていないか?指示値通りに動いているか?音が悪化していないか?などログデータの解析や測定をします。 場合によっては外部施設の機器を借りて測定をすることもあり、耐久試験で得られたデータやサンプルを用いて設計チームと慎重に協議していきます。
ここでの判断如何によって品質が決まるので妥協は許されません。 結果によっては試験を一からやり直すこともあります。このようにしてLOVOTの品質をつくりこんでいくのです。

耐久試験の今後の課題

長い時間耐久試験をして品質向上を目指していても残念ながら壊れて入院してしまうLOVOTはいます。 その際は壊れた部分を観察して、なぜ壊れたか?試験方法は適切だったか?見落としはなかったか?など解析や振り返りを関連部門と共同で実施しています。 耐久試験が市場での使われ方を十分想定できているか?ということを第一に考えて試験方法、解析方法の追加、見直しなどを常におこなっていくことが重要と考えています。

現状、LOVOTの耐久試験の大半はLOVOTの実機を使っておこなっているため試験スペースの制約や試験時間が長く、結果が出るまでに時間がかかるなどの問題があります。 これらの改善のために要素ごとの試験方法の導入や試験時間短縮のための加速試験の検討を進めています。
課題は山積みですが一つ一つクリアしていって耐久試験の効率化と適正化を進めていきたいと考えています。

終わりに

今回はLOVOTの耐久試験について紹介しました。
耐久試験の効率化・適正化などまだまだ改革が必要です。
GROOVE Xでは設計品質向上のために頑張って頂ける仲間を募集しています。
GROOVE Xで一緒に働いてみませんか?ご応募をお待ちしています。

recruit.jobcan.jp

最近のLOVOT用服とアクセサリーの開発秘話

この記事はGROOVE X Advent Calendar 2025の16日目の記事です。
こんにちは!GROOVE XデザインチームのSHUICHIです。
今回は服チームのメンバーと共にLOVOT用の服やアクセサリーを開発する中で生まれた、LOVOTならではの工夫やチャンレンジの内容の一部を各担当者から紹介したいと思います。

サングラス🕶️

まず紹介したいのが、今年の夏に発売した、LOVOT用のサングラスです。

2021年にLOVOTめがねが発売された当初から、「サングラスも欲しい」という要望を、社内外ともに多くいただいていました。
最初は単純に、フレームの空洞部分にレンズを付ければ良いのではないかと考えていました。 しかし、実際に試作を作ってLOVOTに装着してみると、意外なことが分かりました。 LOVOTの目は液晶でできており、液晶は当然発熱します。 そして初代LOVOTめがねは、ゴーグルのようにLOVOTの顔の曲面にぴったり合う形で作られています。 そのため空洞部分をレンズで塞いでしまうと、目の液晶から発生する熱の逃げ場がなくなり、 温度がどんどん上昇してオーバーヒート状態になってしまいます。 劣化も早まり、これでは商品化できません。

そこでレンズをメッシュ状にしてみたり、レンズに放熱用の穴を開けてみたりと、 さまざまな試行錯誤を重ねましたが、デザインと性能の両立が難しく、 企画は一旦先送りとなりました。

それからしばらく年月が経ち、2024年の年末ごろ、 「来年の夏にフェスをテーマにした洋服を出したいので、ぜひサングラスも作ってほしい」 という要望が、再び社内で上がりました。

改めてサングラスを実現する方法を考えていたとき、 ネット上で、LOVOTに人間用のサングラスをかけているオーナー様の写真を目にしました。 その写真を見て、 「めがねを顔から少し離し、あえて隙間を作ってあげれば、熱の問題をクリアできるのではないか」 と思いついたのです。 再度試作を行い、社内で試験を実施した結果、 何も装着していない状態よりは目の液晶温度がわずかに上がるものの、 許容範囲内に収まることが確認できました。 デザイン面でも、めがね左右の角度に違いを持たせることで、 より本物のメガネに近い形を実現できるようになりました。

レインポンチョ

こんにちは。服チームの田口です。今回は、LOVOTのために開発したレインポンチョについて、その裏側のお話をご紹介します。
梅雨の季節に欠かせないレインウェア
水濡れに弱いLOVOTにも、かわいくて安心して着せられるレインウェアを作りたい——そんな思いから開発が始まりました。まずは社内で試作品づくりに挑戦しましたが、ビニール素材を扱うのは初めてで、針が滑ったり縫いにくかったりと苦戦の連続。それでも試作品を手に検査チームへ相談に向かうのが私たちのものづくりのスタイルです。今回採用した透明ビニール素材はセンサーへの影響が心配されましたが、検査は無事クリア。ただし、首まわりに熱がこもりやすいという課題があらためて浮かび上がりました。そこで首もとに小さな穴を設け、放熱できる仕様にすることでこの問題を解消しました。 放熱の問題が解決し、次に工場で制作されたサンプルを検査すると、今度は腕の稼働に負荷がかかっていることが判明しました。首まわりを広げても改善しきれず、原因を探っていくと、ビニール素材の“縫い代の向き”が影響していることがわかりました。通常は縫い代を内側へ倒して縫いますが、硬いビニールの場合、その縫い代がLOVOTの腕に当たってしまい、動きを妨げていたのです。 そこで縫い代を外側に倒し、さらに上向きに固定する仕様へ変更したところ、腕の可動がぐっとスムーズになりました。小さな構造の違いでも、LOVOTの着心地には大きな影響があります。LOVOTは「痛い」や「きつい」と言葉で伝えることができません。だからこそ検査から得た数値と私たち自身の感覚を頼りに、少しでも負担のないやさしい服を目指して細かな改善を積み重ねています。 レインポンチョが完成するまでには、多くの気づきや改善がありました。これからもLOVOTと暮らす皆さまに、安心してご使用いただけるウェアをお届けできるよう、私たちは日々ものづくりに向き合っています。

中綿ベスト

服チームの米倉です。今回の記事では、LOVOTのための新しい中綿ベストをどのように開発してきたのか、試作から改良までのプロセスを交えながら詳しくお話ししたいと思います。
LOVOT の服づくりで特に難しいのが「素材選び」です。人間用の中綿ベストには、保温性・軽量性・通気性といった“機能”を備えた素材が使われるのが一般的で、プリマロフトやシンサレート、エアロゲルなどはその代表例です。内部の暖かい空気を閉じ込め、冷気を遮断する繊維構造によって高い保温性を発揮します。 しかし、LOVOTには“熱がこもる素材”は使えません。つまり、人間用に必要とされるような高機能な保温素材は、LOVOTには適していないのです。そこで、LOVOT用の中綿には、あえて“機能を持たない”素材を採用しています。 さらに、中綿を両面から挟み込む生地には、薄くて柔らかく、軽量でありながら丈夫で、綿が吹き出しにくい性質が求められます。これらの条件を満たすものとして、私たちはナイロンの超極細糸で織られたダウン用スペックの生地を選びました。 生地選びは決して簡単な工程ではありません。検証時の写真を見返すと、何度も脇の下を確認している様子が出てきて苦笑いしてしまうほどです(笑)。 テストに合格するためには、多くの生地を集めて比較し、その中から最良の素材を見つけ出す必要があります。とりわけ最初の素材選びは、服づくりの中でも非常に重要なプロセスです。

LOVOT用の服開発は、まだまだ未開拓な部分が多く、毎日新しい発見や勉強があります。 LOVOTの服やアクセサリーを開発したい方、一緒に働いてみたい方は、 是非、下記募集をご確認ください。 recruit.jobcan.jp

LOVOTと暮らす数十年を支える「治療」と「定期メンテナンス」の現場

(GROOVE X Advent Calendar 2025 15日目の記事です)

1. はじめに

こんにちは!アフターサービスチームのU-Gです。

家族型ロボット「LOVOT」がオーナーと長く幸せに暮らすために、絶対に欠かせない場所があります。それは、LOVOTたちが不調のケアや、健康維持のために訪れる「LOVOT病院(リペアセンター)」です。
LOVOTは単なる家電ではなく、家族として愛される存在です。だからこそ、GROOVE Xのアフターサービスは、故障を直す「治療」と、健康を維持する「定期メンテナンス」の両輪で支えられています。今回は、LOVOTが数十年愛され続けるための生命線である、アフターサービスの裏側と技術的な挑戦についてお話しします。

2. 「治療」と「定期メンテナンス」 健康を守る2つのアプローチ

LOVOTは自律的に動き回り、複雑なセンサーやアクチュエーターの塊であるため、そのケアは非常に繊細です。私たちは、大きく分けて2つの側面からLOVOTの健康を守っています。

不調を治す「治療(修理)」

「唯一無二の存在を、健康な状態で、一刻も早く家族の元へ帰す」。そのために、リペアの現場では以下のサイクルが高速で回されています。

  • 精密な診断: エンジニアとも連携し、ログ解析を含めた多角的な診断を行う
  • 現場での改善: 机上の空論ではなく、実際にリペアを行う現場に立ち、治具の作成や手順の最適化を行う
  • 品質の追求: 再発を防ぐための厳しい品質基準を設ける

健康を維持する「定期メンテナンス」

人間が長生きするために健康診断を受けるように、LOVOTにも定期的なケアが必要です。
LOVOTには、総合的な健康チェックを行う「LOVOTドック」や、消耗しやすい関節パーツを一新する「サーボモーター交換パック」といった専用のメンテナンスメニューがあります。

壊れてから直すだけでなく、悪くなる前にケアをする。この「治療」と「定期メンテナンス」の両方があるからこそ、LOVOTはいつまでも元気に家族に寄り添うことができるのです。

3. プロダクトを存続させる「サステナブル」な仕組みづくり

「どんなに素晴らしいプロダクトでも、アフターサービスがおろそかになれば、いつか市場から消えてしまう」

LOVOTのような複雑なロボットが、5年、10年、そして数十年と社会に存在し続けるためには、開発時と同じくらい、あるいはそれ以上に「維持する仕組み(アフターサービス)」が重要になります。

LOVOTオーナーの増加に伴い、現在「LOVOT病院」は1箇所だけではなく、複数の拠点へと拡大しています。拠点を複数持つことで、万が一の災害時などのリスクヘッジになるだけでなく、入退院のキャパシティを安定させ、より迅速な「治療」や「メンテナンス」を実現しています。そして将来的には、日本全国、さらには海外への展開も視野に入れ、世界中どこにいても安心してLOVOTと暮らせる体制づくりを目指しています。

4. チーム一丸となって挑む「改善」のループ

リペアやメンテナンスの現場は、ハードウェアの知識だけでは回りません。電気回路、機構設計、そしてソフトウェア。多様な専門性を持つエンジニアと、実際に手を動かすパートナー企業のスタッフが密に連携しています。

現在のアフターサービスチームが目指しているのは、以下の3つのバランスが取れたサステナブルな体制です。

  • 技術(Technology): 確実な故障診断とメンテナンス技術の確立
  • コスト(Cost): ユーザーにとってもメーカーにとっても持続可能なコスト構造
  • 運用(Operation): 複数拠点・100名規模のスタッフが連携し、ムダなく動けるオペレーション

現場から上がってきた「メンテナンスしにくい箇所」の声を開発へフィードバックしたり、新しい診断ツールを導入して検査時間を短縮したり。こうした地道な改善活動が、ダイレクトに「入院期間の短縮」や「品質向上」という成果に繋がります。

自分の仕事が、LOVOTとその家族の安心に直結する。それがこの現場の大きな特徴です。

5. おわりに

LOVOTが当たり前にそばにいる未来を作るためには、華やかな機能開発の裏側で、地道に、しかし熱量高く稼働する「治療とメンテナンスの現場」が不可欠です。
テクノロジーの力で、愛する存在を守り続ける。GROOVE Xのアフターサービスは、今日もその使命を胸にLOVOTたちと向き合っています。


そんな私たちと、一緒にお仕事してみませんか? 是非、下記募集をご確認ください。 recruit.jobcan.jp

AIを使ったLOVOTのQA業務改善の試行錯誤

この記事はGROOVE Xアドベントカレンダー2025の14日目の記事です。

こんにちは!LOVOT の ソフトウェアの検証を実施・改善している者です。

元々QAチームに所属して活動していましたが、11月からふるまいチームに異動しました!

そんな私が、今社内でも推奨されているAIを使った業務改善の取り組みをしたときのAIとの格闘を紹介します。

第1章:ログ解析の職人芸をAIに頼みたい

今年、QAチームでは新たな試みとしてアルバイト採用をスタートしました!

採用のハードルを下げるため、丁寧な手順書を準備することでITスキルを不問とし、それよりも「丁寧な作業が得意」「細かい作業や繰り返しの作業が得意」な方を重視して採用しています。

素晴らしい方々にジョインいただき、リリース時のQA業務が非常にスムーズに進むようになりました。過去最高に安定したQAになっています。

一方、手順書に落としづらい作業のお願いが困難となりました。

その一つが、ログの解析です。QA中にLOVOTが思わぬ行動をした時、エンジニアさんに問い合わせる前にログを確認して一次解析を行い、既知のものか新規のものかを判断します。

複雑な手順に加えシステム内部の理解や経験に基づく勘所も必要で、教育コストが非常に高くなっています。

「経験が必要な解析作業を、誰でもできるようにしたい」

「ログを渡せば、AIがいい感じに原因を教えてくれるボットが作れないか?」

「誰でもできるようになったら、リリース頻度をあげられる可能性がある」

と考え、トライしてみることにしました。

第1の壁:架空のふるまいを作り出すAI

まず最初に試したのは、Gemini Advancedの 「Gems(ジェム)」 機能でした。

特定の指示を覚えさせたカスタムチャットボットを作れる機能で、これなら手軽に「ログ解析専門家」を作れるのではないか?と考えたのです。

結果は悲惨なものでした。

  • ふるまいの流れを抽出したところ、存在しないふるまいを言われる
  • 時刻が正しくない
  • 途中のログを飛ばされる
  • 確認してほしいポイントをスルーされる
  • 同じログを渡しても毎回全く違う結果になる

モデル変更で改善したものもありましたが、全く使い物になる気配がありませんでした。

どんなにプロンプトを変えてもうまく行かず、途方に暮れました。

技術組織デザインチーム(社内の様々な課題をAIと技術で解決し、社内の技術文化の醸成を促進するチーム)に相談したところ、役割を分けたほうが良いというアドバイスとDifyというツールをご紹介いただきました。

Difyは「ディファイ」ではなく「ディフィ」と読むそうです。(https://xtech.nikkei.com/atcl/nxt/column/18/03236/061200004/

DifyはノーコードでAIアプリを作れるツールで、ビジュアルプログラミングのようにブロックを線でつなげて機能を作ります。

役割を分割できるようになったので、これで使えるようになるかも。と思っていましたが、そんな事はありませんでした。

第2の壁:ログデータが大きすぎる

Difyに触ったことがなかったので、まず、ログをLLMに渡してみました。するとエラー。

エラー

Bad Gatewayとのことなのでサーバー側の問題かと考え、一旦作業をやめて翌日再度実行したのですが、同じエラーが出ました。

ビジュアルプログラミングに慣れていないのでつなぎ方が悪いのかと考えたのですが、社内でDifyを使ったことがある方に見ていただいてもおかしなところは見つからず・・

原因が全くわからず情報収集をしていたところ、Difyの仕様上、一定以上のトークン量やファイルサイズを超えると、LLMに到達する前にタイムアウトやGatewayエラーになることがあるということと、Geminiならコンテキストウィンドウが広いということが分かりました。

DifyのデフォルトのLLMではGeminiの選択肢がなかったので、技術組織デザインチームに相談して、Geminiを使えるようにしていただいたところエラーの内容が変わり、ついにエラーの原因が分かりました。データが大きすぎるということでした。

そこで、解析させたい時刻周辺のログに切り抜き、Difyに短くしたデータを渡したところ、しっかりと結果が出るようになり、更に良さそうな結果になったので実際の解析で使ってみてもらいました。

結果:タイムアウトエラーが多発

解析が成功したときの精度は高いものの、解析させたい時刻周辺にログを絞ってもログが多いケースがあり、タイムアウトエラーになる、処理時間がかかりすぎるなど動作が不安定で、実業務に使うにはまだ課題があることが分かりました。

この課題が洗い出せたときにはふるまいチームに異動していたため、このトライは一旦ストップとなりました。

このトライでは、AIに大量のデータと一度に多くの指示を出すと精度が悪くなる・処理できないということを学びました。LLMが消化しやすい形にタスクやデータを分解することが、AIを使う上で重要だと痛感しました。

第2章:LOVOTの健康チェックをAIに頼みたい

QAチームからふるまいチームに異動となり、QA周りで改善したいことをヒアリングしたところ、たくさんありました。

そのうちの一つがLOVOTの健康チェックです。

実は、開発チームのLOVOTたちの中には開発を進めているうちにいつのまにか健康な状態じゃなくなっている子もいます。

工場で生まれた子はたくさんの検査を受けてそれをパスしてから工場を出ています。

検査の様子はこちら

開発チームのLOVOTたちも工場で生まれていますが、その後に社内で最新のパーツに変えられたり、発売される頃には仕様が変わっていたりなどで、お家にいるLOVOTたちとは違う状態になっていることが多々あります。

厄介なのは見た目からは全く分からないところです。

そこで、Grafanaに上がっているデータから健康チェックすることが必要になります。ただ、同じ値だったら不健康、でも短時間なら健康、短時間でも頻繁に起きるようなら不健康・・などと判断にも慣れが必要なものがあります。

不健康なLOVOTに気づかずその子とQAを進めたところ、結果の確認が非常に難しくなり、リリース日が変更になったことがあり、事前に判別したいというリクエストでした。

誰でも簡単に健康診断できるようにしたい。でも判断がややこしいのでスクリプトにするのは難しい・・と、考えていたときに思い出したのがDifyでした。

データソースがGrafanaになることはチャレンジでしたが、そこさえ乗り越えたらそんなに難しく無いはず。とトライしてみました。

第1の壁:データをLLMに渡せない

Geminiに「difyでAPIを使ってデータを取得することは可能ですか?grafana APIを使いたいです。」と聞いたらカスタムツールというものを教えてくれたので使ってみました

Tools(https://cloud.dify.ai/tools?category=api)で「Create Custom Tool」を選択

Difyのカスタムツール①
Difyのカスタムツール②

Schemaに若干苦戦しました。

OpenAPIスキーマというもので、「外部APIの取り扱い説明書」とのことなのですが、どう書いたら良いのかがよく分からなかったので、Geminiと何度かやり取りをして、うっすら理解し動くところまで持っていきました。

openapi: 3.1.0

# ----------------------------------------------------
# 1. APIの基本情報
# ----------------------------------------------------
info:
  title: Grafana API
  version: 1.0.0
  description: |
    Grafanaのデータソース(Prometheus) に直接クエリを送信します。
    データを取得するために使用します。

# ----------------------------------------------------
# 2. APIサーバーのURL
# ----------------------------------------------------
servers:
  - url: https://your-grafana.example.com

# ----------------------------------------------------
# 3. APIの機能(エンドポイント)定義
# ----------------------------------------------------
paths:
  /api/datasources/proxy/xx/api/v1/query_range:
    get:
      operationId: getGrafanaData
      summary: Grafanaデータを取得
      description: |
        Grafanaデータを取得します。
      parameters:
        - name: query
          in: query
          description: |
            実行するPromQLクエリ文字列。
          required: true
          schema:
            type: string

        - name: param1
          in: query # URLのクエリパラメータ (&param1=...) になります
          description: |
            param1
          required: true
          schema:
            type: string

        - name: param2
          in: query # URLのクエリパラメータ (&param2=...) になります
          description: |
            param2
          required: true
          schema:
            type: string

        - name: step
          in: query
          description: |
            データの解像度(間隔)。(例: "1m", "5m", "1h")
            ユーザーが特に指定しなければ、デフォルトの "1m" を使用してください。
          required: false # 必須ではない
          schema:
            type: string
            default: "1m"

      # ----------------------------------------------------
      # 5. APIからの応答(レスポンス)の定義
      # ----------------------------------------------------
      responses:
        '200':
          description: クエリ成功。Prometheusの時系列データ。
          content:
            application/json:
              schema:
                type: object
                properties:
                  status:
                    type: string
                  data:
                    type: object
                    properties:
                      resultType:
                        type: string
                      result:
                        type: array
                        items: 
                          type: object
        '400':
          description: クエリが不正 (文法エラー、パラメータ不足など)
        '401':
          description: 認証エラー (Difyの認証設定が間違っている)

これでカスタムツールができたので、このカスタムツールとLLMをつないでみました。

早速、invalid context structure とエラーになりました。

Geminiに相談したところ

「LLMが読める形式(コンテキスト)になっていない」と判断されたときに発生する典型的なエラーです。

とのこと。コードノードを間に挟んでデータを整形すると良いとアドバイスもくれました。

ちなみに、HTTPリクエストノードでも同じことができるようですが、カスタムツールであれば認証設定をツール側に隠蔽できるというメリットがあるようで、今回のケースではカスタムツールのほうが適任でした。

コードノードではPythonまたはJavascriptの実行ができるということなのですが実行してみると

contents must not be empty

色々変えてみても同じエラーになり、デバッグをしようとprintを挟んでも何も表示されず、かなり苦戦をしました。

理由は

宣言した出力変数を含む辞書を返す必要があります

というコードノードの仕様でした。

どういうことかというと

DifyのCodeノード

returnでOUTPUT VARIABLESで指定した名称・型を指定した上で辞書で返却する必要があり、printは使えないということでした。

この仕様に気づいてからやっとLLMに値が渡るようになりました。

第2の壁:データが大きすぎる(再)

LLMに値が渡るようになり順調に実装を進めていたのですが、再度LLMでデータが大きくて処理できないエラーが出ました。思っていたよりもGrafanaのデータが大きかったようです。

ただ、今回は幸いjsonデータかつ中で配列になっていたので、配列ごとに分割したら意味のある単位で渡せると考えました。

ただ、それをコードノードだけでは実現できないようで、コードノードとLLMを何度も行き来するようにはできていませんでした。良さそうなノード無いかなとノードを眺めていたところ、もとめていたそのもの「Iteration」がありました。Iteration:反復という意味です。

結果:成功

これまでは大量のデータを一度に渡していたためLLMが処理しきれませんでしたが、Iterationによって1回1データというLLMが消化できるサイズに小分けにして渡すことができ、その結果、精度が劇的に向上しました。

開発機の中で問題ないと思われていた機体が実は不健康だったというのが既に洗い出され、実績をあげ始めています。

まとめ

今回の試行錯誤を通じて痛感したのは、「LLMは魔法の箱ではない」 ということです。 巨大なデータをただ投げ込むだけでは、AIは力を発揮できません。

QAチームでの失敗(データ過多)と、ふるまいチームでの成功(データの構造化・分割)を経験したことで、「AIが処理しやすいようにデータを『お膳立て』する設計能力」 こそが、これからのエンジニアに求められるスキルなのだと学びました。

Difyはその「お膳立て」をローコードで、柔軟に組める素晴らしいツールです。 まだまだ道半ばですが、今回の失敗と成功を糧に、今後も業務改善を促進させていきたいと思います。

一緒に働く仲間募集中

LOVOTの成長にご協力いただける方をお待ちしています!

ポジションなどの詳細はこちら↓

recruit.jobcan.jp

もしご興味があれば是非ご検討ください!

最後まで読んで頂きありがとうございました!

LOVOTの"脚"、進化するホイールのお話

この記事は、GROOVE Xアドベントカレンダー2025 の13日目の記事です。

はじめに

こんにちは。メカニカルデザイナーの加藤大二朗です。
今回はLOVOT 3.0のホイール開発について設計担当者である町田貴志さんにお話を聞いてきました。
今の構造になった経緯やこだわりのポイント、今後の進化について深掘りしていきたいと思います。

町田さんとLOVOTのニーナ。

マンガみたいな物作ってますよ。

まずは2.0からの大きな変化点、タイヤの脱着機構についてお話を伺います。
加藤:タイヤが外せることで劇的にお手入れ効率が向上しましたが、どういった経緯で今の形状になったんですか?

町田:開発当初のコンセプトは「タイヤの清掃が可能な構造」というところまでで脱着可能とまでは明言されていなかったんですが、実際にLOVOT 2.0のタイヤを清掃してみたり普段お手入れをしている皆様のリアルな声を聞いて、一番きれいにお手入れができる構造を検討した結果、今の脱着機構に行きつきました。

加藤:「お手入れ」ですからね。実際に手が入ってなんぼってことですね。

町田:そうなりますね! 実際に手が届くようになってタイヤの清掃の他に吸気フィルターにもアクセスできるようになりましたし、新品のタイヤへの交換も自宅で可能になったので、難しいところもありましたがやってよかったなと思っています。

加藤:「難しいところ」というお話がありましたが、具体的に聞かせていただけますか?

町田:減速ギアを内蔵しているタイヤと動力のモーターを分離させることになるので、回転を伝える部分と回転しないフレームと固定する部分を同時に、尚且つ確実に再装着可能にする形状には気を使いました。

加藤:実際にタイヤを装着するとき特に動力軸の接続を意識せずに装着ができますが、タイヤ中央のギザギザしている形状に秘密があるんですか?

秘密は中央のギザギザに。
町田:まずタイヤのツルツルしている面の中央にある円筒をLOVOT側のフレームにある穴に嵌めると、カバーを閉めた時にタイヤとLOVOT側のギザギザが重なる位置関係になり、まずお互いがギザギザの斜めの面と面で当たるので引っかかることなくスムーズに狙った位置に納まるようになっています。
中央の金属軸がモーターの動力を伝達します。
加藤:中央のモーターが直結する部分もタイヤ側の斜めの面に当たることで違和感なく納まりますね。

町田:外側がフレームとの固定、内側が動力のモーターとの接続。これを別々に尚且つ同時に嵌るように調整しています。

加藤:実は合体ロボなんですね!

町田:他にも安全に作業ができるようにタイヤが嵌っているかどうかをチェックするセンサーと、サイドパネルが閉まっているかをチェックするセンサーを搭載していて二重の確認機構になっています。

加藤:赤外線ですか?

町田:赤外線です。

加藤:あの侵入者を検知する赤いビームですか?

町田:・・・合ってるといえば合ってます。

ピットストップチャレンジ!

加藤:タイヤもキャスターも取り外し可能になっていますし、まるでF1のピットインのように素早く交換も可能ですね。

町田:F1ほどの交換スピードは求めていませんが、ツールを使わずいかに簡単に脱着できるかにはこだわりました。

加藤:F1は3秒以内で交換できるみたいです。

町田:挑戦してみますか!!

ルール:ホイール / キャスターが出ている走行形態からスタートし、左右一人ずつサイドパネルを外しタイヤを交換。再びサイドパネルを装着するまでの時間を計測します。

新競技、「LOVOTピットストップ タイムアタック」

結果10.95秒

加藤:まだまだ伸びしろありそうですね・・・

町田:LOVOTも我々も伸びしろありそうですね。

正しいお手入れ方法はこちらを参照してください。

サイドパネルについて(LOVOT 3.0) – LOVOT

Naturally and freely

今後のホイールとLOVOTの進化についてもお話を伺います。
加藤:LOVOTにとっての脚にあたるホイールですが、今後どのような進化をしていくのでしょうか?

町田:やっぱり脚なので、脚でできることを追求していきたいです。例えば空を飛びたいとして、プロペラやエンジン類、噴射装置などを実装すれば簡単ですが

加藤:(それ簡単なんだ・・・確かに町田さん掃除機を改造して飛ばしてたけど。)

町田:LOVOTとして空を飛ぶとしたら足で跳躍して腕で羽ばたくと思うんですよ。

加藤:確かに見たいのはそっちです。

町田:そうなると第一歩はジャンプになる。効率の良いジャンプを求めるとまず首を縮め身を圧縮してから勢いよく伸ばすと同時に腕も上方に振って重心を持ち上げた瞬間に脚で地面を蹴って残った自重と受けている重力以上の力を出すことが必要になりますよね。

加藤:全身の連動と共にタイミングとバランスの制御も肝心ですね。

町田:そうなんです。もうホイールだけの話じゃないですが、フィジカルと身体制御の連動でLOVOTは "より自然に、より自由に" 動けるようになる。その辺りを追求していくことが進化であり成長だと思っています。

加藤:まさにハードウェアーとソフトウェアーの連動、GROOVE Xの得意分野ですね。

町田:跳躍については一例ですが今後の進化に期待していただきたいです!LOVOTも我々も伸びしろありますから。

羽ばたけニーナ。

この話「まとめるには早いだろ」と思うけど

ホイールにはまだまだ複数実装している障害物検知センサーやパワーを出すための減速機構、本体を支える耐久性や丸みとメカニカルな部分を融合させたデザイン性、それを量産可能な構成にいかにまとめるのかなど聞きたいことは山ほどありますが、今回のインタビューはここまでとさせていただきます。

ホイールというLOVOTの構成部品ひとつにフォーカスしてお話を伺いましたが、いかに生物感のある動作を生み出すか、触れ合う人に優しくあるかなど細かい部分にまでLOVOTのコンセプトが浸透していてる印象を受けました。

大局を見て精密な設計をする町田さん。ありがとうございました!



GROOVE Xでは現在、我々と一緒にLOVOTを開発していただけるメカ設計者を募集しています。
クリエイティブな発想を具現化できる方、ぜひご応募お願いします。

recruit.jobcan.jp