Fujitsu、FANUC、Yaskawa、Kawasaki和NVIDIA並未發表完成的共同機器人或合資公司。2026年7月啟動的合作仍在探索階段，目標是以具主權、開放的控制底座連接不同企業的機器人和設備，評估製造、物流與醫療的商業機會。產品名、價格與上市日均未決定，價值要等多廠牌場域驗證和標準文件出現後判斷。
五家公司目前共識是探索商機與開發控制底座
Fujitsu 2026年7月16日官方公告指出，公司已和FANUC、Yaskawa Electric及Kawasaki Heavy Industries展開實體 AI（Physical AI）商機探索。Fujitsu主導討論，規劃整合NVIDIA開放式Physical AI技術，開發連結數位與物理世界的協同控制平台。
公告關鍵字是explore，也就是研究與探索。共同開發方向確立，不等於共同人形機器人已量產、付費客戶合約已簽，或方案已成國際標準；合約、智慧財產、具體產品與支援時程仍待後續文件。
| 參與者 | 公告列出的資產 | 尚缺的證據 |
|---|---|---|
| Fujitsu | AI、運算、資料、安全，主導協同控制平台討論 | Physical OS供應範圍與版本 |
| FANUC | 工業機器、AI能力、支援ROS 2與Python的開放平台 | 接上共同平台後的客戶場域驗證 |
| Yaskawa | MOTOMAN NEXT、i3-Mechatronics及ROS 2支援 | 機器、伺服與上層AI責任邊界 |
| Kawasaki | 工業機器、營運資料和醫療整合經驗 | 醫院場景的安全與隱私驗證 |
| NVIDIA | Cosmos、Omniverse、Isaac與Newton | 工具之外的重複性能及成本 |
Fujitsu想補上企業系統與機器控制之間的共同層
工廠的生產計畫、安全PLC、機械手臂、AMR與檢測設備常各自獨立；醫院的處方、檢體、掛號和搬運機器也分散。協同控制底座可理解為把上層業務目標拆成多台設備可執行的工作，再把結果送回原系統。
Fujitsu其他技術策略所稱Physical OS也位於這一層，需要連接描述人、物件和設備狀態的世界模型、工作規劃器、各廠牌控制介面，以及資料與安全政策。目前公告仍是研發方向，尚未確定公開API、支援設備清單、延遲保證或價格。
共同層也不應取代設備內的即時控制。上層AI可要求「把零件送到下一製程」，關節扭矩、急停與安全區仍應由各廠牌已認證控制層優先。命令衝突時誰能否決若沒文件規範，開放整合反而會成為單點故障。
FANUC、Yaskawa與Kawasaki面對的機器問題並不相同
FANUC聚焦製造現場的工業機器和開放平台連接。官方發言提到ROS 2、Python及Fujitsu自主AI平台，真正難題是在不破壞既有生產單元穩定性的前提下，接受更彈性的上層規劃。
Yaskawa把2017年提出的i3-Mechatronics、資料自動化經驗、標配NVIDIA GPU的MOTOMAN NEXT與ROS 2串在一起。它同時掌握機械手臂、運動與伺服資料，場域要驗證上層慢速推論和毫秒級控制的分界。
Kawasaki則強調多種工業機器、現場營運資料及醫療應用，並提出串起住院、診療、手術與復健的醫院整合構想。病患、檢體和藥品並存的環境，在安全、責任與隱私上更嚴格，醫院展示不能等同長期營運。
NVIDIA工具支援訓練與模擬，不能直接證明現場成果
合作文件列出NVIDIA Cosmos基礎模型、Omniverse函式庫、Isaac開放平台和Newton物理引擎。Cosmos用於理解真實環境及社會、物理模擬；Omniverse與Newton建構和驗證物理虛擬環境；Isaac銜接機器訓練、開發與部署。
NVIDIA機器人平台把訓練、模擬和推論拆成不同運算層。工具也許能縮短開發時間，卻不能證明某台FANUC、Yaskawa或Kawasaki機器已通過客戶工作；仍要列出模型與函式庫版本、模擬條件、實機重複次數和人工介入。
Fujitsu Physical AI Technology Strategy把空間世界模型與多機協作放在長期路線中。策略文件說明準備做什麼，不能當成現有可交付功能表。
製造、物流與醫療會用不同方式測出平台弱點
Fujitsu列出的初期場景有製造、零售物流與醫療。工廠要依生產變化和現場狀態調整計畫；物流要連接銷售、庫存和搬運；醫院則考慮藥品、檢體運送及接待引導。
場景改變，失敗意義也不同：工廠停機損失產量，物流故障帶來訂單延誤和機群壅塞，醫院送錯藥品或檢體則涉及人身安全與責任。通過共用API，不代表同時滿足三個產業的營運要求。
| 場景 | 必須串接 | 要注入的失敗條件 |
|---|---|---|
| 製造 | 生產計畫、機械手臂、檢測與安全PLC | 緊急改單與安全控制衝突 |
| 物流 | 銷售庫存、AMR、門與電梯 | 單一機群故障堵住其他廠牌 |
| 醫療 | 醫院營運、藥品檢體運送與引導 | 病患辨識錯誤、敏感資料外洩、堵塞急救通道 |
| 共同層 | 模型、介面、紀錄檔與升級 | 簽章錯誤、斷網與部署錯版 |
開放與主權不是相反概念
開放平台讓參與企業與研究機構使用共用介面、擴充能力，不是讓任何人無限制操控機器。呼叫端身分認證、角色權限、軟體簽章、安全閘門和稽核紀錄仍是必要條件。
主權控制也不只是資料存放在日本。誰能查看生產或病患資料、能否用於訓練、誰可核准或拒絕模型升級、事故紀錄由誰保存和刪除，都包含在內；伺服器位置符合要求，營運權限卻全交給外部，仍不算完整資料主權。
公告也提醒，應用擴大後，網路攻擊、系統中斷、誤動作和機密外洩風險會增加。多廠牌平台方便串接，也可能讓單一帳號或升級問題擴散，因此需要機群隔離、回復與離線安全運行。
標準化要靠多廠牌相容測試，不是只有介面文件
Fujitsu表示會同步推動協同控制底座的標準化與開放。即使草案公開，如果不同廠牌機器仍無法在真實場域完成同一工作，互通性就尚未驗證。
好的試行會把FANUC機械手臂、Yaskawa設備、Kawasaki系統和其他廠商AMR放在一起，共享預約、地圖、安全狀態和故障復原；再刻意升級或停掉一台，確認其餘設備能否安全繞行，並注入延遲、拒絕命令、版本不一致和紀錄缺漏。
場域連接可參考Open-RMF多機器人協作，機群命令規範見VDA 5050 3.0標準解讀，定位則看VIO與SLAM比較。這項合作和既有標準是競爭或互補，要等詳細規格。
合作成敗要由共同客戶場域的重複結果回答
下一次更新最值得找的，是兩家以上廠牌機器在同一客戶場域反覆工作。除了成功率，還應公布介入率、壅塞時間、故障隔離、舊版回復和資料存取紀錄。
商業證據也要跟上：有付費試行、客戶、上市時程和支援組織後，才能說合作由探索進入產品階段。標準成果則要包含介面、安全、資料主權規範與相容測試流程，詳細到外部參與者可重現。
五家知名企業同桌只是起點。長期價值是證明不同世代、不同廠牌的機器能安全互聯，客戶同時保有資料與營運控制權。
常見問題
五家公司已決定共同推出人形機器人嗎？
沒有。官方公告確認的是探索Physical AI商機和開發協同控制底座，共同產品型號、價格與上市日均未確定。
開放介面代表外部任何人都能控制機器嗎？
不是。共用介面仍需身分認證、角色權限、安全閘門、軟體簽章與稽核紀錄；開放不等於無限制控制。
資料主權只要求伺服器設在日本嗎？
不只。還包含資料存取、訓練再利用、升級核准，以及紀錄保存、刪除和稽核權由誰掌握。
已查核的官方資料
最後查核：2026年8月23日