注文書ピッキングロボットの VLA 設計 ― SmolVLA で同じ部品が並ぶ環境をどうピッキングするか

本記事は前後編の 後編 です。WorkPeer・Order Contract・Robot Gateway による全体設計は 前編「手書きの注文書から、ロボットのピッキングへ」 を先にお読みください。

前編では、WorkPeer が注文書を読み取り、Order Contract という構造化タスクを Robot Gateway へ渡すところまでを説明しました。後編ではその先の物理実行に踏み込みます。Robot Gateway が「この 1 個」と選んだ対象を、ロボットが実際にどうやってつかむのか。ここで登場するのが VLA（Vision-Language-Action）モデルです。

ただし、今回のタスクは「目の前の物を 1 つつかむ」だけでは終わりません。

机の上には同じ種類の長いネジが何本も並んでいて、短いネジは見た目がよく似ています。ワッシャーは薄く、2 枚重なっていることもあります。注文には数量があり、1 個取るたびに机の状態が変わります。

この記事を通じてお伝えしたいのは、ひとつの設計方針です。

VLA にすべてを任せるのではなく、VLA が解く問題をできるだけ小さくする。

注文の解釈、数量の管理、つかむ対象の選択、最終検証はすべてモデルの外側で処理し、VLA には**「すでに選ばれた 1 個をつかんで運ぶ」という物理スキルだけ**を担わせます。

図1：VLA に広い問題を丸投げする（左）のではなく、VLA の担当範囲を絞り込む（右）。

この記事でわかること

• ベースモデルに SmolVLA を選んだ理由と、他の VLA（Octo, OpenVLA, π₀）との比較
• どんな環境で、どうやって学習データを集めたか
• smolvla_base をどうファインチューニングしたか
• 推論をリアルタイムで回すための工夫（非同期推論・action chunk・temporal ensemble）
• 「つかめたかどうか」ではなく「注文を満たせたかどうか」で評価する仕組みと、失敗を学習データに戻すループ

---

ベースモデル：なぜ SmolVLA なのか

VLA をゼロから作るのは現実的ではありません。公開されている軽量モデルをベースにして、自分たちのタスクに合わせてファインチューニングする方針を採りました。選んだのは Hugging Face が公開している SmolVLA（arXiv:2506.01844）です。

SmolVLA の構成

図2：SmolVLA のアーキテクチャ。VLM と Action Expert の 2 段構成。

SmolVLA は合計 4.5 億パラメータ（450M） の小型 VLA で、中身は大きく 2 つに分かれています。

VLM 部分（約 350M）：SmolVLM-2 系の軽量な Vision-Language Model です。複数のカメラ画像と言語指示を受け取って、視覚と言語の特徴量を一つにまとめます。計算量を抑えるため、ViT（Vision Transformer）の中間層を半分スキップして視覚トークンの数を約 50% 削減する工夫が入っています。これにより、画像あたりのトークン数が数百レベルに収まり、推論が軽くなります。

Action Expert（約 100M）：VLM が出力した特徴量を受け取り、数ステップ先までの連続的な動作（action chunk）をまとめて生成するモジュールです。内部では Flow Matching という生成手法を使っています。

Flow Matching とは

Flow Matching は、確率的生成モデルの一種です。直感的に説明すると：

• 回帰モデル（MSE loss）：「正解の 1 点」を予測する。問題は、同じ観測から複数の正解パスがある場合（たとえば右から回り込んでもいいし左から回り込んでもいい場合）、予測値がその平均になってしまい、どちらでもない中途半端な動作を出力すること
• Diffusion Policy：ノイズから逆拡散プロセスで動作を生成する。マルチモーダルな分布をうまく扱えるが、推論時に数十ステップの iterative denoising が必要で、リアルタイム性にやや難がある
• Flow Matching：ノイズから目標軌道へ「真っ直ぐ近づく流れ」を学習する。Diffusion と同様にマルチモーダルな分布を扱えるが、推論時のステップ数が少なく済むのが利点。SmolVLA の Action Expert では数ステップ（4〜8 程度）で軌道を生成しており、リアルタイム制御に必要な速度を確保しています

他の VLA との比較

SmolVLA を選んだのは、SO-101 + consumer GPU という制約下で、言語理解と推論速度のバランスが最も良かったからです。

---

データ収集

ファインチューニングの結果を左右するのは、モデルのアーキテクチャよりもデータの質であることが多い、というのが実機を触ってきた実感です。

Leader-Follower テレオペレーション

データ収集には SO-101 の Leader-Follower テレオペレーションを使います。これは、2 台の同型アームをシリアルバスで直結し、人間がリーダー側を動かすとフォロワー側がリアルタイムに追従する仕組みです。

Leader 側の各サーボから現在角度を読み取り（STS3215 の Position Read コマンド）、それを Follower 側のサーボに目標角度として書き込む。この間の遅延は数ミリ秒で、人間は直感的にフォロワーアームを操作できます。

同時に、フォロワー側のカメラ映像・関節角度・実行アクション・タイムスタンプが LeRobot のデータセット形式（Apache Parquet + 画像/動画ファイル）で記録されます。

何を変えながら集めるか

データ収集で最初に決めるのは、「どういう変化に対してロバストにしたいか」 です。

• 同じ部品の個数、配置、向き、密集度
• 照明と背景の条件（蛍光灯、窓からの自然光、LED スポット）
• 箱の位置（5cm 単位でずらす）、注文の数量パターン
• 注文対象ではない部品が混ざっている状況（ディストラクター）

実用上、ディストラクターの有無が精度に最も影響しました。短いネジと長いネジが混在している状態でのデータを十分に含めないと、認識〜把持の一連の精度が大きく下がります。

評価用のデータには、学習中に一度も見ていない配置を必ず含めます。

エピソードはスキル単位で短く切る

注文全体を 1 本の長いログとして記録するのではなく、動作のスキルごとに短く分割します。

データの段階で先に潰しておくべき問題

同じ部品が並ぶと狙いが定まらない

長いネジが 4 本あって注文が 2 本のとき、「長いネジをつかめ」とだけ教えると、4 本のどれも正解になってしまい、推論のたびに狙いがふらつきます。これは multimodal action distribution の問題で、学習データだけで解決しようとするとかなり大変です。

解決策はモデルの外側にあります。前編で説明したとおり、認識モデルが候補を検出し、Robot Gateway が object_id を割り振って「この 1 個」を確定させます。VLA には確定済みの対象のバウンディングボックスやマスクを含む観測を渡すことで、アクション分布を single-mode に絞り込みます。

グリッパが閉じるタイミングのずれ

テレオペレーションで集めたデータは、映像上は成功しているように見えても、実は映像・関節状態・アクション指令のタイムスタンプが微妙にずれていることがあります。

USB シリアルの通信遅延（STS3215 は半二重 UART のため、Read → Write のラウンドトリップに 1〜2ms）、カメラのローリングシャッター遅延、OS レベルのバッファリングが重なると、映像ではまだ触れていないのにアクションログではグリッパが閉じ始めている、という状態が生じます。

対策は、グリッパの開閉を単なる連続値ではなく接触イベントとして検査することです。具体的には、グリッパ角度の変化率が急に小さくなった瞬間（何かに当たった＝対象物を挟んだ）を接触時刻とみなし、アクションログ上の閉じ開始時刻との差を計算します。ずれが閾値（たとえば 100ms）を超えるエピソードは除外するか、タイミングを補正します。

---

ファインチューニング

学習は SmolVLA の事前学習済みチェックポイント smolvla_base を起点にします。smolvla_base は Open X-Embodiment データセットの一部（約 2.9 万エピソード、50 以上のタスク）で事前学習されており、基本的な操作スキルの表現をすでに獲得しています。

学習の実行

LeRobot の学習スクリプトを使えば、実行自体は 1 コマンドです。

python lerobot/scripts/train.py \
  --policy.path=lerobot/smolvla_base \
  --dataset.repo_id=<自分の注文書ピッキングデータ> \
  --batch_size=64 \
  --steps=20000 \
  --lr=1e-4 \
  --wandb.enable=true

学習率のスケジュールは cosine decay を使い、最初の 1000 ステップを warmup に充てます。1× RTX 4090 で約 4〜6 時間。A100 なら 2〜3 時間で完了します。

VLA に学ばせること・学ばせないこと

コマンドそのものより大事なのは、何を VLA に学ばせて、何を学ばせないかの線引きです。

学ばせるもの ―― 物理的なスキル：

• 対象に近づく（approach）
• 位置の微調整をする（alignment）
• つかむ直前の手先の姿勢を合わせる（pre-grasp pose）
• グリッパを閉じてつかむ（grasp）
• 箱まで運んで置く（transport + place）

学ばせないもの ―― 業務判断・安全・状態管理：

• 注文の数量管理
• 部品マスタとの照合
• 信頼度が低い場合の承認判断
• 安全停止の条件（関節トルク異常、衝突検知）
• 箱の中身の最終検品

後者は追跡可能性（traceability）が重要な領域です。なぜその判断になったかをあとから監査できる必要があるため、VLA の潜在空間に埋め込むのではなく、明示的なロジックとして実装します。

この「高レベルの判断と低レベルの動作制御を分ける」アプローチは、Google DeepMind の SayCan（2022）、RT-2（2023）、そして Physical Intelligence の π₀（2024）でも共通して採用されている考え方です。

---

推論と実行 ―― 実機で滑らかに動かすために

学習したポリシーをそのまま実機に載せると、手先が小刻みに震えることがあります。推論の遅延、action chunk の切れ目、センサーノイズ、サーボの速度リミット不足など、いくつかの要因が重なって起きる現象です。

非同期推論と Temporal Ensemble

図3：非同期先読み推論と Temporal Ensemble で chunk の切れ目を滑らかにつなぐ。

SmolVLA は action chunk（数ステップ分の動作を一度に出力する）方式を採用しています。chunk サイズは典型的に 5〜10 ステップ（30Hz で 167〜333ms 分の動作）です。

ただし、chunk の境界で動きが不連続になりやすいのが弱点です。対策は 2 つあります。

① 非同期先読み推論：現在の chunk を実行している間に、最新の観測を使って次の chunk の推論をバックグラウンドで走らせます。これにより、chunk が尽きる前に次の chunk が準備完了している状態を維持します。

② Temporal Ensemble：連続する chunk の重なり部分を指数移動平均（EMA）でブレンドします。

blended_action[t] = α × new_chunk[t] + (1-α) × old_chunk[t]

α は 0（完全に古い chunk）から 1（完全に新しい chunk）へ、overlap 区間で線形に遷移させます。LeRobot の Real-Time Chunking 実装ではこの α のスケジューリングを自動で行っており、chunk サイズと overlap 幅だけ指定すれば使えます。

この 2 つの組み合わせにより、VLA の推論に 50ms 以上かかっても、ロボットは 30Hz で途切れなく動き続けます。

コントローラ側の安全制約

• 速度と加速度の上限：STS3215 には内蔵の速度リミット機能がありますが、それとは別にソフトウェア側でも制限をかけます。急激な目標変更によるサーボの過負荷を防ぐためです
• 可動域のクリッピング：VLA が異常な出力（関節可動域外の値）を出した場合、安全な範囲に丸める。これは学習データの正規化ミスや、未見の観測に対するモデルの外挿エラーへの対策です
• 最終接近の低速化：対象物から 3cm 以内に入ったら速度を半分に落とし、接触後はグリッパの状態を優先する

グリッパの扱いには要注意です。腕の動きには平滑化フィルタをかけても問題ありませんが、グリッパまで同じように平滑化すると、閉じのタイミングが遅れて対象物を取り逃します。グリッパの開閉は、VLA の出力がバイナリ的な閾値（たとえば 0.5）を超えた瞬間にトリガーする離散制御とし、平滑化の対象外にしています。

2 個まとめてつかんでしまう問題

ワッシャーのような薄い小物では、2 個いっぺんにつかんでしまうことがあります。VLA の改善ではなく、候補選択の段階でフィルタリングするのが効果的です。

対象の周囲のクリアランスを評価し、隣の部品との距離がグリッパ開口幅の 120% 未満であれば、その候補をスキップするか、人間に確認を求めるフローに分岐します。

---

成功の定義と改善ループ

ロボットの評価では、つい「つかめたかどうか（pick success rate）」に目が行きがちです。もちろん大事な指標ですが、注文書ピッキングではこれだけでは足りません。

段階ごとに成功率を追う

（数値は説明用のイメージです）

つかめても注文全体が通る率はかなり低くなります。この差（92% → 79%）が**「つかめること」と「注文を満たすこと」のギャップ**で、上方カメラによる箱内検証をやって初めて見えてくる数字です。

失敗はレイヤーごとに分類する

実機のデモは、一度訓練したら終わりではありません。重要なのは、失敗を**「VLA が悪い」で片付けない**ことです。

データ改善ループ

図4：失敗をレイヤーごとに分類してデータ収集に戻す改善ループ。

失敗をレイヤーごとに分類しておくと、「次にどんなデータを集めればいいか」 が見えてきます。

① データ収集（どの変動に対してロバストにしたいか決める）
    ↓
② ファインチューニング（スキル単位のクリーンなデータで学習）
    ↓
③ 実機テスト（注文ピッキング＋箱内検証）
    ↓
④ 失敗をレイヤーごとに分類（認識？ 把持？ 制御？ 検証？）
    ↓
⑤ 不足しているデータや設定を特定
    ↓
① に戻る

このループを 勘ではなく、失敗分類のデータに基づいて回すのが鍵です。

実運用では、Robot Gateway が各ピッキングジョブの実行ログを自動で保存しています。

このログが、次のデータ収集の方針を決めるフィードバック信号になります。たとえば「把持失敗が 60% を占める」なら VLA のデモデータを増やし、「認識の取り違えが 40%」なら認識モデルのデータを増やす、という判断をデータに基づいて行えます。

---

まとめ

注文書ピッキングで VLA を使うむずかしさは、モデルの大きさではありません。同じ部品が何本も並ぶ中から対象を 1 個に絞り、取るたびに状態を更新し、2 個同時把持を防ぎ、グリッパのタイミングを合わせ、箱の中身まで含めて「成功」を定義できるかどうかにかかっています。

だからこそ、

• ベースには手元で回せる SmolVLA（450M, Flow Matching）を使う
• VLA には 「選ばれた 1 個をつかんで運ぶ」物理スキルだけを学ばせる
• その周囲に、候補選択、状態管理、コントローラの安全制約、箱内検証、データの収集・改善ループを配置する

前編で設計した「AI とロボットの役割分担」と、この「VLA の問題を絞り込む」方針がセットで揃って初めて、紙の注文書からロボットのピッキングまでが、デモで終わらず、失敗を分析して育てていけるシステムになります。

👈 全体設計（WorkPeer・Order Contract・Robot Gateway）については 前編「手書きの注文書から、ロボットのピッキングへ」 をご覧ください。

---

参考リンク

• WorkPeer - Black AI
• SmolVLA (arXiv:2506.01844)
• SmolVLA (Hugging Face Blog)
• SO-ARM100 / SO-101 (The Robot Studio)
• LeRobot
• LeRobot Real-Time Chunking
• Diffusion Policy (Chi et al., RSS 2023)
• SayCan (Google DeepMind)
• Octo (UC Berkeley)
• OpenVLA (Stanford)
• π₀ (Physical Intelligence)
• Open X-Embodiment