Is it safe to use a MAC as iv for CTR encoding?
First remark here should be don't roll your own crypto.  That said, your idea seems to be a variant of Synthetic Initialization Vector mode (SIV, RFC 5297), where a pseudorandom function of the plaintext and associated data is used to generate a value that doubles as the message authentication tag and the IV for the cipher.  Your random 3-5 byte value is an optional nonce, which in SIV is just an associated data field.

Note that SIV was designed for deterministic encryption (exceptional cases where it's OK if encrypting the same plaintext twice with the same associated data produces the same ciphertext) and for nonce misuse resistant encryption (cases you don't actually want nonce reuse but you want to minimize the damage if it does happen).  This ties to @EnTaroAdun's answer—the low diversity of random nonce values may be a problem, but if it isn't, then SIV is a well-designed, well-vetted mode that handles your scenario out of the box.  SIV also allows for arbitrary associated data fields, which can help mitigate potential duplication problems by including other contextual data other than the 3-5 random bytes into the synthetic IV computation.

SIV is not a common mode, so there's a good chance you won't find a ready-made implementation for your language.  So apart from a several nasty details (e.g., why not just use truncated HMAC-SHA2 directly?  Are you vulnerable to MAC equality comparison timing attacks?  How are you generating keys for the MAC and cipher?), your idea is neither obviously wrong nor obviously right either.