受注から出荷まで — FAIRINO FR5 ＋ IPC ロボットセルの完全フロー｜環境差適応・無調整出荷・クラウドRLコスト

第0部 — 前回の回答を保存環境差（照明・床色）にどう適応するか

現場ごとに照明も床の色も違う。これにどう対応するか——答えは、あなたのスタックが「2つの別々のモデル」でできているという事実から導けます。

左：環境（照明・床色）の影響を受けるカメラ知覚。右：座標数値を受け取る環境非依存のRL方策 — 左＝知覚（カメラ／YOLO）は照明・床色の影響をモロに受ける。右＝**制御方策**（RL）は数個の座標数値しか受け取らないので、環境色に対して本質的に不変。対策は全部「左側」に寄せる。

核心：あなたの心配は「知覚」に当たり、「制御」には当たらない

B7 RL方策（出荷するONNX）

34次元の状態ベクトルを入力にする —— 物体姿勢（3つの数値 detected_puck）、関節位置/速度、グリッパ、位相フラグ。画素は一切ない。 構造上すでに照明・床色に不変。床を見ることが物理的にできない。

sim-to-realのギャップは「ダイナミクス」＋「姿勢推定ノイズ」だけ。前者は events_dr.py の成功率連動DR（PD/摩擦/質量±20%）で、後者は detected_puck へのσ=3mm/5mmガウスノイズで、すでに叩いている。

B6 YOLO11s 検出器

照明と床を見る唯一の構成要素。カメラ → 物体姿勢 → 方策の detected_puck スロットへ。 環境差はここに宿る。

つまり本当の問いは「現場の照明／床でもYOLOが正確な3数値を渡せるか？」。方策を環境に適応させる必要はない —— 適応は全部検出器に閉じ込め、方策はタダ乗りさせる。これがそのまま“具体的なアーキテクチャ”であり、あなたは既にそれを持っている。

すでに持っているもの（＝ドメインランダム化の教科書レシピ）

レイヤ	すでにランダム化済み	コード位置
YOLO合成データ	ドーム光＋平行光の強度／色／向き、物体・治具の色、カメラ位置・傾き	isaac_fr5/dataset.py:144-161
YOLO学習	UltralyticsデフォルトのHSVジッタ（色相/彩度/明度）、反転、モザイク、スケール	train_yolo.py:40（デフォルト適用）
RL方策	PDゲイン±20%、摩擦、質量±20%、姿勢ノイズ	events_dr.py / fr5_pick_env_cfg.py

⚠ あなたの心配にピタリ一致する「2つの穴」

① 床・テーブルの材質が“明示的に”ランダム化されていない（dataset.py:287 でわざわざ除外と明記）。検出器はたった1種類の地面しか見たことがない。これがまさに「床の色」。最も効く修正。
② 露出／コントラストのランダム化がない。実カメラは自動露出するが、合成データは固定露出。

同一ワークベンチ場面を6通りの異なる照明色・床材質でレンダリングしたドメインランダム化 — 視覚ドメインランダム化の考え方：**同じ場面**を多数の異なる照明色・床材質でレンダリングして学習させる。検出器が「色に依存しない形状」を学ぶことで、未知の現場照明・床でも姿勢を正確に出せる。今の穴①は、ここに「床材質のランダム化」を足すこと。

具体策（優先順）

床・テーブル材質のランダム化を合成データ生成に追加

dataset.py の Randomizer.randomize() で、いまキューブ／治具の色をランダム化しているのと同じ要領で床・テーブルの材質をランダム化（できれば単色でなく小さなテクスチャバンクからランダム適用）。約20行の変更で、明示的に除外されている唯一の項目を埋める。再生成→再学習→mAP再確認。合成mAPは少し下がるはず＝タスクが正直に難しくなった証拠で、実環境ロバスト性は上がる。

最優先~20行再レンダリング要

露出・コントラスト・ブラーのランダム化

Replicatorのポストプロセス（露出・モーションブラー）か、YOLO学習ノブを明示的に上げる（hsv_v 増、RandomErasing 追加、軽いブラー）。YOLO側だけなら再レンダリング不要で安い。

安い再レンダリング不要(YOLO側)

“少量”の実写データを撮る（検証＋微調整用）

定番の知見：DRだけで大半は届くが、実環境の床・照明で撮った実写を数十〜200枚使って合成モデルを微調整すると残りのギャップが閉じる。さらに重要なのは——いま実環境mAPの数値が存在しない。ギャップを測るためだけにも実写は要る。simから得られない唯一のもの。

50–200枚simでは代替不可

方策の姿勢ノイズσを“実測”YOLO誤差に合わせる

実写が揃ったらYOLOの実際の位置決め誤差を測る。3mm/5mmの仮定より悪ければ observations.py:31-48 のσを上げて再学習。環境差が方策に届く経路は「見た目」ではなく「検出誤差の大きさ」——ここが唯一の接点。

実測連動

（任意・堅牢な保険）単眼YOLO姿勢に最終mmを賭けない

深度／ステレオカメラ、または接触確認ステップを足すと、姿勢の見た目依存が激減。reactive_runtime.py には既に confirm_grasp() のスタブ穴がある。

任意ハード追加

正直な但し書き

これらはまだハードに繋がっていない。reactive_runtime.py の実機パス（FairinoServoJArmController）は NotImplementedError スタブで、カメラ→YOLO→ハンドアイ→detected_puck の知覚ブリッジはB6部品＋TODOコメントとしてのみ存在。だから本当の手順0はこの知覚ブリッジを作ること。実フレームで走るまで、床色の問題は「測定」ではなく「予測」しかできない。

第1部受注 → 学習 → 調整 → 出荷の完全フロー

「注文 → IPC＋FR5を即販売」の理想に対し、新規タスクで現実に必要な工程はこれです。鍵は各工程をテンプレ化・自動化して、人手を最小の所に集約すること。

受注書 → CADモデル → シミュレーション → AI学習(GPU) → 実機＋実写 → 出荷箱への流れ — 受注書 → 部品CAD → シミュレーション構築 → RL学習（GPU） → 実機＋実写データ → 出荷。左から右へ一本のパイプライン。人手が要るのは両端（ヒアリングと現地立ち上げ）に偏る。

受注 / 引き合い

顧客は「IPC＋FR5のセット」を発注。ここでセット（ハード）の出荷自体はすぐできるが、“何をさせるか”が未定なら方策は空。

所要：即日自動化度：—人手

ヒアリング（要件定義）

何をピック／仕分け／組付けするか。部品の種類・寸法・素材・公差、セルのレイアウト、サイクルタイム、カメラ設置。ここが全工程の入力であり、最大の人手律速。チェックリスト＋写真テンプレで標準化する。

所要：0.5–2日自動化度：低人手

CADデータ取得（部品・治具）

ボルト・ナット・部品のCAD（STEP/STL）。顧客支給が理想。無ければ採寸→モデル化、または3Dスキャン。robot-guideは既にURDF/メッシュ取り込み（parseBinaryStl→decimateMesh）の口を持つ。

所要：0.5–3日自動化度：中半自動

シミュレーション・ステージ構築

CAD＋セルレイアウトからIsaacシーン（scene.json：パレット、ビン、コンベア、障害物ボックス、jointDynamics）を生成。robot-guideで教示・到達性・衝突・サイクルタイムを事前検証（/api/validate）。パラメトリック・テンプレ化が効く所。

所要：0.5–2日自動化度：中〜高半自動

RL学習（Isaac Lab）

専門家データ生成 → reverse-KLアンカー＋成功率連動DRカリキュラムでPPO学習（既存の≥85%レシピ）。視覚は別途YOLOを合成データ＋DRで学習。GPU時間そのものは安い・速い・自動（詳細は第3部）。

所要：数時間–1日自動化度：高ほぼ自動

実データ投入（写真）・微調整・キャリブ

現地（または社内の再現セル）で実写を撮り、YOLOを微調整・実環境mAPを測定。ハンドアイ校正（handeye.py、ChArUco）。実機キャプチャでreality-gapを測り（realityGap.ts）、必要ならσ・ダイナミクスを更新して再学習。simから得られない唯一の工程。

所要：0.5–2日自動化度：中人手＋自動

出荷 / 現地立ち上げ

検証済みONNXをIPCに焼いて出荷（既にdeploy/rl-policiesの形）。現地で最終受け入れ（実機の成功率・サイクルタイム・誤仕分け0）を確認して引き渡し。

所要：0.5–1日自動化度：中半自動

合計の目安（新規部品・テンプレ整備後）

人手中心のヒアリング／CAD／現地が律速で、おおむね3〜7営業日。GPU学習自体は誤差レベル（数時間）。同型の再受注なら下の第2部のとおり「即」。

第2部「無調整で出荷」は可能か？

正直な答え：条件付きでYES。鍵は「既存テンプレに一致するか」。

受注の性質	無調整出荷	必要なこと	目安
既存テンプレ完全一致同じ部品ファミリ・同じセル・同じカメラ	可能（即）	学習済みONNX＋YOLOをそのまま焼いて出荷。現地で受け入れ確認のみ。	即日〜1日
パラメトリック変種寸法違い・色違い・ビン配置違い	準・無調整	テンプレのパラメータ差し替え→sim再生成→短時間の再学習。実写は少量で検証。	1–2日
新規部品・新規タスク未知の形状／工程	不可（ループ必須）	第1部のフル工程。ただしテンプレ化で数日に圧縮。	3–7日

“無調整”を増やす戦略

受注が来るたびゼロから作るのではなく、部品ファミリ別のテンプレ資産（標準セル・標準カメラ位置・パラメトリックscene.json・学習レシピ・DR設定）を貯める。新規が来たら「最も近いテンプレ＋差分」で立ち上げる。受注を重ねるほど無調整率が上がる。

なぜ完全ゼロ調整は危険か

RL方策は数値ロバストでも、YOLOの実環境mAPと、ハンドアイの実測精度は現地でしか確定しない。ここを飛ばすと「掴めない／取り違える」が出る。第0部の通り、最終mmは知覚精度が握る。だから「少量の実写検証」だけは省略しないのが安全側。

第3部RL学習をクラウドへ（従量課金）— 速度・コスト・ベンダー比較

いまの学習はローカルのRTX 3060。受注が増えたらクラウドGPUの従量課金へ移すべきか。結論から：技術的に容易・コストは些末。効くのはCapex削減と「複数受注の同時並列学習」。

クラウド内のGPUサーバ群が地上のロボットアームへ学習データを降らせる、従量課金のイメージ — クラウドのGPU群がロボット学習を駆動し、使った分だけ課金（pay-as-you-go）。1台の受注に1ジョブを割り当て、受注が重なってもクラウド側で並列に捌ける。自社GPUの先行投資（Capex）が不要になる。

① GPU別 — 速度とコスト（この案件＝状態ベースRLの場合）

あなたのRLは状態ベース（画素なし）なので、律速はカメラ描画ではなくPhysX物理ステップ＋PPO更新。よってRTコア無しのA100/H100でも速い。VRAMが増えるほど並列環境数を増やせて収束が速い。下表はRTX 3060を1.0とした概算。

GPU	VRAM	相対速度 (対RTX3060)	概算 $/hr (専門系オンデマンド)	1学習あたり概算 (GPU時間×単価)	Isaac Sim描画適性 (視覚RL用)
RTX 3060（現状）	12GB	1.0×	自社所有	電気代のみ	可(RTあり)
RTX 4090	24GB	~3–4×	$0.34–0.69	~$0.3–0.7	良(RTあり)
RTX A6000 / 6000 Ada	48GB	~4–5×	$0.49–0.90	~$0.5–1.0	最良(RT・大VRAM)
L40S	48GB	~4–5×	$0.79–1.9	~$0.8–2	最良(RT・大VRAM)
A100 80GB	80GB	~4–6×	$1.07–1.99	~$1–3	RTコア無=描画遅
H100 80GB	80GB	~6–9×	$1.99–3.29	~$2–5	RTコア無=描画遅

※価格は2026年初の専門系プロバイダ（RunPod/Lamb/Spheron等）の概算・大きく変動。AWS/GCP/Azure等のハイパースケーラは同等GPUで概ね2〜4倍（H100で$8–12/hrのことも）。「1学習あたり」は1〜1.5時間想定の単純計算で、実際は専門家データ生成や複数シードでもう少し積む。

② ベンダー比較

区分	代表プロバイダ	強み	弱み・注意	この用途の向き
分散・格安	Vast.ai / RunPod (Community)	最安。RTX 4090が$0.2–0.4/hr	信頼性ばらつき・スポット中断・データ持続性	実験・短時間学習に最適
専門GPUクラウド	RunPod (Secure) / Lambda / CoreWeave / Spheron	安い＋安定。L40S/A6000/H100が揃う。秒課金	リージョン限定・在庫変動	本番学習の主力
ハイパースケーラ	AWS / GCP / Azure	既存基盤統合・SLA・周辺サービス	同GPUで2–4倍高い・割当審査	既に契約があるなら
マネージドRL/Sim	NVIDIA OSMO / Brev 等	Isaac環境のセットアップ済み・運用が楽	割高・ロックイン	運用を外注したいなら

③ ボトルネックは何か

技術側の律速

Isaac SimはRTX（RTコア）前提：視覚RL（B6のカメラ描画）を回すならL40S/6000 Ada/A6000を選ぶ。純コンピュート機（A100/H100）は描画が遅い。状態RL（B7）なら関係ない。
単GPU律速：Isaac LabのPPOは基本1GPU。8×H100の箱を借りても1タスクは速くならない。欲しいのは「強い1枚」か、「多数の受注ジョブを別GPUに並列配備」。
VRAM：12GB(3060)は並列環境数を制限。24–48GBで環境数を増やせて収束が速い。
コールドスタート/中断：Isaacコンテナ約15GBの初回pull、スポット中断リスク。チェックポイント必須。

事業側の“本当の”律速

第1部で見たとおり、GPU時間はロボット1台あたり数十ドル＝事実上タダ。たとえ1台あたり30 GPU時間積んでもL40Sで$36。
本当のボトルネックは人手工程——ヒアリング、CAD整備、現地の実写キャプチャ、ハンドアイ校正。クラウドはこの人手を1秒も減らさない。
ではクラウドの価値は何か：(1) Capex不要（GPUを買わない）、(2) 受注が重なった時に複数ジョブを並列で捌ける（社内の3060は1本ずつ）、(3) 大型機で1案件の学習を数時間に圧縮。需要が読めない受注ビジネスにこそ従量課金が噛み合う。

推奨スタンス

① 開発・実験はRunPod/Vast の RTX 4090（$0.34/hr）で十分。② 本番の納品学習はRunPod Secure / Lambda の L40S か RTX 6000 Ada（RT＋48GB、$0.8–1.5/hr）を主力に。③ 視覚RLを回さない純・状態RLだけならA100がコスパ最良。④ 自社3060はオフライン検証とCI用に残す。受注ごとに「1ジョブ＝1クラウドGPU」を割り当てれば、台数が増えてもスケールする。

まとめ次の一手

知覚を仕上げる

第0部の穴①②（床材質＋露出のランダム化）を dataset.py に実装し、C1→C2ゲートで再検証。実機の知覚ブリッジ（カメラ→YOLO→ハンドアイ→detected_puck）を作って、初めて床色を「測れる」ようにする。

フローをテンプレ化

部品ファミリ別の標準セル・パラメトリックscene.json・学習レシピを資産化。新規受注を「最も近いテンプレ＋差分」で立ち上げ、無調整率を上げていく。

クラウドを薄く導入

まずRunPodで4090実験環境を1つ作り、納品学習だけL40S/6000 Adaに載せる。自社GPUはCI・検証に温存。受注増は「1ジョブ＝1GPU」で並列化。

すぐ着手できる作業（提案）

(a) 穴①＋②（dataset.py の床／テーブル材質＋露出ランダム化＋YOLOノブ）を実装し、既存C1→C2ゲートで回す —— 小さく検証可能な変更。
(b) もしくは、より狭い問いで Gemini ディープリサーチを先に回す：「2025–2026の6-DoF物体姿勢 sim-to-realロバスト性SOTA：テクスチャランダム化 vs フォトリアル描画 vs 実写微調整のデータ効率、実環境mAP差つき」。
おすすめは(a)。既存ゲートに通せる、再実行可能な小変更だから。

受注から出荷まで：FAIRINO FR5 ＋ IPC ロボットセルの完全フロー

3行まとめ