AWS・Azure・Google Cloudで作るRAG — マネージド構成の選び方

RAGをクラウドへ載せるとき、比較表だけでサービスを選ぶと失敗します。検索機能の差よりも、文書がどこにあり、誰が読めて、どのクラウドを運用できるかの方が支配的だからです。S3とIAMが中心ならAWS、Microsoft 365とEntra IDが中心ならAzure、BigQueryやGoogle Cloud上のデータ・AI基盤が中心ならGoogle Cloudが自然な起点です。

この記事では、3社のマネージドRAGを取り込み・検索・生成・権限・評価の同じ境界で比較します。製品名は変わっても、アプリケーション側の評価データと引用形式を共通にしておけば、構成を段階的に変えられます。

先に共通アーキテクチャを固定する

マネージドサービスへ任せる範囲を、次の5層に分けます。

1. 取り込み: オブジェクトストレージや業務システムから文書を取得する
2. 前処理・索引: 解析、チャンク分割、埋め込み、メタデータ付与を行う
3. 検索: キーワード、ベクトル、ハイブリッド、リランキングで根拠を取る
4. 生成: 根拠と質問から回答を作り、引用を返す
5. 統制: 認証、文書ACL、監査、評価、費用上限を適用する

小さく始めるなら3と4を一体化したAPIが速く、品質調整が必要になったら検索と生成を分けます。検索結果のID、スコア、メタデータ、原文位置を自社の共通形式へ変換し、UIと評価をクラウド固有レスポンスへ直結させないようにします。

3社のマネージドRAGを比較する

観点	AWS	Azure	Google Cloud
中心サービス	Bedrock Knowledge Bases	Azure AI Search	RAG Engine
基本の検索API	Retrieve	Knowledge Baseのretrieve	RetrieveContexts
検索+生成	RetrieveAndGenerate	answer synthesisまたはアプリ側生成	RAG corpusを生成モデルのtoolに指定
複雑な質問	AgenticRetrieveStream	agentic retrieval	アプリ／Agent側で分解
大規模な検索先	管理KBまたは対応vector store	Search indexとknowledge source	managed Spanner、Feature Store等
GraphRAG	Neptune Analytics連携	独自グラフ経路を併設	Spanner Graph等を併設
権限の軸	IAM、文書メタデータ	Entra ID、RBAC、ACL	IAM、VPC-SC、メタデータ

機能名が似ていても、GAとプレビューの境界は異なります。特にAzureのagentic retrievalは2026-04-01 REST APIで一部がGAになりましたが、2026-05-01-previewには追加機能が残ります[3]。本番ではプレビューの便利さより、SLA、リージョン、データ境界を優先します。

AWS: Retrieveから始めて必要なら生成を結合する

Bedrock Knowledge Basesは、検索だけのRetrieveと、検索してモデル回答まで返すRetrieveAndGenerateを分けて提供します。複雑な問いをサブクエリへ分解するAgenticRetrieveStream、リランキングも利用できます[1]。

検索だけを呼ぶ最小例です。認証情報をコードへ書かず、実行ロールから取得します。

import boto3

client = boto3.client("bedrock-agent-runtime", region_name="ap-northeast-1")

response = client.retrieve(
    knowledgeBaseId="YOUR_KB_ID",
    retrievalQuery={"text": "設備Aの停止条件は何ですか"},
    retrievalConfiguration={
        "vectorSearchConfiguration": {
            "numberOfResults": 8,
            "filter": {
                "andAll": [
                    {"equals": {"key": "tenant_id", "value": "t-001"}},
                    {"equals": {"key": "status", "value": "approved"}},
                ]
            },
        }
    },
)

chunks = [
    {
        "text": item["content"]["text"],
        "score": item.get("score"),
        "location": item.get("location"),
    }
    for item in response["retrievalResults"]
]

RetrieveAndGenerateは試作に向きますが、独自の引用検証、複数モデル、回答キャッシュを使うならRetrieveと生成を分離します。GraphRAGが必要ならNeptune Analyticsを検索先にできますが、テナントや部署を明示的なカテゴリ属性として持たせ、検索前フィルターを適用します[6]。

Azure: hybrid searchからagentic retrievalへ段階化する

Azure AI Searchのagentic retrievalでは、Knowledge Baseが質問をサブクエリへ分解し、Knowledge Sourceを並列検索してsemantic rankerで統合します[2]。2026年の構成では、Knowledge Sourceを先に作り、Knowledge Baseから参照します。

実装は次の2段階が安全です。

1. Search indexに本文、ベクトル、文書ID、ACL、更新時刻を持たせ、keyword+vector+semantic rankerのhybrid searchを評価する
2. 複合質問の失敗が多い場合だけKnowledge Baseのagentic retrievalを追加する

Knowledge Baseにはminimal、low、mediumのretrieval reasoning effortがあり、minimalではLLMによるクエリ計画を迂回できます[2]。全質問に高度な推論を使わず、単純質問はminimal、複合質問だけlow以上へ送ると遅延と費用を制御できます。

認証はAPIキーよりマネージドIDとRBACを優先します。BlobやADLS Gen2のACLをユーザーIDに合わせて検索へ反映できる構成でも、評価時には「権限外文書がtop-kへ混ざらない」ことを独立テストします。プレビューAPIを使う場合は、APIバージョンを設定とログに残し、GA版への移行テストを用意します。

Google Cloud: corpusと検索基盤を規模で選ぶ

RAG Engineは、文書の取り込み、コーパス作成、検索、生成モデルへの根拠付与をまとめます[4]。検索だけを切り出す場合はRetrieveContextsを呼び、取得したコンテキストを独自の生成処理へ渡せます。

curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  "https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION:retrieveContexts" \
  -d '{
    "vertex_rag_store": {
      "rag_resources": [{"rag_corpus": "projects/PROJECT_ID/locations/REGION/ragCorpora/CORPUS_ID"}]
    },
    "query": {"text": "設備Aの停止条件は何ですか", "similarity_top_k": 8}
  }'

大規模・低遅延の検索では、RAG EngineからVertex AI Feature Storeを使う構成が公式に案内されています[5]。データ量だけで選ばず、更新頻度、必要QPS、p95遅延、リージョン、VPC-SCとCMEKの要件を先に置きます。GraphRAGはSpanner Graphなど別の検索経路として併設し、GraphRAG入門で示した質問ルーターから呼び分けます。

大規模化で本当に効く設計

オンラインとオフラインを分離する

取り込み、OCR、チャンク生成、埋め込み、グラフ抽出はキューを使う非同期処理にします。検索APIは索引生成と分離し、旧版索引を読み続けられるようにします。新索引は評価を通してからエイリアスを切り替え、問題があれば戻します。

文書IDと権限をクラウド非依存にする

tenant_id、document_id、version、acl_group、valid_from、statusを共通メタデータにします。埋め込み先を変えても、同じ文書と権限を再現できます。削除要求では原文だけでなく、チャンク、埋め込み、キャッシュ、グラフ要約まで追跡します。

検索キャッシュは権限込みのキーにする

クエリだけをキーにすると、別ユーザーへ検索結果が漏れます。テナント、ACL集合、索引バージョン、検索設定を含めます。生成回答のキャッシュにも同じ原則を適用します。

可観測性を共通化する

3社に共通して、query_id、検索方式、フィルター、top-k、文書ID、スコア、リランキング前後、モデル、トークン、遅延、回答の引用IDを記録します。本文そのものは機密性に応じてマスキングし、追跡IDから権限のある担当者だけが確認できるようにします。

導入手順と判断ゲート

1. 実質問100件と正解根拠を用意し、検索recall@kを測る
2. 既存データとID基盤に近いクラウドで、読み取り専用の小規模PoCを作る
3. hybrid search、リランキング、メタデータフィルターを先に調整する
4. 複合質問に限ってagentic retrievalやGraphRAGを比較する
5. 権限外検索、削除反映、障害時フォールバック、費用上限をテストする
6. p95遅延、1問当たり費用、正解率、人手介入率のゲートを通して本番化する

検索品質の切り分けはRAGの精度改善ガイドの手順をそのまま使えます。クラウド移行時も評価セットを固定すれば、機能の多さではなく自社質問の改善量で選べます。

まとめ

• クラウド選定は検索機能より、既存データ、ID、運用体制との近さで決める
• 試作は検索+生成の統合API、本番調整は検索と生成の分離が扱いやすい
• AWSはRetrieve、AzureはSearch index、Google CloudはRetrieveContextsを共通検索境界へ変換する
• agentic retrievalとGraphRAGは複雑な質問にだけ使い、全トラフィックへ適用しない
• テナントとACLのフィルターは検索前に適用し、キャッシュキーにも含める
• 評価セット、文書ID、引用形式、観測項目はクラウド非依存に保つ

次の一手は、既存クラウドで100文書・100質問の検索PoCを作り、通常hybrid searchを基準線にすることです。その上で必要な質問群にだけGraphRAGやエージェント検索を足してください。