ClaudeとMCPでSO-101を直接制御！VLA不要のL3ロボット操作を実証

• 事実と背景：汎用LLMのClaudeとMCPを用い、専用モデルなしでアームSO-101を制御する実験が成功を収めた。
• 技術的変革：RoboDojoのL3制御モデルを自作MCPサーバーで具現化し、安全クランプと追従誤差による簡易接触検知を実現。
• 現場への影響：高額なGPUや学習データ不要でフィジカルAI実験が可能となり、安全ハーネス設計の実務重要性が急増した。

深夜の障害対応でスパゲッティコードのデバッグに追われているときのような、あの胃が痛む感覚を久々に覚えた。2026年9月、ロボット操作ベンチマーク「RoboDojo」のチームが公開したレポートは、これまでの「ロボットには専用のVLA（Vision-Language-Action）モデルによる事前学習が不可欠である」というパラダイムを根本から揺るがすものだった。GPT-6 Astraが、専用のVLAモデルを一切介さない「L3（LLM＋固定ハーネス）」構成において、42種類のシミュレーションタスクでScore 28.97、平均成功率22.48%を叩き出し、既存のトップモデルであったDM0.5（Score 24.90 / 成功率19.34%）を鮮やかに抜き去ったのだ。

しかし、私はこの数値を手放しで絶賛する気にはなれない。なぜなら同レポートでは、チューブ挿入や液体充填、摩擦の伴う積み上げといった接触主体の精密操作において成功率0%のタスクが16個も存在し、実機評価においては物理的に無謀な動作の連続によって機材が損壊、評価が途中で中止されるという大惨事が報告されているからだ。まさに「コンパイルは通るが本番環境でデータベースを破壊するコード」を地で行く挙動である。

現在、Hugging Faceの「LeRobot」プロジェクトや低価格アーム「SO-101」、さらにはAWSブースで披露されたIVS2026でのデモ、Amazon Bedrock AgentCoreやNVIDIA GR00Tを巻き込んだフィジカルAIのトレンドが急速に加熱している。だが、我々エンジニアが現場で直面する最大の課題は「いかに汎用LLMの知性と、泥臭い物理世界のハードウェアを安全かつ確実に接着するか」にある。専用モデルをゼロから学習させる膨大なコンピュートリソースを持たない個人やスタートアップにとって、汎用LLMにツール呼び出しを行わせる「L3構成」は極めて魅力的な選択肢だが、そこには物理世界特有のデッドロックと安全上の落とし穴が潜んでいる。

今回検証されたシステムは、LLMの「頭脳」としてClaude Desktopを使い、その指示を自作のMCP（Model Context Protocol）サーバー「so101_mcp.py」を介してLeRobotのPython API（SO101Follower）に流し込むアーキテクチャだ。逆運動学（IK）も「掴む」マクロも仕込まず、Claudeには6つの基本ツール（connect_robot, get_state, move_joints, move_gripper, capture_image, disconnect_robot）のみを提示する。つまり、手先直交座標系すら与えず、関節角の正規化値と画像だけで対峙させるというストイックな構成である。

この実装プロセスにおいて踏み抜かれた地雷の数々は、組み込み系や分散システムに携わるエンジニアなら誰もが首を強く頷く内容だ。まず、MCPはstdio（標準入出力）で通信するため、LeRobot内部のprint文が1行でも出力されるとプロトコルが破壊されて死ぬ。これを`contextlib.redirect_stdout(sys.stderr)`で標準エラー出力へ退避させる対策は必須だ。さらに、`robot.connect()`がキャリブレーションずれの際にキーボード入力（`input()`）を待ち続けてプロセスが永久にハングする問題や、MCP SDK 2.xでの`FastMCP`から`MCPServer`への名称変更など、実務で遭遇すると数時間を溶かすトラップが満載である。

最も技術的洞察として深いのは、LeRobotの暴走防止機能である`max_relative_target=3.0`（目標値を現在地±3以内に制限）が引き起こした「重力不全トラブル」だ。重力負荷のかかる肘関節（elbow_flex）において、追従しようにもモータの初期駆動トルクを発生させるだけの偏差が作れず、腕が垂れ下がり、その垂れた位置に対してさらに±3の制限がかかるという悪魔の無限ループに陥ったのである。安全制限（`MAX_STEP`）を15.0へと引き上げ、滑らかさはMCP側の線形補間で担保するという「制御層ごとの責務分離」を行って初めて、肘は重力に抗して正常に動作した。安全機能を無知に組み込むと、かえってシステムを不全に陥らせるという好例である。

実験が進む中で明らかになったのは、LLMが「思考」する空間と、ハードウェアが「存在する」物理空間との間にある決定的な情報の非対称性だ。真上からの手先カメラだけではアームの高さやグリッパーの浮き上がりが把握できず、斜めからの外カメラでは奥行き誤認が発生する。Claudeが「何が分からないか」を自ら言語化し、「外カメラの位置をテーブル面と同じ高さにしてほしい」と人間にリクエストを出した瞬間こそ、VLAなしL3制御の真骨頂と言える。

さらに劇的なのは、力覚センサーを持たないSO101において、MCPハーネスが毎回返す「目標値（goal）と実際の値（actual）の差分」を、Claudeが定常偏差を利用した簡易接触センサーとして解釈した点だ。肘を下ろす指令を出した際、目標値に届く前に動作が停止した事実から「爪先がテーブルに接触した」と判断し、即座に目標値を現在地に上書きしてサーボへの過負荷を抜く。このようなフレキシブルな振る舞いは、固くプログラムされた従来の制御ロジックでは実現が難しい。

では、我々現場のエンジニアはこの最新潮流から何を学ぶべきか。明日からの開発に向けた「実践的処方箋」を提示したい。

• ハーネス層へのフィードバック設計：APIのレスポンスには単なる成功/失敗ステータスだけでなく、物理量の偏差（目標値 vs 実績値）を必ず含め、LLMが「物理的抵抗」を検知できる構造を作ること。
• フェールセーフの多重化：LLMの判断ミス（回転方向の誤認等）を前提とし、ハードウェアの絶対的な物理限界を超える前にMCPなどのハーネス層で強制クランプ（最大可動域の95%制限など）をかけること。
• 人間を組み込んだコンテキストループ：カメラの物理的配置や摩擦係数の問題（滑り止めゴムの追加など）を、システム単体で解決しようとせず、人間との対話しやすいインターフェースを維持すること。

汎用LLMの進化速度は凄まじく、いずれVLAモデルとの境界線は曖昧になるだろう。しかし、画面の向こう側のピクセルをいくら捏ねくり回しても、重力や摩擦、サーボの定常偏差といった物理法則をごまかすことはできない。我々はLLMという強力な頭脳を手に入れたが、それを導く「安全な神経系（ハーネス）」を正しく設計する覚悟とスキルを備えているだろうか？デジタル空間のロジックに浸りきった我々エンジニアに今、泥臭いハードウェアの現実に立ち返る覚悟が問われている。