Gemma 4 を Antigravity で動かす — Ollama 接続の設定とローカル/クラウドの使い分け

「Gemma 4 を Antigravity で使えるのか？」という質問が増えています。結論から言うと使えます。しかも、クラウド API のコストを気にせずローカルで動かせるという点で、開発用途には非常に相性がよいです。

私自身、個人開発のスクリプト整備やコンテンツ運営の補助で「クラウドに送りたくない処理だけローカルに逃がす」使い分けを続けてきて、この構成が手元に定着しています。接続そのものは10分ほどで終わります。つまずきやすいのはむしろ接続後です。応答が妙に遅い、しばらく放置すると最初の一問だけ待たされる、エージェントに任せると空振りする——このあたりの対処も含めて、手順と運用の実感をまとめます。

Gemma 4 とは

Gemma 4 は Google が提供するオープンウェイトモデルです。Gemini シリーズの蒸留技術を活かして作られており、軽量ながら高い推論能力を持っています。

商用利用が可能なライセンスで公開されており、ローカルで動かせるという点が最大の特長です。API コストがかからないため、開発中の試行錯誤や、データをクラウドに送りたくないユースケースに向いています。

クラウドの Gemini とは役割が違う、と捉えると使いどころが見えてきます。最新情報や長い推論はクラウドに任せ、手元のコードやログのように「外に出したくない・何度も試したい」処理をローカルに寄せる。私はこの切り分けを、コンテンツ運営の下ごしらえスクリプトを直すときに続けていて、手放せなくなっています。

Antigravity で Gemma 4 を使うための前提条件

Antigravity IDE は Gemini モデルとの統合が標準機能として提供されていますが、ローカルモデル（Gemma 4 など）との連携は設定が必要です。

必要なもの：

• Antigravity IDE（最新版）
• Ollama（ローカル LLM を動かすためのランタイム）
• 十分な RAM（Gemma 4 の 4B パラメータモデルで 8GB 以上、12B 以上のモデルは 16GB 推奨）

Step 1: Ollama のインストールと Gemma 4 のダウンロード

# Ollama のインストール（macOS / Linux）
curl -fsSL https://ollama.ai/install.sh | sh
 
# Windows の場合は https://ollama.ai からインストーラーをダウンロード
 
# Gemma 4 の 4B パラメータ版をダウンロード
ollama pull gemma4:4b
 
# 12B パラメータ版（より高性能、要: 16GB RAM）
ollama pull gemma4:12b
 
# ダウンロード確認
ollama list
# EXPECTED OUTPUT:
# NAME           ID              SIZE    MODIFIED
# gemma4:4b      ...             3.3 GB  ...

どのモデルサイズを選ぶか — メモリ別の目安

ollama pull の前に、自分のマシンでどのサイズが現実的かを決めておくと迷いません。

• 8GB RAM: gemma4:4b 一択です。それでもブラウザを多く開いていると遅くなるので、補完よりチャット用途向き
• 16GB RAM: gemma4:4b が快適圏、gemma4:12b は動くものの他のアプリと併用すると厳しい場面があります
• 32GB RAM 以上: gemma4:12b が常用でき、応答品質と速度のバランスが良い構成です
• 64GB 以上 (Apple Silicon): gemma4:27b の量子化版まで視野に入ります

迷ったらまず 4b で接続確認まで通し、品質に不満が出たら上のサイズに切り替える順番が安全です。モデルの切り替えは config.json の model を書き換えて再起動するだけなので、後からいくらでも変えられます。

量子化タグを指定してメモリを節約する

ollama pull gemma4:12b のように無印のタグで取得すると、Ollama は既定の量子化（多くの場合 Q4_K_M 相当）でモデルを落としてきます。メモリがぎりぎりのマシンでは、この既定より一段軽い量子化を明示的に選ぶことで、同じパラメータ数でも起動できることがあります。

# 量子化タグを明示して取得する
ollama pull gemma4:12b-q4_K_M   # 品質と容量のバランス型（既定に近い）
ollama pull gemma4:12b-q3_K_M   # さらに軽い。品質は少し落ちるが 16GB でも動きやすい

私の感覚では、コード補助のように「短い応答を数多く」という使い方であれば、Q4 と Q3 の品質差はそれほど気になりません。一方で、長い説明やリファクタの提案になると Q4 以上の方が破綻が少なく感じます。まず既定（無印）で試し、メモリが厳しいときだけ一段下げる、という順番で十分だと考えています。

Step 2: Antigravity での接続設定

Antigravity IDE を開き、設定画面からモデルの接続先を変更します。

// Antigravity の設定ファイル（.antigravity/config.json）
{
  "ai": {
    "provider": "ollama",
    "baseUrl": "http://localhost:11434",
    "model": "gemma4:4b",
    "contextLength": 8192
  }
}

設定後、Antigravity を再起動すると Gemma 4 が使えるようになります。チャットパネルで簡単な質問を送って応答があれば接続成功です。

接続できたかを確実に確かめる

チャットパネルの応答だけで判断すると、不調になった時に切り分けができません。私は次の3段階で確認するようにしています。

# 1. Ollama がモデルを認識しているか
curl http://localhost:11434/api/tags
 
# 2. モデルがメモリに読み込まれているか（占有サイズと保持期限も見える）
ollama ps
 
# 3. 生成リクエストが通るか
curl http://localhost:11434/api/generate -d '{
  "model": "gemma4:4b",
  "prompt": "1+1=",
  "stream": false
}'

切り分けの目安は次の通りです。

• connection refused が返る → Ollama 自体が起動していません。ollama serve を実行してください
• model not found が返る → モデル名の綴り違いか、ollama pull がまだです。ollama list の NAME 列と config.json の model を一字ずつ照合してください。gemma4:4b と gemma-4:4b の取り違えが定番です
• 3 まで通るのに Antigravity から繋がらない → baseUrl の確認と IDE の再起動。設定ファイルが再起動時にしか読み込まれない挙動に、私は何度か騙されました

Step 3: コーディング補助としての活用

Gemma 4 をコーディング補助として使う場合、システムプロンプトの設定が効果的です。

Antigravity のシステムプロンプト設定で以下を追加することで、コード特化の応答を引き出せます。

あなたは熟練したソフトウェアエンジニアのアシスタントです。
コードの説明を求められた場合は、まず動作の概要を1〜2文で述べ、
次に重要なポイントを具体的に解説してください。
コードを生成する際は、コメントを含めて説明付きで出力してください。
日本語でのやり取りを優先します。

システムプロンプトは「短く・禁止事項より方針を書く」のがコツです。ローカルモデルはクラウドの大型モデルよりも指示の優先順位づけが苦手なので、箇条書きで10行も書くと守られない項目が出てきます。上の例くらいの分量に抑えて、足りない分は会話の中で都度指定する方が結果は安定します。

エージェント機能との組み合わせの注意

Antigravity のエージェント機能（ツール呼び出しを伴う自律実行）をローカルの Gemma 4 で使う場合は、過度な期待は禁物です。単発のコード生成・説明・リファクタ提案は十分実用になりますが、複数ステップのツール呼び出しはクラウドモデルに比べて失敗率が上がります。ツール呼び出しが空振りする・JSON が崩れるといった症状が出たら、Gemma 4 のツール呼び出しエラー対処にまとめた対処を試してみてください。

私の使い分けは「会話とコード片はローカル、エージェントに任せる長いタスクはクラウド」です。この線引きにしてから、どちらの不満も減りました。

放置後の「最初の一問」が遅い — keep_alive の調整

Ollama は既定では、最後のリクエストから約5分でモデルをメモリから降ろします。次に話しかけた時はモデルの再読み込みから始まるため、最初の一問だけ数十秒待たされる、という体感になります。コーディング中は調べ物や実装で質問の間隔が空きがちなので、この既定値は開発用途には短すぎるというのが私の実感です。

# モデルを1時間メモリに保持する（serve の起動前に設定）
export OLLAMA_KEEP_ALIVE=1h
ollama serve &

設定後に ollama ps を実行すると、読み込み中のモデルと「あとどれくらい保持されるか」が確認できます。

トレードオフは、保持している間 RAM を占有し続けることです。16GB マシンで 12b を保持したままビルドやシミュレータを回すと他の作業が苦しくなります。私は 4b を使う日は 1h、12b を使う日は 30m に下げる、という運用に落ち着きました。

Gemini 2.5 Pro との使い分け

Gemma 4 とGemini 2.5 Pro（クラウド API）は、用途によって使い分けるのがよいです。

Gemma 4（ローカル）が向いているケース：

• 開発中の実験・プロトタイピング（API コストを気にせず何度でも試せる）
• 社内データや機密情報を含むコードの補助（データをクラウドに送らない）
• オフライン環境での開発

Gemini 2.5 Pro（クラウド）が向いているケース：

• 複雑な推論や大量のコンテキストが必要な場面
• 最新情報へのアクセスが必要な場合
• 本番環境での高精度な応答が求められる場面

よくある問題

Antigravity がモデルに接続できない

Ollama が起動しているか確認してください。

# Ollama のステータス確認
ollama list
 
# サービスが起動していない場合
ollama serve &
 
# 接続テスト
curl http://localhost:11434/api/generate -d '{
  "model": "gemma4:4b",
  "prompt": "Hello"
}'

応答が遅い

まず「常に遅い」のか「放置後の最初の一問だけ遅い」のかを切り分けてください。後者はモデルの再読み込みが原因なので、上の keep_alive の調整で解消します。

常に遅い場合は RAM 不足によるスワップが本命です。4B パラメータモデルでも、RAM が不足しているとスワップが発生して著しく遅くなります。タスクマネージャー（macOS: アクティビティモニタ）でメモリ使用量を確認し、必要に応じてより小さなモデルに切り替えてください。

メモリ不足で落ちる（Out of Memory）

モデルサイズの選び直しが基本ですが、コンテキスト長（contextLength）を 8192 → 4096 に下げるだけで通ることもあります。コンテキスト長は会話履歴を保持する KV キャッシュの分だけメモリを消費するため、長くするほど同じモデルでも要求 RAM が増えるという関係です。詳細な切り分けは Gemma 4 が Out of Memory になる問題の解決法にまとめています。

LM Studio を使いたい

Ollama の代わりに LM Studio をランタイムにする構成も可能です。GUI でモデル管理をしたい方はこちらの方が扱いやすいかもしれません。手順は Ollama / LM Studio 連携ガイドをご覧ください。

まず1日、ローカルだけで過ごしてみる

セットアップが終わったら、試しに1日だけ「コードの質問は全部ローカルの Gemma 4 に投げる」縛りで過ごしてみることをお勧めします。どの場面でローカルが十分で、どの場面でクラウドが恋しくなるかが、自分の開発スタイルに即して見えてきます。私の場合はこの1日で「エージェントの長いタスク以外はローカルで困らない」とわかり、API コストが目に見えて減りました。

接続まわりをさらに詰めたい方は、ローカル LLM 設定の詳細手順が次の一歩としてちょうどよいはずです。