はじめに
最近、AI Agentが増えすぎてAntigravity、Claude Code、Codex、GitHub Copilot……どれを選べば”使える”アプリが出てくるのか？ モデルの違いはどこまで影響するのか？というのが気になったので実際に検証してみました。
今回の検証は、まったく同じ仕様書を4つのAI Agentに渡し、0→1でWebアプリを構築させるという検証です。お題は「離乳食管理Webアプリ(もぐさぽ)」。ただのTodoアプリとかだと差がわかりずらそうだったので、もう少し内容の濃いアプリを選びました。娘の離乳食がそろそろ始まるので実用レベルで上がってきたら使おうかな。
検証の進め方
1. 仕様書の作成
まず Claude Code に「離乳食管理Webアプリを作りたいので仕様書の作成をお願いします」とプロンプトを投げ、仕様書 MoguSupo-SPEC.md を生成しました。
Claude Code はデータベース設計やフォルダ構成まで出力してくれましたが、そこは各 Agent の裁量に任せたかったのであえて削除し、機能要件・画面要件・技術スタック等のみを残しています。
技術スタックを残したのは、検証を楽にするためにです。AIに選ばせるとSupabaseとかCloud flareとか使って若干検証が面倒になることが予想できたので。
仕様書の規模感
今回使った仕様書は288行で、以下のような内容が定義されています。
| 項目 | 内容 |
|---|---|
| 画面数 | 12画面（ランディングページ〜設定画面まで） |
| 主要機能 | 10機能（認証、子ども情報管理、食事記録、栄養充足判定、アレルギーチェック管理、食材DB、ダッシュボード、ステージガイド、通知、データエクスポート） |
| 技術スタック | Next.js 15（App Router）+ TypeScript + Tailwind CSS + shadcn/ui + SQLite + Drizzle ORM 等を指定 |
| 非機能要件 | モバイルファースト、レスポンシブ対応、WCAG 2.1 AA準拠、LCP 2.5秒以内 等 |
| ビジネスロジック | 栄養素の充足率を3段階判定するロジック、アレルゲン8品目+20品目の分類管理、月齢別ステージ自動判定 等 |
| 食材マスター | 約300品目（文部科学省 日本食品標準成分表ベース） |
技術スタックまで仕様書で指定しているため、各Agentの技術選定の差は出ません。それにもかかわらず出来上がりにこれだけの差が出たというのが、この検証の面白いところです。
2. 各Agentへの指示
各 Agent に投げたプロンプトは完全に同一です。
Webアプリケーションを作成します。”C:\sksp\MoguSupo-SPEC.md”に仕様があるので、これを読んで開発を開始してください
追加の指示やヒントは一切なし。純粋に「仕様書だけ渡してどこまでやれるか」を見ています。
3. 評価軸
今回の検証では、以下の4つの軸で各Agentの出力を評価しました。
| 評価軸 | 観点 |
|---|---|
| UI/UXの質 | ターゲット層（離乳食期の保護者）を意識したデザイで、温かみ・親しみやすさがあるか。仕様書には定義しなかったUI部分をどのように工夫するか |
| エラーの少なさ | 初回ビルド・起動時にエラーなく動作するか。エラーがあった場合、Agent自身または簡単な修正依頼で解決できるか |
| 機能の網羅性 | 仕様書に定義された10機能・12画面がどの程度実装されているか。主要な画面遷移や機能が一通り動作するか |
| 追加指示の手間 | 1回のプロンプトでどこまで完走するか。途中で止まったり、続行・修正の指示が何度必要だったか |
評価は定量スコアではなく、実際に触ってみた際の定性的な所感に基づいています。
結果一覧
| Agent | モデル | UI/UXの質 | エラー | 機能の網羅性 | 追加指示の回数 |
|---|---|---|---|---|---|
| Antigravity | Gemini 3.1 Pro | ○ | 軽微（即解決） | ○ | 少ない |
| Claude Code | Opus 4.6 | △ シンプル・業務的 | なし | △ 一部欠け | 少ない |
| Codex | GPT-5.3-codex | ✕ チープ | 軽微（即解決） | △ 一部欠け | 多い |
| GitHub Copilot | GPT-4.1 | — | 致命的 | — 完成せず | 多い |
各Agentの詳細レポート
Antigravity（Gemini 3.1 Pro）
温かみのあるUIが第一印象でした。離乳食管理という題材からターゲット層を想定してデザインを作り込んでいると感じられ、仕様書には書いていない部分まで”こうあるべきだろう”と推測して実装してくれています。
エラーが2点ありました。ログイン後に画面遷移しない問題と、Module not found エラーです。ただし、いずれも修正依頼を出したら即座に解決してくれて、デバッグ能力には問題なしという印象です。
ちゃんとレスポンシブ対応もされてます。
Claude Code（Opus 4.6）
こちらはエラーゼロで動きました。ただしUI/UXは非常にシンプルで、良く言えば堅実、悪く言えば業務アプリ感が強い仕上がりでした。
ただ食材検索機能や、栄養データの振り返り機能が一部動作しないなど、機能の網羅性にやや課題がありました。こちらも追加修正指示ですぐに修正されました。
ちゃんとレスポンシブ対応もされてます。
一応追加で「ターゲット層に刺さるデザインに改修してください」と指示を出しましたが、以下が出力されたので、あまりデザインは強くなさそうです。
Codex（GPT-5.3-codex）
かなり意外な結果でしたが、前者2つと比較してかなりUI/UXがチープな仕上がりでした。
こちらも追加で「ターゲット層に刺さるデザインに改修してください」と指示を出しましたが、多少マシになった程度でデザイン面の弱さは拭えませんでした。
↓食事記録の際にに食材の検索機能がなく、UX悪すぎる問題がありました。
また、切りのいいところで実装を止めてしまう傾向があり、何度か続行を指示する必要がありました。エラーが1点ありましたが、追加指示ですぐに修正されました。
レスポンシブにはしっかり対応してました。
GitHub Copilot（GPT-4.1）
こちらも切りのいいところで実装が止まる傾向は同じでした。さらに、途中で発生したエラーをAgent自身が解決できず、完成を断念する結果に。今回のような12画面・10機能規模の仕様書を一括で渡すタスクは、現時点のGitHub CopilotのAgent機能には難しかったようです。
モデルを入れ替えてさらに検証
Agent とモデルの関係をもう少し深掘りするため、組み合わせを変えた追加検証も行いました。
Antigravity（Opus 4.6）
Gemini 3.1 Pro でも良かったUI/UXがさらに一段上がりました。特筆すべきは、指示していないにもかかわらず framer-motion を導入し、コンポーネントにフェードアニメーションを付けていた点です。画像だとわからないのでGifにしました。
遊び心のある仕上がりで、同じ Opus 4.6 でも Claude Code とは出力がまるで違いました。エラーは1件ありましたが、こちらも指示ですぐに修正できました。
同じモデルなのにここまで差が出るということは、Agentの側のプロンプト設計やワークフローの作り込みがアウトプットに大きく影響しているということなのかなと思いました。
Claude Code（Haiku 4.5）
軽量モデルなのでUIはチープだったのは想定内でしたが、思ったより普通に実装されました。
こちらも切りのいいところで止まる傾向があり、何度か続行を指示しています。エラーは発生しましたが修正依頼で即解決。使いやすくはないものの、最低限の機能は一通り揃っていかなという印象です。
総評
モデルの差は確実に出る、しかしAgentでも意外と差が出る
上位モデル（Opus 4.6）と下位モデル（Haiku 4.5）で品質差が出るのは想定内でした。Gemini 3.1 Pro も Google の最上位モデルですが、今回の検証では Opus 4.6 の方がより高い品質のアウトプットを出しています。
しかし、同じモデルでも Agent が変わると出力が大きく変わるという発見は非常に興味深いものでした。Opus 4.6 を使った Claude Code と Antigravity では、同じモデルとは思えないほどアプローチが異なります。技術スタックまで仕様書で揃えているにもかかわらず、この差が出るのは Agent 側の作り込みの差と考えて良いと思います
各Agentの所感
Antigravity は、ユーザーを想定したUI/UXの作り込みが際立っていました。指示にない部分まで想定して実装してくれるスタイルは、まさに「プロダクトエンジニア」的な振る舞いと感じました。個人的には最高でしたが、指示されたことだけを忠実にこなしてほしい人にとっては、余計な時間と、トークン消費をされたと感じるかもしれません。
Claude Code は、教科書的で堅実なUI。面白味はないものの、to Bアプリならそのまま実用レベルです。
Codex は、UIの質・機能の網羅性ともに他と比べて弱い結果でした。何度かやり取りが必要になり、0→1のフェーズでは効率が良くないと感じました。
GitHub Copilot は、今回のような大きな仕様書ベースの開発には不向きでした。コンテキストの大きさが原因なのか、完成に至りませんでした。プレミアムリクエストで上位モデルを使えば結果は変わった可能性もありますが、今回の条件はやや酷だったかもしれません。
補足
CodexとGitHub Copilotが今回の検証で振るわなかったのは、大きく曖昧な一括指示に弱いという特性に起因する部分が大きいと考えています。個々の小さなタスクを明確にこなす力は十分にあるはずなので、使い方次第で評価は全然変わると思います
おまけ：ちょっと気になる構図の話
ここから先は完全に個人の雑感です。
MicrosoftはAI初期は買収したGitHubにCopilotを作らせている一方で、途中巨額の出資先のOpenAIがCodexを世に放ち、結果的に競合を自ら生み出しています。最近 Azure 上で Codex が使えるようになったという話もあり、時系列で構図を追っていくと、GitHub Copilot が Microsoft の戦略の中でどういう位置づけになっていくのか……おっと、誰か来たようだ
本記事は特定のツールを推奨・否定するものではなく、あくまで個人の検証結果に基づくものです。各ツールはアップデートにより日々改善されています。
※この記事の執筆には一部生成AIが使用されています
