GeminiとClaudeに喧嘩させながらコードを書いている話 — AntigravityとClaude Codeの併用ワークフロー
最近、コードを書くときにGoogle Antigravity（Gemini 3.1 Pro）とClaude Codeを同時に立ち上げて、互いの出力を相手に添削させるという変な使い方をしている。最初は冗談半分で試したんだけど、これが思いのほか実用的で、今では毎日の普通の作業フローになってしまった。この記事ではその具体的な使い方と、やってみてわかったことを書いておく。
Google Antigravityとは
2025年11月にGoogleが発表したエージェント型IDE。Visual Studio Codeをベースにした開発環境で、Gemini 3.1 Pro・Gemini 3 Flash・Claude Sonnet 4.6・GPT-OSS-120Bなど複数のモデルをネイティブで切り替えながら使える。無料で使えて、SWE-bench Verifiedで76.2%というスコアを出している。VSCode forkなので既存の拡張機能がそのまま動くのも地味に助かる。
自分はAntigravity側ではGemini 3.1 Proをメインに使っている。Gemini 3.1 Proはコンテキストウィンドウが広く、大きなファイルを一気に食わせてもあまり音を上げない。一方でClaude Codeは推論の深さというか、「なぜそう書くのか」を説明させたときの納得感が強い。この特性の違いが、相互添削ワークフローにちょうどいい組み合わせになっている。
実際の使い方：2つのAIに喧嘩させる
基本の流れ
やっていることはシンプルで、片方にファイルを生成させて、そのファイルをもう片方に読ませて「ここがおかしくないか」と聞くだけだ。手でコピーするのではなく、どちらもファイルシステム上のファイルを直接参照できるので、「読み合い」が自然にできる。具体的な流れはこうだ。
- Antigravity（Gemini）にタスクを渡してドラフトファイルを生成させる
- Claude Codeに同じファイルを読ませて「このコードのどこが気になるか」と聞く
- Claudeの指摘をAntigravityに渡してリファクタリングさせる
- 必要なら逆向きにも回す
どちらか片方で完結させようとすると、そのモデルの「癖」がそのまま残る。Geminiはコードの全体感を掴むのが早いけど、細かいエッジケースの処理を省略しがちな印象がある。Claudeはそこに気づいて指摘してくることが多い。逆にClaudeが書くコードは一つひとつの処理が丁寧すぎて冗長になることがあって、そこをGeminiに「もっとシンプルに書き直して」と投げると整理されたりする。
トークンの分散という発想
もう一つの実用的な理由がトークン管理だ。Claude Codeをフルに使うとトークン消費が思ったより早い。長いコンテキストが必要な作業——たとえばリポジトリ全体の設計確認や大きなファイルの読み込み——はAntigravityのGemini側に任せて、Claude Codeは「詰め」の部分に集中させる使い分けをしている。
Antigravityは無料で使えてGemini 3.1 Proが使い放題なので、コンテキストを食う作業をこちらに逃がすとClaude Code側のトークン消費を抑えられる。月の後半にClaude Codeの残量を気にしながら作業する、みたいな状況がかなり減った。
自分の使い分けをざっくり整理するとこんな感じだ。
- Antigravity（Gemini 3.1 Pro）: 大きなファイルの読み込み・リポジトリ全体の把握・初期ドラフト生成
- Claude Code: エッジケースの指摘・推論説明・コードの意図確認・細かいリファクタ
この分担はタスクによって変わるけど、「広く速く全体を見る」がGemini、「深く丁寧にひとつひとつ確認する」がClaudeというイメージが自分の中で固まってきている。
拡張機能の活用
AntigravityはVSCode forkなので、インストール済みの拡張機能がそのまま動く。自分はESLint・Prettier・GitLensあたりを入れていて、Antigravityのエージェントがコードを生成したあとに自動でフォーマットが走る状態にしている。Claude Codeからターミナル経由で変更したファイルもリアルタイムで拾ってくれるので、2つのツールが同じエディタ上で共存している感覚になる。移行コストが低いのはVSCode forkならではの強みで、設定やキーバインドもほぼそのまま持ち込めた。
やってみてわかったこと
一番の発見は、2つのAIが同じコードに対して違う視点で指摘を出すという点だ。単純に「どちらが正しいか」ではなくて、GeminiとClaudeが食い違う部分にこそ、判断が必要な箇所が潜んでいることが多い。両方が同じことを言っていれば素直に直す、意見が割れたら自分で考える、という使い方が自然にできるようになった。
たとえば先日、Pythonで書いた非同期処理のコードをGeminiに投げたら「問題ない」と返ってきた。同じコードをClaudeに渡したら「asyncio.gather()の例外ハンドリングが不完全で、どれかひとつのタスクが失敗したとき残りが無言でキャンセルされる可能性がある」と指摘が来た。試してみたら確かにそうだった。Geminiも嘘をついていたわけじゃなくて、単純に「動くかどうか」で見ていたんだと思う。そういう温度差がある。
コンテキストのズレには注意
デメリットとしては、コンテキストを2つのツールに分散させるとどちらが「最新の状態」を持っているかがわかりにくくなる。特にClaude Codeでファイルを直接編集してAntigravityに渡し忘れると、古いコードに対して添削が走ってしまう。このズレに気づくのに少し時間がかかることがある。
自分は今のところ「編集はClaude Code側で行い、レビュー依頼時にファイル内容をAntigravityに貼り直す」というルールにしている。少し手間だけど、コンテキストのズレによる誤添削よりはずっとマシだと判断している。もっとスマートな方法があれば積極的に試してみたいが、今はこれで落ち着いている。
まとめ
- Antigravity（Gemini 3.1 Pro）は広いコンテキストが必要な作業・全体設計向き
- Claude Codeはエッジケースの指摘・推論の深さが必要な詰め作業向き
- 片方の出力をもう片方に添削させると、単独使用では見えなかった問題が出てくる
- Antigravityを無料のGemini枠として使うとClaude Codeのトークン消費を分散できる
- VSCode拡張がAntigravityでそのまま動くので移行コストは低い