監視画面はデジタルツインと呼べるか ― 物流ロボット PICKR の動画から、実機とのつなぎ方を考えた

韓国の PyBrain AI が物流ロボット PICKR の動画で見せた3Dの画面は、実機2台の位置と作業の状態を写す監視画面で、データの向きで分ける呼び方では、デジタルツインではなくデジタルシャドウにあたる。 実機から自動でデータを受け取るだけでなく、画面の側で決めたことを人を通さずに実機へ返せるようになって、はじめてデジタルツインと呼べる。これは YouTube に公開された動画を画面収録して、Claude（Anthropic の AI）と一緒に見て考えた記録で、PICKR の実機を自分で調べたものではない。

この整理で、次の3つが手に入る。

• 呼び方の物差し。実機と画面の間でデータがどちら向きに、自動で流れているかで、デジタルモデル・デジタルシャドウ・デジタルツインを見分けられる。展示会やメーカーの資料で「デジタルツイン」と書かれた画面を見たときに、中身がどれかを確かめられる
• 自分の Unity の現在地。サービスロボット導入シミュレーションの Unity も、前に取り組んだ R2R2R の Unity の mechArm も、この物差しではデジタルモデルの側だった。R2R2R は実機と同じ1台を写していたが、Unity と実機の間のデータは、事前にまとめて渡す形だった
• 実機とつなぐ順番。メーカーの配膳ロボットや AMR は、公式の API で出し入れできる範囲が決まっていることが多い。外付けのカメラで外から測る仕組みと組み合わせれば、どのメーカーの機体が入った現場にも使える。機体を買う前に、小さい移動ロボットと手元のカメラで、実機と Unity の往復の仕組みを先に作れる

きっかけは、PyBrain AI の YouTube チャンネルの動画 AI自律走行ロボット群制御 無編集デモ [PICKR EP.6] だった。題名は YouTube の自動翻訳で日本語になっていたもので、元は韓国語の動画。白い台車にロボットアームを載せた PICKR が2台、棚から箱を取って荷降ろし先へ運ぶ作業を、早送りなしで交代に繰り返す。画面の右下には、暗い3Dの画面がずっと重なっていて、ロボットの位置と「R1-2 を掴んでいるところ」のような作業の状態が、実機と同じ速さで動いていた。

見ていて気になったのは、この3Dの画面が何なのかだった。シミュレーションに見えるが、ロボットの動きより先に何かを試している様子はない。自分も Unity でサービスロボットの導入シミュレーションを作っているが、そちらは実機と一度もつながっていない。同じ「3Dの画面」でも、実機とのつながり方で、できることがまるで違う。そこで、この画面を入り口に、デジタルツインという言葉を、データの向きで確かめ直すことにした。

作業ログ ― Claude との対話を、そのまま残す

ここから下は、対話の全量です。私の発言を引用で、Claude の答えを本文で載せています。各節の頭の太字の一文は、その節で Claude が答えようとした問いです。記事化の段取りのやり取りは外しました。Claude の答えの中の太字は、記事の太字の決まりに合わせて外しています。Claude の答えの中で私の名前を呼んでいた所と、これからの予定にふれた所の地名は、言い換えました。各節の後ろに、補足として、動画から読み取ったことと、あとで調べたことを足しています。

この記事に出てくる言葉

PICKR の3Dの画面は、事前のシミュレーションではなく実機の監視画面だった

動画チェック。 どんなシミュレーションなのか実機と何が違うのかを調査してみてください。

（このとき、PICKR EP.6 の動画を YouTube で再生して画面収録した、3分57秒の動画を送った）

— PICKR の3Dの画面は、どんなシミュレーションで、実機と何が違うのか。

結論：画面右下の暗い3D画面は、事前に試すための「シミュレーション」ではありません。いま動いている実機2台の位置と作業の状態を、そのまま映す監視画面（デジタルツイン）です。動画は韓国の PyBrain AI の「AI自律走行ロボット群制御 無編集デモ [PICKR EP.6]」でした。

何の動画か

• PyBrain AI は2025年8月にソウルの永登浦区で設立された会社で、倉庫ロボットを作っています。試験中の製品は、自動で箱詰めをする Py PACKR と、LiDAR と深度カメラで自律走行するピッキングロボットの Py PICKR です。
• PICKR は、商品を自分で取り出して梱包ラインに運び、人の積み込み作業を置き換える移動マニピュレーターです。動画でも、自律走行の台車に協働アームを載せたものになっています。
• 動画には PICKR v1.0 と v2.0 の2台が映っていて、棚（R1・R2）から箱を取り、DEST（PACKR が置かれた荷降ろし先）へ運ぶ作業を交代で繰り返しています。「x1」「無編集」の表示どおり、早送りなしで撮っています。
• 現場テストの場（ポハンの物流センター）とデータは、出資元でコスダック上場の OA が提供しています。

暗い3D画面に映っているもの

• 動画の中で「Fleet Management」「Real Time Dashboard」と表示されています。会社のサイトにも、ロボットは標準の API で倉庫管理システム（WMS）につながり、処理量・稼働率・運用ログを見るリアルタイムのダッシュボードがあると書かれています。
• 画面のラベル（韓国語）は次のとおりです。
  • P1・P2：ロボット
  • R1・R2：棚
  • C1：充電器（충전기）
  • P2 자리：P2 の待機場所
  • DEST：荷降ろし先
• ロボットの上には「R1-2 집는 중（R1-2 を掴んでいるところ）」「작업 중（作業中）」といった作業の状態が出ます。線で描かれているのは、これから進む予定の経路です。

実機と違うところ（画面から読み取れた範囲）

つまりこの画面は、物理を計算しているのではなく、「位置と作業の状態」に絞って実機を写した影です。実機とのずれが出るとすれば、掴みの失敗や想定外の障害物など、画面に載っていない部分になります。動画の解像度が低いため、画面が実機からどれだけ遅れて動くかは測れませんでした。

いまのサービスロボット導入シミュレーションとの関係

向きが逆です。

• 導入シミュレーションの Unity：入れる前に、仮の店や病院で「何台なら回るか」を試すもの
• PICKR の画面：入れた後に、動いている実機を見張って割り当てるもの

両方をつなげると、導入前のシミュレーションと同じ部品（店の形・ロボット・状態の名前）を、導入後の監視画面にそのまま使えます。

補足：画面収録の中で、3Dの画面がどう映っていたか

画面収録を4秒おきのコマに分けて全体を見た。時刻は画面収録の上の時刻で、動画の本編の時刻ではない。画面収録の解像度が低く、3Dの画面の札の数字（電池の残りらしき数字など）は読み切れなかった。

どの場面でも、3Dの画面の札は、実機と同じ動きをしていた。実機より先に動いて結果を見せる場面はなかった。この画面が「事前に試すシミュレーション」ではなく「実機を写す画面」だと判断したのは、この点からだった。

見るだけの監視画面は、データの向きで分けるとデジタルシャドウ

リアルタイムの監視画面（デジタルツイン）

監視画面でもデジタルツインっていうの？

— 見るだけの監視画面も、デジタルツインと呼ぶのか。

厳密には「デジタルツイン」と呼ぶのは言い過ぎで、前の返事の私の言葉選びが緩すぎました。

よく使われる区別（Kritzinger ら 2018年）では、データの流れる向きで3つに分けます。

見るだけの監視画面は、この区別では、デジタルシャドウにあたります。

PICKR の画面は「Fleet Management」とあるので、割り当てや経路をロボットに送り返している可能性があります。そうであれば、画面を含めたシステム全体はデジタルツインに近くなります。ただ、動画からは画面が表示専用なのか、指令を出す側なのかまでは分かりません。

一方で、業界やメーカーの宣伝では、実機の状態を3Dで写していれば何でも「デジタルツイン」と呼ぶことが多いです。言葉として通じはしますが、記事などで使うなら次のように書き分けると正確です。

• 見るだけ：「リアルタイムの監視画面（実機の状態を写した3D表示）」
• 指令まで返す：「デジタルツイン」

導入シミュレーションの Unity は、実機から自動でデータが入ってこないので、この区別では「デジタルモデル」の側です。

補足：3つに分ける呼び方の出どころ

この分け方は、Werner Kritzinger らが2018年に製造業のデジタルツインの論文を整理したときに示したもの（Digital Twin in manufacturing: A categorical literature review and classification）。デジタルツインという言葉が、論文によって指すものがばらばらだったので、実物と画面の間のデータが自動で流れるかどうかで3つに分けた。

この物差しの良いところは、画面の見た目の出来をまったく問わないことだった。どれだけ精細な3Dでも、データが手で運ばれていればデジタルモデルになる。逆に、四角と線だけの画面でも、両方向に自動で流れていればデジタルツインになる。PICKR の画面は見た目が簡素で、物理も計算していないが、実機の状態が自動で写っている点では、自分の Unity より実機に近い所にいる。

実機を Unity につなぐだけではシャドウで、判断を返してツインになる

Unity のシミュレーションは、実機から自動でデータが入ってこない 実機を繋げればデジタルツインなんだね。

— 実機を Unity につなげば、デジタルツインになるのか。

半分だけ正解です。つなぎ方によって呼び方が変わります。

• 実機 → Unity だけ自動でつなぐ：実機の位置や状態が Unity に写るだけなので、デジタルシャドウです。
• Unity → 実機にも自動で返す：Unity の側で判断したこと（次の行き先、何台出すか、速さなど）が人を介さずに実機に届くようになって、はじめてデジタルツインです。

もう一つ条件があります。デジタルツインは「特定の1台・特定の1現場」と対になるものです。

• 今の導入シミュレーションは、仮の店や記憶の店で「もしこうしたら」を試す作りです。実機をつなぐなら、Unity の店の形も、その実際の現場に合わせる必要があります。
• mechArm のほうは、実機と同じ1台を Unity に作ってあるので、こちらのほうが近いです。実機の関節角を Unity に流し込めばシャドウ、Unity で決めた動きを実機に送り返せばツインになります。

なお、つないだ後も「もしこうしたら」を試すシミュレーションとしての使い方は残ります。デジタルツインの価値は、いまの実機の状態から先を試して、その結果を実機に返せるところにあります。

R2R2R の Unity は、実機と同じ1台を写したデジタルモデル寄りだった

前にR2R2Rでやっていたのはデジタルツインでしょ？

— R2R2R でやっていたことは、デジタルツインだったのか。

R2R2R は、厳密な区別に当てはめると、デジタルモデル寄りです。ただ、一般的な呼び方として「デジタルツイン」を使ったのは間違いではありません。

ツインと言える部分

• Unity の mechArm は、実機と同じ1台を写した形と関節になっています。
• 座標系もマットの実寸に合わせてあります。
• 「特定の1台と対になっている」という条件は満たしています。

ツインと言えない部分

データが自動で行き来していませんでした。

• Unity → 実機：FK スキャンの表（CSV）を書き出して、Pi がそれを読んで動きます。返してはいますが、事前にまとめて渡す形です。動いている最中に Unity が判断して送り返しているわけではありません。
• 実機 → Unity：カメラで見たずれは、補正記憶（correction_memory.json）として Python 側に溜まっていきます。Unity には戻っていません。実機の関節角を Unity に流して同じ姿勢で動かす仕組みも、把握している範囲ではありません。

なので、実機と現実で回っていた「失敗から学ぶループ」は、Unity の外で閉じていました。

デジタルツインにするなら

1. 実機の関節角とカメラの位置を Unity にリアルタイムで流す（これでデジタルシャドウ）
2. Unity で次の動きや補正を計算して、そのまま実機に送る（これでデジタルツイン）

補正記憶のループの中に Unity を入れれば、名前どおりのデジタルツインになります。

もし実機の角度を Unity に映す仕組みを以前作っていたら教えてください。その場合は、少なくともシャドウまでは来ていたことになります。

補足：R2R2R の流れを、データの向きで並べ直す

R2R2R の名前は、UC Berkeley と Toyota Research Institute の研究 Real2Render2Real に触発されたもので、現実を画面に写し、画面で試し、現実に返す、という流れを指している。この流れを、Claude の答えに沿ってデータの向きで並べると、こうなる。

自動で回っていたのは、最後の行の補正記憶のループだけで、そこに Unity は入っていなかった。名前の Real2Render2Real の Render の部分は、事前の準備としては働いていたが、動いている最中の判断には加わっていなかったことになる。

移動ロボットの実機は、現場の当てができてから選ぶ

配膳ロボットやAMRなどの移動ロボットなどの実機を購入してほんとうの意味でのデジタルツインを進めて行きたいところだね。

— 移動ロボットの実機を買えば、本当の意味のデジタルツインに進めるのか。

いい方向だと思います。ただ、買う前に二つだけ整理しておくと、無駄なく進められます。

1. 「ほんとうの意味」の中身は、ロボットより現場のほうが大きい

デジタルツインは特定の1台・特定の1現場と対になるものです。配膳ロボットを1台買って自宅や作業場で走らせても、Unity 側の店は仮の店のままです。対になるのはロボット本体だけになります。

いまのサービスロボット導入シミュレーションの価値（何台で回るか、どこで詰まるか）をツインにするには、実際に使われている店か病院の床と人の流れが必要です。なので、ロボットを買うことと、現場で協力してもらうことは、セットで考える必要があります。

2. 自分で決めている設備を買う条件に照らすと

増強の条件は「実測されたボトルネック」です。いまの言い方に直すと、たとえば次のようになります。

Unity と試算の数字が、実機とどれだけずれているかを確かめる手段がない

これは、ずれを測れないこと自体がボトルネックだと記録で示せれば、条件に乗せられる可能性があります。「将来デジタルツインをやりたいから」だけだと、先回りの購入になります。

段階を分けるなら

1. 借りる・協力してもらう：導入済みの店や病院、メーカーから、実機の走行ログ（位置・止まった時間・行き先）をもらう。それを Unity に流せればデジタルシャドウになり、買わずに「ずれ」を測れます。
2. 小さい移動ロボットで仕組みを作る：ROS 2 で動く小型の移動ロボットで、実機 → Unity → 実機の往復を先に作る。配膳ロボット本体より安く、Unity とのつなぎ方は同じです。
3. 本命の機体：1と2で「ずれ」と「往復の仕組み」が記録として揃ったら、配膳ロボットや AMR を買う、または借りる。

協力してくれそうな現場（店・病院・メーカー）に心当たりはありますか？あるなら1から始められるので、買う機体もそこに合わせて選べます。

この問いには、協力してくれる現場の当ては今はまだない、と答えた。

それなら、今やれるのは2の「小さい移動ロボットで往復の仕組みを作る」です。現場がなくても進められて、現場が見つかったときにすぐつなげる準備になります。

ただ、設備を買う条件に照らすと、今すぐ買う理由はまだ弱いです。その前に、買わずにできることが二つあります。

• Unity の側だけで受け口を作っておく：実機のログ（時刻・位置・状態）を流し込めば Unity の配膳ロボットが同じように動く、という読み込み口を先に作っておきます。最初はシミュレーション自身の出力を「偽の実機ログ」として流し込めば、ロボットなしで試せます。
• 現場の当てを作る：これから始めようとしている、地域の企業向けのロボット導入の相談の仕事は、協力してくれる現場を見つけるのにちょうどいい入口です。始めてから、店や病院でログをもらえる関係ができれば、そこが最初のツインの現場になります。

受け口ができていて、現場の当ても見えてきた段階で、移動ロボットを買う理由（記録で示せるボトルネック）がはっきりします。

補足：買う前に、何を記録しておけば買う理由になるか

このプロジェクトでは、設備は「将来やるかもしれない研究」のためには買わず、いま進めている研究で実測されたボトルネックがあり、それを記録や計測値で示せるときにだけ増やす、と決めている。移動ロボットに当てはめると、買う前にそろえておく記録は次の3つになる。

3つ目がそろわないうちに配膳ロボットを買っても、対になる現場がない。先に作れるのは2つ目の受け口だけで、これはロボットもお金もいらない。

移動の技術は小さい機体でも同じだが、メーカーの機体はデータの出し入れが閉じている

小さい移動ロボットで試すのは良さそうだね。技術的には現場に入っているロボットと大差ないしね。

— 小さい移動ロボットで試すことは、現場の機体の練習になるのか。

移動の仕組み（LiDAR で地図を作って自分の位置を知り、経路を引いて障害物を避ける）は、小さい機体でも現場の機体でも、基本はほぼ同じです。そこは小さい機体で十分に学べます。

ただ、デジタルツインに関わるところで、大きく違う点が一つあります。

現場の機体は、データの出し入れが閉じていることが多い

小さい機体（ROS 2 で動くもの）は、位置も指令も全部自分で触れます。一方、市販の配膳ロボットや AMR は、メーカーのアプリや管理画面の中で完結していることが多いです。外に出せるデータ、外から送れる指令は、メーカーが用意した API の範囲に限られます。ツインにできるかどうかは、技術よりもこの「どこまで開いているか」で決まります。

なので、小さい機体でやることは二つに分けておくといいです。

• 小さい機体で作る：Unity との往復の仕組み（ログを受ける口、指令を返す口）
• 現場の機体のときに確かめる：メーカーの API で、その口に何が載せられるか

このほかにも、重さと速さ、安全センサーの止まり方、エレベーターやドアとの連携、人の多さは現場の機体のほうが厳しいです。ただ、これらは往復の仕組みができた後に詰めればいい部分です。

候補になる小さい移動ロボットを調べて比べましょうか？

メーカーの機体からデータが全く取れないことはまずないが、細かさと遅れが違う

メーカーのロボットをいじるときにデータが全く取り出せないなんてことはあるのか？（もちろん保証範囲外になるだろうけど）

— メーカーのロボットから、データが全く取り出せないことはあるのか。

「全く取れない」ということはまずありません。ただ、何がどれだけ細かく取れるかはメーカーによってかなり違います。取り出し方は三段階に分けて考えると整理しやすいです。

1. メーカーの公式 API（正規ルート）

• Pudu（配膳の BellaBot などのメーカー）は Open Platform を公開していて、開発者は無料で申し込める形です。
• Bear Robotics も、第三者がロボットに指令を送り、トレイやバッテリーの状態を受け取れる API を出しています。
• 一方、Keenon について、ある API 調査サイトは、公開の開発者向け API やポータルはないとしています。ただし、代理店や提携先向けに非公開の窓口がある可能性はあります。

ツインにとって大事なのは、API の「粒度」と「遅れ」です。

• Pudu の API では、地図上のロボットの位置は取れるが、座標（x, y, 向き）を指定して送ることはできない、という利用者の報告があります。送れるのは「テーブル1へ」のような名前のついた行き先だけで、経路そのものは指示できません。
• OrionStar の API では、オンライン状態がロボットの定期的な通信で判定され、反映に約15秒の遅れがあると書かれています。

つまり、公式ルートでも「見る」は数秒〜十数秒遅れ、「返す」は行き先の指定まで、ということがありえます。この条件で Unity との往復がどこまで成り立つかを確かめるのが、ツインの設計の中心になります。

2. 外から測る（ロボットに手を入れない）

API がなくても、自分のセンサーを外に付ければ位置と動きは取れます。たとえば天井カメラで追う、ロボットに小さな位置タグを貼る、といった方法です。保証も規約も関係なく、どのメーカーの機体でも同じ仕組みが使えるのが強みです。ただし、ロボットの内部の判断（なぜ止まったか、次にどこへ行くか）は分かりません。

3. 中を開ける（非公式）

多くの機体は中身が Linux や Android なので、技術的には入れることが多いです。ただ、保証が切れるだけでは済まない点に注意が必要です。

• 利用規約違反になる
• メーカーのクラウドの認証を迂回すると、不正アクセス禁止法の問題になりうる
• 仕事として現場に出すときに使えない

研究で一度覗くことはあっても、サービスの土台にはできません。

ハードは作らず、シミュレーションとソフトで現場に入るという立ち位置だと、本線は1の公式 API と2の外から測るの組み合わせになります。どのメーカーの機体が入っている現場でも使える形にできます。小さい移動ロボットで試すときも、あえて「行き先の名前しか送れない」「状態は数秒遅れる」という制限を自分でかけて試すと、現場の機体に近い練習になります。

補足：調べたメーカーの API の、出せるものと返せるもの

Claude が答えるときに調べたページを、表にまとめた。どれも公開されている資料と利用者の報告からで、実機で確かめたものではない。

実機と Unity の往復に置き換えると、返せる指令が「名前のついた行き先」までのメーカーでは、Unity で決めた細かい経路をそのまま実機に送ることはできない。Unity の側で決めて返せるのは、次にどこへ行かせるか、何台を出すか、どの順番で回すか、という割り当ての判断になる。導入シミュレーションで比べてきたのも、台数・待機の場所・回す順番だったので、メーカーの API が返せる範囲と、シミュレーションで決めたいことは重なっている。

外付けのカメラで測れるのは位置と止まり方で、止まった理由は分からない

外付けのセンサーやカメラでどこまでできるかというのが、ポイントにはなりそうだね。

— 外付けのセンサーやカメラで、どこまで測れるのか。

そうですね。しかも、これまでの積み上げがそのまま効く領域です。

すでに持っている技術とつながる

• ホモグラフィで、カメラの画素を床の座標（mm）に変える：R2R2R でブロックの位置を出していたのと同じ仕組みです。
• 画像認識シリーズの検出と測り方（IoU など）
• LOG418 の、録画から長い止まりを見つける試し（PatchCore）

天井カメラで移動ロボットを追うのは、「ブロックを上から見て位置を出す」を店の広さにしたものです。

外から分かること・分からないこと

右側は、外から見た動きのパターンから推測するか、API で補うことになります。外から測る仕組みがしっかりしていれば、API の情報は「答え合わせ」として足すだけで済みます。

現場で効いてくる壁

• 人が写ること：店、特に病院では、カメラの設置に同意と運用の決まりが必要です。人を映さない工夫（真上から低解像度で撮る、骨格や点だけを残す、LiDAR を使う）が、技術と同じくらい大事になります。
• 隠れ：人や棚の陰にロボットが入ると見失います。カメラの台数と置き方で解決します。
• 見分け：同じ見た目のロボットが複数あるとき、どれがどれかを取り違えないようにする必要があります。

最初の一歩（買わずにできる）

上カメラのスマホで机の上を撮り、手で動かすおもちゃや紙の駒を追って、床の座標を Unity にリアルタイムで流します。これだけで「外から測る → Unity に写す」（デジタルシャドウ）の最小の形ができます。あとで小さい移動ロボットに置き換えても、仕組みはそのまま使えます。

この話のあと、今すぐはできないが、これから試していく必要はありそうだ、と返して、対話を終えた。

補足：PICKR の画面と、これから作る画面の違い

PICKR の監視画面は、メーカーが自分のロボットの中のデータを使って作ったものだった。ロボットが自分の位置と「何を掴んでいるところか」を知っているので、画面にそのまま出せる。外から測る形では、位置と止まり方は出せても、「R1-2 を掴んでいるところ」のような作業の中身は、API で補うまで出せない。

右の列で人の流れが取れることは、導入シミュレーションにとっては大きい。導入シミュレーションでは、店員や看護師の動きもロボットと同じ店や病院の中で動かして、どこで詰まるかを見てきた。メーカーの監視画面には出ない人の動きを外から測れれば、シミュレーションの人の動きを、実物と比べられるようになる。

デジタルツインの入り口は、機体より先に、データを受ける口と外から測る仕組み

監視画面は、実機を写すだけならデジタルシャドウで、画面の判断が実機へ自動で返って、はじめてデジタルツインになる。自分の Unity をそこへ進めるには、機体を買うより先に、データを受ける口と、外付けのカメラで測る仕組みを作る。

出典

• PyBrain AI「AI自律走行ロボット群制御 無編集デモ [PICKR EP.6]」（YouTube） 題名は YouTube の自動翻訳。元は韓国語の動画
• PyBrain AI Inc. 製品の説明と、WMS への接続・リアルタイムのダッシュボードの説明
• Dealroom「Logistics robotics maker PyBrain AI raises $485K from Kosdaq-listed OA」 会社の設立と、OA との協業
• Signalbase「PyBrain AI Inc. Raises $483.0K」
• Kritzinger ら「Digital Twin in manufacturing: A categorical literature review and classification」（2018年）
• PUDU Open Platform
• Open Robotics の掲示板「Robot Integration (#623)」
• Bear Cloud API
• OrionStar Robot OpenAPI
• API Evangelist「KEENON Robotics」