本サイトでは少し前に、Claude・Gemini・Antigravity を1ヶ月使い分けてわかった、3つのAIの個性という記事を書きました。3つを並行で使ってみて、それぞれの「個性」を整理した内容です。
ただ、その記事を書き終わったあと、本サイトの運営者の中に小さな違和感が残っていました。「同じ対話型AIと呼んでもよさそうな3つ」とまとめてみたものの、Antigravity だけ明らかに毛色が違うのです。Claude と Gemini が「対話して情報を整理する」タイプなのに対し、Antigravity は「実際にブラウザを開いて作業する」タイプ。この差は「個性が違う」という言葉では説明し切れていない気がしました。
その違和感が、Anthropic が提供している Cowork という協働機能と並べてみたときに、すっと解けました。「Antigravity は Gemini にとっての Cowork のようなものだったんだな」という気付きです。本記事はその整理メモと、整理がついた結果いまどう運用しているかを書きとめた記事になります（2026年5月時点）。
ちなみに先にネタバレすると、本サイトの運営者がブラウザ操作を AI に任せたい場面で最初に試したのは Cowork でした。けれど結局、いまは Antigravity に落ち着いています。その流れも含めて書いていきます。
「3つのAI」と並べた時に、本サイトの運営者の中に残っていた違和感
前回の記事では、Claude・Gemini・Antigravity を「3つのAI」として並列に並べて整理しました。日常で触れる3ツールという意味では、その並べ方で困ることはありません。
ただ、書き終わってから読み返してみると、ひとつ気になる箇所がありました。3つ目の Antigravity の章を書く段になって、急に「ブラウザを開いて何かをやってくれる」「実行役」という、それまでとは違う言葉が出てきていたのです。
Claude と Gemini を語る言葉は、どちらも「対話する」「相談する」「情報を整理する」といった、同じ世界の言葉で並べることができました。けれど Antigravity を語ろうとすると、その世界の言葉では足りなくて、「ブラウザ操作」「実行」「自律」といった別カテゴリの言葉に切り替える必要があったのです。
つまり、「3つのAIの個性」という枠で語ったときに、実は最後の1つだけカテゴリが違うものを並べていたのではないか。違和感の正体はそこにありました。
Claude と Gemini は LLM（大規模言語モデル）そのものの名前ですが、Antigravity はもう少し別の位置にあります。Antigravity は Google が2025年11月に発表した AI エージェント型のコーディングツール（IDE）で、自然言語の指示を受けて、コーディングだけでなく Web の閲覧やブラウザ操作までを自律的に進めてくれる環境です。中で動かす AI モデルは Gemini や Claude など複数から切り替えて使えるので、Antigravity 自体は「AI モデル」そのものというより、AI モデルを動かす入れ物（IDE）としての性格が強いものになっています。
この理解が腑に落ちたのは、別のところで Anthropic の Cowork という機能を整理し直していたときでした。
結論を先に書くと、Antigravity は Gemini にとっての Cowork なんだなと思った
結論を先に書きます。本サイトの運営者が1ヶ月使ってみて整理がついた構造はこうです。
| LLM 本体 | 外側で動かすための自律型エージェント |
|---|---|
| Claude | Cowork（Anthropic のデスクトップアプリにある協働セッション機能） |
| Gemini | Antigravity（Google 製の AI エージェント型 IDE・Gemini モデルを載せて使う） |
つまり、Claude も Gemini も「LLM 本体」であって、それぞれの外側に「LLM をどう動かすか」を決める自律型エージェントのレイヤーがある、という話でした。Claude にとってのその外側レイヤーが Cowork で、Gemini にとってのそれが Antigravity です。
両者は「LLM 本体ではなく、LLM を作業に組み込んで動かすための自律型エージェント」という意味で、構造的に対応しています。だから、Antigravity を Claude や Gemini と並列に「3つのAI」として並べようとすると、どこかで「エージェント」と「モデル」が混ざってしまう。これが前回の記事で残っていた違和感の正体でした。
ただし、対応しているのは「LLM 本体 + 自律型エージェント」という構造だけで、実際の動き方と用途は Cowork と Antigravity でかなり違います。むしろ正反対と言ってもいいくらいです。そしてこの違いが、最終的に運営者の「実運用」のかたちを決めていきました。次の2つの章で、それぞれの動き方を整理してみます。
Claude × Cowork — フォアグラウンドで動くので、作業中はマウスが使えなくなる
Claude を「協働して使う」ための自律型エージェントのひとつが、Anthropic の Cowork です。Claude のデスクトップアプリを開くと、左上に「Chat / Cowork / Code」という3つのタブが並んでいて、その真ん中にある Cowork タブが、これにあたります。
Cowork の特徴は、クラウド側で動く協働セッションである点と、git リポジトリをベースに作業する点です。アプリでリポジトリを選んでセッションを開き、依頼を出すと、クラウド側の Claude がそのリポジトリのファイルを編集していきます。変更内容は差分として表示され、作業が一段落したところで Pull Request の形で成果が返ってくる ── これが Cowork の基本的な流れです。
そして本サイトの運営者の場合、Cowork に出会った最初の頃には、「この1つの場所で、AI に任せたい作業をぜんぶ完結させたい」という気持ちが強くありました。リポジトリ上のファイル編集も、コードの修正も、できれば Chrome 上での調査や Web 管理画面の操作までも、Cowork のセッションの中でまとめて任せてしまえたら一番ラクだろう、と。実際、Cowork でも Chrome 操作をさせること自体は、できなくはありません。「これで AI に Web 上の作業も任せられるな」と思って試していた時期がありました。
ただ、もうひとつの特徴が、フォアグラウンドで動くということです。Cowork タブを開いてセッションを始めると、デスクトップアプリのウィンドウがそのまま作業の中心になります。依頼を書き、Claude が動いた結果を確認し、差分を見て次の指示を出す ── これらの操作は、Cowork のウィンドウに意識を集中させた状態で行う必要があります。
実際にやってみるとわかるのですが、Cowork で作業している間は、手元のマウスやキーボードが「Cowork 用」に意識を持っていかれる感覚があります。差分を読むためにスクロールし、追加指示を打ち込むためにキーボードを叩き、PR を確認するためにタブを切り替える ── これらの操作は、Cowork のウィンドウに張り付いている前提で進みます。
「ながら作業」がしにくいのは、Cowork の特性として大きい部分です。Claude が編集を進めてくれている間、別のことをしようとしてもうまくいきません。途中の差分を見落とすと結局戻って確認する必要があり、思考の流れが途切れてしまいます。これは Cowork が悪いという話ではなくて、「対話して詰めていく」タイプのツールである以上、運営者の意識をそこに置いておく必要がある、という当然の特性です。
そしてこの特性は、最初に期待していた「Cowork で Chrome 操作までまとめて任せる」運用とは、相性がよくありませんでした。Chrome に出ていく作業を任せたい時には、本来こっちは別のことをしながら結果を待ちたいのですが、Cowork でそれをやろうとすると、結局アプリの方に意識を引っ張られ続けてしまうのです。「これは別のレイヤーがあった方がいいかもしれない」と感じはじめたタイミングで、別のところで触りはじめていたのが Antigravity でした。
Gemini × Antigravity — DOM 操作なので、Chrome を任せながら別の作業を続けられる
一方、Gemini 系のモデルを「ブラウザ操作も含めて自律的に動かす」ための自律型エージェントが、Google の Antigravity です。
Antigravity 自体は AI エージェント型のコーディングツール（IDE）で、本来はアプリ開発や業務自動化を含む幅広い使い方ができます。中で動かす AI モデルは Gemini 3.1 Pro / Gemini 3 Flash / Claude Sonnet / GPT-OSS など複数から選べるのですが、本サイトの運営者が日常で使っているのは Gemini モデル + Antigravity の組み合わせで、用途としては「Web の閲覧やブラウザ操作を自律的に進めてくれる」側面が中心です。本記事ではその使い方に焦点をあてます。
Antigravity の特徴は、Cowork と対照的にバックグラウンド寄りで動くことです。依頼を渡すと、Chrome のタブが開き、ページを読み取りながら、依頼された作業を自律的に進めていきます。
ここで大事なのは、Antigravity は画面上のマウスを直接動かしているわけではないということです。クリック・スクロール・入力といった操作は、ブラウザ内部の仕組みを使って画面を直接操作する形で行われていて、運営者の手元のマウスカーソルとは独立に動いています。つまり「マウスカーソルが勝手に動いて、ユーザーの手から操作が奪われる」というタイプのツールではありません。
この違いが、運用上では決定的に効きました。Antigravity に「このサイトの仕様を確認してきて」「いくつかのページから情報を集めてきて」と依頼を出した後、運営者は手元のマウスとキーボードを使って、別の作業を続けることができます。Chrome の片隅で Antigravity が走り回って情報を集めている間、運営者は別のターミナルで設計を進めたり、別のアプリで原稿を書いたりできるわけです。
そして、ここからが大事な話なのですが、本サイトの運営者のように非エンジニア寄りの立場で AI に作業を任せたい場面を整理してみると、その多くは実は Chrome の中で発生していました。たとえば：
- Google Apps Script（GAS）の実装や設定（script.google.com 上で動く Google 製の自動化ツール）
- Make（旧 Integromat）のシナリオ作成（Web ベースの業務自動化サービス）
- その他 Web ベースの管理画面（SaaS の設定画面、ダッシュボード、フォーム入力など）
こうした「Chrome の中で発生する作業」を AI に任せたい場面で、Antigravity は他にない位置を取ります。最初は Cowork で同じ位置を埋めようとしていましたが、Chrome 操作という1点に絞って比較すると、確実に Antigravity に軍配が上がりました。速度も安定感も、Antigravity のほうが圧倒的に上だったのです。Cowork はそもそも git リポジトリ操作の協働機能として設計されているので、Chrome 操作はあくまで副次的にできる程度、というのが本サイトの運営者の体感です。
そして、Antigravity に切り替えてみて、運営者の使い方上で特に大きかった実利がもうひとつあります。それは「Chrome 作業中に別プロジェクトを進められる」という点です。
Cowork で Chrome 作業を任せていた頃は、Chrome のタブも Cowork のウィンドウも、結局運営者の意識を奪っていきました。Chrome 側で AI が走っている間に「ついでに別の作業を進めよう」と思っても、Cowork 側のセッションを動かす必要があったため、プロジェクトの並走ができなかったのです。
Antigravity に切り替えたあとは、この点が文字通り別物でした。Antigravity に Chrome 作業を任せている間、運営者は別のターミナルでまったく違うプロジェクトを進めることができます。マウスもキーボードも奪われないので、たとえば本記事のような原稿を Claude Code で書きながら、別のタブで Antigravity に調査を走らせ続ける、という運用が成立します。「Chrome 作業中に別プロジェクトを動かせるかどうか」は、地味なメリットに見えて実は1日の生産性に直結する大きな差でした。
逆方向の比較もしてみました。Cowork が得意とされる「git ベースの作業」も、実は Cowork でないとできないわけではありません。ローカルで動く Claude Code（コマンドライン版や Claude デスクトップアプリの Code タブ）でも、git の操作は十分にこなせます。むしろ「ターミナルで git を触りながら Claude Code と対話する」スタイルのほうが、本サイトの運営者の日常感覚にはしっくりきました。
整理してみると、3つのツールの位置はこうなります：
- Claude Code（コマンドライン版 + Claude デスクトップアプリの Code タブ）: ターミナル / ファイル / git / コーディング作業全般 ── ローカル統合の速度と自由度で独壇場
- Antigravity: Chrome 操作（GAS / Make / Web 管理画面など）── ブラウザ自律操作と「並走のしやすさ」で独自の輝き
- Cowork: 「Claude にとっての Antigravity」という構造的な位置にはいるけれど、実際の使用感では Claude Code と Antigravity の間に挟まれて、日常運用での出番はあまり多くない、というのが正直なところです
本記事のタイトルで「Antigravity は Gemini にとっての Cowork」と書いたのは、実用上の出番の多さの話ではなく、構造的な位置の話です。LLM 本体（Claude / Gemini）の外側に「自律型エージェント」というレイヤーがあって、その対応関係を整理するために Cowork という名前を引いた、というのが本記事の主旨でした。実運用としては、Cowork は「気付きのきっかけ」を残してくれて、現在地は Claude Code + Antigravity の二強体制に落ち着いています。
実際の使い方 — Claude Code で設計しながら、Antigravity に調査を投げて Chrome を走らせる1ヶ月
ここから先は、Claude Code と Antigravity を実際にどう並走させているか、その運用の中身を3つの観点で整理してみます。前章で書いた役割分担（Claude Code = ターミナル系・Antigravity = Chrome 系）を踏まえて、具体的にどう動かしているかの話です。
Claude Code から Antigravity に「指示書」を渡す流れ
ターミナルで Claude Code を開いて、設計や構成の相談を始めます。書き直しが必要な記事の構成案を一緒に詰めたり、運用ルールの叩き台を作ったり、コードの修正方針を確認したり ── このあたりは Claude Code との対話で進めていきます。
その途中で、「最新の Google 検索結果を見ながら判断したい」「実際の公式サイトでどう書かれているか確認したい」「GAS の管理画面で状態を見てきてほしい」といった、Chrome に出ていく作業が発生します。
ここで Claude Code に頼むのは、Antigravity 用の 指示書ファイル（.md） を1本作ってもらうことです。指示書には次のような項目が、Claude Code 側で構造化された形で書き込まれます。
- 対象URL / 対象アカウント / 検索キーワード
- 具体的な作業手順
- 成果物の保存先パス（例:
outputs/2026-05-XX_task_result.md） - 成功状態の定義
- 失敗時の挙動（取れなかった場合の記録方法）
- 禁止事項（スコープ外への越権禁止・要約禁止・推測埋め禁止 など）
この指示書を Antigravity に渡せば、Antigravity 上で動いている AI（運営者の場合は Gemini）がそれを読み、Chrome で DOM 操作しながらタスクを実行し、指定された出力先パスに結果を .md ファイルとして書き出してくれます。Claude Code は完了後にその出力ファイルを読み込み、設計の続きに反映していく ── このサイクルが1ヶ月で一番安定して回りました。
依頼を「チャットに直接書く」のではなく、ファイルとして残しておくのは、後で同じ依頼を再現したいときや、似たタスクで微調整して使い回したいときに、地味に効きます。指示書と出力結果がペアで残るので、何を頼んで何が返ってきたかが、後から自分でも追えるようになるのです。
AI が AI に指示すると、指示の解像度が上がる・抜けがなくなる
このサイクルを回してみて、もうひとつ大きな気付きがありました。それは、Antigravity に直接依頼するよりも、Claude Code を経由して Antigravity に投げる方が、結果の質が上がるということです。
理由は本サイトの運営者の体感ベースで言うと、非エンジニア寄りの自分が AI に依頼を書くとき、「何を指定しないといけないか」が、そもそも見えていないからだと思います。
ブラウザの調査をAIに任せるとき、本来であれば「どのサイトのどの範囲を見るか」「比較する軸はなにか」「除外したい情報源は何か」「どの形式で返してほしいか」といった条件を、ある程度明示する必要があります。けれど、こうした条件は、ふだんの自分の頭の中では「言わなくてもなんとなく察してほしい暗黙の前提」になっていて、依頼文に書き出そうとしても、自分でも書き切れないことがあります。
そして書き切れないまま依頼を投げると、当然ながら抜けたままの結果が返ってきます。「指示が抜けている」と頭ではわかっていても、何を抜いたのかが自分でわからない、という妙な状態に陥ることが、AIを使い始めた頃にはよくありました。
ところが、Claude Code を経由すると話が変わります。Claude Code は依頼の背景にある設計の文脈をすでに知っているので、その文脈に基づいて「Antigravity がどう動けば成果が出るか」を組み立て直してから、先に書いたような構造化された指示書ファイルとして整えてくれます。
結果として、Antigravity に渡る指示は、運営者が直接書くよりもずっと具体的で・条件が揃っていて・抜けの少ないものになります。Antigravity 側もその構造化された指示通りに動いてくれるので、戻ってくる結果も使い物になりやすい、という流れです。
人間 → AI と AI → AI の体感差
この「AI が AI に指示する」運用に慣れてくると、人間 → AI の指示とAI → AI の指示の体感差が、意外なほど大きいことに気付きます。
人間 → AI の指示は、どうしても短くなりがちです。「これ調べて」「これまとめて」のような短文で済ませようとして、結果として AI 側が前提を補完しきれず、ピントのずれた結果が返ってくる ── これは AI を使い始めた人なら誰でも経験する壁です。特に非エンジニアの場合、そもそも「指定するべき条件のリスト」自体が手元にないので、短文化されているというより「短文にしかなりようがない」状態になりがちです。
AI → AI の指示は、その壁を素直に超えてきます。AI 側は「言わなくても察してほしい暗黙の前提」を持たないので、必要な条件を素直に全部書いてくれます。結果として、依頼を受ける側の AI も動きやすい。指示が長くなることを気にする AI はいないので、双方にとってストレスのない通信になるわけです。
この「AI に指示の構造化を任せる」というのは、本サイトの運営者にとって 2026年に入ってからの大きな気付きでした。Claude Code がただの「相談相手」ではなく、他の AI ツールに対する指示の通訳者として機能している、というのが、1ヶ月使い込んでみてやっとはっきりと見えてきた構造です。
LLM 本体と自律型エージェントを分けて考えると、AI の選び方が変わる
ここまで整理してみると、「3つのAI」という枠組みでは見えていなかったものが、いくつか見えてきます。
ひとつは、AI ツールを選ぶときに「LLM 本体」と「自律型エージェント」を分けて見るほうが、判断軸が立ちやすいということです。
LLM 本体（Claude や Gemini）は、対話の質・知識のレンジ・出力のクセなどで比較する対象です。それぞれの個性は前回の記事でも整理した通り、得意分野が分かれています。
一方で、自律型エージェント（Cowork や Antigravity）は、「どんな作業を任せたいか」で選ぶ対象です。フォアグラウンドで詰めたいのか、バックグラウンドで走らせたいのか。ターミナルで完結する作業なのか、Chrome の中で発生する作業なのか。この軸は LLM 本体の比較とは別レイヤーの話で、混ぜると混乱します。
もうひとつは、これらを並走させる発想を持つと、運用の幅が一気に広がるということです。本サイトの運営者が1ヶ月触ってみて一番効いたのは、シンプルな役割分担でした。ブラウザ関係なしの作業は Claude Code に / ブラウザ作業は Antigravity 上の Gemini に。この分け方に揃えただけで、「いま何のツールで作業すべきか」で迷う時間がなくなりました。
特に、本サイトのように非エンジニア寄りで AI を使っていると、AI に任せたい作業の多くは Chrome の中で発生します。GAS の管理画面、Make のシナリオ、Web の調査、ダッシュボードの確認 ── こうした作業を「Claude Code でやろうとすると手が出ない」けれど、「Antigravity ならまるごと任せられる」というのが、運用してみてはっきりわかったことでした。
最初は Cowork で同じことをしようとしていた経緯もあって、Cowork という存在が「気付きの足場」になったのは間違いありません。「Antigravity って結局なんなんだろう」を整理するときに、Cowork という対応物があったからこそ、「ああ、Antigravity は Gemini にとっての Cowork のような位置なんだな」と腑に落ちました。実運用としては Claude Code + Antigravity に落ち着きましたが、その理解の地図ができたのは、Cowork のおかげでもあります。
前回の記事 Claude・Gemini・Antigravity を1ヶ月使い分けてわかった、3つのAIの個性 で残っていた違和感は、こうして「LLM 本体 + 自律型エージェント」というレイヤーの分け方を入れることで、本サイトの運営者の中ではすっと解けました。
「3つのAI」と並べて使い分けるという発想から、「LLM 本体と自律型エージェントを組み合わせて並走させる」という発想に切り替わると、AI との付き合い方が一段静かになります。本記事を読んでくださった方の中で、似たような違和感を抱えていた方の整理の役に立てば嬉しいです。
関連記事
本記事の前提となる、「3つのAI」を並列で整理した第1弾の記事です。本記事はその違和感の解消編という位置づけです。
