It's important to appreciate that a transaction log holds critical data for your database. The name is somewhat misleading if you're more familiar with the type of logs used purely for human review (which can be deleted and the impact is typically zero). Transaction Logs are different.
The transaction log is used in case of system error/failure, to roll back uncomitted transactions in the database. It's also critical to the backup process, to ensure your backup consists of a full, transaction-complete set of data. A backup taken while a half-completed transaction is underway is not a valid backup.
Transaction log growth is linked to database activity. The higher the activity on your database, the faster the databases transaction logs will grow.
So with this in mind, the long-term solution to this problem is in several parts:
Move your SQL data to a non-system volume (Add disks and create a completely seperate D:\ drive. Detach, move, then re-attach your data and log files). This ensures that the OS remains stable even if SQL fills its disks. Also, a seperate array hosting the SQL data will be faster than running an OS + accessing DB files on the same disk.
Ensure your backups are taken daily on the server and that this process rolls the logs in appropriately
Provision enough free storage on the new drive so that there is ample space for growth.
Implement some form of monitoring to ensure that when disk space drops below a certain threshold, you're alerted to the problem and can rectify it before it turns into an outage. This could be as simple as running a perfmon counter from your workstation that polls the server every hour to check % free disk space, or a more complex solution depending on your needs and what products you may already own e.g. IPMonitor.