アヒル型二足ロボットの強化学習環境「microduck_rl」の仕組み

二足歩行ロボットの強化学習は、シミュレーションの中で歩かせるところまでは比較的たどり着けます。難しいのはその先です。学習済みの方策を実機に載せた瞬間に、シミュレーションでは滑らかだった歩容が崩れ、その原因がモデルにあるのか報酬にあるのか制御周期にあるのかが切り分けられない。いわゆる sim2real ギャップは、二足歩行のように不安定な系ではとりわけ厳しく表れます。

参照できる実装を探すと、多くの場合は論文付属のコードか、汎用フレームワークに同梱されたサンプルに行き当たります。前者は論文の再現に必要な範囲しか含まれておらず、後者は「どのロボットでも動くように」抽象化されているため、特定の実機で動かし切るための泥臭い部分がそぎ落とされています。学習コードは読めても、実機で動くところまでを一続きで追える公開リポジトリは多くありません。

Hugging Face 傘下の Pollen Robotics が公開している microduck_rl は、この空白にちょうど収まる位置にあります。約 800g・約 25cm のアヒル型二足ロボット「Microduck」のための強化学習環境で、README は自らを「sim2real のレシピ一式をエンコードしたリポジトリ」と説明しています。具体的には、BAM によるアクチュエータ物理、ドメインランダマイゼーション、バックラッシュのシミュレーション、そして機能する結果につながった報酬設計の教訓までが含まれる、という書き方です。

つまりこのリポジトリは、単なる学習スクリプト置き場ではなく、「小型サーボ機を実機で動かし切るために何をモデル化し、報酬設計で何を避けるべきか」という判断の集積として読むことができます。Microduck 実機を持っていない読者にとっても、参照する価値がここにあります。

本記事では、microduck_rl の README・AGENTS.md・公式サイト・関連リポジトリのドキュメントを根拠に、リポジトリの位置づけ、学習基盤と実行要件、用意されているタスク、sim2real を成立させている設計、ポリシーの配布と実機導入の流れ、類似リポジトリとの違い、そして採用判断の目安を整理します。なお本記事は公開ドキュメントに基づく調査であり、インストールや学習の実行による動作検証は行っていません。学習時間などの数値はすべて README の記載値としての引用です。

microduck_rlとは｜アヒル型二足ロボットMicroduckの強化学習環境

microduck_rl は、Pollen Robotics が開発するアヒル型二足歩行ロボット Microduck 向けの強化学習トレーニング環境です。README はこのリポジトリを、mjlab（MuJoCo Warp）上に PPO で構築された、Microduck のための RL トレーニング環境と定義しています。方策はここで 50Hz で学習され、ONNX にエクスポートされ、実機側のランタイムによって実行されます（microduck_rl README）。

重要なのは、このリポジトリが「学習まで」を担当し、「実行」は別リポジトリが担当するという役割分担です。この境界を最初に押さえておくと、以降の設計上の選択がすべて理解しやすくなります。

Microduck 本体については、公式サイトが高さ 25cm・重量 800g・モーター 15 個・カメラと LiDAR と 2 基の IMU という仕様を示しています。価格は導入価格として 399 ドル（税・送料別）、予約開始は 2026 年 8 月 27 日とされています。歩行、座り立ち、キック、つかみ、ローラースケート、自己復帰といった 7 種類のプリトレーニング済み動作が同梱され、それらはすべて再学習が可能である、という位置づけです。公式サイトが示す学習フローは、MuJoCo シミュレーションでの学習（ローカルまたは Hugging Face Jobs）、実機への転送、調整・再学習、コミュニティへの公開、という 4 段階になっています。microduck_rl はこのうち最初の段階と最後の段階を担うリポジトリです。

リポジトリの基本情報

まず、採用判断の前提となる数値を整理します。以下はすべて 2026 年 9 月 17 日時点に GitHub API から取得した値です。

このリポジトリはアーカイブされておらず、他リポジトリのフォークでもなく、無効化もされていません。つまり、開発が停止した過去の資産ではなく、現在も本体として更新されているリポジトリです。最終 push が調査日の前日にあたることからも、更新が継続していることが読み取れます。

ライセンスについては、単に「Apache-2.0」とだけ覚えると誤りになる点があります。README は、3D モデルファイルについては Creative Commons BY-SA-NC でライセンスされる、と別途明記しています。つまりコード本体は Apache-2.0 ですが、3D モデルファイルは非商用条件（NC）が付いた別ライセンスです。ロボットの筐体データを商用製品に流用したいといった用途を検討している場合、この分離は見落とせません。コードの利用可否とモデルデータの利用可否は分けて確認する必要があります。

Microduck本体と2つのリポジトリの役割分担

Microduck のエコシステムは、学習側と実行側の 2 つのリポジトリで構成されます。

この分離によって、学習側は GPU を前提とした重い処理に集中でき、実機側は推論だけを軽量に回せます。両者をつなぐ契約が ONNX のグラフ形状と観測レイアウトであり、この契約が壊れないように学習側が自動チェックを持っている点は、のちほど配布の流れを見るところで触れます。

なお、サーボ数については出典によって表記が異なります。microduck 側のランタイムは 15 サーボを 50Hz の制御ループで駆動すると記載しており、公式サイトも「モーター 15 個」としています。一方、microduck_rl の AGENTS.md は 14 個の Dynamixel XL330 サーボと記載しています。これはランタイムが扱う全モーター数と、学習環境が駆動関節として扱う数の視点の違いと読めますが、公開ドキュメントからどちらかに統一して断定することはできません。本記事では両方を出典付きで併記するにとどめます。実際の関節構成を前提に設計を進める場合は、リポジトリの定数定義を直接確認することをおすすめします。

学習基盤の構成｜mjlabとPPOで何をどう回すか

採用判断で最初の関門になるのは、そもそも自分の手元で回せるかどうかです。ここを先に確認しておきます。

依存スタックと実行要件

microduck_rl の学習基盤は mjlab です。mjlab は Isaac Lab の API を MuJoCo Warp の上に載せた学習フレームワークで、公式ドキュメントが公開されています。強化学習アルゴリズムは PPO（rsl_rl）で、制御周期は 50Hz です。

実行要件として README が明記しているのは、CUDA GPU が必要であること（学習は MuJoCo Warp を通して走るため）と、パッケージ管理に uv を使うことです。GPU を持っていない場合の逃げ道も用意されており、README は任意の train コマンドに --hf-jobs を付けることで、ローカルではなく Hugging Face Jobs 上で実行できると記載しています。手元に CUDA GPU がないという理由だけで検討を打ち切る必要はない、という点は押さえておく価値があります。

もう一点、ARM 機での注意事項が README に注記されています。DGX Spark / GB10 や Jetson では、初回の uv sync が約 2GB の CUDA wheel を取得するため、uv のデフォルトの 30 秒 HTTP タイムアウトではダウンロード中に中断する可能性がある、というものです。初回同期時に UV_HTTP_TIMEOUT=600 を設定するよう推奨されています。こうした環境固有のつまずきが README に書かれていること自体が、実機まで通した経験の反映と読めます。

学習からONNX書き出しまでのコマンドの流れ

README の Quickstart は、学習から実機向け書き出しまでを一続きで示しています。以下は README からの抜粋です。

git clone https://github.com/pollen-robotics/microduck_rl
cd microduck_rl

# train the walking policy (uses your GPU; ~1-2 h for a usable gait at 4096 envs)
uv run train Mjlab-Velocity-Flat-MicroDuck --env.scene.num-envs 4096

# watch a trained policy in the viewer
uv run play Mjlab-Velocity-Flat-MicroDuck --wandb-run-path <entity/project/run_id>

# export to ONNX for deployment
uv run scripts/export.py Mjlab-Velocity-Flat-MicroDuck --wandb-run-path <...>
uv run publish --onnx output.onnx --repo <user>/microduck-<name> --kind episodic --duration-s 4.0   # share it (see "Publishing a policy")

# drive the exported policy in CPU MuJoCo with the keyboard
uv run scripts/infer_policy.py --walking output.onnx

出典: microduck_rl README

コメント行にある通り、README は 4096 環境並列で「使える歩容」が得られるまでの目安を 1〜2 時間と記載しています。これは README の記載値であり、実際の所要時間は GPU の世代や設定によって変わります。

注目したいのは、この 5 コマンドが「学習 → 目視確認 → ONNX 書き出し → 配布 → CPU 上での実行予行」という流れをそのまま表現していることです。多くの RL リポジトリは学習と評価までで終わりますが、ここでは書き出しと配布と実行予行までが Quickstart の中に入っています。学習の成果物をどう実機に届けるかがリポジトリの設計に組み込まれている、ということです。

学習の再開についても、チェックポイントからのレジューム用コマンドが README に用意されています。長時間ランを前提とした運用が想定されていることがうかがえます。

用意されているタスク｜歩行から転倒復帰・ローラースケートまで

microduck_rl が提供するタスクは歩行だけではありません。README には 13 のタスク id がテーブルで並んでおり、uv run list-envs を実行すると実際のレジストリが出力されると記載されています。ドキュメントの一覧が古くなっていても、コマンドで現状を確認できる設計です。

タスク一覧と地形バリエーション

（出典: microduck_rl README）

歩行タスクだけを見れば他の RL 環境と大きな差はありません。この一覧が示しているのは、転倒復帰・前転・ローラースケートといった、歩行とは要求される報酬設計がまったく異なるタスク群を同一リポジトリで扱っているという事実です。デモとしての歩行ではなく、複数の動作を同じ枠組みで作り分けた実績がある、という読み方ができます。

そして、これらの方策は実機上でホットスワップされます。README は、デプロイ時にランタイムが 61 次元の共有観測契約の背後でこれらの方策（歩行・復帰・トリック）を差し替えるため、どの方策でもいつでもロボットを引き継げると記載しています。その予行演習を CPU 上で行うためのコマンドも示されています。

uv run scripts/infer_policy.py --walking walk.onnx --standing stand.onnx \
    --sitstand sitstand.onnx --roulade roulade.onnx --new-cmd-obs

出典: microduck_rl README

このスクリプトはキーボード操作に対応しており、--debug / --save-csv / --record によって sim2real の比較ができると README は説明しています。サーボは学習時と同じ BAM M6 XL330 モデルでシミュレートされ、--vin / --vin-drop-gain / --kp-fw によって学習時のドメインランダマイゼーション範囲を 1 つの値に固定できます。実機に載せる前に、シミュレーション側の条件を意図的に絞って挙動を見るための仕掛けです。

Backlash版ツインが再現しているもの

microduck_rl の設計で特徴的なのが、主要タスクに用意された Backlash（ギアのガタ）版のツインです。タスク id の MicroDuck の前に -Backlash を挿入することで選択します（例: Mjlab-Velocity-Flat-Backlash-MicroDuck）。

README の説明によれば、このバリアントは 14 個のサーボ関節それぞれに直列で ±1 度（合計 2 度）のギア遊びを持つモデルで学習します。注目すべきは、その実装方法です。各サーボに非駆動の passive_<joint>_backlash ヒンジが与えられ、実機のエンコーダが遊びの出力側に位置しているという事実に合わせて、ファームウェアの PD エミュレーション（BacklashEncoderBamActuator）と joint_pos / joint_vel の観測が、遊びを越えた値（qpos[servo] + qpos[backlash]）を読むようになっています。

単に「ガタを乱数で足す」のではなく、実機のセンサがどこに付いているかという物理的な事実をモデルの構造として再現している点が要点です。そのうえで README は、観測次元と行動次元は変わらないため、ONNX の書き出しもランタイム側も変更不要である、と補足しています。sim2real のための追加モデル化が、下流の契約を壊さない形で導入されている、ということです。

安価な小型サーボを使う自作ロボットでは、ギアのバックラッシュは無視できない誤差要因になりがちです。Microduck を持っていない読者にとっても、この実装は参照する価値のある部分です。

sim2realを成立させる設計｜アクチュエータモデルとドメインランダマイゼーション

ここが microduck_rl というリポジトリの核心にあたる部分です。なぜこのリポジトリが「学習コード」ではなく「sim2real のレシピ」を名乗れるのかは、この設計の作り込みに表れています。

アクチュエータを電圧制御則まで落として再現する理由

全タスクは、Dynamixel XL330 向けの BAM M6 アクチュエータモデルを使用しています。BAM は Rhoban が公開しているサーボの拡張摩擦モデル同定・シミュレーションのためのリポジトリで、microduck_rl はそこから電圧制御則、逆起電力、クーロン摩擦・ストライベック摩擦・負荷依存摩擦を取り込んでいます。さらに環境ごとのドメインランダマイゼーションとして、バッテリー電圧、負荷時の電圧降下、コマンド遅延、摩擦の大きさがランダム化されます（FrictionDRBamActuator）。

なぜここまで作り込むのかについて、README は明確な理由を述べています。このスケール、すなわち約 800g の二足機を駆動する小さなサーボにおいては、アクチュエータの忠実度が sim2real ギャップの大半を占める。だからこそアクチュエータは理想的な PD 制御ではなく、その電圧制御則のレベルまでモデル化されている、という説明です（microduck_rl README）。

この一文は、設計判断の根拠として読む価値があります。大型のヒューマノイドであれば、リンクの慣性や接触モデルの寄与が相対的に大きくなります。しかし小型軽量機では、サーボそのものの非理想性が支配的になる。モデル化の労力をどこに配分するかという問題に対して、このリポジトリは「アクチュエータに寄せる」という答えを出しており、その理由が言語化されています。同じ規模のロボットを扱う場合、ここは直接的な参照点になります。

用途別に作り分けられたロボットモデル

MJCF モデルは Onshape から onshape-to-robot でエクスポートされ、用途別に衝突形状が作り分けられています。

（出典: microduck_rl README）

衝突ジオムの数は計算コストに直結します。歩行タスクでは胴体が床に触れる状況を精密に扱う必要がないため接触を削ぎ落とし、起立や前転のように床との接触そのものが課題であるタスクでは接触部位を厳選する。1 つのモデルですべてを賄うのではなく、タスクの性質に応じて精度と速度のトレードオフを切り替えるという方針が読み取れます。完全衝突モデルが「未使用」として残されている点も、必要になったときに切り替えられる余地を残す設計として理解できます。

61次元の共有観測契約とポリシーのホットスワップ

microduck_rl の全方策は、61 次元の共通したアクター観測を持ちます。内訳は 48 次元の固有受容感覚と、13 次元のコマンドブロック [twist(3), head_pose(4), body_pose(6)] です。README が強調しているのは、コマンドスロットを使わない環境であっても、そのスロットを削除するのではなくゼロ埋めする、という規約です。

この一見冗長に見える規約が、実機でのホットスワップを可能にしています。すべての方策が同じ入力形状と同じ出力形状を持つため、ランタイムはどのタイミングでも方策を差し替えられます。歩行中に転倒したら復帰方策に切り替え、復帰したら歩行に戻す、といった制御が、方策ごとの個別対応なしに成立する構造です。

関連して、非駆動関節は一律 passive_* という命名規約に従い、アクチュエータ・関節観測・姿勢報酬のセレクタは ^(?!passive_).* という正規表現で駆動関節だけを選びます。ローラーの受動輪もバックラッシュヒンジもこの命名に従うため、新しい非駆動要素を追加しても既存の選択ロジックを書き換える必要がありません。小さな規約ですが、モデルのバリエーションを増やしていくうえで効いてくる種類の設計です。

ONNXに正規化器を焼き込むという不可侵ルール

README の「知っておく価値のある規約」の最後に置かれているのが、書き出しに関する警告です。エクスポータは観測正規化器を ONNX グラフに焼き込むため、常に scripts/export.py が生成した ONNX をデプロイすること、手変換したチェックポイントは決して使わないこと、さもないと方策は実行時に正規化されていない観測を受け取ることになる、という内容です。

この種の不具合は、学習も推論もエラーなく完走してしまうため発覚が遅れます。方策の出力がおかしいという症状だけが出て、原因が観測のスケールにあるとはなかなか気づけません。だからこそ「唯一の安全な経路」を明示的に定め、それ以外を禁じるという書き方になっているのだと読めます。同じ警告が README と AGENTS.md の双方に置かれている点も、この規約の重みを示しています。

AGENTS.mdに書かれた報酬設計のプレイブック

microduck_rl を読むうえで、README と同じかそれ以上に参照価値が高いのが AGENTS.md です。README はこれを、プロジェクト全体を通じて学ばれた環境構築のワークフローと報酬設計のルールを記録したドキュメントであり、このリポジトリで作業する AI コーディングエージェントにも向けたものだと説明しています。

内容は抽象的な原則論ではなく、プロジェクトが踏んだ失敗から引き出された具体的な指針です。Microduck を採用しない読者にとっても、強化学習で動作を獲得させるプロジェクト全般に転用できる部分が多く含まれています。主要なものを整理します。

スモークテストを必ず先に回す。 AGENTS.md は、長時間の学習を始める前に必ず走らせるべきコマンドとして、64 環境・5 イテレーションの短時間ランを挙げています。これで設定ミスの約 95% を安価に検出できる、という位置づけです。

uv run train <TASK_ID> --env.scene.num-envs 64 --agent.max_iterations 5   # SMOKE TEST — always run first

出典: AGENTS.md

報酬の符号規約を取り違えない。 mjlab 由来のコスト関数は 0 以上の値を返すため負の重みを与え、microduck 独自の自己否定型の関数（*_penalty / *_l1 といった、0 以下を返すもの）には正の重みを与えます。これを取り違えると、違反行為に対して報酬が付いてしまい、方策は当然それを稼ぎにいきます。AGENTS.md はその結果として現れる挙動に名前を付けており、尻でのホッピングや衝突するような座り込みが例として挙げられています。検査方法も具体的で、wandb 上のすべての Episode_Reward/<penalty> が 0 以下であることを確認する、という形で示されています。

強化学習は報酬の字面を最適化する。 規定されていない自由度は必ず悪用される、というのが AGENTS.md の立場です。そのため「何をもってその動作とみなすか」は、小さなペナルティで示唆するのではなく、接触・姿勢軸・ラッチといった状態ベースのハードゲートとして表現するべきだとしています。ペナルティで「なんとなく望ましくない」と伝えるのではなく、条件として「そうでなければ成立しない」と定義する、という考え方です。

ジャックポットを作らない。 「ある状態に到達したら報酬」という設計は、目標状態に早く到達してから毎ステップ稼ぎ続ける構造を生みます。そうして貯めた報酬は、その前段のどれだけ乱暴な動きも買えてしまう原資になります。AGENTS.md はこれに対し、レート制限を入れるか、一定速度で進む内部目標（スルー）を設ける、という対処を示しています。

悪い状態を条件に正の報酬を出さない。 転倒中や極端な低姿勢といった状態を条件に正の報酬を与えると、方策は最も安上がりにその姿勢を取り続けて稼ぎます。代わりに推奨されているのが、ポテンシャルベースの報酬整形です。状態そのものではなく進捗の差分（例として Δcos(tilt)）に報酬を与えるという形です。

正則化は重みではなく報酬の総量で比較する。 ある環境から別の環境へ正則化項をコピーするとき、同じ重みを使えば同じ効果が得られるとは限りません。PPO は相対的なアドバンテージを見るため、正の報酬スタックが 4 倍ある環境では、同じ重みの正則化は 4 分の 1 の効き目になります。あわせて AGENTS.md は正則化を 2 種類に分けています。動作を阻害する系（角速度、角運動量、姿勢分散）は動的なタスクでは低く抑え、平滑化系（action_rate、トルク変化率）はスキルを獲得した後にカリキュラムで導入する。探索の最中に行動へ税をかけると「何もしない」が最適解になってしまうためです。

ドメインランダマイゼーションをリセットをまたいで累積させない。 mjlab 1.3.0 の dr.* は非累積ですが、独自の DR 関数を書く場合は「復元してから適用する」必要があります。AGENTS.md には、累積してしまう重心ランダマイザが数か月にわたって長時間ランの品質を劣化させていた、という記述があります。

これらはいずれも、公開ドキュメントとして読める形で残されている点に価値があります。強化学習の報酬設計は経験則の比重が大きく、うまくいかなかったパターンが共有される機会は多くありません。microduck_rl を採用しない判断に至った場合でも、このドキュメントは持ち帰る価値があります。

学習したポリシーを実機と配布まで運ぶ流れ

microduck_rl が学習だけで終わらない設計であることは、uv run publish の存在に表れています。README によれば、このコマンドはロボットのデーモンが読み込む形のまま、方策を Hugging Face Hub に配置します。アップロードされるのは、観測正規化器を焼き込んだ policy.onnx、microduck policy manifest の schema 2 に従う manifest.json、そして実行方法を説明した README の 3 点です。Microduck を持っている人は、デーモンのリリースを待つことなく、1 つのコマンドでそれをインストールできる、と説明されています。

注目したいのは、アップロード前に走る自動ゲートです。README は、publish が実行する検査を具体的に列挙しています。グラフの形状が [1,61] -> [1,14] であるかの確認（51 次元の旧世代の方策はメッセージ付きで拒否されます）、妥当な入力で実行して NaN や定数出力になっていないかの確認、git と wandb からの training ブロック（タスク・コミット・ブランチ・dirty フラグ・ラン・チェックポイント）の補完、そして既存の .onnx を --force なしに上書きすることの拒否です。リポジトリは既定で private として作成され、公開するには --no-private を、リビジョンにタグを付けるには --tag v1 を指定します。

配布物の壊れ方をあらかじめ列挙し、それを機械的に弾く仕組みを持っているという点は、プロジェクトの成熟度を測る材料になります。特に「51 次元の旧ポリシーを拒否する」という記述は、観測契約が過去に一度変更されており、その移行に伴う事故を経験として持っていることを示唆しています。

実機側への導入は、以下のコマンドで行うと README は示しています。

sudo robotctl policy add polite-bow <user>/microduck-polite-bow   # episodic: length comes from the manifest
sudo robotctl policy add flamingo <user>/microduck-flamingo --hold 5   # held pose: you pick how long
sudo robotctl policy load walk <user>/microduck-my-walk                # gait: into the walk slot
robotctl robot do polite-bow

出典: microduck_rl README

方策の種別を指定する --kind には 2 つの値があります。episodic は --duration-s の間だけ動作して自ら立位に戻るもので、キックや前転、お辞儀といった動作が該当します。perpetual は指示があるまで動き続けるもので、さらに 2 つの形に分かれます。歩容（新しい歩き方や立ち方）の場合は --slot walk（または stand）を指定し、保持姿勢（片足立ちのような動作）の場合は --unwind-s を与えます。後者は、デーモンがアイドル用の twist を駆動してから歩容に制御を戻すまでの時間で、ロボットが片足立ちのまま放り出されないようにするための指定です。

ただし制約もあります。README は、この方法で公開できるのは定数コマンドの方策のみだと明記しています。フェーズ駆動の動作（床からのつかみ動作）や、姿勢フラグで駆動される座り↔立ちは、デーモン自身が駆動するため公式セットである pollen-robotics/microduck-policies に属する、という切り分けです。コミュニティが自由に配布できる範囲と、本体側が管理する範囲が線引きされていることになります。

テストについても、CPU だけで走るリグレッションテストが同梱されています。

uv run --with pytest pytest tests/

出典: microduck_rl README

README はこれを、関節インデックスの対応、報酬の符号規約、NaN ガードを固定するための、CPU のみで実行できる設定不変条件と報酬関数のリグレッションテストであると説明しています。GPU を持たない環境でもリポジトリの整合性チェックだけは回せる、という構成です。

類似リポジトリとの違い｜Open Duck・MuJoCo Playgroundとの棲み分け

採用判断で避けて通れないのが、他の選択肢との比較です。以下の数値はすべて 2026 年 9 月 17 日時点に GitHub API から取得した値です。

Open_Duck_Mini は、Disney の BDX ドロイドのミニ版を自作するコミュニティプロジェクトです。microduck_rl との最大の違いはハードウェアの入手方法にあります。Open Duck Mini は機構と電装の製作から始まる DIY 前提のプロジェクトであり、BOM と 3D プリントが出発点になります。対して Microduck は 399 ドルの完成品として予約販売されています。ロボット本体を作ること自体に価値を見出すのか、学習と制御に集中したいのかで、選ぶべき側が変わります。

Open_Duck_Playground は、Open Duck プロジェクト向けの MuJoCo Playground ベースの RL 環境です。位置づけとしては microduck_rl に最も近い存在ですが、業務での利用を検討する場合は 2 点の確認が必要です。1 つはライセンスが未設定であること。GitHub 上でライセンスが特定されていないリポジトリは、原則として著作権法上の既定の扱いになるため、社内のライセンス審査を通す際にハードルになります。もう 1 つは最終 push が 2025 年 8 月であり、microduck_rl（2026 年 9 月）との間に更新頻度の差があることです。設計思想の面では、Open Duck 系は BDX 論文に由来する模倣報酬と参照動作生成器を軸にしており、参照する動作データを前提とします。一方、microduck_rl の README と AGENTS.md には参照動作に関する記述がなく、報酬設計とハードゲートによって挙動を規定する方針が取られています。模倣データを用意できるかどうかが、両者の前提条件の違いになります。

mujoco_playground は、GPU 加速による ロボット学習と sim2real のための汎用ライブラリで、複数のロボットを横断的にカバーします。microduck_rl とは抽象度の階層が異なります。汎用基盤は「多くのロボットで動くこと」を優先するため、アクチュエータは理想的な PD をベースにするのが標準的です。microduck_rl は単一のハードウェアに専念し、MJCF もサーボモデルも観測契約も実機に合わせて作り込んでいます。汎用性と忠実度のトレードオフで、正反対の位置にあると言えます。

mjlab は、microduck_rl が依存している学習フレームワークそのものです。Isaac Lab の API を MuJoCo Warp の上に載せた構成で、Unitree G1 などの汎用サンプルを同梱しています。両者は競合ではなく積層関係にあり、microduck_rl は mjlab の上に「1 台のロボットを実機で動かし切るための層」を載せたものだと理解するのが正確です。mjlab の更新が 2026 年 9 月 16 日と microduck_rl と同日である点は、依存関係が生きていることの傍証になります。

構造が近い例として、unitreerobotics/unitree_rl_gym（3,553 / 586・BSD-3-Clause・2025 年 7 月 25 日 push）も挙げられます。特定メーカーのハードウェア専用の RL 環境という点で microduck_rl と同じ立ち位置にありますが、最終 push には 1 年以上の差があります。

以上を整理すると、比較の軸は次の 5 つに集約されます。対象ハードウェアが固定か汎用か、ハードウェアの入手性（完成品か自作か）、模倣参照データの要否、アクチュエータのモデル化の深さ、そして学習で終わるか配布と実機運用の契約まで含むか。microduck_rl はいずれの軸でも「特定ハードに寄り切る」側に立っており、それが強みであると同時に、そのまま他のロボットへ持ち込めない制約にもなっています。

採用判断の目安｜microduck_rlが向くケースと向かないケース

ここまでの整理を踏まえ、公開ドキュメントから読み取れる範囲で判断材料をまとめます。

向いているケース

• Microduck の実機を所有している、または購入を検討している。この場合は事実上の標準的な学習環境になります
• CUDA GPU を利用できる、または Hugging Face Jobs を使える。--hf-jobs により GPU 非所持でも検討の余地があります
• 小型サーボ機の sim2real 設計を参照したい。BAM によるアクチュエータモデル、ドメインランダマイゼーションの対象選定、バックラッシュの構造的なモデル化は、対象ロボットが異なっても設計判断の参考になります
• 強化学習の報酬設計で繰り返し失敗している。AGENTS.md の内容は、Microduck 固有の記述を除けば汎用的に読めます
• 学習だけでなく、方策の配布と実機への導入までを含めた運用設計の実例を見たい

慎重に判断したほうがよいケース

• Microduck 以外のロボットにそのまま流用したい。MJCF もサーボモデルも 61 次元の観測契約も Microduck の実機を前提に作られているため、移植には相応の書き換えが必要になります。汎用性を求める場合は mjlab や mujoco_playground の側から入るほうが適合します
• GPU が用意できず、Hugging Face Jobs も利用できない。学習は MuJoCo Warp を通して走るため、CPU のみでは学習フェーズを回せません（CPU で回せるのは推論予行とリグレッションテストです）
• 3D モデルファイルを商用目的で利用したい。コードは Apache-2.0 ですが、3D モデルファイルは CC BY-SA-NC であり非商用条件が付きます。この分離は社内のライセンス審査で必ず論点になります
• ロボット本体の製作そのものを目的としている。この場合は自作前提の Open Duck Mini 系のほうが目的に合致します

メンテナンス状況の見方

公開情報から読み取れる健全性の指標としては、最終 push が 2026 年 9 月 16 日と直近であること、アーカイブもフォークもされていない本体リポジトリであること、依存先である mjlab も同日に更新されていること、そして CPU だけで走るリグレッションテストが同梱されていることが挙げられます。テストが「関節インデックスの対応」「報酬の符号規約」「NaN ガード」という、事故が起きやすい箇所を固定している点は、運用の実態を反映した構成と読めます。

ただし、本記事はドキュメントに基づく整理であり、学習の実行や実機での再現性の確認は行っていません。README が記載する学習時間や挙動が自分の環境で再現されるかどうかは、各自で確認する必要があります。検討を進める場合は、まず AGENTS.md が推奨する 64 環境・5 イテレーションのスモークテストが自分の GPU で通るかを確かめるのが、最も低コストな最初の一歩になります。

まとめ

microduck_rl は、2 つの異なる読み方ができるリポジトリです。

1 つは、そのままの位置づけ、すなわち Microduck という特定のハードウェアのための強化学習環境としての読み方です。この観点では、Microduck 実機を持っているかどうかが採用の分かれ目になります。MJCF もサーボモデルも観測契約も実機に合わせて作り込まれているため、他のロボットへの流用は容易ではありません。汎用性を求めるなら、依存元である mjlab や mujoco_playground の側から入るのが筋です。

もう 1 つは、小型サーボ機の sim2real レシピと報酬設計の教訓が言語化された参照実装としての読み方です。こちらは実機の有無にかかわらず価値があります。約 800g の二足機ではアクチュエータの忠実度が sim2real ギャップの大半を占めるという判断と、それに基づいて電圧制御則までモデル化するという選択。実機のエンコーダ位置に合わせてバックラッシュを構造的に再現し、それでも観測次元を変えずに下流の契約を守るという設計。そして、報酬の符号規約からジャックポットの回避、ドメインランダマイゼーションの累積事故まで、プロジェクトが踏んだ失敗として AGENTS.md に残された記録。これらは、対象のロボットが何であれ、強化学習で動作を獲得させようとする人にとっての参照点になります。

強化学習の実装では、うまくいった構成は論文や記事として共有される一方、うまくいかなかった構成が共有される機会は多くありません。microduck_rl が公開ドキュメントとして後者を残している点は、このリポジトリを評価するうえで見落とすべきでない部分です。採用を検討する場合も、参照だけにとどめる場合も、README と AGENTS.md の最新の記述を直接確認したうえで判断することをおすすめします。

関連情報

機械学習を組み込んだシステムの設計や、検証環境から本番運用までを見据えた開発体制についてご相談がある場合は、お問い合わせフォーム からご連絡ください。要件が固まる前の段階からご相談いただけます。