シミュレーションで動いたロボットを、実機で何を確かめてから信じるか：発注側のための報告の読み方

開発パートナーから「シミュレーションでは問題なく動きました」という報告を受けたとき、その一文だけで次の工程に進めてよいのか、迷う方は少なくないと思います。シミュレーションの結果は貴重な材料ですが、それが保証してくれる範囲は、何を模擬したかで決まります。この記事は、生産技術やR&Dの担当者が、シミュレーション結果の報告を受けたときに、何を根拠として読み、何を実機で確かめ、どの条件がそろったら実機へ移すかを整理したものです。

Sim2Realの仕組みや、現実とのギャップを小さくする技術そのものの解説ではなく、発注側の「報告の読み方」に絞ります。特定のシミュレータやクラウドサービス、製品の比較・推奨はしません。また、「シミュレーションで十分」「実機が必須」のどちらかを言い切ることもしません。どちらになるかは、対象の作業と、失敗したときの影響の大きさによって変わります。

シミュレーション結果とは何を示しているのか

シミュレーション結果とは、この記事では、現実の機体・対象物・設備を、計算機の中のモデルに置き換えたうえで得られた挙動の記録を指します。現実そのものの記録ではありません。モデルに入れた仮定（寸法、重さ、摩擦、センサーの見え方、制御の遅れなど）が現実に近ければ参考になり、離れていれば、結果がよく見えても現実では再現しません。

そのため、報告を読むときの出発点は「動いたかどうか」より、「何を模擬した結果なのか」です。

報告を受けたら、最初に聞く5つの問い

問い	確認すること	答えがないと起きやすいこと
何を模擬したか	機体、対象物、設備、センサー、制御の周期など、モデルに入れたものの一覧	どこまでが確かめられた範囲なのか分からない
何を模擬していないか	簡略化した点、省いた点。たとえば周辺設備、人の動き、汚れや経年変化	模擬していない部分まで確認済みと読んでしまう
条件をどこまで変えたか	対象物の位置・形・重さのばらつき、明るさ、機体の個体差などを、どの範囲で振って試したか。誰がその範囲を決めたか	開発側が選んだ都合のよい条件だけで評価される
現実と照らしたか	実機や実測のデータと、モデルの挙動を突き合わせた記録があるか	モデルの仮定が正しいかを、誰も確かめていない
失敗をどう扱ったか	試行の全体と、うまくいかなかった試行、結果から除いた試行とその理由	成功した場面だけが報告に載る

答えが「分からない」「記録がない」のは、それ自体が報告の読み方を決める情報です。責める必要はなく、実機で確かめる項目を増やす理由として使います。

何を結果として読み、何を実機で確かめるか

次の表は、観点ごとの目安です。どの程度の差が出るかは、機体と作業によって異なるため、実際の判断は個別の確認が必要です。

観点	シミュレーションの結果から読めること	実機で確かめること
動作の流れ	モデルの中で、想定した順に動作がつながるか	実際の機体と対象物でも、同じ順につながるか
接触と力	摩擦などの仮定を置いたときの、つかむ・押す・はめる動き	実際の滑り、引っかかり、力の入り方。仮定した値が現物に合っているか
見え方（センサー）	シミュレーション上の画像・センサー値での認識	実際の照明、反射、汚れ、ノイズ、取り付け位置のずれでも認識できるか
時間	理想的な処理の流れ	通信や制御の遅れを含めても、動作が間に合うか
機体の個体	設計上の寸法・特性での動き	個体差、ガタ、摩耗がある実機でも動くか
周辺の設備と人	簡略化した周辺での動き	実際の搬送、治具、通信、人の作業と並行して動くか
安全	停止条件の設計上の動き	実際に止められるか、止めたあとに元の状態へ戻せるか

センサーの見え方、接触、時間の遅れは、シミュレーションと現実の差が出る要因として挙げられることの多い項目です。ただし、差の出方は機体と作業で異なります。安全に関わる確認は、関係法令・規格と、現場の安全管理者・専門家の確認を前提に進めてください。

判断条件：実機に移してよい状態、まだ早い状態

実機に移してよい状態：

• 模擬した範囲と、模擬していない範囲が、文章で示されている
• 実機で最初に確かめる動作と、その順番が決まっている
• 実機の結果がシミュレーションと食い違ったとき、何を見直すかが決まっている
• 実機試験を止める条件と、止めたあとの戻し方が決まっている
• 実機へ進むかどうかを、誰が決めるかが決まっている

まだ早い状態：

• 報告が動画やグラフだけで、条件の一覧がない
• 条件を振った範囲が、現場で起きるばらつきと比べられていない
• 実機の準備が、安全管理者や設備の担当者に共有されていない

シミュレーションの結果が判断材料として重みを持ちやすいのは、模擬した範囲が現場の条件を広く覆っていて、現実のデータとの突き合わせがある場合です。逆に、実機での失敗が人の危険や設備の損傷につながる作業ほど、実機に移す前の確認と、実機での最初の条件の絞り込みが重要になります。

実機での確かめ方（手順）

1. 報告の前提（模擬した・していないもの、条件を振った範囲）を一覧にし、足りない情報を開発側に聞く
2. シミュレーションで成立した動作のうち、実機で最初に確かめるものを絞る
3. 速度や動作範囲を抑え、いつでも人が止められる状態から始める
4. シミュレーションと実機で、同じ項目を同じ見方で記録する。比べられる形にしておく
5. 差が出た項目を、原因の候補ごとに分ける（モデルの仮定、実機の個体、設置の条件、現場の条件）
6. 条件を広げる。対象物のばらつき、稼働が多い時間帯、人の作業との並行など、現場で起きる変動を加える
7. 結果を、事前に決めた人が、次へ進む・見直す・止める、のいずれかに判断する

実機で動かしたあと、「実機が悪かった」「モデルが悪かった」と決めつけず、原因の候補に分けて確かめることで、次のシミュレーションの見直しにつながります。

報告・提案で確認すること

確認する点	十分な答えの例	注意したい答え
前提の示し方	模擬した・していないものの一覧が、結果と一緒に示される	「シミュレーションでは問題なく動いた」だけ
条件の範囲	条件を振った範囲と、その範囲を決めた理由が示される	範囲が示されない。または開発側だけで決めている
現実との照合	実機や実測との突き合わせの記録が示される。照合していない場合は、その旨と実機で確かめる項目がある	「実機でも同じはず」
失敗の扱い	うまくいかなかった試行と、除いた試行の理由が記録されている	成功した場面の映像だけが共有される
実機での進め方	最初の条件の絞り方、止める条件、判断する人が示される	「実機で調整すれば合う」と述べ、何を調整するかが無い

失敗しやすいパターン

• 模擬していない部分があることが報告に書かれず、全体が確認済みだと受け取る
• 成功した場面の映像で判断し、うまくいかなかった試行を見ていない
• 条件を振る範囲を、開発側だけが決めている
• 実機で差が出たとき、実機の不具合として扱い、シミュレーションの仮定を見直さない
• 実機での最初の確認から、現場の通常の条件で動かしてしまう
• シミュレーションの結果を、ライン適用や量産の判断の根拠として、そのまま使う

発注側から先に渡しておく情報

シミュレーションの条件は、現場を知っている側が情報を出さなければ、開発側は想像で置くことになります。次のような情報を、報告を受ける前に渡しておくと、条件の範囲を現場に近づけやすくなります。

• 対象物の種類と、個体ごとのばらつき（形、重さ、置かれ方）
• 作業場所の明るさ、床や台の状態、周辺の設備の配置
• 作業者が同じ場所で作業する場面と、その動き
• 過去にうまくいかなかった場面や、例外の対応

機密に関わる情報は、渡す範囲を契約や社内の取り決めで確認してください。

WITHPROJECTSの考え方

WITHPROJECTSは、フィジカルAI事業化・FDE支援のページで、PoCの設計と、事業化までの道筋を支援内容として掲げています。

同ページは、実証で終わるPoCは設計が間違っているとの立場を示し、PoCを、事業化に向けた設計の途中の工程として位置づけています。

PoCの前に決めておく条件はフィジカルAIのPoC支援の記事に、物理タスクの分解は工場自動化の記事に、支援の全体はフィジカルAI事業化・FDE支援にまとめています。

次の一歩

フィジカルAIのPoCで、シミュレーション結果の読み方と実機で確かめる項目を整理したい方は、個別相談の予約へお進みください。（個別相談会（30分）の予約ページへ移動します）