はじめに：RAGの「幻滅期」を乗り越えるために
生成AIのブーム初期、開発現場ではLangChainやLlamaIndexといったライブラリを使い、PineconeやChromaといったベクトルデータベースを組み合わせて、RAGパイプラインを構築することに熱中しました。しかし、いざ「全社展開」や「本番運用」を考えたとき、「運用の壁」と「精度の壁」という2つの現実に直面します。
「もっともらしい嘘（ハルシネーション）」をどう防ぐか？ 社内用語の検索漏れをどうするか？ そして、それらを支えるインフラを誰が管理するのか？
ここで紹介する Amazon Bedrock Knowledge Bases は、それらの課題に対するAWSからの強力な回答です。これは単なる「便利な機能」ではありません。RAG構築における「差別化につながらない重労働（Undifferentiated Heavy Lifting）」を排除し、エンジニアが本来注力すべき「データの質」と「検索体験」に集中するためのプラットフォームです。経営者視点から見ても、インフラ管理コストの削減と市場投入までのリードタイム短縮は大きな魅力となります。
本記事では、単なる機能紹介や手順の羅列ではなく、「なぜその設定が必要なのか」という設計思想に踏み込んで解説します。特に、日本語ドキュメントを扱う際のチャンキング戦略や、実用レベルの検索精度を実現するハイブリッド検索の実装について、ベストプラクティスを共有します。
さあ、PoC（概念実証）止まりのRAGから脱却し、全社員が信頼して使える検索システムを構築していきましょう。
なぜBedrock Knowledge Basesなのか：自前構築RAGとの決定的な違い
まず、技術的な意思決定の基盤を固めましょう。なぜ、既存のライブラリを使って自前で構築するのではなく、AWSのマネージドサービスを選択すべきなのでしょうか？
実務の現場では、「とりあえずLangChainで」と始まったRAG開発が、運用フェーズで泥沼化するケースが頻発しています。ここでは、その理由を構造的に解説します。
フルマネージドRAGパイプラインのメリット
自前でRAGを構築する場合、典型的なアーキテクチャは以下の構成要素を組み合わせることになります。
- ドキュメントローダー: S3などからファイルを読み込む
- テキストスプリッター: テキストを適切なサイズに分割する
- 埋め込みモデル: テキストをベクトル化する（Titan Embeddingsや外部のLLM API）
- ベクトルデータベース: ベクトルを保存・検索する（Pinecone, Milvus, OpenSearchなど）
- LLM: 検索結果をコンテキストとして回答を生成する
これらをOSSのオーケストレーターで繋ぎ合わせるアプローチは柔軟ですが、そこには「隠れた運用コスト」が潜んでいます。
ライブラリと依存関係のメンテナンス負荷:
ここが最も見落とされがちなポイントです。RAG関連のライブラリ（LangChain等）やLLMプロバイダーのSDKは進化が極めて速く、頻繁なアップデートへの追従を余儀なくされます。
例えば、主要ライブラリのメジャーバージョンアップに伴うパッケージ構成の変更や、依存するAPIの仕様変更（例：Google Vertex AI SDKの移行やOpenAIモデルのバージョン更新）に対応するためのコード修正コストは無視できません。さらに、ライブラリに深刻なセキュリティ脆弱性（APIキー流出のリスクなど）が発見された場合、即座にパッチを適用し検証する体制も必要となります。同期の複雑さ:
ドキュメントが追加・更新・削除されたとき、ベクトルDB側も即座に同期する必要があります。この差分更新ロジック（ETL処理）を自前で実装するのは、想像以上にバグを生みやすい作業です。インフラ管理:
ベクトルDBをEC2やコンテナでホストする場合、スケーリング設計やOSパッチの適用、バックアップの管理といった「差別化につながらない重労働」が発生します。
Bedrock Knowledge Bases は、この「1〜4」のプロセスを完全にマネージドサービスとして提供します。S3バケットを指定するだけで、ドキュメントの解析、チャンキング、ベクトル化、そしてベクトルDBへの保存までを自動化します。開発チームは「どのデータを使うか」と「どう分割するか」という戦略決定に集中できるのです。
OpenSearch Serverlessとのシームレスな統合
Bedrock Knowledge Basesのバックエンドとして推奨されるのが、Amazon OpenSearch Serverless です。
以前のOpenSearch Service（プロビジョニング型）は、クラスターの設計やサイズ見積もりが難しく、コストも固定でかかりがちでした。しかし、Serverless版の「ベクトルエンジン向けコレクション」は、RAG用に最適化されており、データの取り込み時と検索時のみリソースを消費するスケーリングモデルを採用しています（※データの保持に必要な最低限のOCUは発生します）。
Bedrock Knowledge Basesは、このOpenSearch Serverlessのインデックス作成や設定を自動的に行い、IAM権限の連携もスムーズに処理します。これにより、インフラ構築にかかる時間を数日から数時間へと劇的に短縮でき、高速なプロトタイピングが可能になります。
コストと運用負荷の比較
| 項目 | 自前構築（EC2/コンテナ + OSSライブラリ） | Bedrock Knowledge Bases + OpenSearch Serverless |
|---|---|---|
| 初期構築 | 複雑（数日〜数週間） | 極めて容易（数時間） |
| データ同期 | 自前で実装（Lambda等でトリガー） | 標準機能（Sync APIを呼ぶだけ） |
| ライブラリ管理 | 頻繁な更新・脆弱性対応が必要 | 不要（AWSが管理） |
| インフラ管理 | OS、MWのパッチ適用、スケーリング設計が必要 | 不要（サーバーレス） |
| コスト | インスタンス稼働時間分（常時課金） | データ量とアクセス数に応じた従量課金（※） |
※OpenSearch Serverlessにはベースコストがありますが、エンジニアによるライブラリの保守やインフラ運用の人件費を含めたTCO（総所有コスト）で比較すれば、多くの場合マネージドサービスに軍配が上がります。ビジネスの観点からも、このリソースの最適化は非常に重要です。
実装前の設計：精度を左右する「データ前処理」と「チャンキング戦略」
RAGシステムの精度が出ないという課題に直面した際、多くのケースでその原因はLLMの性能ではなく、「データの渡し方」にあります。
LLMは魔法使いではありません。RAGにおいて、ドキュメントをどのように分割してベクトル化するか、つまり「チャンキング戦略」が回答精度を大きく左右すると言っても過言ではありません。ここでは、AWS Bedrock Knowledge Basesを活用する際の具体的な設計ポイントを解説します。
ドキュメント形式ごとの最適な前処理
社内ドキュメントは多種多様です。PDFのマニュアル、Wordの契約書、Excelの仕様書、Wikiのテキストデータ。これらをそのままナレッジベースに登録するだけでは、期待する精度は得られにくいのが現実です。
- PDF/Word: ヘッダー、フッター、ページ番号は検索ノイズとなり得ます。これらは意味的なつながりを分断するため、可能な限り前処理で除去することが望ましいです。Bedrock Knowledge Basesには高度な解析機能（Advanced Parsing）も備わっていますが、複雑なレイアウトの場合は、事前にテキスト抽出（OCR等）を行い、クリーンなテキストファイルとしてS3に配置するアプローチが、依然として精度安定への近道です。
- Excel/CSV: 表形式データは、行ごとにテキスト化するなどの工夫が必要です。単にセルを連結しただけでは、列の意味（「価格」「日付」など）が失われ、LLMが正しく解釈できません。各行を「項目名: 値」の形式で記述するなどの前処理が有効です。
固定サイズチャンキング vs セマンティックチャンキング
Bedrock Knowledge Basesでは、主に以下のチャンキング戦略を選択できます。データの特性に合わせて選択することが重要です。
- デフォルトチャンキング: AWSが推奨する設定で自動分割します。手軽ですが、詳細な制御はできません（ブラックボックスになりがちです）。
- 固定サイズチャンキング (Fixed Size Chunking): トークン数で機械的に分割します。予測可能性が高く一般的ですが、文脈が途中で切れるリスクがあります。
- 階層的チャンキング (Hierarchical Chunking): 親チャンク（大きな文脈）と子チャンク（詳細）を管理します。検索時は子チャンクをヒットさせ、LLMには親チャンクを含めて渡すことで、文脈理解を深める手法です。複雑な文書構造を持つ場合に特に有効です。
- セマンティックチャンキング (Semantic Chunking): 意味のまとまりに基づいて分割します。計算コストは高くなりますが、最も人間らしい区切り方です。
日本語の社内ドキュメント、特に規定集やマニュアルの場合、まずは制御しやすい「固定サイズチャンキング」から始め、パラメータを調整することをお勧めします。あるいは、文脈維持を重視する場合は「階層的チャンキング」も有力な選択肢です。セマンティックチャンキングは強力ですが、日本語の文構造によっては意図しない箇所で切れるケースもあり、検証が必要です。まずは動くプロトタイプを作り、実際のデータで検証を繰り返すことが成功の鍵です。
推奨設定の目安（日本語ドキュメント向け）:
- 最大トークン数: 1000 〜 2000 トークン
- 日本語は英語に比べてトークン情報を多く含みやすいため、適切なサイズ設定が必要です。小さすぎると（例: 300トークン）文脈が失われ、大きすぎると検索ノイズが増え、LLMのコンテキストウィンドウを圧迫します。
- オーバーラップ率: 10% 〜 20%
- チャンク間のつなぎ目で情報が欠落するのを防ぐため、必ずオーバーラップ（重複部分）を持たせます。例えば1000トークンの設定なら、100〜200トークン程度を重複させると良いでしょう。
埋め込みモデル（Titan vs Cohere）の選定基準
ベクトル化を行う埋め込みモデル（Embeddings Model）の選択も、検索精度（Retrieval性能）に直結します。
- Amazon Titan Text Embeddings: AWS純正モデルです。コストパフォーマンスに優れ、多言語対応も強化されています。通常の用途では、最新バージョンのTitanモデル（v2以降）が第一選択肢となります。次元数（1024, 512, 256）を選択可能な場合、精度重視ならデフォルトの1024を選ぶのが一般的です。
- Cohere Embed Multilingual: 多言語対応に定評があるモデルです。特に、英語と日本語が混在するドキュメントや、非常に専門的な用語が多い業界固有のデータにおいて、Titanとは異なる特性を示すことがあります。
アプローチとしては、まずコスト効率の良い Amazon Titan Text Embeddings の最新版でベースラインを構築し、特定の検索クエリで精度が出ない場合に Cohere モデルでの検証を行うという段階的な導入が合理的です。
ハンズオン：Knowledge Baseの構築とデータソース連携
設計方針が決まったら、実際の構築フェーズに入ります。AWSマネジメントコンソールは直感的ですが、本番運用を見据えた場合、特にIAM権限やネットワーク設定において注意すべき落とし穴があります。ここでは、堅牢なRAGパイプラインを構築するための要点を解説します。
1. S3バケット構成とIAMロールの権限設定
ドキュメントを格納するS3バケットは、単なるストレージではなく「知識の源泉」です。後のメタデータフィルタリングやアクセス制御を見据え、論理的なフォルダ構成（プレフィックス）を設計することが重要です。データガバナンスの観点からも、この初期設計は欠かせません。
- 推奨構成例:
s3://my-rag-docs/domain-a/category-b/のように、ドメインやカテゴリで階層化しておくと、データソースごとの同期設定や削除が容易になります。
重要：IAMロールと最小権限の原則
BedrockがS3からデータを読み込み、OpenSearch Serverlessへ書き込むためには、適切なIAMロールが必要です。
コンソールのウィザード機能は便利ですが、自動生成されるロールは権限が広すぎる場合があります。セキュリティを重視する組織では、以下の点に注意して手動設定、あるいはIaC（Infrastructure as Code）での管理を推奨します。
- 信頼ポリシー（Trust Relationship）:
bedrock.amazonaws.comがこのロールを引き受けられる（AssumeRole）ように設定します。 - リソース制限: S3のアクセス権限は、特定のバケットおよびプレフィックスのみに限定（
Resource句で指定）し、不要なデータへのアクセスを防ぎます。
2. ベクトルストア（OpenSearch Serverless）の自動構成とセキュリティ
Knowledge Base作成ウィザードでは、ベクトルデータベースの指定が求められます。
- クイック作成の功罪: 「新しいベクトルストアを作成」のクイックオプションは、数クリックでOpenSearch Serverless (OSS) コレクションを立ち上げられるため、PoC（概念実証）には最適です。しかし、デフォルト設定では要件に合わない場合があるため注意が必要です。
- 本番環境へのアプローチ: 企業ユースでは、VPCエンドポイント経由でのアクセスに限定するなど、より厳格なセキュリティが求められます。その場合は、事前にOpenSearch Serverless側で以下のポリシーを定義し、作成済みのコレクションをBedrockから参照するフローが安全です。
- 暗号化ポリシー: AWS KMSキーによるデータ暗号化を指定。
- ネットワークポリシー: VPC内からのアクセスのみを許可。
- データアクセスポリシー: BedrockのIAMロールに対して、コレクションおよびインデックスへの操作権限を付与。
注意点: OpenSearch Serverlessのコレクション作成（プロビジョニング）には数分を要します。ステータスが「Active」になるまで待ちましょう。
3. データソース同期の初回実行と検証
設定完了後、「同期 (Sync)」を実行します。このバックグラウンドプロセスでは、S3内のドキュメントが読み込まれ、選択した戦略に基づいてチャンキングされ、埋め込みモデルによってベクトル化され、最終的にインデックスに格納されます。
初期検証のポイント:
同期完了後は、コンソール右側のテストウィンドウを活用します。
- 引用元の確認: 回答の下にある「ソースの詳細」を確認し、意図したドキュメントの適切な箇所（チャンク）が参照されているかチェックします。これが期待通りの箇所を指しているかどうかが、最初の評価ポイントです。
- ハルシネーションの有無: ドキュメントにない情報を勝手に補完していないか確認します。倫理的AIの観点からも、事実に基づかない出力の抑制は極めて重要です。
また、CloudWatch Logsを有効化しておくことで、同期エラー（ファイル形式の不備や権限不足など）を詳細に追跡できます。AWSの可観測性機能は日々強化されており、運用フェーズでのトラブルシューティングにおいてログは極めて重要な資産となります。
精度向上テクニック：ハイブリッド検索とメタデータフィルタリングの実装
基本的なRAGの仕組みは構築できても、実務運用フェーズに入ると「検索できない」「関係のない文書ばかりヒットする」という精度の壁に直面することは珍しくありません。ビジネス現場で求められる高精度な検索を実現するための鍵となるのが、「ハイブリッド検索」と「メタデータフィルタリング」の実装です。
キーワード検索とベクトル検索の融合（ハイブリッド検索）
ベクトル検索（セマンティック検索）は、「意味」を捉えることに長けており、「契約書」というクエリで「合意書」や「覚書」を含むドキュメントを見つけ出すことができます。しかし、一方で弱点も存在します。「プロジェクトコード X-99」や「型番 ABC-123」といった、意味を持たない記号や固有名詞の完全一致検索においては、従来のキーワード検索に劣る場合があります。
企業内の検索ニーズでは、こうした「特定の品番」や「固有のプロジェクト名」での検索が頻繁に行われるため、ベクトル検索単体ではユーザーの期待に応えられないリスクがあります。
Amazon Bedrock Knowledge Basesは、バックエンドのOpenSearch Serverlessの機能を活用してハイブリッド検索をサポートしています。これは、ベクトル検索による意味の理解と、従来のキーワード検索（BM25など）による完全一致の強さを組み合わせ、双方の結果をリランク（再順位付け）して最適な回答を返す仕組みです。
実装のポイント:
ハイブリッド検索を有効にするには、Retrieve API を呼び出す際の retrievalConfiguration でクエリの挙動を明示的に制御することが重要です。検索タイプを HYBRID に設定することで、意味的な関連性とキーワードの一致度の両方を考慮した検索が可能になります。
メタデータを用いた検索範囲の絞り込み
「人事部の規定を知りたいのに、経理部や法務部のドキュメントがヒットしてノイズになる」
こうした課題を解決するには、メタデータフィルタリングが極めて有効です。S3にドキュメントをアップロードする際、同じ階層に <ファイル名>.metadata.json という形式でメタデータファイルを配置することで、各ドキュメントに属性情報を付与できます。
例: handbook.pdf.metadata.json
{
"metadataAttributes": {
"department": "HR",
"year": 2025,
"doc_type": "rule"
}
}
そして、検索時（Retrieve または RetrieveAndGenerate API）にフィルタ条件を指定します。これにより、ベクトル検索を行う前に検索対象を物理的に絞り込むことができ、精度とレスポンス速度の両面でメリットがあります。
Boto3による実装例:
import boto3
bedrock_agent_runtime = boto3.client('bedrock-agent-runtime')
response = bedrock_agent_runtime.retrieve(
knowledgeBaseId='YOUR_KB_ID',
retrievalQuery={
'text': '有給休暇の申請方法は？'
},
retrievalConfiguration={
'vectorSearchConfiguration': {
'numberOfResults': 5,
'filter': {
'equals': {
'key': 'department',
'value': 'HR'
}
},
# 必要に応じてハイブリッド検索を指定
# 'overrideSearchType': 'HYBRID'
}
}
)
このように、アプリケーションのUI側で「対象部署」や「文書カテゴリ」をユーザーに選択させ、その値をフィルタ条件としてAPIに渡す設計にすることで、検索精度を劇的に向上させることができます。
Retrieve APIとRetrieveAndGenerate APIの使い分け
Bedrock Knowledge Basesには、ユースケースに応じて使い分けるべき2つの主要なAPIが存在します。
Retrieve API:
検索結果（関連するテキストチャンクのリスト）のみを返します。LLMによる回答生成は行いません。- 推奨シーン: 検索結果を独自のプロンプトに組み込みたい場合や、複数の検索結果をマージして処理したい場合、あるいは検索結果を別のLLM（例えばClaudeの最新モデルやLlamaモデルなど）に渡して高度な推論を行わせたい場合に適しています。
RetrieveAndGenerate API:
検索からLLMによる回答生成、さらには引用元の提示までを一気通貫で行います。- 推奨シーン: 手早くチャットボットを構築したい場合や、標準的なRAGの挙動で十分な場合に適しています。バックエンドで自動的にコンテキストが構築されるため、開発工数を大幅に削減できます。
プロトタイピング段階では RetrieveAndGenerate で素早く価値検証を行い、本番運用に向けてより細やかな制御や複雑な推論が必要になった段階で Retrieve APIとLangChainなどのオーケストレーションツールを組み合わせた構成へ移行するのが、リスクの少ない堅実なアプローチです。最新のモデル機能（推論強化型モデルなど）を活用する場合も、Retrieve APIの方が柔軟に対応しやすいでしょう。
本番運用を見据えたテストと継続的改善
システムを構築して終わりではありません。AIプロジェクトは、リリースしてからが本当のスタートです。初期構築時の精度が良くても、データの増加や利用パターンの変化により、回答品質は徐々に変化していく可能性があります。
回答精度の定量評価（RAGAS等の活用示唆）
「なんとなく良さそう」という主観的な評価ではなく、数値に基づいた客観的な評価指標を持つことが重要です。RAGパイプラインの評価フレームワークとして広く利用されている RAGAS (Retrieval Augmented Generation Assessment) などを活用すると、「検索精度（Context Recall）」や「回答の忠実性（Faithfulness）」をスコアリングできます。
評価には、テスト用の「質問と正解のペア（Golden Dataset）」を50〜100件程度用意します。これを、推論能力の高い最新のLLM（Claudeの最新モデルなど）を用いて判定させることで、チャンキング設定やプロンプトの変更が精度にどう影響したかを定量的に判断できます。
AWS Bedrockでもモデル評価機能が拡充されつつあります。最新の公式ドキュメントを参照し、マネージドな評価機能が利用可能かどうかも確認することをお勧めします。
ドキュメント更新時の同期自動化（EventBridge連携）
ナレッジベースとなるドキュメントは日々増え続けます。担当者が毎回手動でコンソールにログインし「同期ボタン」を押す運用は、持続可能ではありません。
S3へのファイル追加・削除をトリガーにして、自動的に同期API（Ingestion Job）を実行するパイプラインを構築しましょう。
推奨アーキテクチャ:S3 (Event Notification) -> Amazon EventBridge -> AWS Lambda -> Bedrock Agent API (StartIngestionJob)
このイベント駆動アーキテクチャにより、ユーザーがファイルをアップロードした直後に、自動的に検索対象に含まれるようになります。情報の鮮度を保つことは、社内検索システムの信頼性に直結します。
コストモニタリングと最適化
最後に、コスト管理についてです。Knowledge BasesのバックエンドとしてAmazon OpenSearch Serverlessを利用する場合、データ量に関わらず最低限のOCU（OpenSearch Compute Unit）を消費する仕様になっています。
これまでの仕様では、検索用とインデックス用でそれぞれ最小限のOCUが確保されるため、開発環境などでデータ量が少なくても一定の月額費用が発生する構造でした。最新の料金体系では、より小規模なワークロード向けの低コスト設定（0.5 OCUなど）が導入されている可能性がありますが、それでも「待機コスト」は無視できません。
実践的なコスト最適化策:
- コレクションの共有: 複数のKnowledge Baseで1つのOpenSearch Serverlessコレクションを共有し、インデックスを分けることでリソース効率を高める。
- 適切なストレージ選定: コスト要件が厳しい場合、OpenSearch Serverless以外のサポートされているベクトルストア（Aurora PostgreSQLやPineconeなど）の利用も検討する。
- 定期的な見直し: AWSの料金体系や機能は頻繁にアップデートされます。公式サイトで最新の価格情報を確認し、構成を最適化してください。
まとめ：信頼される「社内AI」を目指して
AWS Bedrock Knowledge Basesは、RAG構築のハードルを劇的に下げてくれます。しかし、「高精度な検索」を実現するためには、ツールを導入するだけでなく、以下のようなエンジニアリングアプローチが不可欠です。
- 適切なチャンキング戦略: 日本語の文脈やドキュメント構造を考慮した分割。
- ハイブリッド検索: ベクトル検索の「意味理解」と、キーワード検索の「正確性」を組み合わせる。
- メタデータ活用: 検索範囲を適切にフィルタリングし、ノイズを排除する。
- 自動化された運用: データ同期と評価のパイプライン化。
これらを実装することで、構築するRAGシステムは、「嘘ばかりつくチャットボット」から「頼れる業務アシスタント」へと進化します。
技術はあくまで手段です。大切なのは、それを使って組織のメンバーがより効率的に、より創造的に働ける環境を作ることです。Bedrock Knowledge Basesという強力な武器を手に、ぜひその変革をリードしてください。
コメント