記事一覧/連携・プラグイン

⬡ 連携・プラグイン/2026-05-04上級

Antigravity に Gemma 4 ローカルモデルを統合する — オフライン/エアギャップ環境での AI 開発

Apache 2.0でリリースされた Gemma 4 を Antigravity に統合することで、機密プロジェクトやオフライン環境でも Antigravity のエージェント体験が可能になります。Ollama / vLLM 経由の接続設定、Architect / Builder の挙動チューニング、本番運用の注意点までを実装ベースで解説します。

Antigravity³³⁸ Gemma 4²¹ ローカルLLM²⁰ オフライン開発³ Ollama¹² vLLM エアギャップセキュリティ¹²

✦ プレミアム記事

社外秘プロジェクト、医療データを扱うシステム、出張先でネットが不安定な環境——こうしたシーンで Antigravity を使いたいと思ったことはないでしょうか。Antigravity の標準構成は Gemini 3 Pro をクラウドで利用する前提なので、データの組織外送信が許されない案件では使いどころが限られていました。

ところが2026年4月のGemma 4リリース以降、状況は変わりつつあります。Apache 2.0 でリリースされた Gemma 4 26B A4B または 31B Dense モデルをローカル/オンプレで動かし、Antigravity から呼び出せれば、機密性の高い案件でもAntigravity のエージェント体験を享受できるようになります。

ここで扱うのは私が実際に検証したGemma 4 ローカルモデルと Antigravity の統合手順を、設定ファイルと共に詳細に共有します。Architect / Builder それぞれの挙動チューニングや、エアギャップ環境での運用上の落とし穴まで、本番投入前に知っておくべき内容を網羅します。

統合パターンの全体像

Antigravity と Gemma 4 を統合するパターンは、技術的には3つに分類できます。それぞれのトレードオフを理解してから実装に入るのが確実です。

パターンA: Antigravity をすべてローカルに切り替える 最もシンプルで、エアギャップ環境向け。Antigravity の Architect / Builder のモデル接続先を Gemini API から Gemma 4 ローカルサーバへ完全に置き換えます。

パターンB: タスク種別でモデルを振り分ける 軽いタスクは Gemma 4 ローカル、重いタスク（複雑な調査・長文生成）は Gemini API。コストとセキュリティのバランス型。

パターンC: 機密度ベースで動的ルーティング データに含まれる機密情報の有無を判定し、機密データを含む場合のみ Gemma 4 ローカルに送る。社内SaaSや顧客データを扱うエンタープライズ向け。

ここで扱うのはまずパターンAの基本実装を完成させ、その上でパターンB・Cへの拡張方法を示します。

ステップ1: Gemma 4 推論サーバの構築

Antigravity から呼び出すため、Gemma 4 を OpenAI 互換 API として公開する推論サーバを立てます。私の経験上、Antigravity との接続が最も安定するのは vLLM か Ollama の OpenAI 互換エンドポイントを使う構成です。

ここでは Ollama ベースの最小構成を示します。

# Ollama インストール（Mac / Linux）
curl -fsSL https://ollama.com/install.sh | sh
 
# Gemma 4 26B A4B をダウンロード
ollama pull gemma4:26b-a4b
 
# OpenAI 互換エンドポイント有効化（Ollama 0.5+）
export OLLAMA_HOST=0.0.0.0:11434
ollama serve &

この時点で http://localhost:11434/v1/chat/completions が OpenAI 互換 API として使えるようになります。

エアギャップ環境で運用する場合は、事前にインターネット接続のある環境で ollama pull を実行し、~/.ollama/models/ ディレクトリ全体を USB やセキュアな転送手段で移送します。Gemma 4 26B A4B のQ4_K_M版は約15GB、31B Dense版（Q4_K_M）は約20GB程度です。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦Antigravity から Gemma 4 を呼び出すための設定ファイル全文（コピペで動く）

✦Architect / Builder それぞれに対する Gemma 4 向けプロンプト調整パターン

✦オフライン/エアギャップ環境で運用するための推論サーバ構成図

✦Gemini 3 と Gemma 4 のハイブリッド構成で機密度別に振り分ける実装

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

ステップ2: Antigravity の設定ファイルを書き換える

Antigravity の設定ファイル（~/.config/antigravity/config.json または .antigravity/config.json）に、Gemma 4 推論サーバへの接続設定を追加します。

{
  "providers": {
    "local-gemma4": {
      "type": "openai-compatible",
      "baseURL": "http://localhost:11434/v1",
      "apiKey": "ollama-no-auth-needed",
      "models": {
        "default": "gemma4:26b-a4b",
        "fast": "gemma4:26b-a4b",
        "deep": "gemma4:31b"
      }
    }
  },
  "agents": {
    "architect": {
      "provider": "local-gemma4",
      "model": "deep",
      "temperature": 0.3,
      "maxTokens": 4096
    },
    "builder": {
      "provider": "local-gemma4",
      "model": "default",
      "temperature": 0.1,
      "maxTokens": 8192
    }
  },
  "defaultProvider": "local-gemma4"
}

ここで重要なのは『Architectには 31B Dense（"deep"）を、Builderには 26B A4B（"default"）を割り当てる』という分担です。Architect は要件分解と設計判断を行うため、より高い推論力を持つモデルが望ましく、31B Dense モデルが向きます。Builder は実装作業中心で、応答速度の優位性から 26B A4B（MoE）を使うのが体感的に最も快適です。

apiKey は Ollama では不要ですが、Antigravity の OpenAI 互換クライアントが空文字列を許容しないため、ダミー値を入れる必要があります。

ステップ3: Architect 向けプロンプトの調整

Gemma 4 を使う場合、Gemini 3 と比べて『暗黙の前提を読み取る能力』がやや弱いため、Architect への指示は明示的に書く必要があります。

私が標準テンプレートとして使っている Architect 用システムプロンプトを共有します。

あなたはAntigravityのArchitectエージェントです。ローカルLLM (Gemma 4) で動作しているため、以下の制約に従ってください。
 
## 出力形式
1. 要件の再確認（ユーザーの要望を1段落で要約）
2. 設計案（番号付きリストで3つ）
3. 各案のメリット・デメリット
4. 推奨案と確信度（高・中・低）
5. 確信度が中・低の場合、追加で必要な情報を質問形式で記載
 
## 重要な制約
- 推測ではなく、明示された情報のみに基づいて判断する
- ユーザーが指定していない技術選定は『推測』として明記する
- 1回の応答で扱うのは1つの要件のみ
- 既存コードに依存する判断は、ファイル名と行番号を明示する
 
## 禁止事項
- 「一般的には」「多くの場合」のような曖昧な根拠
- 推論の過程を省略した結論だけの提示
- 設計案の数を3つから増減すること

Gemini 3 の場合は、もっとざっくりした指示でも自然に補完してくれますが、Gemma 4 では明示的なフォーマット指定をしないと出力がブレます。これを面倒と感じるかもしれませんが、結果的に出力品質の予測可能性が上がるので、本番運用ではむしろこちらが安定します。

ステップ4: Builder 向けプロンプトの調整

Builder は Architect の出力した設計を元にコードを生成します。Gemma 4 の Builder 向けには、より厳格な制約付き最適化フレームを使うのが効果的です。

あなたはAntigravityのBuilderエージェントです。Architectが出した設計に基づき、コードを実装してください。
 
## 入力
- Architectの設計（前のターンで提示済み）
- 対象ファイル一覧（ユーザー指定）
- 既存コード（必要に応じてファイル読み取りツールで確認）
 
## 出力形式
1. 実装方針（1段落、Architectの設計との対応関係を明示）
2. 変更ファイル一覧と各ファイルの変更概要
3. 各ファイルの diff 形式の変更内容
4. テスト方針（既存テストへの影響と、新規テストの提案）
 
## 制約（必ず守ること）
- ファイル読み取りツールで実コードを確認してから変更を提案する
- 不明な型・関数があれば憶測で書かず、ユーザーに確認する
- 1ファイルあたりの変更行数は150行以下に抑える
- 上記を超える場合は、変更を複数のセッションに分割する提案をする
 
## 禁止事項
- 既存コードを大規模に書き換える提案
- テストを書かない実装
- TODO コメントだけを残して未完了で終える

特に『1ファイルあたり150行以下』という制約は、Gemma 4 の長文生成が Gemini 3 ほど安定しないことへの対策として効きます。これ以上の変更は分割提案させることで、結果として品質の高いコミット粒度が自然に維持できます。

エアギャップ環境での運用構成

機密性の高いプロジェクトでは、ネットワークから完全に切り離した環境で Antigravity + Gemma 4 を運用することがあります。この場合の構成パターンを示します。

[開発者の作業端末]
    │
    │ ローカルネットワークのみ
    ▼
[推論サーバ (DGX Spark / RTX 4090 マシン)]
    ├─ Ollama サーバ (port 11434)
    ├─ Gemma 4 26B A4B (実装用)
    └─ Gemma 4 31B Dense (設計用)

ポイントは『推論サーバを開発者端末と分離する』ことです。複数開発者で同じプロジェクトに関わる場合、各人が GPU を持つ必要がなくなり、コストとメンテナンス負荷を抑えられます。

エアギャップ環境では、モデル更新の運用フローを最初に決めておくのが必須です。私が知る現場では、四半期ごとに「最新の Gemma バージョンを安全な手段で持ち込み、評価データセットで品質回帰がないことを確認してから配備」というルーチンを回しています。

ハイブリッド構成（パターンC）の実装例

機密度ベースの動的ルーティングを実装するには、Antigravity の前段に簡単なルーターを置く方法が現実的です。Cloudflare Workers や FastAPI で実装した薄いプロキシで、リクエストの内容を機密度判定し、Gemma 4 ローカルか Gemini API のいずれかに振り分けます。

# 機密度判定の擬似コード
def route_request(messages: list[dict]) -> str:
    full_text = "\n".join(m["content"] for m in messages)
 
    # 機密ワード検知
    if any(kw in full_text for kw in CONFIDENTIAL_KEYWORDS):
        return "local-gemma4"
 
    # 患者ID/カードNo/個人情報パターン
    if re.search(r"\b\d{4}-\d{4}-\d{4}-\d{4}\b", full_text):
        return "local-gemma4"
 
    # ファイル名から判定
    if any("internal" in m.get("metadata", {}).get("file", "")
           for m in messages):
        return "local-gemma4"
 
    return "gemini-api"

このルーターを Antigravity の前に挟むことで、Architect / Builder どちらの呼び出しも自動的に適切なバックエンドに振り分けられます。

運用上の3つの注意点

ここまでの構成を本番投入する前に、注意すべき点を3つ共有します。

第一に、応答時間のばらつき。 Gemma 4 31B Dense をローカルで動かすと、推論時間が10〜30秒の幅で揺れます。Antigravity のUI は Gemini API 前提でレスポンス時間を想定しているため、長すぎるとタイムアウト扱いになることがあります。Antigravity の設定でタイムアウト値を 60 秒以上に拡張しておきましょう。

第二に、コンテキストウィンドウの制約。 Gemma 4 のコンテキストは Gemini 3 より短いです（実用的には 8K〜32K）。Architect が大量のファイルを参照する設計セッションでは、コンテキスト溢れに気を付ける必要があります。私はファイル参照を10件以下に制限する運用ルールを置いています。

第三に、定期的な品質回帰テスト。 Gemma 4 は今後もアップデートが入ります。新バージョンに切り替えるたびに、自分のユースケースで品質が下がっていないかを確認するルーチンを持つこと。代表的なタスク10〜20個を記録しておき、新バージョン投入時に再実行して結果を比較するのが最低限の対策です。

個人開発者の視点から（実体験メモ）

締めくくり

Antigravity を機密性の高い案件で使えるようにするのは、これまで現実的ではありませんでした。Gemma 4 のリリースで、その壁が崩れ始めています。

完全に Gemini 3 を置き換えることはまだ難しいですが、適切な構成（特にパターンB・C）を選べば、機密性とエージェント体験を両立できるようになります。ローカルLLMの運用には独特のオペレーションが必要ですが、ここを乗り越えると、Antigravity の適用範囲が大きく広がります。

次の一歩としておすすめなのは、まず手元のマシン（M3 Max 以上または RTX 4090 以上）でパターンA（フル切り替え）を1日試してみること。Architect の出力品質が想像以上に実用的であることに驚くはずです。そこから運用要件に合わせてパターンB・Cへ進化させていくのが、現実的な導入ルートです。