開発者ツールの赤い一行、TypeError: Failed to fetch。個人開発で API を呼ぶ画面を作っていると、何度も出会う文言です。
サーバーは動いているはずなのに、画面は空のまま。コードを疑い、キャッシュを疑い、気づけば時間だけが過ぎている——この種のエラーは、原因を一つに絞りにくいところが厄介です。
この「Failed to fetch」という文言は、ブラウザが「通信そのものが成立しなかった」としか教えてくれないときの、いわば総称です。Antigravity の公式フォーラムにも、同じ文言で困っている方の報告が上がっています（Failed to Fetch エラーのスレッド）。
ここでお断りしておきます。私の手元では、Antigravity 側のこの表示を意図して再現できておりません。したがって「これが原因です」とは書けません。代わりに、この文言が出たときに私が必ず同じ順番で見ている3か所と、その確かめ方を書き残します。
最初にお伝えしたいのは、設定を触る前に見る順番です
エラーが出ると、つい設定画面を開いて項目を変えたくなります。ただ、通信の失敗は設定以外の場所で起きていることのほうが多いのです。
直す前に、届くかどうかを確かめます。 この一文を、私は切り分けの線引きにしています。
見る順番は次のとおりです。
- 通信の届き先に、そもそも手元のマシンから届くか
- 届くなら、認証（サインイン）が切れていないか
- それでも駄目なら、プロキシや VPN が間に挟まっていないか
1つ目: 届き先に、手元から届くか
最初に、Antigravity を介さずターミナルから届くかを見ます。ここで届かなければ、原因は Antigravity の外にあります。
# 何を解決するか: 「ネットワークそのものが死んでいる」のか「特定の宛先だけ駄目」なのかを分ける
curl -sS -o /dev/null -w "status=%{http_code} time=%{time_total}s\n" https://www.google.com
curl -sS -o /dev/null -w "status=%{http_code} time=%{time_total}s\n" https://discuss.ai.google.devstatus=200 が返れば、少なくとも手元のネットワークは外に出られています。ここで Could not resolve host が出たら名前解決（DNS）の問題で、Operation timed out なら経路の途中で止まっています。
なぜ宛先を2つ使うかというと、片方だけ失敗したときに「特定のサイトだけ遮断されている」と読めるからです。
| curl の結果 | 読み方 | 次の一手 |
|---|---|---|
| どちらも 200 | 手元のネットワークは外へ出られる | 2つ目（認証）へ進む |
| Could not resolve host | 名前解決の失敗（DNS） | Wi-Fi の切り替え、DNS 設定の見直し |
| Operation timed out | 経路の途中で止まっている | VPN・社内ネットワーク・ルーターを疑う |
| 片方だけ失敗 | 特定の宛先だけ遮断されている可能性 | 3つ目（プロキシ）へ進む |
2つ目: 認証が切れていないか
通信は届いているのに失敗するとき、次に疑うのはサインインの状態です。有効期限が切れた状態で API を呼ぶと、サーバーは応答を返していても、クライアント側では取得失敗に見えることがあります。
私は、ここでは設定を変えず、まずサインアウトとサインインをやり直します。手元でできる確認として、これ以上に軽いものがないからです。やり直して直るなら、原因は認証でした。直らないなら、3つ目へ進みます。
なお、サインインの画面の出し方や項目名は版によって変わります。画面名を暗記するより、「いったん切って、入り直す」という動作で覚えておくほうが長持ちします。
3つ目: プロキシや VPN が間に挟まっていないか
会社や学校のネットワーク、あるいは VPN を使っていると、通信が途中のプロキシを通ります。ブラウザは使えるのに特定のアプリだけ失敗する、という状況の典型です。
# 何を解決するか: 環境変数にプロキシが設定されていないかを見る
env | grep -i proxy
# macOS: システムのプロキシ設定を確認する
scutil --proxy | head -20何も出なければ、環境変数経由のプロキシはありません。何か出たなら、その宛先が実際に使えるかを curl に -x を付けて試します。
Antigravity は VS Code 系のエディタなので、プロキシを設定する項目（http.proxy など）が設定にあるはずです。ただ、この項目名は私の手元でプロキシ環境を作って確かめたわけではありません。設定画面で「proxy」と検索して、実際に出てくる項目を確認していただければ幸いです。
結果の読み方を、一枚にまとめます
| 状況 | 原因の見立て | やること |
|---|---|---|
| curl が失敗する | ネットワーク・DNS・経路 | Antigravity の設定は触らず、回線を直す |
| curl は通る、再サインインで直る | 認証の期限切れ | 入り直して様子を見る |
| curl は通る、再サインインでも直らない | プロキシ・VPN・ファイアウォール | proxy の値を確認、VPN を切って再試行 |
| すべて問題ないのに出る | サービス側の一時的な不調の可能性 | 時間を置く、フォーラムで同じ報告を探す |
最後の行は、正直に申し上げると「切り分けた結果、自分の側では何も見つからなかった」という状態です。私自身も、確かめ終えたあとに時間を置いたら直っていた、ということがあります。切り分けを終えていれば、待つことにも根拠が持てるのです。
手元でできる、次のアクション
まず、ターミナルで上の curl を2本だけ実行してみてください。それだけで、原因が Antigravity の内側か外側かが分かれます。
私自身の個人開発でも、エラー文言が同じなのに原因は毎回違いました。だからこそ、文言ではなく順番を決めておくことが、いちばん効いているのだと思います。この3か所の順番が、同じ場面に立った方の時間を少しでも減らせましたら幸いです。