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年版】にまとめています。以下では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での構築手順を解説で整理しています。

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

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

名前の「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での設定で解説しています。

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

モデルカードの指示調整版の数値を、隣り合うサイズと前世代の最上位と並べます。

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の公式表は、重みの読み込みに20%の余裕を足した概算で、12BはBF16が26.7GB、8bitが13.4GB、4bit（Q4_0）が6.7GBです。実際に配布されているファイルの大きさは次のとおりです。

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には、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です。

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 で依存ライブラリを入れておきます。モデルカードの手順は次のとおりです。

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を導入済みであることが前提です。開発者ガイドの手順では、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検索、Apple Siliconでの実行はMLXとは？Apple SiliconでLLMを動かすmlx-lmの導入手順と採用判断、サーバーでの同時処理はvLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとを参照してください。

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

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

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

文書の検索には、Googleの埋め込みモデル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で文書と質問をベクトルに変え、コサイン類似度が最も高い1件を選びます。回答の形は構造化出力の仕組みで固定し、format にJSONスキーマを渡します。公式ドキュメントは、スキーマを文字列としてプロンプトにも含めると応答が安定すると説明しており、上のコードはその形に合わせました。サンプリングの値はモデルカードの推奨どおりです。

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

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

RAGで見落としやすいのがコンテキスト長です。Ollamaのドキュメントによると、既定値は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に書かれています。

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

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

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

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

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

最も気付きにくいのはOllamaのテンプレート選択です。Ollamaは、モデル名に「e2b」「e4b」が含まれれば小型用、「12b」「26b」「31b」なら大型用のテンプレートを選びます。名前で判定できないときはパラメータ数が120億以上かで決めますが、12BのGGUFは119億と表示されるため小型用に落ちます。小型用は思考モードを切ったときの空の思考ブロックを省くため、モデル本来のチャット形式とは異なる形式です。Ollama 0.33.2でのコメント報告では、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で空の応答が再現したという追記があります。同じ症状が出る場合は、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のタグ一覧では、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が外部を呼ぶ仕組みと実装の判断基準を解説が参考になります。

ローカル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受託開発でモデル選定と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年版】
• LM StudioのMCP設定とGemma 4の動かし方｜OAuth・MTP高速化・Web検索
• Speculative Decoding（投機的デコーディング）とは？仕組みと速くなる条件、LM Studio・llama.cpp・vLLMでの設定
• MLXとは？Apple SiliconでLLMを動かすmlx-lmの導入手順と採用判断
• DiffusionGemmaとは｜4倍速い拡散型LLMの仕組み・スペックとローカルでの動かし方
• ローカルLLMとは？クラウド型との違い・必要スペック・Ollamaでの構築手順を解説
• Ollamaでファイルをアップロード・読み込む方法｜公式アプリとOpen WebUIのRAG設定【2026年10月】