手書きの注文書から、ロボットのピッキングへ ― WorkPeer と Robot Gateway の役割分担

本記事は前後編の 前編 です。VLA（SmolVLA）の学習・推論・改善ループの詳細は 後編「注文書ピッキングロボットの VLA 設計」 で扱います。

紙の注文書をスマートフォンで撮って WorkPeer に送ると、AI が中身を読み取り、机に並んだ部品をロボットが 1 個ずつ箱に入れていく。動画を見ると「AI が注文を読んで、そのままロボットに指示している」ように見えるかもしれません。

でも、実際に作ってみると一番むずかしいのは「読み取った内容を、どうやって動作に変えるか」の部分でした。

たとえば手書きの「長いネジ 2本」。人間にとっては十分な指示ですが、ロボットにとっては曖昧な入力でしかありません。どの型番なのか、在庫単位はどうなっているか、どの箱に入れるか、検出の確信度がどこまであればつかんでよいか、失敗したらどうするか、何が揃えば「完了」なのか――何も決まっていないからです。

この曖昧さを、誰が・どこで・どうやって埋めるのか。 この記事ではその設計判断を掘り下げます。注文の「意味」を理解する WorkPeer と、物理的な動作を担う Robot Gateway の間に、どういう役割分担を敷いたのか。そして実際に SO-101 というアームの動きにどうつながっているかを、順を追って説明していきます。

VLA（Vision-Language-Action モデル）の訓練や把持ポリシーの詳細は後編で扱います。

図1：WorkPeer × ロボットによる注文票ピッキング自動化の全体像。

この記事でわかること

• 注文書を OCR / VLM で「読む」だけでは、なぜロボットを動かせないのか
• AI とロボットの責務をどこで分けるか、という設計パターン
• WorkPeer とロボットをつなぐ Order Contract の仕組みとライフサイクル
• WorkPeer から SO-101 まで、制御が実際にどう伝わるか
• OpenAPI / MCP / A2A / ROS 2 Action の使い分け

---

「読めた」のはスタートにすぎない

注文書を OCR や VLM（Vision-Language Model）にかけると、「長いネジ 2本、短いネジ 3本」のようなテキストが得られます。ここまでは比較的うまくいきます。問題はその先です。

手書き日本語ならではの難しさ

実際に扱ってみると、手書きの日本語の OCR にはいくつか固有の課題があります。

• 崩し字と略字：「長」を「长」に近い形で書く人、数量の「2」を「z」のように走り書きする人がいる。VLM（たとえば GPT-4o や Gemini）は前後の文脈から推測できることが多いですが、確信度が低い場合にそれをどう扱うかは、モデルの外で決める必要があります
• 表形式のずれ：手書きの注文票には罫線があっても、記入がずれていることがほとんどです。品名と数量の対応が行単位で崩れていると、OCR 精度が高くても意味のある構造化ができません
• 略称と表記ゆれ：「M4×30」「長ねじ」「ロングスクリュー」が全部同じ部品を指す。この正規化は VLM の仕事ではなく、部品マスタとの照合ロジックの仕事です

つまり OCR / VLM は入力の第一段階にすぎず、その出力を部品マスタとの照合・数量の正規化・承認・実行条件・検証条件まで含んだ構造化タスクに変換して、ようやくロボットが動ける形になります。

---

LLM の出力をそのままロボットに渡してはいけない

ここで、やりがちだけど避けたい設計パターンがあります。AI エージェントに「この注文書どおりに部品を集めて」と指示し、その出力を直接ロボットに流す構成です。

デモとしてはわかりやすいのですが、失敗したときに原因を特定できないのが致命的です。

たとえば、箱の中身が注文と違っていたとしましょう。原因の候補はいくつもあります。

• OCR が手書き文字を読み間違えた
• 部品マスタとの紐付けを誤った
• 認識モデルが似た部品を取り違えた
• 把持の軌道がずれて隣の部品をつかんだ
• そもそも箱の中身を検証していなかった

これらが 1 回の巨大な LLM コールの中にまとめて入っていると、どこを直せばいいのかわかりません。原因がわからなければ、改善しようがない。これが最大の問題です。

AI とロボットの責務をはっきり分ける

そこで、AI とロボットの間に構造化されたタスク仕様を挟んで、役割を明確に分離します。

図2：LLM 直結（左）と、役割を分けて構造化する設計（右）の比較。

• WorkPeer が担うこと：注文の意味を理解する、部品マスタと照合する、数量を正規化する、承認する、実行ログを残す
• Robot Gateway が担うこと：カメラで観測する、つかむ対象を選ぶ、実際にアームを動かす、箱の中身を検証する

この設計は Google DeepMind の SayCan や Inner Monologue と同じ思想です。高レベルの「何をするか」（semantic planning）と低レベルの「どう動くか」（motor control）を分離し、間に明確なインターフェースを置くことで、各レイヤーを独立に改善できるようにします。

この 2 つをつなぐのが、次に説明する Order Contract です。

---

Order Contract ―― WorkPeer とロボットの共通言語

WorkPeer が読み取った注文は、Order Contract という形で Robot Gateway に渡します。法的な契約書の話ではなく、「AI 側の解釈結果」と「ロボット側の実行条件」を 1 つにまとめた仕様書、と考えてください。

図3：Order Contract は AI の解釈結果とロボットの実行条件をひとつにまとめた仕様。

たとえば手書きの「長いネジ 2本」は、Robot Gateway に届く時点ではこうなっています。

{
  "order_id": "ORD-2026-0630-014",
  "source": {
    "type": "handwritten_form",
    "image_id": "img_8842",
    "ocr_confidence": 0.91
  },
  "items": [
    {
      "part_id": "SCREW-M4-30",
      "display_name": "長いネジ",
      "quantity": 2,
      "unit": "pcs",
      "bin": "BIN-A",
      "min_confidence": 0.85,
      "pick_constraint": "one_by_one",
      "verify": "count_and_class"
    }
  ],
  "approved_by": "ops_user_03",
  "status": "approved",
  "created_at": "2026-06-30T08:14:00+09:00"
}

ポイントは、part_id のような WorkPeer が解決した解釈結果と、min_confidence や pick_constraint のような Robot Gateway が従う実行条件が同居していることです。

Robot Gateway はこの 1 枚だけを見ればよく、注文書の画像を読み直す必要はありません。WorkPeer も、ロボットの関節やグリッパの物理的な制約を知る必要がありません。

Order Contract のライフサイクル

実運用では、Order Contract は次の状態を遷移します。

draft → approved → executing → verifying → completed
                                    ↓
                             partially_failed → retry / escalate

• draft: WorkPeer が OCR / VLM で読み取った直後。まだ承認されていない
• approved: 人間またはルールベースのチェッカーが内容を確認し、実行を許可した状態
• executing: Robot Gateway がピッキングを実行中
• verifying: ピッキング完了後、カメラで箱の中身を検証中
• completed: 数量・品目ともに正しいことが確認された
• partially_failed: 一部の品目が失敗。リトライするか人間にエスカレーションするか判断する

このライフサイクルがあることで、dry-run（事前確認）、二重実行の防止（order_id の重複チェック）、進捗追跡とキャンセルが自然に実装できます。

物理世界での二重実行は在庫の二重消費に直結するため、API レイヤーでの冪等性（idempotency）チェックは特に重要です。HTTP の Idempotency-Key ヘッダーと同様のパターンで、order_id の重複リクエストをリジェクトします。

---

WorkPeer から SO-101 まで ―― 実際の制御パスをたどる

Order Contract が「何を実行するか」を固定することはわかりました。では、それが実際に SO-101 というロボットアームの動きにどう変わるのか。内部の構成を順にたどってみます。

図4：WorkPeer から SO-101 までの制御パスと、レイヤーごとの時間スケールの違い。

① WorkPeer から Robot Gateway へ

入口は WorkPeer です。承認済みの Order Contract を、OpenAPI（または MCP のツール呼び出し）で Robot Gateway に送ります。ここまではごく普通の API コールです。

② Robot Gateway がピッキングジョブに分解する

Robot Gateway は受け取った注文を 1 個単位のピッキングジョブに分解します。

1. カメラで机の上を撮影し、認識モデルが部品の候補を検出する
2. 各候補に対して部品マスタの型番とマッチングし、part_id との対応を確認する
3. 候補選択のロジックが「今回つかむ 1 個」を決め、object_id を付ける
4. 対象の周囲に十分な隙間（クリアランス）があるか、重なっていないか確認する

候補選択のアルゴリズムは、単純な「最も信頼度の高い候補を取る」だけではありません。クリアランス（隣の部品との隙間がグリッパ幅より広いか）、アクセス方向（上からつかめるか横からか）、姿勢の安定性（傾いていないか）を総合的に評価して、最もつかみやすい 1 個を選びます。条件を満たす候補がない場合は、人間に「部品を少しばらしてください」と依頼するフローに分岐します。

ここで大事なのは、ロボットに渡る情報が「長いネジ」という曖昧な名前から、「画面上のこの 1 個」という具体的な対象に変わることです。

③ LeRobot ランタイムが 30Hz でアームを動かす

実際にアームを動かすのは、Robot Gateway の中にある LeRobot ランタイムです。

SO-101 は 6 個の Feetech STS3215 サーボで構成された、6 自由度の小型ロボットアームです。STS3215 はシリアルバス方式のスマートサーボで、位置・速度・負荷のフィードバックを持ち、5V 動作で最大 19.5 kg·cm のトルクを出力します。産業用の大掛かりなコントローラは使わず、LeRobot ライブラリから USB シリアル（半二重 UART、1Mbps）経由で直接制御します。

ランタイムはおよそ 30Hz のループで以下を繰り返します。

1. 観測を取る：複数の RGB カメラ画像（通常 2〜3 視点、640×480 @ 30fps）と、各サーボの現在角度を STS3215 のステータスパケットから読み取る
2. VLA に推論させる：観測データを VLA ポリシー（後編で扱う SmolVLA）に入力し、数ステップ分の目標動作（action chunk）を生成する
3. アクションを取り出す：出力から目標関節角度とグリッパの開閉指令を抽出する
4. サーボに書き込む：Feetech サーボへシリアルバスで目標位置を書き込む。STS3215 は Sync Write に対応しているため、6 軸分のコマンドを 1 回の通信で送信できる
5. 繰り返す：動いた結果が次の観測に反映されるので、また 1 に戻る

VLA の推論には数十ミリ秒かかりますが、その間も前回の action chunk の残りを実行し続けるため、ロボットの動きが途切れることはありません（LeRobot の Real-Time Chunking という仕組みです。後編で詳しく説明します）。

④ レイヤーが分かれていることの意味

「WorkPeer が SO-101 を動かす」と言っても、WorkPeer が関節の角度を直接制御しているわけではないという点が重要です。

• WorkPeer が渡すのは「何を・どの条件で」という情報だけ（秒〜分の時間スケール）
• 30Hz の制御ループは Robot Gateway 内の LeRobot ランタイムがすべて受け持つ（~33ms の時間スケール）

この分離のおかげで、上位の業務ワークフローはそのままに、ロボット側だけを差し替えることができます。SO-101 を別のアームに変えても、SmolVLA を別のポリシーモデルに入れ替えても、WorkPeer 側のコードには一切手を入れる必要がありません。

逆方向も同様です。注文書の OCR を GPT-4o から Gemini に変えても、Robot Gateway 側は何も変わりません。Order Contract というインターフェースが、両者の実装詳細を互いに隠蔽しています。

---

通信方式はレイヤーごとに選ぶ

ここまでで、外側の API コールと内側の 30Hz 制御ループという、まったく時間スケールの違う 2 つの世界が登場しました。

AI とロボットをつなぐ通信方式には OpenAPI、Webhook、MCP、A2A、gRPC、MQTT、ROS 2 Action などたくさんの選択肢がありますが、これらを横一列に並べて「どれが一番いいか」と考えるのはあまりうまくいきません。レイヤーごとに、扱う情報の性質と時間スケールに合った方式を選ぶのが現実的です。

図5：通信方式は時間スケールに合わせてレイヤーごとに選ぶ。

MCP と A2A の違いと使い分け

MCP（Model Context Protocol） は、AI エージェントが外部のツールやサービスを同期的に呼び出すための標準プロトコルです。JSON-RPC 2.0 ベースで、リクエスト→レスポンスの 1 往復で完結します。WorkPeer が Robot Gateway を MCP ツールとして登録すると、execute_order_picking のような操作を関数呼び出しと同じ感覚で発行できます。

ただし、MCP は本質的に同期的です。ピッキングのように数分かかるタスクの場合、MCP のコール中ずっとコネクションを保持し続けるのは現実的ではありません。

ここで A2A（Agent-to-Agent Protocol） が活きてきます。A2A はエージェント同士が長時間にわたるタスクを非同期でやりとりするためのプロトコルで、Google が 2025 年に公開しました。A2A では「タスクカード」を発行してすぐ制御を返し、あとから進捗をポーリングするか、完了通知をサブスクライブします。

実際の使い分け：

• 状態確認（「今どの品目をピッキング中？」）→ MCP で同期的に聞く
• 注文のピッキングを開始→ A2A でタスクを委譲し、完了を待つ
• 緊急停止→ MCP で即時コマンドを送る

今回の SO-101 デモのように軽量な構成なら、最初から ROS 2 や MoveIt をフルで組み込む必要はありません。将来、産業用アームや MES / WMS / PLC との連携が必要になったら、Order Contract というインターフェースはそのままに、Robot Gateway の中身だけを入れ替えれば対応できます。

---

ロボットの「生の操作」は外に出さない

最後にセキュリティに関わる設計上のポイントがあります。

MCP で Robot Gateway をツールとして公開するとき、robot.move_joint（関節を指定角度に動かす）のような低レベルの API を公開するのではなく、業務レベルの操作だけを公開します。

✕ robot.move_joint(joint_id=3, angle=45.0)    ← 危険：直接制御
✕ robot.set_gripper(force=80)                  ← 危険：直接制御

✓ robot.inspect_scene()                         ← 安全：業務スキル
✓ robot.dry_run_order(order_contract)            ← 安全：事前チェック
✓ robot.execute_order_picking(order_contract)    ← 安全：承認済み注文のみ

これは Defense in Depth（多層防御） の考え方です。

1. 入力レイヤー：Order Contract は WorkPeer のワークフローで承認されたものだけが有効
2. API レイヤー：公開するのは業務スキルのみ。関節レベルの操作は内部に閉じる
3. 実行レイヤー：Robot Gateway 内で min_confidence や pick_constraint を強制適用

カメラ画像に何か文字が写り込んでいたとしても、それはただの観測情報であってロボットへの命令にはなりません。「画像に写った文字列がそのまま命令として実行されてしまう」ようなプロンプトインジェクション的な事故を、アーキテクチャレベルで防ぐ設計です。

---

まとめ

このデモの本質は、LLM がロボットを直接動かすところにはありません。手書きの注文書という曖昧な入力を、部品マスタ・承認・実行条件・検証条件を備えた業務プロセスに変換し、SO-101 の物理動作までつなげるところにあります。

• WorkPeer ―― 注文の意味理解、部品マスタ照合、承認、監査ログ
• Order Contract ―― 両者の共通言語となる構造化タスク仕様（ライフサイクル管理付き）
• Robot Gateway ―― 観測、対象選択、30Hz の制御ループ、箱内検証

この役割分担があると、AI とロボットの連携は「見せるためのデモ」にとどまらず、失敗の原因をレイヤーごとに切り分けられ、段階的に改善していけるシステムになります。

後編では、この先に踏み込みます。Robot Gateway の中で動く VLA ポリシー（SmolVLA）を、同じ部品が何本も並ぶ環境でどう安定させるか。データ収集・ファインチューニング・評価・改善ループの実際について詳しく書いていきます。

👉 続きは 後編「注文書ピッキングロボットの VLA 設計 ― SmolVLA を使って、同じ部品が並ぶ環境でどうピッキングするか」 へ。

---

参考リンク

• WorkPeer - Black AI
• SO-ARM100 / SO-101 (The Robot Studio)
• LeRobot
• SmolVLA (Hugging Face Blog)
• Model Context Protocol Specification
• Agent2Agent Protocol Specification
• SayCan (Google DeepMind)
• ROS 2 Actions
• LeRobot Real-Time Chunking
• Feetech STS3215 Datasheet