1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Antigravityは「AIがコードを書く道具」じゃない。開発の主語をずらす作業面だと思う

1
Posted at

アップロード容量が月の制限(100MB)を超えました。設定 -> アップロードしたファイル から、当月にアップロードされた不要なファイルの削除を行ってください。

正直、最初はスルーしかけた。

また新しいAIコーディングツールでしょ、くらいに見えていたから。

でもAntigravityは、CursorやClaude Codeの延長線だけで見るとたぶん読み違える。

これの本質は、コード補完が賢くなったことじゃない。開発の作業面そのものが、AIエージェント前提に組み替わり始めたことだと思う。Googleは2025年11月にAntigravityを公開し、EditorだけでなくManagerの画面を持つ「agent-first」の開発プラットフォームとして打ち出した。エージェントがエディタ、ターミナル、ブラウザをまたいで計画し、実行し、検証するところまでを一つの流れとして扱っている。

これ、何がそんなに違うのか

従来のAIコーディング支援って、感覚的には「隣にいる優秀な先輩」だった。

困ったら聞く。補完してもらう。差分を出してもらう。そういう関係だよね。

Antigravityはもう少し踏み込んでいて、人が逐一ハンドルを握る前提を外そうとしている

公式の説明でも、エージェントは複雑なタスクを自律的に計画し、実行し、検証する存在として扱われている。しかも、その過程をArtifactsとして残す。タスクリスト、実装計画、コード差分、スクリーンショット、ブラウザ録画まで返してくる。ここがかなり重要で、単に「やりました」と言うAIではなく、“何をどうやったかの証跡”ごと返す設計になっている。Google自身がこれを「Trust Gapを埋めるもの」と説明しているのも、かなり本音だと思う。
身近な例えで言うと、電動ドライバーが高性能になった話じゃない。

現場監督が、作業指示書と途中写真と完了報告を持って、複数の職人を回し始めた感じに近い。

だから「AIがコードを書く」より、「人は何をレビューし、どこで止め、どこを任せるか」を設計する側に回る。

ここがピンとくると、Antigravityの見え方がかなり変わる。


なぜ今、急に意味が重くなったのか

この話が“単なる新製品紹介”で終わらないのは、Googleの開発体験がこの数か月で役割分担をはっきり見せ始めたからだと思う。

2026年3月にはGoogle AI Studioに、Antigravityのcoding agentを使った新しいBuild modeが入り、プロンプトから本番寄りのWebアプリを作る流れが強く押し出された。Firebase連携まで入っていて、ブラウザ上で試作し、そのまま実アプリに近づける導線が太くなっている。 一方で、Firebase Studioの終了案内では、移行先がGoogle AI StudioかGoogle Antigravityに整理された。しかも説明がかなり明快で、速いブラウザ中心の試作はAI Studio、コードファーストでローカルに深く触る開発はAntigravity、という棲み分けがはっきり書かれている。 Firebase

ここ、地味だけど大きい。

つまりGoogleは、AI開発を「チャットで試作する場所」と「自律エージェントに仕事を回す場所」に分け始めたわけで、これって3年後に振り返ると、IDEの再定義の入口として見られる気がする。


AI駆動開発の人ほど、むしろ見方を変えた方がいい

Cursor、 Code、Copilotを触っている人ほど、Antigravityを「競合製品」とだけ見るともったいない。

個人的には、ここは代替というより分業だと思っている。

たとえばCursorやClaude Codeは、いまでも「自分と並走する」感じが強い。

会話しながら、差分を見ながら、一緒に詰めるのがうまい。

Antigravityはそこに、**“自分が今キーボードから離れていても進む仕事”**を持ち込みにきている。

Managerでは複数ワークスペースや多数のエージェントを見渡せるし、EditorはVS Codeベースなので既存の筋肉記憶も捨てずに済む。さらにKnowledgeという永続メモリもあり、ユーザー指示やパターンを蓄積していく設計になっている。つまりこれは、単発の補完ツールじゃなくて、**作業の文脈を持った“半常駐の実働者”**に近い。 Google Antigravity+3Google
ここで面白いのは、ドキュメントの価値が逆に上がること。

AIが強くなると設計書はいらない、みたいな話がたまにあるけど、僕はむしろ逆だと思う。設計意図、制約、レビュー基準が曖昧だと、自律エージェントは速く間違える。Artifactsで証跡が出る世界では、「何を正解とするか」を先に言語化しているチームほど強い。

余談だけど、これは受験の答案添削にも少し似ている。

書いた本人の頭の中より、採点基準が明文化されている方が、修正は速い。AI開発もだんだん同じになってきた。


明日からどう使うか

僕なら、いきなり全部をAntigravityに寄せない。

まずは役割を分ける。

雑に言うと、

発想と最速試作はAI Studio

リポジトリに深く入る実装と検証はAntigravity

細かい伴走修正はCursorやClaude Code

この3層に分けるのが、今はいちばん気持ちよく回るんじゃないかなと思う。
モデル面でも、AntigravityはGemini 3.1 Proのhigh/lowに加えて、 Sonnet 4.6、 Opus 4.6、GPT-OSS-120bまで選べる。

逆に言うと、“どのAIを使うか”より、“どの仕事をどの面で回すか”の方が、だんだん重要になる。プラン面ではGoogle AI Pro/Ultraで利用枠が変わるし、賢いモデルほどクォータ設計の影響も受けやすいから、全部を一つの道具に背負わせる設計はやや危ない。 Google Antigravity+3Google
だから最初の一歩としては、

いま持っている小さめの個人開発案件を一つ選んで、設計・実装・検証のどこを“自分の仕事”として残すかを先に決めてからAntigravityに渡す

これがたぶん一番ハマりにくい。

たぶん問われ始めているのは、コードを書く速度じゃなく、AIにどこまで仕事を委譲しても壊れない開発体制を作れるかどうかだ。

Antigravityの話って、ツールの新旧比較だけで終わらせると薄い。

本当は、「開発者の仕事はどこまで実装で、どこから監督になるのか」という話なんだと思う。

ここを見落とすと、ただの新しいIDEに見える。

でもここに気づくと、わりと先の景色まで変わって見える。

1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?