Google Cloud公式Skillsを備えたAntigravity CLIとアーキテクチャ設計力を競いたくなった
AIエージェントの進化が目覚ましく、アーキテクチャ設計もある程度AIエージェントがこなせるようになってきました。
Google CloudでもAgent Skillsが公開されており、その中にはベストプラクティスに沿った設計をしてくれるスキルもあります。
私の生業は主にアーキテクトです。
まだまだAIより優れたアーキテクチャ設計ができる！…よね？と心配になってきたので、アーキテクチャ設計対決をしてみました。
個人の余興としての対決です。
ClaudeやAntigravity CLIの性能を測るような内容ではありません。
対決のルール
あるお題に対して、私とAntigravity CLIが以下を作成します。
- システム構成図
- アーキテクチャ上特に重要なポイント4点に関する簡潔な説明文
公正な判定をするために、以下をClaude(Sonnet5)に担当いただきます。
- お題の作成
- アーキテクチャ設計の評価
対戦相手
Antigravity CLI(Gemini 3.5 Flash)に以下を装備させました。
- Google Cloud公式のAgent Skills ※とりあえず全部
- draw.io MCP Server ※作図用
お題：育児用品レビューサイトのアーキテクチャ提案
Claudeに作成してもらった提案依頼書
# システム開発 提案依頼書(RFP)
## 育児用品レビューサイト 新規事業
---
## 1. 本書の目的
本書は、新規事業として立ち上げる「育児用品レビューサイト」のシステム構築にあたり、各担当者(提案者)がGoogle Cloud上でのシステム構成案を検討・提案するための提案依頼書(RFP)である。各提案者は本書の要件を踏まえたシステム構成、概算コスト、実現方式を提案すること。最終的に、事業責任者が複数提案を比較評価し、採用案を決定する。
---
## 2. 事業概要
### 2.1 事業内容
- 日本市場をターゲットに、育児用品のレビューサイトを運営する。
- 主な想定利用者は、一人目の子どもの育児を経験している(している最中の)両親。
- ユーザーが投稿した育児用品のレビュー・口コミを中心としたコンテンツで構成する。
### 2.2 収益モデル
| フェーズ | 収入源 | 概要 |
| ---------- | -------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| 初期段階 | 広告収入 | サイト内へのディスプレイ広告掲載等 |
| 事業成長後 | デジタルマーケティング支援 | サイト運営が軌道に乗った後、蓄積されたユーザー投稿データを活用し、育児用品販売企業向けにマーケティング支援サービスを提供 |
> 将来的に投稿データを分析・活用する前提のため、データの蓄積・分析基盤への拡張を見据えた設計が望ましい。
### 2.3 企業背景
- 従業員十数名のスタートアップ企業。
- 全社的に既にGoogle Cloudを利用しており、本事業のシステムもGoogle Cloud上に構築する方針。
---
## 3. 予算・体制に関する方針
- **初期構築費用**は可能な限り低く抑えること。
- **ランニングコスト**(インフラ利用料等の月額固定費・従量費)も可能な限り低減すること。
- **運用・保守にかかる人件費**も可能な限り低減できる構成とすること(マネージドサービスの積極活用、自動化等)。
- スモールスタートを前提とし、初期投資を抑えつつ将来的な拡張投資に段階的に振り向けられる構成を評価する。
---
## 4. 拡張性に関する方針
- サービス開始時点(スモールスタート)は最小構成で良いが、将来的に利用者数・投稿数・アクセス数が増加した場合にも、大規模なアーキテクチャ再設計なしに対応できるスケーラブルな構成であること。
- 将来のデジタルマーケティング支援事業(データ分析基盤の追加等)を見据え、データ活用の拡張がしやすい構成であることが望ましい。
---
## 5. 登場人物(ステークホルダー)一覧
| 登場人物 | 概要 |
| -------------------------- | ------------------------------------------------------------------------------------ |
| 一般ユーザー(閲覧者) | 育児用品のレビュー・口コミを閲覧する両親。会員登録なしでも閲覧可能とすることを想定 |
| 投稿ユーザー(会員) | 会員登録の上、育児用品のレビュー・評価・写真等を投稿する両親 |
| サイト管理者(社内運営担当) | サイトコンテンツの管理、不適切投稿の監視・削除、カテゴリ・タグ管理等を行う社内担当者 |
| 広告主 | サイトに広告を出稿する企業(初期段階の収益源) |
| 育児用品販売企業(将来) | 将来的にデジタルマーケティング支援サービスの提供対象となる企業 |
| 事業責任者 | 本事業の意思決定者。システム構成案の最終採用可否を判断 |
| システム開発者・運用者 | システムの構築・運用・保守を担当する提案者(社内エンジニア想定) |
---
## 6. ユーザーストーリー
### 6.1 一般ユーザー(閲覧者)
- 両親として、育児用品名やカテゴリで検索し、実際に使った人のレビューを読みたい。それにより、購入前に商品の使用感を把握できるから。
- 両親として、会員登録せずにレビューを閲覧したい。手軽に情報収集したいから。
- 両親として、スマートフォンから快適にサイトを閲覧したい。育児中は隙間時間での利用が中心になるから。
### 6.2 投稿ユーザー(会員)
- 育児中の親として、会員登録し、実際に使用した育児用品のレビュー(評価・コメント・写真)を投稿したい。他の親の参考になり、また自分の経験を記録として残したいから。
- 投稿ユーザーとして、自分が投稿したレビューを後から編集・削除したい。
- 投稿ユーザーとして、他のユーザーのレビューに「参考になった」等のリアクションをつけたい。
### 6.3 サイト管理者
- 管理者として、不適切な投稿(誹謗中傷・虚偽情報・広告目的の投稿等)を検知し、非表示・削除したい。サイトの信頼性を保つため。
- 管理者として、商品カテゴリ・タグを管理し、サイトの情報構造を整理したい。
- 管理者として、広告枠の掲載状況を管理したい。
### 6.4 事業責任者(将来フェーズ)
- 事業責任者として、蓄積された投稿データ(商品別評価傾向、ユーザー属性等)を集計・分析したい。育児用品販売企業向けのマーケティング支援サービスの提案材料とするため。
---
## 7. 主な機能要件
### 7.1 フロントエンド(利用者向け)機能
- トップページ(新着レビュー、人気商品、カテゴリ導線)
- 商品カテゴリ・キーワードによる検索機能
- 商品ページ(商品情報、レビュー一覧、評価分布表示)
- レビュー投稿機能(評価点、コメント、写真添付)
- 会員登録・ログイン機能(メールアドレス、SNS連携等)
- マイページ(投稿履歴の確認・編集・削除)
- レビューへのリアクション機能(「参考になった」等)
- レスポンシブ対応(スマートフォンでの閲覧・投稿を重視)
### 7.2 管理機能
- 会員・投稿の管理画面(検索、非表示、削除)
- 商品・カテゴリ・タグのマスタ管理
- 広告枠の管理・掲載設定
- 簡易な投稿統計の確認(閲覧数、投稿数の推移等)
### 7.3 将来フェーズ向け機能(拡張性として考慮)
- 投稿データのエクスポート・分析基盤との連携
- 育児用品販売企業向けレポーティング機能(閲覧・評価傾向の可視化)
---
## 8. 非機能要件
### 8.1 可用性
- 一般消費者向けサービスとして、通常時間帯における高い可用性を確保すること。
- 単一障害点(SPOF)をできる限り排除した構成が望ましい(ただし過剰投資は避け、コストとのバランスを考慮すること)。
- 障害発生時の影響範囲・復旧方針について提案に含めること。
### 8.2 性能・拡張性
- スモールスタート時の想定アクセス数でも快適な応答性能を確保すること。
- 将来的な利用者数・投稿数の増加に対し、インフラ構成の変更(スケールアウト・スケールアップ)により対応できること。大規模な作り直しを要しない設計を評価する。
- アクセス急増時(SNSでの話題化等)にも耐えられる、または迅速にスケールできる構成であることが望ましい。
### 8.3 セキュリティ
- 会員情報(個人情報)を取り扱うため、適切なアクセス制御・データ保護対策を講じること。
- 不正投稿・スパム・なりすまし等への対策方針を含めること。
- Google Cloud上のセキュリティベストプラクティス(IAM権限設計、ネットワーク境界設計等)に基づく構成とすること。
### 8.4 運用・保守性
- 運用にかかる人件費を抑えるため、マネージドサービスの活用、監視・アラートの自動化、デプロイの自動化(CI/CD)等を積極的に取り入れること。
- 障害検知から復旧までの運用フローについても提案に含めること。
- 開発・運用体制の人数が少数であることを前提とした、保守しやすい構成・技術選定であること。
---
## 9. その他、重要視している点
- **コスト効率**:初期費用・ランニングコスト・運用人件費のいずれも抑制すること。単純な機能実現だけでなく、コストパフォーマンスの観点を重視する。
- **段階的な拡張のしやすさ**:スモールスタートから将来のデータ活用・機能拡張へ無理なく移行できる設計であること。
- **Google Cloudの活用**:全社的に利用実績のあるGoogle Cloudの各種マネージドサービスを積極的に活用し、運用負荷を下げること。
- **モバイル利用への最適化**:育児中のユーザーはスマートフォンでの利用が中心になると想定されるため、UX・パフォーマンスの両面で配慮すること。
- **将来のデータ活用を見据えた設計**:デジタルマーケティング支援事業への発展を見据え、投稿データを後から分析・活用しやすいデータ設計・保存方式であることが望ましい。
---
## 10. 提案に含めていただきたい内容
各提案者は、以下の内容を含めて提案書を作成すること。
1. システム構成図(Google Cloud上の利用サービス、ネットワーク構成等)
2. 上記「主な機能要件」「非機能要件」への対応方針
3. 概算コスト試算(初期費用・月額ランニングコスト、想定利用規模別の変動を含む)
4. 運用・保守体制および想定される運用人件費・工数
5. 将来の利用者増加・機能拡張(データ分析基盤等)への対応方針
6. 構成案の採用によるリスク・留意点
---
## 11. 提出・評価について
- 提案書の提出期限、フォーマット、評価基準(コスト、拡張性、実現性、運用負荷等の重み付け)については別途案内する。
- 事業責任者が各提案を比較評価し、採用案を決定する。
Claude提案依頼書を作成してもらった際のプロンプト
システム開発の提案依頼書を作成してください。
## 背景
従業員十数名のスタートアップ企業です。
一人目の育児を経験している両親向けに育児用品のレビューサイトを新規事業として立ち上げたいと考えています。
この企業では既にGoogle Cloudを利用しているため、Google Cloud上にサイトを構築する方針です。
新規事業の責任者であるあなたは複数名の部下にシステム構成を検討させ、より優れた案を採用することにしました。
## 提案依頼書に必須で入れる内容
### 事業概要
日本市場をターゲットに育児用品のレビューサイトを運営します。
主な収入源は以下を想定しています。
1. 広告収入 ※初期段階
2. 育児用品販売企業向けのデジタルマーケティング支援 ※サイト運営が軌道に乗ったら投稿データを利用して開始
### 予算
できる限り少ない初期費で構築し、ランニングコストも抑えたいと考えています。
運用に必要な人件費もできる限り低減する必要があります。
### 拡張性
スモールスタートで開始したいですが、将来的に利用者が増えても対応できるようスケーラブルな構成が望ましいです。
## その他、提案依頼書に含める要素
* サイトに関わる登場人物の一覧
* ユーザーストーリー
* 主な機能要件
* 非機能要件(可用性、性能・拡張性、セキュリティ、運用・保守性)
* その他、重要視していること
評価基準
評価結果がブレないよう、実際に評価してもらう前に評価基準を準備してもらいました。
Claudeに作成してもらった評価基準
# システム構成案 評価基準
## 育児用品レビューサイト 新規事業
提案依頼書(RFP)の要件に基づき、各提案案を以下の基準で評価する。
---
## 1. 評価の考え方
- 各評価項目を **5段階(1〜5点)** で採点する。
- 項目ごとに **重み(配点)** を設定し、加重合計点で比較する。
- 「予算(コスト)」と「拡張性」は事業責任者として特に重視する方針のため、重みを高めに設定している。
| 点数 | 評価の目安 |
| ---- | ------------------------------------------------- |
| 5 | 要件を大幅に上回って満たしている/非常に優れている |
| 4 | 要件を十分に満たしている |
| 3 | 要件を最低限満たしている |
| 2 | 要件を一部満たしていない/懸念がある |
| 1 | 要件を満たしていない/大きな懸念がある |
---
## 2. 評価項目・配点
| No | 評価項目 | 重み | 評価の観点 |
| --- | ------------------------ | ------- | ---------------------------------------------------------------------------------------------------------- |
| 1 | 初期構築コスト | 15 | 初期費用がどの程度低く抑えられているか |
| 2 | ランニングコスト | 15 | 月額のインフラ費用・従量課金がスモールスタート規模で低く抑えられているか。利用増加時のコスト増加の緩やかさ |
| 3 | 運用・保守にかかる人件費 | 15 | マネージドサービス活用や自動化により、少人数での運用・保守が可能な構成か |
| 4 | 拡張性・スケーラビリティ | 20 | 将来の利用者・投稿数増加時に、大規模な再設計なしでスケールできるか。データ分析基盤等への発展のしやすさ |
| 5 | 可用性 | 10 | 単一障害点の排除、障害時の影響範囲・復旧のしやすさ(過剰投資でないか) |
| 6 | セキュリティ | 10 | 会員の個人情報保護、不正投稿・スパム対策、IAM等の権限設計の妥当性 |
| 7 | 機能要件の充足度 | 10 | RFPで挙げた主な機能要件(投稿・検索・会員管理・管理画面等)をどの程度満たしているか |
| 8 | 実現性・リスク | 5 | 提案内容の実現可能性、技術的リスク、構築期間の妥当性 |
| | **合計** | **100** | |
---
## 3. 採点シート(記入用)
| No | 評価項目 | 重み | 案A 点数 | 案A 加重点 | 案B 点数 | 案B 加重点 | コメント |
| --- | ------------------------ | ------- | -------- | ---------- | -------- | ---------- | -------- |
| 1 | 初期構築コスト | 15 | | | | | |
| 2 | ランニングコスト | 15 | | | | | |
| 3 | 運用・保守人件費 | 15 | | | | | |
| 4 | 拡張性・スケーラビリティ | 20 | | | | | |
| 5 | 可用性 | 10 | | | | | |
| 6 | セキュリティ | 10 | | | | | |
| 7 | 機能要件の充足度 | 10 | | | | | |
| 8 | 実現性・リスク | 5 | | | | | |
| | **合計** | **100** | | | | | |
※ 加重点 = 点数(1〜5) × 重み ÷ 5
---
## 4. 補足
- 同点・僅差の場合は、「拡張性」「ランニングコスト」を優先する項目として扱う(将来のデータ活用事業への発展を見据えているため)。
- 各項目について、単なる点数だけでなく懸念点・リスクをコメント欄に残し、最終判断の材料とする。
私の設計(A案)
システム構成図
アーキテクチャのポイント
1. 公開サイトの検索結果画面以外をSSGで構成し、低レイテンシと低コストを実現
ユーザ向けのレビューサイトは検索結果画面を除き、リアルタイムなデータ検索が不要と予想します。
そこで、SSGとCSR/SSRを併用できるフレームワーク(Next.js等)を採用し、検索結果以外の画面をSSGとすることでユーザアクセス時のDB検索を不要とします。
SSGの更新はCloud Buildによって定期的に実行します。
2. 不適切なコメント・画像の自動検閲で運用負荷を低減
ユーザがコンテンツを投稿するサイトでは、不適切な投稿がない状態を維持することが重要です。
しかし、ユーザ数が増加するにつれて人間による検閲は困難になります。
そこで、ユーザ投稿をまず検閲用のDB・ストレージに保存し、AIが自動検閲してクリアした場合のみサイト上に公開される仕組みを構築します。
3. サーバーレスを中心とした製品選定で運用コストを低減
Cloud Run、Firestore、Cloud Storageなど、サーバーレス製品を中心に構成します。
これらの製品は利用料に応じた従量課金であるため、ユーザが少ないうちはクラウド利用料が比較的低額です。
また、インフラの維持管理が不要なため、運用に必要な人員を抑えることができます。
4. 将来的なデータ分析機能の構築に向けたデータ連携
将来的にBigQueryにもデータを蓄積することを見据え、検閲済みのコメントはPub/Subを介す構成とします。
これにより、BigQueryにデータを蓄積開始する際は、データの初期登録してからPub/SubにBigQueryサブスクリプションを追加するだけでニアリアルにデータ連携できます。
Antigravity CLIの設計(B案)
Antigravity CLIに設計してもらった際のプロンプト
後述の提案依頼書に対する提案書を作成してください。
提案書は以下を遵守して作成してください。
* システム構成図をdrawio形式で作成してください
* システム構成図の中から重要事項を最大4つまで説明してください
* 重要事項以外の説明は不要です
* 簡潔な文章を作成してください
----
(以下、Claudeに作成してもらった提案依頼書)
システム構成図
線が重なっていたり、アイコンが非表示になっていたりと見ずらい図ですが、プロンプトによる指示ではこれ以上きれいにできなかったので諦めました。
drawioで作図させるための私のプロンプト力が足りないのかもしれません…
今回は勝負なので、手を加えずこのままClaudeに評価してもらいます。
アーキテクチャのポイント
システム構成における重要事項4点は以下の通りです。
1. Firebase Hosting & Cloud Run によるサーバーレス・低コスト運用
フロントエンド配信に Firebase Hosting、APIバックエンドに Cloud Runを採用します。リクエストがない時間帯はサーバーレスで自動的に料金がほぼゼロになるため、極小コストでのスモールスタートを実現します。また、アクセス急増時にも自動で即座にスケールアウトします。
2. Firebase Authentication による安全な会員認証の早期構築
会員登録やSNS連携（Google、LINE等）に Firebase Authenticationを採用します。認証セキュリティ対策をマネージドに一任することで、初期の開発工数を大幅に削減し、運用保守人件費を抑制します。
3. Cloud SQL から Datastream・BigQuery への将来的なデータ分析拡張性
トランザクションDBには Cloud SQL for PostgreSQL の最小構成を採用して初期コストを抑えます。将来のマーケティング支援事業に向け、Datastream で BigQueryにデータをニアリアルタイム同期し、本番DBに負荷をかけない分析基盤へ容易にスケール可能です。
4. AI API による不適切コンテンツの自動一次検知
投稿レビューの画像・テキストを Cloud Vision API と Natural Language APIで自動スキャンします。誹謗中傷や不適切画像を自動で検知して非表示にする仕組みを構築し、サイト管理者の監視コストと人件費を削減します。
Claudeによる厳正な評価結果
# システム構成案 評価結果
## A案 vs B案
評価基準(評価基準\_システム構成案.md)に基づき、両案を採点した。
---
## 1. 採点結果
| No | 評価項目 | 重み | 案A 点数 | 案A 加重点 | 案B 点数 | 案B 加重点 |
| --- | ------------------------ | ------- | -------- | ---------- | -------- | ---------- |
| 1 | 初期構築コスト | 15 | 3 | 9.0 | 4 | 12.0 |
| 2 | ランニングコスト | 15 | 3 | 9.0 | 4 | 12.0 |
| 3 | 運用・保守人件費 | 15 | 3 | 9.0 | 4 | 12.0 |
| 4 | 拡張性・スケーラビリティ | 20 | 5 | 20.0 | 5 | 20.0 |
| 5 | 可用性 | 10 | 4 | 8.0 | 3 | 6.0 |
| 6 | セキュリティ | 10 | 5 | 10.0 | 3 | 6.0 |
| 7 | 機能要件の充足度 | 10 | 4 | 8.0 | 4 | 8.0 |
| 8 | 実現性・リスク | 5 | 3 | 3.0 | 4 | 4.0 |
| | **合計** | **100** | | **76.0** | | **80.0** |
**結論:B案がわずかに優位(80.0点 vs 76.0点)**
---
## 2. 項目別コメント
### 1. 初期構築コスト
- **A案(3点)**:Cloud Run×5系統、Firestore×2、Pub/Sub、Load Balancing、Cloud Armor、IAP、Gemini Enterprise Agent Runtime など構成要素が多く、構築の難易度・工数はB案より高い。
- **B案(4点)**:Firebase Hosting/Auth、Cloud Run、Cloud SQL、Cloud Storage という定番構成中心で、構築難易度・工数を抑えやすい。
### 2. ランニングコスト
- **A案(3点)**:サーバーレス中心の構成で従量課金は抑えられるが、Load Balancer・Cloud Armorの固定費や、コメント検閲に用いるGemini Enterprise Agent Runtimeの利用料がB案より割高になりやすい。
- **B案(4点)**:Cloud Run・Firebase Hostingはゼロスケール可能で、利用が少ない間は費用をほぼ抑えられる。Cloud SQLのみ最小インスタンスの固定費が発生する点が減点要素。
### 3. 運用・保守人件費
- **A案(3点)**:Pub/Sub、複数Firestore、Gemini Agent Runtimeなど運用対象コンポーネントが多く、扱える人材確保や運用手順の複雑さから人件費がかかりやすい。
- **B案(4点)**:Firebase Authで認証まわりの実装・保守を丸ごとマネージドサービスに委ねられ、構成要素も少ないため少人数運用に向く。
### 4. 拡張性・スケーラビリティ
- **A案(5点)**:検閲済みコメントをPub/Sub経由とし、将来BigQueryへ拡張する際はサブスクリプションを追加するだけで済む、低工数な拡張設計となっている。
- **B案(5点)**:Cloud SQLからDatastream経由でBigQueryへニアリアルタイム同期する拡張経路が明確で、本番DBに負荷をかけずに分析基盤へ拡張できる。
### 5. 可用性
- **A案(4点)**:Load BalancingとCloud Armorを備え、単一障害点への配慮や可用性設計が明示的。
- **B案(3点)**:Firebase HostingのグローバルCDNやCloud Runの自動スケールはあるが、Cloud SQLの冗長化(HA構成)について図中に明記がなく、DB部分が単一障害点になり得る懸念がある。
### 6. セキュリティ
- **A案(5点)**:Cloud Armor(WAF/DDoS対策)、IAPによる管理画面アクセス制限など、公開範囲・管理者アクセスの制御が具体的に設計されている。
- **B案(3点)**:Firebase Authによる会員認証とVision/NL APIでの投稿検閲はあるが、管理操作へのアクセス制御やWAF等のエッジセキュリティ対策が図中に明示されていない。
### 7. 機能要件の充足度
- **A案(4点)**:RFPで求める投稿・検索・会員管理・管理画面などの主要機能を過不足なく満たしている。
- **B案(4点)**:同様に、RFPで求める主要機能を過不足なく満たしている。
### 8. 実現性・リスク
- **A案(3点)**:コメント検閲にGemini Enterprise Agent Runtimeという比較的高度なサービスを採用しており、B案と比べると実装・運用の難易度がやや高い。
- **B案(4点)**:実績のある標準的なマネージドサービス中心の構成であり、実現性が高く実装リスクが低い。
---
## 3. 総評
RFPで重視されている「初期費用・ランニングコスト・運用人件費の抑制」の観点では、B案がシンプルな構成により優位である。一方、「可用性」「セキュリティ」についてはA案がCloud ArmorやIAPによる具体的な対策を備えており優位である。拡張性・機能要件の充足度については両案とも同等の評価となった。
総合点差はわずか4点(B案80.0点、A案76.0点)であり、いずれを採用しても大きな問題はないと考えられる。
### 推奨
1. **コスト最優先の場合**:B案を採用しつつ、A案の強みであるCloud Armor(WAF)・IAPによるアクセス制御をB案に追加する形で改善を依頼する。
2. **可用性・セキュリティを優先する場合**:A案を採用しつつ、コメント検閲部分をGemini Enterprise Agent RuntimeからよりシンプルなCloud Vision API/NL API構成に見直すことで、コスト・運用負荷をさらに下げられないか提案者に確認する。
ま…負けたぁぁーーーー!!!
4点差で…
評価基準を見ると初期費用・ランニングコストの配点が多く、その部分でAntigravity CLIに負けていたようです…
Agent Runtimeを利用したのがコスト観点で悪手とみなされてしまいました…
最後に
今回は負けてしまいましたが、実現方式の解像度やセキュリティなどではAntigravity CLIに負けていなかったと思います。(負け惜しみ)
製品選定に違いはあるものの、考え方は思った以上に似ていたなと思いました。
もしかしたらお題に自由度が少なかったのかもしれません。
やってみて感じたことは以下の二つです。
- AIとの対決は自身の設計スキルを磨く良い機会になる
- アーキテクチャ設計する際、AIに叩いてもらうことで精度を上げられそう
特に1点目のスキルを磨く機会はとても良いと感じました。
今後も時々戦ってみようと思います。今度こそ勝ってやる…!!