3行要約
Gemma 4 はターミナルから起動して、
PC 内のファイル操作・コード編集・シェル実行を LLM に任せる用途で動く。
必要なのは「モデル」「実行エンジン(Ollama / llama.cpp / LM Studio)」「エージェント層(Goose / OpenCode / Claude Code 接続)」の 3 層構造だ。
τ2-bench 86.4%(31B Dense、
Gemma 3 比 13 倍改善)は派手だが、
実装バグとベンチ乖離で詰まる 3 箇所がある。
Ollama v0.20.1 の tool parser、
SWE-bench 52%(Qwen 3.6 の 73.4% に負ける)、
知識カットオフ 2025-01 以降の新ライブラリだ。
M4 Pro 24GB / RTX 4090 級ハードなら 50 tok/s 超の実用速度。
有料クラウドエージェント(Claude Code 月 200 ドル相当)の作業のうち 約 7 割はローカルの Gemma 4 で降ろせる、
というのが 2026-04 時点の冷静な落としどころ。
Gemma 4 が 2026-04-02 に公開された(出典: Google Blog)。
Apache 2.0 ライセンスで商用利用・自己ホスト自由、
E2B/E4B/26B MoE/31B Dense の 4 バリアント、
コンテキスト最大 256K。
ターミナルから直接叩ける「PC 内作業の自動化エンジン」として、
久しぶりに本気で検討する選択肢になった。
ただ、ここで立ち止まる。
ネットの「完全代替」「月 0 円で最強エンジニア」系の見出しは、
ほぼ全部話半分で読んだほうがいい。
公式の τ2-bench 86.4% は確かに強い数字だが、
Paweł Huryn(X で Gemma 4 の tool calling 実態をテスト)は「Ollama v0.20.1 ではファイル取得もツール呼び出しもできない。
chat だけ動く」と明記している(出典: X)。
ベンチの数字と、
実際に PC 内の作業を任せたときの挙動は完全にズレている。
この記事では、
Gemma 4 にターミナル経由でどこまで PC 内作業(ファイル操作・コード編集・シェル実行)を任せられるかを、
実行エンジン × エージェント層 × タスク種別の 3 軸で整理する。
動く組み合わせと動かない組み合わせを、
引用ベースで歯切れよく引く。
Gemma 4 とは何か｜Gemini 3 と同じ研究から出たオープンモデル
Google DeepMind 公式の説明はシンプルだ。
「Built from the same research as Gemini 3」「purpose-built for advanced reasoning and agentic workflows」(出典: Google Blog)。
Gemini 3 の研究成果をオープンウェイトに落とし込んだ、
エージェント用途前提のモデル、
という立て付け。
系譜でいうと、
2025-03 の Gemma 3(1B/4B/12B/27B)、
2025-05 の Gemma 3n(E2B/E4B、
モバイル特化)の後継。
Gemma シリーズ累計ダウンロードは 4 億回を突破している(出典: Google Blog)。
4つのバリアントの違い
| モデル | 有効パラメータ | コンテキスト | 想定用途 |
|---|---|---|---|
| E2B | 2.3B | 128K | モバイル・軽量端末 |
| E4B | 4.5B | 128K | 16GB Mac/家庭 GPU |
| 26B A4B (MoE) | 活性 3.8B / 総 25.2B | 256K | M4 Pro 24GB / RTX 4090 |
| 31B Dense | 30.7B | 256K | M4 Pro 48GB / GB10 |
特徴は MoE が入ったこと。
26B A4B は総パラメータ 25.2B でも推論時の活性は 3.8B なので、
見かけのサイズに対して動作が軽い。
これが「M4 Pro 24GB で普通に回る」現実的ラインを作っている。
ここが Gemma 3 との一番の分岐点だ。
27B Dense 時代は RTX 4090 24GB でもコンテキストを絞る運用が当たり前だったが、
26B MoE で必要 VRAM が 16GB まで降りた。
実質的な「家庭の PC にエージェントを常駐させる」下限が一段下がった形。
公式の τ2-bench 86.4% は何を測っているのか
Gemma 4 の目玉数字は τ2-bench の 86.4%(31B Dense)。
Gemma 3 27B の 6.6% から約 13 倍の改善(出典: Android Developers Blog)。
ここまで跳ねた例はオープンウェイトでは珍しい。
τ2-bench はエージェント的ツール使用を測るベンチマークで、
Google DeepMind によれば Gemma 4 は「6 つの専用スペシャルトークン」でツール呼び出しのライフサイクルを管理する実装になっている(出典: earezki.com 技術解説)。
プロンプトエンジニアリング任せではなく、
モデル側が構造的にサポートする形。
ターミナルからシェルコマンドを叩かせる用途には直接効く設計だ。
主要ベンチの横並び
| ベンチマーク | 31B Dense | 26B MoE | E4B | 測るもの |
|---|---|---|---|---|
| τ2-bench | 86.4% | 85.5% | 57.5% | エージェント的ツール使用 |
| LiveCodeBench v6 | 80.0% | 77.1% | 52.0% | 競技プログラミング |
| Codeforces ELO | 2150 | 1718 | 940 | アルゴリズム実装力 |
| AIME 2026 | 89.2% | 88.3% | 42.5% | 数学コンテスト |
| MMLU Pro | 85.2% | 82.6% | 69.4% | 総合知識 |
| GPQA Diamond | 84.3% | 82.3% | 58.6% | 科学 |
数字だけ見れば 31B はクローズドのフラッグシップと同格に並ぶ。
LiveCodeBench v6 で Gemma 4 31B が 80.0%、
Claude Sonnet 4.6 が 79.6%(出典: BenchLM 比較)。
オープンウェイトがクローズドにベンチ上は追いついた、
とニュースで語られる。
ただし、この数字は一歩引いて見ないと危ない。
SWE-bench Verified 52% という冷や水｜Qwen 3.6 に負けている
LiveCodeBench と τ2-bench が華やかな一方で、
SWE-bench Verified では Gemma 4 31B は 52.0%(出典: LushBinary 比較)。
同じコーディング系ベンチでも、
実リポジトリを改修するタイプの SWE-bench では数字が大きく落ちる。
しかも同じオープンウェイトの Qwen 3.6-35B-A3B は 73.4%。
20 ポイント以上負けている。
τ2-bench と SWE-bench で何がズレているのか
| ベンチ | Gemma 4 31B | Qwen 3.6-35B | 測っている負荷 |
|---|---|---|---|
| τ2-bench | 86.4% | データなし | 単発ツール呼び出し・会話的エージェント |
| LiveCodeBench v6 | 80.0% | データなし | 単発の競技プログラミング問題 |
| SWE-bench Verified | 52.0% | 73.4% | 実 OSS リポジトリの issue 修正 |
つまり「ターミナルで 1 コマンド叩かせる」「1 ファイルを書かせる」は得意だが、
「複数ファイルの依存関係を保ったまま修正する」は苦手、
という差分だ。
BenchLM の評価は同じことを言っている。
引用するとこう。
Gemma 4 covers about 70% of daily coding work at acceptable quality, while the other 30%—where you need deep architectural reasoning or complex multi-file refactoring—still calls for Claude Sonnet or GPT-5 class cloud models.
出典: BenchLM: Claude Sonnet 4.6 vs Gemma 4
日常 70% は Gemma 4、
残り 30% のアーキテクチャ判断と複数ファイル改修はクラウドのフラッグシップに戻せ、
という割り切り。
これが 2026-04 時点の冷静な落としどころだ。
私はこの 70/30 の線引きを、
Gemma 4 を評価する一番誠実な視点だと位置付けている。
実行エンジン別｜tool calling が動くかのマトリクス
ここから本題。
Gemma 4 にターミナル経由で PC 内作業を任せるには、
モデル単体では動かない。
実行エンジン層(Ollama / llama.cpp / LM Studio / MLX)と、
その上のエージェント層(OpenCode / Goose / Claude Code 接続 / aider / Open Interpreter)の両方が噛み合って初めて、
ファイル操作やシェル実行に届く。
2026-04 時点で一番不安定なのは Ollama。
Paweł Huryn の報告はこうだ。
Gemma 4 has function calling built in. Good luck actually using it. I tested it with Claude Code yesterday. It worked as chat only — couldn't retrieve files, couldn't call tools. Just a conversation model in an agentic shell. Ollama: tool parser still broken as of v0.20.1.
出典: Paweł Huryn (X)
「ファイルが取れない、
ツールが呼べない」。
ターミナルから PC 内作業を任せたい人にとって、
これは致命傷の種類のバグだ。
chat だけ動いても意味がない。
同氏の別投稿では 16GB MacBook + Ollama + E4B について「モデル自体のサイズ比の性能は impressive。
ただしツールが呼べない。
chat は動く、
function calling は動かない。
モデルが独自のツールコールスキーマを持っている」と整理している(出典: X)。
OpenCode 側でも同じ問題が GitHub Issue として立っている。
OpenCode の GitHub Issue #20995: E4B 経由の Ollama OpenAI 互換 API でストリーミング tool_calls が認識されない。
Daniel Farina の gist によれば、
Ollama v0.20.0/v0.20.1 では「ツール呼び出しパーサーのクラッシュ」「ストリーミング時に tool call が reasoning フィールドに誤入力」「トークナイザーバグによるガベージ出力」の 3 問題が確認されている(出典: Daniel Farina gist)。
Ollama v0.20.2 で GitHub Issue #15241 が対応され、
tool calling パーサーは修正済み(出典: Ollama GitHub)。
ただし Hacker News のユーザー magic_hamster は「Ollama は最悪のエンジン選択。
vLLM や llama.cpp を推奨」とまで書いている(出典: Hacker News)。
バージョン依存が激しい、
と覚えておけばいい。
実行エンジン × tool calling 動作マトリクス(2026-04 時点)
| 実行エンジン | chat | tool calling | 備考 |
|---|---|---|---|
| Ollama v0.20.0 / v0.20.1 | 動く | 壊れる | パーサー不具合・ガベージ出力 |
| Ollama v0.20.2 以降 | 動く | 動く(改善中) | Issue #15241 で修正。環境差あり |
| llama.cpp(PR #21326+#21343) | 動く | 動く | ソースビルド+--jinja フラグ必須 |
| LM Studio | 動く | 動く | 公式ライブラリ掲載。26B A4B Q4 = 17.99GB |
| MLX(Apple Silicon) | 動く | 部分動作 | TurboQuant 対応・コミュニティモデル経由 |
「とりあえず Ollama」で始めた人が一番ハマるのがこの層だ。
私なら llama.cpp か LM Studio を第一選択にする。
ここだけは譲れない。
エージェント層｜PC 内作業を任せるフロントはどれが動くか
実行エンジンが動いたとして、
その上のエージェント層(ファイル読み書き・シェル実行の実際の担い手)でも動作は割れる。
2026-04 時点で日本語圏に情報が出ている主要 6 種の対応状況をまとめる。
| エージェント | Gemma 4 対応 | tool calling 実態 | 備考 |
|---|---|---|---|
| OpenCode | 対応(最も情報多い) | GitHub Issue #20995 あり(workaround 有) | llama.cpp ルートなら安定 |
| Goose(Block 社) | 対応 | 動く | MCP ツール 3000+ 対応・GitHub Stars 30,000+ |
| aider | Ollama 経由で接続可 | Ollama バージョン依存 | 公式 docs は Gemma 3 までの記載 |
| Open Interpreter | Ollama 経由で接続可 | バージョン依存 | 公式 local_setup.py は gemma2 参照 |
| Claude Code(LM Studio 経由) | 対応 | 動く | 有料エージェント UI をそのまま残す比較参照ルート |
| Gemini CLI | 非対応(公式明言) | 動かない | フォークの llxprt-code が代替 |
注意したいのが Gemini CLI。
公式は「Gemma ローカルモデルをエージェント本体として使う機能は今のところ予定していない」と回答している(出典: GitHub Discussions)。
「Google の CLI だから Gemma が一番動くはず」と思い込むとハマる罠。
代替として紹介されているのがコミュニティフォークの llxprt-code。llxprt --provider openai --baseurl 127.0.0.1:1234/v1/ --model gemma-3n-it の形式で接続できる(出典: 同 GitHub Discussions)。
私が最終的に推すのは Goose ルートだ。
Block 社発で、
Linux Foundation の Agentic AI Foundation(AAIF)の初期プロジェクトに採択されており、
Anthropic と OpenAI の 2 社が支援する公益性の高い位置にある(出典: Effloow レビュー)。
MCP ツール 3000+ に対応し、
ファイル操作・シェル実行・ブラウザ操作まで広い。
運営体制・採用実績・MCP 連携の広さ、
3 点が揃っている。
Gemma 4 をターミナルから PC 内作業の自動化に使う前提なら、
この Goose ルートが実用的な着地点だ。
ハードウェア別｜どの Mac / GPU で実用速度が出るか
モデルと実行エンジンが決まっても、
最後はハードウェアで速度が決まる。
ここは実測値を並べるのが一番早い。
VRAM/RAM 要件(Q4_K_M 量子化時)
| モデル | VRAM 目安 | 動くハード |
|---|---|---|
| E2B | 2-3 GB | 8GB VRAM 以上なら余裕 |
| E4B | 4-5 GB | M4 Base 16GB / RTX 4060 以上 |
| 26B MoE | 16 GB | M4 Pro 24GB / RTX 4090 |
| 31B Dense | 20-24 GB | M4 Pro 48GB / RTX 4090(128K 制限) |
| 31B Dense + 256K | 約 28 GB | RTX 4090(24GB)単体では不足 |
ここで地味にきついのが 31B を 256K コンテキストで使う場合。
KV キャッシュだけで約 22 GB 必要になる、
という r/LocalLLaMA の指摘があって、
RTX 4090 の 24GB 単体だと詰む(出典: Latent Space)。
256K を本気で使うなら M4 Pro 48GB か RTX 5090 クラスの選択肢になる。
推論速度(実測値の抜粋)
| 環境 | モデル | 速度 | ベンチタスク |
|---|---|---|---|
| M4 Pro 48GB(LM Studio) | 26B MoE Q4 | 51 tok/s | — |
| Apple Silicon Mac(Codex CLI) | 26B MoE Q4 | 52 tok/s | 10 回ツール呼び出し 4分42秒 |
| NVIDIA GB10(Blackwell) | 31B Dense | 10 tok/s | 3 回ツール呼び出し 6分59秒 |
| AMD RX 7900 XTX | — | 100 tok/s | HN rsolva 実測 |
| M3 Ultra 48GB | — | 動作確認済み | コンテキスト 65536・HN tuzemec |
| CPU 推論のみ | E4B | 2-5 tok/s | 実用に耐えない |
| CPU 推論のみ | 26B | 0.5-2 tok/s | 実用に耐えない |
| (参考) GPT-5.4 クラウド | — | — | 同タスク 65 秒で完了 |
目を引くのが Codex CLI での実測比較。
Daniel Vaughan は Apple Silicon Mac(26B MoE Q4)で 10 回ツール呼び出しタスクを 4 分 42 秒、
GB10(31B Dense)で 3 回ツール呼び出しを 6 分 59 秒、
同じタスクをクラウド GPT-5.4 は 65 秒で完了、
と書いている(出典: Medium)。
同氏のまとめはこれ。
First-pass reliability mattered more than raw generation speed.
出典: Daniel Vaughan (Medium)
一発目で正しい結果を返すかが、
生成速度より効く。
タスク完了時間で 4-6 倍遅くても、
やり直しが少ないほうが総時間は短くなるという指摘だ。
個人的にはここの論点が一番納得感が強い。
逆に、
CPU 推論だけで突っ込む選択肢は捨てていい。
E4B で 2-5 tok/s、
26B で 0.5-2 tok/s では、
ターミナルでシェル自動化どころか、
待ち時間で心が折れる。
どのタスクをローカルで任せられるか｜単ファイル・マルチファイル・シェル自動化で分ける
ここがこの記事の芯になる論点。
「PC 内作業」と一括りにせず、
単ファイル編集・マルチファイル改修・シェル自動化・MCP ツール連携に分けて、
ローカルに降ろせる境界を引く。
比較参照として、
相場感を出すために有料クラウドエージェント(Claude Sonnet 4.6 クラス、
Claude Code の課金モデル)の線も併記する。
| タスク種別 | Gemma 4 31B ローカル | 根拠 |
|---|---|---|
| 単ファイル編集・ボイラープレート生成 | 任せられる | Dev.to「60-70% of a typical session」 |
| ターミナル直叩きのシェル自動化(ls/find/grep/sed) | 任せられる | τ2-bench 86.4%・単発ツール呼び出しが強い |
| コード補完・コメント生成 | 任せられる | 公式「code completion and correction」 |
| 単発の競技プログラミング | 任せられる | LiveCodeBench 80.0% = クラウド最上位と同等 |
| 数学・論理推論 | 任せられる | AIME 2026 = 89.2% |
| 単発 tool call(検索・計算・ファイル I/O) | 環境次第で任せられる | Ollama は v0.20.2+ 限定・llama.cpp / LM Studio は安定 |
| 複数ファイル横断リファクタリング | 厳しい | SWE-bench 52.0% < Qwen 3.6 の 73.4% |
| 深いアーキテクチャ判断 | 厳しい | BenchLM「残り 30% はクラウド最上位が必要」 |
| MCP ツールの複雑連携(長時間セッション) | 不安定 | HN neonstatic「MCP ツール使用を拒否する」 |
| 2025-01 以降の最新ライブラリ | 任せられない | 知識カットオフが 2025-01・幻覚リスク |
| 200K 超の超長文コンテキスト | ハード依存 | 31B 256K で KV キャッシュ 22GB 必要 |
境界の引き方はシンプルだ。
単発でぶつ切りになる作業はローカル、
長い依存チェーンが絡む作業はクラウド。
ターミナルでファイルを grep して sed で書き換える、
README を更新する、
単体ファイルの補完、
コミットメッセージ生成、
エラーログから原因の一次解析——この系統は全部 Gemma 4 に降ろせる。
逆に Next.js 15 の App Router 全体を一括リファクタする、
依存するテストを壊さずに 10 ファイル横断で型を変える、
MCP で Slack / GitHub / ブラウザをまたいで 1 時間セッションを回す——この系統はクラウドの有料エージェント(Claude Code 月 200 ドル級)に戻す。
コストの差もある。
Gemma 4 31B は API 経由で $0.14/M tokens(入力)、
比較参照として Claude Sonnet 4.6 は 1-2 桁高い(出典: Synthetic Futures)。
ローカルなら通信費ゼロ。
量が出るタスクほど Gemma に逃がす経済性が効く。
XDA Developers の Adam Conway はこう総括している。
Gemma 4 isn't the smartest local LLM I've run, but it's the one I reach for most.
出典: XDA Developers
「最賢ではないが、最も手が伸びる」。この距離感が Gemma 4 の正体だ。
動くのに動かない｜コミュニティが報告した 4 つの躓きポイント
Hacker News と r/LocalLLaMA のスレッドを横断すると、
同じトラブルが繰り返し出てくる。
共通項は単純で、
Gemma 4 は「文脈が長く依存が絡む仕事」で挙動がブレるという 1 点に収束する。
具体的には 4 類型。
- ライブラリ知識が弱く MCP ツール使用を拒否する(HN neonstatic): 知識カットオフが 2025-01 なので、それ以降のフレームワーク変更をファンタジー扱いする(出典: Hacker News)
- ツール使用でループに陥る(HN cjbgkagh): 同じツール呼び出しを繰り返して終わらない
- コンテキスト制限で agentic 処理が低下(HN gerard_labs): 大入出力タスクで性能が大きく下がる
- 複雑なコードベースで半端な実装を出力(HN axjns): 途中で諦める・TODO コメントで埋める挙動
裏を返せば 4 つの躓きは全て「長い依存チェーン」「MCP の複雑連携」「2025-01 以降の最新 API」という 3 本柱に紐付く。
SWE-bench 52.0% の弱さと同じ根っこだ。
複数ファイルの依存を保つ力、
最新エコシステムへの追従、
長時間の MCP セッションで一貫性を保つ力。
この 3 つが Gemma 4 の構造的な弱点であり、
SWE-bench と現場報告が同じ結論に収斂する形で現れている。
一方で賛成寄りの声も具体的。
HN fortyseven は「初めて OpenCode を local server で確実に使えるようになった。
Godot エンジン学習に効果的」、
egorfine は「M5 Pro 48GB で M4 Pro から 8 倍高速化を実現」、
prettyblocks は「Vision/OCR 能力が同等級の他モデルより優秀」と報告している(出典: 同上)。
両側の声を並べると、
Gemma 4 の使いどころは「単発でぶつ切りになるタスク」「OCR 含む視覚入力」「明確に境界が切れる問題」にハマる、
という傾向が浮かぶ。
reverse 側の「長い依存チェーン」「MCP の複雑連携」「知識カットオフ以降の最新 API」は苦手、
と覚えておく。
最短セットアップ｜Ollama 地獄を避ける 3 ルート
Ollama の tool calling 問題を踏まえて、
2026-04 時点で相対的に安定している 3 ルートを並べる。
いずれも出典元のコマンドをそのまま引いたもの。
ルート A: llama.cpp + OpenCode(tool calling 安定重視)
# macOS
brew install llama.cpp
# 26B Q4_K_M で起動(--jinja フラグ必須)
# GGUF モデルタグは公式配布の `gemma-4-26B-A4B-it-GGUF` 形式
llama-server -hf <gemma-4-26B-A4B-it-GGUF>:Q4_K_M \
--port 8089 -ngl 99 -c 32768 --jinja(出典: Daniel Farina gist・HuggingFace 公式)
llama.cpp の PR #21326(テンプレート修正)と PR #21343(トークナイザー修正)を取り込んだソースビルドで tool calling が動くようになる、
と Daniel Farina が詳細な手順を残している。
Ollama パーサー不具合の完全回避ルート。
ルート B: LM Studio(M4 Mac 向け・有料エージェント UI を残す接続)
# LM Studio CLI
curl -fsSL https://lmstudio.ai/install.sh | bash
# デーモン起動 + モデル取得
lms daemon up
lms get google/gemma-4-26b-a4b
# 有料エージェント(Claude Code 等)の接続先を LM Studio に向ける
export ANTHROPIC_BASE_URL=http://localhost:1234
export API_TIMEOUT_MS=30000000(出典: George Liu ブログ)
普段使っている有料エージェントの UI/UX を残したまま、
推論だけローカルの Gemma 4 に切り替える構成。
LM Studio が Anthropic API 互換のエンドポイントを出すので、
既存エージェント側は環境変数 2 つ書き換えるだけで済む。
「普段の操作感のまま、
課金をローカル推論に逃がす」という乗り換え筋に一番近いルート。
ルート C: Ollama + OpenCode(最もガイドが多い・ただし v0.20.2+ 必須)
# Ollama & モデル
curl -fsSL https://ollama.com/install.sh | sh
ollama pull gemma4:e4b # RAM 8GB+
ollama pull gemma4:26b # RAM 24GB+
# コンテキスト 32K に拡張(デフォルトは 4K)
ollama run gemma4:e4b
# セッション内で
# /set parameter num_ctx 32768
# /save gemma4:e4b-32k
# /bye
# OpenCode
curl -fsSL https://opencode.ai/install | bash
# ~/.config/opencode/opencode.json に
# { "provider": "ollama",
# "baseURL": "http://localhost:11434/v1",
# "model": "gemma4:e4b-32k",
# "tool_call": true, "maxTokens": 16384, "temperature": 0.1 }
opencode(出典: Dev.to・haimaker.ai)
Ollama のデフォルトコンテキストが 4K トークンという罠がある。
ターミナルでコーディング作業を任せるなら num_ctx を 32K 以上に拡張し、/save でカスタムタグを付ける手順は必須。
Ollama はバージョン v0.20.2 以降を選ぶこと。
必要ディスク容量まとめ
| モデル | ファイルサイズ | コンテキスト |
|---|---|---|
| gemma4:e2b | 7.2 GB | 128K |
| gemma4:e4b / latest | 9.6 GB | 128K |
| gemma4:26b | 18 GB | 256K |
| gemma4:31b | 20 GB | 256K |
セキュリティ｜シェル権限を渡すリスクを忘れない
ターミナルからローカル LLM に PC 内作業を任せる構成の盲点がここ。
OpenCode、
Goose、
Open Interpreter はいずれもシェルコマンド実行権限をデフォルトで要求する(出典: Open Interpreter docs)。
ファイル削除・移動・ネットワーク操作を LLM が直接叩ける状態で動く。
ここにプロンプトインジェクション攻撃が刺さると、
信頼できない GitHub リポジトリを開いただけで rm -rf 相当が走るリスクが残る。
最低限の運用ルールはこれくらい。
- 信頼できないコードを含むリポジトリをエージェントに直接触れさせない
- Ollama はデフォルトで localhost のみ公開。外部公開設定を安易にいじらない
- 重要作業は git で中間コミットを残し、エージェントにロールバック余地を残す
- シェル実行系の操作はエージェントの確認プロンプトを必ず通す設定にしておく
ローカルで動く=安全、
ではない。
ここはクラウド有料エージェントで権限スキップを切るのと同じ感覚で扱う必要がある。
結局、ターミナルから Gemma 4 にどこまで任せられるのか
ここまでの引用を束ねると、現実的な線はこう。
- 日常 70% の PC 内作業は Gemma 4 31B ローカルに降ろせる(BenchLM): 単ファイル編集・ボイラープレート生成・シェル自動化・コミットメッセージ・エラーログ解析・単発 tool call
- 残り 30% はクラウド有料エージェントに戻す: 複数ファイル横断リファクタ・深いアーキテクチャ判断・最新ライブラリ対応・長時間 MCP セッション
- 速度はクラウド比 4-6 倍遅い(Daniel Vaughan): ただし first-pass reliability が高ければ総時間はむしろ近い
- コストは API で 1-2 桁安く、ローカルなら通信費ゼロ: 量が出るタスクほどローカルに逃がす経済性が効く
- Ollama v0.20.1 以下は地雷: llama.cpp か LM Studio を選ぶ
私は Gemma 4 を「ターミナル常駐のサブエンジン」として位置付ける立場をとる。
PC 内で発生する日常タスクの 7 割を Gemma に任せ、
残り 3 割の重い依存タスクだけクラウドの有料エージェントに投げる併走設計。
Claude Code 相当の月 200 ドル課金をまるごと 0 円にする話ではなく、
量が出る 70% をローカルに逃がすことで、
実質的な作業コストと依存度の両方を下げる話だ。
ひとつ意識しておきたいのが、
HN neonstatic の「知識カットオフ 2025-01 以降をファンタジー扱いする」という指摘。
Next.js 15 や React Compiler 以降のエコシステムを扱うエンジニアにはかなり刺さる制約。
ここを知った上で、
ローカルに降ろすタスクを選別する覚悟は要る。
「τ2-bench 86.4%」の見出しだけで飛びつくと、
SWE-bench 52% の壁で二度痛い。
逆に 70% のタスクを狙って使い分ければ、
Gemma 4 はターミナル常駐の相棒としてかなり働く。
この温度感。
FAQ
Q. Gemma 4 にターミナルから PC 内のファイル操作を全部任せられますか
日常の 70% 相当は任せられます。
BenchLM の評価によれば単ファイル編集・ボイラープレート生成・シェル自動化・単発ツール呼び出しは許容品質を満たす一方、
複数ファイル横断リファクタリングや深いアーキテクチャ判断はクラウドの有料エージェント(Claude Sonnet 4.6 / GPT-5 クラス)に戻す必要がある、
とされています(出典: BenchLM)。
完全代替ではなく「PC 内作業の日常 70% を逃がす受け皿」が現実的なポジションです。
Q. Ollama で Gemma 4 を動かすと tool calling が壊れるという話は本当ですか
Ollama v0.20.0 と v0.20.1 では tool calling パーサーのクラッシュ・ストリーミング時のデータ誤入力・トークナイザーバグが確認されており、
Paweł Huryn は「ファイル取得もツール呼び出しもできない」と報告しています(出典: X)。
v0.20.2 で GitHub Issue #15241 が対応され、
パーサーは修正済み。
安定重視なら llama.cpp か LM Studio ルートが無難です。
Q. τ2-bench 86.4% と SWE-bench Verified 52.0% の差はなぜですか
τ2-bench は単発のツール呼び出しを評価する一方、
SWE-bench Verified は実 OSS リポジトリの issue を修正する実務課題を評価します。
ベンチごとに測っている負荷が違うため、
数字が乖離します。
実務的なマルチファイル改修では同じオープンウェイトの Qwen 3.6-35B-A3B(SWE-bench 73.4%)のほうが優位です(出典: LushBinary)。
Q. どのハードウェアなら実用速度が出ますか
公開実測では M4 Pro 48GB が LM Studio 経由で 51 tok/s(26B MoE Q4)、
AMD RX 7900 XTX が 100 tok/s、
Apple Silicon Mac の Codex CLI 実行で 10 回ツール呼び出しタスクが 4 分 42 秒で完了しています(出典: George Liu・Medium)。
M4 Pro 以上 or RTX 4090 クラスが実用ラインの目安です。
Q. Gemini CLI で Gemma 4 をエージェントとして使えますか
使えません。
Gemini CLI チームは「Gemma ローカルモデルをエージェント本体として使う機能は今のところ予定していない」と GitHub Discussions で明言しています(出典: GitHub)。
代替としてコミュニティフォークの llxprt-code が紹介されています。
Q. 月 200 ドル相当のクラウド有料エージェント課金をゼロにできますか
完全ゼロは現実的ではありません。
Gemma 4 で日常 70% の PC 内作業を逃がすと通信費はゼロになりますが、
残り 30% の「複数ファイルリファクタ」「最新ライブラリ対応」「長時間 MCP セッション」は依然クラウドの有料エージェントが必要、
と BenchLM は整理しています。
併走設計で月額を半分以下に圧縮するのが現実解です。
Q. 初めて触るならどの実行エンジンを選ぶべきですか
tool calling を使いたいなら llama.cpp + OpenCode ルート、
普段の有料エージェント UI をそのまま残したいなら LM Studio + 環境変数切替ルート、
Ollama を使うなら必ず v0.20.2 以降を選んでください。
Daniel Farina の gist が llama.cpp ルートの具体的コマンドを残しており、
公式 Day-0 サポート対象は HuggingFace によれば Pi / Hermes / OpenClaw / Open Code とされています(出典: HuggingFace)。
参考リンク
- Google 公式リリースブログ: https://blog.google/innovation-and-ai/technology/developers-tools/gemma-4/
- Google DeepMind 公式モデルページ: https://deepmind.google/models/gemma/gemma-4/
- 公式モデルカード: https://ai.google.dev/gemma/docs/core/model_card_4
- HuggingFace 公式ブログ(Gemma 4): https://huggingface.co/blog/gemma4
- Android Developers Blog(τ2-bench): https://android-developers.googleblog.com/2026/04/gemma-4-new-standard-for-local-agentic-intelligence.html
- Ollama 公式ライブラリ: https://ollama.com/library/gemma4
- Ollama tool calling Issue: https://github.com/ollama/ollama/issues/15402
- llama.cpp workaround gist(Daniel Farina): https://gist.github.com/daniel-farina/87dc1c394b94e45bb700d27e9ea03193
- Paweł Huryn(X): https://x.com/PawelHuryn/status/2040498812318273583
- BenchLM(Claude Sonnet 4.6 vs Gemma 4): https://benchlm.ai/compare/claude-sonnet-4-6-vs-gemma-4-e2b
- LushBinary(Qwen vs Gemma 4 比較): https://lushbinary.com/blog/qwen-3-6-vs-gemma-4-llama-4-glm-5-1-deepseek-v4-open-source-comparison/
- Codex CLI + Gemma 4 実測(Daniel Vaughan): https://medium.com/google-cloud/i-ran-gemma-4-as-a-local-model-in-codex-cli-7fda754dc0d4
- LM Studio 経由のローカル接続実践: https://ai.georgeliu.com/p/running-google-gemma-4-locally-with
- OpenCode + Gemma 4 セットアップ(Dev.to): https://dev.to/grovertek/running-gemma-4-locally-with-ollama-and-opencode-2h6
- XDA Developers レビュー: https://www.xda-developers.com/gemma-4-not-smartest-local-llm-but-reach-for/
- Hacker News スレッド: https://news.ycombinator.com/item?id=47744255
- Gemini CLI ローカル対応議論: https://github.com/google-gemini/gemini-cli/discussions/5945
- VRAM 要件詳細(Oflight): https://www.oflight.co.jp/en/columns/gemma4-hardware-requirements-local-ai-spec-2026
- Goose(Block 社)レビュー: https://effloow.com/articles/goose-open-source-ai-agent-review-2026
※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。