Info Progress Update 11th April

No, not really, because the question doesn't make a great deal of sense. Probability as mathematicians, statisticians, and probabilist know it is some sort of measure of likelihood---the Gachapon is not that, it is just a virtual machine one talks to. The things it does has certain probabilities of happening. Moreover, just for the record, things do not have to be random at all for probability to be a meaningful concept. We could discuss the probabilities of the various outcomes of the Gachapon even if it returned the aforementioned cheese literally every time, all it would mean is that the probability of cheese is 100% and the probability of everything else is 0%.

Probably (puns intended and so forth) not very much. Or, rather, not really even a little bit. Computers are terrible at doing random things. Their whole deal is being predictable, deterministic machines. Clever mathematicians and computer scientists fake it, however, and create pseudorandom number generators, which seem random.

There are essentially two ways of doing this: good ways and fast ways. The good ways are so-called cryptographically secure pseudorandom number generators, and are the sort of algorithms one wants to use when dealing with encryption or related things. (The condition, for the interested reader, is that it should be impossible to predict the next bit in a stream with better probability than 50% in polynomial time; to my knowledge there is only one generator mathematically proven to be secure in this sense, called BBS and it's horrendously slow to the point where practically no one wants to use it in practice.)

The fast ones are not cryptographically secure at all, in fact they are really quite predictable. Sort of. More on this in just a moment.
Most programming languages implements at least one fast way to get pseudorandom numbers, and it is often a linear congruential generator. This is the case for Java's java.util.Random, for instance.

On to predicting outputs: Knowing the parameters of a linear congruential generator, i.e. the multiplier, addend, and modulus (as we do for Java's java.util.Random, as seen in the source code above), makes it trivial to predict the next output if we know the previous output. We would just plug in the random number it gave us last into the same formula and we are off to the races.

However in practice there are two things stopping us from doing this in a game such as this. Reason number one is that we don't actually have any idea of what the previous number was. Many actions in the game that require random numbers to be generated don't manifest themselves to the player in the shape of a number we can record at all, and even the ones that do will not be the actual number returned by the generator, instead it will be derived in some way from that number. For instance, consider the amount of Mesos dropped by a monster. That is a (pseudo)random number in some range, but when the source code for the game server asks the computer for a random number, the computer internally generates a number in some range which it then manipulates and alters until it's an amount of Mesos between, say, 60 and 100, or what have you.
Reason number two is that even if we knew what the current state of the generator was because we figured out how to reverse engineer it from how many Mesos we got from a monster, we could not use this to predict the very next random number we will encounter in game, because, as it happens, many more things than our own actions in game depend on random numbers; the next number in the stream that we predict could be used for someone else's Meso drop, or a Gachapon interaction, or someone scrolling, or the direction a monster starts running in, or any of a large number of actions spread across the game that we couldn't possibly record.

(Strictly, all pseudorandom number generators depend on a seed in some shape or form.)
It is exceedingly unlikely that the programmers would seed the generator with the current game state. There are three reasons for my saying this: reason one, it would be technically challenging. They would have to distil the current state of the entire game, in some shape or form, into a large number and throw that into the generator. There are certainly ways to do this, but they are problematic because of reason number two: It would be ridiculously computationally expensive. Or, in other words, it would be slow.
Reason number three is that it is simply an overly complicated solution (and for technical reasons also a pretty bad idea) to a problem that has easier and better solutions that require essentially zero work. The aforementioned java.util.Random, for instance, simply seeds the generator with the current time (as recorded by the computer's clock) in nanoseconds. That's generally good enough.
For applications that require more entropy, say when seeding cryptographically secure pseudorandom number generators, the practice is generally to do the same but also throw in some other source of noise, like a few of the insignificant bits of the temperature of the processor, the user's current cursor position, etc..

If all of this has convinced anyone of anything, and indeed if anyone actually read this far, it is hopefully that the above is not the case.

Nor this. But, on a happy note, at least we now know the details of the generator being used, as linked in the Java source code above. I do not know for a fact that the game server uses java.util.Random, but it is very likely indeed to be the case.

This, on the other hand, is true! In the strictest sense of random it isn't random at all! Not even a little bit! But it is, for all practical purposes, unpredictable, which is not the same thing. The answer to the last bit is almost surely "not very complex at all," as it happens.