---
title: "Gemma 4 12BでローカルAIを動かす｜必要スペック・Ollama API実装・26B A4Bとの違い"
url: "https://www.issoh.co.jp/tech/details/12370/"
published: 2026-06-04
updated: 2026-10-15
categories: ["LLM・RAG"]
publisher: "株式会社一創"
---

# Gemma 4 12BでローカルAIを動かす｜必要スペック・Ollama API実装・26B A4Bとの違い

Gemma 4 12Bは、Google DeepMindが2026年6月3日に公開したオープンウェイトのマルチモーダルモデルです。画像と音声の専用エンコーダーを持たない「Unified」構成で、パラメータ数は11.95B、ライセンスはApache 2.0です。Googleは「16GBのVRAMまたはユニファイドメモリで動く」と説明しており、社内データを外へ出さずに動かすローカルAIの有力な候補になります。この記事の解説対象は、12Bに固有の仕様、ベンチマーク上の位置、量子化ごとの必要メモリ、Ollamaでの動かし方に加え、Ollama APIで社内文書RAGを組むPythonコードと、業務に入れるかの判断基準です。説明の根拠はモデルカードと公式ドキュメントの数値です。2026年10月時点で各ランタイムに報告されている不具合も扱います。

## まとめ：Gemma 4 12Bの要点と選ぶ条件

- **中身**：総パラメータ11,959,730,224のDense型、48層、コンテキスト256Kトークン。入力はテキスト・画像・音声・動画で、出力はテキストのみです。
- **性能**：GPQA Diamond 78.8%、LiveCodeBench v6 72.0%で、26B A4B（82.3%、77.1%）に数ポイント差まで迫ります。BigBench Extra Hardは53.0%と64.8%で、差が大きく開きます。
- **必要スペック**：Google公式の目安は4bitで6.7GB、8bitで13.4GB、BF16で26.7GB。Ollamaの既定タグ `gemma4:12b` は7.7〜8.0GBです。
- **26B A4Bとの違い**：メモリは12Bの方が軽い一方、生成速度は活性3.8Bの26B A4Bの方が速くなることがあります。16GB機で動かしたい、音声を入力したいなら12Bを選びます。
- **制約**：音声は1回30秒まで、動画は1fpsで60秒まで。画像生成はできません。
- **注意点**：Ollamaでは名前に「12b」を含まない派生モデルを作ると小型用のテンプレートが選ばれる不具合が未解決です（2026年10月時点）。
- **ローカルAIとしての使い所**：社外へ送れない文書の要約・分類・抽出に向きます。Ollamaの既定コンテキストはVRAM 24GiB未満だと4Kトークンなので、RAGで使うときは広げてから評価します。

Gemma 4の全5サイズの一覧と選び方は[Gemma 4とは｜モデル一覧・必要スペック(VRAM)・量子化(GGUF/AWQ)・ローカル実行を解説【2026年版】](/tech/details/11651/)にまとめています。以下では12Bに固有の話に絞ります。

## ローカルAIにGemma 4 12Bを使う前提：社外送信ゼロと16GB機で動く意味

ローカルAIは、生成AIのモデルを自社のPCやサーバーで動かし、入力から出力までを手元で完結させる使い方です。クラウドのAPIと違い、プロンプトに入れた顧客情報や設計書が外部の事業者へ送られません。Gemma 4 12Bがこの用途の候補に挙がるのは、次の条件がそろうためです。

- **ライセンス**：Apache 2.0で、商用利用・改変・社内配布に独自の利用規約への同意が要りません。社内の法務審査で確認する論点が、Gemma 3までの独自規約より少なく済みます。
- **機材**：4bit量子化なら重みは公式目安で6.7GBです。16GBのGPU1枚、または16GB以上のユニファイドメモリを積んだMacで動き、専用のGPUサーバーを調達しなくても検証を始められます。
- **入力の幅**：テキストに加えて画像と音声を1つのモデルで受け付けます。帳票画像の読み取りと短い音声の文字起こしを、別々のモデルを用意せずに試せます。
- **費用**：トークン単位の従量課金がありません。かかるのは機材と電気代、運用の手間です。

引き受ける負担もあります。知識は2025年1月までの学習データに基づくため、新しい情報は毎回入力で渡す必要があります。性能はクラウドの最上位モデルに届かず、モデルの更新、ランタイムの不具合対応、アクセス制御はすべて自社の作業です。ローカルLLM全般の仕組みとクラウド型との違いは[ローカルLLMとは？クラウド型との違い・必要スペック・Ollamaでの構築手順を解説](/column/details/12964/)で整理しています。

## Gemma 4 12Bの仕様：エンコーダーを持たないUnified構成

12Bは、Gemma 4ファミリー（E2B・E4B・26B A4B・31Bは2026年4月公開）に後から加わった5番目のサイズです。[公式ブログ](https://blog.google/innovation-and-ai/technology/developers-tools/introducing-gemma-4-12B/)は位置づけを「エッジ向けのE4Bと、より高度な26B MoEの間を埋める」と説明し、中型として初めて音声入力に対応した点を挙げています。

| 項目       | 値                  | 出典           |
| -------- | ------------------ | ------------ |
| 公開日      | 2026年6月3日          | 公式ブログ        |
| 総パラメータ   | 11,959,730,224     | Hugging Face |
| 構造       | Dense・48層          | モデルカード       |
| 注意機構     | 局所40層（窓1,024）＋全体8層 | config.json  |
| コンテキスト長  | 256Kトークン           | モデルカード       |
| 語彙サイズ    | 262K               | モデルカード       |
| 入力       | テキスト・画像・音声・動画      | モデルカード       |
| 出力       | テキストのみ             | モデルカード       |
| 学習データの期限 | 2025年1月            | モデルカード       |
| ライセンス    | Apache 2.0         | モデルカード       |

名前の「Unified」は、エンコーダーを持たない構造を指します。31Bと26B A4Bは約5.5億パラメータの視覚エンコーダーを、E2BとE4Bは約1.5億の視覚エンコーダーと約3億の音声エンコーダーを別に持ちます。12Bはどちらも持たず、入力を直接デコーダー本体へ流し込む構造です。開発者ガイドによると、構成は次のとおりです。

- **画像**：3,500万パラメータの埋め込みモジュールが、他の中型モデルにある27層の視覚Transformerを置き換えます。48×48ピクセルのパッチを1回の行列積で本体の次元へ射影し、縦横の座標情報を足します。
- **音声**：16kHzの音声を40ミリ秒（640サンプル）ずつ切り、線形変換で本体の入力空間へ射影します。E2B・E4Bが使う12層のConformerは使いません。
- **微調整**：画像・音声・テキストが同じ重みを通るため、LoRAなどの追加学習で凍結エンコーダーを別に調整する必要がありません。

公式の説明によると、本体のデコーダー構造は31B Denseと同じです。推論を速めるMTP（Multi-Token Prediction）ドラフターも別リポジトリ `google/gemma-4-12B-it-assistant`（4.2億パラメータ）として配布されています。MTPドラフターの仕組みと効く条件は[Speculative Decoding（投機的デコーディング）とは？仕組みと速くなる条件、LM Studio・llama.cpp・vLLMでの設定](/tech/details/6948/)で解説しています。

## Gemma 4 12Bの性能：ベンチマークで見る26B A4B・E4Bとの差

[モデルカード](https://huggingface.co/google/gemma-4-12B-it)の指示調整版の数値を、隣り合うサイズと前世代の最上位と並べます。

| ベンチマーク              | 12B   | 26B A4B | 31B   | E4B   | Gemma 3 27B |
| ------------------- | ----- | ------- | ----- | ----- | ----------- |
| MMLU Pro            | 77.2% | 82.6%   | 85.2% | 69.4% | 67.6%       |
| GPQA Diamond        | 78.8% | 82.3%   | 84.3% | 58.6% | 42.4%       |
| LiveCodeBench v6    | 72.0% | 77.1%   | 80.0% | 52.0% | 29.1%       |
| Codeforces ELO      | 1659  | 1718    | 2150  | 940   | 110         |
| Tau2（平均）            | 69.0% | 68.2%   | 76.9% | 42.2% | 16.2%       |
| BigBench Extra Hard | 53.0% | 64.8%   | 74.4% | 33.1% | 19.3%       |
| MMMLU（多言語）          | 83.4% | 86.3%   | 88.4% | 76.6% | 70.7%       |
| MMMU Pro（画像）        | 69.1% | 73.8%   | 76.9% | 52.6% | 49.7%       |
| MRCR v2 128k        | 43.4% | 44.1%   | 66.4% | 25.4% | 13.5%       |

Gemma 3 27Bの値は思考モードを使わない条件のものです。Gemma 4側は思考モードの有無が明記されていないため、世代間の差は割り引いて読みます。

公式ブログの「26Bに迫る性能」が当てはまるのは、知識問題（GPQA）、コーディング（Codeforces）、ツール利用（Tau2）です。Tau2ではむしろ12Bが上回ります。一方、BigBench Extra Hardは11.8ポイント、MMLU Proは5.4ポイントの差があり、多段の難しい推論では26B A4Bとの差がはっきり残ります。E4Bとの差はどの項目でも大きく、ノートPCで動く範囲では12Bが一段上の選択肢です。

日本語に限った公式ベンチマークはありません。参考になるのは多言語版MMLUのMMMLUで、83.4%はE4B（76.6%）より7ポイント近く高い値です。社内文書の要約や分類に使うなら、ベンチマークより自社データで試験問題を作って確かめる方が確実です。

## Gemma 4 12Bの必要スペック：16GBで動く条件とメモリの見積もり

### 16GB機で選ぶ量子化ごとの必要メモリとOllamaの配布タグ

[Googleの公式表](https://ai.google.dev/gemma/docs/core)は、重みの読み込みに20%の余裕を足した概算で、12BはBF16が26.7GB、8bitが13.4GB、4bit（Q4\_0）が6.7GBです。実際に配布されているファイルの大きさは次のとおりです。

| 配布物                       | サイズ       | メモリの目安 |
| ------------------------- | --------- | ------ |
| gemma4:12b-it-qat（Ollama） | 7.2GB     | 16GB機  |
| gemma4:12b（Ollama既定）      | 7.7〜8.0GB | 16GB機  |
| gemma4:12b-it-q8\_0（同上）   | 13GB      | 24GB以上 |
| gemma4:12b-it-bf16（同上）    | 24GB      | 32GB以上 |
| 公式QAT GGUF（本体）            | 6.98GB    | 16GB機  |
| 公式QAT GGUF（画像・音声用mmproj）  | 175MB     | 本体と併用  |

16GBで動くという公式の説明は、4bit量子化が前提です。QAT（量子化を見越した学習）版は、量子化しても精度が落ちにくいよう学習させた版で、Ollamaでは学習後に量子化したQ4\_K\_M（8.0GB）より小さい7.2GBです。公式表は重みの読み込み分なので、8bit（13.4GB）を16GBのGPUに載せると文脈用のメモリがほとんど残りません。8bitなら24GB級、BF16（26.7GB）なら32GB以上のメモリが目安です。

### 長いコンテキストで増えるKVキャッシュの計算と256K時のメモリ見積もり

重みとは別に、会話の文脈を保持するKVキャッシュがメモリを使います。12Bは48層のうち40層が直近1,024トークンだけを見る局所注意で、文脈長に比例して増えるのは全体注意の8層だけです。config.jsonの値（全体注意層はKVヘッド1本・次元512）とTransformersの実装から、BF16で保持した場合の理論値を計算すると次のとおりです。

- 局所注意40層：40層×1,024トークン×（K・V各8ヘッド×256次元）×2バイト＝約320MiB（文脈長に関係なく一定）
- 全体注意8層：1トークンあたり8層×（K・V各512次元）×2バイト＝16KiB
- 合計：32Kトークンで約0.8GiB、128Kで約2.3GiB、256Kで約4.3GiB

QAT版の7.2GBに256K分の4.3GiBを足すと約11.5GBです。OSや計算用の一時バッファは含まないため、256Kでの動作を保証する値ではありません。実際の確保量を左右するのは、ランタイム側の実装です。Ollamaでは、空きVRAMがあるのに事前見積もりが過大でCPUへ逃がしてしまう報告（issue #16617）が出ています。生成が急に遅くなったら、まずコンテキスト長を下げて確かめます。

### CPUだけ・GPUなしで12Bを動かす場合の生成速度とE4Bとの選択基準

Ollamaやllama.cppはCPUだけでも12Bを動かせます。ただしCPUでの生成速度はメモリ帯域の影響を強く受け、毎トークン11.95Bすべてを読む12Bは、実効4.5BのE4Bより遅くなるのが一般的です。比べるときは量子化方式とランタイムをそろえます。CPUのみで対話用途に使うならE4Bを、精度が要るバッチ処理なら12Bを選ぶのが現実的です。なお、IntelのOpenVINOバックエンドでllama.cppから12BのGGUFを読み込むと、CPU・GPU・NPUのいずれでも読み込みに失敗する不具合が報告されています（llama.cpp issue #24415、2026年10月時点で未解決）。

## 12Bと26B A4Bはどちらが重いか：メモリと速度が逆転する理由

「12Bと26Bのどちらが重いのか」は、メモリと速度で答えが逆になります。

- **メモリ**：26B A4Bは推論時に総25.2Bパラメータをすべて読み込みます。4bitで公式14.4GB、Ollamaの `gemma4:26b` は16〜19GBで、12B（公式6.7GB、Ollama既定7.7〜8.0GB）の約2倍です。
- **速度**：26B A4BはMoE（混合エキスパート）で、1トークンの生成に使うのは3.8B分だけです。12BはDense型で、毎トークン11.95Bすべてを計算します。

実際、Ollamaの[issue #17362](https://github.com/ollama/ollama/issues/17362)には、Apple Silicon搭載のiMacで `gemma4:12b-mlx` が毎秒18.36トークン、`gemma4:26b-mlx` が毎秒31.67トークンだったという報告があります。コメント欄では「26Bはトークンごとに4B分しか処理しないので、12Bより速いのは想定どおり」という説明が付いています（issue自体は2026年10月時点でOpenのままです）。

メモリが24GB以上あり、音声入力が要らないなら26B A4Bが第一候補です。MMLU ProやBigBench Extra Hardなど多段の推論では26B A4Bが上回り、生成速度も上の報告のように速くなる場合があります。ただしTau2（ツール利用）は12Bが上なので、エージェント用途では自分の環境と量子化方式をそろえて両方を試してから決めます。12Bを選ぶ理由がはっきりするのは、16GB機で動かしたい場合と、音声を直接入力したい場合の2つです。26B A4Bと31Bは音声入力に対応していません。

## Gemma 4 12Bの導入：OllamaとTransformersでの実行手順

### Ollamaでの12B導入と実行コマンド：タグ指定と更新時の確認事項

Ollamaなら、モデルの取得から対話までに必要なコマンドは2つです。タグを省略した `gemma4` は12Bではないので、`:12b` を明示します。12Bの公開直後は版ごとの不具合修正が続いたため（0.30.5でx86・CUDA環境の浮動小数点例外クラッシュを修正、0.30.6でQAT版を追加）、古いOllamaは更新してから使います。2026年10月15日時点の最新の安定版は、10月12日公開の[0.40.4](https://github.com/ollama/ollama/releases)です。

```
ollama pull gemma4:12b-it-qat
ollama run gemma4:12b-it-qat
# 起動中のモデルとメモリ使用量を確認
ollama ps
```

OllamaはOpenAI互換のAPIも公開しています。OpenAIのSDKから使うときは、接続先（base\_url）を `http://localhost:11434/v1`、モデル名を `gemma4:12b-it-qat` などのタグにし、APIキーには任意の文字列を入れます。互換なのはチャット補完など主要なエンドポイントで、OpenAIのすべての機能が使えるわけではありません。

### Hugging Face Transformersでの読み込みと生成

重みは `google/gemma-4-12B-it` から取得します。Gemma 3と違い利用規約への同意は不要で、トークンなしでダウンロードできます（gated=false）。事前に `pip install -U transformers torch accelerate` で依存ライブラリを入れておきます。[モデルカード](https://huggingface.co/google/gemma-4-12B-it)の手順は次のとおりです。

```
from transformers import AutoProcessor, AutoModelForMultimodalLM

MODEL_ID = "google/gemma-4-12B-it"
processor = AutoProcessor.from_pretrained(MODEL_ID)
model = AutoModelForMultimodalLM.from_pretrained(MODEL_ID, dtype="auto", device_map="auto")

messages = [
    {"role": "system", "content": "あなたは社内ヘルプデスクの担当者です。"},
    {"role": "user", "content": "VPNに接続できないときの確認手順を3つ挙げてください。"},
]
inputs = processor.apply_chat_template(
    messages, tokenize=True, return_dict=True, return_tensors="pt",
    add_generation_prompt=True, enable_thinking=False,
).to(model.device)
input_len = inputs["input_ids"].shape[-1]
outputs = model.generate(**inputs, max_new_tokens=512)
response = processor.decode(outputs[0][input_len:], skip_special_tokens=False)
print(processor.parse_response(response, prefix=inputs["input_ids"]))
```

`enable_thinking=True` にすると段階的な推論（思考モード）が有効になり、`parse_response` が思考部分と回答を分けて返します。推奨のサンプリング設定は `temperature=1.0`、`top_p=0.95`、`top_k=64` です。BF16のまま読み込むと26.7GBが必要なので、16GB機ではOllamaかGGUFの量子化版を使います。

### LiteRT-LMでのOpenAI互換サーバーの起動と12Bの実行手順

Googleは12Bの公開に合わせて、LiteRT-LMのCLIに `litert-lm serve` を追加しました。LiteRT-LMのCLIを導入済みであることが前提です。[開発者ガイド](https://developers.googleblog.com/gemma-4-12b-the-developer-guide/)の手順では、Hugging Faceから変換済みモデルを取り込み、OpenAI互換サーバーとして起動します。

```
litert-lm import --from-huggingface-repo=litert-community/gemma-4-12B-it-litert-lm gemma-4-12B-it.litertlm gemma4-12b
litert-lm serve
```

macOS向けには、Google AI Edge GalleryのデスクトップアプリがApple SiliconのGPUで12Bをオフライン実行できます。

### LM Studio・llama.cpp・MLX・vLLMの対応状況と参照先

公式ブログが挙げる対応先は、LM Studio、Ollama、Hugging Face Transformers、llama.cpp、MLX、SGLang、vLLMで、追加学習はUnslothです。llama.cppで画像や音声を入力するには、本体のGGUFとは別にmmproj（マルチモーダル射影）ファイルが必要です。LM StudioでMTPドラフターを使う設定は[LM StudioのMCP設定とGemma 4の動かし方｜OAuth・MTP高速化・Web検索](/tech/details/11736/)、Apple Siliconでの実行は[MLXとは？Apple SiliconでLLMを動かすmlx-lmの導入手順と採用判断](/tech/details/17956/)、サーバーでの同時処理は[vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMと](/tech/details/15786/)を参照してください。

## Gemma 4 12Bの社内連携：Ollama APIのRAG・JSON出力実装

対話で動作を確かめたら、社内ツールからAPIで呼び出す段階に進みます。Ollamaの起動後にREST APIを待ち受けるアドレスは `http://localhost:11434` です。ここでは、社内規程のような短い文書から質問に近いものを探し、その内容だけを根拠に12Bへ答えさせる最小構成のRAG（検索拡張生成）を組みます。

### embeddinggemmaと12Bで社内文書RAGを組むPythonコードの全体像

文書の検索には、Googleの埋め込みモデル[EmbeddingGemma](https://ollama.com/library/embeddinggemma)を使います。パラメータ数は300M、Ollamaでのサイズは622MBで、Ollama 0.11.10以降が必要です（2026年10月15日時点のライブラリページ）。QAT版の12B（7.2GB）と並べても重みの合計は約7.8GBに収まります。事前に `ollama pull embeddinggemma`、`ollama pull gemma4:12b-it-qat`、`pip install requests` を済ませておきます。

```
import json, math, requests

OLLAMA = "http://localhost:11434"
CHAT_MODEL = "gemma4:12b-it-qat"
EMBED_MODEL = "embeddinggemma"

docs = [
    "経費精算は月末締めで、翌月10日までに上長の承認を得る。",
    "VPNに接続できない場合は、社内ポータルで端末証明書の有効期限を確認する。",
    "有給休暇は取得日の3営業日前までに勤怠システムで申請する。",
]

def embed(texts):
    r = requests.post(f"{OLLAMA}/api/embed", json={"model": EMBED_MODEL, "input": texts}, timeout=120)
    r.raise_for_status()
    return r.json()["embeddings"]

def cos(a, b):
    dot = sum(x * y for x, y in zip(a, b))
    return dot / (math.sqrt(sum(x * x for x in a)) * math.sqrt(sum(y * y for y in b)))

question = "VPNにつながらないときは何を確認すればいい？"
doc_vecs = embed(docs)
q_vec = embed([question])[0]
best = max(range(len(docs)), key=lambda i: cos(q_vec, doc_vecs[i]))

schema = {
    "type": "object",
    "properties": {"answer": {"type": "string"}, "source_index": {"type": "integer"}},
    "required": ["answer", "source_index"],
}
r = requests.post(f"{OLLAMA}/api/chat", json={
    "model": CHAT_MODEL,
    "messages": [
        {"role": "system", "content": "社内規程だけを根拠に日本語で答える。次のJSONスキーマで返す: " + json.dumps(schema, ensure_ascii=False)},
        {"role": "user", "content": f"規程[{best}]: {docs[best]}\n質問: {question}"},
    ],
    "format": schema,
    "stream": False,
    "think": False,
    "options": {"num_ctx": 8192, "temperature": 1.0, "top_p": 0.95, "top_k": 64},
    "keep_alive": "30m",
}, timeout=600)
r.raise_for_status()
print(json.loads(r.json()["message"]["content"]))
```

埋め込みは[/api/embed](https://docs.ollama.com/api/embed)で文書と質問をベクトルに変え、コサイン類似度が最も高い1件を選びます。回答の形は[構造化出力](https://docs.ollama.com/capabilities/structured-outputs)の仕組みで固定し、`format` にJSONスキーマを渡します。公式ドキュメントは、スキーマを文字列としてプロンプトにも含めると応答が安定すると説明しており、上のコードはその形に合わせました。サンプリングの値はモデルカードの推奨どおりです。

モデル名は公式タグ `gemma4:12b-it-qat` のまま呼びます。名前に「12b」を含まない派生モデルでは、思考モードを切ってJSONスキーマを指定したときに余計なトークンが付く不具合（後述の#18824）が報告されているためです。この例は文書3件をメモリ上で比べるだけなので、件数が数千を超えたらベクトルデータベースへ置き換えます。PDFの取り込みからチャンク分割、精度評価までの工程は[RAG構築の手順とは？データ整備から精度向上・本番運用までの進め方](/column/details/12920/)、コードを書かずにOllamaへファイルを読ませる方法は[Ollamaでファイルをアップロード・読み込む方法｜公式アプリとOpen WebUIのRAG設定](/tech/details/2381/)にまとめています。

### 既定4Kトークンのコンテキスト長を広げる設定とollama psでの確認手順

RAGで見落としやすいのがコンテキスト長です。[Ollamaのドキュメント](https://docs.ollama.com/context-length)によると、既定値はVRAMの量で決まり、24GiB未満なら4Kトークン、24〜48GiBなら32K、48GiB以上なら256Kです。16GBのGPUで既定のまま使うと4Kで打ち切られ、検索した文書を何件も渡したときに先頭の指示が押し出されます。リクエストごとに変えるなら上のコードの `num_ctx`、サーバー全体の既定を変えるなら環境変数 `OLLAMA_CONTEXT_LENGTH` を使います。Linuxでsystemdから起動している場合の設定例です。

```
# Linux（systemd）で既定のコンテキスト長を16Kトークンに広げる
sudo systemctl edit ollama.service
# 開いたエディタに次の2行を追記して保存
[Service]
Environment="OLLAMA_CONTEXT_LENGTH=16384"

sudo systemctl daemon-reload
sudo systemctl restart ollama
# CONTEXT列が16384、PROCESSOR列が100% GPUになっているか確認
ollama ps
```

12BのKVキャッシュは、前述の計算に当てはめると16Kトークンで約0.6GiBです。QAT版の7.2GBと合わせても16GBのGPUに収まります。`ollama ps` のPROCESSOR列が「100% GPU」以外になっていたら、一部がCPUへ退避している状態です。コンテキスト長を下げるか、量子化をQAT版に替えて確かめます。同時に処理するリクエスト数を決める `OLLAMA_NUM_PARALLEL` は既定1で、上げると必要メモリはコンテキスト長との掛け算で増えると[FAQ](https://docs.ollama.com/faq)に書かれています。

### 社内LANから使うOLLAMA\_HOST設定とAPIキーが無視される点への対策

Ollamaは既定で127.0.0.1の11434番ポートだけで待ち受けます。他のPCから使わせるには、FAQの手順で `OLLAMA_HOST=0.0.0.0:11434` を設定して待ち受けアドレスを変えます。

このとき問題になるのが認証です。[OpenAI互換APIの説明](https://docs.ollama.com/api/openai-compatibility)には「クライアントはAPIキーの値を要求するが、Ollamaはそれを無視する」とあります。11434番ポートに届く人なら誰でもモデルを呼べるということです。社内LANに開くなら、Ollama自体は127.0.0.1のまま待ち受けさせ、前段に認証付きのリバースプロキシを置く構成にします。少なくとも、ファイアウォールで接続元のセグメントを絞ってから公開します。

## 12Bのランタイム別の既知の不具合と回避策（2026年10月時点）

12Bは公開から4か月経っても、ランタイム側の対応に未解決の問題が残っています。「12Bが遅い」「出力がおかしい」と感じたら、モデルの性能を疑う前に次の表を確認します。

| 症状                | 対象                                                                     | 状態  | 回避策            |
| ----------------- | ---------------------------------------------------------------------- | --- | -------------- |
| 小型用テンプレートが選ばれる    | [Ollama #18824](https://github.com/ollama/ollama/issues/18824)         | 未解決 | 名前に12bを含める     |
| 生成が極端に遅い・空応答      | [Ollama #16562](https://github.com/ollama/ollama/issues/16562)         | 未解決 | llama.cpp等で比較  |
| VRAMが空いていてもCPUへ退避 | [Ollama #16617](https://github.com/ollama/ollama/issues/16617)         | 未解決 | コンテキスト長を下げる    |
| OpenVINOで読み込み失敗   | [llama.cpp #24415](https://github.com/ggml-org/llama.cpp/issues/24415) | 未解決 | CPU・Vulkan等を使う |

最も気付きにくいのはOllamaのテンプレート選択です。Ollamaは、モデル名に「e2b」「e4b」が含まれれば小型用、「12b」「26b」「31b」なら大型用のテンプレートを選びます。名前で判定できないときはパラメータ数が120億以上かで決めますが、12BのGGUFは119億と表示されるため小型用に落ちます。小型用は思考モードを切ったときの空の思考ブロックを省くため、モデル本来のチャット形式とは異なる形式です。Ollama 0.33.2での[コメント報告](https://github.com/ollama/ollama/issues/18824#issuecomment-6055396852)では、`FROM gemma4:12b` から作った派生モデルに `think: false` とJSONスキーマ指定で問い合わせると、8回中8回、JSONの後ろに余計なトークンが付きました。Modelfileで派生モデルを作るときは、名前に「12b」を含めるか、`RENDERER gemma4-large` と `PARSER gemma4` を明記します。

#16562は、Apple M4・24GBのMacで `gemma4:12b` が同等サイズの他モデルより大幅に遅く、空の応答を返すという報告です。2026年8月にもOllama 0.33.1で空の応答が再現したという[追記](https://github.com/ollama/ollama/issues/16562#issuecomment-5442270264)があります。同じ症状が出る場合は、llama.cppやLM Studioで同じ量子化版を動かし、ランタイムの問題かどうかを切り分けます。

## 12Bの音声・画像・動画入力：業務処理での使い方と入力の長さ・トークン数の上限

12Bの強みは、音声をテキストに起こさず直接入力できる点です。用途は音声認識（ASR）と、音声を別の言語のテキストへ訳す音声翻訳（AST）で、開発者ガイドは話者分離（ダイアライゼーション）の例も挙げています。ただし入力の長さに上限があります。

- **音声**：1回の入力は最大30秒。会議の録音全体を一度に渡すことはできないため、30秒以内に分割して順に処理します。
- **動画**：モデルカードの上限は1秒1フレームで最大60秒。開発者ガイドには、5分の動画から313フレームを抜き出し、1フレームあたりの画像トークンを70に下げて処理した実演例もありますが、長い動画を一般に扱える保証ではありません。業務では60秒以内の区間に分けます。
- **画像**：1枚に使うトークン数を70・140・280・560・1120から選べます。分類や動画は少なく、OCRや細かい文字の読み取りは多くします。

ランタイムによって受け付ける入力が違う点にも注意します。Ollamaの[gemma4のタグ一覧](https://ollama.com/library/gemma4/tags)では、`gemma4:12b` の入力は「Text, Image」と表示され、音声は記載されていません（2026年10月15日時点）。ローカルで音声を直接入力するなら、前述のTransformersかLiteRT-LMで動かすのが確実です。

プロンプトでは、画像はテキストの前に、音声はテキストの後ろに置くのが推奨です。文字起こしのプロンプトは、モデルカードの形式（言語を指定し「改行せず書き起こしだけを出力」「数字は算用数字で」）に合わせると安定します。

出力はテキストだけなので、12Bで画像を生成することはできません。「画像生成」で検索されることがありますが、できるのは画像の説明、図表の読み取り、OCRなどの理解側の処理です。画像を作るには、別の画像生成モデルを組み合わせます。

## ライセンスと派生モデル：Apache 2.0と「アンセンサー版」の扱い

Gemma 4はApache 2.0で配布され、Gemma 3までの独自規約（Gemma Terms of Use）にあった利用制限条項の継承義務はありません。商用利用、改変、再配布ができます。再配布するときは、ライセンス文の写しを渡し、改変したファイルには変更した旨を明記し、元の著作権・特許・商標・帰属の表示を残し、NOTICEファイルがあればその帰属表示も含めます（Apache 2.0第4条）。

Hugging Faceには、安全性の調整を外したと称する「uncensored」「abliterated」などの派生モデルが多数公開されています。これらはGoogleの配布物ではなく、第三者が重みを改変したものです。Googleは公式モデルについて、性的・危険・差別的な内容などの生成を安全性評価の対象にしたと説明していますが、派生モデルはその評価の外にあります。業務システムに組み込む際の選択肢は、公式の `google/gemma-4-12B-it` です。出力のフィルタリングは自社側で設計します。モデルが外部ツールを呼ぶ構成にする場合の判断は[AIツール使用（Tool Use）とは？LLMが外部を呼ぶ仕組みと実装の判断基準を解説](/tech/details/16314/)が参考になります。

## ローカルAIとして12Bを業務に入れる判断：採用する条件と見送る場面

ここまでの仕様と既知の不具合を踏まえると、結論は次のとおりです。

**採用してよいのは**、以下の条件が重なる場合です。

- 入力に顧客情報・契約書・設計書など、社外のAPIへ送れないデータが含まれる
- 用途が要約・分類・項目抽出・規程に基づく問い合わせ回答など、答えの形を決められる処理である
- 16GB以上のGPUか、16GB以上のユニファイドメモリを積んだApple Silicon機を用意できる
- 同時に投げるリクエストが少ない（Ollamaの既定は1モデルあたり同時1件）

**見送るのは**次の場面です。2025年2月以降の制度や製品の情報を知識として答えさせたいなら、RAGで毎回渡す仕組みを作らない限り使いません。BigBench Extra Hardは53.0%で26B A4Bより11.8ポイント低く、多段の推論が要る審査や見積もりの判断を任せる用途にも向きません。部署全体から同時に呼ばれる社内サービスにするなら、Ollamaのままでは詰まるため、同時処理に強いvLLMなどでの構成に切り替えます。モデルとランタイムの更新を追う担当者を置けない場合は、ローカルにこだわらずクラウドAPIを選びます。

検証は、自社の文書から50問ほどの試験問題を作り、12B・26B A4B・クラウドAPIの3通りで正答率と応答時間を比べると判断材料がそろいます。社内データを外へ出さない生成AIの仕組みを、PoCから既存の業務システムとの連携まで外部に任せたい場合は、一創の[生成AI開発・AI受託開発](https://www.issoh.co.jp/service/ai/development/)でモデル選定とRAG構築をまとめて相談できます。

## よくある質問

### Gemma 4 12Bは日本語に対応していますか？

対応しています。事前学習は140以上の言語、そのまま使える言語は35以上とされ、多言語版MMLU（MMMLU）は83.4%です。日本語に限った公式ベンチマークは無いため、業務で使う前に自社の文書で精度を確認してください。

### Gemma 4 12Bはコーディングに使えますか？

使えます。LiveCodeBench v6は72.0%、Codeforces ELOは1659で、26B A4B（77.1%、1718）に近い水準です。開発者ガイドは、llama.cppで動かした12BをOpenCodeから使い、Gradioアプリを作らせた例を紹介しています。

### Gemma 4 12Bは無料・オフラインで商用利用できますか？

できます。ライセンスはApache 2.0で、重みのダウンロードにも料金や規約同意は不要です。重みとランタイムを一度取得すれば、推論そのものはネットワークにつながっていない端末でも動き、API利用料もかかりません。改変したモデルを社外へ配布する場合は、ライセンス文の写しを付け、変更した旨を明記します。

### Gemma 4 12BとE4Bはどちらを選ぶべきですか？

メモリが16GBあり精度を重視するなら12B、8GB程度の機器やスマートフォン、CPUのみの環境ならE4Bです。12BはE4BよりGPQA Diamondで20ポイント高い一方、必要メモリは4bitで6.7GBと4.5GBの差があり、生成速度も遅くなります。

### Gemma 4 12Bの知識はいつ時点までですか？

事前学習データの期限は2025年1月です。それ以降の出来事や製品の仕様は正確に答えられる保証がないため、最新情報を扱う用途では検索結果や社内文書を入力に渡すRAG構成を組みます。

## 関連記事

- [Gemma 4とは｜モデル一覧・必要スペック(VRAM)・量子化(GGUF/AWQ)・ローカル実行を解説【2026年版】](/tech/details/11651/)
- [LM StudioのMCP設定とGemma 4の動かし方｜OAuth・MTP高速化・Web検索](/tech/details/11736/)
- [Speculative Decoding（投機的デコーディング）とは？仕組みと速くなる条件、LM Studio・llama.cpp・vLLMでの設定](/tech/details/6948/)
- [MLXとは？Apple SiliconでLLMを動かすmlx-lmの導入手順と採用判断](/tech/details/17956/)
- [DiffusionGemmaとは｜4倍速い拡散型LLMの仕組み・スペックとローカルでの動かし方](/tech/details/12470/)
- [ローカルLLMとは？クラウド型との違い・必要スペック・Ollamaでの構築手順を解説](/column/details/12964/)
- [Ollamaでファイルをアップロード・読み込む方法｜公式アプリとOpen WebUIのRAG設定【2026年10月】](/tech/details/2381/)

---

出典: [Gemma 4 12BでローカルAIを動かす｜必要スペック・Ollama API実装・26B A4Bとの違い](<https://www.issoh.co.jp/tech/details/12370/>)（株式会社一創）