この事例を読むべき理由

「社内にドキュメントが山ほどあるので、AIで質問に答えるチャットボットを作ってほしい」——この依頼が来たとき、多くのエンジニアはこう思います。「またRAGを組むのか……」 😅

Gallupはこの問題を少し違う角度で解きました。90年以上蓄積された職場心理学の研究、従業員エンゲージメントのデータ、CliftonStrengthsの診断結果を、単なる検索可能なドキュメント倉庫ではなく、リーダーが業務フローの中で即座に引き出せる「コーチ」へと変えたのです。

本記事は「AWSブログに良い事例があった」という要約ではありません。自社のRAGを構築する際にそのまま参考にできるアーキテクチャ上の意思決定ポイントを抽出して整理したものです。Bedrockを触ったことがなくても読めるように構成しています。

先に結論を述べます。

  • Amazon Bedrock Knowledge Bases でマネージドRAGを採用（ベクトルDBを自前運用しない）
  • Amazon Kendra で最新Webドキュメントまで二重インデックス化（過去アーカイブ＋最新研究）
  • Bedrock Guardrails で生成途中のポリシー違反をブロック
  • Lambda + FastAPI + ElastiCache Serverless でsub-secondのストリーミング応答
  • プロトタイプから本番まで MLOps専任チームなしで数週間

なお、本記事の元となるアーキテクチャ解説は AWS Architecture BlogのGallup事例 で根拠資料として確認できます。

Cloud architecture diagram showing Amazon Bedrock and serverless AWS services for enterprise AI coaching platform Dev Environment Setup

アーキテクチャを分解する：5レイヤーで見るGallup AI

Gallup AIの構成は大きく ① データ収集 → ② 検索/グラウンディング → ③ 生成 → ④ キャッシュ/永続化 → ⑤ 可観測性 の5段レイヤーに分かれます。サーバーレス基盤のためオートスケールがデフォルトであり、マルチテナント（複数組織の同時利用）をサポートしています。

1) データ収集レイヤー — 「過去アーカイブ＋最新Web」の二重化

# 概念的な疑似コード：Gallupの二重インデックス戦略
# （実際のコードではなく、アーキテクチャ理解用の例です）

# 1-A. 静的研究アーカイブ → Bedrock Knowledge Bases（マネージドRAG）
s3_bucket = "s3://gallup-research-archive"
knowledge_base = bedrock.create_knowledge_base(
    name="gallup-proprietary-research",
    data_source=s3_bucket,
    embedding_model="amazon.titan-embed-text-v2",
    vector_store="opensearch-serverless"  # マネージドのため自前運用不要
)

# 1-B. 最新Webドキュメントのクロール → Amazon Kendra（リアルタイムインデックス）
kendra_index = kendra.create_index(name="gallup-live-web")
kendra.crawl(
    start_url="https://www.gallup.com",
    schedule="daily",
    index=kendra_index
)

なぜ2つを併用するのか？ Bedrock Knowledge Basesは不変に近い大容量アーカイブに強く、Kendraは頻繁に更新されるWebコンテンツに強いという特性があります。どちらか一方に統一すると、鮮度が落ちるかコストが跳ね上がります。二重化が定石です。

2) 検索/グラウンディングレイヤー — 信頼度スコアリング

リーダーが質問を投げると：

  1. Bedrock Knowledge Bases + Kendra の両方から並列検索
  2. ドキュメントごとに confidence threshold でフィルタリング
  3. 通過したドキュメントを consolidate（統合）
  4. Claudeモデルにコンテキストとして注入

ポイントは 「単にtop-kを取って突っ込む」のではなく、信頼度ベースのフィルタリングを行うことです。これがないとハルシネーションが急増します。

3) 生成レイヤー — Claude＋Guardrailsの同時適用

# Bedrock呼び出し時にGuardrailsを生成途中で介入させる概念
response = bedrock_runtime.converse_stream(
    model_id="anthropic.claude-sonnet-4-5",  # リージョンごとの対応モデルを要確認
    messages=[{"role": "user", "content": [{"text": user_query}]}],
    guardrail_config={
        "guardrailIdentifier": "gallup-content-safety",
        "guardrailVersion": "1",
        "trace": "enabled"
    }
)
# 重要：ストリーミング中にポリシー違反が検知された場合、
# mid-streamで応答を遮断できる（事後フィルタリングではない）

mid-streamでの介入が本質的に重要です。事後フィルタリングでは、すでに危険な文がユーザー画面に表示された後になります。Guardrailsはトークンが出力される途中で遮断します。

4) キャッシュ/永続化レイヤー — 会話履歴の二重化

ストレージ役割レイテンシ特性
ElastiCache Serverless直近の会話履歴キャッシュsub-millisecond
RDS for MySQL会話/プロンプト/応答/出典の永続保存標準RDBMS
DynamoDBユーザーロール別のパーソナライズコンテキスト柔軟なスキーマ

「なぜRedis一つで済まないのか？」 → 監査（audit）と出典引用（citation）が必要だからです。リーダー向け製品では「この回答の根拠は何か」という問いが規制リスクに直結します。

5) 可観測性レイヤー — トークン単位のコスト追跡

# Data Firehoseに流す主要メトリクス
metrics = {
    "input_tokens": response.usage.input_tokens,
    "output_tokens": response.usage.output_tokens,
    "cached_tokens": response.usage.cache_read_input_tokens,  # コスト最適化の鍵
    "ttfb_ms": time_to_first_byte,
    "stop_reason": response.stop_reason  # guardrail_intervened の有無を確認
}
firehose.put_record(DeliveryStreamName="gallup-ai-metrics", Record=json.dumps(metrics))

cached_tokens は必ず確認してください。 プロンプトキャッシュがどれだけ効いているかが、そのまま月次請求額になります。stop_reason に guardrail_intervened がどれだけ記録されるかも、安全性指標として活用できます。

AI assistant chat interface delivering personalized workplace coaching powered by Amazon Bedrock Claude models IT Technology Image

このアーキテクチャの限界と注意点（冷静に）

AWSブログの事例記事は成功談のみが並ぶ傾向があるため、実務者が見るべき影の部分を指摘します。

⚠️ 1) Claudeモデルのリージョン制約

Anthropic Claude on Bedrockはすべてのリージョンで提供されているわけではありません。 原文でも「select AWS Regions」と明記されています。日本国内でサービス提供する場合、東京リージョン（ap-northeast-1）でどのClaudeモデルがサポートされているかを最初に確認する必要があります。対応していない場合は大阪やバージニアへのクロスリージョン呼び出しになりますが、レイテンシとデータレジデンシーの問題が即座に表面化します。

⚠️ 2) Bedrock Knowledge BasesのマネージドRAGは「ただ飯」ではない

  • チャンキング戦略をカスタマイズしにくいです。文書構造が特殊な場合（例：表が多いHRレポート）は検索品質が急落します。
  • ハイブリッド検索（キーワード＋ベクトル）のチューニングが限定的です。ドメイン特化検索が必要なら、OpenSearchを直接接続する方が適しています。
  • コストモデルが不透明です。埋め込み再生成、ベクトルストアのストレージ、クエリコストがそれぞれ課金されます。PoC時点では安く見えても、本番で驚くことがあります。

⚠️ 3) Kendraは強力だが高価

Kendraはエンタープライズ検索品質が高い代わりに、時間単位のインデックスコストが相当かかります。「Webクロールを数件」程度なら、Bedrock Knowledge BasesにWebクローラーを直接接続する方がはるかに安価です。Kendraは真に大規模な文書セット＋コネクタが必要な場合にのみ使用してください。

⚠️ 4) Guardrailsは万能ではない

Guardrailsはポリシーベースのフィルターです。ドメイン特化の微妙な不適切応答（例：労働法に関する誤った助言）は捕捉できません。Gallupのようにドメイン専門家が応答を定期的にレビューするヒューマン・イン・ザ・ループが必須です。

⚠️ 5) 「MLOpsチームなしで数週間」は条件付き

これはAWSマネージドサービスに最大限乗った場合に成立します。カスタムモデルのファインチューニング、自前ベクトルDB運用、独自評価パイプラインを入れた瞬間にMLOps人材が必要になります。Gallupが速く進めた理由は、**「ファインチューニングを諦めてRAGに集中したから」**です。

日本の開発エコシステムにおける適用文脈

国内のSI/エンタープライズ環境でこのアーキテクチャをそのまま持ち込むと、いくつかの点で齟齬が生じます。

  • 規制産業（金融/医療/公共）：データレジデンシー要件により東京リージョン内での完結が強制されます。Claudeモデルの対応可否がプロジェクトの成否を分けます。
  • 社内文書はほとんどが非構造化：日本の企業文書は表、画像、スキャンPDFの比率が高く、Bedrock Knowledge Basesのデフォルトパーサーでは不十分です。Textract＋カスタムチャンキングを前段に置くことを推奨します。
  • 権限体系が複雑：Gallupは「リーダー」ロール中心ですが、日本の組織はチーム/本部/役員ごとに閲覧権限が多層的です。DynamoDBのパーソナライズレイヤーに権限フィルターを必ず入れる必要があります。そうしないと役員専用文書がチームリーダーに漏れます。

次のステップ学習の方向性

このアーキテクチャを自分で作ってみるなら、以下の順序で進めてください。

  1. Bedrock Knowledge BasesのチュートリアルでS3 → ベクトル検索まで30分で貫通する
  2. Bedrock GuardrailsでPIIマスキングポリシーを1つ作成し、ストリーミング途中の遮断を確認
  3. Lambda + FastAPI + converse_stream でsub-secondストリーミング応答のPoC
  4. Data Firehose → S3 → Athena でトークン/コストダッシュボード構築（ここで実力が分かれます）
  5. 余裕があれば Bedrock AgentCore でエージェント化（Gallupの次のロードマップがここです）

特に4番を飛ばすチームが多いのですが、トークン可観測性なしで運用する生成AIサービスは請求書地獄に直行します。

AWS serverless backend infrastructure with Lambda, ElastiCache, and RDS for real-time AI response streaming Technical Structure Concept

まとめ

Gallupの事例が印象的な理由は、**「最新モデルを使った」ことではなく「マネージドサービスの組み合わせでMLOps負担を排除し、RAG品質と可観測性に集中した」**点にあります。

そのまま持ち帰れる原則は3つです。

  1. RAGは二重化せよ — 不変アーカイブ（Bedrock KB）＋最新Web/文書（Kendraまたは自前クローラー）
  2. Guardrailsは生成途中で介入させよ — 事後フィルタリングは遅い
  3. トークン単位の可観測性を最初から付けよ — 後から付けるのは手遅れ

AIアシスタントを「とりあえず作ってみよう」で始めるチームと、「可観測な状態にしよう」で始めるチームは、6か月後の保守コストで完全に分かれます。

あわせて読みたい記事

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。