学習済みの脳をブラウザで動かす — ONNXとリアルタイム推論【アヒルで学ぶフィジカルAI #6】

Ember 編集部 ・ 2026-08-28 ・ 約5分 ・ robotics

前回、アヒルの歩き方は強化学習で「育てた」ものだと話しました。育てる作業はGPUを積んだ計算機の上で、Pythonの訓練フレームワークを使って行われます。しかしFUTSAL DUCKSで実際に動いている場所は、あなたのブラウザです。PythonもGPUサーバーもそこにはありません。 つまりどこかで、<strong 育った脳の「引っ越し」</strong が起きています。今回はこの引っ越しと、引っ越し先で毎秒50回×8羽ぶんの計算を間に合わせ続ける技術—— リアルタイム推論 の話です。地味に聞こえますか? 実はここは、フィジカルAIが「研究」から「現実に動くもの」になるかどうかを分ける、勝負どころです。

道具箱① ONNX — 脳の輸送コンテナ 訓練を終えたニューラルネットワークの実体は、「計算の手順書」と「20万個のパラメータ」です。問題は、これが訓練に使ったフレームワーク(PyTorchなど)の形式で保存されていて、そのままでは他の環境で動かせないこと。 そこで ONNX (オニキス, Open Neural Network Exchange)という共通規格に変換します。海運のコンテナと同じ発想です。中身(モデル)を規格化された箱に詰めれば、どの船・どのトラック(=どの実行環境)でも運べる。 ゲームのロード画面に「ONNX ポリシーをロード中…」と出ていたのを覚えているでしょうか。あのときダウンロードされていたのが、この「箱」です。1個約0.8MB。歩行用、左キック用、右キック用、ローラー用……と種類ぶんあります。 箱を開けて動かす側のソフトを ランタイム と呼びます。このゲームではONNX Runtimeというランタイムを、WebAssemblyという仕組みでブラウザ内で動かしています。そして重要なのはここです——<strong 実機のmicroduckも、同じONNX形式のポリシーファイルを、体に積んだスマホ級の小型コンピュータのランタイムで読み込んで動かします</strong (実機側のソフトウェアはRust製で、これも公開されています。制御ループは50Hz——このゲームと同じ拍です)。ブラウザのアヒルと現実のアヒルは、文字どおり同じ規格の脳を使うのです。 道具箱② リアルタイム制約 — 締め切りは20ミリ秒ごと 第2回で、物理は200Hz、脳は50Hzという2つの時計の話をしました。50Hzということは、 20ミリ秒ごとに締め切り が来るということです。1回の締め切りまでに、ゲームは次の仕事を全部終えなければなりません。 間に合わなかったら? ゲームならカクつきで済みます。実機なら、モーターへの指令が止まり、アヒルは転びます。 物理世界の締め切りには「ちょっと待って」が通じない ——これがフィジカルAIとWebサービスの一番の違いです。 ここで前回の「脳は小さい(0.8MB)」が効いてきます。20万パラメータのネットワーク1回の実行は1ミリ秒未満。8羽実行しても余裕で締め切りに間に合う。もし脳がChatGPTサイズだったら、1回の返事に数百ミリ秒〜数秒かかり、その間にアヒルは15回転びます。 フィジカルAIの脳は、賢さだけでなく「速さ」で選ばれる のです。 道具箱③ エッジ推論 — なぜクラウドに頼れないのか 「重い計算はクラウドのGPUにやらせて、結果だけロボットに送ればいいのでは?」——自然な発想ですが、バランス制御では成立しません。 ネットワークの往復には、条件が良くても数十ミリ秒かかります。20ミリ秒ごとの締め切りに、往復100ミリ秒の相談役は間に合いません。しかも電波は途切れます。転びかけたロボットが「圏外」で固まる姿を想像してください。 だから、体のバランスのような即応性が命の計算は、 ロボット自身に載せた計算機で行う のが原則です。これを エッジ推論 (手元での推論)と呼びます。一方で、「次の試合戦略を考える」ような数秒待てる思考はクラウドに任せてもいい。第4回でやった 階層設計 (下の階=反射、上の階=判断)が、計算機の配置にもそのまま現れるわけです。 ちなみに、200Hzと50Hzの間の「4ステップぶんの空白」を埋めているのは、第3回でやったモーターのPD制御です。脳が20ミリ秒に1回しか目標を言わなくても、モーターは200Hz側の世界でばねのように目標へ引っ張り続けてくれる。 遅い脳と速い体の間を、ばねが取り持つ 。人間の運動制御も同じ構造だと言われています(意識的な反応は0.2秒かかるのに、走れるのは筋肉と脊髄反射が間を埋めるから)。 引っ越しの全体地図 連載前半の登場人物が、ここで一本の線につながります。 同じ箱が、ゲームにも実機にも配達される。この「配達網」が規格化されているおかげで、研究室の成果が数日でブラウザのおもちゃにもなり、現実のロボットにもなる。フィジカルAIの生態系は、こういう地味な規格の上に建っています。 観察課題 今回は、ブラウザの開発者ツールを使ったちょっと本格的な観察です。 1. ゲームのページで F12キー (Macは Cmd+Option+I)を押して開発者ツールを開き、 Network(ネットワーク)タブ を選んでからページを再読み込みし、ソロプレイを開始してください。流れるファイル一覧の中に .onnx が数個(各約0.8MB)、 .wasm (物理エンジンMuJoCo本体とONNX Runtime)、 .stl (体の部品の3D形状)が見つかるはずです。 この連載で説明してきた部品が、全部実名で流れてきます。 2. そのままNetworkタブで 通信が止まる ことを確認してください。ロード完了後、アヒルたちがどれだけ動き回っても、サーバーとの通信はほぼゼロです。物理も推論も全部あなたのPCの中で起きている証拠です(マルチプレイ時だけ、341個の状態がプレイヤー間を流れます)。 3. 性能の低いPCやスマホで開くと、動きがスローモーションになることがあります。これは締め切り(20ms)に間に合わないとき、ゲームが「破綻」ではなく「時間を引き延ばす」ことを選ぶ設計だからです。実機ではこの選択肢がない——時間は引き延ばせない——ことを想像すると、リアルタイム制約の重さが実感できます。 次回は応用編です。歩く脳、蹴る脳、ローラーで滑る脳—— 複数の専門家ポリシーを切り替える という設計と、そこから見える「知能と身体は切り離せない」という話をします。ローラーモードの旋回がなぜあんなに遅いのか、種明かしもそこで。