First of all, current block size is not 1MB. Segwit soft fork (defined in BIP-141) allowed packing more transactions in a block by moving the witness data (signatures) outside the transaction. The current theoretically allowed weight of the block is 4,000,000 bytes. A little more on how this was achieved without a hard fork is at the end of the answer.
Now coming to your question, as to why a hard fork is required in order to increase block size, we need to understand when a hard fork should occur. A hard fork is a change in consensus rules that are not forward compatible. That means, previous consensus rules will lead to blocks mined after a hard fork as invalid. When a block is mined and propagated across the network, the full nodes first check the block across the different rules to ensure that the block is valid. One of the rules include checking that the block size is below 1MB. Thus including blocks with sizes above 1MB will require nodes to upgrade their consensus rules to verify such block sizes.
Segwit allowed increased block weight with a soft fork (back-war. That means, that the previous consensus rules still declare the new block weight as valid. This was achieved by taking the witness data (signatures that verify the transaction) outside the transaction data. For a non-Segwit aware client (one that did not upgrade to Segwit) these transactions will appear to be locked with signature that anyone can spend and hence are also valid. However, a Segwit aware client sees the Segregated Witness output and expect to find a valid witness for it in the transaction's witness data.