はじめに
Googleは2026年9月23日、エージェント開発用の「Antigravity SDK」がローカルAIモデルに対応したと発表しました。最初の対応モデルはGemma 4 26B A4Bで、完全オフラインで動かせます。本稿では、セットアップ手順とサンプルコード、クラウドとの併用例を解説します。
参考記事
- タイトル: Introducing Support for Local AI Models in the Antigravity SDK
- 著者: Sachin Kotwani、Taylor Mullen
- 発行元: Google Developers Blog
- 発行日: 2026年9月23日
- URL: https://developers.googleblog.com/introducing-support-for-local-ai-models-in-the-antigravity-sdk/
関連記事
要点
- Antigravity SDKがローカルモデルでの実行に対応し、初期対応としてGemma 4 26B A4BをLiteRT経由で動かせるようになった
- ローカル実行により、API費用やレート制限なし、コードを外部に出さない、オフラインでも動く、といった利点が得られる
- 推奨環境は24GBを超えるVRAMまたはユニファイドメモリを備えたマシンである
- クラウドのGemini 3.8 Flashが計画を立て、ローカルのGemma 4 26Bが作業を担う構成では、全トークンの97.2%がローカルで処理された
- Ollama、LM Studio、vLLMなどOpenAI互換のサーバーにも接続できる
詳細解説
Antigravity SDKのローカル対応とは
Antigravity SDKは、Googleのエージェント型開発環境「Google Antigravity」を支えるのと同じエージェント機能を、開発者が自分のアプリに組み込むためのSDK（ソフトウェア開発キット）です。Google I/O 2026で発表されたAntigravityの仕組みを、プログラムから直接使えるようにしたものと位置づけられます。
Googleによれば、今回のアップデートで、Antigravity SDKは幅広いローカルモデルと実行方式でのワークフローに対応しました。最初に対応したのは、Google AI EdgeのLiteRTを使ったGemma 4 26B A4Bです。完全にオフラインのままエージェントによる支援を受けられ、このワークフローはLiteRTとGemma 4 26B向けに最適化されており、手元のGPUとRAMを効率よく使うとされています。
LiteRT（旧TensorFlow Lite）は、スマートフォンやPCなどの端末上でAIモデルを効率よく動かすためのGoogleの実行環境で、LiteRT-LMはその大規模言語モデル向けの仕組みです。また「26B A4B」という名前は、一般に総パラメータ数が約260億で、推論時に実際に使われる（アクティブな）パラメータが約40億であることを示す表記です。こうしたMoE（Mixture of Experts：入力ごとに一部の専門家ネットワークだけを使う方式）のモデルは、大きなモデルの知識を持ちながら計算量を抑えられるため、ローカル実行と相性が良いと考えられます。
ローカルでエージェントを動かす4つの利点
記事では、ローカルでモデルを動かすことの利点として次の4つが挙げられています。
- コスト効率: API費用やレート制限（一定時間あたりの呼び出し回数の上限）なしで、エージェントのワークフローを実行できる
- プライバシー: コードやリクエストを完全に手元のマシンにとどめられる。厳しいデータ保護の要件がある開発者や、コンプライアンス上の制約がある企業環境に向いている
- オフラインでの安定性: 安定したインターネット接続がない環境でも、ワークフローを途切れずに実行できる
- ハイブリッドなワークフロー: トークン効率の良いローカル処理とクラウド上の処理を組み合わせ、必要なときには大規模なモデルも使える
本稿としては、社外にソースコードを出せないという理由で生成AIの導入が止まっている企業にとって、2つ目のプライバシーの利点が最も実務的な意味を持つと考えています。
前提条件・環境構成
Googleは、24GBを超えるVRAM（GPU専用のメモリ）またはユニファイドメモリを備えたマシンを推奨しています。ユニファイドメモリは、Apple シリコンのMacなどでCPUとGPUが共有するメモリのことです。つまり、GPUのメモリが24GB以下のPCや、メモリが24GB以下のMacでは、動作が難しいか非常に遅くなる可能性があります。
以降の手順は、記事のコマンドに合わせてMac／Linuxのターミナルを想定しています。
インストール・セットアップ
手順は次の3段階です。
- 仮想環境を作成して有効にする
- Antigravity SDKとLiteRT-LMをインストールし、Gemma 4 26B A4Bをダウンロードする
- サンプルのPythonファイルを作成して実行する
最初に、仮想環境を作ります。仮想環境は、プロジェクトごとにPythonのライブラリを分けて管理するための仕組みで、他のプロジェクトとライブラリのバージョンが衝突するのを防ぐために使います。
# カレントディレクトリに「.venv」という名前の仮想環境を作成します
python3 -m venv .venv
# 作成した仮想環境を有効にします(以降のpipはこの環境にインストールされます)
source .venv/bin/activate次に、pip（Pythonのパッケージ管理ツール）でAntigravity SDKとLiteRT-LMをインストールし、LiteRT-LMのコマンドでGemma 4 26B A4Bのモデルファイルを取り込みます。
# Antigravity SDK(google-antigravity)とLiteRT-LMをインストールします
pip install google-antigravity litert-lm
# Hugging Faceのリポジトリからモデルファイルを取得し、「gemma4-26b」という名前で登録します
litert-lm import \
--from-huggingface-repo=litert-community/gemma-4-26B-A4B-it-litert-lm \
gemma-4-26B-A4B-it-gpu.litertlm \
gemma4-26blitert-lm import の各引数は、順に「取得元のHugging Faceリポジトリ」「リポジトリ内のモデルファイル名（GPU向け）」「手元で使う登録名」を指定しています。末尾の \ はコマンドを複数行に分けて書くための記号です。
注意: モデルファイルは数十GB規模になると考えられるため、ダウンロードには時間がかかり、十分なディスクの空き容量も必要です。
実装例：最初のエージェントを動かす
インストールが終わったら、作業ディレクトリに agy_sample.py というファイルを作り、次の内容を貼り付けます。ローカルのGemma 4 26Bを使うエージェントを起動し、「現在のディレクトリにどんなファイルがあるか」を尋ねるコードです。以下は記事のサンプルコードをもとにしており、日本語のコメントは本稿で補足しています。
import asyncio
import os
from google.antigravity import Agent, LiteRTAgentConfig
from google.antigravity.hooks import policy
# UPDATE: Point to the locally downloaded model from the previous step (litert-lm import ...)
# 前の手順(litert-lm import)で取り込んだモデルファイルの場所を指定します
MODEL_PATH = os.path.expanduser("~/.litert-lm/models/gemma4-26b/model.litertlm")
async def main():
print(f"Using local LiteRT model: {MODEL_PATH}. Please wait for local inference to complete. This could take several minutes.")
# LiteRTでローカルモデルを使う設定を作り、lightweight()で軽量な構成にします
config = LiteRTAgentConfig(model_path=MODEL_PATH).lightweight()
# エージェントを起動し、質問を送ります
async with Agent(config) as agent:
response = await agent.chat("What files are in the current directory?")
# 回答はトークン単位で順次届くので、届いた分から画面に表示します
async for token in response:
print(token, end="", flush=True)
if __name__ == "__main__":
asyncio.run(main())コードの主なポイントは次のとおりです。
- MODEL_PATH: litert-lm import で登録したモデルが保存される場所です。登録名を変えた場合は gemma4-26b の部分を合わせて変更します
- LiteRTAgentConfig: LiteRTで動くローカルモデルを使うための設定です
- asyncio: 非同期処理（処理の完了を待つ間に他の処理を進められる仕組み）のための標準ライブラリで、回答を少しずつ受け取って表示するために使われています
ファイルを保存したら、仮想環境を有効にした状態で次のコマンドで実行します。
# サンプルを実行します
python agy_sample.py注意: コード中のメッセージにあるとおり、ローカルでの推論は完了まで数分かかることがあります。止まったように見えてもしばらく待つ必要があります。なお、このサンプルでは policy をインポートしていますが使っていません。次の例で使われる機能です。
実装例：CLIのリソースモニターを作らせる
記事では、Gemma 4 26B A4Bと組み合わせたAntigravity SDKは実用的なツールの「作成」が得意だとして、ターミナル上で動くリソースモニターを作らせる例が紹介されています。1つのプロンプトを与えるだけで、エージェントが自律的に、psutil（CPUやメモリの情報を取得するライブラリ）とrich（ターミナルの表示を装飾するライブラリ）を使うPythonスクリプトを書き、必要なライブラリを列挙した requirements.txt を作り、動作確認まで行います。すべて手元のマシン上で完結します。
次のコードを cli_resource_monitor.py として保存します。
## cli_resource_monitor.py
import asyncio
import os
from google.antigravity import Agent, LiteRTAgentConfig
from google.antigravity.hooks import policy
# UPDATE: Your prompt
# エージェントへの指示(CPU・メモリ使用量と、メモリ使用量上位5プロセスの表を表示するツールを作り、動作確認まで行う)
PROMPT = "Build a command-line interface tool using the psutil and rich libraries that displays a live-updating terminal dashboard. It should show CPU usage, memory consumption, and a sorted table of the top 5 most memory-intensive processes. Save the script as 'monitor.py' and create a 'requirements.txt' file. Test that it works."
# UPDATE: Point to the locally imported LiteRT-LM model path
MODEL_PATH = os.path.expanduser("~/.litert-lm/models/gemma4-26b/model.litertlm")
# UPDATE: Give AGY-SDK a workspace to write files
# エージェントがファイルを書き込む作業フォルダ(~/agy-test)を作成し、そこへ移動します
WORKING_DIR = os.path.expanduser("~/agy-test")
os.makedirs(WORKING_DIR, exist_ok=True)
os.chdir(WORKING_DIR)
async def main():
print(f"Using local LiteRT model: {MODEL_PATH}. Please wait for local inference to complete. This could take several minutes.")
config = LiteRTAgentConfig(
model_path=MODEL_PATH,
# エージェントが操作できる作業フォルダを指定します
workspaces=[WORKING_DIR],
# ツールの実行をすべて許可するポリシーです
policies=[policy.allow_all()],
).lightweight()
async with Agent(config) as agent:
response = await agent.chat(PROMPT)
async for token in response:
print(token, end="", flush=True)
if __name__ == "__main__":
asyncio.run(main())最初の例との違いは、workspaces で作業フォルダを、policies でエージェントに許可する操作の範囲を指定している点です。ファイルの作成やコマンドの実行を伴うため、これらの設定が必要になります。
注意: policy.allow_all() は、エージェントのツール実行をすべて許可する設定と読めます。ローカルとはいえ、エージェントがファイル操作やコマンドを確認なしに実行できる状態になるため、試す際は専用の作業フォルダを使い、重要なファイルがある場所では動かさないのが安全だと思います。
ハイブリッド構成：クラウドの設計者とローカルの作業者
記事では、クラウドモデルの規模とローカルモデルの利点を組み合わせる方法として、「Architect-Builder（設計者と作業者）」パターンが有効だとしています。デモでは、クラウドのGemini 3.8 Flashが計画と指揮を担い、ローカルで複数動かしたGemma 4 26Bが実作業をすべて端末上で行いました。
課題は、脆弱性を含む3つのモジュール（auth.py、billing.py、database.py）の監査と修正です。Googleによれば、この構成でデータのプライバシーを厳密に保ちながら、トークンを有効に使えたとされています。
- コードをアップロードしない: Gemini 3.8 Flashはファイル名とタスクの説明だけをもとに戦略を立てて作業を分解し、使ったクラウドのトークンは95だけで、ソースコードは一切マシンの外に出なかった
- ローカルでの自律的な検証ループ: ローカルGPU上のGemma 4 26Bが引き継ぎ、脆弱性の再現、修正案の作成、修正の相互批評、回帰テスト（既存機能が壊れていないかを確かめるテスト）による検証という、敵対的な監査ループを実行した
- コストとプライバシーの両面の効果: 記録された実行では、全トークンの97.2%（3,322トークン）がクラウドAPIを呼ばずにローカルでオフライン処理され、完全に検証済みのパッチ（テストがすべて通る状態）を作りつつ、独自のコードを端末内に安全にとどめた
サンプルプロジェクトも公開されており、同梱の3ファイルの検証課題を試すことも、自分のPythonモジュールとテストスイートを対象にすることもできます。
「判断はクラウドの賢いモデル、量の多い作業はローカルのモデル」という分担は、社外にコードを出さずに高度なモデルの計画力を借りる方法として、実務でも採り入れやすい構成だと思います。ただし、ファイル名やタスクの説明にも機密が含まれうるため、クラウドに渡す情報の範囲は組織の方針に沿って確認しておく必要があると考えています。
OpenAI互換サーバーへの接続
Antigravity SDKは、LocalOpenAIAgentConfig を使って、Ollama、LM Studio、vLLMなどOpenAI互換のサーバーにも接続できます。OpenAI互換サーバーとは、OpenAIのAPIと同じ形式でリクエストを受け付けるローカルの推論サーバーのことです。これにより、エージェントの構成やツール、ワークフローを変えずに、さまざまなローカル推論の仕組みを試せるとされています。
すでにOllamaやLM Studioで別のモデルを動かしている場合は、それを活かしながらAntigravity SDKのエージェント機能を試せる点が便利だと思います。詳しい手順は、Antigravity Python SDKのREADMEのローカルモデルの項で確認でき、要望や不具合はGitHubのIssue Trackerで受け付けています。
まとめ
Antigravity SDKのローカル対応で、コードを外部に出さずにエージェントを動かせる選択肢が広がりました。必要なメモリは大きいものの、クラウドとの分担も含めて試す価値はあると思います。LiteRTとGemma 4の端末向けの活用は、Raspberry Pi向けの事例もあわせてご覧ください。
