Antigravity をローカルで動かしていると、「マシンが変わると再現できない」「OS 依存のパスが混ざる」「同僚に同じ環境を渡せない」といった、再現性の壁にぶつかります。これを根本的に解決する方法が DevContainer 化です。
このガイドは、私が個人プロジェクトと小規模チームの両方で Antigravity の DevContainer を運用してきた経験から、最初から知っておけば良かった設計判断と、避けるべき罠をまとめたものです。Docker と VS Code の基礎は前提として、Antigravity 特有の構成にフォーカスします。
なぜ Antigravity こそ DevContainer 化すべきか
Antigravity は単なるエディタではなく、エージェント実行環境を内包しています。エージェントは bash コマンドを実行し、ファイルを書き、ネットワークアクセスをします。この実行環境が「ローカルマシンそのもの」だと、エージェントの誤動作が直接システムに影響します。
DevContainer 化することで、次のメリットが得られます。
- エージェントの破壊的操作がコンテナ内に閉じる
- Node.js / Python / Go などのツールチェインがプロジェクト単位で固定できる
- Ollama や Postgres を同じ compose で起動して、エージェントから即使える
- 同僚に環境を配布する時に「これを
code .で開いて」だけで済む
私の経験では、新規メンバーのオンボーディングに半日〜1 日かかっていたのが、DevContainer 化後は 30 分に短縮されました。
最小構成の DevContainer
まず動くものを作ります。プロジェクトのルートに .devcontainer/ ディレクトリを作って、次の 2 ファイルを配置してください。
.devcontainer/devcontainer.json:
{
"name": "Antigravity Workspace",
"build": {
"dockerfile": "Dockerfile"
},
"customizations": {
"vscode": {
"extensions": [
"google.antigravity",
"esbenp.prettier-vscode",
"dbaeumer.vscode-eslint"
],
"settings": {
"antigravity.workspaceMode": "container",
"antigravity.allowedTools": ["bash", "fileEdit", "webSearch"]
}
}
},
"remoteUser": "node",
"forwardPorts": [3000, 11434, 5432],
"postCreateCommand": "npm install"
}.devcontainer/Dockerfile:
FROM mcr.microsoft.com/devcontainers/javascript-node:22
RUN apt-get update && apt-get install -y \
curl jq postgresql-client redis-tools \
&& rm -rf /var/lib/apt/lists/*
# Antigravity CLI をインストール（バージョン固定）
RUN curl -fsSL https://antigravity.google.com/install.sh | sh -s -- --version 2.4.1これだけで、VS Code から「Reopen in Container」を選べば Antigravity が動く環境が立ち上がります。
Ollama を同 compose に同梱する
ローカル LLM を使う場合は、Docker Compose で Ollama を別サービスとして起動するのが最も安定します。
.devcontainer/docker-compose.yml:
services:
workspace:
build:
context: .
dockerfile: Dockerfile
volumes:
- ../..:/workspace:cached
command: sleep infinity
depends_on:
- ollama
environment:
- OLLAMA_BASE_URL=http://ollama:11434
ollama:
image: ollama/ollama:latest
volumes:
- ollama-models:/root/.ollama
ports:
- "11434:11434"
deploy:
resources:
reservations:
devices:
- capabilities: ["gpu"]
count: all
volumes:
ollama-models:devcontainer.json 側を dockerComposeFile 形式に書き換えます。
{
"name": "Antigravity + Ollama",
"dockerComposeFile": "docker-compose.yml",
"service": "workspace",
"workspaceFolder": "/workspace"
}これで Antigravity 内のエージェントから http://ollama:11434 で Ollama が呼び出せます。OLLAMA_BASE_URL を環境変数で渡しているので、Antigravity の設定でハードコードする必要もありません。
GPU を使う場合の deploy.resources 部分は、NVIDIA Container Toolkit がホストにインストールされている前提です。Apple Silicon の場合は deploy ブロック全体を削除してください（Docker Desktop は Mac の Metal GPU をコンテナに渡せません）。
シークレットを安全に扱う
DevContainer に API キーをハードコードするのは絶対に避けてください。.env ファイルを使う方法が最も実践的です。
.devcontainer/.env.example:
ANTHROPIC_API_KEY=
GOOGLE_API_KEY=
GITHUB_TOKEN=
OPENAI_API_KEY=
.gitignore に .devcontainer/.env を追加し、各メンバーがローカルで .env.example をコピーして自分のキーを書きます。docker-compose.yml から参照します。
services:
workspace:
env_file:
- .envこれで Antigravity からは process.env.ANTHROPIC_API_KEY でキーが読めますが、Git には絶対に上がりません。
私が以前やってしまった失敗は、devcontainer.json の containerEnv に直接キーを書いていたケースです。これは .devcontainer/devcontainer.json 自体が Git にコミットされるため、即座にキーが漏れます。env_file 経由が必須です。
ボリューム永続化の落とし穴
DevContainer の標準動作では、コンテナ削除時に内部のファイルがすべて消えます。次のものを永続化したい場合は、明示的にボリュームを切る必要があります。
- Ollama のモデル（数 GB〜数十 GB あるので、毎回ダウンロードは現実的でない）
- Antigravity の会話履歴・エージェント状態
- npm / pip のキャッシュ
docker-compose.yml に追加：
services:
workspace:
volumes:
- ../..:/workspace:cached
- antigravity-state:/home/node/.antigravity
- npm-cache:/home/node/.npm
- pip-cache:/home/node/.cache/pip
volumes:
ollama-models:
antigravity-state:
npm-cache:
pip-cache:これで再ビルドしても会話履歴やキャッシュが残ります。私はこれを設定するまで、毎回 Ollama のモデルダウンロードに 20 分待たされていました。
チームでの配布パターン
チームで使う場合の運用フローです。
1. リポジトリのルートに .devcontainer/ をコミット
Dockerfile、docker-compose.yml、devcontainer.json、.env.example をコミット。.env はコミットしありません。
2. README に起動手順を 3 行で書く
## 開発環境の起動
1. Docker Desktop を起動
2. `cp .devcontainer/.env.example .devcontainer/.env` して API キーを記入
3. VS Code でリポジトリを開き、コマンドパレットから "Reopen in Container"3. Antigravity の設定を devcontainer.json の customizations.vscode.settings に集約
これにより、誰がコンテナを立ち上げても同じ Antigravity 設定が適用されます。「自分の環境では動いた」を撲滅できます。
CI と連動させる
DevContainer の Dockerfile を CI でも使えば、「ローカルでは通るが CI で落ちる」を防げます。GitHub Actions の例：
name: Test in DevContainer
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: devcontainers/ci@v0.3
with:
imageName: my-app-devcontainer
push: never
runCmd: npm testdevcontainers/ci Action は .devcontainer/Dockerfile を CI 上でビルドして、その中でコマンドを実行します。ローカルと CI が同じ Dockerfile から作られるので、環境差異によるバグが激減します。
DevContainer 化で気をつけるべき制約
便利な反面、注意点もあります。
ファイルウォッチャの挙動
/workspace は bind mount のため、ホスト側のファイル変更は即座に反映されますが、フレームワーク（Next.js の next dev 等）のホットリロードがコンテナ内で動かないことがあります。CHOKIDAR_USEPOLLING=true を環境変数に追加すると改善することが多いです。
起動時間が長い
初回ビルドは 5〜15 分かかります。これは仕方ないので、初回だけは時間を見ておいてください。postCreateCommand を最小限に抑えると次回以降は高速です。
ホスト側のシェル設定が引き継がれない
ホスト側の .zshrc の alias などはコンテナ内では使えません。プロジェクト固有の aliases.sh を .devcontainer/ に置いて、Dockerfile で ~/.bashrc に source 追加するのが定番です。
コンテナの中と外で、AI の応答がずれるとき
DevContainer 化して最初に驚いたのは、同じプロンプトでもホストとコンテナで Antigravity の応答が変わることでした。原因は環境変数です。
ホスト側に残していた ANTIGRAVITY_MODEL や API キーの向き先が、コンテナには渡っていない。結果としてコンテナ内では既定モデルにフォールバックし、応答の粒度も速度も変わります。気づかないまま「コンテナだと精度が落ちる」と誤解しかけました。
対処は単純で、devcontainer.json の remoteEnv に必要な変数だけを明示的に列挙します。containerEnv ではなく remoteEnv を使うのは、イメージのビルドキャッシュに値を焼き込まないためです。
{
"remoteEnv": {
"ANTIGRAVITY_MODEL": "${localEnv:ANTIGRAVITY_MODEL}",
"GOOGLE_API_KEY": "${localEnv:GOOGLE_API_KEY}"
}
}キーそのものは .env に置き、.gitignore に必ず入れてください。containerEnv に直接書いてしまうと、イメージレイヤに値が残り、共有した瞬間に漏れます。個人開発でも、ここだけは横着しないほうが安全です。
ローカル LLM をコンテナから呼ぶ場合は、ホストの Ollama へ host.docker.internal で到達させる必要があります。その設定は「Antigravity からローカル LLM を呼ぶ」に、CLI へ移行しながら自動化を止めない段取りは「Gemini CLI から Antigravity CLI へ」にまとめています。
次のアクション
このガイドの内容のうち、まず一つだけ試すなら 「最小構成の DevContainer」セクションのコピペ です。Ollama や CI 連動は後付けで追加できます。
最初の Reopen in Container が成功するまで来れば、後はあなたの好きな順序で機能を足していけます。Antigravity を本格運用する以上、再現可能な環境はもはやオプションではなく前提です。一度作ってしまえば、新しいプロジェクトにコピーして改造する形で何度でも使い回せます。