Antigravity を DevContainer で動かす — チーム全員が同じ環境で動く設定の作り方

Antigravity を複数人で開発していると「私の Mac では動くのに、新しいメンバーの Windows では動かない」「依存関係が衝突して別のプロジェクトが壊れた」といった問題が出てきます。私自身、社外コラボの最初の1週間がこれで溶けたことがあります。

DevContainer を使えば、Antigravity の実行環境を Dockerfile として宣言的に固定できます。新メンバーは VS Code で「Reopen in Container」を押すだけで、全く同じ環境で開発を始められます。ここでは私が実際に使っている .devcontainer 設定をベースに、最小構成から段階的に説明します。

最小構成: まず動かしてみる

.devcontainer/devcontainer.json と .devcontainer/Dockerfile の2ファイルだけで始められます。

// .devcontainer/devcontainer.json
{
  "name": "Antigravity Dev",
  "build": {
    "dockerfile": "Dockerfile"
  },
  "features": {
    "ghcr.io/devcontainers/features/git:1": {},
    "ghcr.io/devcontainers/features/github-cli:1": {}
  },
  "customizations": {
    "vscode": {
      "extensions": [
        "ms-python.python",
        "ms-python.vscode-pylance",
        "google.antigravity"
      ],
      "settings": {
        "python.defaultInterpreterPath": "/usr/local/bin/python",
        "editor.formatOnSave": true
      }
    }
  },
  "postCreateCommand": "pip install -r requirements.txt && antigravity init",
  "remoteUser": "vscode"
}

# .devcontainer/Dockerfile
FROM mcr.microsoft.com/devcontainers/python:3.12
 
# Antigravity CLI のインストール
RUN curl -fsSL https://antigravity.google.com/install.sh | bash
 
# 開発に必要な追加ツール
RUN apt-get update && apt-get install -y --no-install-recommends \
    jq \
    httpie \
    && rm -rf /var/lib/apt/lists/*
 
# 作業ディレクトリ
WORKDIR /workspace
 
# Pythonパッケージのキャッシュ層を分離（ビルド時間短縮）
COPY requirements.txt /tmp/
RUN pip install --no-cache-dir -r /tmp/requirements.txt
 
# Antigravity の追加プラグインを事前インストール
RUN antigravity plugins install agentkit lm-link

VS Code でこのリポジトリを開いて Cmd+Shift+P → Dev Containers: Reopen in Container を選ぶと、初回は数分かけてビルド、2回目以降はキャッシュからほぼ瞬時に立ち上がります。

認証情報の安全な受け渡し

ここからが多くの方が詰まるポイントです。Antigravity は API キーや OAuth トークンを必要としますが、これらを Dockerfile に書き込むと Docker レイヤに残ってしまい、リポジトリに push してしまうと事故になります。

私が使っている方法は3パターンあります。

方法1: ローカル環境変数の引き継ぎ（個人開発向け）

devcontainer.json の remoteEnv で、ホストマシンの環境変数をコンテナに引き渡します。

{
  "remoteEnv": {
    "ANTIGRAVITY_API_KEY": "${localEnv:ANTIGRAVITY_API_KEY}",
    "OPENAI_API_KEY": "${localEnv:OPENAI_API_KEY}"
  }
}

ホスト側で export ANTIGRAVITY_API_KEY=YOUR_API_KEY しておけば、コンテナ内でも同じ値が使えます。Mac/Linux のシェル設定（~/.zshrc 等）に書いておくのが楽です。

方法2: ホストの設定ファイルをマウント（推奨）

API キーをコンテナに入れず、ホスト側の認証ファイルを read-only でマウントする方法です。

{
  "mounts": [
    "source=${localEnv:HOME}/.config/antigravity,target=/home/vscode/.config/antigravity,type=bind,consistency=cached,readonly"
  ]
}

antigravity login で生成される認証情報がホストの ~/.config/antigravity 以下に保存されているので、これをそのままマウントします。コンテナを破棄しても認証情報は失われず、複数のプロジェクトで同じ認証情報を共有できます。

方法3: Secrets 管理サービスとの連携（チーム開発向け）

チームで開発する場合は、HashiCorp Vault や AWS Secrets Manager 等から起動時にフェッチする方式が安全です。

# .devcontainer/postCreate.sh
#!/bin/bash
set -e
 
# AWS CLI 経由で Secret を取得
export ANTIGRAVITY_API_KEY=$(aws secretsmanager get-secret-value \
  --secret-id antigravity/dev/api-key \
  --query SecretString --output text)
 
# 環境変数として永続化（コンテナ内のみ）
echo "export ANTIGRAVITY_API_KEY=$ANTIGRAVITY_API_KEY" >> ~/.bashrc
echo "export ANTIGRAVITY_API_KEY=$ANTIGRAVITY_API_KEY" >> ~/.zshrc

devcontainer.json の postCreateCommand で bash .devcontainer/postCreate.sh を呼ぶように設定します。

GPU を使うエージェントを動かす

Antigravity でローカルLLM（Ollama 等）を併用したい場合、GPU パススルーの設定が必要です。Docker Desktop（Windows / macOS）と Linux ネイティブで設定が異なります。

Linux（NVIDIA GPU）

{
  "runArgs": [
    "--gpus=all",
    "--shm-size=8gb"
  ],
  "containerEnv": {
    "NVIDIA_VISIBLE_DEVICES": "all",
    "NVIDIA_DRIVER_CAPABILITIES": "compute,utility"
  }
}

事前に host で nvidia-container-toolkit をインストールしておく必要があります。

# Ubuntu の例
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit
sudo systemctl restart docker

macOS（Apple Silicon）

Apple Silicon では Docker からの GPU パススルーが現状サポートされていません。代わりに、Ollama をホスト側で起動して、コンテナから host.docker.internal:11434 で接続する方式が現実的です。

{
  "runArgs": ["--add-host=host.docker.internal:host-gateway"]
}

# コンテナ内のコードから
import ollama
client = ollama.Client(host="http://host.docker.internal:11434")

ファイルパフォーマンスのチューニング

DevContainer で大量のファイルを扱う際、デフォルト設定だとファイルアクセスが遅くなることがあります。特に macOS では顕著です。

{
  "mounts": [
    "source=${localWorkspaceFolder},target=/workspace,type=bind,consistency=cached"
  ]
}

consistency=cached を指定するだけで、ホストからのファイル読み込みが大幅に速くなります（Mac では3〜5倍の体感差）。ただしコンテナからホストへの書き込みは少し遅延が出るので、ビルド成果物などは Named Volume に分離するのが理想です。

チームでの onboarding を最小化する README

DevContainer を導入したら、README に以下を記載しておくと新メンバーの立ち上げが10分以内になります。

## 開発環境のセットアップ
 
### 必要なもの
- VS Code（最新版）
- Docker Desktop（Mac/Win）または Docker Engine（Linux）
- VS Code 拡張機能: Dev Containers
 
### 手順
1. このリポジトリをクローン
2. ホスト側で `cp .env.example .env` し、必要な API キーを設定
3. VS Code でリポジトリを開く
4. `Cmd+Shift+P` → `Dev Containers: Reopen in Container`
5. 初回ビルド完了まで5〜10分待つ
6. ターミナルで `antigravity --version` が動けば完了
 
### よくある質問
- 「ビルドがエラーで止まる」→ Docker Desktop のメモリ割当を 8GB 以上に
- 「認証エラー」→ ホスト側で `antigravity login` を済ませてからコンテナを開き直す

私の本音: DevContainer を使う・使わない判断

正直なところ、個人開発の小さなプロジェクトでは DevContainer はオーバーキルだと感じます。私が DevContainer を使うのは、以下のいずれかに当てはまる時だけです。

2人以上で開発する（特に OS が混在する場合）
本番環境が Linux で、開発が macOS や Windows
機密度の高い API キーを扱い、ホストに残したくない
CI と完全に同じ環境で手元で動かしたい

逆に、ローカルの venv で十分動いていて、特に困っていないなら無理に DevContainer 化する必要はありません。技術的に可能なことと、やった方が良いことは別の話です。

次に試すこと

DevContainer の設定が固まったら、次は GitHub Codespaces で同じ .devcontainer を使ってクラウド開発環境を立ち上げることもできます。Codespaces なら Docker のセットアップすら不要で、ブラウザだけで開発開始できるので、外部協力者に対する onboarding はさらに短縮できます。