Antigravity、Codex、Kiroを同じ土俵で見る
はじめに：なぜ今、これらを比較するのか
2025年末、AIコーディングツールの様相が一気に変わった。Google Antigravityの登場、OpenAI Codexの大幅アップデート、そしてAWS Kiroの発表。それぞれが異なるアプローチで「AIが開発する時代」を提案している。
ただ、実際に手を動かしてみると分かるのだが、これらは単純に「どれが優れているか」では語れない。それぞれが想定する開発スタイルが根本的に違うからだ。
本稿では、Antigravity、Codex、Kiroという3つの異なるアプローチを整理し、それぞれがどのような開発体験を目指しているのかを明らかにしたい。
ちなみに「なぜClaude Codeが含まれていないのか」と疑問に思う方も多いかもしれないが、個人的にはKiroが出るまでは使っていたが、その後、Codex、Antigravityと様々試していく中で最近のお気に入りから外れているためです。
1. Codex：既存フローを強化する実務派
位置づけ
OpenAIのCodexは、既存の開発フローにAIエージェントを「差し込む」アプローチを取っている。ターミナルから使えるCLI版と、VS Code/Cursor/Windsurfなどで動作するIDE拡張版の両方を提供しており、開発者が今使っている環境をそのまま活かせる設計だ。
特筆すべきは、ChatGPTアカウントでそのままサインインできる点。APIキーの設定すら不要で、Plus会員なら今日から使える。この導入障壁の低さは、実務で試す上で無視できない利点だ。
最近のアップデートでは、GitHub PRに@codexとメンションするだけで自動コードレビューが走る機能や、ローカルで作業しつつ重いテストをクラウドにオフロードする機能が追加された。「AIエージェントを、今のワークフローに自然に組み込む」という方向性が明確になってきている。
Antigravityとの決定的な違い
Codexは「既存のIDE」が主役だ。VS CodeでもCursorでも、開発者が慣れ親しんだ環境の中にエージェントが入ってくる。対してAntigravityは「エージェントが主役のIDE」として設計されている。
この違いは、日々の開発体験に直結する。Codexを使う場合、開発者は依然として「次にどのファイルを触るか」「どういう順序でタスクを進めるか」を考える必要がある。エージェントは強力だが、あくまで指示待ちの補佐官だ。
一方、Antigravityでは「ECサイトのプロトタイプを作って」という高レベルの要求を投げると、エージェントが設計から実装、テストまでのタスク全体を分解し、自律的に進めていく。Manager Viewという専用UIで、複数のエージェントが並行して動く様子を眺めることになる。
もう一つ重要な違いは、カバー範囲だ。Codexはファイル操作とコマンド実行が中心で、ブラウザの自動操作は基本的にスコープ外。Antigravityは、エディタ、ターミナル、ブラウザの三者を横断し、UI検証のスクリーンショットまでArtifactsとして記録する。
実務で使い分けるなら、「機能追加」「バグ修正」といった明確なタスクにはCodexが向いている。既存プロジェクトの文脈を理解させて、ピンポイントで作業させる用途だ。対して、新規プロジェクトの立ち上げや、複数の関連タスクを一気に片付けたい場合は、Antigravityの自律性が活きる。
2. Kiro：仕様を中心に据えたAWS流
設計思想
AWS Kiroは、他の二つとは全く異なる方向性を持っている。「仕様駆動開発」を徹底し、YAMLやJSONで記述した「Kiro Specs」を単一の真実の源とする。
この発想は、従来のBDD（振る舞い駆動開発）やテスト駆動開発の延長線上にある。要件を先に形式化し、それに基づいてエージェントが実装を進める。人間が考えるべきは「何を作るか」であり、「どう実装するか」はエージェントに委ねる、という思想だ。
さらにKiroは「Hooks」という仕組みで、CI/CDパイプラインとの統合を前提にしている。PRがオープンされたらテストを走らせ、失敗したら自動で修正PRを出す、といった自動化が標準で組み込まれている。
AWSエコシステムとの親和性も高い。Model Context Protocol（MCP）経由で社内システムと連携したり、AWS Qと組み合わせてインフラ構築まで含めたフローを回すことができる。
Antigravityとの比較
両者ともVS Code（Code OSS）ベースのエージェントIDEだが、焦点が異なる。
Antigravityは「Computer Use」を前面に押し出し、ブラウザ操作を含めた開発タスク全般をカバーする。証跡を残すArtifacts機能により、エージェントが何をしているのかを可視化することに注力している。
Kiroは「仕様」と「パイプライン」に焦点を当てている。Specファイルを維持し続けることで、プロジェクトの意図を明示的に保ち、長期的な保守性を担保する設計だ。また、HooksによってDevOpsのワークフローに深く組み込まれる前提で作られている。
実際の使い分けとしては、プロトタイプの素早い検証にはAntigravityが向いている。一方、本番環境への移行を見据えた開発、特にAWSインフラ上でサービスを構築する場合は、Kiroの仕様駆動アプローチが活きる。
人気が高すぎて既にウェイトリストが設けられているという報道もあり、AWS界隈での期待値の高さが窺える。
Codexとの違い
インターフェース面では、Codexがターミナルと既存IDEを主戦場にしているのに対し、KiroはCode OSSベースの専用IDE環境を提供する。
開発スタイルでいえば、Codexは「その場その場で指示を出す」対話駆動型。「このディレクトリでこのタスクをやって」という即座のフィードバックループが中心だ。
Kiroは先にSpecを書いてから、それに沿ってエージェントが長期的に動き続ける。一度Specを定義すれば、その後の実装、テスト、リファクタリングまで自律的に進む。
エコシステムの観点では、CodexはChatGPT、GitHub、Cursor、Windsurfなど、ベンダー横断で広く使える汎用性が強み。Kiroはその逆で、AWSのサービス群（Q、Codeシリーズ、CI/CD）に深く入り込むことで、AWS上での開発体験を一貫して最適化する方向性だ。
3. 三者を同じ軸で整理する
「何を主役にしているか」
この視点で見ると、三者の違いが鮮明になる。
Antigravityは「エージェントIDE」そのものが主役だ。開発の一連の流れ—仕様理解、コーディング、テスト、ブラウザでの動作確認—をすべてArtifactsという形で可視化し、エージェントが自律的に動く様子を観察できる環境を作り上げた。
Codexは「既存のターミナル・IDE」が主役。開発者が使い慣れた環境に、強力なAIの補佐官を配置する形だ。環境を変えることなく、AIの恩恵を受けられる。
Kiroは「仕様（Spec）とパイプライン（Hooks）」が主役。IDEはそのUIに過ぎず、エージェントはSpecに基づいて動く自動運転エンジンという構図だ。
自律性とガバナンス
自律性の高さで並べると、AntigravityとKiro autonomous agentが同等で、Codexがその次に来る印象だ。CursorのComposerやCopilot Agentも、このあたりのレンジに位置する。
ただし、自律性が高ければ良いわけではない。Antigravityは既に「ターミナルでの自動実行が暴走してHDD全削除」という事故例が報告されている。高い自律性には、それに見合ったガバナンスの仕組みが必要だ。
Codexは、IDE拡張版やGitHub連携では比較的安全な入口が多い。PRレビューという既存のワークフローに乗せる形で導入できるため、いきなり危険なコマンドが実行されるリスクは低い。
Kiroは、SpecとHooksで「どのイベントで何をするか」を明示的に設計できる。これは諸刃の剣で、適切に設計すれば安全な自動化レールを敷けるが、設計ミスがあればそのまま自動化される危険もある。ポリシー設計の重要性が高い。
ビジネス視点での使い分け
実務での使い分けを考えるなら、以下のような整理になる。
PoCと攻めの実験には、Antigravityが適している。ローカルの検証環境で、「エージェントにどこまで任せられるか」を試すフィールドとして優秀だ。失敗してもリカバリできる環境で、限界まで触らせてみる用途に向く。
AWS上での新規サービス立ち上げでは、Kiroの仕様駆動アプローチが活きる。Specから実装、テスト、CI/CD、本番デプロイまでを一貫して管理できるため、プロトタイプから本番への橋渡しがスムーズだ。
既存プロダクトの継続開発には、Codexが無難だ。今使っているVS Code、Cursor、GitHubベースのフローを壊さずに、AIエージェントの力を段階的に取り入れられる。チーム全体の移行コストも最小限に抑えられる。
マルチエージェント運用については、三者三様のアプローチがある。GitHub Agent HQで複数エージェントを統合的に管理する方向性、AntigravityのAgent Managerで並列実行を制御する方向性、Kiro autonomous agentをチーム共有リソースとして運用する方向性。どのハブを組織の標準にするかが、今後の分かれ目になるだろう。
4. なぜAntigravityが「未来」なのか
ここまで三者を比較してきたが、Antigravityが特別視される理由は何か。
それは、開発という行為の抽象度を一段引き上げた点にある。
従来のAIツールは、結局のところ「コードを書く速度」を上げるものだった。GitHub Copilotは優れた補完ツールだし、ChatGPTは的確なコード例を返してくれる。しかし、タスクの分解、実装の順序決定、テストの設計といった「開発の流れ」自体は、依然として人間が考える必要があった。
Antigravityは、その「開発の流れ」そのものをエージェントに委ねる設計になっている。「ECサイトを作りたい」という要求に対して、エージェントが自ら設計を立て、バックエンドとフロントエンドを並行実装し、動作確認まで自律的に進める。
これは、プログラミングという作業が「コードを書くこと」から「何を作るかを定義すること」へとシフトする可能性を示している。
もちろん、現時点では粗削りだ。ターミナル権限を与えた結果、予期しないコマンドが実行されるリスクは無視できない。実際、公式もTerminal Execution Policyの設定を強く推奨しているし、本番環境での使用は現実的ではない。
しかし、10年前にGitが登場したとき、多くの開発者は「バージョン管理ツールなんて使わなくても開発できる」と考えていた。今ではGitなしの開発は考えられない。
Antigravityも、同じ軌道を辿る可能性がある。2年後、3年後には、「エージェントIDEを使わない開発」が時代遅れになっているかもしれない。
重要なのは、Antigravityが提示しているのは単なる「便利なツール」ではなく、開発という行為そのものの再定義だということだ。
5. 実務での現実的な構成案
複数のコーディングエージェントを並列活用する前提なら、現時点では以下のような構成が現実的だろう。
日々の開発の主軸には、CodexとCursor（またはCopilot Agent）の組み合わせを推奨する。既存のIDE環境とGitHubベースのワークフローを維持しつつ、タスク単位で強力なエージェントを活用できる。
AWS上での新規サービス開発では、Kiroを試す価値がある。Specベースの仕様管理と、Hooksによる自動化パイプラインが、プロトタイプから本番への移行をスムーズにする。特に「Specレビュー → 実装 → テスト → デプロイ」の一連の流れを、どこまで自動化できるかを評価すべきだ。
エージェントIDEの探索枠として、Antigravityを検証用環境で限界まで試す。破壊されても問題ないリポジトリと環境を用意し、Artifactsによるレビューコスト削減効果や、マルチエージェントの並列実行が実際に機能するかを見極める。
この三段構えで、それぞれのツールの強みを活かしつつ、リスクを分散できる。
おわりに
Antigravity、Codex、Kiroは、それぞれが異なる未来像を描いている。どれが「正解」ということはなく、プロジェクトの性質、チームの文化、インフラ環境によって最適な選択肢は変わる。
ただ一つ確実なのは、「AIが開発する時代」はもう始まっているということだ。問題は「使うか使わないか」ではなく、「どう使いこなすか」に移っている。
それぞれのツールを理解し、適材適所で使い分ける。その先に、開発者としての次のステージが待っているはずだ。