Gemma 4はターミナルから起動して、PC内のファイル操作・コード編集・コマンド実行を肩代わりさせる用途で動くオープンモデル。
組み合わせは「モデル」「実行エンジン(Ollama / llama.cpp / LM Studio)」「自動化フロント(Goose / OpenCode / Claude Code接続)」の3層になる。
τ2-bench 76.9%(31B Dense、Gemma 3 27B比約4.8倍)は派手だが、詰まる3箇所がある。
Ollama v0.20系のツール呼び出し不具合、複数ファイル横断改修の弱さ、知識カットオフ2025-01以降の新ライブラリ。
M4 Pro 24GB / RTX 4090級のハードなら50 tok/s超で実用速度。
クラウドの月200ドル課金作業のうち約7割はGemma 4ローカルに逃がせる、というのが2026-04時点の落としどころ。
この記事はClaude Code等のクラウド有料AIを月100-200ドル使っていて、ローカルAIに作業を逃がしたい開発者向け(ターミナル操作の基本が分かる前提)。
Gemma 4が2026-04-02に公開された(出典: Google Blog)。
Apache 2.0ライセンスで商用利用・自己ホスト自由、E2B/E4B/26B MoE/31B Denseの4種、コンテキスト最大256K。
ターミナルから直接叩ける「PC内作業の自動化エンジン」として、本気で検討する選択肢になりました。
ただ、ここで立ち止まります。
ネットの「完全代替」「月0円で最強エンジニア」系の見出しは話半分。
公式の τ2-bench 76.9% は強い数字ですが、Ollama公式GitHubにはGemma 4のツール呼び出し関連のIssueが立っていて、v0.20系の環境でchat以外の挙動が安定しなかった事実が記録されています(出典: Ollama GitHub Issue #15402)。
ベンチの数字と、PC内作業を任せたときの実挙動はズレている。
この記事では、Gemma 4にターミナル経由でどこまでPC内作業(ファイル操作・コード編集・コマンド実行)を任せられるかを、実行エンジン×自動化フロント×タスク種別の3軸で整理します。
動く組み合わせと動かない組み合わせを、公式GitHubと公式ドキュメントから引きます。
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に自動化AIを常駐させる」下限が一段下がった形。
私はこの軽量化が今回の最大の意味だと思っています。
公式のτ2-bench 76.9%は何を測っているのか
Gemma 4の目玉数字はτ2-benchの76.9%(31B Dense)。
Gemma 3 27Bの16.2%から約4.8倍の改善(出典: Google公式モデルカード)。
ここまで跳ねた例はオープンウェイトでは珍しい。
τ2-benchは自動化AI的なツール呼び出しを測るベンチマークで、Google DeepMindによればGemma 4は「6つの専用スペシャルトークン」でツール呼び出しのライフサイクルを管理する設計になっています(出典: Google公式モデルカード)。
文章テンプレ任せではなく、モデル側が構造的にサポートする形。
ターミナルからコマンドを叩かせる用途には直接効く設計です。
主要ベンチの横並び
| ベンチマーク | 31B Dense | 26B MoE | E4B | 測るもの |
|---|---|---|---|---|
| τ2-bench | 76.9% | — | — | ツール呼び出しの自動化 |
| 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スコア80.0%(出典: Google公式モデルカード)。
AIME 2026の89.2%・MMLU Proの85.2%と合わせて、オープンウェイト勢の中では一段抜けたラインに到達した数字です。
ただし、この数字は一歩引いて見ないと危ない。
私の判断は、ベンチ80%は「ツール呼び出し1発が9割通る」程度の意味。
単発ベンチが強くても複数ファイル改修は別物｜Qwen 3.6比較で見える壁
LiveCodeBenchとτ2-benchが華やかな一方で、「複数ファイル横断の実プロジェクト改修」では別の壁にぶつかります。
LiveCodeBenchが単発の競技プログラミング問題を解かせるのに対し、実OSSの不具合を直す系のベンチは難易度が一段違う。
比較対象として同じオープンウェイトのQwen 3.6-35B-A3BはSWE-bench Verifiedで73.4%(出典: Qwen公式ブログ)。
Gemma 4はGoogle公式モデルカードにSWE-bench Verifiedの掲載がなく、公式数字での突き合わせは現時点で出来ません。
ただ、公開後の現場報告と次節で触れる4つの躓きパターンを見る限り、複数ファイル横断系では明確に弱点が見えてきます。
τ2-benchが強いタスクと、別軸で測られるタスク
| ベンチ | Gemma 4 31B | Qwen 3.6-35B | 測っている負荷 |
|---|---|---|---|
| τ2-bench | 76.9% | データなし | 単発ツール呼び出し・会話型自動化 |
| LiveCodeBench v6 | 80.0% | データなし | 単発の競技プログラミング問題 |
| SWE-bench Verified | 未掲載(公式モデルカード) | 73.4% | 実OSSプロジェクトの不具合修正 |
つまり「ターミナルで1コマンド叩かせる」「1ファイルを書かせる」は得意だが、「複数ファイルの依存関係を保ったまま修正する」は別軸の負荷がかかる、という差分。
公式モデルカードの数字を素直に並べると、Gemma 4の強みは単発タスク側に振れているのが見えます。
複数ファイル改修の手戻りは、月単位で見れば月10時間分の作業遅延に化けます。
私の見方では、日常作業のうち約7割はGemma 4で十分回せて、残り3割の作りの深い判断と複数ファイル改修だけクラウドの上位課金モデルに戻す、というのが2026-04時点の現実的な線。
月200ドル課金を全部消すのは無理、でも7割は逃がせる。
実行エンジン別｜ツール呼び出しが動くかのマトリクス
ここから本題。
Gemma 4にターミナル経由でPC内作業を任せるには、モデル単体では動きません。
実行エンジン層(Ollama / llama.cpp / LM Studio / MLX)と、その上の自動化フロント層(OpenCode / Goose / Claude Code接続 / aider / Open Interpreter)の両方が噛み合って初めて、ファイル操作やコマンド実行に届く。
2026-04時点で一番不安定なのはOllama。
Ollama公式GitHubのIssue #15402にGemma 4のツール呼び出し関連の挙動が報告されています(出典: Ollama GitHub Issue #15402)。
chat応答は通っても、Claude Code等から繋いだ際にツール呼び出しが安定せず、PC内作業を任せようとした人がハマるパターンが記録に残っている形。
「ファイルが取れない、ツールが呼べない」。
ターミナルからPC内作業を任せたい人にとって、これは致命傷の種類のトラブルです。
chatだけ動いても意味がない。
llama.cpp側はもっと早く対応が入りました。
公式リポジトリのPR #21326(テンプレート修正)とPR #21343(トークナイザー修正)で、Gemma 4のツール呼び出しは公開直後から動く状態になっています(出典: llama.cpp PR #21326)。
ソースから入れて--jinjaを付ければOK、という記述が公式に残っている。
HuggingFace公式ブログでも、Day-0サポート対象としてllama.cppとLM Studioが明示されていて、Ollamaは含まれていません(出典: HuggingFace公式)。
エコシステム側からも「Ollamaは様子見」のシグナルが出ていた、と読み取れる事実です。
実行エンジン×ツール呼び出し動作マトリクス(2026-04時点)
| 実行エンジン | chat | ツール呼び出し | 備考 |
|---|---|---|---|
| Ollama v0.20系 | 動く | 不安定 | Issue #15402でツール呼び出し関連の問題報告あり |
| 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対応 | ツール呼び出し実態 | 備考 |
|---|---|---|---|
| OpenCode | 対応(情報多い) | GitHub Issueあり(回避策有) | llama.cppルートなら安定 |
| Goose(Block社) | 対応 | 動く | 外部ツール接続3000+対応・GitHub Stars 30,000+ |
| aider | Ollama経由で接続可 | Ollamaバージョン依存 | 公式ドキュメントはGemma 3まで記載 |
| Open Interpreter | Ollama経由で接続可 | バージョン依存 | 公式local_setup.pyはgemma2参照 |
| Claude Code(LM Studio経由) | 対応 | 動く | 有料アプリのUIをそのまま残す比較参照ルート |
| Gemini CLI | 非対応(公式明言) | 動かない | フォークのllxprt-codeが代替 |
注意したいのがGemini CLI。
公式のGitHub Discussionsで「Gemmaローカルモデルを自動化AI本体として使う機能は今のところ予定していない」と回答されています(出典: 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の初期プロジェクトに採択されている公益性の高い位置で、Anthropic・OpenAIの2社が支援に入っています(出典: Goose公式GitHub)。
外部ツール接続3000+に対応し、ファイル操作・コマンド実行・ブラウザ操作まで広い。
運営体制・採用実績・接続範囲、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コンテキストで使う場合。
HuggingFace公式ブログによるとキャッシュ部分だけで約22GB必要で、RTX 4090の24GB単体だと詰む。
256Kを本気で使うならM4 Pro 48GBかRTX 5090クラスの選択肢になります(出典: HuggingFace公式)。
推論速度(公式・公式ライブラリ掲載の実測値抜粋)
| 環境 | モデル | 速度 | ベンチタスク |
|---|---|---|---|
| M4 Pro 48GB(LM Studio) | 26B MoE Q4 | 51 tok/s | — |
| Apple Silicon Mac(自動化アプリ経由) | 26B MoE Q4 | 52 tok/s | 10回ツール呼び出し 4分42秒 |
| NVIDIA GB10(Blackwell) | 31B Dense | 10 tok/s | 3回ツール呼び出し 6分59秒 |
| CPU推論のみ | E4B | 2-5 tok/s | 実用に耐えない |
| CPU推論のみ | 26B | 0.5-2 tok/s | 実用に耐えない |
| (参考)クラウド最上位 | — | — | 同タスク65秒で完了 |
目を引くのは、Apple Silicon Macで10回ツール呼び出しタスクを4分42秒、NVIDIA GB10(31B Dense)で3回ツール呼び出しを6分59秒で完了、同じタスクをクラウド最上位は65秒で済ます、という比較。
タスク完了時間で4-6倍遅くても、一発目で正しい結果を返すかが、生成速度より効くという整理になります。
つまり、生成自体は4-6倍遅くても、やり直しが少ないほうが総時間は短くなる。
私の見方では、ここの論点が一番納得感が強い。
月200ドルの課金を月60ドル相当(クラウドは3割使用)に圧縮しつつ、待ち時間も思ったほど増えない、という計算になる。
逆に、CPU推論だけで突っ込む選択肢は捨てていい。
E4Bで2-5 tok/s、26Bで0.5-2 tok/sでは、ターミナルでコマンド自動化どころか、待ち時間で心が折れます。
M4 Pro 48GBは実売40万円前後。月200ドルの課金1.7年分です。
どのタスクをローカルで任せられるか｜単ファイル・複数ファイル・コマンド自動化で分ける
ここがこの記事の芯になる論点。
「PC内作業」と一括りにせず、単ファイル編集・複数ファイル改修・コマンド自動化・外部ツール接続に分けて、ローカルに降ろせる境界を引きます。
比較参照として、相場感を出すために有料クラウド自動化AI(Claude Codeの月200ドル課金モデル相当)の線も併記。
| タスク種別 | Gemma 4 31Bローカル | 根拠 |
|---|---|---|
| 単ファイル編集・テンプレ生成 | 任せられる | τ2-bench 76.9%・単発ツール呼び出しが強い |
| ターミナル直叩きのコマンド自動化(ls/find/grep/sed) | 任せられる | τ2-bench 76.9%・単発ツール呼び出しが強い |
| コード補完・コメント生成 | 任せられる | 公式「code completion and correction」 |
| 単発の競技プログラミング | 任せられる | LiveCodeBench 80.0% = クラウド最上位と同等 |
| 数学・論理推論 | 任せられる | AIME 2026 = 89.2% |
| 単発ツール呼び出し(検索・計算・ファイル読み書き) | 環境次第で任せられる | Ollama v0.20系は不安定・llama.cpp / LM Studioは安定 |
| 複数ファイル横断の書き直し | 厳しい | 公式は同ベンチ未掲載・Qwen 3.6が73.4%でリード |
| 深いアーキ判断 | 厳しい | 複数ファイル整合性で躓くパターンが報告されている |
| 外部ツール接続の複雑連携(長時間セッション) | 不安定 | OpenCode GitHub Issue #20995で報告 |
| 2025-01以降の最新ライブラリ | 任せられない | 知識カットオフが2025-01・幻覚リスク |
| 200K超の超長文コンテキスト | ハード依存 | 31B 256Kでキャッシュ22GB必要 |
境界の引き方はシンプル。
単発でぶつ切りになる作業はローカル、長い依存チェーンが絡む作業はクラウド。
ターミナルでファイルをgrepしてsedで書き換える、READMEを更新する、単体ファイルの補完、コミットメッセージ生成、エラーログから原因の一次解析——この系統は全部Gemma 4に降ろせる。
逆にNext.js 15の構造全体を一括で書き直す、依存するテストを壊さずに10ファイル横断で型を変える、外部ツール経由でSlack / GitHub / ブラウザをまたいで1時間セッションを回す——この系統はクラウドの有料自動化AI(Claude Code月200ドル級)に戻す。
コストの差もあります。
Gemma 4 31BはAPI経由で$0.14/M tokens(入力)。
Google公式モデルカードに価格表記がある一方、クラウドの上位モデルは1-2桁高い水準が一般的(出典: Google公式モデルカード)。
ローカルなら通信費ゼロ。
量が出るタスクほどGemmaに逃がす経済性が効きます。
私なら、月200ドル課金のうち月140ドル相当(7割)はローカルに逃がす設計を試します。
残り60ドル相当だけクラウドに残す。
年間で1700ドル(約25万円)の差が出る計算で、ハード代の元はM4 Proなら1-2年で取れる。
動くのに動かない｜公式GitHubに報告された4つの躓きポイント
Ollama・OpenCode・llama.cppのGitHub Issuesを横断すると、同じトラブルが繰り返し出てきます。
共通項は単純で、Gemma 4は「文脈が長く依存が絡む仕事」で挙動がブレるという1点に収束する。
具体的には4類型。
- 外部ツール接続を拒否する: 知識カットオフが2025-01なので、それ以降のフレームワーク変更を想像扱いする(出典: Ollama Issue #15402)
- ツール使用でループに陥る: 同じツール呼び出しを繰り返して終わらない(出典: OpenCode Issue #20995)
- コンテキスト制限で自動化処理が低下: 大入出力タスクで性能が大きく下がる
- 複雑なプロジェクトで半端な実装を出力: 途中で諦める・TODOコメントで埋める挙動
裏を返せば4つの躓きは全て「長い依存チェーン」「外部ツールの複雑連携」「2025-01以降の最新仕様」という3本柱に紐付く。
複数ファイルの依存を保つ力、最新エコシステムへの追従、長時間セッションで一貫性を保つ力。
この3つがGemma 4の構造的な弱点で、ベンチ数字の偏り(単発タスク強い・複数ファイル測定なし)と現場報告が同じ結論に収斂する形で現れています。
一方でOpenCodeのIssueトラッカーには賛成寄りの声も具体的に並んでいます。
「初めてOpenCodeをローカルサーバーで確実に使えるようになった。
Godotエンジン学習に効果的」「M5 Pro 48GBでM4 Proから8倍高速化を実現」「視覚入力(画像認識)能力が同等級の他モデルより優秀」といった報告も同じトラッカーに記録されています(出典: OpenCode Issue #20995)。
両側の声を並べると、Gemma 4の使いどころは「単発でぶつ切りになるタスク」「視覚入力を含む処理」「明確に境界が切れる問題」にハマる、という傾向が浮かびます。
逆に「長い依存チェーン」「外部ツールの複雑連携」「知識カットオフ以降の最新仕様」は苦手、と覚えておく。
最短セットアップ｜Ollama地獄を避ける3ルート
Ollamaのツール呼び出し問題を踏まえて、2026-04時点で相対的に安定している3ルートを並べます。
手順は公式ドキュメント・公式リポジトリの内容をそのまま引いたもの。
ルートA: llama.cpp + OpenCode(ツール呼び出し安定重視)
ステップ1: llama.cppを入れる。
Macならbrew install llama.cpp。
期待結果: llama-server --versionでバージョン表示。
詰まりどころ: HomebrewなしのLinuxはソースからビルドする必要があり、PR #21326/#21343を取り込んだバージョンを選ぶこと。
ステップ2: モデルを取得して起動する。
下のコマンドを叩く。
期待結果: 8089ポートでサーバーが立ち上がる。
詰まりどころ: --jinjaを忘れるとツール呼び出しのテンプレが効かず、文章しか返ってこない。
# macOS
brew install llama.cpp
# 26B Q4_K_Mで起動(--jinjaフラグ必須)
# モデルタグは公式配布の `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(出典: llama.cpp PR #21326・HuggingFace公式)
ステップ3: OpenCodeを接続する。~/.config/opencode/opencode.jsonにbaseURL: http://localhost:8089/v1を書く。
期待結果: opencodeを叩くと対話プロンプトが立ち上がり、ファイル読み書きが効く。
詰まりどころ: モデル名が間違っているとchat応答だけ返ってツール呼び出しが沈黙する。
ルートB: LM Studio(M4 Mac向け・有料アプリのUIを残す接続)
ステップ1: LM Studio CLIを入れる。curl -fsSL https://lmstudio.ai/install.sh | bashを叩く。
期待結果: lmsコマンドが使える。
詰まりどころ: M1 Macより前のIntel Macは公式サポート外。
ステップ2: モデルを取得してサーバーを起動する。lms daemon upとlms get google/gemma-4-26b-a4b。
期待結果: 1234ポートでAnthropic API互換のサーバーが起動する。
詰まりどころ: 初回ダウンロードが18GBあり、回線次第で30分〜1時間かかる。
# 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(出典: LM Studio公式ドキュメント)
ステップ3: Claude Codeに環境変数を渡す。export ANTHROPIC_BASE_URL=http://localhost:1234を~/.zshrcに書く。
期待結果: いつものClaude Codeを叩くと、裏側でGemma 4が答える。
詰まりどころ: 環境変数の有効化を忘れて、クラウドのClaudeに当たり続ける(明細を見て気づく)パターン。
ルートC: Ollama + OpenCode(ガイドが多い・最新版必須)
ステップ1: Ollama本体とモデルを入れる。curl -fsSL https://ollama.com/install.sh | shとollama pull gemma4:e4b。
期待結果: ollama listでe4bが見える。
詰まりどころ: 古いバージョンのOllamaを入れるとツール呼び出しが安定しない。ollama --versionで最新版に上げてから使う。
ステップ2: コンテキストを32Kに広げる。
デフォルトは4Kしかなく、ターミナル作業には足りない。ollama run gemma4:e4bでセッションに入り、/set parameter num_ctx 32768と/save gemma4:e4b-32k。
期待結果: 32K対応のタグが保存される。
詰まりどころ: この設定を忘れるとファイル数本でコンテキスト超過、AIが直前の指示を忘れる。
# 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ステップ3: OpenCodeを入れて接続する。curl -fsSL https://opencode.ai/install | bash、設定ファイルにtool_call: trueを書く。
期待結果: opencodeを叩くとファイル操作のプロンプトが立ち上がる。
詰まりどころ: tool_callを書き忘れるとchatオンリーで終わる。
(出典: Ollama公式ライブラリ・OpenCode公式)
必要ディスク容量まとめ
| モデル | ファイルサイズ | コンテキスト |
|---|---|---|
| gemma4:e2b | 7.2 GB | 128K |
| gemma4:e4b / latest | 9.6 GB | 128K |
| gemma4:26b | 18 GB | 256K |
| gemma4:31b | 20 GB | 256K |
セキュリティ｜コマンド権限を渡すリスクを忘れない
ターミナルからローカルAIにPC内作業を任せる構成の盲点がここ。
OpenCode・Goose・Open Interpreterはいずれもコマンド実行権限をデフォルトで要求します(出典: Open Interpreter公式ドキュメント)。
ファイル削除・移動・ネットワーク操作をAIが直接叩ける状態で動く。
ここに悪意ある指示が混じった文書を読ませると、信頼できないプロジェクトを開いただけでrm -rf相当が走るリスクが残る。
最低限の運用ルールはこれくらい。
- 信頼できないコードを含むプロジェクトをAIに直接触れさせない
- Ollamaはデフォルトでlocalhostのみ公開。外部公開設定を安易にいじらない
- 重要作業は10分ごとに途中保存(commit)を残し、AIにロールバック余地を残す
- コマンド実行系の操作はAIの確認プロンプトを必ず通す設定にしておく
ローカルで動く=安全、ではない。
ここはクラウドの有料自動化AIで権限スキップを切るのと同じ感覚で扱う必要があります。
私は、最初の1ヶ月は確認プロンプトを全部オンにして運用感を掴むのを推します。
結局、ターミナルからGemma 4にどこまで任せられるのか
ここまでの公式情報を束ねると、現実的な線はこう。
- 日常7割のPC内作業はGemma 4 31Bローカルに降ろせる: 単ファイル編集・テンプレ生成・コマンド自動化・コミットメッセージ・エラーログ解析・単発ツール呼び出し
- 残り3割はクラウドの有料自動化AIに戻す: 複数ファイル横断の書き直し・深いアーキ判断・最新ライブラリ対応・長時間セッション
- 速度はクラウド比4-6倍遅い: ただし一発目で正しく返せば総時間はむしろ近い
- コストはAPIで1-2桁安く、ローカルなら通信費ゼロ: 量が出るタスクほどローカルに逃がす経済性が効く
- Ollama v0.20系は地雷気味: llama.cppかLM Studioを選ぶ
私はGemma 4を「ターミナル常駐のサブエンジン」として位置付けます。
PC内で発生する日常タスクの7割をGemma 4に任せ、残り3割の重い依存タスクだけクラウドの有料自動化AIに投げる併走設計。
Claude Code相当の月200ドル課金をまるごと0円にする話ではなく、量が出る7割をローカルに逃がすことで、実質的な作業コストと依存度の両方を下げる話です。
ひとつ意識しておきたいのが、知識カットオフ2025-01以降をモデルが想像で埋める制約。
Next.js 15やReact Compiler以降のエコシステムを扱うエンジニアには刺さります。
ここを知った上で、ローカルに降ろすタスクを選別する覚悟は要る。
「τ2-bench 76.9%」の見出しだけで飛びつくと、複数ファイル改修の壁で二度痛い。
逆に7割のタスクを狙って使い分ければ、Gemma 4はターミナル常駐の相棒としてかなり働く。
私なら年25万円のコスト差を取りに行く。
この温度感です。
FAQ
Q. Gemma 4にターミナルからPC内のファイル操作を全部任せられますか
日常の7割相当は任せられます。
Google公式モデルカードに記載されたτ2-bench 76.9%・LiveCodeBench 80.0%が示すとおり、単ファイル編集・テンプレ生成・コマンド自動化・単発ツール呼び出しは許容品質を満たす一方、複数ファイル横断の書き直しや深いアーキ判断はクラウドの有料自動化AI(GPT-5クラスやClaude Codeの月200ドルプラン)に戻す必要があります(出典: Google公式モデルカード)。
完全代替ではなく「PC内作業の日常7割を逃がす受け皿」が現実的なポジションです。
Q. OllamaでGemma 4を動かすとツール呼び出しが壊れるという話は本当ですか
Ollama公式GitHubのIssue #15402にGemma 4のツール呼び出し関連の挙動が報告されています(出典: Ollama GitHub)。
安定重視ならllama.cppかLM Studioルートが無難です。
Q. τ2-bench 76.9%は何を測っていて、複数ファイル改修にはどう効きますか
τ2-benchは単発のツール呼び出しを評価する一方、複数ファイル横断の改修はSWE-bench Verified等の別系統で測られます。
Gemma 4は公式モデルカードにSWE-bench Verifiedの掲載がなく、同系統のオープンウェイトのQwen 3.6-35B-A3Bは73.4%(出典: Qwen公式)。
実務的な複数ファイル改修ではQwen系列のほうが優位というのが2026-04時点の公開情報の見立てです。
Q. どのハードウェアなら実用速度が出ますか
公式・公式ライブラリ掲載の実測ではM4 Pro 48GBがLM Studio経由で51 tok/s(26B MoE Q4)、Apple Silicon Macの自動化アプリ実行で10回ツール呼び出しタスクが4分42秒で完了しています(出典: HuggingFace公式・LM Studio公式)。
M4 Pro以上 or RTX 4090クラスが実用ラインの目安です。
Q. Gemini CLIでGemma 4を自動化AIとして使えますか
使えません。
Gemini CLIチームは「Gemmaローカルモデルを自動化AI本体として使う機能は今のところ予定していない」とGitHub Discussionsで明言しています(出典: GitHub)。
代替としてコミュニティ派生版のllxprt-codeが紹介されています。
Q. 月200ドル相当のクラウド有料自動化AI課金をゼロにできますか
完全ゼロは現実的ではありません。
Gemma 4で日常7割のPC内作業を逃がすと通信費はゼロになりますが、残り3割の「複数ファイル書き直し」「最新ライブラリ対応」「長時間セッション」は依然クラウドの有料自動化AIが必要です。
年間で約25万円のコスト差(月200ドル→月60ドル相当)を取りに行く併走設計が現実解です。
Q. 初めて触るならどの実行エンジンを選ぶべきですか
ツール呼び出しを使いたいならllama.cpp + OpenCodeルート、普段の有料アプリのUIをそのまま残したいならLM Studio + 環境変数切替ルート、Ollamaを使うなら最新版に上げてから入ってください。
HuggingFace公式によれば、Day-0サポート対象としてllama.cppとLM Studioが明示されています(出典: HuggingFace)。
このページに出てきた言葉
- オープンウェイト
- モデルの中身を公開して、手元のPCで動かせる形式のAI
- MoE
- 中身を専門家ネットワークに分割して、必要箇所だけ動かす仕組み。動作が軽くなる
- コンテキスト
- AIが一度に読める文字数の上限
- VRAM
- グラフィックボードの専用メモリ。AIモデルはここに載せて動かす
- τ2-bench
- AIに単発のツール呼び出しを解かせる試験
- SWE-bench Verified
- 実OSSプロジェクトの不具合修正を解かせる試験。複数ファイル整合性が要求される
- 実行エンジン
- AIモデルを動かすソフト本体(Ollama / llama.cpp / LM Studio / MLX)
- 自動化フロント
- 実行エンジンの上に乗ってファイル操作・コマンド実行を担うアプリ(OpenCode / Goose / Claude Code)
- ツール呼び出し
- AIが返答中に「ファイル開く」「コマンド実行」など外部の動作を指示する仕組み
- 外部ツール接続
- AIから外部サービス(GitHub・Slack・ブラウザ)を呼び出すための共通仕組みと道具一式
- 量子化
- モデル内部の数値を間引いて、ファイルサイズと必要メモリを削る処理
- tok/s
- トークン毎秒。1秒間にAIが生成する文字数の目安
- 知識カットオフ
- モデルが学習データを取り込んだ最終時点。Gemma 4は2025-01
- パーサー
- AI出力を解析してコマンド指示を取り出す部品
- 幻覚
- AIがもっともらしいが事実無根の出力を返す現象
参考リンク
- 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
- Ollama公式ライブラリ: https://ollama.com/library/gemma4
- Ollamaツール呼び出しIssue #15402: https://github.com/ollama/ollama/issues/15402
- llama.cpp Gemma 4対応PR #21326: https://github.com/ggml-org/llama.cpp/pull/21326
- OpenCode Gemma 4 Issue #20995: https://github.com/sst/opencode/issues/20995
- Goose公式GitHub: https://github.com/block/goose
- LM Studio公式ドキュメント: https://lmstudio.ai/docs
- LM Studio公式モデルページ: https://lmstudio.ai/models/google/gemma-4
- OpenCode公式: https://opencode.ai/docs
- Open Interpreter公式ドキュメント: https://docs.openinterpreter.com/guides/running-locally
- Qwen公式ブログ: https://qwenlm.github.io/blog/qwen3-coder/
- Gemini CLIローカル対応議論: https://github.com/google-gemini/gemini-cli/discussions/5945
※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。