ナレッジベースとRAGの違い｜社内文書をAmazon Bedrockで検索させる設計と権限制御【2026年版】

社内には規程も議事録もマニュアルも揃っているのに、必要なときに出てこない。原因の多くはナレッジベース製品そのものではなく、検索がキーワード一致で止まっている点にあります。RAGはその検索層を意味ベースに差し替える仕組みで、Amazon Bedrock Knowledge Basesを使えば既存のSharePointやConfluenceを取り込み元にしたまま構築できます。この記事では、社内文書という素材側で決まる4つの論点、取り込める形式、チャンクの切り方、部署ごとの権限、ベクトルストアの選択に加えて、精度が出ないときの手当ての順番と、そもそも入れるべきでない文書の見分け方まで、公式ドキュメントとAPIモデルの実測に基づいて整理します。

まとめ

ナレッジベースは文書の置き場、RAGは質問に意味の近い断片を取り出してLLMへ渡す仕組みです。両者は置き換え関係ではありません。既存のSharePoint・Confluence・Google Drive・OneDriveを直接つなげるのはBedrock Managed Knowledge Baseの7コネクタで、ベクトルストアを自前で用意する構成ではS3とCustomの2つしか選べません。

社内展開で最初に効くのは精度ではなく権限です。ACL対応検索はuserContextを渡さない限り、ACLを有効にしたデータソースが0件を返します。この引数はbotocore 1.43.32以降でないと存在せず、それ以前のバージョンでは呼び出し自体が弾かれます。

検索方式は選んだ種別で決まります。Managed Knowledge Baseは設定項目を持たない代わりに、公式の比較表で「Agentic and semantic hybrid retrieval」と明記されたハイブリッド検索を既定で行います。ベクトルストアを自分で用意する構成では自分で選べますが、ハイブリッド検索が成立するのはAmazon RDS・Amazon OpenSearch Serverless・MongoDBのうちフィルタ可能なテキストフィールドを持つものだけです。精度の手当ては返却件数、メタデータフィルタ、リランキングの順で試すと手戻りが少なくなります。以下、それぞれの判断材料を見ていきます。

ナレッジベースとRAGの役割分担と、両者をつなぐ経路

ナレッジベースが持たない「意味での検索」

ナレッジベース製品が提供するのは、文書の保管と分類、そして文字列の一致検索です。「育休 いつまで」と入力しても、本文に「育児休業給付金の支給期間」としか書かれていない規程はヒットしません。語が違うからです。

RAGはここを変えます。質問文を埋め込みモデルでベクトルに変換し、同じくベクトル化しておいた文書断片のうち距離の近いものを取り出して、LLMのプロンプトに添えて回答させます。文書の置き場を捨てるわけではなく、検索の当たり方だけを差し替える構成です。Amazon Bedrock Knowledge Basesでは、断片だけを返すRetrieveと、取得から回答生成までを一度に行うRetrieveAndGenerateの2つのAPIが用意されています。埋め込みモデル側の選定基準は埋め込みモデルとは？仕組みと日本語モデルの選び方・RAG実装での判断基準【2026年版】で扱っています。

SharePoint・Confluenceを検索対象にする2つの経路

Bedrock Knowledge Basesには、取り込みから索引・検索までAWSが持つManaged Knowledge Baseと、ベクトルストアを自分で用意するCustomer-managedの2系統があります。既存の社内ナレッジベース製品を起点にできるかどうかは、この選択でほぼ決まります。

Managedの7コネクタは、S3、SharePoint、Confluence、Webクローラ、Google Drive、OneDrive、Customです。社内ナレッジベース製品が起点なら、Managedを選ぶ以外の現実的な道はありません。Customer-managedでSharePointの文書を扱うには、いったんS3へ書き出す仕組みを別途作ることになり、その時点で更新の追随と権限の写しという2つの宿題が増えます。両者の料金差とboto3での構築手順はAmazon BedrockでRAGを実装する手順｜Managed Knowledge Baseのboto3実装と東京リージョンの制約【2026年版】にまとめています。

社内文書の取り込みで先に確認する形式・上限・同期

対応7形式と1ファイル50MBの上限

S3やコネクタ経由で取り込めるのは、プレーンテキスト（.txt）、Markdown（.md）、HTML、Word（.doc／.docx）、CSV、Excel（.xls／.xlsx）、PDFの7形式です。テキスト系はUTF-8エンコードが前提で、1ファイルあたりのサイズは50MBが上限になります。画像を含める場合、JPEGとPNGの上限は3.75MBです。

ここで落ちるのは、たいてい2種類の文書です。ひとつは50MBを超える設計資料やスキャンPDF、もうひとつは共有フォルダに散らばった旧形式のファイル（.xlsや.docではなく、それ以前の独自形式）です。取り込み前にサイズと拡張子で棚卸ししておくと、同期ジョブの失敗を追いかける時間を丸ごと節約できます。

台帳CSVを列単位で扱うmetadata.json

社内の管理台帳をCSVで持っている場合、どの列を本文として埋め込み、どの列を絞り込み用のメタデータとして残すかを指定できます。CSVはRFC4180形式・UTF-8・1行目がヘッダであることが条件で、同じ場所にfileName.csv.metadata.jsonを置きます。

{
  "metadataAttributes": {
    "doc_type": "ledger"
  },
  "documentStructureConfiguration": {
    "type": "RECORD_BASED_STRUCTURE_METADATA",
    "recordBasedStructureMetadata": {
      "contentFields": [
        { "fieldName": "対応内容" }
      ],
      "metadataFieldsSpecification": {
        "fieldsToInclude": [
          { "fieldName": "部署" },
          { "fieldName": "受付日" }
        ]
      }
    }
  }
}

CSVは1行ずつ解析され、チャンク分割と埋め込みは本文フィールドにだけ適用されます。本文として指定できるフィールドは現在1つだけで、他の列は文字列としてチャンクに紐付きます。fieldsToIncludeを書いた時点でメタデータとして扱われるのは列挙した列だけになるため、担当者メールのような個人情報の列は書かなければ自動的に外れます。fieldsToExcludeで除外する書き方もありますが、両方を同時に指定した場合の挙動は公式に定義がなく、衝突すると失敗すると明記されています。どちらか一方に寄せてください。

構造化データは埋め込み不要のSQL経路

数値の集計が答えになるデータは、ベクトル化しない経路が用意されています。Amazon RedshiftまたはAWS Glue Data Catalog（AWS Lake Formation）に接続する構成では、自然言語の質問をSQLへ変換して直接問い合わせます。「2020年から2022年で購入額の多い上位5社」のような質問がこれに当たります。売上台帳や勤怠データをPDFに固めてから埋め込むより素直ですし、精度も安定します。

社内文書のチャンク設計と既定300トークンの限界

先に選べる範囲を確認しておきます。Managed Knowledge Baseで指定できるのは既定・固定サイズ・チャンクなしの3つで、既定を選んだ場合は固定サイズチャンクの300トークン・重なり20%が適用されます。階層チャンクとセマンティックチャンクはベクトルストアを自分で用意する構成の選択肢で、セマンティックチャンクについては「managed knowledge basesではサポートされない」と公式に明記されています。

既定チャンクで足りる文書・崩れる文書

既定のチャンクは約300トークンで、文の境界を尊重して分割されます。FAQや操作手順のように1項目が短い文書なら、この設定のままで支障はありません。

崩れるのは長い規程類です。第○条の見出しと但し書きが別チャンクに割れると、「例外を除き」という条件だけが取り出され、本則が抜けた回答が生成されます。この場合は固定サイズチャンクに切り替え、1チャンクあたりの最大トークン数（1〜8192）と隣接チャンクの重なり（1〜99%）を指定します。条文の平均長より少し大きめの最大トークン数に、10〜20%程度の重なりを足すのが出発点になります。

階層チャンクの副作用と返却件数の減少

ここからはベクトルストア構成での選択肢です。階層チャンクは、親チャンクと子チャンクの2階層を作り、検索は子で行い、返すときは親に置き換えます。精度の高い小さな埋め込みと、文脈の足りる大きな断片を両立させる仕組みです。階層は2つ固定で、親と子それぞれの最大トークン数と重なりトークン数を指定します。

副作用が2つあります。ひとつは、同じ親を持つ子チャンクがまとめて親に置き換わるため、返却件数が要求した数より少なくなること。もうひとつは、ベクトルストアにS3ベクトルバケットを使う構成では階層チャンクが推奨されない点です。親子合計で8,000トークンを超えるような設定にすると、メタデータのサイズ制限に当たります。ストアの選択とチャンク戦略は独立に決められません。

チャンクなしで失う引用のページ番号

1文書を1チャンクとして扱う「チャンクなし」も選べます。事前に短いファイルへ分割済みの場合に向く設定ですが、代償があります。引用にページ番号が表示されなくなり、x-amz-bedrock-kb-document-page-numberメタデータでの絞り込みも使えません。社内文書の回答に「就業規則 12ページ」と根拠を添えたいなら、この設定は選べません。

意味の切れ目で分割するセマンティックチャンクも、ベクトルストア構成なら選べます。バッファサイズは0か1で、1を指定すると前後を合わせた3文をまとめて埋め込み、境界を判定する仕組みです。分割の閾値は50〜99パーセンタイルの範囲で指定します。Managed Knowledge Baseでは選べないため、意味の切れ目での分割を要件にするなら、種別の選択自体をここから逆算することになります。

部署・職位で見せる範囲を分けるACL対応検索

userContextの渡し方と未指定時の0件挙動

社内RAGで最初に問題になるのは検索精度ではありません。人事評価のドラフトが全社員の質問に出てくる、という事故のほうです。Managed Knowledge Baseでは、取り込み時にデータソース側の許可・拒否リストを一緒に取り込み、問い合わせ時に渡された利用者の情報で結果を絞り込めます。

import boto3

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

resp = client.retrieve(
    knowledgeBaseId="XXXXXXXXXX",
    retrievalQuery={"text": "育児休業の申請期限は"},
    userContext={"userId": "[email protected]"},
    retrievalConfiguration={
        "vectorSearchConfiguration": {
            "numberOfResults": 10,
            "filter": {"equals": {"key": "department", "value": "hr"}},
        }
    },
)

for r in resp["retrievalResults"]:
    print(r["score"], r["content"]["text"][:80])

利用者を表すのは常にメールアドレスです。別名の解決も、IDプロバイダをまたぐ突き合わせもありません。渡したアドレスがデータソース側に登録されたものと1文字でも違えば、そのデータソースからは何も返らず、しかもエラーにもなりません。無言で0件になります。

既定の振る舞いも押さえておく必要があります。userContextを省略すると、ACLを有効にしたデータソースは0件を返し、ACLを設定していないデータソースだけが通常どおり返ります。ACL情報が取れなかった文書は、公開文書であっても誰にも返りません。権限の欠落は「公開」ではなく「制限」として扱われる設計です。許可リストと拒否リストの両方に同じ利用者が現れた場合は、拒否が優先されます。

なおuserContextはbotocore 1.43.32（2026-06-17公開、Python 3.10以上）で追加された引数です。手元でAPIモデルを突き合わせたところ、直前の1.42系ではUnknown parameter in input: "userContext"としてパラメータ検証の段階で弾かれます。SDKを上げずに実装を進めると、権限制御だけが動かない状態でつまずきます。

コネクタ別のリアルタイム検証可否

絞り込みは2段階で動きます。取り込み時に取得した権限による事前フィルタと、返す直前にデータソースへ問い合わせて現在も閲覧できるかを確かめるリアルタイム検証です。後者に対応するコネクタは限られます。

S3とCustomにリアルタイム検証がないのは、権限情報が生きた権限システムからではなく利用者が用意した設定ファイル由来だからです。つまりこの2つでは、同期の間隔がそのまま権限のズレの最大値になります。異動が月初にまとまる組織なら、同期スケジュールを人事異動の反映日に合わせるだけで実害はかなり減ります。グループの所属も最後の同期時点のものが使われ、権限変更の反映は結果整合で通常は数分、外部IDプロバイダの資格情報は最大1時間キャッシュされます。

認可はアプリ側に残る責任

この機能はフィルタであって認可ではありません。Bedrock側は利用者を認証しないので、渡されたメールアドレスが本人のものかどうかを確かめる手段がありません。アプリケーション側で認証を済ませ、検証済みのIDだけを渡す前提で使います。この機能単体をアクセス制御の唯一の砦にする設計は採用すべきではありません。

失敗時の挙動は閉じる方向に倒れています。グループ解決の失敗、リアルタイム検証のタイムアウト、内部エラーのいずれでも、該当文書は返りません。一時的な障害で権限のない文書が漏れることはない代わりに、結果が0件になったとき「本当に該当なし」なのか「ACLの解決に失敗した」のかを区別する必要があります。エラー応答で判別できるので、チャットのUIでは前者を「見つかりませんでした」、後者を「一時的に確認できません」と出し分けておくと、利用者が誤って「社内に資料がない」と結論づけずに済みます。

もうひとつ、退職者のメールアドレスを別の人に再割り当てする運用は事故に直結します。リアルタイム検証は対応コネクタでの安全網にはなりますが、IDのライフサイクル管理の代わりにはなりません。

ハイブリッド検索の可否を左右するベクトルストア選択

ハイブリッド検索が成立する3つのストア

ベクトルストアを自分で選ぶ構成では、現在8種類が指定できます。Amazon OpenSearch Serverless、OpenSearchマネージドクラスター、Pinecone、Redis Enterprise Cloud、Amazon RDS（Aurora PostgreSQL）、MongoDB Atlas、Amazon Neptune Analytics、Amazon S3 Vectorsです。製品単位で料金や制限値を比べるなら、Pineconeとは？サーバーレス型ベクトルDBの料金・制限値・実装と選び分け【2026年版】のような個別記事が判断材料になります。

選定で見落とされやすいのが検索方式の制約です。ベクトル検索と生テキスト検索を組み合わせるハイブリッド検索が使えるのは、Amazon RDS・Amazon OpenSearch Serverless・MongoDBのうち、フィルタ可能なテキストフィールドを持つストアだけです。それ以外を選ぶと、overrideSearchTypeでHYBRIDを指定しても意味検索にフォールバックします。

社内文書は型番、社内略語、システム名、規程番号といった固有表記の塊です。「AX-2200の保守条件」のような質問では、意味の近さより文字列の一致が効きます。ここを捨てる判断は慎重にしてください。なおこの制約はベクトルストア構成の話です。Managed Knowledge Baseに検索方式の設定項目はありませんが、公式の比較表では検索方式が「Agentic and semantic hybrid retrieval」と記載されており、既定でハイブリッド検索が行われます。固有表記の取りこぼしはManagedを選んだ場合の懸念には当たりません。

S3 Vectorsで下がるコストと外れる機能

Amazon S3 Vectorsは2025年12月2日に一般提供が始まり、2026年3月31日の17リージョン追加で計31リージョンに広がりました。ベクトルのアップロード・保存・クエリの総コストを最大90%削減するとされ、1インデックスあたり20億ベクトル、1バケットあたり1万インデックスまで拡張できます。書き込みは単一ベクトルのストリーミング更新で毎秒1,000ベクトル、1クエリで最大100件の取得、ベクトル1件あたり50のメタデータキーを保持できます。

ただし外れるものがあります。ハイブリッド検索の対象外であること。階層チャンクが推奨されないこと。バイナリベクトルの保存に対応しないこと（対応するのはOpenSearch ServerlessとOpenSearchマネージドクラスターだけです）。そして、S3ベクトルバケットのインデックスではstartsWithとstringContainsのフィルタが使えないこと。この4点目は、部署コードや文書番号の前方一致で絞る設計と正面からぶつかります。

判断はこうなります。数千万件規模の議事録やメールアーカイブを意味検索だけで引ければ足りるなら、S3 Vectorsのコスト差は他の要素を圧倒する差になります。一方、規程や技術文書のように固有表記での一致が回答品質を左右する用途なら、OpenSearch Serverlessを選んで固定サイズチャンクと組み合わせるほうが、後から精度を取り戻す手間は小さく済みます。

精度が出ないときに順に試す手当て

返す件数と検索方式の見直し

問い合わせに対して返る断片は、既定で最大5件です。社内規程のように関連条項が複数箇所に散る文書では、この5件が単純に足りていないだけということがよくあります。numberOfResultsは最大100まで指定できるので、まず10〜20に上げて回答が改善するかを見ます。階層チャンクを使っている場合、この値は子チャンクの取得数を指し、親に置き換わる分だけ実際の返却件数は減ります。指定した数より少ないことを異常と誤認しないでください。

メタデータフィルタの演算子制約と暗黙フィルタでの自動生成

件数を増やしても古い版の規程が混ざる場合は、絞り込みの出番です。手動のフィルタではequals、notEquals、greaterThan、greaterThanOrEquals、lessThan、lessThanOrEquals、in、notIn、listContains、startsWith、stringContainsが使え、andAllとorAllで組み合わせます。ただしstartsWithとstringContainsは、Managed Knowledge Baseでも、S3ベクトルバケットのインデックスを使うベクトルストア構成でも使えません。部署コードの前方一致で絞る設計は、この2つの構成で破綻します。inで候補を列挙する形が結局は共通解になります。

利用者にフィルタを意識させたくない場合は、質問文からフィルタを自動生成させる方法があります。属性のスキーマとモデルを渡すと、Claudeが問い合わせの内容に応じた絞り込み条件を組み立てる仕組みです。なお公式ドキュメントでこの設定が説明されているのはベクトルストア構成のクエリ設定の側で、Managed Knowledge Baseの設定項目一覧には現れません。

resp = client.retrieve(
    knowledgeBaseId="XXXXXXXXXX",
    retrievalQuery={"text": "2025年度の情報セキュリティ規程"},
    retrievalConfiguration={
        "vectorSearchConfiguration": {
            "numberOfResults": 20,
            "implicitFilterConfiguration": {
                "modelArn": (
                    "arn:aws:bedrock:ap-northeast-1::foundation-model/"
                    "anthropic.claude-haiku-4-5-20251001-v1:0"
                ),
                "metadataAttributes": [
                    {
                        "key": "fiscal_year",
                        "type": "NUMBER",
                        "description": "文書が対象とする年度。例 2025",
                    },
                    {
                        "key": "doc_type",
                        "type": "STRING",
                        "description": "文書種別。regulation, minutes, manual のいずれか",
                    },
                ],
            },
        }
    },
)

属性の型はSTRING、NUMBER、BOOLEAN、STRING_LISTから選びます。descriptionはモデルへの指示そのものなので、「年度」とだけ書かず「文書が対象とする年度。例 2025」のように値の形式まで書いたほうが生成されるフィルタが安定します。

組み込みリランカーとBedrockリランカーモデルの使い分け

件数と絞り込みでも順位が噛み合わないときに、取得後の並べ替えを挟みます。Managed Knowledge Baseには組み込みのセマンティックリランカーが追加費用なしで付属し、必要ならBedrockのリランカーモデルを指定することもできます。ベクトルストア構成では組み込みが無いため、Bedrockのモデルを自分で指定します。検索工程そのものの改善手法はリトリーバルとは？RAGの検索工程の仕組みと実装・精度改善の判断基準【2026年版】で詳しく扱っています。改善の効果を体感で判断しないための測り方はRAG評価とは？検索と生成を分けて測る指標・Ragasでの実装・運用への組み込み【2026年版】を参照してください。

社内RAGに向かない文書と、その代わりの置き場

すべての社内文書をひとつのKnowledge Baseに入れる設計は、たいてい失敗します。次の3つは、精度の問題ではなく当てはめ違いです。

• 権限が日単位で動く案件フォルダ。S3とCustomコネクタにはリアルタイム検証がなく、同期の間隔ぶん古い権限で結果が返ります。
• 数値の集計が答えになる台帳。前述の構造化データ接続に回せば、埋め込みを作らずに答えが出ます。
• 社外にも見せる公開情報とのごちゃ混ぜ。Webクローラのコネクタは権限モデルを持たないためACL対応を有効化できず、権限付きの社内文書と同居させると設計が破綻します。

特に3つ目は分けてください。公開情報用と社内権限付きの2つのKnowledge Baseに分割し、アプリ側で問い合わせ先を切り替えるほうが、ひとつに詰め込んで例外処理を書き足すより結果的に短い実装で済みます。チャットとして社内に出すところまでの方式比較はAIチャットボットの作り方｜生成AI＋RAG・ノーコード・受託開発の方式選定と実装手順にまとめています。

よくある質問

ナレッジベースとRAGは何が違いますか？

ナレッジベースは社内文書を蓄積・分類しておく仕組みで、検索は文字列の一致が中心です。RAGは質問文をベクトル化し、意味の近い文書断片を取り出してLLMに渡して回答を生成させる仕組みを指します。RAGはナレッジベースを置き換えるものではなく、その検索層と回答生成を追加する関係にあります。Amazon Bedrock Knowledge Basesの場合、既存のナレッジベース製品をデータソースとして接続し、断片取得のRetrieveと回答生成込みのRetrieveAndGenerateで使い分けます。

既存のConfluenceやSharePointをそのままRAGの対象にできますか？

Bedrock Managed Knowledge Baseなら可能です。S3、SharePoint、Confluence、Webクローラ、Google Drive、OneDrive、Customの7つのネイティブコネクタが用意されており、取り込み・保存・索引・検索の基盤はAWS側が持ちます。一方、ベクトルストアを自分で用意するCustomer-managedの構成ではS3とCustomの2つしか選べないため、SharePointの文書を扱うにはS3へ書き出す仕組みを別に作る必要があります。

ベクトルデータベースはどれを選べばよいですか？

そもそもManaged Knowledge Baseを選ぶ場合、ベクトルストアはAWS側が持つためこの選択自体が不要です。ベクトルストアを自分で用意する構成なら、検索方式から逆算してください。ハイブリッド検索が使えるのはAmazon RDS・Amazon OpenSearch Serverless・MongoDBのうちフィルタ可能なテキストフィールドを持つ構成に限られ、他のストアでは意味検索になります。型番や規程番号のような固有表記で引く社内文書ならOpenSearch Serverlessが無難です。大量のアーカイブを意味検索だけで引く用途なら総コストを最大90%削減できるAmazon S3 Vectorsが有力ですが、階層チャンクが推奨されず前方一致フィルタも使えない点は設計に織り込んでください。

検索結果に古い規程が混ざるときは何から直しますか？

順序は3つです。第一に返却件数で、既定は最大5件、上限は100件なので10〜20件に上げて改善するかを確認します。第二にメタデータフィルタで、年度や文書種別の属性を付けて絞り込みます。属性のスキーマとモデルを渡せば質問文からフィルタを自動生成させることもできます。第三にリランキングです。チャンクの切り方が原因のこともあるため、条文が途中で割れていないかも併せて確認してください。

社内チャットボットとして公開するとき、権限はどう扱いますか？

Managed Knowledge BaseのACL対応検索を使い、RetrieveリクエストにuserContextで利用者のメールアドレスを渡します。渡さない場合、ACLを有効にしたデータソースは0件を返します。ただしこれはフィルタであって認可ではなく、Bedrockは利用者を認証しません。アプリケーション側で認証を済ませ、検証済みのIDだけを渡す設計が前提です。この引数はbotocore 1.43.32以降で追加されたため、SDKのバージョンも併せて確認してください。

関連記事

• Amazon BedrockでRAGを実装する手順｜Managed Knowledge Baseのboto3実装と東京リージョンの制約【2026年版】
• リトリーバルとは？RAGの検索工程の仕組みと実装・精度改善の判断基準【2026年版】
• 埋め込みモデルとは？仕組みと日本語モデルの選び方・RAG実装での判断基準【2026年版】
• AIチャットボットの作り方｜生成AI＋RAG・ノーコード・受託開発の方式選定と実装手順
• RAG評価とは？検索と生成を分けて測る指標・Ragasでの実装・運用への組み込み【2026年版】