Gemma 4 12B：ローカルAIは「小型チャット」から「手元のマルチモーダル実行基盤」へ

今日の一本は、Google DeepMindが6月3日に公開したGemma 4 12Bです。見出しだけ見ると「12Bの新しいオープンモデル」ですが、少し掘ると主題はモデルサイズではありません。むしろ、クラウド上の巨大モデルに任せていたマルチモーダル・エージェント的な処理を、ノートPC上にどこまで戻せるか、という実装の話です。Gemma 4 12BはApache 2.0ライセンスのオープンウェイトモデルとして公開され、Googleは16GBのVRAMまたはユニファイドメモリを持つ一般的なラップトップでのローカル実行を前面に出しています。(blog.google)

何が新しいのか。ポイントは「エンコーダーなし」の統合マルチモーダル設計です。従来の多くのVLMは、画像なら画像エンコーダー、音声なら音声エンコーダーでいったん特徴量に変換し、それをLLM本体へ渡します。Gemma 4 12Bではこの分離を薄くし、画像パッチや音声信号を軽量な射影でLLMの埋め込み空間へ直接入れる構成にしています。開発者向け解説では、画像は48×48ピクセルのパッチを単一の行列積などで射影し、音声は16kHz信号を40msフレームに切って線形射影すると説明されています。(developers.googleblog.com)

ここで面白いのは、性能競争の軸が「大きなモデルをクラウドで呼ぶ」から「モデル、ランタイム、端末内ツールを一体で配る」へ少し動いていることです。Googleは同時にAI Edge GalleryのmacOS対応、音声入力・編集アプリAI Edge Eloquent、LiteRT-LMのローカルサーバー機能を打ち出しています。LiteRT-LMはOpenAI互換のローカルAPIサーバーとして動かせるため、AiderやContinueのような既存の開発ツールから、ローカルのGemma 4 12Bを呼び出す道が開かれます。(developers.googleblog.com)

つまり、これは単に「ローカルでチャットできます」ではありません。手元のCSVを読ませてPythonコードを生成・実行し、グラフを作る。音声メモをローカルで整形する。画像や動画の内容を端末内で読み取り、次の作業に渡す。こうした小さなエージェント的ワークフローを、通信コストや外部送信への懸念を抑えながら試せるようにする発表です。Google自身も、データが端末に残ること、応答性やコスト効率を保てることをAI Edge側の価値として説明しています。(developers.googleblog.com)

ただし、ここは冷静に見たいところです。Gemma 4 12Bは「ローカルで動くフロンティア級モデル」ではなく、「ローカル実行できる中規模マルチモーダル基盤」と見る方が正確です。モデルカード上のベンチマークでは、MMLU Pro 77.2%、AIME 2026 no tools 77.5%、LiveCodeBench v6 72.0%などの数字が示されていますが、これはGoogle側の評価であり、実際の開発タスクや日本語業務文書、長時間音声、企業内データでどう振る舞うかは別途検証が必要です。(huggingface.co)

もう一つの論点は、安全性と運用責任です。クラウドAPIでは、プロバイダー側の監査、レート制限、コンテンツフィルタ、ログ設計がある程度組み込まれます。一方、ローカルモデルは自由度が高いぶん、アプリ開発者や組織側がガードレールを設計しなければなりません。モデルカードも、誤情報、バイアス、悪用、プライバシーリスクへの注意を明記しています。オープンであることは透明性と検証可能性を高めますが、それだけで安全になるわけではありません。(huggingface.co)

今回の発表の核心は、「AIをどこで動かすか」という問いが再び重要になってきたことです。クラウドの巨大モデルは今後も強い。一方で、毎回クラウドへ送るほどではない作業、個人情報や社内資料を含む作業、低遅延で繰り返す作業は、端末側に戻る余地があります。Gemma 4 12Bは、その境界線を少し押し広げるリリースです。

これからのローカルAI競争は、モデル単体の点数だけでは決まりません。どの端末で動くか。どのツールから呼べるか。音声、画像、コード実行、ファイル処理をどこまで自然につなげられるか。そして、開発者が安全に組み込めるか。Gemma 4 12Bが示したのは、ローカルAIの本番は「軽いチャットボット」ではなく、手元の環境そのものを使う小さな作業OSに近づいている、ということだと思います。