ANTIGRAVITY LABEN
記事一覧/Editor View
Editor View/2026-06-27中級

Antigravity 2.0 で IDE とエージェントが別アプリになって最初に困ったこと

Antigravity 2.0 のモジュラー構成で IDE とチャット型エージェントが2つのアプリに分かれました。両者の見ているファイル状態がずれて混乱した実体験と、ソース・オブ・トゥルースを一本化する運用をまとめます。

Antigravity 2.07エージェント45ワークフロー18個人開発77

週末にアプリの細かな修正をまとめて片付けようとして、Antigravity 2.0 で同じ変更を二度書く羽目になりました。原因は単純で、IDE 側で開いて編集途中だったファイルを、別アプリになったエージェントに「直しておいて」と渡してしまったことです。エージェントはディスク上の古い内容を見て差分を作り、私は IDE の編集中バッファを見ている。二人で別の地図を広げていたわけです。

2.0 のモジュラー構成は、コードを書く IDE と、タスクを任せるチャット型のエージェント・インターフェイスを別々のアプリに分けました。書く作業と任せる作業を、それぞれに最適化された画面で扱えるのは確かに快適です。ただ、この分離は「両方のアプリが同じプロジェクトを見ているのに、見ているタイミングが違うことがある」という、これまで意識しなくてよかった落とし穴を連れてきます。

2つのアプリは「同じファイル」を別の瞬間に見ている

単一アプリだった頃は、編集中のバッファとエージェントが触る対象が同じプロセス内にありました。未保存の変更があっても、AI への指示はその場の状態を前提に動きます。

2.0 で IDE とエージェントが別プロセス・別アプリになると、両者をつなぐのは基本的に「ディスク上のファイル」です。つまりエージェントが読むのは、あなたが最後に保存した時点の内容になります。IDE 側で保存していない編集は、エージェントからは存在しないのと同じです。

私がはまったのはまさにここでした。IDE で関数を半分書き換え、保存しないままエージェント・アプリに切り替えて「この関数のエラー処理を足して」と頼む。エージェントは保存済みの旧バージョンにエラー処理を足した差分を提案し、それを適用すると、IDE で書いていた未保存の変更と衝突します。どちらが正かを人間が手で判定する羽目になり、結局二度手間でした。

ソース・オブ・トゥルースを「ディスク」に固定する

対処そのものは拍子抜けするほど地味です。ディスク上のファイルを唯一の正とみなし、アプリ間で作業を渡すときは必ず保存を挟む。これだけで、上の混乱はほぼ消えました。

私が実際に守っているルールは次の3つです。

  1. エージェントに渡す前に、IDE 側を必ず保存する。編集中のファイルだけでなく、関連して触ったファイルもまとめて保存します。全ファイル保存を渡し際の儀式にしておくと、考えなくても手が動きます。
  2. エージェントが書き換えている最中は、IDE 側で同じファイルを触らない。並行して両方から同じファイルを編集すると、保存のたびに新しい不整合が生まれます。渡したら、戻ってくるまでは IDE 側では別のファイルに移ります。
  3. エージェントの差分を取り込んだら、IDE 側でディスクから読み直す。多くのエディタは外部変更を自動で検知してリロードを促しますが、未保存の変更があると黙って握り潰すことがあります。取り込み後はいったんファイルを閉じて開き直すくらいでちょうどよいです。

この「保存を境界にする」発想は、複数のサイトやアプリを一人で並行運用していると、ことのほか効きます。私自身、Dolice Labs として4つのブログのリポジトリを個人開発で行き来しているので、どのアプリがいまそのファイルの正本を握っているのかが曖昧になると、被害がそのまま複数プロジェクトに広がります。アプリをまたぐたびに保存で「ここまでが確定」と線を引くと、頭の中の状態とディスクの状態が一致して、混乱の入り込む隙がなくなります。

「書く」と「任せる」の往復を減らす設計

保存規律でぶつかり事故は防げますが、そもそもアプリ間を細かく往復しないほうが楽です。分離されたからこそ、往復の回数を意識的に減らす設計が効きます。

私の場合は、まとまった単位で渡すようにしています。「この一行を直して」ではなく、「この機能のこのファイル群を、こういう方針で直して」とまとめてエージェントに任せ、その間は IDE 側で別の独立したファイルを手で書く。書く作業と任せる作業が別のファイルに向いていれば、保存衝突は起きません。分離されたアプリ構成は、この「人間とエージェントの担当範囲を空間的に分ける」運用と相性が良いのだと思います。

逆に、一行ずつ確認しながら直したい繊細な変更は、わざわざエージェント・アプリに渡さず IDE 内のインライン編集で完結させます。アプリが分かれたからといって、すべてをチャット側に流す必要はありません。むしろ「これは IDE で手を動かすもの」「これはエージェントにまとめて任せるもの」を最初に仕分けるほうが、往復そのものが減ります。

どのサーフェスに何を任せるかという全体像は、Antigravity 2.0・CLI・IDE・SDK — 4つのサーフェスをどう選ぶか で整理しています。エージェントに渡すコンテキストの精度を上げたいときは Antigravity に的確なコンテキストを渡す — @ リファレンスで AI 出力の精度を上げる実践ガイド も合わせて読むと、渡し方の解像度が上がります。

次の一歩

まずは、あなたのいまの作業で「アプリを切り替える直前に全保存する」を一度だけ意識的に試してみてください。たった一度の全保存が、二度書きの大半を防ぎます。分離された構成は慣れると快適ですが、その快適さはディスクを正とする小さな規律の上に成り立っています。同じところでつまずいている方の参考になれば幸いです。

シェア

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

Antigravity Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

もしこの記事がお役に立ちましたら、チップ(¥150)で応援いただけると大変励みになります。広告なしでの運営を続けるため、皆さまのご支援が大きな力になっています。

関連記事

Editor View2026-06-26
Antigravity が一気に書いた巨大な差分を、意味単位のコミットに分け直す
エージェントが書いた数百行の差分を、そのままコミットしていませんか。レビューできない一括コミットを、関心ごとに分け直すための実践的なワークフローとスクリプトを紹介します。
Editor View2026-06-16
仕様書 PDF を Antigravity 2.1.4 に読ませて実装する — 添付機能の実務メモ
Antigravity 2.1.4 で追加された PDF 添付を、仕様書をエージェントに渡す実装ワークフローとして使い込んだ記録です。対応形式・スキャン PDF の罠・トークン消費・検証の手順までまとめました。
Editor View2026-05-27
Antigravity の Settings Sync を3週間運用した所感 — 2台の Mac で個人開発を続けるための同期設計
自宅と外出用の2台の Mac で同じプロジェクトを行き来する個人開発者として、Antigravity の Settings Sync を3週間運用した実装メモを、ぶつかった壁と現在の同期設計に沿って書きました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →