結論|3 行で押さえる Gemma 4 12B
先に要点だけ整理します。
- 16GB クラスのマシンで動く。Ollama の 4bit 量子化版が 7.6GB で、Apple Silicon の Mac や 16GB VRAM の GPU があればローカル実行できます
- 画像・音声・動画を 1 つのモデルで扱える。専用エンコーダを持たない統一アーキテクチャで、音声は 30 秒、動画は 60 秒まで入力できます
- 1 世代前の 27B を半分以下のサイズで上回る。MMLU Pro 77.2、AIME 2026 77.5 と、12B としては異例のスコアが出ています
迷いやすいのは名前と必要スペックの 2 点です。クラウド API の Gemini とは別物のオープンモデルであり、必要メモリは「フル精度なら 24GB 前後、4bit 量子化なら 7.6GB」と精度フォーマットで大きく変わります。この記事では公式モデルカードと Ollama の配布情報をもとに、実際に動かすまでの判断材料を揃えます。
はじめに — ノート PC で動くマルチモーダル AI が現実になった
2026 年 6 月 3 日 (米国時間)、Google が新しいオープンモデル Gemma 4 12B を発表しました。画像・音声・動画まで扱えるマルチモーダルモデルでありながら、16GB のメモリを積んだノート PC でローカル実行できるサイズに収まっている点が特徴です。
ここ数年、「高性能な AI はクラウドの巨大モデルを API で呼ぶもの」という前提が業界の標準でした。Gemma 4 12B は、その前提を「手元のマシンでもここまで動く」方向へ一歩進めたモデルです。AI 駆動開発のクリエイティブスタジオである FIXIT でも、プロダクトに組み込む推論基盤の選択肢として発表直後から動向を追っています。
本記事の数値は、Google 公式ブログの発表、開発者向けガイド、Hugging Face のモデルカード、および Ollama の配布情報に基づきます。
ひと目でわかる Gemma 4 12B
まずは全体像です。
| 項目 | 内容 |
|---|---|
| 開発元 | Google (Google DeepMind) |
| 発表日 | 2026 年 6 月 3 日 (米国時間) |
| パラメータ数 | 有効 11.95B (埋め込みを含めて約 12B、dense 構成) |
| 層数 | 48 層 |
| 入力モダリティ | テキスト・画像・音声・動画 |
| コンテキスト長 | 入力 256K トークン |
| 対応言語 | 140 以上で事前学習、35 以上をネイティブサポート |
| 配布サイズ | 7.6GB (Ollama の 4bit 量子化版) |
| 動作要件の目安 | 16GB の VRAM またはユニファイドメモリ |
| ライセンス | Apache 2.0 |
| 入手先 | Hugging Face・Kaggle (Ollama・LM Studio からも可) |
読み方と正式なモデル ID
読み方は「ジェマ フォー 12B」です。Gemma はラテン語で宝石を意味する語に由来し、Google DeepMind のオープンモデルファミリーの名称として使われています。クラウド API の Gemini (ジェミニ) と名前が似ていますが別のモデル群なので、混同しないよう押さえておきましょう。
Hugging Face 上の正式なモデル ID は次の 3 つです。B が大文字である点に注意してください。
google/gemma-4-12B— ファインチューニングの起点になるベースモデルgoogle/gemma-4-12B-it— 対話向けに調整された instruction-tuned 版google/gemma-4-12B-it-assistant— 投機的デコードで応答を高速化するドラフトモデル
通常の用途では -it 付きの instruction-tuned 版を選びます。3 つ目のドラフトモデルは Multi-Token Prediction (MTP) の実装で、本体モデルと組み合わせるとローカル推論のレイテンシを下げられます。「ローカルで動くだけ」ではなく「ローカルで速く動かす」ための部品まで公式が揃えている構成です。
Gemma 4 ファミリーのどこに位置するのか
Gemma 4 には複数のサイズがあり、12B はその中間に位置します。Ollama で配布されているサイズを並べると、選び方の目安が見えてきます。
| モデル | Ollama 配布サイズ | 想定する実行環境 |
|---|---|---|
gemma4:e2b | 7.2GB | スマートフォン・エッジ端末 |
gemma4:e4b | 9.6GB | エッジ端末・軽量サーバ |
gemma4:12b | 7.6GB | 開発者のノート PC (16GB クラス) |
gemma4:26b | 18GB | ワークステーション (MoE 構成) |
gemma4:31b | 20GB | サーバー・高性能 GPU |
ここで目を引くのが、12B が e4b より小さいという点です。直感に反しますが、E 系のモデルは Per-Layer Embeddings という仕組みを使っており、有効パラメータ数より実体のパラメータ数が多くなります。つまり e4b は「有効 4B 相当で動くが、ディスク上の実体はもっと大きい」モデルです。ノート PC で動かす前提であれば、サイズがほぼ同じで性能の高い 12B を選ぶ判断になります。
補足
ファイルサイズは量子化の設定によって変わります。上の表は Ollama が既定で配布しているタグのサイズです。Hugging Face 上のコミュニティ量子化版を使う場合はサイズが前後します。
何ができるのか — テキスト生成からエージェントまで
画像・音声・動画をひとつのモデルで扱う
Gemma 4 12B は、テキストの読み書きに加えて、画像・音声・動画の入力をモデル単体で受け付けます。モデルカードに記載されている制約は次のとおりです。
| モダリティ | 対応 | 制約 |
|---|---|---|
| テキスト | ○ | 入力 256K トークン |
| 画像 | ○ | 可変解像度 (トークン予算 70〜1120) |
| 音声 | ○ | 最大 30 秒 |
| 動画 | ○ | 最大 60 秒 (毎秒 1 フレーム) |
音声が 30 秒までという上限は、実装のうえで効いてきます。1 時間の会議音声をそのまま渡すことはできないため、実務では音声を 30 秒ごとに分割して順に処理するか、文字起こしに特化したモデルで先にテキスト化してから Gemma に渡す構成をとります。画像はトークン予算が可変なので、解像度を上げるほどコンテキストを消費する点も押さえておくとよいでしょう。
スクリーンショットを読ませて UI の文言を直す、会議音声の要点を書き起こす、製品写真から説明文を起こす。こうした処理を、データを 1 バイトも外部に送らずに手元のマシンで完結させる構成が現実的になります。
256K トークンの長文コンテキスト
入力コンテキストは 256K トークンまで広がっています。リポジトリのコード一式や長い議事録、複数のドキュメントをまとめて渡すような使い方が、ローカル環境でも視野に入るサイズです。
ただし、コンテキストを長く取るとその分の KV キャッシュがメモリを消費します。256K をフルに使う想定なら、モデル本体の 7.6GB に加えて余裕を見ておく必要があります。長文の取り回しについては、公式が MRCR v2 の 128K 設定で 43.4 というスコアを公表しており、長くすれば無条件に精度が保たれるわけではないことも読み取れます。
エージェント用途を見すえた設計
マルチステップの推論やツール呼び出しを前提にした調整が入っており、あわせてエージェント開発向けのスキル集「Gemma Skills」リポジトリも公開されました。ツール利用を測る τ2-bench でも 85.5 というスコアが出ており、エージェントの部品として組み込む前提の仕上がりになっています。
できないこと・向かない用途
採用判断のために、できないことも整理しておきます。
画像・音声・動画は入力としてのみ扱え、出力はテキストのみです。画像生成には対応していないため、その用途では Imagen のような生成専用モデルが必要になります。音声の 30 秒制限、動画の 60 秒制限も上で触れたとおりです。
もうひとつ、最高水準の推論品質が要る場面では上位モデルに分があります。複雑な設計判断や長時間の自律的なエージェント作業では、クラウドの上位モデルのほうが安定します。12B というサイズで到達できる水準を理解したうえで、向く仕事から任せるのが現実的です。
用途別の使いどころ — 具体的に何に使えるのか
スペックを並べても使い道は見えにくいので、実際に任せられる仕事を用途別に整理します。判断の基準は「手元で完結させたいか」と「12B の品質で足りるか」の 2 点です。
開発現場で使う
コード生成では LiveCodeBench v6 で 72.0、Codeforces ELO で 1659 というスコアが出ており、日常的な実装補助には足ります。既存コードの読解と要約、テストケースの下書き、リファクタリング案の列挙といった定型に近い作業が向きます。256K のコンテキストを活かして、関連ファイルをまとめて渡したうえで影響範囲を洗い出させる使い方もできます。
一方、アーキテクチャの選定のような設計判断はクラウドの上位モデルに任せたほうが安定します。開発作業そのものは Claude Code のようなツールで進め、プロダクトに組み込む推論だけをローカルモデルに寄せる構成が現実的です。
社内文書とナレッジを処理する
長文コンテキストが効くのがこの領域です。議事録の要約、仕様書から確認事項の抽出、複数ドキュメントの横断比較といった処理を、データを外部に出さずに回せます。文書理解の指標である OmniDocBench 1.5 のスコアも公表されており、レイアウトを含む文書の読み取りに一定の対応力があります。
社内ナレッジを検索させる用途では、モデル単体ではなく検索拡張と組み合わせる設計が必要です。構成の考え方は RAG 構築の実践ガイド にまとめています。
画像・音声を入り口にした自動化
マルチモーダル対応がそのまま活きる領域です。スクリーンショットから UI の文言を洗い出す、製品写真から説明文の下書きを作る、短い音声メモを文字起こしして要点を整理する、といった処理を手元で完結できます。
音声は 30 秒、動画は 60 秒という上限があるため、長い素材は分割前提で設計します。会議録音のような長時間の音声は、文字起こしに特化したモデルで先にテキスト化し、その後の要約と構造化を Gemma に任せる二段構成が扱いやすいです。
閉域環境・オフラインで動かす
外部 API を呼べない環境で使えることが、オープンモデルを選ぶ最大の理由になります。オンプレミスのサーバや、ネットワークから切り離された端末での推論、現場に持ち出すノート PC 上での処理などが該当します。推論コストがマシン代に固定されるため、大量の定型処理を回すバッチ用途でも読みやすい構成になります。
なぜすごいのか — エンコーダを捨てた統一アーキテクチャ
画像も音声も直接言語モデルに流し込む
これまでのマルチモーダルモデルは、画像にはビジョンエンコーダ、音声には音声エンコーダと、モダリティごとに専用の変換器を前段に置くのが定石でした。先行する Gemma 4 の E2B / E4B もこの構成です。
Gemma 4 12B はここを設計から変えました。画像は約 35M パラメータの軽量な埋め込みモジュールでパッチを直接投影し、音声は 16kHz の波形を 40 ミリ秒ごとのフレームに切って、線形変換でそのまま言語モデルの入力空間へ流し込みます。数億パラメータ規模のエンコーダを足す代わりに、言語モデル本体がモダリティをまとめて引き受ける構成です。
flowchart TB
subgraph before["従来のマルチモーダル構成"]
I1["画像"] --> E1["ビジョンエンコーダ<br/>(数億パラメータ)"]
A1["音声"] --> E2["音声エンコーダ<br/>(数億パラメータ)"]
E1 --> L1["言語モデル"]
E2 --> L1
end
subgraph unified["Gemma 4 12B の統一アーキテクチャ"]
I2["画像"] --> P1["軽量埋め込み<br/>(約 35M)"]
A2["音声 (16kHz 波形)"] --> P2["線形投影"]
P1 --> L2["言語モデルが直接処理"]
P2 --> L2
end
この設計の利点は 3 つあります。エンコーダ分のメモリが浮くこと、エンコード処理が消えてレイテンシが下がること、そしてファインチューニング時にテキスト・画像・音声を同じ重みで一度に更新できることです。
内部構造 — 48 層とハイブリッド注意機構
もう少し内部を見ると、48 層の構成で、注意機構にローカルとグローバルを組み合わせたハイブリッド方式が採られています。狭い範囲を見るスライディングウィンドウ注意 (ウィンドウ幅 1024 トークン) と、全体を見るグローバル注意を層ごとに交互に配置する形です。
この設計は、256K という長いコンテキストを扱いながら計算量を抑えるための工夫です。すべての層で全トークン間の注意を計算すると、コンテキスト長の 2 乗で計算量が膨らみます。大半の層をローカル注意にして、要所だけグローバル注意を挟むことで、長文を扱いつつローカル実行できるサイズに収めています。
ベンチマーク — 1 世代前の 27B を半分以下のサイズで上回る
公式モデルカードが公開しているスコアです。まずファミリー内の比較から見ます。
| ベンチマーク | Gemma 4 12B | Gemma 4 E4B | Gemma 4 31B | Gemma 3 27B |
|---|---|---|---|---|
| MMLU Pro (知識・推論) | 77.2 | 69.4 | 85.2 | 67.6 |
| AIME 2026 (数学、ツールなし) | 77.5 | 42.5 | 89.2 | 20.8 |
| LiveCodeBench v6 (コード生成) | 72.0 | 52.0 | 80.0 | 29.1 |
| GPQA Diamond (科学系の難問) | 78.8 | 58.6 | 84.3 | 42.4 |
| MMMU Pro (画像理解) | 69.1 | 52.6 | 76.9 | 49.7 |
| MATH-Vision (図版つき数学) | 79.7 | 59.5 | 85.6 | 46.0 |
1 世代前の Gemma 3 27B を半分以下のサイズで全項目で上回り、最上位の 31B にも一定の距離まで迫っています。さらに公式は、兄弟モデルの 26B (MoE 構成) と比べても「近い性能を半分未満のメモリフットプリントで実現した」と説明しており、サイズあたりの性能効率がこのモデルの売りです。
12B 単体では、上の表以外にも次のスコアが公表されています。用途に近い指標を見ると判断の材料になります。
| 領域 | ベンチマーク | スコア |
|---|---|---|
| 競技プログラミング | Codeforces ELO | 1659 |
| 難問耐性 | BigBench Extra Hard | 53.0 |
| 多言語知識 | MMMLU | 83.4 |
| 文書理解 | OmniDocBench 1.5 | 0.164 |
| 音声翻訳 | CoVoST | 38.5 |
| 音声認識 | FLEURS | 0.069 |
| ツール利用 | τ2-bench | 85.5 |
| 長文検索 | MRCR v2 (8 needle 128k) | 43.4 |
補足
ベンチマークの数値は公開時点の公式モデルカードに基づきます。実務での体感は量子化の程度やタスクの種類で変わるため、採用判断では自社ユースケースでの評価をあわせて行ってください。
日本語の実力をどう見るか
日本語で使う前提だと、気になるのは多言語性能です。公式では 140 以上の言語で事前学習し、35 以上の言語をネイティブサポート対象としています。多言語の知識を測る MMMLU では 83.4 が公表されており、英語中心の指標と比べても大きく落ちていません。
ただし、こうした総合指標が高いことと、日本語の文章として自然に書けることは別の話です。日本語の生成品質が要件になる場合は、量子化の程度によって崩れ方が変わる点も含めて、自社のデータで確かめるのが確実です。評価の組み立て方は LLM 評価ハーネスの作り方 にまとめています。
Apache 2.0 ライセンスという扱いやすさ
Gemma 4 12B は Apache 2.0 ライセンスで公開されています。商用利用、改変、ファインチューニングした派生モデルの再配布まで広く認められる、企業利用と相性のよいライセンスです。自社プロダクトへの組み込みも、クライアントワークでの提案にも載せやすくなりました。
必要スペックとメモリの目安
ローカル実行で最初につまずくのがここです。「16GB で動く」という説明をよく見かけますが、これは量子化版を前提にした数字です。精度フォーマットごとに必要量が変わるため、順に整理します。
Ollama の配布サイズで見る実測値
もっとも確実な目安は、実際に配布されているファイルサイズです。Ollama の gemma4:12b は 7.6GB です。この状態で 16GB のメモリまたは VRAM があれば、コンテキストを常識的な範囲で使う限り動きます。
ディスク容量は、配布サイズに加えて展開分と他のモデルを試す余地を見て、20GB 程度の空きを確保しておくと安心です。
精度フォーマット別のメモリ目安
パラメータ数から計算すると、フォーマットごとの重み分のメモリは次のようになります。約 12B のパラメータに対して、1 パラメータあたりのバイト数を掛けた概算です。
| フォーマット | 1 パラメータ | 重み分の目安 | 実行環境の目安 |
|---|---|---|---|
| BF16 (フル精度) | 2 バイト | 約 24GB | 24GB 以上の GPU、または 32GB の Mac |
| 8bit 量子化 | 1 バイト | 約 12GB | 16GB クラス (余裕は少ない) |
| 4bit 量子化 | 0.5 バイト | 約 6〜8GB | 16GB クラスで快適 |
Ollama の 7.6GB は 4bit 量子化に相当します。この表は重み分だけの概算で、実際にはこれに KV キャッシュとフレームワークのオーバーヘッドが乗ります。コンテキストを長く取るほど KV キャッシュが増えるため、「重み分 + 数 GB」で見積もるのが実務的な目安です。
コツ
「16GB で動くか」を判断するときは、モデルの重みだけでなく、同時に開いている他のアプリが使うメモリも見てください。Mac のユニファイドメモリは OS やブラウザと共有するため、実効的に使える量は搭載量より少なくなります。
量子化でどこまで落とせるか
Hugging Face 上には多数の量子化版が公開されており、モデルカードの時点で 287 の量子化モデルが登録されています。llama.cpp、LM Studio、Jan、Ollama といった主要なランタイムがそれぞれ対応しています。
選び方の指針はシンプルです。まず 4bit から始めて、品質が足りなければ 8bit に上げます。4bit より小さい量子化はメモリをさらに削れますが、日本語の崩れや指示追従の低下が出やすくなるため、用途を絞って評価したうえで採用してください。同じ評価セットで比べると判断がぶれません。
Mac / Windows / Linux それぞれの現実解
環境ごとに押さえるポイントが違います。
Apple Silicon の Mac はユニファイドメモリを GPU と共有するため、16GB モデルでも 4bit 量子化版が動きます。後述する MLX 版を使うとさらに速くなります。ただし OS とアプリの使用分を差し引く必要があるため、32GB あると余裕を持って扱えます。
Windows / Linux で NVIDIA GPU を使う場合は VRAM が基準です。16GB クラス (RTX 4070 Ti / 4080 など) で 4bit 量子化版が載ります。フル精度を狙うなら 24GB 以上が必要です。
CPU のみでも llama.cpp 経由で動作はしますが、応答速度は実用域から外れやすくなります。動作確認や単発のバッチ処理に限る用途と考えたほうが無難です。
どう使うのがよいのか — 目的別の始め方
FIXITこういうのって、結局 GPU マシンがないと試せないんじゃないの?
Tsumiki16GB のユニファイドメモリで足りるので、最近の Mac ならそのまま動きます。まず触ってみるのが早いです。
FIXIT
Tsumikiデータを外に出さずに済むことと、推論コストがマシン代に固定されることですね。
FIXIT
Tsumiki高難度の推論はまだクラウドの上位モデルに分があります。向く仕事から任せるのが現実的ですね。
まず触ってみる — Ollama
手元で試すだけなら、Ollama なら 1 コマンドで始められます。
# モデルを取得して対話を開始する (初回は 7.6GB のダウンロードが走る)
ollama run gemma4:12b
# OpenAI 互換 API サーバとして起動する
ollama serveollama serve を使うと、既存の LLM クライアントコードは接続先を差し替えるだけで移行できます。画像を渡す場合は、対話中にファイルパスを添えるとマルチモーダル入力として扱われます。
コツ
公式モデルカードでは temperature 1.0、top_p 0.95、top_k 64 が推奨されています。出力が安定しないときは、まずこの推奨値に合わせてから調整すると比較がぶれません。
GUI で試す — LM Studio
コマンドラインを使わずに試したい場合は LM Studio が向いています。アプリ内のモデル検索で Gemma 4 12B を探し、量子化のバリアントを選んでダウンロードすると、そのままチャット画面で対話できます。
LM Studio の利点は、量子化の種類を切り替えながら同じ質問を投げて比較しやすいことです。4bit と 8bit で日本語の出力がどう変わるかを確かめたいときは、コマンドを打ち直すより GUI のほうが手早く済みます。ローカルサーバ機能も備えているため、OpenAI 互換 API として他のアプリから呼ぶこともできます。
スマートフォンやタブレットで試したい場合は、Google AI Edge Gallery アプリも用意されています。
Apple Silicon で速く動かす — MLX 版
Mac を使っているなら MLX 版を選ぶと推論が速くなります。MLX は Apple が公開している Apple Silicon 向けの機械学習フレームワークで、ユニファイドメモリと Metal を前提に最適化されています。
# Apple Silicon 向けに最適化されたビルドを使う
ollama run gemma4:12b-mlx同じモデルでも汎用の量子化版より速度が出やすいため、Mac で常用するなら最初から MLX 版で試す価値があります。Intel Mac では利用できないため、その場合は通常の gemma4:12b を使ってください。
アプリに組み込む — LiteRT-LM
ローカル実行をアプリへ組み込む経路として、Google は LiteRT-LM を案内しています。OpenAI 互換の API サーバとして動くため、既存の LLM クライアントコードは接続先を差し替えるだけで移行できます。
litert-lm import --from-huggingface-repo=litert-community/gemma-4-12B-it-litert-lm
litert-lm serveサーバで配信する — vLLM
まとまったトラフィックをさばくなら vLLM が定番です。連続バッチ処理と PagedAttention により、同時リクエストが多い状況でスループットが出ます。
# OpenAI 互換のエンドポイントとして配信する
vllm serve google/gemma-4-12B-it --max-model-len 32768--max-model-len でコンテキスト長を絞るのが実務上のコツです。256K をフルに確保すると KV キャッシュのためのメモリが大きく必要になるため、実際のユースケースに合わせて切り下げるとより多くの同時リクエストを処理できます。SGLang でも同様に配信できます。Hugging Face Transformers、llama.cpp、MLX といった主要フレームワークも公開初日から対応しています。
自社データに合わせる — LoRA / Unsloth
統一アーキテクチャの恩恵が最も出るのはファインチューニングです。従来のように凍結されたエンコーダを別建てで扱う必要がなく、テキスト・画像・音声をまたぐ学習を単一パスで回せます。軽量に始めるなら LoRA、効率を重視するなら Unsloth の利用が公式ドキュメントでも案内されています。
コード生成に寄せたい場合も、専用の Coder バリアントは公開されていないため、gemma-4-12B-it を起点に自社のコードベースでチューニングする形になります。
本番運用に載せる — Google Cloud
Vertex AI の Model Garden、Cloud Run、GKE と、Google Cloud 側のデプロイ経路も最初から整備されています。ローカルで検証したモデルをそのままクラウドの推論基盤へ載せ替えられるため、PoC から本番までの距離が短い点も採用しやすいところです。
Ollama にはクラウド実行向けのタグも用意されており、手元のマシンでは重い処理だけを外に出す構成も取れます。
Gemini と Gemma の違い
名前が似ているため混同されやすい 2 つですが、位置づけは対照的です。
| 観点 | Gemini | Gemma |
|---|---|---|
| 提供形態 | クラウド API・アプリ | モデルの重みを公開 |
| 実行場所 | Google のインフラ | 自社のマシン・インフラ |
| 費用構造 | 利用量に応じた課金 | マシン代に固定 (モデル自体は無料) |
| データの流れ | 外部に送信される | 手元で完結できる |
| 推論品質 | 最上位モデルは Gemma より高い | サイズ相応 (12B としては高水準) |
| ライセンス | 利用規約に従う | Apache 2.0 |
判断の軸は「データを外に出せるか」と「品質をどこまで求めるか」の 2 つです。機密データを扱う処理や、推論コストを固定したいバッチ処理は Gemma に寄せます。逆に、複雑な設計判断や最高水準の品質が要る処理はクラウドの上位モデルに任せます。
クラウドモデルとの使い分け — ローカル LLM をどこに置くか
Gemma 4 12B が向くのは次のような場面です。
- 機密データや個人情報を外部 API に出せない処理 (オンプレミス・閉域環境での推論)
- 大量の定型処理で推論コストを固定したいバッチ的な用途
- オフライン環境やエッジ端末での推論
- 音声・画像を入り口にしたオンデバイスのアシスタント機能
一方で、複雑な要件の設計判断や長時間のエージェント作業など、最高水準の推論品質が要る場面では、クラウドの上位モデルにまだ分があります。クラウド側の現在地は Claude Opus 4.8 とは で整理しています。
実務では「開発作業は Claude Code などのクラウドモデル、プロダクトに組み込む推論はオープンモデル」のような役割分担が現実的です。API 利用料の構造と削減手順は LLM コスト最適化 で、機密データを扱う検索拡張の設計は RAG 構築の実践ガイド で詳しく扱っています。
つまずきやすいところ
導入時に引っかかりやすい点をまとめます。
メモリ不足で落ちる、または極端に遅い。 4bit 量子化版を使っているか確認してください。フル精度を引いてしまうと 24GB 前後が必要になります。量子化版でも遅い場合は、コンテキスト長を絞ると改善することがあります。
長い音声を渡すとエラーになる。 音声入力の上限は 30 秒です。長い音声は分割するか、文字起こし専用のモデルで先にテキスト化してください。動画も 60 秒が上限です。
モデルが見つからない。 Hugging Face の公式表記は google/gemma-4-12B-it で、B が大文字です。ライブラリやツールによって大文字小文字の扱いが変わるため、公式表記のまま指定しておくと確実です。
Coder 版を探している。 専用のコード生成バリアントは公開されていません。gemma-4-12B-it をそのまま使うか、自社データで LoRA チューニングしてください。
Mac で速度が出ない。 MLX 版のタグに切り替えると改善します。Intel Mac では MLX が使えないため、通常版で量子化を強めるほうが効きます。
まとめ — まず手元で動かしてから判断する
整理すると、Gemma 4 12B は「ノート PC で動くサイズに、マルチモーダル対応と 256K コンテキストとエージェント適性を詰め込んだオープンモデル」です。エンコーダを捨てた統一アーキテクチャと Apache 2.0 ライセンスが、その実用性を支えています。
必要スペックで迷ったら、Ollama の 4bit 量子化版が 7.6GB で 16GB クラスのマシンなら動く、という基準を起点にしてください。フル精度が必要になるのは、精度を追い込む研究用途やファインチューニングの一部です。
幸い、試すコストはほぼかかりません。ollama run gemma4:12b で動かして、自社のユースケースに当てて評価する。この順番が遠回りに見えて確実です。評価の組み立て方は LLM 評価ハーネスの作り方 にまとめています。
ローカル LLM やオープンモデルを組み込んだ AI エージェント・プロダクトの開発は AI エージェント開発 で、AI ツールの導入・定着の支援は AI 開発ツール定着支援 で承っています。個別のご相談は お問い合わせ からどうぞ。