Antigravity × ローカルLLM（Ollama / LM Studio / LM Link）を本番運用する実践接続ガイド

AntigravityをローカルLLMで動かす記事は増えていますが、そのほとんどが「とりあえず繋がるまで」で終わっています。実際に1日8時間、開発で使い倒すと、接続層はすぐに本番品質の問題にぶつかります。数時間に1度の切断、重い推論で応答が返らないセッション、モデル切替時の詰まり、再起動で状態を失う——こうした症状です。

ここでは私がAntigravity × ローカルLLMで半年以上運用してきた経験から、本番運用で実際に効く接続層の設計をまとめました。接続手順そのものではなく、「繋がった後、壊れないように運用するにはどうするか」に焦点を当てています。

まず最初に：3つのバックエンドの使い分け

Antigravityから接続できるローカルLLMバックエンドは主に3つあります。OllamaとLM StudioとLM Linkです。「どれを選べばいいか」という質問をよく受けますが、一つに決めずにタスクタイプで使い分けるのが私の結論です。

Ollamaが向いているタスク

CLIからスクリプトで呼びたい場合
複数マシンで同じモデル構成を再現したい場合（Dockerfileに近い感覚で環境が揃う）
長時間連続で走らせる場合（安定性が一番高い印象）

LM Studioが向いているタスク

GUIでモデルを試行錯誤したい開発初期
量子化レベル（Q4_K_M, Q5_K_M等）を細かく切り替えて検証したい
Appleシリコン上でMLXを活かしたい場合

LM Linkが向いているタスク

自分のMacを母艦にして、別マシンからLM Studioのモデルを使いたい場合
Tailscaleなどのプライベートネットワーク経由で社外から自分のモデルにアクセスしたい
開発マシンと推論マシンを分離したい場合

3つを使い分ける運用にしておくと、1つが不調な時に切替が効きます。私はOllamaを主、LM Studioを検証用、LM Linkを外出時のリモート接続用という配置にしています。

接続層を本番品質にするための5つの設定

1. タイムアウトを明示的に長く取る

デフォルトのタイムアウトは、大きめのモデルで長い応答を生成するには短すぎます。Ollamaの場合、Antigravity側のカスタムエンドポイント設定でタイムアウトを延長できます。

{
  "name": "local-ollama",
  "baseUrl": "http://localhost:11434/v1",
  "apiKey": "none",
  "timeoutMs": 600000,
  "maxRetries": 1,
  "streamingEnabled": true
}

ポイントは3つです。timeoutMs を10分（600,000ms）に伸ばす、maxRetries を1に抑える（エージェントのretry設計と二重にしない）、streamingEnabled を有効にしてトークンごとの進捗を可視化する、この3点です。

2. Ollamaのkeep_aliveを調整する

Ollamaはデフォルトで、最後のリクエストから5分経つとモデルをメモリから解放します。Antigravityで作業中に5分のアイドルが入ると、次のリクエストでモデルの再ロード（数十秒〜数分）が走り、体感が著しく悪化します。

# Ollamaサーバー起動時の環境変数で指定
export OLLAMA_KEEP_ALIVE=3h
ollama serve

3h にしておけば、昼休みから戻ってきてもすぐ応答が返ります。VRAM圧迫が気になる場合は 1h でも十分です。

3. LM Studioのcontext lengthを上げる

LM StudioのGUIで、該当モデルの Context Length をモデルのネイティブ上限まで上げておきます。デフォルトで4096になっているケースが多く、Antigravityが長めの会話を続けると、途中でコンテキストから古い部分が消えて応答品質が落ちます。

Model Settings → Context Length → 131072 (Gemma 4の場合の例)
Evaluation Batch Size → 512（メモリに余裕があれば）

4. LM Link は Tailscale経由に固定する

LM Linkを直接インターネットに開くのは避けてください。Tailscale（またはWireGuardなど）のメッシュVPN経由で、プライベートネットワーク内でのみ到達可能にします。

# LM Linkホスト側でTailscale起動
tailscale up
 
# Antigravity側（クライアントマシン）から接続確認
curl http://<tailscale-hostname>:1234/v1/models

この運用にすると、公開IPを気にせずに、出先のMacBookから自宅の推論マシンを安全に使えます。

5. システムプロンプトでモデル能力を補足する

ローカルLLMはクラウドモデルに比べて指示追従が甘いケースがあります。Antigravityのカスタムシステムプロンプトで、モデルに期待する振る舞いを明示的に補足しておきます。

## Behavior policy for this local backend

- 出力は常に UTF-8 の日本語または英語のみ。他の言語への自動切替は禁止。
- コード変更を提案する場合、必ず diff 形式で提示する。
- テストが必要な変更の場合、テストファイルもあわせて提示する。
- 外部APIを呼ぶコードを書く場合、`// TODO: verify endpoint` コメントを必ず添える。

これを入れるだけで、ローカルモデルでの出力のばらつきが半分以下になる印象です。

フォールバック設計：ローカルが沈黙した時の復旧

本番運用で避けられないのが、「ローカルが応答しなくなる」瞬間です。熱暴走、他プロセスのVRAM占有、バックエンドのハング——原因はさまざまですが、対処は共通です。自動フォールバックの経路を最初から用意しておくことです。

最低限の2経路構成

私の構成は次のようになっています。

{
  "endpoints": [
    {
      "name": "primary-local",
      "type": "ollama",
      "baseUrl": "http://localhost:11434/v1",
      "priority": 1,
      "healthCheckPath": "/api/version"
    },
    {
      "name": "fallback-cloud",
      "type": "anthropic",
      "priority": 2,
      "triggerOnLocalFailure": true
    }
  ]
}

プライマリをローカル、フォールバックをクラウドAPIに設定します。ローカルが応答しない時は、自動的にクラウドへ切り替わる運用です。

ヘルスチェックの自動化

私は60秒ごとにローカルの応答性をチェックするスクリプトを回しています。

#!/usr/bin/env bash
# local_health.sh — ローカルLLMのヘルスチェック
set -uo pipefail
 
LOGFILE="$HOME/.antigravity/health.log"
LOCAL_URL="http://localhost:11434/api/version"
 
while true; do
  TS=$(date -Iseconds)
  if curl -fsS --max-time 5 "$LOCAL_URL" >/dev/null 2>&1; then
    echo "$TS OK" >> "$LOGFILE"
  else
    echo "$TS FAIL" >> "$LOGFILE"
    # 通知（Slack webhook等）
    curl -s -X POST -H 'Content-Type: application/json' \
      -d "{\"text\":\"⚠️ Local LLM unreachable at $TS\"}" \
      "$SLACK_WEBHOOK_URL" >/dev/null 2>&1
  fi
  sleep 60
done

Dead man's switchの発想で、沈黙を早期に検知できるようにしておきます。

VRAM逼迫時の自動退避

同じマシンで他の重いプロセス（動画編集、別のローカルLLM）を立ち上げた瞬間にVRAMが逼迫し、Ollamaが応答不能になるケースがあります。対策として、モデルサイズの違う2つを用意しておき、自動で小さいほうに切り替える運用が有効です。

# VRAM残量が閾値を下回ったら小モデルに切替
AVAIL_MB=$(nvidia-smi --query-gpu=memory.free --format=csv,noheader,nounits | head -1)
if [ "$AVAIL_MB" -lt 4000 ]; then
  ollama stop gemma4:27b 2>/dev/null
  ollama run gemma4:9b > /dev/null 2>&1 &
fi

Apple Silicon の場合は vm_stat で swap 使用量を監視し、閾値超過で切り替えます。

モデル選定：用途別の私のおすすめ

タスク別のモデル選定は、何度も試行錯誤して今は次の構成に落ち着いています。

エージェント型のコード修正タスク: Gemma 4 の中〜大（9B〜27B）、または Qwen 系の同規模。判断の一貫性が必要な場面では27Bが安定しますが、VRAM 24GB以下なら9Bの方が快適です。

チャットでの壁打ち、ドキュメント執筆: 量子化の効いた Gemma 4 9B（Q4_K_M）。応答速度と品質のバランスが良く、長い文章でも破綻しません。

軽いタスク（リネーム提案、一行修正など）: Gemma 4 2B または小型モデル。応答が瞬時なので、試行錯誤が多い場面で効く。

実運用のコツとして、モデルを固定しないことをおすすめします。Antigravityの設定に複数モデルを登録しておき、タスクに応じて切り替えるワークフローにしておくと、1つのモデル依存からくる事故が減ります。

運用監視：最低限仕込んでおくこと

本番運用で絶対にやっておいたほうがいいのが、応答時間のログ取りです。どのモデルでどのくらい掛かっているかを記録しておくと、「最近遅い」が感覚ではなく数字で見えるようになります。

# Ollama 応答時間の計測
START=$(date +%s%N)
echo "hello" | ollama run gemma4:9b > /dev/null
END=$(date +%s%N)
echo "$(date -Iseconds) gemma4:9b $((($END - $START) / 1000000))ms" \
  >> ~/.antigravity/perf.log

週1回このログを振り返ると、モデルの劣化（再量子化が必要）やハードウェアの不調（サーマルスロットリング）を早めに発見できます。

全体を振り返ってに代えて：最初の一歩

この記事には書いたことが多いので、導入の最初の一歩をご提案します。タイムアウト10分とOLLAMA_KEEP_ALIVE=3h、この2つだけを今日設定してください。それだけで、体感の安定性が大きく変わります。

フォールバック設計やヘルスチェックは、運用に慣れてから段階的に足せば十分です。大事なのは、「ローカルLLMは本番品質になる」という前提で、壊れることを想定した設計に最初から入れておくことです。

ローカルLLMは手元で完結する安心感と、コスト面のメリットが本当に大きい選択です。ぜひこのガイドを参考に、自分のプロジェクトで無理のない範囲から始めてみてください。