フィジカルAI研究室を作る Log#31 | mechArm 270 の待ちを測り、Claude Fable 5.2 の使い所を決めた

Anthropic の Claude Fable 5.2 は、実物の小型ロボットアーム mechArm 270 の実験では、1回の試行の待ち時間を縮める道具としてではなく、失敗の見立て（何が起きて、どこまで戻すか）のような人の判断の所に絞って使うのが合う。 Physical Intelligence の π0.5 に動かさせた実機20本の記録を分けると、アームが動いていたのは全体の43.6%で、残りは推論の待ち25.8%と、人がキーで「進めて」を出すまでの待ち26.5%でした。この2つは Fable では縮まらず、設定と仕組みの側で縮める所です。

この回で決めたことで、次のことが変わります。

• 試す順番が決まった：まず注文した12V・5A の電源で動きの差だけを測り、動きが安定してから Fable を足す。電源と Fable を同時に変えると、良くなった理由が分からなくなるため
• 待ちを縮める先が数字で見えた：20本・合計27.7分のうち、人の合図待ちが7.3分、推論の待ちが7.2分。推論の待ちのうち約1.9分は、GPU のマシンを起こした直後の2回だけだった。試行と試行のあいだ（置き直しなど）は中央値25.6秒で、1回の試行（中央値64.9秒）の約4割にあたる
• Fable の週の上限を使う所を絞れた：実機の動きのループの中では呼ばず、失敗の記録を見せて見立てを出させる所と、仕組みのコードを書く所に回す
• 横の iPhone 11 も、上カメラと同じ仕組みで自動で記録できると分かった。どちらも USB の有線でつながっているので、試行ごとに上と横の映像を自動で切り分けられる

きっかけは、X に流れてきた ayush paul さんの投稿でした（@hyusapx）。Claude Fable 5.2 がレジの前に立つロボットアームを動かし、食料品をスキャンして袋に詰めるシミュレーションの動画で、Anthropic の公式アカウント（@claudeai）の「Fable 5.2 は物理的なロボットを制御する力が大きく伸びた」という投稿を引用していました。Anthropic の発表（Claude Fable 5.2 and Mythos 5.2）では、カメラの画像から2本腕のロボットを動かす試験 RoboDojo で、Fable 5.2 は64.9%と、前の Fable 5.1 の27.6%の2倍以上でした。

これだけ聞くと、今の mechArm の実験にもすぐ入れたくなります。ただ、動画の右下には「8× · pauses cut」「60× · pauses cut」と出ていて、8倍速・60倍速で、考えている間の止まりを切った映像でした。そこで、Fable を今の実験のどこに入れると効くのかを話し合い、自分の実機の記録で1回の試行の時間がどこに消えているかを測りました。

時間の数字は、実機の記録（log.jsonl）の時刻から計算した値です。Fable を入れたあとにどれだけ縮むかは、まだ試していない見込みです。

GPU を買うか借りるかの判断は、Runpod で実際に借りて学習させた費用をもとに、別のページにまとめています。

¥750,000¥4,700導入比較ガイドロボットAIの学習用GPU、買うか借りるか実際に借りて学習させた費用と、損益分岐の計算機で決められますarrow_forward

作業ログ ― Claude Fable 5.2 を mechArm 270 の実験のどこに入れるかを決め、待ちを測るまで

ここから下は作業の記録です。コードと出力は全量で載せます。効果を書いた所のうち、数字で書いたものは記録から計算した値、「見込み」と書いたものはまだ確かめていない値です。

この回で何度も出てくる言葉を先に言い換えておきます。

• π0.5：Physical Intelligence が公開しているロボット用の AI のモデル。カメラの画像と関節の角度を受け取り、次の動きを出す。mechArm のお手本50本で学習させて使っている
• VLA：Vision-Language-Action の略。画像と言葉の指示を受け取り、ロボットの動きを直接出すモデルのこと。π0.5 はこの1つ
• チャンク：π0.5 が1回の推論で出す、約10歩分の動きのまとまり。1回の試行は7〜17チャンクでできている
• Pod：Runpod で借りる GPU のマシン。π0.5 はこの上で動き、Mac から画像と角度を送って、次のチャンクを受け取る
• 人の合図待ち：今の実機推論は、チャンクごとに人がキーを押して「進めて」を出す設定（記録の auto が false）。推論が返ってから、キーが押されて動き始めるまでの時間

Claude Fable 5.2 は、Anthropic が11月9日に出した上位のモデル

Claude Fable 5.2 は、言葉で考えて段取りを決めるモデル

Claude Fable 5.2 は、Anthropic が2026年11月9日に公開した Claude のモデルです。文章・コード・画像を扱う汎用のモデルで、ロボット専用のモデルではありません。発表では、ロボットを動かす力が伸び、教えていない作業でも力を出すとしています。

このプロジェクトでは、Fable を実機を直接動かすモデルとしては使いません。π0.5 の上に乗って、失敗の見立てや次の手を決める役として試します。

RoboDojo の点数と、デモ動画の速さ

Anthropic の発表にある RoboDojo の点数は次のとおりです（Anthropic の社内の測定）。

一方で、X で見たデモ動画は、レジの袋詰めが8倍速、パズルキューブを解く映像が60倍速で、どちらも考えている間の止まりを切っていました。実時間では、1つの動きを決めるまでにかなり考えていることになります。

この点は、Stanford の研究 VIA（Visual Interface Agent）とも合います。VIA は、市販の AI のエージェントが、ブラウザの3D画面のスクリーンショットを撮って指示を出す形でアームを動かす仕組みでした。Anthropic 自身の研究（Claude plays robotics）でも、ロボットの点数はモデルだけでなく、機体と、どうつなぐかで同じくらい決まり、VLA を土台にすると、モデルが関節を直接動かすより把持の成績がずっと上がるとしています。

fable5.2そんなにすごいのかな？（あっという間に週の上限来そうだけど）

ここから、Fable は π0.5 の代わりではなく、その上に乗る段取り役として考えることにしました。

Fable 5.2 を入れる場所は、失敗の見立てと、複数の物を順に扱う回

今の mechArm の実験は「赤いブロックを1個つかんで、白い箱に入れる」の1つの動作です。順番を決める余地が小さいので、段取り役の出番はまだ少ない。そのうえで、入れる場所を2つに分けました。

逆に、入れないと決めた所もあります。

• 実機の動きのループの中で毎回呼ぶ使い方。今でも動きの合間の待ちが長いと感じているので、悪化する。週の上限にもすぐ届く。呼ぶのは1回の試行の終わりか、作業の切れ目だけにする
• お手本の採否。つかみの深さ（閉じて1秒後に、ブロックが爪先の印から24px を超えてはみ出すか）のように、ルールで決まっているものはルールのままにする

最初の1回は、実機を動かさずにできることにしました。過去の失敗の記録を Sonnet と Fable の両方に見せて、見立てを比べます。

なるほど。あくまでもポイントでうまく使うといえ話だね。電源が来てアームの動きがスムーズになるようなら新しく試してみたいところだね。

12V・5A の電源の差を先に測り、Fable はそのあとに足す

Log#30（LOG487）で、mechArm 270 がつかんだブロックを落とすのは、電源アダプターの不足（本体は40W、アダプターは12V・2A の24W）が原因とみて、12V・5A を注文しました。

ここで電源と Fable を同時に変えると、失敗が減ったときに、どちらが効いたのか分からなくなります。そこで順番を決めました。

1. 電源の差だけを測る：同じ置き場所で、2A と 5A のアダプターを替えて、爪の緩み・持ち上げ・爪の電流を比べる
2. 動きが安定したら Fable を足す：失敗が減ったあとの方が、残った失敗の見立てを比べやすい

電源を替えると、失敗の種類そのものが変わるかもしれません。Fable に見せて比べる失敗の記録も、電源を替えたあとのものを使います。

VLA が進化すると、差がつく場所が「動くか」から「戻し方」へ移る

VLAはこれから進化してくるかな？どんな違いをもたらすのだろうかね。

VLA の今の流れを調べると、大きく3つありました。

一番大きな違いは、新しい作業を覚えさせるのに必要なお手本の本数が減ることです。今 mechArm で位置ごとに10本、合計50本そろえているお手本が、将来は数本や言葉の指示で済む方向に向かっています。

そうなると、差がつく場所が移ります。どのお手本が良いか、失敗したときに現場でどう戻すか、人がその動きを受け入れるか（速さ・間・怖さ）。VLA が良くなるほど、出力側と運用の比重が上がります。

まずは失敗した現場での戻し方のスピードを上げるのは先決かな。そこのスピード感が向上してくることによって現場での活用も広がるとは思っています。

現場で使い続けられるかは、失敗しないことより、失敗してから何秒で元の仕事に戻れるかで決まる場面が多い。 そこで、失敗から再開までの時間を4つに分けて測ることにしました。

この時間は、配膳ロボットや病院の搬送ロボットのシミュレーションで見ている「止まり」と同じ種類の数字です。mechArm で測った戻し方の時間は、導入シミュレーションの前提の値にもそのまま使えます。

1回の試行の待ちを、試行の中・試行のあいだ・立ち上げの3か所に分けた

それと試行そのものの時間ももっと短縮したり、繰り返し試行に耐えられる設計が必要かなと思っています。いろんな動きのサンプルを大量に作るために、待ちの時間をどれだけ減らせるかも考える必要があります。

お手本を大量に作るとき、待ちは大きく3か所に分かれます。

繰り返しに耐えるために、次の3つも仕組みに入れたい所です。

• 試行ごとに自動で台帳に1行を書き、録画も自動で切る
• 熱・電流・カメラのずれが一定を超えたら、自動で止めて休む
• 失敗したら自動で置き直しまで戻って次の試行へ進み、人が呼ばれるのは戻せないときだけにする

2026-11-11 の実機20本を、記録から4つの時間に分けた

考えだけで終わらせず、Log#30 の日（2026-11-11）に π0.5 で動かした実機20本の記録 log.jsonl から、1回の試行の時間を分けました。記録には、チャンクごとに次の時刻が残っています。

• t：推論の結果が返ってきた時刻
• latency_s：推論にかかった秒数（t - latency_s が推論を頼んだ時刻）
• t_exec_start / t_exec_end：アームへの指令を送り始めた時刻と、送り終えた時刻

この4つから、チャンクごとに「推論の待ち（latency_s）」「人の合図待ち（t_exec_start − t）」「動き（t_exec_end − t_exec_start）」「次の推論までの間（次のチャンクの頼んだ時刻 − t_exec_end）」を足しました。実行の設定には、爪の閉じたあとの待ち（grip_wait 0.8秒）と落ち着き待ち（settle_wait 0.8秒）があります。これが4つのどこに入るかは、この集計では分けていません。

コードと出力は KIOXIA の lab/Log31/analysis/ に置きました。

trial_time_split.py（1回の試行を4つの時間に分ける）

/Volumes/KIOXIA/r2r2r-data/runs/pi05_policy で動かします。元の記録は読むだけです。

import json,glob,os,sys
tot={'inf':0,'human':0,'move':0,'other':0}
rows=[]
for d in sorted(glob.glob('pi05_20261111_*')):
    s=os.path.basename(d)
    L=[json.loads(l) for l in open(f'{d}/log.jsonl')]
    meta=json.load(open(f'{d}/{s}.json'))
    c=[r for r in L if 'chunk' in r and r.get('t_exec_start')]
    a={'inf':0,'human':0,'move':0,'other':0}
    for i,r in enumerate(c):
        a['inf']+=r['latency_s']; a['human']+=max(0,r['t_exec_start']-r['t']); a['move']+=r['t_exec_end']-r['t_exec_start']
        if i+1<len(c): a['other']+=(c[i+1]['t']-c[i+1]['latency_s'])-r['t_exec_end']
    span=c[-1]['t_exec_end']-(c[0]['t']-c[0]['latency_s'])
    rows.append((s,meta.get('outcome'),len(c),round(span,1),*[round(a[k],1) for k in a]))
    for k in a: tot[k]+=a[k]
print('run_stem outcome chunks span_s inference_s human_go_s moving_s between_s')
for r in rows: print(*r)
T=sum(tot.values()); print('TOTAL',{k:round(v,1) for k,v in tot.items()}, round(T,1), {k:round(100*v/T,1) for k,v in tot.items()})

trial_time_split_20261111.txt（出力）

run_stem outcome chunks span_s inference_s human_go_s moving_s between_s
pi05_20261111_095426 success 17 143.3 72.9 15.9 52.6 1.9
pi05_20261111_095717 success 13 94.7 18.4 27.7 47.2 1.4
pi05_20261111_095917 success 12 65.9 14.4 12.9 37.3 1.3
pi05_20261111_100659 success 13 86.6 17.1 24.3 43.6 1.6
pi05_20261111_100857 success 16 95.4 21.8 20.5 51.3 1.9
pi05_20261111_101102 failure 10 51.1 12.3 8.7 28.9 1.1
pi05_20261111_101217 failure 8 44.2 10.0 8.0 25.4 0.8
pi05_20261111_101329 success 16 101.2 20.8 24.6 54.0 1.9
pi05_20261111_101557 failure 8 56.3 11.4 15.7 28.4 0.8
pi05_20261111_101720 success 13 88.9 16.8 9.5 40.6 22.0
pi05_20261111_101918 failure 8 41.6 11.4 7.7 21.8 0.8
pi05_20261111_102043 failure 9 63.8 20.4 13.1 29.3 1.0
pi05_20261111_102213 failure 7 40.1 12.1 7.1 20.2 0.8
pi05_20261111_102353 failure 11 57.5 17.7 7.6 30.9 1.3
pi05_20261111_102516 success 15 95.2 29.2 19.6 44.8 1.6
pi05_20261111_102720 failure 7 48.5 9.6 17.1 21.1 0.7
pi05_20261111_102851 failure 9 53.1 14.8 13.2 24.2 1.0
pi05_20261111_160851 success 14 284.0 80.0 134.3 44.2 25.5
pi05_20261111_161402 failure 7 117.2 10.1 46.1 60.2 0.7
pi05_20261111_161743 failure 7 35.8 8.6 7.2 19.3 0.7
TOTAL {'inf': 429.8, 'human': 440.7, 'move': 725.3, 'other': 68.8} 1664.5 {'inf': 25.8, 'human': 26.5, 'move': 43.6, 'other': 4.1}

20本・1,664.5秒（27.7分）のうち、動きは725.3秒（43.6%）、推論の待ちは429.8秒（25.8%）、人の合図待ちは440.7秒（26.5%）、次の推論までの間は68.8秒（4.1%）でした。

推論の待ちを1回ずつ見ると、220回の推論の中央値は1.04秒で、長いものは2つだけでした。

• 1本目（09:54）の最初の推論：52.0秒
• 午後の1本目（16:08）の最初の推論：63.6秒

どちらも Pod を起こした直後の1回目です。この2回で約116秒、推論の待ち全体の約27%を占めていました。チャンクごとの推論の秒数は、次のコマンドで確かめました。

cd $HOME/mnt/KIOXIA/r2r2r-data/runs/pi05_policy && for s in 095426 160851 100659; do python3 -c "
import json;L=[json.loads(l) for l in open('pi05_20261111_$s/log.jsonl')];print('$s',[r['latency_s'] for r in L if 'chunk' in r])"; done; python3 -c "
import json,glob,statistics as st
v=[r['latency_s'] for d in glob.glob('pi05_20261111_*') for r in map(json.loads,open(d+'/log.jsonl')) if 'chunk' in r and r.get('t_exec_start')]
print(len(v),st.median(v),max(v))"

095426 [52.0, 0.806, 0.957, 2.367, 0.986, 0.811, 0.991, 0.825, 2.38, 1.049, 0.806, 1.079, 0.905, 2.144, 1.074, 2.411, 1.314, 1.091]
160851 [63.593, 0.806, 0.803, 2.216, 1.222, 1.042, 0.809, 2.232, 0.808, 1.102, 2.418, 1.169, 2.365, 1.003, 0.811, 0.933]
100659 [1.823, 0.808, 0.826, 2.522, 0.831, 0.808, 0.908, 2.473, 0.867, 0.806, 0.91, 2.644, 0.829, 1.053]
220 1.0354999999999999 63.593

人の合図待ちが大きいのは、1チャンクごとに人がキーで進める設定だからです。16:08 の回は、8つ目のチャンクで67.4秒、最後のチャンクで46.5秒、キーが押されるのを待っていました。

trial_gaps.py（試行と試行のあいだを測る）

import json,glob,os
prev=None
print('run_stem start_to_first_request_s end_of_last_move gap_from_prev_run_end_s')
for d in sorted(glob.glob('pi05_20261111_*')):
    s=os.path.basename(d)
    L=[json.loads(l) for l in open(f'{d}/log.jsonl')]
    t0=[r['t'] for r in L if r.get('type')=='model'][0]
    c=[r for r in L if 'chunk' in r and r.get('t_exec_start')]
    first=c[0]['t']-c[0]['latency_s']; end=c[-1]['t_exec_end']
    gap=None if prev is None else round(t0-prev,1)
    print(s, round(first-t0,1), round(end,1), gap)
    prev=end

trial_gaps_20261111.txt（出力）

run_stem start_to_first_request_s end_of_last_move gap_from_prev_run_end_s
pi05_20261111_095426 5.4 1794358615.4 None
pi05_20261111_095717 2.6 1794358734.4 21.7
pi05_20261111_095917 2.7 1794358826.0 22.9
pi05_20261111_100659 2.8 1794359309.0 393.7
pi05_20261111_100857 3.0 1794359436.3 28.9
pi05_20261111_101102 2.9 1794359516.8 26.5
pi05_20261111_101217 2.7 1794359584.6 20.9
pi05_20261111_101329 2.7 1794359713.7 25.3
pi05_20261111_101557 2.6 1794359816.6 43.9
pi05_20261111_101720 2.8 1794359932.7 24.4
pi05_20261111_101918 2.6 1794360002.5 25.6
pi05_20261111_102043 2.6 1794360110.2 41.2
pi05_20261111_102213 2.8 1794360176.6 23.5
pi05_20261111_102353 2.8 1794360293.5 56.7
pi05_20261111_102516 2.9 1794360414.6 23.0
pi05_20261111_102720 2.7 1794360492.2 26.4
pi05_20261111_102851 2.9 1794360587.4 39.2
pi05_20261111_160851 2.7 1794381218.7 20344.6
pi05_20261111_161402 2.7 1794381363.0 24.3
pi05_20261111_161743 2.7 1794381502.2 100.7

試行と試行のあいだは、最後の動きの指令を送り終えてから、次の試行のスクリプトが立ち上がるまでの秒数です。ホームへ戻る動き・ブロックの置き直し・スクリプトの起動が入っています。Pod を立ち上げ直した間（393.7秒）と、午前と午後の間（20,344.6秒）を除いた17回の中央値は25.6秒でした。1回の試行の長さ（span_s）の中央値は64.9秒なので、試行のあいだは試行の約4割にあたります。

待ちの分け方から、Fable で縮む所と設計で縮む所を分けた

• ねらい：Fable の週の上限を、縮む見込みのある所だけに使う
• 変わったこと：1回の試行の時間のうち、Fable で縮む所は記録の中にほとんどなく、大きいのは人の合図待ちと試行のあいだだと分かった
• 見込める効果：人の合図待ちと Pod の起き上がりを設計で外すと、20本の27.7分のうち最大で約9.3分が浮く見込み。置き直しを自動にすると、1回あたり約25秒の人の手が要らなくなる見込み。どちらも、実装したあとの20本で同じ計算をして確かめる

この辺はfable5.2を使えば短縮できるものなの？それとももっと違う考えが必要なのかな？

まとめると、ロボットの動きの中の待ちは設計で、人が判断している時間はモデルで縮めます。先に設計で縮めて、残った人の判断の時間に Fable を当てます。

横の iPhone 11 も、上カメラと同じ仕組みで自動で記録できる

iPhoneで上カメラと横で動画の録画しているけど、カメラは自動で画像を取得してるんだったら、横のiPhoneも動画や画像を自動で取得できるんじゃない？

上カメラの iPhone 14 Pro Max（Continuity Camera）と、横カメラの iPhone 11（Iriun Webcam）は、Mac からはどちらもウェブカメラとして見えています（OpenCV の番号は上が2、横が1）。上カメラの画像を取っているのと同じ仕組みで、横も自動で取れます。

両方ともUSB有線で繋がってるよ。

Wi-Fi でつないだときに出やすいこま落ちや遅れの心配は、これでほぼなくなりました。残る点は、2台のこま数が少しずれることです。画像ごとに時刻を付けて保存しておけば、あとから合わせられます。

自動にすると、次のことが変わる見込みです。

• 録画の開始・終了を試行ごとに自動で切れる。手で録画ボタンを押し、あとで切り分ける手間が消える
• 上と横の画像に同じ時刻が付くので、失敗の見立てのとき「そのとき横から見るとどうだったか」がすぐに引ける。Fable に見せる材料にもなる
• 失敗から再開までの4つの時間も、録画から自動で拾いやすくなる

横カメラを π0.5 の入力にも足すと、モデルの入力が変わるので学習し直しになります。まずは記録用だけにして、入力に足すかは別に決めます。保存先は、試行の連続記録の置き場所（各試行の recording/）に、上と横を並べて入れます。実装は Claude Code への依頼（依頼箱）で、電源の試しの前に入れます。

12V・5A のアダプターが届いたら、横カメラつきで2A と5A の差を測る

次にやることは、この順番です。

1. 依頼箱に「上と横のカメラを試行ごとに同時に自動で記録する」を出す
2. 12V・5A のアダプターが届いたら、同じ置き場所で2A と5A を比べる。爪の緩み・持ち上げ・爪の電流と、この回の4つの時間を記録する
3. 失敗から再開までの時間を、気づく・止める・戻す・再開の4つに分けて記録する
4. 動きが安定したら、失敗の記録を Sonnet と Fable 5.2 に見せて、見立てを比べる

出典

• Claude Fable 5.2 and Mythos 5.2（Anthropic）
• ayush paul さん（@hyusapx）の X
• Claude（@claudeai）の X
• VIA: Visual Interface Agent for Robot Control（Stanford）
• Claude plays robotics（Anthropic）
• A Pragmatic VLA Foundation Model（LingBot-VLA）
• Qwen-VLA
• arXiv 2611.08373（VLA の空間の理解）