Antigravity × Warp Terminal で開発フローを一体運用する — エディタとAIターミナルを往復しないための実践ガイド

「Antigravity のエディタ内にいるときは AI と気持ちよく対話できているのに、ターミナルに降りた瞬間、別人格の自分に戻ってしまう」— Antigravity を個人開発で数ヶ月使ってきて、一番もったいなかったのはこの時間でした。コマンドをコピーしてはエディタに戻り、エラーを手で貼り付けてまた降りる。往復だけで1日30分以上溶けていたと気づいたのが、今回の環境構築のきっかけです。

Antigravity と Warp を組み合わせる理由

Antigravity の強みは、プロジェクト全体を俯瞰しながらコードを書けることです。一方で、ビルド・デプロイ・ログ確認といった「シェルで完結する作業」に入ると、どうしても一度エディタの外に出る必要があります。そのときに使うターミナルが普通のシェルだと、エディタで積み上げた文脈がそこで途切れてしまいます。

Warp はコマンドごとに入出力をブロックで保持し、そのブロックに対して AI に質問できる作りになっています。つまり「エラーログを選択して『これを直すためのパッチ案を出して』と聞く」ような操作が、ターミナルに居たままできます。この性質が Antigravity 側の AI と相性が良く、エディタとシェルのどちらに居ても同じ粒度で AI と会話できる環境が作れます。

私は Cursor や VS Code + 標準ターミナルの組み合わせも試しましたが、ターミナル内で AI にエラー要約を任せられる点と、コマンド履歴がコンテキスト付きで残る点で、Warp の体験は頭ひとつ抜けていると感じました。

初期セットアップ — Antigravity から Warp を既定ターミナルにする

まずは Antigravity の統合ターミナルが Warp を起動するように設定します。Antigravity の設定画面から Terminal: External を検索し、外部ターミナルの種類を Warp に切り替えるだけです。

// Antigravity / settings.json (User)
{
  // 統合ターミナルのシェルは Warp に任せる
  "terminal.external.osxExec": "Warp.app",
  "terminal.integrated.defaultProfile.osx": "warp",
  // プロジェクトのルートで起動したい
  "terminal.integrated.cwd": "${workspaceFolder}",
  // Warp のブロック ID を外部リンクで開けるよう許可
  "window.openFilesInNewWindow": "on"
}

ポイントは cwd をワークスペースルートに固定することです。Warp は warp:// スキーマで特定のブロックに直接飛ぶリンクを生成できるため、プロジェクトを跨いで起動するとこのリンクが壊れます。

macOS 以外の環境では osxExec を linuxExec / windowsExec に読み替えてください。Warp は2026年時点で macOS 以外でもネイティブ版が提供されていますが、ショートカットの挙動はプラットフォームによって差があるので、まずは Cmd+J / Ctrl+J での起動だけ確認しておけば十分です。

共通の「文脈」を作る — プロジェクト直下に prompt ファイルを置く

エディタ側とターミナル側で AI に与える前提を揃えるために、プロジェクト直下に .ai/context.md を置いて両方から参照する運用にしています。私は以下のような最小構成にしています。

<\!-- .ai/context.md -->
# プロジェクトの前提
 
- フレームワーク: Next.js 15 (App Router) + TypeScript
- スタイル: Tailwind CSS v4、ダークモード既定
- 決済: Stripe (price_id は src/config/pricing.ts に集約)
- デプロイ先: Cloudflare Workers (wrangler)
- テスト: Vitest、E2E は Playwright
 
# コーディング規約
 
- 型は any を避ける。`unknown` → 型ガード。
- 例外は握りつぶさず、上位に `Result` 型で返す。
- console.log はビルドで落とす。ログは src/lib/logger.ts を使う。

Antigravity 側では、この context.md を Antigravity のカスタムコマンド運用ガイドで紹介されているルールファイルから参照します。Warp 側では、Warp の AI コマンド欄で use .ai/context.md as background のように明示すると、同じ前提のもとで応答が返ってきます。

完全に同じ応答にはなりませんが、「型に厳しいプロジェクトである」「決済周りは pricing.ts を見ろ」といった大前提はブレなくなります。地味ですが、この一歩で AI への質問文が毎回半分くらい短くなりました。

現場で効いた3つの運用パターン

文脈を揃えたうえで、日々の開発で特に効果があったのは次の3つの使い分けです。

一つめは「ターミナルのエラーをその場で要約→エディタで修正」です。pnpm build が失敗したら、Warp のブロックをそのまま選択して AI に「根本原因を日本語で3行」と頼みます。返ってきた要約を Antigravity の Inline Chat に貼り付け、関連ファイルのパッチを作ってもらいます。Antigravity の Inline Chat 活用ガイドの使い方を押さえていれば、ここは数十秒で済みます。

二つめは「シェル芸を AI に下書きさせる」使い方です。Warp のコマンドパレットで # 今日の日付で始まるログファイルを 7 日分残して古いものを gzip のように自然文を打つと、そのままコマンド候補が出ます。Antigravity 側に下書きを貼り付け、scripts/ 配下の npm スクリプトに昇格させるところまで一気に書ききれます。

三つめは「長時間ジョブの監視を Warp 任せにする」使い方です。Cloudflare Workers のビルドや動画の書き出しなど、数十分かかる処理は Warp で走らせ、エディタでは別作業を進めます。Warp のブロックには完了通知を仕込めるので、Antigravity の集中を切らしません。Antigravity × ターミナルワークフロー自動化ガイドと組み合わせると、通知とログ整形まで一貫して自動化できます。

ハマりやすいポイントと対処

最初にやっておかないと後から面倒なのは、この3つです。

シェル履歴の暗号化: Warp はクラウド同期が既定で有効です。仕事のコマンドが個人アカウントに残るのを避けたい場合は、設定から Command History → Local only に切り替えておきます。
Antigravity のファイル監視と Warp の cd の相性: Warp で別プロジェクトに cd しても、Antigravity のワークスペースは動きません。プロジェクトを切り替えるときは Antigravity の File → Open Folder から開き直すのが結果として一番早いです。
AI の情報源の食い違い: Warp の AI はコマンド履歴を強く参照するため、過去に失敗したコマンドを学習して似た提案を繰り返すことがあります。明らかに筋が悪いと感じたら、そのブロックを Delete Block で消してから聞き直すと提案が変わります。

ツールに依存しない「AI との対話の設計」が丁寧に整理されていて、Warp や Antigravity を使いこなすうえでの下地として読み返しています。

小さな実例 — 失敗するテストを1行で直した往復

ここまでの話を具体的にするために、先週私が実際に通した往復を一つ紹介します。英雄的な話ではありません。むしろこの「地味なやり取り」を何度も素早く回せることこそ、この環境の価値だと思っています。

発端は、CI でだけ落ちる Vitest のテストでした。Warp でローカルでも再現させて、失敗ブロックを選択します。

$ pnpm test src/lib/pricing.test.ts
 
 FAIL  src/lib/pricing.test.ts > resolves the JP price for an article
AssertionError: expected 250 to be 25000
  Expected: 25000
  Received: 250

Warp のブロックに対して「Stripe は JPY の金額をどの単位で受け取る？」と聞くと、2行で返事が来ます。JPY はゼロ小数通貨なので、実際の円の額をそのまま渡す、という仕様です。テストのほうが USD の例から機械的にコピーされていて、100倍の値になっていたのが原因でした。

そのまま Antigravity に戻り、Inline Chat にその2行をそのまま貼り付けて「振る舞いを変えずに最小の修正を」とお願いします。差分は1行とコメント1行。3分かからずに緑に戻りました。同じ修正を単独のターミナルだけでやろうとすると、Stripe のドキュメントをブラウザで検索している間にゼロ小数通貨の記述を見落とし、USD 側を壊す書き換えを入れてしまう、というのを以前やらかしています。

この話のポイントは「AI がバグを直してくれた」ではなく、「ターミナルの AI とエディタの AI が、同じプロジェクト観で動いていた」ことです。どちらも基礎の再導出に時間を使わずに済むので、体感時間が目に見えて縮みます。

向いている作業と向いていない作業

2ヶ月ほど運用してみて、この環境が本領を発揮するのは、日々の短いコード&デバッグのループでした。小さなリファクタリング、ログの一次分類、新規ファイルの雛形作り、シェルパイプラインの下書き — このあたりは共有文脈とターミナル側の AI があるかないかで、摩擦の量がまったく違います。

逆に、システム全体の設計を考えるときは、相変わらずエディタを閉じて紙やホワイトボードに戻ります。AI はローカルな一手には強いですが、構造のトレードオフを見渡す役割は、いまのところ人間の側に残しておいたほうが安全です。「スキーマを設計して」と丸投げすると、もっともらしく見えて事業要件に合わない案が混じってきます。

もう一つの境界は、規制の厳しい領域や顧客データに触れる作業です。個人開発と受託・事業の案件は環境を完全に分け、先ほどの「Local only」の履歴設定は必ず最初にオンにしておきます。Warp のクラウド機能は便利ですが、何がどこに同期されているかを自分で説明できる状態にしておくのが最低ラインです。

全体を振り返って

今日から試すなら、まず .ai/context.md を1ファイルだけ用意して、Antigravity と Warp の両方でそのファイルを参照させるところから始めてみてください。プロンプトの前置きが短くなるだけで、AI が返してくれるコードの筋が目に見えて安定します。エディタとターミナルを往復しても「同じ人に相談している」感覚が保てると、1日の集中力の残り方がまったく違ってきます。