Agent SkillsとSubagentsで同一要件からAWSとGoogle Cloudのインフラ設計を同時生成・比較してみた

目次

1.はじめに
2.Subagentsの作成
3.Agent Skillsの作成
4.SkillとSubagentの実行
5.おわりに

1.はじめに

パブリッククラウド環境でシステム構築を検討する際、AWS と Google Cloud のどちらを使用するか、それぞれの環境でどのようなアーキテクチャとすべきか、吟味するポイントかと思います。

そこで、Gemini CLI の Agent Skills と Subagents、AWS の AWS Knowledge MCP Server、Google の Developer Knowledge MCP server を活用し、ユーザーの要件を入力、そこから AWS と Google Cloud の両方のアーキテクチャ案の自動生成、それらの比較結果生成までを自動化してみました。

本ブログでは、AWS と Google Cloud それぞれのアーキテクチャ案作成 Subagent から、その Subagent を実行するための Agent Skills の Skill の作成、その Skill を実行してみた結果を紹介します。

2.Subagentsの作成

Subagents について、Gemini CLI の公式ドキュメントベースではありますが、簡単に説明します。

Subagents は メインのエージェンから特定のタスクを委任され、そのタスクを実行するエージェントになります。
サブエージェントはタスクを完了すると、その結果をメインエージェント（今回であれば Agent Skills の Skill を実行している主体）に返します。

この形により特定のタスクの実行に関わるコンテキストでメインエージェントのメモリ圧迫や不要な情報の混在を防ぐことができます。

Gemini CLI の Subagents において、組み込み Subagents の他に独自 Subagents（カスタムエージェント）を作成できます。
本ブログではカスタムエージェントとして、AWS と Google Cloud のアーキテクチャ案作成 Subagent を作ります。

カスタムエージェントの設定については、YAML フロントマターを含む Markdown ファイルの作成と配置が必要です。
プロジェクトレベルであれば、.gemini/agents/*.md、ユーザーレベル（グローバルに使用可能）であれば、~/.gemini/agents/*.md に配置します。

Gemini CLI でのカスタムエージェントの使用については、settings.json で以下を設定する必要があります。

〜〜省略〜〜
"experimental": {
    "enableAgents": true
  }
〜〜省略〜〜

本ブログ執筆時点では、Gemini CLI の Subagents は experimental 版で、正式リリース前状態であるため、このような設定が必要なのかと思われます。
（後続の Subagent 作成前にこの設定を実施の上、作業を進めております）

簡単な説明は以上になります。
詳細については 公式ドキュメントを参照ください。

AWSのアーキテクチャ案作成Subagentについて

Subagent の作成にあたり、YAML フロントマターとして Subagent の名前、機能に関する簡単な説明の定義が必須となります。
他はオプション設定となります。

この Subagent のオプション設定ですが、tools には AWS Knowledge MCP Server のツールを明記しています。
model については、gemini-2.5-flash、温度は0.0です。他のオプション項目はデフォルトとしています。

gemini-2.5-flash 指定の経緯として、この Subagent のプロンプトには AWS の公式ドキュメントを唯一の情報源としてアーキテクト案を生成する旨の記載をするので、モデルに高度な創造的推論機能は不要と考えたからです。代わりに応答速度やトークンコストでメリットのある gemini-2.5-flash を指定することとしました。

温度については0.0で推測や創造的補完を極力排除する設定としました。
AWS の公式ドキュメントを唯一の情報源としてアーキテクト案を生成し、出力に揺らぎがない形が好ましいという意図もあります。

YAML フロントマターは以上で、その下に具体的な Subagent の処理内容を定義します。
詳細は以下の通り AWS の AWS Knowledge MCP Server を活用し、ユーザーからの要件に基づくアーキテクト案を生成する旨を定義しています。

---
name: aws-architect
description: AWSの観点から、公式ドキュメント（MCP）に基づきアーキテクチャ案・サービス構成・料金情報を提示するサブエージェント。
kind: local
tools:
  - aws___search_documentation
  - aws___read_documentation
  - aws___recommend
  - aws___list_regions
  - aws___get_regional_availability
model: gemini-2.5-flash
temperature: 0.0
max_turns: 15
---

あなたは AWS 専門のクラウドアーキテクトAIです。
AWSの観点から最適なアーキテクチャ構成案を提示することが役割です。

ただし、必ず公式ドキュメント（MCP）に基づいて回答してください。
推測や一般論は禁止です。

---

## 目的

- AWSを用いたアーキテクチャ案を提示する
- 使用すべきサービスを明示する
- 料金や制約事項について公式情報を根拠として提示する
- ハルシネーションを防止する
- 将来的なマルチクラウド比較に耐えうる構造で出力する

---

## 使用可能なMCPツール

### 1. aws___search_documentation

- Search across all AWS documentation with optional topic-based filtering for more targeted result

### 2. aws___read_documentation

- Retrieve and convert AWS documentation pages to markdown

### 3. aws___recommend

- Get content recommendations for AWS documentation pages

### 4. aws___list_regions

- Retrieve a list of all AWS regions, including their identifiers and names

### 5. aws___get_regional_availability

- Retrieve AWS regional availability information for Services, Features, SDK service APIs and CloudFormation resources

---

## 必須ワークフロー

AWSに関する設計・移行・構成の質問を受けた場合：

1. 必ず aws___search_documentation を実行
2. 必要に応じて aws___recommend で関連ドキュメントを補完
3. aws___read_documentation で本文を確認
4. サービスのリージョン制約が関係する場合は aws___get_regional_availability を確認
5. 公式記述を根拠に設計案を構築する

---

## アーキテクトとしての思考指針

設計提案を行う際は以下を明示すること：

- コンピュート層（例：EC2 / ECS / EKS / Lambda など）
- ストレージ層（S3 / EBS / EFS など）
- データベース層（RDS / Aurora など）
- ネットワーク構成（VPC / ALB / NAT など）
- 可用性設計（マルチAZ / マルチリージョン）
- スケーリング方式（Auto Scaling 等）
- セキュリティ関連サービス（IAM / WAF など）
- バックアップ戦略
- マネージドサービスの活用有無

必ず公式ドキュメントに記載がある範囲で説明すること。

---

## 料金について

- 料金に関する質問が含まれる場合、必ず公式料金ドキュメントを検索する
- サービス単価は公式ドキュメントを根拠に確認する
- 想定構成に基づき概算を算出してよい

ただし、以下を必ず守ること：

- 金額は「目安（概算）」であることを明示する
- 実際の料金は利用量・リージョン・割引・為替などにより変動することを明記する
- 正式な見積りには AWS Pricing Calculator の利用を推奨する
- ドキュメントに記載がない単価は推測しない

---

## 厳守ルール

- MCPを使わずに回答してはいけない
- 記憶ベースで断定してはいけない
- 他クラウドと比較しない
- ドキュメントに記載がない場合は明示する
- Preview / GA の区別を確認する
- リージョン依存制約は必ず確認する

---

## 出力フォーマット（比較前提構造）

### 1. 推奨アーキテクチャ概要
（AWSでの構成案）

### 2. 使用サービス一覧
- サービス名
- 役割

### 3. 可用性・スケーリング設計

### 4. 料金概算（目安）

※ 以下は公式料金情報を基にした概算です。
実際の料金は利用状況・リージョン・割引条件等により変動します。

- サービスごとの想定コスト内訳
- 月額概算合計

### 5. 制約事項・注意点

### 6. 公式ドキュメント根拠
- ドキュメント名
- URL
- 該当箇所の要約

---

## 禁止事項

- 他クラウドとの優劣比較
- ドキュメント未確認の設計断定

---

あなたの役割は「AWS側の公式ベースアーキテクト」です。
AWSの視点に集中してください。

ハルシネーションは重大な失敗です。
必ずMCPを使用してください。

この内容の Markdown ファイル（aws-architect.md）を以下ディレクトリに配置しました。

/Users/名前/.gemini/
└── agents/ # Subagents を格納するディレクトリ
    └── aws-architect.md # AWS のアーキテクチャ案作成 Subagent

AWS 用の Subagent の設定はこれで以上です。

Google Cloudのアーキテクチャ案作成Subagentについて

Google Cloud 用の Subagent の設定について、AWS 用 Subagent とほぼ同じ構造となります。

こちらは Google Cloud のドキュメントを情報源としてアーキテクト案を生成して欲しいので、 Developer Knowledge MCP server を指定しています。

YAML フロントマター、具体的な Subagent の処理内容は以下です。

---
name: google-cloud-architect
description: Google Cloudの観点から、公式ドキュメント（MCP）に基づきアーキテクチャ案・サービス構成・料金情報を提示するサブエージェント。
kind: local
tools:
  - google-developer-knowledge__search_documents
  - google-developer-knowledge__get_document
  - google-developer-knowledge__batch_get_documents
model: gemini-2.5-flash
temperature: 0.0
max_turns: 15
---

あなたは Google Cloud 専門のクラウドアーキテクトAIです。
Google Cloudの観点から最適なアーキテクチャ構成案を提示することが役割です。

ただし、必ず公式ドキュメント（MCP）に基づいて回答してください。
推測や一般論は禁止です。

---

## 目的

- Google Cloudを用いたアーキテクチャ案を提示する
- 使用すべきサービスを明示する
- 料金や制約事項について公式情報を根拠として提示する
- ハルシネーションを防止する
- 将来的なマルチクラウド比較に耐えうる構造で出力する

---

## 使用可能なMCPツール

### 1. search_documents

- Searches Google's developer documentation (Firebase, Google Cloud, Android, Maps, and more) to find relevant pages and snippets for your query. Use get_document or batch_get_documents with the parent from search results to get full page content.

### 2. get_document

- Gets the full content of a document using the parent from a search_documents result.

### 3. batch_get_documents

- Gets the full content of multiple documents using parents from search_documents results.

---

## 必須ワークフロー

Google Cloudに関する設計・移行・構成の質問を受けた場合：

1. 必ず search_documents を実行
2. 関連ドキュメントを特定
3. get_document または batch_get_documents で全文確認
4. 公式記述を根拠に設計案を構築する

---

## アーキテクトとしての思考指針

設計提案を行う際は以下を明示すること：

- コンピュート層（例：VM / マネージドサービス）
- ストレージ層
- ネットワーク構成
- 可用性設計（リージョン / マルチゾーン）
- スケーリング方式
- セキュリティ関連サービス
- バックアップ戦略
- マネージドサービスの有無

必ず公式ドキュメントに記載がある範囲で説明すること。

---

## 料金について

- 料金に関する質問が含まれる場合、必ず公式料金ドキュメントを検索する
- サービス単価は公式ドキュメントを根拠に確認する
- 想定構成に基づき概算を算出してよい

ただし、以下を必ず守ること：

- 金額は「目安（概算）」であることを明示する
- 実際の料金は利用量・リージョン・割引・為替などにより変動することを明記する
- 正式な見積りには Google Cloud Pricing Calculator の利用を推奨する
- ドキュメントに記載がない単価は推測しない

---

## 厳守ルール

- MCPを使わずに回答してはいけない
- 記憶ベースで断定してはいけない
- 他クラウドと比較しない
- ドキュメントに記載がない場合は明示する
- Beta / Preview / GA を必ず確認する
- リージョン依存制約は必ず確認する

---

## 出力フォーマット（比較前提構造）

### 1. 推奨アーキテクチャ概要
（Google Cloudでの構成案）

### 2. 使用サービス一覧
- サービス名
- 役割

### 3. 可用性・スケーリング設計

### 4. 料金概算（目安）

※ 以下は公式料金情報を基にした概算です。
実際の料金は利用状況・リージョン・割引条件等により変動します。

- サービスごとの想定コスト内訳
- 月額概算合計

### 5. 制約事項・注意点

### 6. 公式ドキュメント根拠
- ドキュメント名
- URL
- 該当箇所の要約

---

## 禁止事項

- 他クラウドとの優劣比較
- ドキュメント未確認の設計断定

---

あなたの役割は「Google Cloud側の公式ベースアーキテクト」です。
Google Cloudの視点に集中してください。

ハルシネーションは重大な失敗です。
必ずMCPを使用してください。

この内容の Markdown ファイル（google-cloud-architect.md）を以下ディレクトリに配置しました。

/Users/名前/.gemini/
└── agents/ # Subagents を格納するディレクトリ
    ├── aws-architect.md # AWS のアーキテクチャ案作成 Subagent
    └── google-cloud-architect.md # Google Cloud のアーキテクチャ案作成 Subagent

Subagent 作成については、これで以上です。
続いて Agent Skills の Skill 作成についてです。

3.Agent Skillsの作成

cloud-architecture-comparison-skillの作成について

ユーザープロンプトにて要件を入力した際に起動する Skill を作成します。

そもそも Agent Skills とは? というところの説明は本ブログではスキップします。
Agent Skills について知りたい方は弊社ブログ Claude CodeとGemini CLIでAgent Skillsを使ってみた を参照ください。

作成する Skill としては、

• システム構築要件の入力に伴い起動する。
• システム構築要件を抽出、2つの Subagent に対して設計タスクを指示し、Subagent を実行させる。
• 2つの Subagent の実行結果を受け取り、aws.md（AWS 構成案）、googlecloud.md（Google Cloud 構成案）、comparison.md（各構成の比較結果） を作成し、./outputs/ ディレクトリに保存する。

の機能を持つものとします。

Skill の作成については、Gemini CLI の組み込み skill-creator で行いました。
そもそも組み込み skill-creatorとは？というところの説明は本ブログではスキップします。
組み込み skill-creator について知りたい方は弊社ブログ Gemini CLIの組み込みskill-creatorを使ってみた を参照ください。

組み込み skill-creator にて上記機能を持つ Skill の作成を依頼します。
作成された SKILL.md の内容は以下です。

---
name: cloud-architecture-comparison-skill
description: ユーザーのシステム構築要件（業務要件および非機能要件を含む）に基づき、独立した設計エージェントを使用してAWSとGoogle Cloudそれぞれのアーキテクチャ構成を作成します。それぞれの設計結果を個別に出力し、さらに両者の比較マークダウンファイルを生成します。クラウド上でのシステム構築におけるアーキテクチャの検討が必要な様々なシナリオで使用します。
---

# クラウドアーキテクチャ比較分析スキル

## 概要
このスキルは、ユーザーが提示するシステム要件に基づき、AWSとGoogle Cloudにおける最適なアーキテクチャ構成を比較分析します。
AWS設計エージェントとGoogle Cloud設計エージェントを並列実行し、それぞれのクラウド環境での推奨構成を設計させます。
最終的に、各クラウドの構成案と両者の比較分析をまとめた3つのマークダウンファイルを自動生成し、ユーザーに提供します。

## ワークフロー

### 1. ユーザー入力の受け取り
ユーザーからの質問（例: 「Kubernetes ベースのマイクロサービスアーキテクチャを構築したいのですが、AWS と Google Cloud でそれぞれどんな構成になりますか？」）を受け取り、システム要件を抽出します。

### 2. Skill の実行
- 抽出されたシステム要件を基に、`aws-architect` と `google-cloud-architect` の2つのsubagentに対して設計タスクを指示します。
- これら2つのsubagentは並列で実行されます。

### 3. Subagents の実行（独立した動作）
#### Subagent 1: AWS 設計エージェント
- 公式ドキュメント（MCP）を参照し、入力されたシステム要件に基づいてAWSでの推奨構成を設計します。
- 設計結果を構造化された形式で返却します。

#### Subagent 2: Google Cloud 設計エージェント
- 公式ドキュメント（MCP）を参照し、入力されたシステム要件に基づいてGoogle Cloudでの推奨構成を設計します。
- 設計結果を構造化された形式で返却します。

### 4. Skill での結果の統合と出力
Skill は両 subagent からの結果を受け取り、以下の3つのマークダウンファイルを生成します。

#### Output 1: `aws.md`
- AWS 設計エージェントの出力をそのまま整形し、詳細なAWS構成案としてこのファイルに書き込みます。

#### Output 2: `googlecloud.md`
- Google Cloud 設計エージェントの出力をそのまま整形し、詳細なGoogle Cloud構成案としてこのファイルに書き込みます。

#### Output 3: `comparison.md`
- AWS 設計エージェントと Google Cloud 設計エージェントの出力内容を比較分析し、比較表、メリット・デメリット、総合的な考察をまとめた形でこのファイルに書き込みます。

これらのファイルは、実行時に生成される `./outputs/` ディレクトリに保存されます。

## スキルが持つべき機能

### A. Subagent 管理機能
- `aws-architect` および `google-cloud-architect` subagentを並列実行し、それぞれの設計結果を正確に受け取ります。

### B. マークダウン生成機能
- `aws.md`：AWS設計の詳細を構造化して出力します。
- `googlecloud.md`：GCP設計の詳細を構造化して出力します。
- `comparison.md`：両クラウドの比較表と分析を見やすく整理して出力します。

### C. ファイル出力機能
- 生成された`aws.md`、`googlecloud.md`、`comparison.md`の3つのマークダウンファイルを、実行時に自動生成される`./outputs/`ディレクトリに保存します。

Skill をグローバルに使用できるよう以下のディレクトリに SKILL.md を配置します。

/Users/名前/.gemini/
└── skills/ # Agent Skills を格納するディレクトリ
    └── cloud-architecture-comparison-skill # クラウドアーキテクチャ比較分析 Agent Skills の定義を格納するディレクトリ
        └── SKILL.md # この Skill のワークフロー、持つべき機能を記載したドキュメント

Skill の作成はこれで以上です。
続いては作成した Skill を実際に動かしてみます。

4.SkillとSubagentの実行

動作環境や利用モデル、事前準備については以下の通りです。

動作環境

• macOS：Tahoe 26.2
• Node.js のバージョン（ node –version ）：24.11.1
• Gemini CLI のバージョン（ gemini –version ）：0.28.2

利用モデル

• gemini-2.5-flash

事前準備

• Gemini CLI に MCP を設定：AWS Knowledge MCP Server と Developer Knowledge MCP server

上記設定のもと、Gemini CLI を立ち上げ Skill を実行します。
ちなみに利用モデルは gemini-2.5-flash です。Subagents の実行結果を受け取り、Markdown ファイルの生成と AWS、Google Cloud の構成比較・結果出力に作業が限定されており、複雑な思考処理は要求しないためです。代わりに応答速度やトークンコストでメリットのあるモデルとしました。

SkillとSubagentの実行について

では、Gemini CLI を立ち上げ、要件を入力しSkill が起動、各 Subagent も起動、アーキテクチャ案とそれの比較結果 Markdown ファイルが生成されるか見ていきます。

Gemini CLI を立ち上げました。

MCP と Subagent、Skill は以下の通りです。

 > /mcp list                                                                                                                      
Configured MCP servers:

🟢 aws-knowledge-mcp-server - Ready (5 tools)
  Tools:
  - aws___get_regional_availability
  - aws___list_regions
  - aws___read_documentation
  - aws___recommend
  - aws___search_documentation

🟢 google-developer-knowledge - Ready (3 tools)
  Tools:
  - batch_get_documents
  - get_document
  - search_documents

/agents list コマンドで利用できる Subagent が確認できます。
Codebase Investigator Agent (codebase_investigator) と CLI Help Agent (cli_help) は Gemini CLI の組み込み Subagent で、aws-architect と google-cloud-architect が今回作成した Subagent になります。

〜〜省略〜〜  
- aws-architect
    AWSの観点から、公式ドキュメント（MCP）に基づきアーキテクチャ案・サービス構成・料金情報を提示するサブエージェント。  
- google-cloud-architect
    Google Cloudの観点から、公式ドキュメント（MCP）に基づきアーキテクチャ案・サービス構成・料金情報を提示するサブエージェント。

Skill は以下です。

Available Agent Skills:

  - cloud-architecture-comparison-skill
      ユーザーのシステム構築要件（業務要件および非機能要件を含む）に基づき、独立した設計エージェントを使用してAWSとGoogle
      Cloudそれぞれのアーキテクチャ構成を作成します。それぞれの設計結果を個別に出力し、さらに両者の比較マークダウンファイルを生成します。クラウド上でのシステム構築におけるアーキテクチャの検討
      が必要な様々なシナリオで使用します。

では、ユーザープロンプトを入力します。
Gemini CLI を立ち上げているプロジェクトディレクトリ直下にユーザーの要件を記載したテキストファイルを用意し、その内容に基づきアーキテクチャ作成と比較分析を実行する旨を指示します。

テキストファイルの内容は以下で、生成 AI を活用したサイト内検索機能についてです。

生成AI を活用したサイト内検索機能
生成AIを活用したサイト内検索機能を検討しています。
現在、公式ウェブサイトには約1万ページの情報が掲載されていますが、利用者から「欲しい情報にたどり着けない」という問い合わせが多く寄せられています。
既存の検索機能はキーワードが完全一致しないとヒットしないため、「検索したのに見つからない」というケースが頻発しています。
自然言語で質問でき、キーワードが一致していなくても意味を理解して関連情報を提示できるような仕組みにしたいと考えています。
また、単一ページだけでなく、複数ページの内容を横断して要点をまとめた回答ができることが理想です。
対象ページ数は約1万ページ規模で、商用サイトとして安定稼働できる構成を希望します。
応答時間は数秒以内が望ましく、一般的なWebサービス水準の可用性を確保したいです。
コンテンツは随時更新されるため、更新内容を検索結果に反映できる仕組みも必要です。
主な利用者は日本国内を想定しています。
このような要件を満たすクラウドアーキテクチャを検討してください。料金の目安もあれば知りたいです。

ユーザープロンプトは以下です。

> システム構築要件.txt の内容に基づき、AWS と Google Cloud のアーキテクチャをそれぞれ設計し、比較分析まで行ってください。

ユーザープロンプトを入力すると 作成した Skill が起動しました。

✓  Activate Skill "cloud-architecture-comparison-skill"

要件を抽出し、Subagent の実行に進みます。

これから、aws_architectとgoogle_cloud_architectツールを使用して、それぞれのクラウドアーキテクチャ設計を依頼します。

aws-architect と google-cloud-architect が実行されました。

 ✓  aws-architect Delegating to agent 'aws-architect'                                                                           │
                                                                                                                               │
Subagent aws-architect Finished 

✓  google-cloud-architect Delegating to agent 'google-cloud-architect'                                                         │
                                                                                                                              │
Subagent google-cloud-architect Finished 

各 Subagent からの設計結果を受け取り、Markdown ファイルの生成に進みます。

ここからは出力内容が長くなるので、画面キャプチャの掲載は省略し、処理の実行および完了が確認できる要点のみを記載します。
以下の通りです。

✦ outputsディレクトリが作成されたので、今から3つのマークダウンファイルを生成し、それぞれoutputs/aws.md、outputs/googlecloud.md、ou
  tputs/comparison.mdとして書き込みます。


  まず、AWSアーキテクトの出力結果をoutputs/aws.mdに書き込みます。
〜〜省略〜〜
✓  WriteFile Writing to outputs/aws.md
〜〜省略〜〜
✦ outputs/aws.md の作成が完了しました。次に、Google Cloud Architect からの出力結果を outputs/googlecloud.md に書き込みます。
✓  WriteFile Writing to outputs/googlecloud.md 
〜〜省略〜〜
✦ outputs/googlecloud.mdが書き込まれました。次に、計画通りcomparison.mdを生成し、outputsディレクトリに書き込みます。
 ✓  WriteFile Writing to outputs/comparison.md
〜〜省略〜〜
✦ すべてのファイルがoutputsディレクトリに正常に書き込まれました。

  AWSとGoogle Cloudのアーキテクチャ設計および比較分析が完了しました。結果は以下のファイルに生成されています。


   * outputs/aws.md: AWSアーキテクチャの詳細
   * outputs/googlecloud.md: Google Cloudアーキテクチャの詳細
   * outputs/comparison.md: 両クラウドの比較分析


  これらのファイルをご確認ください。

Markdown ファイルが作成されました。
それぞれ内容を見てみます。

aws.mdについて

内容ですが、

• アーキテクチャ全体像について
• 主要サービスの役割分担
• スケーラビリティと可用性
• 月額コスト概算
• 制約事項

が記載されています。

AWSを利用した生成AI活用型サイト内検索機能のアーキテクチャ設計について、以下の通りご提案いたします。

---

### 1. 推奨アーキテクチャ概要

本アーキテクチャは、RAG (Retrieval Augmented Generation) パターンを採用し、Amazon Bedrockによる生成AIと、Amazon OpenSearch Service (ベクトルエンジン) または Amazon Kendraによるセマンティック検索を組み合わせることで、自然言語による質問応答と複数ページ横断での要約を実現します。

**全体像:**

1.  **コンテンツ取り込み・前処理:** 公式ウェブサイトのコンテンツを定期的にクロールまたはイベント駆動で取得し、テキスト抽出、チャンキング（セグメント分割）、エンベディング（ベクトル化）を行います。
2.  **ベクトルデータベース:** ベクトル化されたコンテンツをAmazon OpenSearch Serviceのベクトルエンジン（またはAmazon Kendraのインデックス）に保存します。
3.  **検索・生成:** ユーザーからの自然言語クエリをエンベディングし、ベクトルデータベースで関連ドキュメントを検索（Retrieval）。検索結果を基に、Amazon BedrockのLLMが要約・回答を生成（Generation）します。
4.  **アプリケーション層:** Amazon API GatewayとAWS Lambdaで構成され、ユーザーリクエストの受付、検索・生成ロジックの実行、結果の返却を担います。

---

### 2. 使用サービス一覧

| サービス名 | 役割 |
| :------------------------------- | :-------------------------------------------------------------------------------------------------- |
| **Amazon S3** | ウェブサイトコンテンツのバックアップ、クロール結果、前処理済みデータの一時保管場所。 |
| **AWS Lambda** | コンテンツの取り込みトリガー、前処理、エンベディング、OpenSearch/Kendraへのデータ投入、およびユーザーリクエスト処理のバックエンドロジック実行。 |
| **AWS Fargate (ECS/EKS)** | より複雑なコンテンツ処理や、常時稼働するクロール・データパイプラインが必要な場合。Lambdaの並列処理能力や実行時間制限を超えるワークロードに対応。 |
| **Amazon OpenSearch Service (with vector engine)** | ウェブサイトコンテンツのテキスト埋め込み（ベクトル）を保存し、セマンティック検索を行うベクトルデータベース。k-NN検索をサポート。 |
| **Amazon Kendra** | エンタープライズ検索サービス。ウェブサイトコネクタやセマンティック検索、RAG機能の内蔵オプション。OpenSearch Serviceの代替または併用。 |
| **Amazon Bedrock** | テキスト埋め込みモデル（Titan Embeddings）によるテキストのベクトル化、およびLLMによる質問応答の生成。 |
| **Amazon API Gateway** | フロントエンドからのAPIリクエストを受け付け、Lambda関数を起動するRESTful APIエンドポイント。 |
| **Amazon CloudFront** | 静的コンテンツの配信およびAPI Gatewayへのリクエストをキャッシュし、低レイテンシーと負荷軽減を実現。 |
| **Amazon Route 53** | カスタムドメイン名の設定とDNS解決。 |
| **Amazon DynamoDB** | ユーザーセッション管理、検索履歴、コンテンツメタデータ、アプリケーション設定などの保存。 |
| **Amazon VPC** | プライベートネットワーク空間の構築。 |
| **AWS WAF** | ウェブアプリケーションに対する一般的な攻撃からの保護。 |
| **AWS IAM** | 各サービスへのアクセス制御と権限管理。 |
| **Amazon CloudWatch** | ログ収集、メトリクス監視、アラーム設定。 |
| **AWS CloudTrail** | AWSアカウント内のAPIアクティビティを記録し、セキュリティ監査を可能にする。 |

---

### 3. 可用性・スケーリング設計

*   **マルチAZ配置:**
    *   **Amazon OpenSearch Service:** 複数のアベイラビリティーゾーンにインスタンスを配置し、ゾーン障害からの回復性を確保します。
    *   **Amazon Kendra:** 自動的に高可用性が提供されます。
    *   **AWS Lambda, Amazon API Gateway, Amazon S3, Amazon DynamoDB, Amazon Bedrock:** これらはマネージドサービスであり、AWS側で自動的にマルチAZ冗長化や高可用性が考慮されています。
*   **スケーリング方式:**
    *   **AWS Lambda:** リクエスト数に応じて自動的にスケールアウトします。同時実行数を適切に設定することで、予期せぬ負荷スパイクに対応可能です。
    *   **Amazon OpenSearch Service:** インスタンスタイプやノード数を増やすことで、検索負荷やデータ量に応じてスケールアップ/スケールアウトが可能です。Auto Scalingグループを設定することも推奨されます。
    *   **AWS Fargate:** ECS/EKSのAuto Scaling機能により、タスク数やポッド数を自動的に調整し、必要な処理能力を確保します。
    *   **Amazon API Gateway:** 自動的にスケーリングします。
    *   **Amazon Bedrock:** マネージドサービスとして、要求に応じてスケーリングされます。
*   **日本国内利用者への最適化:**
    *   AWS東京リージョン（ap-northeast-1）でのサービス展開を基本とします。
    *   Amazon CloudFrontを利用してコンテンツおよびAPIレスポンスをエッジロケーションでキャッシュし、エンドユーザーへの配信速度を向上させます。

---

### 4. 料金概算（目安）

**※ 以下は公式料金情報を基にした概算です。実際の料金は利用状況・リージョン・割引・為替などにより変動することを明記します。正式な見積りには AWS Pricing Calculator の利用を推奨します。**

約1万ページのウェブサイトに対して、月に数万回の検索リクエストが発生する一般的なケースを想定した概算です。

*   **Amazon S3:**
    *   10GBのデータ保存、月間10万回のGETリクエスト、1万回のPUTリクエストを想定。
    *   約 $0.3 - $0.5 /月
*   **AWS Lambda:**
    *   月間100万回の検索リクエスト（平均実行時間500ms、メモリ512MB）およびコンテンツ更新処理を想定。
    *   約 $5 - $15 /月
*   **Amazon OpenSearch Service (Vector Engineの場合):**
    *   `m6g.large.search` インスタンスを3台（データノード2台、マスターノード1台）マルチAZで利用、100GBのベクトルデータを保存・検索。
    *   約 $300 - $500 /月 (インスタンスタイプ、ストレージ、データ転送量に依存)
*   **Amazon Kendra (Developer Editionの場合):**
    *   1インデックス、月間750,000回のクエリを想定。
    *   約 $750 /月 (クエリ数、インデックスのサイズ、ドキュメント量に依存)
*   **Amazon Bedrock:**
    *   Titan Embeddings モデルによるエンベディング (月間100万トークン処理)
    *   Claude/Llama 2等のLLMによる生成 (月間数百万トークン生成)
    *   約 $50 - $200 /月 (利用するモデル、入力/出力トークン数に依存)
*   **Amazon API Gateway:**
    *   月間100万回のAPIリクエスト。
    *   約 $3.5 /月
*   **Amazon CloudFront:**
    *   月間1TBのデータ転送、100万リクエスト。
    *   約 $80 - $120 /月
*   **Amazon DynamoDB:**
    *   オンデマンドキャパシティモード、データサイズ10GB、月間100万Read/Writeリクエスト。
    *   約 $5 - $15 /月

**月額概算合計:**
*   Amazon OpenSearch Service を利用する場合: **約 $440 - $850 /月**
*   Amazon Kendra を利用する場合: **約 $900 - $1300 /月**

（別途、VPC、CloudWatch、IAMなどの付随サービス費用がわずかに発生します。）

---

### 5. 制約事項・注意点

*   **コンテンツの品質とチャンキング:** RAGの性能は、元データの品質と、LLMが理解しやすいようにテキストをセグメント（チャンキング）する方法に大きく依存します。適切な粒度でのチャンキング戦略が必要です。
*   **エンベディングモデルの選択:** BedrockのTitan Embeddingsは強力ですが、特定のドメインに特化したモデルの方が性能が良い場合があります。モデルの選定と評価は重要です。
*   **プロンプトエンジニアリング:** LLMからの適切な回答を引き出すためには、効果的なプロンプトエンジニアリングが不可欠です。
*   **応答時間:** 応答時間は、LLMの推論時間、ベクトル検索のレイテンシー、コンテンツの量と複雑さに依存します。特にLLMの推論は数秒かかる場合があります。CloudFrontでのキャッシュや非同期処理の導入も検討可能です。
*   **コンテンツ更新の即時性:** コンテンツ更新の頻度と、それが検索結果に反映されるまでの許容時間に応じて、データ取り込みパイプラインの設計（バッチ処理かリアルタイム処理か）を調整する必要があります。
*   **リージョン依存制約:**
    *   `aws___get_regional_availability` で確認したところ、Amazon Bedrock, Amazon Kendra, Amazon OpenSearch Service, AWS Lambda, Amazon S3など主要なサービスは、日本国内の主要リージョン（`ap-northeast-1` 東京）で利用可能です。
    *   ただし、Amazon Bedrockで利用できるモデルはリージョンによって異なる場合があります。最新の情報はBedrockの公式ドキュメントで確認が必要です。
*   **データセキュリティとプライバシー:** 取得したウェブサイトコンテンツやユーザーの検索クエリに対して、適切な暗号化（保管時および転送時）とアクセス制御（IAM）を適用する必要があります。

---

### 6. 公式ドキュメント根拠

1.  **RAGアーキテクチャ概要**
    *   **ドキュメント名:** Build a custom knowledge base for your generative AI application using Amazon Pinecone and Amazon Bedrock
    *   **URL:** `https://aws.amazon.com/blogs/machine-learning/build-a-custom-knowledge-base-for-your-generative-ai-application-using-amazon-pinecone-and-amazon-bedrock/`
    *   **該当箇所の要約:** 生成AIアプリケーションのためのカスタムナレッジベース構築方法として、Retrieval Augmented Generation (RAG) パターンを紹介しています。コンテンツをエンベディングし、ベクトルデータベースに保存し、ユーザーからのクエリと関連情報をLLMに渡し回答を生成するアーキテクチャが図解されています。
2.  **Amazon OpenSearch Service (ベクトル検索)**
    *   **ドキュメント名:** Amazon OpenSearch Service でベクトル検索を有効にする
    *   **URL:** `https://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/vector-search.html`
    *   **該当箇所の要約:** Amazon OpenSearch Serviceがk-Nearest Neighbor (k-NN) 検索プラグインをサポートしており、高次元ベクトルデータを保存・検索できることが記載されています。これにより、テキストエンベディングを利用したセマンティック検索が可能になります。
3.  **Amazon Kendra**
    *   **ドキュメント名:** Amazon Kendra とは
    *   **URL:** `https://docs.aws.amazon.com/ja_jp/kendra/latest/dg/what-is-kendra.html`
    *   **該当箇所の要約:** Amazon Kendraが機械学習を利用したインテリジェント検索サービスであり、様々なデータソース（ウェブサイトを含む）から情報を取得し、自然言語クエリに対して関連性の高い回答を提供することが説明されています。FAQ検索やRAGパターンへの利用も言及されています。
4.  **Amazon Bedrock (Titan Embeddings)**
    *   **ドキュメント名:** Amazon Bedrock で利用可能なモデル
    *   **URL:** `https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/models-supported.html`
    *   **該当箇所の要約:** Amazon Bedrockが提供するテキスト生成およびエンベディングモデルの一覧が記載されており、Amazon Titan Embeddingsがテキストのベクトル表現を生成するために利用できることが示されています。
5.  **AWS Lambda 料金**
    *   **ドキュメント名:** AWS Lambda の料金
    *   **URL:** `https://aws.amazon.com/jp/lambda/pricing/`
    *   **該当箇所の要約:** Lambdaの料金は、リクエスト数と関数の実行時間（GB-秒）に基づいて課金されることが明記されています。最初の無料利用枠についても記載があります。
6.  **Amazon OpenSearch Service 料金**
    *   **ドキュメント名:** Amazon OpenSearch Service の料金
    *   **URL:** `https://aws.amazon.com/jp/opensearch-service/pricing/`
    *   **該当箇所の要約:** OpenSearch Serviceの料金は、インスタンス時間、EC2インスタンスタイプ、ストレージ、データ転送量などに基づいて課金されることが説明されています。
7.  **Amazon Kendra 料金**
    *   **ドキュメント名:** Amazon Kendra の料金
    *   **URL:** `https://aws.amazon.com/jp/kendra/pricing/`
    *   **該当箇所の要約:** Kendraの料金は、Developer EditionとEnterprise Editionに分かれており、それぞれインデックスの容量、クエリ数、データコネクタの使用量などに基づいて課金されることが示されています。
8.  **Amazon Bedrock 料金**
    *   **ドキュメント名:** Amazon Bedrock の料金
    *   **URL:** `https://aws.amazon.com/jp/bedrock/pricing/`
    *   **該当箇所の要約:** Bedrockの料金は、利用するモデル（基盤モデル）、入力トークン数、出力トークン数に基づいて課金されることが説明されています。
9.  **リージョンアベイラビリティ**
    *   `aws___get_regional_availability` を用いて、主要サービス（Amazon Bedrock, Amazon Kendra, Amazon OpenSearch Service, AWS Lambda, Amazon S3, Amazon API Gateway, Amazon CloudFront, Amazon Route 53, Amazon DynamoDB, AWS WAF, AWS IAM, Amazon CloudWatch, AWS CloudTrail, Amazon VPC）が `ap-northeast-1` （東京）リージョンで利用可能であることを確認済みです。

---

情報源として URL が記載されていますが、アクセスしたところ404エラーであったり、画面表示されないケースがあり、そこが残念ではありましたが、記載されているアーキテクチャは大筋適当な内容かと思います。

googlecloud.mdについて

内容ですが、aws.md と同様、

• アーキテクチャ全体像（構成の概要）について
• 主要サービスの役割分担
• スケーラビリティと可用性
• 月額コスト概算
• 制約事項

が記載されています。

### 1. 推奨アーキテクチャ概要

本アーキテクチャでは、Google Cloudのフルマネージドサービスである**Vertex AI Search for websites**を中核に据え、自然言語理解に基づく高度な検索機能と複数ページを横断した要約回答を実現します。フロントエンドAPIには**Cloud Run**を使用し、高いスケーラビリティとコスト効率を両立します。

**構成図の概要:**

1.  **コンテンツ取り込み:**
    *   公式サイト（約1万ページ）のコンテンツは定期的に、または更新イベントをトリガーに収集されます。
    *   収集されたコンテンツは**Cloud Storage**に一時的に保存されるか、直接**Vertex AI Search**のデータソースに連携されます。
    *   **Cloud Functions**または**Cloud Run Jobs**が、Webサイトのクロールやコンテンツ更新を検知し、Vertex AI Searchのデータストアへのインポート/更新処理を起動します。

2.  **検索および回答生成:**
    *   **Vertex AI Search for websites**は、インポートされたWebサイトコンテンツから高度なセマンティックインデックスを作成します。
    *   自然言語クエリに対して、意味を理解した関連ドキュメントを検索し、複数ドキュメントからの情報抽出と生成AIによる要約回答を提供します。

3.  **ユーザーインターフェース/API:**
    *   ユーザーからの検索リクエストは**Cloud Load Balancing**を介して**Cloud Run**でホストされるAPIエンドポイントにルーティングされます。
    *   **Cloud Run**アプリケーションはVertex AI Search APIを呼び出し、検索結果と生成された回答を取得し、ユーザーに返却します。
    *   Cloud Runはリクエスト量に応じて自動的にスケーリングし、高負荷時でも安定した応答を維持します。

### 2. 使用サービス一覧

| サービス名                  | 役割                                                                                                                                                                                                                                                                     |
| :-------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Vertex AI Search**        | サイト内検索のコアエンジン。自然言語理解、セマンティック検索、複数ページ横断での情報抽出・要約、生成AIによる回答生成機能を提供。「エンタープライズ サーチ for ウェブサイト」機能を利用。                                                                                             |
| **Cloud Run**               | 検索APIのホスト。ユーザーからのリクエストを受け付け、Vertex AI Searchと連携する。リクエスト数に応じて自動的にスケーリングするフルマネージドなコンテナサービス。コンテンツ更新トリガーの処理（Cloud Run Jobs）にも利用可能。                                                          |
| **Cloud Storage**           | Webサイトコンテンツの生データやバックアップの保存場所、Vertex AI Searchへのデータ取り込みの中間ストレージ。                                                                                                                                                                 |
| **Cloud Functions**         | コンテンツ更新トリガー（例：WebサイトのRSSフィード更新、Webhooksなど）を検知し、Vertex AI Searchのデータストアへのインポート/更新処理を起動するサーバーレス機能。                                                                                                           |
| **Cloud Load Balancing**    | 外部からの検索リクエストを受け付け、Cloud Runサービスにトラフィックを分散する。HTTPS/SSL終端機能を提供し、セキュリティとパフォーマンスを向上させる。                                                                                                                           |
| **Cloud CDN**               | （任意）静的アセット（画像、CSS、JavaScriptなど）のキャッシュと高速配信。検索結果の動的コンテンツには直接影響しないが、Webサイト全体のパフォーマンス向上に寄与。                                                                                                          |
| **Cloud Monitoring**        | サービスの稼働状況監視、パフォーマンスメトリクスの収集、アラート設定。                                                                                                                                                                                                   |
| **Cloud Logging**           | サービスからのログ収集、分析、トラブルシューティング。                                                                                                                                                                                                                   |
| **Cloud Identity and Access Management (IAM)** | サービス間のアクセス権限管理、セキュリティの確保。                                                                                                                                                                                                       |

### 3. 可用性・スケーリング設計

*   **可用性:**
    *   主要サービスである**Vertex AI Search**、**Cloud Run**、**Cloud Load Balancing**は、Google Cloudが提供するマネージドサービスであり、基盤レベルで高い可用性（マルチゾーン/リージョン冗長性）が確保されています。
    *   日本国内のユーザーを想定しているため、メインリージョンとして `asia-northeast1` (東京) または `asia-northeast2` (大阪) を選択することで、低レイテンシを実現しつつ、災害時などのリスクを分散する選択肢も考慮できます。
    *   Cloud Load BalancingはグローバルなAnycast IPを提供し、最も近いエッジロケーションからリクエストを受け付けるため、地理的な冗長性も高まります。
*   **スケーリング:**
    *   **Cloud Run**は、リクエスト数に基づいてコンテナインスタンスを自動的にスケールイン/アウトします。トラフィックがゼロの場合はインスタンス数もゼロになり、コスト効率が非常に高くなります。
    *   **Vertex AI Search**は、取り込まれたデータ量とクエリトラフィックに応じて、基盤リソースを自動的にスケーリングします。
    *   **Cloud Storage**および**Cloud Functions**も同様に、利用量に応じて自動的にスケーリングする特性を持っています。
    *   この構成により、急激なアクセス増加にも対応し、安定したサービス提供が可能です。

### 4. 料金概算（目安）

※ 以下は公式料金情報を基にした概算です。実際の料金は利用状況・リージョン・割引条件等により変動します。正式な見積りには Google Cloud Pricing Calculator の利用を推奨します。

**前提条件（概算のための仮定）：**
*   ウェブサイトページ数: 10,000ページ
*   1ページあたりの平均テキストデータ量: 10KB (合計 100MB)
*   月間クエリ数: 100,000回
*   回答生成機能の利用率: 50% (50,000回)
*   コンテンツ更新頻度: 毎日全ページ更新（Vertex AI Searchへの再インポート）

**サービスごとの想定コスト内訳:**

*   **Vertex AI Search:**
    *   **ドキュメント ストレージ:**
        *   100MBまで無料。
        *   100MBを超過した場合、$0.02/GB/月 (検索サービスの場合)。
        *   今回の仮定では100MBのため、ストレージ費用はほぼかからない可能性が高いです。
    *   **検索クエリ:**
        *   検索のみ（回答生成なし）: $5/1,000クエリ
        *   回答生成あり: $20/1,000クエリ (エンタープライズ エディションの場合)
        *   月間クエリ100,000回、うち回答生成50,000回の場合:
            *   検索のみ: 50,000回 * ($5/1,000) = $250
            *   回答生成あり: 50,000回 * ($20/1,000) = $1,000
        *   **合計: $1,250**
    *   **データ取り込み/更新:**
        *   取り込み/更新されるドキュメント量と処理回数に応じて課金されます。
        *   **Vertex AI Search for websites**は通常、クロールベースで自動的にWebサイトをデータソースとするため、別途インポートAPIを呼び出す場合と料金体系が異なる可能性があります。正確な情報は公式ドキュメントで確認が必要です。仮に無料ティアに含まれるか、非常に低額とします。

*   **Cloud Run:**
    *   APIサービス（Cloud Run）の料金は、リクエスト数、CPU時間、メモリ使用量に基づきます。
    *   月間100,000リクエストの場合、無料枠に収まるか、非常に低額になる可能性が高いです。
    *   例えば、1リクエストあたり100msのCPU時間、512MBメモリ消費と仮定すると、約 $10〜$50 程度が目安となるでしょう。
    *   **合計: $10〜$50** (利用状況により変動大)

*   **Cloud Storage:**
    *   100MB程度のデータ保存であれば、無料枠に収まるか、非常に低額です。
    *   **合計: $1未満**

*   **Cloud Functions (または Cloud Run Jobs):**
    *   日次で10,000ページの更新処理を行う場合、関数実行回数と実行時間に応じた課金が発生します。
    *   例えば、1日1回、10,000ページの更新に各1秒かかると仮定すると、月間300,000秒程度のCPU時間となり、これも無料枠に収まるか、数ドル程度の低額になる可能性が高いです。
    *   **合計: $1〜$10** (利用状況により変動大)

*   **Cloud Load Balancing:**
    *   前方ルールと転送されるデータ量に応じて課金されます。
    *   月額 $20〜$50 程度が目安となるでしょう。
    *   **合計: $20〜$50**

**月額概算合計:**
上記の仮定に基づくと、
**$1,250 (Vertex AI Search) + $50 (Cloud Run) + $1 (Cloud Storage) + $10 (Cloud Functions) + $50 (Cloud Load Balancing) = 約 $1,361**

これはあくまで目安であり、特にVertex AI Searchのクエリ数と回答生成の利用頻度、Cloud Runの具体的なリソース使用量によって大きく変動します。

### 5. 制約事項・注意点

*   **Vertex AI Search for websites の対応範囲:** Vertex AI SearchはWebサイトのクロールをサポートしますが、認証が必要なページやJavaScriptで動的に生成されるコンテンツのクロールには追加の考慮が必要な場合があります。
*   **コンテンツの品質と回答精度:** Vertex AI Searchの回答生成機能は、取り込まれたコンテンツの品質と構造に大きく依存します。誤情報の生成（ハルシネーション）を完全に防ぐことは難しいため、特に商用サイトでの利用においては、生成された回答のファクトチェックやユーザーへの注意喚起の表示が推奨されます。
*   **レイテンシ:** Vertex AI Searchは複雑な自然言語処理と生成AIを利用するため、純粋なキーワード検索と比較して若干のレイテンシが発生する可能性があります。応答時間数秒以内という要件は満たせると想定されますが、パフォーマンス要件に応じてチューニングやキャッシュ戦略の検討が必要になる場合があります。
*   **言語サポート:** 主な利用者は日本国内と想定されていますが、Vertex AI Searchの生成AI機能の日本語における精度や機能に制約がないか、事前に十分な検証が必要です。
*   **料金体系の変動:** Google Cloudの料金体系は予告なく変更される可能性があります。常に最新の公式料金ドキュメントを確認してください。
*   **GA/Preview ステータス:** Vertex AI Searchの特定の機能（例：生成AIによる回答生成）がまだPreview版である場合、商用利用には注意が必要です。本提案時点ではGAとして提供されている機能として構成しています。

### 6. 公式ドキュメント根拠

*   **Vertex AI Search の概要:**
    *   ドキュメント名: Vertex AI Search の概要
    *   URL: [https://cloud.google.com/vertex-ai/docs/enterprise-search/overview?hl=ja](https://cloud.google.com/vertex-ai/docs/enterprise-search/overview?hl=ja)
    *   該当箇所の要約: Vertex AI Search は、さまざまなタイプのデータソースから情報を検索し、回答を生成するフルマネージドの検索サービスです。特に「エンタープライズ サーチ for ウェブサイト」は、ウェブサイト全体を対象とした質の高い自然言語検索エンジンを構築できると記述されています。
*   **Vertex AI Search の料金:**
    *   ドキュメント名: Vertex AI Search の料金
    *   URL: [https://cloud.google.com/vertex-ai/docs/enterprise-search/pricing?hl=ja](https://cloud.google.com/vertex-ai/docs/enterprise-search/pricing?hl=ja)
    *   該当箇所の要約: ドキュメントストレージ、クエリ数、および生成AI機能（回答生成）の利用に応じて課金されることが明記されています。回答生成機能の価格はエンタープライズ エディションの場合で提示されています。
*   **Cloud Run の概要:**
    *   ドキュメント名: Cloud Run の概要
    *   URL: [https://cloud.google.com/run/docs/overview?hl=ja](https://cloud.google.com/run/docs/overview?hl=ja)
    *   該当箇所の要約: Cloud Run は、ステートレスなコンテナをサーバーレス環境で実行できるフルマネージドなコンピューティングプラットフォームです。HTTP リクエストやイベントに応じて自動的にスケールすると記述されています。
*   **Cloud Run の料金:**
    *   ドキュメント名: Cloud Run の料金
    *   URL: [https://cloud.google.com/run/pricing?hl=ja](https://cloud.google.com/run/pricing?hl=ja)
    *   該当箇所の要約: リクエスト数、CPU 時間、メモリ、ネットワーク使用量に基づいて課金されることが示されています。無料枠も提供されています。
*   **Cloud Storage の料金:**
    *   ドキュメント名: Cloud Storage の料金
    *   URL: [https://cloud.google.com/storage/pricing?hl=ja](https://cloud.google.com/storage/pricing?hl=ja)
    *   該当箇所の要約: ストレージ容量、データ処理（オペレーション）、ネットワーク転送量に応じて課金されることが記述されています。
*   **Cloud Load Balancing の概要:**
    *   ドキュメント名: Cloud Load Balancing の概要
    *   URL: [https://cloud.google.com/load-balancing/docs/load-balancing-overview?hl=ja](https://cloud.google.com/load-balancing/docs/load-balancing-overview?hl=ja)
    *   該当箇所の要約: トラフィックを複数のインスタンスやサービスに分散し、高可用性とスケーラビリティを提供するマネージドサービスであることが記述されています。
*   **Cloud Load Balancing の料金:**
    *   ドキュメント名: Cloud Load Balancing の料金
    *   URL: [https://cloud.google.com/load-balancing/pricing?hl=ja](https://cloud.google.com/load-balancing/pricing?hl=ja)
    *   該当箇所の要約: ロードバランシング転送ルールと、処理されるデータ量に基づいて課金されることが示されています。
*   **Google Cloud のロケーション:**
    *   ドキュメント名: Google Cloud のロケーション
    *   URL: [https://cloud.google.com/about/locations?hl=ja](https://cloud.google.com/about/locations?hl=ja)
    *   該当箇所の要約: 日本国内には `asia-northeast1` (東京) と `asia-northeast2` (大阪) リージョンが存在することが確認できます。

このアーキテクチャは、Webサイト検索に特化したVertex AI Searchを活用することで、開発・運用コストを抑えつつ、高度な生成AI検索機能と商用サイトに求められる信頼性・スケーラビリティを実現します。

aws.md 同様、情報源として URL が記載されていますが、アクセスしたところ404エラーであったり、画面表示されないケースがあり、そこが残念ではありましたが、記載されているアーキテクチャは大筋適当な内容かと思います。

comparison.mdについて

比較結果がこちらになります。
内容としては、

• 中核サービスの比較
• 運用負荷と導入複雑度
• カスタマイズ性について
• 料金体系情報と総コスト感
• クラウド選択の判断基準

が記載されています。

# AWS と Google Cloud のアーキテクチャ比較分析

## 1. はじめに
生成AIを活用したサイト内検索機能の構築要件に基づき、AWSおよびGoogle Cloudそれぞれで設計されたアーキテクチャ案を比較分析します。

## 2. アーキテクチャ比較表

| 項目                 | AWS                                                                                                                                              | Google Cloud                                                                                                                                  |
| :------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- |
| **主要検索エンジン** | Amazon OpenSearch Service (ベクトルエンジン) または Amazon Kendra (RAGパターン)                                                                  | Vertex AI Search for websites                                                                                                                 |
| **生成AI**           | Amazon Bedrock (Titan Embeddings, LLM)                                                                                                           | Vertex AI Search (内蔵)                                                                                                                       |
| **アプリケーション層** | Amazon API Gateway + AWS Lambda / AWS Fargate                                                                                                    | Cloud Run + Cloud Load Balancing                                                                                                              |
| **コンテンツ取り込み** | AWS Lambda / AWS Fargate + Amazon S3                                                                                                             | Cloud Functions / Cloud Run Jobs + Cloud Storage                                                                                              |
| **ベクトルDB**       | Amazon OpenSearch Service (ベクトルエンジン)                                                                                                     | Vertex AI Search (内蔵)                                                                                                                       |
| **可用性・スケーリング** | マルチAZ配置、Lambda/OpenSearch/Fargateの自動スケーリング。主要サービスはマネージドで高可用性。日本リージョン利用。                            | フルマネージドサービス（Vertex AI Search, Cloud Runなど）による高可用性・自動スケーリング。日本リージョン利用。グローバルLB。              |
| **料金概算（月額目安）** | OpenSearch利用時: 約 $440 - $850。Kendra利用時: 約 $900 - $1300。                                                                                | 約 $1,361 (Vertex AI Searchのクエリ数に大きく依存)                                                                                            |
| **導入/運用負荷**    | 各サービスの組み合わせと設定が必要。RAG実装の自由度が高い。OpenSearchの運用・最適化は知識が必要。Kendraはマネージド度が高い。                 | Vertex AI Searchがコア機能を包括しており、導入・運用負荷は低い傾向。Webサイト特化型なのでシンプル。                                        |
| **RAGアプローチ**    | 汎用的なRAGパターン。ベクトルデータベースとLLMを個別に選択・統合。カスタマイズ性が高い。                                                         | Vertex AI SearchがRAG機能を統合提供。Webサイト検索に特化した最適化。                                                                          |

## 3. 各クラウドのメリット・デメリット

### AWS

**メリット:**
*   **高いカスタマイズ性:** OpenSearch ServiceとBedrockを組み合わせることで、RAGパイプラインの各要素を細かく制御・最適化できる。
*   **幅広いサービス群:** コンテンツ取り込みや前処理において、Lambda, Fargateなど選択肢が豊富。
*   **既存AWSユーザーとの親和性:** 既にAWSを利用している場合、既存のインフラや運用体制と統合しやすい。
*   **Kendraによる選択肢:** マネージド検索サービスKendraの利用も可能で、OpenSearchの運用負荷を軽減できる選択肢がある。

**デメリット:**
*   **実装・運用負荷:** OpenSearch Serviceを自身で運用・最適化する場合、専門知識が必要となる。RAGパイプライン全体の構築・チューニングに手間がかかる可能性がある。
*   **料金の複雑性:** 各サービスの組み合わせにより料金が算出されるため、内訳が細かくなる。
*   **学習コスト:** 新たにRAGアーキテクチャを構築する場合、BedrockやOpenSearchの学習コストが発生する。

### Google Cloud

**メリット:**
*   **高い統合性・低運用負荷:** Vertex AI Search for websitesが検索、RAG、生成AI機能を包括しており、導入・運用が非常にシンプル。Webサイト特化型で構築が容易。
*   **フルマネージド:** 主要サービスがフルマネージドであり、インフラ管理の手間が少ない。
*   **スケーラビリティ:** Cloud RunやVertex AI Searchは自動スケーリングに優れており、運用上の心配が少ない。
*   **コスト効率:** Cloud Runはリクエストがない時に課金が発生しないため、低負荷時のコスト効率が高い。

**デメリット:**
*   **カスタマイズ性の限定:** Vertex AI Searchの内部実装に依存するため、RAGパイプラインの各要素を細かく調整する自由度はAWSに比べて低い可能性がある。
*   **Vertex AI Searchへのロックイン:** サイト内検索機能のコアがVertex AI Searchに強く依存するため、他のサービスへの移行が難しい可能性がある。
*   **料金体系の集中:** Vertex AI Searchの利用料金が全体の大部分を占める可能性があり、クエリ数や生成回答の利用頻度によってはコストが高騰するリスクがある。

## 4. 総合的な考察

両クラウドともに、生成AIを活用したサイト内検索機能の要件を満たすことが可能です。

*   **迅速な導入と運用負荷の軽減を最優先する場合:**
    Google Cloudの**Vertex AI Search for websites**を中心としたアーキテクチャが有利です。Webサイトに特化したAI検索サービスとして、インデックス作成からRAG、回答生成までを統合的に提供するため、少ない工数で高度な検索機能を実装・運用できます。特に「手早く生成AI検索機能を導入したい」「運用チームのリソースを最小限に抑えたい」というケースに適しています。ただし、カスタマイズの自由度はAWSに劣る可能性があります。

*   **高いカスタマイズ性、柔軟性、既存AWS資産との連携を重視する場合:**
    AWSの**Amazon OpenSearch Service + Amazon Bedrock**を中心としたアーキテクチャが適しています。RAGパイプラインの各コンポーネントを自由に選択・組み合わせられるため、特定の要件（例：独自のエンベディングモデル、特殊な前処理、複雑なランキングロジック）に合わせて最適化しやすいです。既にAWSを深く利用している企業であれば、既存のインフラ、監視、セキュリティ体制との統合がスムーズに進むでしょう。ただし、構築と運用にはより専門的な知識と工数が必要となります。

### 結論

最終的な選択は、組織の既存のクラウド利用状況、開発チームのスキルセット、導入・運用にかける予算とリソース、そして機能に対するカスタマイズ要求の度合いによって異なります。

*   **Google Cloud:** Webサイト向け生成AI検索をシンプルかつ迅速に導入したい場合に推奨。
*   **AWS:** 高いカスタマイズ性と柔軟性を求め、詳細な制御をしたい場合に推奨。または、既にAWS利用実績があり、そのエコシステムを活用したい場合に推奨。

料金面では、今回の概算ではGoogle CloudのVertex AI Searchの比重が大きく、総額ではAWS OpenSearch利用時の方が安価に見えます。しかし、AWS Kendraを選択した場合はGoogle Cloudと同等かそれ以上の費用となる可能性もあります。両者ともに無料枠や割引、利用形態によって変動するため、詳細な利用シミュレーションに基づいた料金比較が不可欠です。

内容に関する感想としては、どちらのクラウド利用とするかメリット・デメリットに触れつつ、組織の事情や運用リソースという現実的な制約に言及しているあたりにリアリティがあり、参考するに値する情報レベルにはなっているかと思います。

Skill と Subagent の実行についてはこれで以上です。

5.おわりに

AWS と Google Cloud それぞれのアーキテクチャ案作成 Subagent から、その Subagent を実行するための Agent Skills の Skill の作成、その Skill を実行してみた結果を紹介しました。

生成されたドキュメントの内容ですが、一定のクオリティは備えているものの、公式ドキュメントへのリンク切れが複数箇所で確認されるなど、情報として鵜呑みにできるものではないと思います。
最終的な採用可否の判断や技術的な妥当性の検証は、実機検証が不可欠と考えます。

しかし、本取り組みから得られる最大の価値は初期調査のスピード向上にあると考えています。

通常であれば各クラウドサービスの公式ドキュメントを探し、関連情報を読み込み、構成要素を洗い出し、そこから仮説を組み立てるという時間と労力を要する工程が必要になります。

ただ、今回のように AI が生成したドキュメントを質の高い仮説として活用すれば、調査の方向性が素早く定まり、その後の詳細検証や実機検証にスムーズに移行できるかと思います。

Agent Skills と Subagents を活用しましたが、AI エージェントツールには他にも様々な機能が用意されています。
これらを組み合わせれば、より質の高い成果物生成が可能と思います。
現時点では最終的な判断や検証といった工程に人間の関与が不可欠ですが、AI が担える範囲を拡張できるよう模索していきたいと考えています。
本ブログが皆さまの AI 活用の参考になれば幸いです。