✦ Tips & 活用術/2026-07-07上級

Antigravityの起動がウイルス対策に弾かれたら、署名を検証してから許可する

Antigravityデスクトップアプリの起動がウイルス対策に阻まれたとき、誤検知と本物の脅威を切り分ける方法を解説します。macOSのGatekeeperとWindows Defenderで署名を検証してから、最小スコープで許可リスト化する手順をコード付きでまとめました。

Antigravity³¹⁴ ウイルス対策コード署名² Gatekeeper Windows Defender セキュリティ¹¹

✦ プレミアム記事

新しいバージョンの Antigravity を入れ直した翌朝、デスクトップアイコンをダブルクリックしても、数秒だけ砂時計が出て、そのまま何も起きませんでした。クラッシュログも残っていません。エラーダイアログすら出ない。この「無反応で終わる」パターンは、アプリのバグよりも先にウイルス対策ソフトの介入を疑うべきサインです。

実際、直近の Antigravity のリリースノートにも「ウイルス対策や IDE 起動ボタンの問題を解消した」という趣旨の記述が並びました。つまり公式側も認識している、起動時に踏みやすい落とし穴です。ただ、ここで多くの人がやってしまうのが「とりあえずフォルダごと除外」「隔離属性を全部剥がす」という乱暴な許可です。それはビルド環境に穴を開ける行為でもあります。

ここで残したいのは、誤検知と本物の脅威を切り分け、署名の正当性を確かめてから最小スコープで許可するという順序です。macOS と Windows のそれぞれで、実際に動くコマンドとして書き留めておきます。

なぜ新しい開発ツールほど弾かれるのか

ウイルス対策の検知は、大きく二つの仕組みで動いています。一つは既知のマルウェアのハッシュと照合するシグネチャ検知。もう一つは「見慣れない実行ファイルが、コードを書き換えたり子プロセスを大量に起動したりする」といった振る舞いを見るヒューリスティック検知です。

エージェント型 IDE は、この後者に真正面から引っかかります。Antigravity は起動直後に CLI やサブエージェントのプロセスを立ち上げ、ファイルを書き換え、ときにローカルで実ブラウザを起動します。これは正当な機能ですが、振る舞いの見た目は「未知の実行ファイルがシステムを触り始めた」とほぼ同じです。

さらに、リリース頻度の高さが拍車をかけます。Antigravity は安定版と新機能版を短い間隔で並行公開しており、新しいバイナリほど「評判（レピュテーション）」の蓄積が浅く、Windows の SmartScreen も macOS の Gatekeeper も慎重に振る舞います。新しさそのものが弾かれる理由になるわけです。

ここで大切なのは、「弾かれた＝誤検知」と即断しないことです。頻度が高いからこそ、本物の改ざんが混じったときに気づけなくなる。だから許可する前に、必ず一段の検証を挟みます。

まず「誤検知」と「本当に危険」を切り分ける

切り分けの起点は、症状から原因の当たりをつけることです。私は毎回この対応表を頭の中でなぞってから手を動かします。

症状	疑うべき原因	最初の一手
ダブルクリックしても無反応・ログも残らない	OS の実行ゲート（Gatekeeper / SmartScreen）が黙ってブロック	署名と隔離属性を確認
起動途中で「ファイルが見つからない」と落ちる	ウイルス対策が実行ファイルの一部を隔離フォルダへ移動	検疫ログを確認し復元
起動はするがサブエージェント/CLI だけ動かない	子プロセスの生成を EDR がブロック	プロセス単位の許可を検討
数日前まで動いていたのに突然弾かれる	定義ファイル更新で振る舞い検知が過敏化	ベンダーの誤検知報告と署名確認

この表の右端が「まず署名を確認」に寄っているのは意図的です。復元や許可はその後でいい。改ざんされたバイナリを許可してしまう事故を防ぐには、正当性の確認が常に先だからです。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦起動ボタンを押しても無反応なとき、原因がアプリ側かウイルス対策側かを数分で切り分けられるようになる

✦「隔離を全部解除」で済ませず、コード署名の正当性を確かめてから許可する検証フローを、Windowsとmacの両方で実行できる

✦複数マシンで同じ誤検知に何度も対処してきた無駄を、1本の検証スクリプトに畳んで再発を止められる

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

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 つだけを順に踏んでください。