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

- 記録: LOG490（フィジカルAI研究室）
- 公開: 2026/11/11
- 記事のページ: https://pixelstomotors.com/record/measure-mecharm-270-waits-decide-claude-fable-5-2-role
- サイト: Pixels to Motors（ADAPT DESIGN / 島津 栄一） https://pixelstomotors.com/
- 要約: Anthropic の Claude Fable 5.2 は、実物のロボットアーム mechArm 270 の実験では、失敗の見立てのような人の判断の所に絞って使う。π0.5 の実機20本では、アームが動いていたのは全体の44%だった。

> AI が読むための記事の全文です（コード・実行ログを含む）。引用するときは上の「記事のページ」の住所を使ってください。

---

**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](https://x.com/hyusapx)）。Claude Fable 5.2 がレジの前に立つロボットアームを動かし、食料品をスキャンして袋に詰めるシミュレーションの動画で、Anthropic の公式アカウント（[@claudeai](https://x.com/claudeai)）の「Fable 5.2 は物理的なロボットを制御する力が大きく伸びた」という投稿を引用していました。Anthropic の発表（[Claude Fable 5.2 and Mythos 5.2](https://www.anthropic.com/news/claude-fable-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回の試行の時間がどこに消えているかを測りました。

| やったこと | なぜ | 結果 |
|---|---|---|
| Fable 5.2 の発表と、ロボットを動かす研究を調べた | 動画が何を見せているのかを知るため | 言葉の指示で段取りを決める上の層が伸びた話。細かい動きは VLA（画像から動きを出すモデル）が強い |
| 今の mechArm の実験のどこに入るかを考えた | 週の上限があるので、使う所を絞るため | 失敗の見立てと、複数の物を順に扱う回の段取り役。動きのループの中では呼ばない |
| 試す順番を決めた | 電源と Fable を同時に変えないため | 12V・5A の電源の差を先に測り、そのあと Fable |
| 1回の試行の待ちを3か所に分けて考えた | 大量のお手本を作るのに、どこを縮めるかを決めるため | 試行の中の待ち・試行のあいだ・立ち上げ |
| 2026-11-11 の実機20本を、記録から時間ごとに分けた | 考えを数字で確かめるため | 動き43.6%・推論25.8%・人の合図26.5%・次の推論までの間4.1% |
| 横の iPhone 11 の記録を自動にできるかを確かめた | 失敗の見立てに横からの映像を使うため | 上カメラと同じウェブカメラ扱いなので、同じ仕組みで取れる |

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

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

[ロボットAIの学習用GPU、買うか借りるか](https://pixelstomotors.com/gpu-buy-or-rent)

[図解: LOG490_trial_time_split.html](https://pixelstomotors.com/embeds/LOG490_trial_time_split.html)


## 作業ログ ― 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](https://www.anthropic.com/news/claude-fable-and-mythos-5-2) は、Anthropic が2026年11月9日に公開した Claude のモデルです。文章・コード・画像を扱う汎用のモデルで、ロボット専用のモデルではありません。発表では、ロボットを動かす力が伸び、教えていない作業でも力を出すとしています。

| 言葉 | この回での意味 |
|---|---|
| Claude Fable 5.2 | Anthropic の上位のモデル。料金は入力100万トークンあたり8ドル、出力40ドル |
| RoboDojo | カメラの画像から、シミュレーションの中の2本腕のロボットを動かす試験。Anthropic の発表で使われた |
| 段取り役 | どの物を、どの順で、どこへ動かすかを決める役。掴む・置くの細かい動きは VLA が担う |
| 週の上限 | claude.ai で上位のモデルを使える量の上限。Fable は多く使うとすぐに届く |

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

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

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

| モデル | RoboDojo |
|---|---|
| Claude Fable 5.2 | 64.9% |
| Claude Opus 5.5 | 39.4% |
| Gemini 4 Argon | 34.2% |
| GPT-6 Astra | 29.8% |
| Claude Fable 5.1 | 27.6% |

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

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

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

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


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

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

| 場所 | Fable にさせること | 今あるもの |
|---|---|---|
| 今すぐ効く所：失敗の見立て | 失敗した試行の録画と、爪のサーボの電流の記録を見せて、どの区間で何が起きたか、どこまで巻き戻すかを出させる | PICK と PLACE の成否は、Claude Sonnet に画像を見せて判定している（VLM-as-Reward）。巻き戻しとゲームパッドでの補正もある |
| 本命：複数の物・言葉の指示 | 「次はどのブロックを、どこへ」を決め、π0.5 が掴む・置くを担う | 赤と青のブロックを言葉で選び分ける試しを、LOG443 でやりたいこととして挙げていた |

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

- 実機の動きのループの中で毎回呼ぶ使い方。今でも動きの合間の待ちが長いと感じているので、悪化する。週の上限にもすぐ届く。呼ぶのは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つありました。

| 流れ | 例 | このプロジェクトへの意味 |
|---|---|---|
| 実機のデータの量で押す | [LingBot-VLA](https://arxiv.org/abs/2601.18692)：9種類の2本腕の機体で集めた約2万時間の実機データで学習し、データを増やすほど別の機体・作業にも効くと示した | 新しい機体・作業に必要なお手本の本数が減っていく |
| 言葉の理解とひとつにする | [Qwen-VLA](https://www.emergentmind.com/papers/2605.30280)：つかむ・移動・画像の理解を混ぜて学習し、動きと文章の両方を出す | Fable の段取りと VLA の動きが、いずれ1つのモデルに寄っていく |
| 空間の理解を後から強める | 2026年11月の論文（[arXiv 2611.08373](https://papers.cool/arxiv/2611.08373)）：補助の仕組みは学習のときだけ使い、学習済みの VLA の重みと推論の形はそのまま使える | 今の π0.5 の使い方を変えずに、上積みが入る |

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

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

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

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

| 区間 | どこからどこまで | 今の mechArm |
|---|---|---|
| 気づく | 失敗が起きてから、人か仕組みが気づくまで | 人が目で見ている |
| 止める | 気づいてから、アームが安全に止まるまで | ゲームパッドで止められる（L2 と R2 を両方半分以上） |
| 戻す | やり直せる姿勢に戻すまで | 巻き戻しとゲームパッドの補正がある |
| 再開 | 戻してから、自動の動きに戻るまで | 人がキーで再開している |

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


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

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

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

| 場所 | 中身 | 縮め方の案 |
|---|---|---|
| 試行の中 | 爪の開け閉めのあとの待ち、姿勢が落ち着くまでの待ち、推論の返りの待ち、人の合図待ち | 固定の秒数で待つ所を「止まったと分かったら次へ」に変える。電流やエンコーダの値で、爪が閉じきった・アームが止まったを判定する |
| 試行のあいだ | 人がブロックを戻す時間。ホームへ戻る・起動も含む | 箱に入れたあと、アーム自身がブロックを取り出し、毎回違う位置に置き直す。置き直しは決まった手順で書けるので学習が要らず、置き場所のばらつきも自動で生まれる |
| 立ち上げ | 上カメラの位置出し、Pod の準備 | 上カメラの傾きはソフトでそろえる形にした（Log#28）。Pod の準備は1行の起動スクリプトにまとめてある |

繰り返しに耐えるために、次の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` で動かします。元の記録は読むだけです。

```python
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（出力）

```text
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%を占めていました。チャンクごとの推論の秒数は、次のコマンドで確かめました。

```bash
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))"
```

```text
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（試行と試行のあいだを測る）

```python
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（出力）

```text
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 で縮む所と設計で縮む所を分けた

| 待ち | 20本での量 | 縮めるのは |
|---|---|---|
| 人の合図待ち | 440.7秒（26.5%） | 設計：チャンクごとのキー操作をやめ、決めた条件で自動に進める |
| 推論の待ち（Pod の起き上がり） | 約116秒 | 設計：試行を始める前に、空の推論を1回流しておく |
| 推論の待ち（ふだん） | 中央値1.04秒×218回 | π0.5 と Pod の側 |
| 試行のあいだ | 中央値25.6秒 | 設計：アーム自身の置き直し |
| 失敗の見立て | この20本では巻き戻しが0回で、まだ測れていない | Fable 5.2 を当てる |

- ねらい：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）](https://www.anthropic.com/news/claude-fable-and-mythos-5-2)
- [ayush paul さん（@hyusapx）の X](https://x.com/hyusapx)
- [Claude（@claudeai）の X](https://x.com/claudeai)
- [VIA: Visual Interface Agent for Robot Control（Stanford）](https://www.alphaxiv.org/abs/2607.11119)
- [Claude plays robotics（Anthropic）](https://www.anthropic.com/research/claude-plays-robotics)
- [A Pragmatic VLA Foundation Model（LingBot-VLA）](https://arxiv.org/abs/2601.18692)
- [Qwen-VLA](https://www.emergentmind.com/papers/2605.30280)
- [arXiv 2611.08373（VLA の空間の理解）](https://papers.cool/arxiv/2611.08373)