新しいバージョンの Antigravity を入れ直した翌朝、デスクトップアイコンをダブルクリックしても、数秒だけ砂時計が出て、そのまま何も起きませんでした。クラッシュログも残っていません。エラーダイアログすら出ない。この「無反応で終わる」パターンは、アプリのバグよりも先にウイルス対策ソフトの介入 を疑うべきサインです。
実際、直近の Antigravity のリリースノートにも「ウイルス対策や IDE 起動ボタンの問題を解消した」という趣旨の記述が並びました。つまり公式側も認識している、起動時に踏みやすい落とし穴です。ただ、ここで多くの人がやってしまうのが「とりあえずフォルダごと除外」「隔離属性を全部剥がす」という乱暴な許可です。それはビルド環境に穴を開ける行為でもあります。
ここで残したいのは、誤検知と本物の脅威を切り分け、署名の正当性を確かめてから最小スコープで許可する という順序です。macOS と Windows のそれぞれで、実際に動くコマンドとして書き留めておきます。
なぜ新しい開発ツールほど弾かれるのか
ウイルス対策の検知は、大きく二つの仕組みで動いています。一つは既知のマルウェアのハッシュと照合するシグネチャ検知。もう一つは「見慣れない実行ファイルが、コードを書き換えたり子プロセスを大量に起動したりする」といった振る舞いを見るヒューリスティック検知です。
エージェント型 IDE は、この後者に真正面から引っかかります。Antigravity は起動直後に CLI やサブエージェントのプロセスを立ち上げ、ファイルを書き換え、ときにローカルで実ブラウザを起動します。これは正当な機能ですが、振る舞いの見た目は「未知の実行ファイルがシステムを触り始めた」とほぼ同じです。
さらに、リリース頻度の高さが拍車をかけます。Antigravity は安定版と新機能版を短い間隔で並行公開しており、新しいバイナリほど「評判（レピュテーション）」の蓄積が浅く、Windows の SmartScreen も macOS の Gatekeeper も慎重に振る舞います。新しさそのものが弾かれる理由 になるわけです。
ここで大切なのは、「弾かれた＝誤検知」と即断しないことです。頻度が高いからこそ、本物の改ざんが混じったときに気づけなくなる。だから許可する前に、必ず一段の検証を挟みます。
まず「誤検知」と「本当に危険」を切り分ける
切り分けの起点は、症状から原因の当たりをつけることです。私は毎回この対応表を頭の中でなぞってから手を動かします。
この表の右端が「まず署名を確認」に寄っているのは意図的です。復元や許可はその後でいい。改ざんされたバイナリを許可してしまう事故を防ぐには、正当性の確認が常に先 だからです。
macOS: Gatekeeper と隔離属性を検証してから解除する
macOS では、ダウンロードしたアプリに com.apple.quarantine という拡張属性が付き、初回起動時に Gatekeeper が署名と公証（Notarization）を評価します。無反応で終わるときは、まずこの評価が失敗しているかを見ます。
# 1. 隔離属性が付いているか（付いていれば初回ゲートの対象） xattr -p com.apple.quarantine /Applications/Antigravity.app
# 2. 署名の完全性を検証（改ざん・不完全署名なら非ゼロで失敗する） codesign --verify --deep --strict --verbose=2 /Applications/Antigravity.app
# 3. Gatekeeper の判定を人間可読で確認（rejected の理由まで出る） spctl -a -t exec -vvv /Applications/Antigravity.app
# 4. 誰の署名かを確認（ここが最重要） codesign -dv --verbose=4 /Applications/Antigravity.app 2>&1 | grep -E "Authority|TeamIdentifier" 4 番目の出力に並ぶ Authority と TeamIdentifier が、配布元として公表されている値と一致しているかを必ず目視します。ここが肝心で、codesign --verify が通っても「正しく署名されている」ことしか保証しません。「正しい相手が署名した」かどうかは、署名者の身元を自分の目で照合して初めて言えます 。ダウンロード元の公式ページに記載された Team ID と突き合わせ、一致しないなら、それは誤検知ではなく本物の警告として扱います。
身元が一致し、署名検証も通ったと確認できて初めて、隔離属性を外します。
# アプリ配下の隔離属性を再帰的に除去（検証が済んでから実行する） sudo xattr -dr com.apple.quarantine /Applications/Antigravity.app -dr の r は再帰、d は削除です。アプリバンドルの中には多数の実行ファイルが含まれるため、トップ階層だけ外しても内側のヘルパーで再び弾かれることがあります。だから再帰で一括して外します。逆に言えば、検証していないアプリにこれをかけるのは、Gatekeeper を丸ごと無効化するのと同義 なので、順序を絶対に飛ばさないでください。
Windows: 署名を確かめてから最小スコープで許可する
Windows では、ダウンロードしたファイルに「Zone.Identifier」という代替データストリームが付き、SmartScreen が実行を保留します。加えて Microsoft Defender の振る舞い検知が重なることが多いです。PowerShell を管理者権限で開いて、順に確認します。
# 1. ダウンロード由来のブロックフラグが付いているか Get-Item " $ env: USERPROFILE \Downloads\AntigravitySetup.exe" - Stream Zone.Identifier - ErrorAction SilentlyContinue
# 2. Authenticode 署名の状態を検証（Valid 以外は要注意） Get-AuthenticodeSignature "C:\Program Files\Antigravity\Antigravity.exe" | Format-List Status , StatusMessage , SignerCertificate
# 3. 署名者の Subject を表示（配布元と一致するか照合する） ( Get-AuthenticodeSignature "C:\Program Files\Antigravity\Antigravity.exe" ).SignerCertificate.Subject 2 番目の Status が Valid でなく HashMismatch なら、ファイルが署名後に書き換わっています。これは誤検知ではなく、破損か改ざんのサインです。再ダウンロードから始めてください。Valid かつ 3 番目の Subject が公表された発行元と一致したときだけ、許可に進みます。
# ブロックフラグを外す（インストーラ単体に対して） Unblock-File " $ env: USERPROFILE \Downloads\AntigravitySetup.exe"
# Defender の除外は「フォルダ全体」でなく「プロセス単位」で最小化する Add-MpPreference - ExclusionProcess "Antigravity.exe" 多くの解説が Add-MpPreference -ExclusionPath "C:\Program Files\Antigravity" のようにフォルダごと除外させますが、私はこれを避けています。フォルダ除外は、そのフォルダに後から置かれた別の実行ファイルまで無検査にしてしまう からです。プロセス名単位（-ExclusionProcess）に絞れば、対象の実行ファイルだけを検査対象から外せます。除外は狭ければ狭いほど安全、という原則をここでも守ります。
自分で例外を入れられない企業環境での立ち回り
会社支給のマシンでは、EDR（Endpoint Detection and Response）が集中管理されていて、Add-MpPreference も xattr も権限で弾かれることがあります。この場合に個人の裁量で回避策を探すのは筋が悪い判断です。
代わりに、情報システム部門へ渡す材料を整えます。渡すべきは「動かないので何とかして」という要望ではなく、検証済みの事実 です。具体的には、codesign -dv や Get-AuthenticodeSignature の出力（署名者の身元と検証ステータス）、配布元公式ページの URL、そして「プロセス単位の許可で足りる」という最小スコープの提案。この 3 点が揃っていると、管理者は正当性を自分で再検証したうえで、最小限の例外を安全に入れられます。
私自身、個人開発と並行してアート活動の運用も回している都合で、環境ごとに管理主体が違う端末を触ります。そこで学んだのは、「回避の手順」より「検証の証拠」を持っていくほうが、結局いちばん速く通る ということでした。証拠があれば議論が要件確認に変わり、なければ押し問答になります。
複数マシンで再発させないために検証を1本にまとめる
同じ誤検知に、Mac と Windows と、それぞれ複数台で個別に対処していると、手順がだんだん我流にぶれていきます。私はある時期、3 台の Mac で微妙に違う「隔離解除メモ」を持っていて、片方では署名確認を飛ばしていたことに後で気づきました。危ういのはこの「片方だけ手を抜く」状態です。
対策はシンプルで、検証と解除を 1 本のスクリプトに畳み、検証が通らなければ解除に進まない という制御をコードで強制します。
#!/usr/bin/env bash # verify-then-allow.sh — 署名検証に通った時だけ隔離を外す（macOS） set -euo pipefail
APP = "/Applications/Antigravity.app" EXPECTED_TEAM_ID = "XXXXXXXXXX" # 配布元公式ページで公表された Team ID に置き換える
echo "▶ 署名の完全性を検証中..." codesign --verify --deep --strict " $APP "
echo "▶ 署名者の Team ID を照合中..." ACTUAL = $( codesign -dv --verbose=4 " $APP " 2>&1 | awk -F= '/TeamIdentifier/{print $2}' ) if [ " $ACTUAL " != " $EXPECTED_TEAM_ID " ]; then echo "✗ Team ID 不一致（実際: ${ ACTUAL :- なし}）。誤検知ではなく本物の警告として扱います。" exit 1 fi
echo "▶ Gatekeeper 判定を確認中..." spctl -a -t exec -vv " $APP "
echo "✓ 検証を通過。隔離属性を除去します。" sudo xattr -dr com.apple.quarantine " $APP " echo "✓ 完了。" このスクリプトの本質は、便利さではなく順序の固定化 にあります。set -euo pipefail によって、途中のどれか一つでも失敗すれば以降は実行されません。Team ID が一致しなければ exit 1 で止まり、隔離解除にたどり着けない。つまり「面倒だから確認を飛ばす」という判断の余地を、最初から消しておくわけです。新しいマシンをセットアップするときも、このファイルを 1 つ持ち込むだけで、検証の質が端末間でぶれなくなります。設定同期の考え方は、複数Macでの設定同期の実践メモ と同じ発想です。
EXPECTED_TEAM_ID を実際の値に置き換える一手間だけは自動化しないでください。ここを自動取得にすると、「実際に署名した相手」ではなく「今ダウンロードされているバイナリの主張」を信じることになり、検証の意味が失われます。人間が公式ページと突き合わせて 1 度だけ埋める——この摩擦こそが、このスクリプトの安全性の源です。
つまずいたら、次にやること
もし今まさに起動できずに困っているなら、まず OS を確認して該当セクションのコマンド 1〜4 を順に流し、Authority / Subject が配布元の公表値と一致するかだけを見てください。一致すれば誤検知として安全に許可でき、一致しなければ再ダウンロードに戻る——判断はこの一点に集約されます。
迷ったら、次の 3 つだけを順に踏んでください。
OS を確認し、該当セクションの確認コマンドを 1 から 4 まで順に実行する
Authority（macOS）または Subject（Windows）が、配布元の公表値と一致するかを目視で照合する一致すれば隔離解除・許可へ進み、一致しなければ再ダウンロードからやり直す
起動そのものは通るのに動作が重い、という段階に進んだら、原因は別のところにあります。その場合はAntigravityの動作が重いときの切り分け や、CLIの起動レイテンシをhyperfineで測る方法 のほうが役に立つはずです。
ウイルス対策との付き合いは、開発ツールを速く回すほど避けて通れなくなります。私自身まだ端末ごとに小さくつまずくことがありますが、「検証してから許可する」という順序さえ崩さなければ、少なくとも自分の手で穴を開けることはありません。お読みいただきありがとうございました。