Action chunk：小さな摂動後の復帰を測る

新しい論文が実際に測ったもの

Measuring the Stability Assumption Behind Action Chunking の arXiv 初版は2026年10月1日に投稿された。著者らの問いは狭く、しかし実用的である。action に小さな誤差を注入した後、名目軌道との差は縮むのか、増えるのか。二つの counterfactual trajectory を比べる。一つは open loop で、記録済み chunk の残りの action を再計画せず再生する。もう一つは closed loop で、摂動後の state を方策に渡し、以後の step で再計画する。有限の観測窓で差分の変化率を当てはめ、根拠が十分でない state も含めて stable、unstable、unresolved に分ける。

これは、論文に記載された simulation benchmark と方策条件における著者らの測定である。全ロボットに最適な chunk 長を決める結果でも、短い chunk が常に安全だという証明でも、この教材の実測でもない。論文自身も、当てはめた率を有限 horizon の要約として扱い、誤差伝播の測定と task performance を分けている。

「方策が8個の action を出した」という表現には、別の二問が混ざる。最初の action が名目状態からどれだけ外し得るか。そして次の observation から、その外れを回復できるかである。滑らかな demonstration だけでは、このどちらも分からない。残りを再生すれば古い計画を保つかもしれないし、再計画しても observation、task state、回復データが足りなければ失敗する。

未実行のオフライン fixture

以下は論文の測定枠組みに着想を得た、この教材固有の設計である。ここでは実行していない。使うのは simulator、または actuation を伴わない保存済み rollout だけである。ロボットを接続せず、motor を命令せず、model を訓練せず、実機試験の許可も与えない。

1. 1オフラインの作業契約と動作範囲
2. 2名目軌道と動作の時点を選ぶ
3. 3上限内の合成摂動を一つ加える

1. 1名目 branch
2. 2保存済み残り action を再生
3. 3open-loop の差分

1. 1摂動 state
2. 2offline simulator だけで再計画
3. 3closed-loop の差分

1. 1二つの軌道
2. 2根拠と許可条件の確認
3. 3次のオフラインの問い、または停止

最初に task contract を書く。state 表現、action の単位と座標 frame、action envelope、成功条件、距離尺度、確認者の名前である。保存済み trajectory と action stamp を一つ選び、変更しない action の nominal branch を作る。別の合成 branch では、事前に定めた上限内で選んだ action だけを変える。上限は action と同じ単位・frame で表す。「小さい」移動量を後から説明するだけでは再現できない。

open-loop の比較では、simulator 内で policy を呼ばず、保存済みの残り action を再生する。closed-loop の比較は、reset 可能な simulator が摂動後の observation を供給できる場合だけ、後続 action を方策に問い合わせる。妥当な simulator state、observation model、方策へのアクセスのいずれかが無ければ closed_loop_unavailable と記録する。再計画なら回復するはずだ、と推測で置き換えない。

結果を見る前に、object pose error、end-effector error、または task-state distance などの距離と固定 horizon を選ぶ。nominal と摂動 branch の時系列、horizon、摂動 vector、simulator と policy の version、random seed、reset を保存する。contracting、expanding、unresolved のラベルは、task contract に書いた threshold を満たすときだけ付ける。このラベルは、その trace と条件を記述するだけで、一般的な安定性証明ではない。

permission と stop も結果に含める

誤差曲線の横に、次の四つの判断を残す。

問い	必要な記録	根拠が無いときの安全な扱い
摂動は offline action envelope 内か	単位、frame、上限、確認者	その case を stop
branch は reset して再現できるか	state snapshot、seed、simulator version	unresolved
closed-loop branch は方策を呼べるか	明示的な offline permission と入力契約	再計画しない
後続 action 案が task 境界を越えないか	stop reason と担当者	stop、実機へ進めない

open loop が expanding なら、observation timing や chunk horizon を見直す契機にはなる。しかし controller の chunk を自動で短くしたり、live trial を許可したり、closed-loop 方策の危険を証明したりはしない。contracting も同様に限定的である。反復する摂動、sensor delay、contact の変化、別 task では結論が反転し得る。拒否・停止した case も残す。除外すれば、根拠が示す以上に回復が良く見える。

既存章との接続

データ、模倣、Sim2Real の章 は、環境が変わった後にも古い action chunk が続く危険を扱っている。この fixture は実装判断より前に、さらに小さな問いを置く。一つの明示した摂動と horizon において、再生は名目との差を増幅したのか。offline での再計画は実際に利用可能だったのか。方策評価ワークショップ のより広い Sim2Real gate は、そのまま有効である。

残すべき成果は benchmark score ではなく review packet である。task contract、対になった trace、宣言済み threshold、利用できなかった branch、stop record、次の問いを一緒に置く。著者の測定結果と、未実行のローカル演習を区別できない、または branch 条件を示せない packet は、action chunk の変更判断に使えない。