ankuro.dev
← ブログ一覧に戻る
【GenU完全攻略 #2】GenUのアーキテクチャ——全体構成とデータフローを図解する
2026-03-22#AWS#GenU#Bedrock#CDK#アーキテクチャ

【GenU完全攻略 #2】GenUのアーキテクチャ——全体構成とデータフローを図解する

GenUを使い始めると「CDKでデプロイしたら動いた」で終わりがちだ。

でも中で何が動いているかわからないまま使っていると、エラーが出たときに原因を追えない。コスト最適化もできない。カスタマイズもしにくい。

この記事ではGenUの全体像を構成・フローの両面から整理する。

GenUの3層構造

GenUのアーキテクチャは大きく3層に分かれる。

[フロントエンド層]
  CloudFront + S3 (静的ホスティング)
  Cognito (認証)
        |
        | HTTPS
        v
[バックエンド層]
  API Gateway
        |
        v
  Lambda
        |
        v
[AI・データ層]
  Amazon Bedrock (LLM)
  Knowledge Base (RAG用)
  S3 (ドキュメント保存)
  DynamoDB (会話履歴)

それぞれの役割を見ていく。

フロントエンド層

CloudFront + S3でReactで作られたチャットUIを配信している。ユーザーはブラウザからCloudFrontのURLにアクセスする。

Cognitoで認証を管理している。ユーザーはCognitoのUser Poolでアカウントを持ち、ログインしないとチャット画面にアクセスできない。招待制にも設定できるので、社内向けの閉じたツールとして使える。

閉域構成の場合はCloudFront + S3ではなくALB + ECS Fargateに切り替わる。詳しくはGenUの閉域構成の記事を参照。

バックエンド層

API Gatewayがフロントエンドからのリクエストを受け取り、Lambdaに渡す。

LambdaはNode.jsで書かれており、リクエストの内容（通常チャット・RAG・Agent）に応じてBedrockへの呼び出し方を切り替える。

AI・データ層

Amazon BedrockがLLMの実体。ClaudeやLlama・Titanなどのモデルをここで呼び出す。

Knowledge BaseはRAGに使うベクトルデータベース。S3に置いたドキュメントをインデックス化して、ユーザーの質問に関連する文書を検索する。

DynamoDBには会話履歴が保存される。セッションをまたいで文脈を引き継ぐのに使われる。

デプロイ後に立ち上がるAWSリソース

npx cdk deploy を実行すると、以下のリソースが自動で作られる（主要なもののみ）。

リソース 用途
CloudFront Distribution チャットUIの配信
S3 Bucket（フロントエンド） Reactアプリのビルドファイルをホスティング
S3 Bucket（ドキュメント） RAG用ドキュメントの保存先
Cognito User Pool ユーザー認証
API Gateway フロントとLambdaの橋渡し
Lambda（複数） チャット・RAG・Agentの処理
Bedrock Knowledge Base RAG用ベクトル検索
DynamoDB 会話履歴の保存
CloudWatch Logs Lambdaのログ

リソース数が多いが、CDKがすべて管理してくれるので手動で設定する必要はない。

リクエストのデータフロー

ユーザーが質問を入力してから回答が返ってくるまでの流れ。

1. ユーザーがチャットUIに質問を入力
         ↓
2. CloudFrontを経由してAPI Gatewayへ
         ↓
3. Lambdaが起動してリクエストを処理
         ↓
4. BedrockのAPIを呼び出し（Claude等）
         ↓
5. Bedrockから生成されたテキストが返る
         ↓
6. Lambdaがレスポンスを整形してフロントへ
         ↓
7. チャットUIに回答が表示される

会話履歴はステップ3でDynamoDBから取得され、過去のやり取りをBedrockに渡すことで文脈が引き継がれる。

RAGとAgentでフローがどう変わるか

通常チャット・RAG・Agentの3つでBedrockへの渡し方が異なる。

通常チャット

Lambda → Bedrock（質問をそのまま投げる）→ 回答

ドキュメント参照なし。モデルが学習済みの知識だけで回答する。

RAG

Lambda → Knowledge Base（ベクトル検索）
       → 関連ドキュメントを取得
       → Bedrock（質問 + 関連ドキュメントを投げる）
       → 回答

「登録したドキュメントをもとに答えてほしい」用途に使う。社内マニュアル・FAQ・製品ドキュメントの検索に向いている。

Agent

Lambda → Bedrock（質問を投げてツール呼び出しを判断させる）
       → Lambdaツール・APIを呼び出し
       → 結果をBedrockに返す
       → 必要なら追加でツールを呼び出す（繰り返し）
       → 最終回答

Agentは複数ステップを自律的に実行できる。「データベースを検索してメールを送る」といった複合的なタスクに向いている。

ただしステップ数が増えるほどコストと遅延が増える。RAGで解決できる問題にAgentを使う必要はない。この判断基準については後の回で詳しく扱う。

まとめ

  • GenUはフロントエンド・バックエンド・AI層の3層構造
  • CDKデプロイで CloudFront・Cognito・Lambda・Bedrock等が自動で立ち上がる
  • 通常チャット・RAG・Agentでデータの経路が変わる
  • RAGはドキュメント検索、Agentはツール実行——目的に合わせて使い分ける

構成を把握しておくとエラー発生時の原因特定が速くなる。次回はRAGのナレッジベース構築と検索の仕組みを実装ベースで解説する。

← 第1回：GenUとは？——RAG・Agent・Bedrockとの違いを整理する ｜ 第3回：GenUの閉域構成——VPCエンドポイントでPrivate環境に閉じ込める →

← ブログ一覧に戻る