自宅では問題なく動いていた Antigravity が、会社のネットワークに入った途端に「Sign in failed」「Network error: unable to reach Gemini API」と表示される。これ、社内 SE の方でなくてもなかなか原因が見えづらくて厄介です。私自身、クライアントの常駐先で Antigravity を動かそうとして半日ハマったことがあり、そのときに整理したチェック手順をまとめておきます。
プロキシやファイアウォールのトラブルは、症状が似ているのに原因がいくつもあるので、闇雲に設定を変えるとさらに状況が悪化することがあります。まずは「どのレイヤーで止まっているのか」を切り分けるところから始めるのが遠回りに見えて一番早いです。
最初に確認すべきログの場所と読み方
Antigravity のネットワークエラーは、UI 上は「Sign in failed」としか出ないことが多く、ここだけ見てもプロキシが原因なのか証明書が原因なのか分かりません。まず開発者ツールに近い情報を取りに行きます。
macOS / Linux:
# Antigravity のログディレクトリ（Electron ベース）
tail -f ~/Library/Logs/Antigravity/main.log # macOS
tail -f ~/.config/Antigravity/logs/main.log # LinuxWindows（PowerShell）:
Get-Content "$env:APPDATA\Antigravity\logs\main.log" -Wait -Tail 100このログを流したまま、Antigravity を起動してサインインを試みてください。出現するキーワードで、原因がほぼ絞り込めます。
ETIMEDOUT/ECONNREFUSED→ プロキシ未設定、または FW によってブロックunable to verify the first certificate/self signed certificate in certificate chain→ 社内 SSL インスペクション（MITM 型プロキシ）HTTP 407 Proxy Authentication Required→ プロキシ認証が必要HTTP 403/Forbiddenでgenerativelanguage.googleapis.comが出る → ドメイン単位のブロック
「Sign in failed」だけで判断せず、必ずこのログに出ている具体的なエラーコードで切り分けます。
HTTP プロキシを通すときの正しい設定方法
多くの企業ネットワークでは、直接インターネットに出られず、プロキシ経由になります。Antigravity 内蔵のネットワーククライアントは、基本的にシステムのプロキシ設定を読みますが、確実に効かせたい場合は環境変数を明示するのが安全です。
# ~/.zshrc や ~/.bashrc に追記
export HTTPS_PROXY="http://proxy.example.com:8080"
export HTTP_PROXY="http://proxy.example.com:8080"
export NO_PROXY="localhost,127.0.0.1,.example.com"
# Antigravity を起動（シェルから起動することで環境変数が引き継がれる）
/Applications/Antigravity.app/Contents/MacOS/Antigravity認証付きプロキシの場合は、URL に user:pass@ を埋め込みます。ただしパスワードに @ や # が含まれているとパース失敗するので、%40 などにパーセントエンコードしてください。
export HTTPS_PROXY="http://user:p%40ss@proxy.example.com:8080"重要なのは NO_PROXY に localhost と 127.0.0.1 を必ず入れておくこと。ここを忘れると、ローカルで動かしている MCP サーバーや開発サーバーへの通信までプロキシに飛んで、「原因不明の localhost 接続エラー」に悩まされます。MCP を活用している方は、特に MCP サーバー接続トラブルシューティングも合わせて確認しておくと安心です。
SSL インスペクション（自己署名証明書）への対応
エンタープライズ環境で多いのが、Zscaler や Netskope、社内 CA などが TLS トラフィックを復号・再暗号化する「SSL インスペクション」です。このとき Antigravity から見ると、generativelanguage.googleapis.com の証明書が Google のものではなく社内 CA のものに差し替わっているため、証明書検証に失敗します。
対処は、社内 CA 証明書を OS とランタイムの両方に信頼させることです。OS に入れただけでは Node.js ベースのランタイムが使わないケースがあります。
# 社内 CA 証明書を信頼チェーンに追加（macOS）
sudo security add-trusted-cert -d -r trustRoot \
-k /Library/Keychains/System.keychain ~/Downloads/corporate-root-ca.pem
# Electron/Node.js 側にも明示（Antigravity 内蔵ランタイム向け）
export NODE_EXTRA_CA_CERTS="$HOME/.ssl/corporate-root-ca.pem"Windows は証明書マネージャー（certmgr.msc）で「信頼されたルート証明機関」にインポートしたうえで、同じく NODE_EXTRA_CA_CERTS をユーザー環境変数に設定します。
一方、「とりあえず動かしたいから証明書検証を無効化したい」という気持ちはよく分かりますが、NODE_TLS_REJECT_UNAUTHORIZED=0 を常用するのはおすすめしません。API キーやコード差分が平文で中間者に見える状態になり得ます。検証用のローカル確認でだけ一時的に使い、原因を特定したら必ず元に戻してください。
ファイアウォールで特定ドメインが通らないとき
プロキシも証明書も問題ないのに、特定の API 呼び出しだけ失敗する場合、ドメイン単位のアロウリスト漏れが原因のことが多いです。Antigravity が実際にアクセスするドメインは、少なくとも以下を社内のネットワーク管理者に共有して通してもらう必要があります。
antigravity.google— 認証・プロダクト系accounts.google.com/oauth2.googleapis.com— Google サインインgenerativelanguage.googleapis.com— Gemini API 本体*.googleusercontent.com— アバター等の静的リソースstorage.googleapis.com— モデル・アセット配信
アロウリスト追加を依頼する際は、「IP アドレスではなくホスト名（FQDN）で開けてほしい」と明記するのがポイントです。Google の API エンドポイントは IP が頻繁に変わるため、IP ベースで許可されると数日で再度つながらなくなります。
また、curl でドメイン単位のアクセス可否を素早くテストできます。
# プロキシ越しに Gemini API エンドポイントへ到達できるか確認
curl -x "$HTTPS_PROXY" -I https://generativelanguage.googleapis.com/
# 正常なら HTTP/2 404 などが返る（401/403 以外の応答でも到達確認としては十分）返ってくるのが curl: (56) や timeout であれば、まだネットワーク側の問題が残っています。アプリの問題ではないので、いじるべきは社内ネットワーク側の設定です。
サインインだけ通らないパターンの追加チェック
プロキシ・証明書・ドメインがすべて整っていても、OAuth の途中で失敗することがあります。特に SSO（Okta, Azure AD 等）を経由する会社アカウントで Antigravity を使っている場合、ブラウザ側のリダイレクトが戻ってこないケースです。
- ブラウザの既定が Chrome 以外（Edge の業務ポリシー等で拡張がブロック）になっていないか確認
localhost:9004周辺のループバックが社内 FW でブロックされていないか（OAuth コールバック先）- 会社の Google Workspace 側で、Antigravity の OAuth スコープが管理者承認待ちになっていないか
最後のパターンは個人ではどうにもならないため、Workspace 管理者に「Antigravity（Google Developer の OAuth クライアント）を許可アプリに追加してほしい」と依頼します。このあたりはサインイン・アカウントエラーの対処でも補足しているので、症状が一致しそうなら参考にしてください。
全体を振り返って
社内ネットワーク経由のトラブルは、切り分けの順番を間違えなければ必ず原因に辿り着きます。今日から最初にやっていただきたいのは、ログを tail -f で開きながらサインインを試し、出ているエラーコードを1つメモに残すことです。ETIMEDOUT なのか self signed certificate なのかが分かれば、この記事のどのセクションに戻ればいいかが決まります。インフラ側に相談するときも、具体的なエラーコードを持って話すとぐっと早く解決します。