【Geek Terminal】Gemma 4は「怠惰」なのか？Redditで勃発した26B MoEモデルを巡る熱狂と落胆の全貌

2026年4月13日にお伝えした、Google Gemma 4 31Bがベンチマークで世界3位を記録したニュースの続報です。リリースから数日が経過し、ローカルLLMコミュニティ（特にRedditのr/LocalLLaMA）では、混合精度モデルである「Gemma 4 26B A4B（MoE）」の評価を巡って激しい議論が巻き起こっています。

事の発端は、一部のユーザーから上がった「Gemma 4は『怠惰（Lazy）』ではないか？」という不満の声です。特定の複雑な指示に対して回答を簡略化しすぎたり、ステップバイステップの解説を端折ったりする挙動が見られるとして、「性能を抑えすぎているのではないか」という疑念が呈されました。しかし、この「怠惰」という指摘に対し、実用性を重視する開発者層からは真っ向から反論が飛んでいます。

Redditユーザーのpizzaisprettyneato氏は、64GBメモリのMac環境で「HTML/JSによるDoomスタイルのレイキャスター作成」という過酷なコーディングテストを実施。その結果、競合となるQwen 3.5 MoEが「思考ループ」に陥り、同じファイルを何度も書き直して完成させられなかったのに対し、Gemma 4 26Bはわずか3回のプロンプトで動作するコードを完成させたと報告しました。同氏は「Gemma 4は詳細に迷い込まず、やるべきことを即座に実行する。これは怠惰ではなく、極めて高い実行能力だ」と絶賛しています。

この挙動の背景には、Gemma 4独自の技術的アプローチがあります。26B A4Bモデルは、総パラメータ数26Bでありながら、推論時にアクティブになるのはわずか4Bという極めて軽量なMoE（Mixture of Experts）構成を採用しています。さらに、今回導入された「Shared KV Cache（共有KVキャッシュ）」は、モデルの最終層が先行する層のKey-Value状態を再利用することで、メモリ消費と計算量を劇的に削減しています。また、「Per-Layer Embeddings (PLE)」という、各デコーダー層に小さな残差信号を注入する新技術により、フロントロード（初期段階での詰め込み）なしで、必要な層が必要な時に情報を処理できる設計になっています。

LMArena（Chatbot Arena）でのELOスコア1452という数字が示す通り、Gemma 4はクローズドソースの有料APIモデルに匹敵する知能を、Raspberry Piや一般的なコンシューマーPCで動作可能なサイズで実現しています。一部のユーザーが「怠惰」と感じる挙動は、実はGoogleが意図した「推論の最短経路化」の結果である可能性が高いというのが、現在の技術的な見方です。

今後の展望として、この「思考の冗長性を削ぎ落とした」Gemma 4の特性は、自律型エージェントやリアルタイムコーディングアシスタントにおいて、従来の「考えすぎて動けなくなる」大型モデルに代わる強力な選択肢になると期待されています。コミュニティでは現在、この『効率的な知能』をさらに引き出すためのシステムプロンプトの最適化が急速に進められています。