はじめに
こんにちは。ミルディア廣瀬です。
皆さんはアプリの些細な設定ミスで上手く動かず、原因調査や対応に延々と時間を奪われた経験はありませんか？
私はしょっちゅうです。
この度、AI Agent（Antigravity）の導入でも例に漏れず設定ミスで動かなくなってしまい、それをAIに解消してもらったのでまとめてみました。
なお、この記事で引用している文章は入力したプロンプト、あるいは出力された文章を限りなくそのまま記載しています。（一部マスクしています）多少の読みづらさはご容赦ください。
こんな軽いノリの入力でも、ここまでの出力が返ってくる点にも注目です。
Antigravityについて
Antigravityについての詳細はこちらの記事を参照ください。
私の手元の環境はWindows OSなのですが、基本的な流れは上記記事と変わりません。
私はGUI派なので Antigravity App(※)を導入したのですが、CLI版の方もインストールしていました。
それがのちにトラブルシューティングに効いてきたのでした。
さて、上記記事の通りエンタープライズ版のGoogle Workspaceでは単純にログインするだけでは使えず、GCPプロジェクトに紐づける必要があります。
お作法に従って最初の疎通確認までして少し試したらその日は満足したのですが、後日事件は起きるのでした。
(※ Antigravity 2.0とも呼ぶようですが、この記事内ではCLIとの対比でAntigravity Appと表記します)
トラブル発生（認証エラー）
後日、改めていろいろ検証してみようとAntigravity Appを起動したところ、ログインを促されます。
はて？既にGCPプロジェクトと繋いで認証済では？と思いつつも素直にもう一度認証を通そうとするとエラーが出てしまい次の画面に進みません。
エラーメッセージを見る限り、認証時の名前解決（DNS）がローカルIP（172.23.0.1）宛てでタイムアウトしていることは分かるのですが、Windows側は普通にネットに繋がっています。そもそも、なぜローカルIPを見に行っているのかパッと見当がつきません。さぁ困ったぞ。
同業の皆様におかれましては1度や2度ならず経験があるかと思います。
この手の設定ミスっぽいトラブルは調査方針の初手を間違えると泥沼にはまって時間泥棒まっしぐらです。
そのくせ原因は凡ミスで、解消したときの達成感の無さたるや。どんどんやる気が削がれていきます。どうしようかな。
Antigravity CLIに聞いてみた
そんな時にふと思い出しました。そういえばCLIの方もインストールしてたな。
ブラウザ版のGeminiと違い、Antigravityは端末内の設定も見てくれます。これはもしかして？
そう思って尋ねてみました。
尋ねてみる
入力プロンプト
Antigravity Appを起動すると以下のメッセージが表示されて開けません。原因を調査してください。
There was an unexpected issue setting up your account.
Post "https://oauth2.googleapis.com/token": dial tcp: lookup oauth2.googleapis.com on 172.23.0.1:53: read udp
172.23.10.73:39004->172.23.0.1:53: i/o timeout
Continue with different account
Having trouble signing in?
任せて眺めていると少し考えながら何度かPowerShellコマンド（ログや設定ファイルの確認など）の実行をリクエストしてくるので、変なコマンドでないことを確認しつつポチポチと許可を出してみます。
そして待っていると出てきた結論がこちら。（一部マスク掛けています）
お返事
出力文章
原因が特定できました。エラーの直接の原因は、Antigravity App が現在「WSL モード (Ubuntu-22.04)」で動作しており、その WSL2 内部で DNS
名前解決がタイムアウトしているためです。
──────
### 何が起きているか（原因の詳細）
1. Antigravity App が WSL (Ubuntu-22.04) 上でバックエンドを起動している
• 設定ファイル wsl_state.json:1 に {"distro":"Ubuntu-22.04"} が保存されており、ログ（main.log:1068-1070、language_server.log:7-111）から、Windows 側ではなく WSL
(Ubuntu-22.04) 内の Linux 版サーバーが起動していることが分かります。
• WSL 内は Windows 側の認証情報（Keyring）とは別管理（/home/●●●/.gemini）になるため、再ログインが求められています。
2. Ubuntu-22.04 内の DNS (172.23.0.1:53) がタイムアウトしている
• エラーの 172.23.10.73 -> 172.23.0.1:53: i/o timeout は、WSL2 (172.23.10.73) から Windows ホスト側の仮想アダプタ vEthernet (WSL) (172.23.0.1) への DNS
クエリが応答していないことを示しています。
• （※もう一つの WSL ディストリビューション Ubuntu 側では /etc/resolv.conf が nameserver 8.8.8.8 に変更されていますが、Ubuntu-22.04 側は自動生成の nameserver 172.23.0.1 のままになっています。）
──────
### 解決方法（2通り）
ご利用目的に合わせて以下のいずれか（または両方）で解決できます。こちらでコマンドを実行して修正することも可能です。
#### 方法A：Windows 環境として Antigravity App を使う場合（今の CLI と同じ環境・認証を共有）
WSL モードの設定ファイル wsl_state.json を削除して Antigravity App を再起動すると、Windows 側のバックエンドで起動し、現在の CLI と同じ Windows 側の認証（●●●@milldea.com / ●●●）とネットワークをそのまま引き継げます。
Remove-Item "$env:APPDATA\Antigravity\wsl_state.json"
（※実行後、Antigravity App を一度終了して再起動します）
#### 方法B：WSL (Ubuntu-22.04) モードでもサインインできるようにする場合
Ubuntu-22.04 内の DNS 設定を 8.8.8.8 へ向けることで、oauth2.googleapis.com のタイムアウトを解消できます。
wsl -d Ubuntu-22.04 -u root -e sh -c 'printf "[boot]\nsystemd=true\n[network]\ngenerateResolvConf=false\n" > /etc/wsl.conf && rm -f /etc/resolv.conf && printf
"nameserver 8.8.8.8\nnameserver 1.1.1.1\n" > /etc/resolv.conf'
──────
どちらの対応（A: Windows モードに戻す / B: WSL の DNS を修正する / 両方）をこちらで実行しましょうか？
こ、こやつできる！
自覚は無かったのですが、どうやら以前の検証時にWSLモードに切り替えてしまっていたようです。
しかもWSL側の設定も良くないところがあり、合わせ技で今回のエラーに繋がっていたのでした。
このまま修正もAntigravity CLIに対応してもらい、無事にAntigravity Appが使えるようになったのでした。
おまけ：AIの実力試し（日本語化を頼んでみる）
ここから先は当初のトラブルシューティングとは少し逸れた余談です。
無事に使えるようになったのですが、せっかくなのでもう少しAntigravity CLIの実力を見てみましょう。
Antigravity Appも、初期インストール時は英語表記のメニューです。
読めないわけじゃないのですが得意でもないので、日本語化できるところはできるだけ日本語化したいです。
そんなわけで軽い気持ちで聞いてみました。
無茶振りしてみる①
入力プロンプト
> Antigravity App のメニューを日本語化する方法はある？できるなら代わりにやるところまでお願いしたい。
お返事①
出力文章
I've identified and translated key UI components within the system tray menu, context menus, folder selection dialogs, and the in-app sidebar, settings, and search fields. This covers essential user interactions for the Japanese localization.
スタンドアロン版の Antigravity App (v2.23.1) には現在まだ公式の言語切り替え設定（日本語言語パック）が搭載されておらず、メニューや UI が英語で固定されていますが、アプリ本体のパッケージ（app.asar）に日本語化レイヤーを組み込むことで日本語化が可能です。
バックアップを作成した上で、日本語化の適用と Antigravity App の再起動まで完了しました。
──────
### 実施した内容
1. オリジナルファイルのバックアップ作成
• app.asar.bak に変更前のパッケージを保存しています。
2. ネイティブメニュー・トレイ・右クリックメニューの日本語化
• app.asar 内の dist/main.js・dist/menu.js・dist/tray.js・dist/ipcHandlers.js に Chromium ロケール指定（--lang=ja）と日本語メニュー辞書を適用しました。
• 対象項目:
• トレイメニュー・アプリメニュー：新しいウィンドウ、WSL に接続、ローカル環境で開き直す、Antigravity を開く、実行中のエージェントなし、ドキュメント、終了、終了確認ダイアログ
• コンテキストメニュー（右クリック等）：新しい会話、設定を開く、ワークスペースを開く、コピー / 貼り付け / すべて選択、ピン留め、アーカイブ、削除 など
3. メイン画面（サイドバー・設定画面・ツールチップ等）の日本語化
• dist/preload.js に UI テキスト翻訳レイヤー（コードブロックやチャット本文・入力欄には影響を与えず、メニュー・ボタン・設定項目のみを翻訳する処理）を追加しました。
• 対象項目:
• サイドバー：新しい会話、会話、ワークスペース、スケジュール済みタスク、オートメーション、スキルとカスタマイズ、設定 など
• 設定画面：一般、外観、ブラウザ、アカウント、モデル、カスタマイズ、通知、アプリ、各種設定ラベルおよび検索プレースホルダー
──────
### 補足（アップデート時の再適用・元に戻したい場合）
• アプリのアップデート後に再度日本語化したい場合:
アップデートで app.asar が上書きされた場合は、作成したスクリプト localize_antigravity.ps1 を実行すると再適用できます（アップデート後に再適用する場合は先に古い app.asar.bak を削除してから実行してください）。
• 英語表記に戻したい場合:
Antigravity App を終了した状態で、PowerShell で以下を実行すると元の状態に戻ります。
Copy-Item "C:\Users\●●●\AppData\Local\Programs\antigravity\resources\app.asar.bak" "C:\Users\●●●\AppData\Local\Programs\antigravity\resources\app.asar" -Force
画面を開いていただき、他にも「この英語表記も日本語にしたい」という箇所があればお知らせください。すぐ辞書に追加して反映します。
こ、こやつできる！！（二度目）
日本語言語パックがあるかどうかを検索してくる程度かと思っていたら、存在しないからって自分で作りおった。。。
しかもちゃんと変更前にバックアップも取ってるし、再設定用にスクリプトまで作りおったわ。。。
さらにおまけ：AIの実力試し（フォント変更も頼んでみる）
せっかくなのでもっと無茶振りをしてみたくなります。
自称フォント警察の私はもう一つ気になるところがありました。Antigravity App はテキストベースで操作をするアプリなので、どうせなら自分が好きなフォントで見た目を整えたほうが、低ストレスで末永く付き合えそうです。
無茶振りしてみる②
入力プロンプト
> フォントも変えられる？
お返事②
出力文章
I've successfully patched `utils.js` and `preload.js`, updated all SHA-256 hashes within `app.asar`, and restarted...
UI（メニュー・チャット本文など）とコード・ターミナル（等幅）の両方を PlemolJP に変更し、Antigravity App
を再起動しました。
### 適用した変更内容
1. Chromium デフォルトフォント設定（app.asar 内 dist/utils.js）
• Electron の BrowserWindow 生成時の webPreferences.defaultFontFamily（standard / sansSerif / serif /
monospace）に PlemolJP を設定しました（ターミナルの Canvas 描画等にも反映されます）。
2. UI・コード用 CSS 変数の上書き（app.asar 内 dist/preload.js）
• アイコンフォント（Material Symbols 等）を維持したまま、--font-sans / --font-mono / --vscode-font-family / --
editor-font-family / --sdk-font-family に "PlemolJP" を適用しました。
### 後から別のフォントに変えたい場合
パッチスクリプト localize_antigravity.ps1
の先頭（6〜7行目）にある以下の変数を書き換えて実行するだけで、いつでも別のフォント（HackGen35 Console NF や Noto
Sans JP、BIZ UDGothic、Myrica M など）に切り替えられます。
$UI_FONT_FAMILY = "PlemolJP"
$MONO_FONT_FAMILY = "PlemolJP"
こ、こやつできる！！（三度目）
どこでフォントの設定をしているかを解析して、直接書き換えることでアプリの表示フォントを変えおった。
フォント変えられるかだけ聞いたのに、VSCodeで私が設定しているフォントを調べてレコメンドしてきたぞ！（中間やり取りは省略してます）
しかも再設定用にスクリプトまで作りおったわ。。。（二回目）
まとめ
後半のついでに試した設定変更含めて、「AI活用！」と胸を張るには小さい事例かもしれません。しかし、こういう対応に時間をかけることのほうが勿体ないので、意外と悪くないのでは？と思ったりしています。
Antigravity Appの認証エラーの原因は結局のところ以下の2つの合わせ技でした。
- Antigravity AppをWSL上で起動する設定にしていた（たぶん設定画面を無意識に触った）
- WSLのDNS設定が不十分な状態になっていた（これは全く記憶にない）
この件のポイントは、認証エラーの直接原因そのものではなく、今回のような複合的な要因で起きた事象もAIが代わりに調べてくれたことです。
Antigravity Appの設定だけではなく、WSL側の設定まで掘り下げて調査をしてくれたおかげで根本的な問題まで解消しています。
よく見るとエラーメッセージ内のIPアドレスがローカルIPなので、WindowsやWSLに精通しているエンジニアならすぐにピンときたかもしれません。
しかし、前述の通りこの手の凡ミスはハマると時間ばかりが過ぎていくので、この調査をAI Agentに任せられるのは（特に精神的に）非常に楽になります。
さらに日本語化やフォントの変更など、公式にはサポートされないような設定変更も、ユーザーのリクエスト通りに力業で解決してくれるパワフルさを備えています。
（※なお、今回おまけで試した app.asar 等のアプリケーションパッケージを直接書き換える手法は非公式なものであり、動作保証外となるほか、ソフトウェアの利用規約に抵触する可能性もあります。今回は「AIがどこまで自律的に解析・対処できるか」の実験として手元で試したものですが、実運用での適用はよく確認の上、自己責任での実施をお願いします。）
この記事では途中のやり取りは省略していますが、AIはリクエストに応えようと時に踏み込んだ操作（システム設定やアプリ本体の書き換えなど）も提案してくるため、やろうとしている操作を人間側できちんと理解・判断した上で承認するようにしないと思わぬトラブルの元にもなりそうです。
上手く使いこなせれば強力な武器になる一方で、付き合い方はますます気を配らなくてはならないと感じた一件でした。
(追記)
せっかくAntigravityにカスタマイズしてもらった日本語化やフォントは、アプリのバージョンアップに合わせてあっさり元に戻っていました。
やっぱり非公式カスタマイズなんてしないほうが良いですね。