There's a concept in threat modelling called spheres of control. A sphere of control is effectively the things in a system that a particular actor has control over. Actors are usually people with different roles, such as unauthenticated users, logged in users, administrators, etc., and each of these has their own sphere of control. If you think about how these spheres overlap, or might overlap, you can better understand what resources each actor has access to (or at least should have access to) and use that to identify where your risks might be concentrated.
You have one sphere for everyone. You, the trusted user, have persistent admin access on an OS and they, the untrusted users, have exactly the same level of persistent access. No matter what control you put in place, they can circumvent it, because you have the same sphere of control as an untrusted user.
For the purposes of my answer here I'm going to ignore the potential for hardware modification. While they're technically possible, your students probably don't have sufficient motivation and resources to implement such attacks, and if I included them in the threat model my answer would be much more complicated and bleak.
What you need to do is create two separate spheres of control, and enforce the separation with a security boundary. If the students require administrative access on the OS, you cannot enforce separation between you and them on that OS. To demonstrate why this is the case, imagine the scenario in which you use full-disk encryption (FDE) such as BitLocker, LUKS, or VeraCrypt in order to encrypt the data on your drive. You hand the laptop off to a student, with your disk encrypted. They can't unlock the drive because they don't have your password, but they can install a keylogger on the system and steal your password the next time you unlock the disk.
One way around this is to install a second copy of the OS onto your hard disk, then use FDE to encrypt it, resulting in a multi-boot system where students get access to one "dirty" instance of the OS, and you get access to a "clean" instance of the OS. When the system boots, the POST or bootloader gives the user two options to boot from, and they cannot boot from your copy of the OS without knowing the FDE password. The FDE password entry is done outside of the OS, so it is outside of the students' control sphere. This creates two separate spheres of control with a strong security boundary that is (given certain caveats) outside their sphere of control.
You can improve the security of this approach if you use a TPM with your FDE, to prevent brute-force attacks, and enable Secure Boot to prevent manipulation of the bootloader and preboot authentication binaries. This is made more difficult to mess with if you apply a BIOS administrator password.
Regarding setting up FDE, you've got a few options. If you're using Windows 10 Pro you'll have access to BitLocker, which is the most convenient. Unfortunately it isn't available on Windows 10 Home edition.
To enable BitLocker on a data drive (i.e. a drive that the OS isn't installed on) you can just type BitLocker into the start menu search and then click "Turn BitLocker on" on the fixed data drive you want to encrypt. By default, when you start the computer the drive will be locked, and when you try to open it in Explorer it'll ask you for your password to unlock the drive. You can later right click the drive and lock it again. It's a manual process, although obviously it locks the drive automatically when you shut down the computer.
One important caveat is that when you unlock a drive, it is accessible by all users that are logged on. So if you're logged in and have unlocked the drive, then hand the laptop to a student who uses Switch User to also log in at the same time, they'll be able to read the unlocked disk. You should lock the disk manually or shut down before giving them the laptop.
It's worth noting that BitLocker may present you with an option to automatically unlock the drive on startup. This is usually used for situations where you want to have a data drive encrypted as well as your OS drive, but don't want the inconvenience of having to manually unlock the drive on startup. Unfortunately this cannot be done on a per-user basis, so you shouldn't choose this option in your situation.
If you don't have Windows 10 Pro, and therefore don't have BitLocker, you could use VeraCrypt instead. Launch VeraCrypt, click Create Volume, pick "Encrypt a non-system partition/drive", select "Standard VeraCrypt" volume, click "Select Device...", pick the partition associated with the drive you want to encrypt, then choose "Encrypt partition in place". You can then pick your password and encrypt the volume. When you want to unlock it later, you just launch VeraCrypt, pick the partition to mount, and unlock it with your password. The same precautions apply as with BitLocker in terms of giving students access to the laptop while the drive is unlocked.
