UnitreeやAGIBOTのようにヒューマノイドロボットが安価に手に入るようになりました。ところが、こうしたロボットを買っただけでは、ロボットが何か自律的に作業ができるわけではありません。たしかにダンスやカンフーは面白いですが、ロボットについてくる既存の会話やナビゲーション機能は実際に使うには限界があります。
Omakase OSはそうしたヒューマノイドロボットが、実際に人のいる空間で役に立てるようになるためのオペレーティングシステムです。1つのOEMに依存せずに、様々なOEMが提供しているロボットに載せることができます。
人間らしいマルチモーダルの会話
私たちが最初に取り組んだ機能は、ロボットが人間らしくコミュニケーションできることでした。人がいる空間でのオフラインのコミュニケーションは、想像以上に難しいものです。複数人がロボットに話しかける、どうやって話に割り込むのか、誰の声に集中するのか、周りの雑音は無視する、など考慮することが非常に多いです。
昨今の音声AIの発展は目覚ましいですが、まだまだ既存のAIやAPIを活用すればロボットの会話が簡単に動く、というものではありません。ロボットの場合は、周りの状況を見ながら会話できる必要があり、このマルチモーダル会話を遅延なく行うのが大きなチャレンジになります。私たちは、自分たちのGPU上で動く独自の会話エンジンを実現し、さらに、この会話エンジンでは任意の人物の音声を学習することで、まるでその人のようにロボットをコミュニケーションさせます。
何を短くすべきか
会話の速さを語るとき、多くの実装は「応答が返るまでの時間」を測ります。しかし対面のロボットで効くのは、応答が返り終わる時刻ではなく、ロボットの声が出はじめる時刻です。人は相手が話しはじめた瞬間に「聞いてもらえた」と判断し、そこから先の長さは会話の自然さをほとんど左右しません。そこで私たちは、話し終えてから最初の音声が出るまでの時間（time-to-first-audio, 以下 TTFA）を設計上の主指標に置いています。
一括処理では、TTFAは応答全体の生成が終わるまで縮みません。
TTFA一括 = T音声認識 + T生成(y) + T音声合成(y)
ここで y は応答文の全体です。私たちの実装は言語モデルの出力を句読点単位で切り出し、最初の1区間 s1 が確定した時点で合成を始めます。応答が何文になろうと、TTFAは最初の1区間ぶんしか待ちません。
TTFA逐次 = T音声認識 + T最初のトークン + T生成(s1) + T音声合成(s1)
さらに、最初の1区間だけは合成の反復回数を落とし、2区間目以降は音質側に振ります。話しはじめの速さと、話し続けたときの声の質は、別々に調整できる量として扱っています。
表1 逐次処理での応答時刻。カメラ画像の有無で比較。画像は 640 × 480・JPEG 品質 80（実機の頭部カメラと同じ条件）。
結果として一番はっきりしたのは、画像を1枚足してもほとんど時間が増えないことでした。TTFAの差は 3 ms で、これは測定のばらつきに埋もれる大きさです。視覚トークンは生成前の一括処理に吸収され、そこは律速ではないためです。ロボットが周りを見ながら話すことに、速度上の代償はほぼありません。「見て話す」を諦める理由が計算コストにない、という確認は、この機能を標準で有効にする判断の根拠になりました。
図1 会話1ターンの時間の使われ方（2026年8月4日実測・中央値）。上2段は同じ処理を一括と逐次で行った比較で、逐次では応答が全部できあがるのを待たずに声が出はじめる。3段目は同じ処理にカメラ画像を1枚足したもので、差はほとんど無い。最下段は同じサーバに広域回線越しに到達した場合で、増えた 1.42 秒はすべて回線であり計算ではない。破線は、人が遅れを知覚しはじめるとされる 0.7 秒。
もうひとつは、同じ処理を遠隔のGPUに置いた場合です。往復 120 ms の回線越しに同じ音声を送ると、TTFAは 1.18 秒から 2.60 秒に伸びました。増えた 1.42 秒に計算は1ミリ秒も含まれておらず、すべて音声データの往復です。会話を速くするために最も効くのは、モデルの選定でも量子化でもなく、GPUをロボットと同じ場所に置くことでした。私たちが会話エンジンを自前でホストしている理由の半分はこれです。残りの半分は、通信が切れても会話が止まらないことです。
たしかに、TTFA 1.18 秒は、人が遅れを感じはじめるとされる 0.7 秒をまだ超えています。次に削る余地があるのは音声認識で、ここは現在、発話が終わってから認識を始める実装になっています。発話中から逐次認識する構成に変えれば、認識にかかる時間の大半は発話時間の裏に隠せます。
声を学習する
会話エンジンは、特定の人物の声を学習して、その人のようにロボットに話させることができます。基盤となる音声合成モデルは残したまま、その人ぶんの差分だけを小さなアダプタとして学習します。
図2 声を1つ足すのに必要なもの。実際に運用している話者の学習実績。収録6分・学習約5分・成果物 84 MB。基盤モデルは共有され、差し替わるのは声だけ。
表2 声の学習の実績値（実運用中の話者1名ぶん）。
数字にすると、ある人の声を1つ増やすコストは「6分の収録と5分の学習」です。声はモデル本体ではなくファイルなので、同じ声をどのロボットにも載せられますし、現場ごとに違う声を持たせることもできます。
会話の次に開発したのは自律ナビゲーションの機能です。ロボットが歩き回れる、というのは非常に基礎的な機能になります。Vision Language Navigation（VLN）のようなend-to-endのアプローチではなく3D LiDARを活用したSLAMベースのナビゲーション機能を実装しました。
図3 ナビゲーションの構成。設計の要点は、地図をつくる相と走る相を完全に分け、走行中は地図を書き換えないことにある。自己位置推定は既知地図に対する照合だけを行い、その健全性が下流のすべての速度指令を支配する。ロボットごとの違いはプロファイル1枚に閉じ込めてあり、構成そのものは車輪型でも脚型でも同じ。
安全に関わる部分だけ補足しておくと、この構成でいちばん重要な部品は経路計画ではなく安全ガバナです。自己位置の健全性が「劣化」なら速度に係数をかけ、「喪失」なら速度指令を即座にゼロにします。推測航法で走り続ける実装にはしていません。自己位置を見失ったロボットが、見失ったことに気づかないまま進むのは、現場でいちばん危ない挙動だからです。
筑波大学附属病院での実証
私たちは2026年3月、筑波大学附属病院で、夜間の見回りや多言語での案内業務の実証実験を行いました。この実証では、コミュニケーションやナビゲーション機能を中心にロボットの利活用を検証し、病院というリアルな環境で、二足歩行ロボットが障害物を避けながら目的地までの案内や夜間の見回りというユースケースを確認しました。病院のような特徴点の少ない環境での自律ナビゲーションの検証は非常に有意義なものでした。
表3 第1回実証（2026年3月23〜25日・1階ロビー・二足歩行ロボット）。
走行距離・巡回時間は、自己位置が安定していた有効走行の集計。
37
910 m
70.6 分
169
52
297
90.8 %
82.2 %
92.3 %
86.2 %
64.4 %
94.9 %
78.8 %
82.0 %
0 / 0
0 / 0
0 / 0
0 / 0
3日間で転倒0・接触0、自律走行910 m、到達率86.2 %。移動そのものは想定どおりでした。一方で実証で分かった弱点もはっきりしていました。ロボットを起こす、あるいは見失いから復帰させるリローカライゼーションが安定せず、長時間の走行では自己位置の誤差が徐々に溜まっていくセッションが残ります。特徴点の乏しい病院のロビーは、この弱点が最も出やすい環境でした。
そして、2026年6月には、同病院にて第2回の実証実験を行い、さらなる機能の検証を行いました。第2回目の実証実験では、異なるベンダーのロボットを用いて、より長い走行距離の走行を実験しました。
表4 第2回実証（2026年6月24〜25日 各日19:00–21:00・1階）。ロボット別の走行距離 [m]。
1,338
1,343
2,681
第2回の総走行距離は2,681 mで、第1回の約3倍になりました。四足ロボットでは自律走行を含めた検証ができた一方、車輪型ロボットの自律ナビゲーションは今回は目標に届かず、案内走行はテレオペで代替しています。
ここまで書いてきたのは、実証で分かった弱点が、そのまま次の設計を決めているからです。第1回でリローカライゼーションの不安定さに直面していなければ、ナビゲーション機能が持つ構造的な弱点にも、たどり着いていませんでした。現場に持ち込むこと自体が、私たちにとっては最も効率のよい設計手段になっています。
表5 現行構成のシミュレーション上の実測（12 × 8 m の室内・侵入禁止区域＋減速区域＋移動障害物）。
実機での再検証はこれから。
0.30 m/s / 0.63 m/s
移動障害物との最小距離
2.16 m
自己位置喪失を注入したときの停止
約 0.04 秒で速度指令 0、その後復帰し目標に到達
ナビゲーションのロバスト性は、評価基盤と現場での検証の両輪が欠かせません。私たちは、泥臭く現場に導入することで機能の改善を図っています。
独自のリアルタイム行動認識モデル
様々な現場でOmakase OSを検証していく過程で、ロボットのリアクション速度が非常に大きな課題になりました。人が手を振って近づいてくると、ロボットとしては、ほぼリアルタイムで応答する必要があります。もし、人が手を出して握手を求めてくると、ロボットとしては握手をし返すのが自然です。そこで私たちは、深層学習を用いた独自のモデルを開発しました。
この問題には、ふつうの行動認識研究とは違う制約が3つあります。遅延（正確でも遅ければ意味がない）、計算資源（学習用GPUではなくロボットに載ったJetsonで動かす）、説明可能性（なぜ間違えたかが分からなければ直せない）です。この3つを同時に見ながら、骨格表現とモデル構造を横並びで評価しました。
図4 行動認識パイプライン。頭部のRGB-Dカメラから骨格を取り、複数人のうち最も近い一人を選び、1秒ぶん（10フレーム）の系列から5クラスを判定する。手首だけでなく体幹と顔の点を入れているのは、視線の向きが「自分に用があるか」を強く示すため。
HRI（Human Robot Interaction）のデータセットを多様に集めて注釈をつける作業は非常に高価です。そこで、実測で集める代わりに、変動要因を明示的にモデル化して増やす方針をとりました。左右の利き手、動作の速さ、そしてロボットの頭が動くことによるカメラ姿勢の変化 — この3つを幾何的に定義して合成すると、データは約12倍になります。ただし効果は条件によって差があり、人による違いそのものは水増しでは埋まりません。1人ぶんのデータをいくら増やしても、多人数で学習したモデルには届きませんでした。
正確さと、間に合うことは別
時空間の特徴を取るモデルを14種、横並びで比較しました。評価は分類精度だけでは足りません。実際に効くのは、動作が始まってからロボットが正しく判定するまでの時間で、これが 0.7 秒を超えると人は遅れを知覚します。つまり分類器がどれだけ正確でも、Jetson上の推論に 600 ms かかるなら、その時点で予算をほぼ使い切っています。
図5 精度と組込み推論時間の関係。最も正確なモデルと、ロボットに載せられるモデルは一致しない。塗った領域が、応答予算 0.7 秒に間に合う範囲。Bi-LSTM は最重量級モデルの 1/29 の推論時間で F1 0.711 を出しており、実装候補になる。
最も正確なモデルは Jetson 上で 600 ms 以上かかり、そのままでは載りません。一方で軽量な Bi-LSTM は 38.2 ms で F1 0.711 を出し、はるかに重いモデルと肩を並べます。応答予算に収まり、かつ精度が競合する帯はここだけでした。入力表現の設計もモデル構造と同じくらい効き、位置と速度に加えて「その関節を検出できたか」というフラグを渡すと、軽量モデルの成績が目に見えて上がります。骨格が取れなかったことを、モデルに黙って推測させないためです。
もうひとつ、学習済みモデルがどこを見ているかを可視化したところ、予想外の結果が出ました。手首中心の動作であるはずのハイタッチや手振りでも、モデルは手首をあまり見ておらず、体幹と顔の点を重く見ていました。これは末端の3D計測が不安定であることの裏返しです。手首の3D位置は現在のカメラの分解能とフレームレートでは信頼できず、モデルはより安定した情報のほうへ学習で逃げていた、ということになります。この2つの動作を分けたければ、モデルを大きくするのではなく、手首の3D計測そのものを改善するのが正しい手当てです。説明可能性を評価に組み込んでおかなければ、この結論には到達せず、モデルの容量を増やす方向に時間を使っていたはずです。
ロボット非依存の設計
Omakase OSはベンダーに依存しない設計で開発されました。複数のベンダーのロボットを触ると、いかにそれぞれのロボットのインターフェースが異なるのか、ということに気付かされます。私たちは、そう言ったベンダーごとの差分を吸収できるようにインターフェースを設計しました。
図6 RobotInterface の構造（実コードより）。必須は6メソッドだけで、それ以外の能力はロボット側が「持っているかどうか」を申告する。上位のコードは機種名を知らず、capabilities() の戻り値だけを見る。
設計の中心は、必須と任意をはっきり分けたことです。必須は6メソッド — 目標姿勢への移動、速度指令、停止、頭部の相対／絶対の向き変更、うなずき。これが実装できないロボットはそもそも載せられません。逆に言えば、これだけ実装すれば載ります。
その他の能力 — 立つ・座る・しゃがむ・脱力、腕の動作、状態の取得、電池残量、会話状態のLED表示 — はすべて任意です。実装されていなければ、既定の無害な動作（何もしない、あるいは「その能力はない」と明示的に返す）に落ちます。上位のコードはcapabilities()の戻り値を見て振る舞いを決めるので、機種名で分岐する箇所がありません。
この設計の効果は、アダプタの実装量に表れています。最小のアダプタは268行です。ロボットを1台足す作業量は、おおむね必須6メソッドの配線に等しく、残りは持っている能力を申告するだけです。逆に最大のものが2,194行あるのは、そのロボットが持っている能力が多いこと（姿勢制御も録画再生も持つ）を反映しているのであって、共通部分が肥大しているわけではありません。
ロボットの追加は設定ファイル1行で、クラスへのパスを書けば実行時に読み込まれます。ナビゲーション側でも同じ考え方をとっており、ロボットごとの footprint・速度・加速度・運動学はプロファイル1枚に閉じています（図3右下）。
ラボではなく現場で役に立つ
汎用ロボットの社会実装はまだまだ距離がありますが、Omakase OSを通じて、ロボットが人のいる環境に入っていけるように開発を進めています。
ここまでの4つの節は、別々の技術の話に見えて、実は同じ手順を4回繰り返しています。現場に持ち込む → 測る → 数字が悪い理由を突き止める → 設計を変える。この文書に載せた数字のうち、私たちにとって価値があったのは、良かった数字ではなく悪かった数字のほうでした。
会話では、遅いのはモデルではなく回線でした（1.42秒）。だから会話エンジンをロボットと同じ場所に置く構成にしました。ナビゲーションでは、リローカライゼーションが実環境で安定しませんでした。だから走行中は地図を書き換えない設計に変えました。行動認識では、モデルは手首をほとんど見ていませんでした。だから次に直すのはモデルではなくカメラです。インターフェースでは、5社目のロボットを載せるときに上位のコードを触りたくありませんでした。だから能力を申告制にしました。
どの判断も、机の上では出てきません。病院の1階ロビーは、特徴点が少なく、床が反射し、夜間は照明が落ち、人が予測不能に横切ります。社内の環境では問題なく動いていたものが、そこでは動かない。その差分こそが、製品にするために埋めなければならない距離であり、それを見つける方法は、持ち込んで動かす以外にありません。
まだ埋まっていない距離も、はっきりしています。会話の TTFA 1.18秒は、人が遅れを感じる 0.7 秒をまだ超えています。車輪型ロボットの自律ナビゲーションは、第2回実証では目標に届きませんでした。行動認識の実機統合はこれからです。マニピュレーションを人の介在なしに自律実行する精度も、まだ足りていません。
これらは、次に測る対象のリストでもあります。私たちが作っているのは、完成した知能ではなく、現場の失敗が設計にちゃんと戻ってくる仕組みのほうです。ロボットが人のいる空間で本当に役に立つようになるまでに何回この輪を回す必要があるのかは、まだ分かりません。ただ、回す速さで決まる、ということは分かってきました。