Google Antigravity（第1回）: WSL勢が気になる「VS Code置き換え可否」と、まずはインストール

🚀 はじめに

この記事は Google Antigravity（以下 Antigravity）を「これから触る」方向けの導入記事です。
今回は 「インストール → 初回セットアップ → WSLに接続して最低限の動作確認」 までを、初学者向けにまとめました。

特に、筆者のように WSL上から code . でVS Codeを起動して使っている人 にとっては、

• Antigravityでも 同じ体験（WSLリモート開発） ができるのか？
• いつもの開発に必要な 拡張機能（Python / Git / Snowflake など） が入るのか？
• もし拡張が厳しいなら、CLI中心運用（=IDEは薄く） で逃げられるのか？

が「乗り換え可否」の分岐点になりがちです。

注意（重要）
Antigravityはプレビュー段階のため、UI/用語/対応機能は変更される可能性があります。
この記事の通りに見えない場合は、コマンドパレットで WSL / Remote / Connect などの単語検索で“近い操作”を探すのが早いです。

---

✅ この記事でわかること

• Antigravity と VS Code の違い（置き換え可否の判断ポイント）
• WSLユーザーの最重要ポイント
  • AntigravityからWSLに接続できる？
  • WSL側から code . 相当で起動できる？（＝ターミナル起点の起動）
• インストール手順（Windows / macOS / Linux）
• 初回セットアップで迷いがちな「インポート」と「安全設定」
• 拡張機能の入れ方（検索 / VSIX）と、詰まったときの逃げ道
• 必須ツール（Python / Git / Snowflakeなど）の 最短スモークテスト手順（10分）

---

🪐 Antigravityとは？（超ざっくり）

Antigravityは、従来の「補完＋チャット」型より “エージェントに仕事を任せる” ことを前提にしたIDE（エディタ）です。

• エディタ部分は Code - OSS（VS Codeのオープンソースコア） をベースにしているため、操作感や設定の雰囲気が近い
• エージェントの実行・管理を行う Manager（Agent Manager） を備える
• ブラウザ操作まで含めてエージェントが作業できる（Chrome連携が関わる機能がある）

図1: Editor + Manager + Browser の3点セットで「エージェントに任せる」前提。

---

🆚 VS Codeと何が違う？置き換えられる？

結論から言うと、

• 基本の編集体験（ショートカット、UI、設定）はかなり近い
• 一方で Remote開発（WSL/SSH/Dev Containers）と拡張機能エコシステム が、置き換え可否の分岐点

になりやすいです。

図2: “拡張とRemote”が多いほどVS Code優位。“エージェントとブラウザ”重視ほどAntigravityが刺さる。

置き換え判断のざっくり結論

• 完全移行：拡張少なめ + Remote要件が軽い + エージェント活用が主目的
• 併用：拡張が多い / Remoteが必須 / 会社のポリシーが厳しい → まずは併用が現実的
• まずは様子見：Dev Containersや特殊な拡張が命綱なら、検証してから

図3: “拡張依存”と“Remote要件”で、移行のしやすさが決まる。

---

⭐【最重要】WSL勢の疑問：Antigravityで同じことできる？

筆者の前提（よくあるVS CodeのWSL運用）：

• Windows上のVS Codeを使う
• WSL（Ubuntuなど）側で code . を叩く
• WindowsのVS Codeが起動し、WSLにリモート接続してそのフォルダを開く
  → 開発ツール（python / git / node等）は WSL側 を使う

Antigravityの場合：まず押さえるべき「2つの起動パターン」

Antigravityでも考え方はほぼ同じで、起動パターンが2つあります。

パターンA（おすすめ）：Antigravity → WSLに接続して開く

• GUI側から WSLに接続してフォルダを開く ルート
• まずはこれが成立すれば「いつものWSL開発」がほぼ成立します
• 初学者は ここを“正ルート” にするとハマりにくいです

パターンB（慣れてから）：WSL → code . 相当で起動する

• WSLのターミナルから code . 的に起動できると満足度が上がります
• ただし現時点では、WSLから antigravity を叩くとWindows側が起動したり、カレントディレクトリが渡せないケースがあります
  → まずはパターンAで成立させ、Bは後からでOKで

図4: 「アプリ側からWSLへ接続」が安定ルート。code .相当は環境差が出やすい。

---

🧰 事前準備（ここを揃えると詰まりにくい）

Antigravity本体以外にも、環境によって必要な道具があります。
WSL勢が迷いやすいポイントを、先に潰します。

図5: WSL勢は “WSL2 + Git + ターミナル” まで揃えると迷いにくい。

共通であると安心

• Googleアカウント
  • プレビューや組織ポリシーの関係で、まずは 個人アカウント（個人Gmail） で検証すると切り分けが楽です（会社アカウントは制限に当たりやすい）
• Chrome（推奨）
  • Browser連携（エージェントがブラウザ操作する機能）を使う場合に必要になりがちです
  • 会社PCのポリシーでChrome拡張がブロックされることもあるので、先に確認できると安心です

Windows + WSLで開発する場合（必須に近い）

• WSL2（Ubuntuなど）
• WSL側の Git / Python
  • AntigravityがWSLに接続した場合、基本的に WSL側の git / python を使います

WSLが動いているか確認（PowerShell）：

wsl -l -v

---

📦 インストール（Windows / macOS / Linux）

インストールは基本的に 公式のダウンロードページ から行います。
※偽サイト・類似ドメインが出やすいので、検索経由の場合はURLをよく確認してください。

https://antigravity.google/

図6: “インストール→初回起動→インポート→WSL接続→拡張導入”までが1セット。

Windows

1. インストーラをダウンロード
2. そのまま実行してインストール
3. 起動（スタートメニュー or 検索）

macOS

1. dmgをダウンロード
2. アプリケーションにドラッグしてインストール
3. 初回はセキュリティ許可が出ることがあるので許可

Linux

1. パッケージ（deb/rpm等）をダウンロード
2. ディストリに合わせてインストール

まずは “起動してログインできる” ところまで進めばOKです。

---

🧭 初回起動（迷いやすい2点だけ押さえる）

初回はウィザードで色々聞かれます。
初学者が迷うのはだいたい 「設定のインポート」と「安全設定」 です。

図7: 最初に決めるのは「移行（インポート）」と「安全（権限）」。

1) VS Codeから設定をインポートする？

可能なら、最初にやると楽です。

• キーバインド
• テーマ
• 一部設定
• 拡張機能（環境によっては「入る/入らない」があるので、後で検証）

ただし、ここで 「全部完璧に」 を狙うと沼りやすいです。
まずは 起動してWSLに繋がる状態 を作り、拡張は後で追加するのが安全です。

2) Terminal / Review の安全設定はどうする？

ここが「事故を防ぐ」キモです。

図8: 最初は “確認多め” が正解。慣れてから自動化を上げる。

初学者向けのおすすめ：

• Terminal実行は控えめ（Manual寄り）
  • エージェントが勝手にコマンドを叩かないようにする
• Review（レビュー）は強め（確認ステップ多め）
  • 生成・変更された内容を見てから適用する

自動化は 段階的に 上げるのが正解です。最初から強くしないのがおすすめです。

図9: 自動化は“段階的に”上げる。最初から強くしない。

Antigravity を開くと VS Codeに近いUI で起動します。

Antigravity の起動直後

---

🔌 ここからが本題：WSLに接続してみる（最短手順）

「VS CodeのRemote-WSLの代わり」ができるか、まず確認します。

手順（安定ルート）：Antigravity → WSL

1. Antigravityを起動
2. コマンドパレットを開く（例: Ctrl+Shift+P）
3. WSL / Remote / Connect あたりで検索し、
   Remote WSL: Connect to WSL（名称が近いコマンド） を実行
4. WSLのディストリ（Ubuntuなど）を選択
5. WSL上のフォルダを開く（例: ~/work/myrepo）

![AntigravityからWSLへの設定画面](/images/20260107_google_antigravity/antigravity3
.png)
Antigravity からWSLへ接続する画面（例）

注意（WSL接続の落とし穴）
WSL接続時は「Windowsが見ているWSLパス（\\wsl.localhost\...）」ではなく、Linux側のパス（/home/...） のワークスペースを選ぶのが安全です。

接続できたかの確認（WSLターミナルで実行）

AntigravityのターミナルがWSL側になっているか、これで確認できます。

uname -a
which git
which python3

Antigravity がWSLに接続できた状態（例）

---

🧩 拡張機能のインストール戦略（ここがVS Codeとの差になりやすい）

AntigravityはVS Code系の拡張モデルに近いですが、拡張の入手元がポイントです。

• まずは 検索で入るものから試す（手軽）
• 無い場合は VSIXで手動インストール
• それでも厳しい場合は、拡張に依存しない運用（CLI中心） を検討する

図10: 「検索→VSIX→CLIで逃げる」の順が安全。

注意：マーケットプレイス切り替えは“上級者ルート”
Marketplace切替（非公式設定）は、利用規約や組織ポリシーに抵触する可能性があります。
本記事では 検索/VSIXの範囲で進める方針にしています。

Remote（WSL）時の注意：拡張は「WSL側」に入る場合がある

VS Codeと同様に、WSLに接続した状態では

• 拡張が「ローカル（Windows）」に入るだけでは不十分
• WSL側（リモート側）にインストールが必要

というケースがあります。
拡張の詳細画面に “Install in WSL” のような表示が出たら、そちらを選ぶのが基本です。

---

🧪 必須ツールの互換性チェック（10分で当たりを付ける）

ここでは「置き換え可否」を判断するための 最小セットを載せます。
目的は “WSL環境で開ける → 最小実行できる” を10分で確認する ことです。

互換性チェック表（まずここだけ見ればOK）

目的	だいたい必要なもの	見通し	WSL利用時のポイント
Python開発	Python拡張 + LSP（Pylance等）	多くの場合OK	Python本体はWSL側に入れる
Git運用	内蔵Git機能 + git コマンド	ほぼOK	git はWSL側に必須
Snowflake	Snowflake拡張 or CLI（snowsql等）	拡張は環境差あり	認証（SSO/外部ブラウザ）確認
Claude Code	CLI（+ 任意で拡張）	“CLIで動く”が最優先	WSL側でCLI実行する運用が自然
Qwen	CLI/拡張（Node/npmが絡むことが多い）	“CLIで動く”が最優先	WSL側のNode/npmが必要になりがち

“導入できる” と “運用でストレスなく使える” は別です。
まずは「WSLで起動 → 最小実行」までやって判断しましょう。

---

✅ 実機での確認（10分スモークテスト）

図11: “WSL接続→拡張→最小実行” の順で確認。

0) WSLの準備（WSL側で実行）

git --version
python3 --version

# Node系が必要な人だけ（Qwen等で必要になることがあります）
node --version
npm --version

入っていなければ（Ubuntu例）：

sudo apt update
sudo apt install -y git python3 python3-venv
# Nodeは必要なら別途

1) Antigravityを起動 → WSLに接続

• Remote-WSL: Connect to WSL（または類似コマンド）を実行
• WSLのホーム配下に ~/work/ を作って開く

2) Gitが動くか（WSL側のリポジトリで確認）

cd ~/work
git clone <your_repo_url>
cd <repo>

AntigravityのSource Controlで差分が見えるか確認します。

3) Pythonが動くか（WSL側のPythonで実行）

hello.py を作り：

print("hello antigravity on wsl")

ターミナル（WSL）で：

python3 hello.py

（余裕があれば）venv作成も確認：

python3 -m venv .venv
source .venv/bin/activate
python hello.py

4) Snowflake（拡張 or CLI）を確認

• Snowflake拡張が検索で出るか（出なければVSIX/別手段へ）
• 認証が外部ブラウザを使う場合、WSL接続時に詰まらないか

拡張が難しい場合も、まずは CLIで疎通できる かを確認すると切り分けが早いです。

5) Claude Code / Qwen（まずは“導入できるか”だけ）

• 拡張が検索で見つかるか
• もし拡張が厳しければ、WSL側でCLIとして使えるか（--version が通るか）を確認

---

🧯 初学者がつまずきやすいポイント（FAQ）

図12: つまずきは “アカウント/WSL/拡張/権限” に集中しがち。

Q. WSLに接続できない

• WSL2が有効になっているか
• WSLディストリが起動できるか（wsl -l -v などで確認）
• 会社PCの場合、仮想化やWSLがポリシーで制限されていないか

Q. code . みたいにWSLから起動したいが、うまくいかない

• まずは アプリ側→WSL接続 を“正”として成立させる（安定）
• WSLターミナル起点は、環境依存のトラブルが出やすい → 後から最適化でOK

WSL起点の起動をどうしてもやりたい場合は、agy . のようなランチャー回避策が共有されています（ただし手順は上級者向け）。

Q. 拡張が検索で出てこない

• 拡張の配布先（マーケット）に存在しない可能性があります
  → VSIXで手動インストールを検討（提供元の配布がある場合）
• それでも難しい場合は、CLIで代替できるか検討（特にSnowflake/LLM系）

Q. 拡張は入ったが、WSL側で動かない

• WSL接続時は、拡張が リモート（WSL）側に入る必要があることがあります
  → “Install in WSL” のような選択肢がないか確認

Q. エージェントが勝手にコマンドを実行しそうで怖い

• Terminal execution policy を弱めに
• Review policy を強めに
• “作業フォルダを限定” + “Gitで保護” してから慣れる

Q. Browser連携がWSL接続時にうまく動かない

WSL側からBrowser連携Browser連携を使う場合、WSLのネットワーク設定によっては詰まることがあります（例：WSL内の 127.0.0.1 がWindows側Chromeに届かない）。
回避として WSLの mirrored networking mode を使う案が紹介されています。

図13: Antigravity→Chrome操作→Artifactsに記録、という流れ（概念図）。

---

📝 まとめ

• Antigravityは「エージェントに任せる」前提のIDEで、VS Codeに近い操作感を持つ
• 置き換え可否は WSL/Remote と拡張機能 で決まりやすい
• WSL勢はまず Antigravity → WSL接続 ができるか確認するのが最短
• 拡張は 検索→VSIX→CLIで逃げる の順が安全
• 本記事のチェックリストで、10分で“使える/使えない”の当たりを付けられる

---

🔗 参考リンク

• Tutorial: Getting Started with Google Antigravity（公式チュートリアル）
  https://developers.google.com/codelabs/antigravity-getting-started
• Working with Google Antigravity in WSL（WSLでの動作例・注意点）
  https://medium.com/google-cloud/working-with-google-antigravity-in-wsl-944c96c949f3
• Fixing Antigravity launcher from WSL command line（WSL起点で詰まる場合の議論）
  https://discuss.ai.google.dev/t/fixing-antigravity-launcher-from-wsl-command-line/164219
• Antigravity関連記事（概要）
  https://www.theverge.com/2025/11/19/24300076/google-antigravity-ai-ide-agent-manager-browser