Antigravity からローカル LLM を呼ぶ — Ollama・LM Studio 統合と実用ワークフロー

Antigravity を使い始めた頃の私は、クラウド型の Gemini や Claude にだけ繋いで使っていました。当時はそれで十分だと思っていたのですが、ある日、機密性の高い社内文書を扱う仕事を引き受けたとき、状況が変わりました。クラウド LLM に流せないデータが目の前にあり、「Antigravity 自体は手放したくないけれど、推論はローカルでやりたい」というニーズが生まれたのです。

調べてみると Antigravity は思いの外柔軟で、Ollama や LM Studio を介してローカルの推論サーバーに繋ぐ設定が可能です。クラウド LLM のような「ワンクリックで万能」ではないのですが、設定さえ詰めれば実用に耐える組み合わせになります。

私が試行錯誤しながら詰めた設定と、運用してわかったクラウド LLM との使い分け、そしてローカル LLM ならではの制約をどう回避するかを実例とともに整理しました。「興味はあるが面倒くさそう」と感じていた方の背中を押せる内容を意識しました。

なぜ Antigravity でローカル LLM を使うのか

そもそもの動機を整理すると、私の場合は大きく 3 つあります。

ひとつは、機密データの扱いです。クライアントの NDA で「外部 API に送信不可」と書かれているデータを Antigravity で扱いたい場面があります。クラウド LLM だと運用ポリシー的に難しい局面でも、ローカルで完結すれば許容されるケースは多いです。これが最も切実な動機でした。

ふたつめは、コストです。1 日に何百回も呼ぶような自動化を組むと、API コストが地味に積み上がります。手元のマシンに余力があるなら、定型作業はローカル LLM に任せて、難しい判断だけクラウドに振る、という分担が経済的です。

3 つめは、オフライン耐性です。これは些細に思えますが、ネットワーク環境が不安定な場所で作業することがある人には大きな価値があります。私は時々海外で作業するのですが、現地のネットが遅かったり API が遅延したりするとき、ローカル LLM があると安心できます。

逆に「ローカル LLM じゃなくていい」場面もあります。最先端の推論力が必要なタスク（複雑な設計判断、長文の論理整合性チェックなど）はクラウド一択です。手元のマシンで動く範囲のモデルでは、そこまでの能力には到達しません。

Ollama と LM Studio、どちらを選ぶか

Antigravity から繋ぐローカル推論サーバーの代表格は、Ollama と LM Studio です。私は両方使ってきましたが、用途で使い分けています。

Ollama の強みは「コマンドライン中心で安定」しているところです。CLI で ollama pull gemma3:27b のようにモデルを取得し、ollama serve で OpenAI 互換の API を立てる、というシンプルな構造です。バックグラウンドで動かしっぱなしにしておく運用に向いています。私は Mac mini にこれを常駐させて、自宅 LAN 内のあらゆる端末から叩いています。

LM Studio の強みは「GUI で完結する」ところです。モデルのダウンロード、量子化レベルの選択、システムインストラクションの試行錯誤、すべてが画面上で完結します。プロンプトをいじりながら挙動を見比べるような探索フェーズには LM Studio が明確に楽です。一方で、運用フェーズに入ると Ollama の方が安定します。

私の使い分けは、「手元で試行錯誤するときは LM Studio、運用に乗せるときは Ollama」です。同じ GGUF モデルなら両方で動かせるので、移行コストは低いです。

接続設定の実際 — Ollama 編

Ollama を Antigravity から呼ぶ場合の設定を共有します。Antigravity の設定画面で、カスタムプロバイダとして OpenAI 互換エンドポイントを追加します。

Provider Name: Ollama (local)
Base URL: http://localhost:11434/v1
API Key: ollama  (任意の文字列で OK)
Model: gemma3:27b  (事前に ollama pull で入れたモデル名)

Base URL の末尾に /v1 を付けるのが地味に重要です。これを忘れると、Antigravity 側が OpenAI Chat Completions の形式でリクエストを投げたときに 404 が返ってきます。

API Key は Ollama では実際には使われませんが、Antigravity 側のバリデーションが「空欄」を弾くことがあるので、適当な文字列を入れておきます。ollama でも dummy でも構いません。

別のマシンで動いている Ollama に繋ぐ場合は、Ollama 側で外部接続を許可する必要があります。デフォルトは localhost のみなので、OLLAMA_HOST=0.0.0.0:11434 ollama serve のように起動します。同じ LAN 内であれば、これで他のマシンの Antigravity から http://192.168.1.10:11434/v1 のようにアクセスできます。

セキュリティの観点から、外部 LAN や WAN に開放するのは避けてください。最低でも VPN や SSH トンネル経由で繋ぐ運用にしないと、誰でもあなたのマシンの推論を使い放題になります。

接続設定の実際 — LM Studio 編

LM Studio の場合は、アプリ内の "Local Server" タブから API サーバーを起動します。デフォルトのポートは 1234 で、こちらも OpenAI 互換 API を提供します。

Provider Name: LM Studio (local)
Base URL: http://localhost:1234/v1
API Key: lm-studio
Model: ローカルロード中のモデル名

LM Studio の便利な点は、サーバー起動時のシステムインストラクションを GUI で設定できることです。日本語応答を強制したい場合、量子化を工夫したい場合など、Antigravity 側のプロンプトを変えずに挙動を調整できます。

ただし LM Studio の API サーバーはアプリを起動している間しか動かないので、長時間運用には向きません。「日中は LM Studio で実験、夜間バッチは Ollama」のような分担をしている方を多く見ます。

ローカル LLM 向けのモデル選定

Antigravity から呼ぶ用途で、私が現在使っているモデルを共有します。お使いのマシンスペックによって最適解は変わりますが、参考にしてください。

メインで使っているのは Gemma 3 27B です。M2 Pro の Mac mini（メモリ 32GB）で量子化版（Q4_K_M）が快適に動きます。コード補完、文章校正、要約などの一般タスクは、これでクラウド LLM に近い品質が得られます。

長文を扱うときは Llama 3.3 70B の量子化版を使います。ただし速度は明確に遅くなるので、対話的な使い方には向きません。バッチ処理でじっくり推論させる用途専用です。

軽量タスクには Phi-3.5 mini（3.8B）を使います。ファイル名の正規化、簡単な分類、JSON の整形といった「機械的な変換」用途なら、これで十分高速です。Antigravity の補助的なエージェントとして常時走らせるならこのクラスが現実的です。

モデル選びで失敗しやすいのは、「とにかく大きいのを入れる」発想です。メモリギリギリのモデルを使うと、推論中にスワップが発生して激遅になります。マシンの実効メモリに対して 70% 以下のモデルサイズを選ぶのが安全です。

クラウド LLM との使い分けルーティング

Antigravity の魅力のひとつは、複数のプロバイダを共存させられることです。私はプロジェクトごとに、どのプロバイダを使うかをルール化しています。

機密データを含むプロジェクトでは、すべての推論を Ollama 経由のローカル LLM に固定します。Antigravity の設定でデフォルトプロバイダを Ollama にしておくと、うっかりクラウドに送る事故を防げます。

逆に、機密性の低い OSS プロジェクトでは、デフォルトをクラウド LLM（Gemini や Claude）にして、コード補完など軽量タスクだけローカルに振ります。これでコスト最適化と品質を両立できます。

プロジェクト横断で使い分けるテクニックとして、Antigravity のプロジェクト設定ファイル（.antigravity/config.json のような場所、バージョンによって異なる）に defaultProvider を書き込んでおくのが便利です。プロジェクトを開くたびに正しいプロバイダが自動選択されます。

ローカル LLM の制約 1: コンテキスト長

ローカル LLM の代表的な制約は、コンテキスト長の短さです。クラウド LLM は 1M トークンといった巨大なコンテキストをサポートしますが、ローカル LLM は 8k〜32k 程度が一般的です。Gemma 3 で 128k まで拡張できるモデルもありますが、メモリ消費が爆発するので実用範囲は限られます。

対処パターンは 3 つです。

ひとつは、Antigravity 側のコンテキスト分割機能を活用することです。長いファイルを開いて推論させる場合、Antigravity が「関連部分だけ抜き出してモデルに渡す」モードがあります。これを有効にしておくと、ローカル LLM のコンテキスト制限内に収まりやすくなります。

ふたつめは、要約をかましてからローカル LLM に渡すことです。長い議事録の要約タスクなら、まずクラウド LLM で章ごとに要約してから、それをローカル LLM で統合する、という二段構えにします。Antigravity 上で別々のプロバイダを使い分けられるので、これは比較的簡単に組めます。

3 つめは、コンテキスト依存度の低いタスクをローカル LLM に集中させることです。たとえば「このコードのレビュー」よりも「この関数だけのリファクタリング」の方がコンテキストは短くて済みます。タスク粒度を意識すれば、コンテキスト制約は意外と気にならなくなります。

ローカル LLM の制約 2: 関数呼び出しの精度

クラウド LLM の Function Calling は近年急速に賢くなりましたが、ローカル LLM ではまだ品質に差があります。Gemma 3 27B でも、複雑なツールチェーンをミスなく実行するのは厳しいです。

対処は 2 つあります。ひとつは、ローカル LLM に複雑な関数呼び出しをさせないことです。エージェント的な使い方は基本クラウドに任せて、ローカルは「単発の応答生成」に絞ります。

もうひとつは、関数呼び出し代替のフォーマットを使うことです。OpenAI 形式の Function Calling ではなく、「JSON 出力を強制するプロンプト」で代替します。「以下の形式の JSON だけを出してください: { ... }」と書いて、レスポンスを自分でパースする方式です。これなら多くのローカルモデルで安定動作します。

Antigravity のプラグインを書いている方なら、ローカル LLM 用の薄いラッパーを作っておくと便利です。「JSON 出力 → パース → 関数実行」までを 1 つのプラグインで処理する感じですね。

ローカル LLM の制約 3: 速度

最後の制約は、純粋な推論速度です。Gemma 3 27B を Mac mini M2 Pro で動かすと、トークン生成速度は秒間 12〜18 トークン程度です。クラウド LLM の数倍は遅いので、対話的な使い方ではストレスを感じます。

対処は、用途を分けることに尽きます。リアルタイム性が必要な作業（コード補完、対話）はクラウド LLM、バッチ的な作業（夜間の自動更新、ログ要約、コンテンツ生成）はローカル LLM、と切り分けます。

私のサイト群の自動更新は深夜に走らせているので、多少遅くても困りません。ローカル LLM は深夜の静かな時間帯に活躍してくれて、API コストを抑えてくれる、という分担が定着しています。

ハードウェアの現実的な選択肢

Antigravity でローカル LLM を本気で使うなら、ハードウェアの選択は避けて通れません。私の経験から、3 つの価格帯で推奨を書いておきます。

一番安い選択肢は、既存の M シリーズ Mac を活用することです。MacBook Pro M3 Pro 以上、メモリ 32GB 以上なら、Gemma 3 27B クラスを実用的に動かせます。新規投資不要で始められます。

中価格帯の専用機としては、Mac mini M2 Pro / M4 Pro のメモリ 32〜64GB が定番です。30 万円前後で、24 時間稼働できる推論サーバーが手に入ります。私はこれを使っています。

高価格帯では、Apple Silicon の Mac Studio（メモリ 96GB 以上）か、NVIDIA RTX 4090 / 5090 を積んだ Linux ワークステーションです。70B クラスのモデルを快適に動かしたいならこの帯域です。100 万円前後の投資になりますが、月のクラウド LLM コストが 5 万円を超えるような使い方をしているなら、半年〜1 年で回収できます。

実運用で気をつけているモニタリング

ローカル LLM をプロダクションに乗せるなら、最低限のモニタリングは必須です。私が見ているのは次の指標です。

GPU/Neural Engine の温度と利用率。長時間の高負荷運用では、サーマルスロットリングで急に推論が遅くなることがあります。asitop のようなツールで定期的にチェックします。

メモリ使用量とスワップ発生量。スワップが発生し始めたら推論速度が桁違いに落ちるので、その閾値を超えないモデルサイズに調整します。

応答時間の中央値と 95 パーセンタイル。中央値だけ見ていると、たまに発生する遅延を見落とします。95 パーセンタイルを見ると、ユーザー体感の悪さがわかります。

これらを Grafana や簡易ダッシュボードで可視化しておくと、いざ問題が起きたときに原因の切り分けが速くなります。

ローカルモデルに切り替えた瞬間、応答が英語になる問題

ローカル LLM を使い始めて最初に戸惑うのが、クラウドモデルでは日本語で返っていたタスクサマリが、Ollama に切り替えた途端に英語になることです。

これは Antigravity 側の設定が効いていないのではなく、軽量モデルがシステム指示の言語指定を無視しやすいために起こります。Gemma 3 4B クラスでは、システム指示に「日本語で回答する」と一行書くだけでは足りず、指示の位置とプロンプト内の言語比率に引きずられます。

個人開発の環境で試行錯誤しながら、最終的に安定させられた方法は次の二つです。

システム指示ではなく、各リクエストの末尾に出力言語の指定を置く。モデルは直近のトークンに強く反応します
Few-shot の例を日本語で1つだけ入れる。例文が1つあるだけで、以降の応答言語が固定されます

逆に、コードコメントまで日本語化されると困る場面もあります。その場合は「本文は日本語、コード内のコメントは英語」と両方を明示してください。片方だけ書くと、モデルは全体をどちらかに寄せます。

症状	効いた対処
サマリだけ英語になる	リクエスト末尾に出力言語を再指定
応答言語が毎回ぶれる	日本語の Few-shot 例を1つ追加
コードコメントまで日本語化	本文とコードの言語を別々に明示

UI や応答言語の設定そのものの置き場所は「Antigravity 2.0 を日本語UI で快適に使うための設定」に、モデルの実行環境ごとコンテナに閉じ込めて再現性を確保する手順は「Antigravity DevContainer 構築ガイド」に整理しています。

明日から始めるための最小ステップ

長くなりましたが、明日から始める方のための最小手順を共有します。

まず Ollama をインストール（brew install ollama）し、Gemma 3 4B あたりの軽量モデルを ollama pull gemma3:4b で取得します。次に ollama serve で起動し、Antigravity 側で前述の設定でカスタムプロバイダを追加します。最後に Antigravity でテキスト生成タスクを 1 回実行して、応答が返ってくることを確認します。

ここまでで小一時間かかります。動いたら、徐々に大きなモデルや複雑なタスクに挑戦してみてください。

ローカル LLM は「クラウド LLM の代替」ではなく「クラウド LLM の補完」と捉えるのが現実的です。両方を使いこなせる Antigravity 環境を持っていると、扱える仕事の幅が確実に広がります。私が機密案件を引き受けられるようになったのは、この組み合わせを整えたおかげです。同じような壁を感じている方の参考になれば幸いです。