Antigravity を立ち上げてエージェントに話しかけても応答が返らず、ログを開くと self-signed certificate in chain あるいは unable to verify the first certificate という一行だけが残っている——。先日、出張先のコワーキングスペースで作業していたとき、私が最初にぶつかったのがこの症状でした。自宅では何の問題もなく動いていたのに、ネットワークが変わった途端にモデルへの接続だけが失敗するのです。
先に結論を書きます。このエラーはほぼ確実に Antigravity 自体の不具合ではなく、あなたと Google のサーバーの間に「TLS を一度解いて中身を覗いてから繋ぎ直す」中間装置がいる ことが原因です。社内プロキシ、ZScaler のようなクラウドゲートウェイ、あるいはアンチウイルスの HTTPS スキャン機能がこれにあたります。これらは通信の途中で独自の証明書を差し込むため、Antigravity が内蔵する Node.js が「知らない証明書だ」と判断して接続を拒否しているわけです。
2014年から個人開発を続け、世界各地でアート活動をしながらカフェやホテルのネットワークを転々としてきた身としては、この手の証明書エラーは旅の相棒のようなものです。ここでは私自身の切り分け手順を、再現条件から順に整理しておきます。
まず症状を正しく読み取る
このトラブルは、いくつかの異なるメッセージで顔を出します。代表的なものを挙げます。
Error: self-signed certificate in chainunable to verify the first certificateUNABLE_TO_GET_ISSUER_CERT_LOCALLYrequest to https://... failed, reason: ... certificate
文言は違っても、すべて「証明書チェーンを最後まで辿って信頼できるルートに行き着けなかった」という同じ事象を指しています。重要なのは、この症状はネットワークに依存して再現する という点です。自宅の回線では出ず、会社や特定の Wi-Fi に繋いだときだけ出るなら、原因はほぼ間違いなく経路上の TLS 検査です。
切り分けの第一歩として、同じ回線でターミナルから次を実行してみてください。
node -e "require('https').get('https://generativelanguage.googleapis.com', r => console.log(r.statusCode)).on('error', e => console.error(e.code, e.message))"ここで SELF_SIGNED_CERT_IN_CHAIN 系のエラーが返れば、Antigravity ではなく Node.js のレイヤーで証明書検証に失敗していることが確定します。Antigravity は内部で Node ベースのランタイムを使っているため、この結果がそのまま Antigravity の挙動を説明します。
なぜ「正しい証明書」が拒否されるのか
社内プロキシやセキュリティソフトは、暗号化された通信の中身を検査するために、いったん TLS を終端します。そして自前のルート証明書（CA）で署名し直した証明書を、あなたの端末に向けて提示します。OS の証明書ストアにその CA がインストールされていれば、ブラウザは何事もなく動きます。
問題は、Node.js が OS の証明書ストアを完全には参照せず、自前にバンドルしたルート証明書のリストを使う 点にあります。ブラウザは通るのに Antigravity だけが落ちる、という非対称はここから生まれます。つまり「証明書が壊れている」のではなく、「Antigravity 側がその CA を知らされていない」だけなのです。
解決策その1：信頼すべき CA を Node に教える（推奨）
最も筋の良い対処は、検証を無効化するのではなく、会社や端末が使っている CA 証明書を Antigravity に明示的に渡す ことです。Node.js には NODE_EXTRA_CA_CERTS という環境変数があり、ここに指定した PEM ファイルを既定のルートに追加してくれます。
まず、信頼すべき CA 証明書（拡張子は .pem または .crt）をIT部門から受け取るか、OS のストアからエクスポートします。macOS ならキーチェーンアクセスから、Windows なら証明書マネージャーから書き出せます。
そのうえで、Antigravity を 環境変数が効く形で起動 します。GUI から普通に起動すると、シェルで設定した環境変数が読まれないことがあるので、ターミナルから起動するのが確実です。
macOS の場合:
export NODE_EXTRA_CA_CERTS="$HOME/certs/corporate-ca.pem"
open -a "Antigravity"Windows（PowerShell）の場合:
$env:NODE_EXTRA_CA_CERTS = "C:\certs\corporate-ca.pem"
Start-Process "Antigravity"GUI のショートカットからの起動でも常に効かせたい場合は、macOS なら ~/.zshrc ではなく launchctl setenv を、Windows ならシステム環境変数に登録します。
# macOS: GUI アプリにも環境変数を渡す
launchctl setenv NODE_EXTRA_CA_CERTS "$HOME/certs/corporate-ca.pem"
# 設定後は一度ログアウト・ログインするか、Antigravity を完全に再起動します複数の CA を束ねたい場合は、PEM ブロックを連結した一つのファイルにまとめておけば、その全部が信頼対象になります。
解決策その2：プロキシそのものを正しく通す
証明書を解決しても、そもそもプロキシを経由しないと外に出られない環境では、接続先までパケットが届きません。この場合は標準的なプロキシ環境変数を設定します。
export HTTPS_PROXY="http://proxy.example.com:8080"
export HTTP_PROXY="http://proxy.example.com:8080"
# 社内ホストや localhost はプロキシを通さない
export NO_PROXY="localhost,127.0.0.1,.internal.example.com"ここで一点だけ注意があります。プロキシ環境変数と NODE_EXTRA_CA_CERTS は 両方同時に必要になることが多い という点です。「プロキシは通ったが証明書で弾かれる」「証明書は入れたがプロキシに出られない」のどちらか片方だけを直しても接続は復活しません。私も最初はプロキシ設定だけ入れて満足し、まる一日ハマりました。両輪で考えるのが近道です。
やってはいけない対処
検索すると NODE_TLS_REJECT_UNAUTHORIZED=0 で検証を丸ごと無効化する方法が出てきます。これは確かにエラーを消しますが、TLS の検証を全面的に切る という意味であり、中間者攻撃に対して無防備になります。一時的な切り分けに使うのは構いませんが、日常運用に残すのは避けてください。検証を消すのではなく、正しい CA を教える——この向きを守るのが安全です。
予防策
ネットワークを頻繁に移動する方は、信頼すべき CA をまとめた PEM ファイルを一つ用意し、launchctl setenv（macOS）やシステム環境変数（Windows）に常設しておくと、回線が変わるたびに慌てずに済みます。私はカフェ作業が多いので、自宅・コワーキング・モバイル回線それぞれで一度ずつ動作確認をして、つまずきやすいポイントを手元のメモに残すようにしています。最初の一度だけ丁寧に設定しておけば、あとは環境が変わっても同じ手順で立ち上がります。
接続が回復したら、解決策その1のワンライナーをもう一度走らせ、200 が返ることを確認してから本格的な作業に戻るのがおすすめです。同じ証明書エラーに悩んでいる方の遠回りが、少しでも短くなれば幸いです。