Amazon Bedrockを使ったEnterprise AI Gateway、RAG、GraphRAGの実装

Enterprise AI Gatewayの参考図書として以下のようなものがあります

AI運用基盤アーキテクチャ: Enterprise AI GatewayとDecisionOpsの実践

生成AIを企業システムへ導入する際、最初は「社内文書を検索して回答するチャットボット」から始めることが多い。

しかし実運用へ進むと、すぐに次の課題が現れる。

• 誰が、どの文書を検索・参照してよいのか
• 回答に使われた根拠を、後から確認できるか
• 文書検索、業務API、ワークフローを安全に接続できるか
• モデル、ツール、データソースが増えた時に統制できるか
• 高性能モデルだけを使わず、品質とコストを両立できるか

これらに対し有力なのが、Amazon Bedrockを中核にした Enterprise AI Gateway + RAG の構成である。さらに、文書の類似検索だけでは答えにくい、関係性・依存関係・影響範囲・因果を扱うために、GraphRAGへ拡張できる。

Amazon Bedrockとは

Amazon Bedrockは、AWS上で複数の基盤モデルを統一的に利用するためのフルマネージドサービスである。

アプリケーション側は、個別のモデル実行環境を構築せずに、API経由でLLM、埋め込みモデル、再ランキングモデル、Guardrails、Knowledge Basesなどを利用できる。

代表的なモデル群には、Anthropic Claude、Amazon Nova、Amazon Titan、Cohere、Meta Llama、Mistral AIなどがある。

重要なのは、Amazon Bedrockが単なるLLMの呼び出しAPIではない点である。企業利用では、RAG、アクセス制御、監査、ガードレール、評価、エージェント連携を含むAIアプリケーション基盤として捉えるべきである。

Enterprise AI Gatewayが必要になる理由

AIを業務へ組み込むと、LLMは単独では完結しない。

たとえば、製造業や技術系企業のAIアシスタントには、次のような処理が求められる。

• 設計標準、作業手順、品質規程、保全記録を検索する
• 製品構成、部品、案件、変更履歴を業務APIから参照する
• 不具合報告、検査記録、顧客要求を横断して調査する
• 技術回答、変更申請、報告書の下書きを作る
• 重要な変更や対外回答は、人間の承認後に実行する

各AIアプリケーションがそれぞれ業務システムへ直接接続すると、認証、権限、監査、API仕様、接続先管理が分散する。AIと接続先が増えるほど、統制が難しくなる。

そこで、AIと業務資源の間にGatewayを置く。

flowchart TD
    U["利用者"] --> A["AIアプリケーション / Agent"]
    A --> G["Enterprise AI Gateway"]
    G --> K["RAG / GraphRAG"]
    G --> B["Bedrock モデル"]
    G --> T["業務API・Lambda・SaaS"]
    K --> S["S3 / 文書・データ"]

Gatewayは、AIに対して「何を検索できるか」「どのツールを実行できるか」「誰の権限で実行するか」を一元的に制御する境界になる。

Amazon Bedrock AgentCore Gateway

Amazon Bedrock AgentCore Gatewayは、エージェント、ツール、他のエージェント、LLMへのアクセスを、一つの安全なエンドポイントへ統合するフルマネージドのAI Gatewayである。

既存のREST API、OpenAPI仕様、Lambda関数などを、MCP（Model Context Protocol）互換のツールとしてエージェントへ公開できる。

主な役割は次の通りである。

• APIやLambdaをAIツールとして公開する
• MCPによるツール検出・呼び出しを統一する
• 利用者・エージェントからGatewayへの認証を行う
• Gatewayから各業務ツールへの認証情報を安全に扱う
• ツール利用のログ、監査、可観測性を集約する
• 多数のツールから、文脈に適したツールを選択しやすくする

Gatewayは、AIに何でも直接実行させる仕組みではない。AIが利用できる機能を、業務上の権限・承認・証跡のもとで限定的に公開する仕組みである。

RAGの基本構成

RAG（Retrieval-Augmented Generation）は、質問に対して先に社内知識を検索し、その検索結果を根拠としてLLMに回答させる方式である。

基本処理は次の通りである。

1. 文書をS3などに登録する
2. 文書を意味のある単位で分割する
3. 各チャンクを埋め込みベクトルへ変換する
4. ベクトル検索とメタデータフィルタで候補を検索する
5. 必要に応じて再ランキングする
6. 根拠チャンクと質問をLLMに渡す
7. 回答と引用元を返す

Amazon Bedrock Knowledge Basesを使うと、データ取り込み、インデックス、検索、回答生成、引用表示をマネージドに構築できる。S3のほか、SharePoint、Confluence、Google Drive、OneDriveなどをデータソースにできる。

RAGで最も重要なのは、モデルより知識の境界である

RAGではLLM選定が注目されがちだが、精度と安全性を左右するのは、むしろ次の設計である。

• 文書をどの粒度でチャンク化するか
• 原文・見出し・版数・作成者・有効期限を保持しているか
• 公開、社内限定、機密、AI利用禁止などの区分があるか
• 利用者権限に応じて検索結果を絞れるか
• 回答に必ず出典を添付できるか
• 根拠が足りない時に「不明」と返せるか

たとえば、設計標準、品質規程、作業手順、技術報告書をRAGへ登録する場合、各チャンクには次のようなメタデータを持たせる。

{
  "document_id": "design-standard-2026-10",
  "title": "設備設計標準",
  "section": "回転機械の温度監視",
  "version": "3.2",
  "effective_from": "2026-10-01",
  "classification": "internal",
  "ai_use": "allowed",
  "allowed_roles": ["engineering", "quality"],
  "product_family": "rotating_equipment",
  "source_url": "s3://example/standards/design-standard-v3.2.pdf"
}

この設計があることで、RAGは単なる類似検索ではなく、権限と根拠を持った知識アクセスになる。

Bedrock Knowledge BasesをGatewayから利用する

Amazon Bedrock Knowledge Basesは、AgentCore Gatewayのターゲットとして公開できる。MCP対応エージェントからは、Knowledge Baseを標準ツールとして呼び出せる。

単純な検索結果を返すRetrieveだけでなく、複数段階の検索と根拠付き回答を行うAgenticRetrieveStreamも利用できる。

RAGのモデル選定：Claude Haiku、Sonnet、埋め込み、再ランキング

RAGでは、一番高性能なモデルを常に使う必要はない。処理を分け、用途に応じてモデルを使い分けることが、コストと品質の両立につながる。

通常の回答生成はClaude Haikuを標準にする

大量の社内問い合わせ、手順案内、仕様確認、簡単な要約には、Claude Haikuを第一候補にするとよい。

Haikuは低レイテンシー・低コストで大量リクエストを処理しやすく、分類、要約、情報抽出、定型的なRAG回答に向く。AWSはClaude Haiku 5.5を、高頻度かつコストに敏感な処理、リアルタイム応答、サブエージェント用途に位置付けている。

たとえば、次の用途はHaikuで十分なことが多い。

• 設計標準・作業手順の該当箇所を案内する
• 品質規程の引用付き回答を返す
• 問い合わせや不具合報告を分類する
• 点検記録から項目を抽出する
• 会議録や作業報告を要約する
• 技術回答や報告書の下書きを作る

複雑な比較・判断支援はClaude Sonnetへ限定する

Claude Sonnet級のモデルは、複数の根拠を統合し、条件や例外を慎重に扱う場面に向く。

• 設計標準、顧客仕様、契約条件の差分を比較する
• 長い技術資料や不具合履歴をもとに調査報告を作る
• 変更要求が品質・安全・保全へ与える影響を整理する
• エージェントのツール利用を計画する
• 管理者・技術責任者向けの判断材料を整理する

通常のFAQ・手順・仕様確認
  → Haiku + RAG

複数規程の比較・長文分析・影響整理
  → Sonnet + RAG

設計変更・発注・外部送信・設定変更
  → LLMは提案まで
  → Gatewayの権限確認 + 人間承認後に実行

Bedrockの料金はモデル、入力・出力トークン数、リージョン、推論方式で変わる。特に出力トークンは高くなりやすいため、必要以上に長い回答を生成させないことが重要である。導入時は公式価格表とAWS Pricing Calculatorで試算する。

埋め込みモデルはTitan Text Embeddings V2から始める

日本語を含む企業文書RAGでは、まず Amazon Titan Text Embeddings V2 を起点にするのが扱いやすい。

Titan Text Embeddings V2は東京リージョンで利用でき、256、512、1024次元を選択できる。初期検証では512次元程度から始め、検索品質、保存容量、コストを評価して調整するとよい。

多言語文書が中心で、英語以外の検索品質を強く重視する場合は、Cohere Embed Multilingualも比較候補になる。

再ランキングで検索精度を上げる

RAG精度を改善したい場合、高性能な生成モデルへ切り替える前に、再ランキングを導入すると効果的なことが多い。

検索で得た上位候補を、質問との関連性に基づいて並べ替え、LLMに渡す根拠を絞る。東京リージョンではAmazon Rerank 1.0およびCohere Rerank 3.5が利用できる。

GraphRAGへの拡張

通常のRAGは、「質問と似た文章」を探すことには強い。一方で、次のような問いは苦手になりやすい。

• ある設備の異常と、過去の設計変更・保全記録の関係は何か
• 顧客要件、設計仕様、部品構成、検査記録をまたいだ影響範囲はどこか
• 品質不具合に関連する工程、部品、変更履歴、対応記録は何か
• ある判断が、どの証拠とどの承認を経て実行されたか

このとき有効なのがGraphRAGである。

GraphRAGは、文書チャンクの類似度だけでなく、文書中のエンティティと関係をグラフとして保持する。

flowchart LR
    Q["質問"] --> V["ベクトル検索"]
    Q --> G["グラフ探索"]
    V --> C["根拠チャンク"]
    G --> R["エンティティ・関係"]
    C --> L["LLMによる根拠付き回答"]
    R --> L

たとえば、次のような関係を扱える。

設備A ──構成部品──> 軸受B
軸受B ──発生した故障──> 過熱
設計変更C ──影響──> 軸受B
保全記録D ──確認──> 過熱
承認E ──承認した──> 設計変更C

これにより、「軸受の過熱について教えて」という質問に対し、単に「過熱」という語を含む文書だけでなく、対象設備、部品、設計変更、保全履歴、承認履歴を辿った回答を作りやすくなる。

Amazon Bedrock Knowledge Basesは、Amazon Neptune Analyticsを利用したGraphRAGをサポートしている。文書取り込み時にチャンク化と埋め込み生成に加え、エンティティと関係を抽出し、グラフとして格納できる。

GraphRAGの導入判断

GraphRAGは、すべてのRAGに最初から必要なわけではない。

単純なFAQや一つの手順書を対象とした検索であれば、通常のRAGで十分である。一方で、複数文書・複数システムにまたがる因果、構成、依存関係、影響範囲、承認履歴を扱う領域では、GraphRAGの価値が大きい。

推奨する初期構成

実装時の設計原則

1. 検索と実行を分離する
   RAGとGraphRAGは根拠を提示する。業務操作は、権限確認と承認後に別経路で実行する。
2. 回答ではなく根拠を評価する
   「もっともらしい回答」ではなく、正しい出典・関係・版数が取得されているかを評価する。
3. 文書と関係の利用境界をメタデータで強制する
   公開可否、機密区分、権限、AI利用可否を、検索・グラフ探索のフィルタとして実装する。
4. 低コストモデルを標準にし、必要時だけ上位モデルへ送る
   Haikuを標準とし、複雑な比較・推論・計画だけをSonnetへエスカレーションする。
5. GraphRAGは関係性が価値を生む領域から始める
   まず通常RAGで効果を検証し、影響分析、構成管理、意思決定トレースなどへGraphRAGを拡張する。
6. 重要操作にはレシートを残す
   誰が、いつ、どの根拠を検索し、どのモデルが、どの提案をし、誰が承認して何を実行したかを記録する。

まとめ

Amazon Bedrockを使ったEnterprise AIの本質は、LLMを呼び出すことではない。

重要なのは、組織の知識、業務ツール、人間承認、権限、監査を、安全な境界の中で接続することである。

初期段階では、S3、Bedrock Knowledge Bases、Titan Embeddings、Claude Haiku、AgentCore Gatewayを組み合わせたRAGから始める。その上で、関係性や影響範囲の把握が重要になった領域を、Neptune Analyticsを用いたGraphRAGへ拡張する。

AIが回答するだけの仕組みから、根拠を持ち、権限を守り、人間の判断と接続された知識・意思決定基盤へ進化させること。それがEnterprise AI Gateway、RAG、GraphRAGの目指すべき姿である。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance