ナレッジベースは文書をためておく置き場で、RAGは質問に近い文書の断片を検索してLLMに渡し、回答を書かせる仕組みです。片方がもう片方を置き換える関係ではありません。ややこしいのは、Amazon BedrockやDifyのようなAI製品が、RAGの検索層そのものを「ナレッジベース」と呼んでいる点です。この記事では、まず両者の違いを軸ごとに比べ、次に社内文書をAmazon Bedrock Knowledge Basesに載せるときに決まる、取り込み形式、チャンク、部署ごとの権限、ベクトルストアの選び方を、2026年11月時点の公式ドキュメントとAPIモデルに基づいて整理します。
まとめ
ナレッジベースは「何を持っているか」、RAGは「それをどう引いて答えに使うか」を指す言葉です。キーワード一致の社内検索で見つからない文書も、RAGが使うベクトル検索なら意味の近さで拾えます。一方で、もっともらしい誤答という新しい失敗も生まれます。AI製品の文脈では、元の文書の置き場は「データソース」、そこから作った検索用の索引が「ナレッジベース」と呼ばれます。
Amazon Bedrockで既存のSharePointやConfluenceを取り込み元にするなら、Bedrock Managed Knowledge Baseを選びます。2026年9月30日以降、ベクトルストアを自分で用意するCustomer-managed構成では、Confluence・SharePoint・Salesforce・Web Crawlerのコネクタを新しく作れません。Managed構成ではRetrieveAndGenerateが使えないため、回答の生成はAgenticRetrieveStreamを使うか、Retrieveの結果を自分でモデルに渡します。
社内展開で最初に効くのは精度より権限です。ACL対応検索はuserContextを渡さないと、ACLを有効にしたデータソースから0件を返します。0件の原因はbotocore 1.43.72で追加されたCheckIngestedDocumentAclで切り分けられます。精度の手当ては、返却件数、メタデータフィルタ、リランキング、検索指示の順に試すと手戻りが少なくなります。
ナレッジベースとRAGの違いを5つの軸で比較
RAGはRetrieval-Augmented Generation（検索拡張生成）の略です。2020年にLewisらが論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」で示した方式で、外部の文書を検索して得た断片を生成モデルの入力に添えます。定義上の違いは、情報を蓄積する基盤か、検索結果を使って回答を生成する方式かにあります。検索方式や更新方法は実装で変わるため、次の表はキーワード検索型の文書管理と、ベクトル検索型のRAGの代表的な構成を比べたものです。
| 軸 | ナレッジベース | RAG |
|---|---|---|
| 正体 | 文書の置き場（製品・データ） | 処理の流れ（方式） |
| 探し方 | キーワード一致・タグ・階層 | ベクトルの近さ（＋キーワード） |
| 返すもの | 文書の一覧 | 根拠付きの回答文 |
| 更新 | 文書を書き換える | 再同期して索引を作り直す |
| 失敗の形 | 見つからない | もっともらしい誤答 |
キーワード一致では届かない質問の例
同義語展開のないキーワード一致検索では、「育休」という略称が「育児休業」という正式名称に一致せず、規程を見落とす場合があります。RAGは質問文を埋め込みモデルでベクトルに変換し、あらかじめベクトル化しておいた文書の断片から距離の近いものを取り出します。語が違っても意味が近い文書を拾えるのは、ベクトル検索の特徴です。この検索機能は、回答生成を伴わないナレッジベースの検索にも利用できます。
代わりに増えるのが回答文の誤りです。古い版の規程が混ざっていれば、RAGはそれを根拠に自信のある文章を書きます。後述する件数・フィルタ・権限の設計は、この利用者が気づきにくい失敗を減らすためのものです。埋め込みモデルの選び方は埋め込みモデルとは？仕組みと日本語モデルの選び方・RAG実装での判断基準【2026年版】で扱っています。
ファインチューニングや全文検索との位置関係
ファインチューニングはモデルの重みに知識や振る舞いを覚えさせ、RAGは問い合わせのたびに文書を引きます。改定が続く規程は、再学習が要らないRAGのほうが向きます。判断基準とコストの比較はRAGとファインチューニングの違いと使い分け｜判断基準とコストで選ぶ2026年の実装方針にまとめています。
全文検索とRAGは対立しません。型番や規程番号のような固有表記は文字列一致のほうが強いため、実務ではベクトル検索とキーワード検索を併用するハイブリッド検索が使われます。どのベクトルストアで併用できるかは後半で整理します。
AI製品の「ナレッジベース」がRAGの検索層を指す理由
「ナレッジベースとRAGの違い」で迷う人の多くは、この同名異義に引っかかっています。ナレッジマネジメントの文脈でナレッジベースと言えば、社内wikiやFAQのような文書の置き場です。ところがAI製品の画面やドキュメントでは、同じ言葉がRAG用に作った検索索引を指します。
| 文脈 | 「ナレッジベース」が指すもの | 元の文書の呼び名 |
|---|---|---|
| ナレッジマネジメント | 社内wiki・FAQ・文書管理 | ナレッジベースそのもの |
| Amazon Bedrock | ベクトル索引などの検索リソース | データソース |
| Dify | 検索してモデルへ渡す層 | コンテンツのソース |
Amazon BedrockのKnowledge Baseは、文書をベクトル化して検索する構成に加え、既存のKendraインデックスや構造化データストアへ接続する構成も持つ検索リソースです。APIモデル上の種別はVECTOR・KENDRA・SQL・MANAGEDの4つで、どれも検索の受け口です。Difyの公式ドキュメントも「質問が届くと、最も関連性の高い文章が検索され、質問と一緒にモデルに渡されます」と説明しており、これはRAGの説明そのものです。Difyには自動で索引を作るAgentナレッジベースと、チャンクや検索方法を自分で決める従来型ナレッジベースの2種類があり、1ファイルの上限は前者が全プラン15MB、後者がProfessionalとTeamで50MBです。
つまりAI製品で「ナレッジベースを作る」と言うとき、社内wikiを新しく作る話ではなく、既存の文書からRAG用の索引を作る話をしています。ベンダーの提案書を読むときは、どちらの意味で書かれているかを先に確かめてください。置き場としてのナレッジベースの作り方と社内wiki・FAQとの違いはナレッジベースとは？意味と種類、社内wiki・FAQとの違いと作り方・AI連携の基準で解説しています。Difyでの具体的な設定はDifyでチャットボットを作る手順｜種別の選び分けと社内公開・ナレッジ設定【1.18対応】が詳しいところです。
既存のナレッジベースをBedrockの取り込み元にする経路
ManagedとCustomer-managedの比較
Amazon Bedrock Knowledge Basesには、取り込みから索引・検索までAWSが持つBedrock Managed Knowledge Baseと、ベクトルストアを自分で用意するCustomer-managedの2系統があります。公式の比較表から、社内文書の扱いに効く行を抜き出します。
| 項目 | Managed | Customer-managed |
|---|---|---|
| コネクタ | 7種（比較表） | S3・Customのみ |
| ベクトルDBの運用 | 不要 | 自分で用意 |
| 検索方式 | 既定でハイブリッド | 自分で選択 |
| エージェント型検索 | 対応 | 非対応 |
| ACL対応検索 | 対応 | 非対応 |
| リランカー | 組み込み（指定も可） | Bedrockのモデルを指定 |
比較表のManaged 7種は、S3、SharePoint、Confluence、Web Crawler、Google Drive、OneDrive、Customです。ACL対応表のページにはBoxやServiceNowなども並んでおり公式内で数が割れているので、使いたい製品は接続手順のページで確かめてください。料金差とboto3での構築手順はAmazon BedrockでRAGを実装する手順｜Managed Knowledge Baseのboto3実装と東京リージョンの制約【2026年11月】にまとめています。
2026年9月30日以降のCustomer-managedのコネクタ
データソース接続のページには、2026年9月30日以降、Customer-managedのKnowledge BaseでConfluence、Microsoft SharePoint、Salesforce、Web Crawlerのコネクタを新しく作れなくなったと書かれています。作成済みのコネクタは取り込みも検索も続けて動きますが、これから社内ナレッジベース製品をつなぐなら、AWSが推奨するとおりManagedを選ぶことになります。Customer-managedで新たにSharePointの文書を取り込むなら、S3経由やCustomデータソース経由の連携を自前で実装する方法があり、更新への追随と権限の写しという2つの作業が増えます。
Managedで回答を生成するAPI
取得から回答生成までを1回で行うRetrieveAndGenerateとRetrieveAndGenerateStreamは、Managed Knowledge Baseでは使えません。APIリファレンスは「This API cannot be used with managed knowledge bases. Use AgenticRetrieveStream or Retrieve with managed knowledge bases.」と明記しています。Managedで回答文まで得るには、質問を分解して繰り返し検索し、既定で回答も生成するAgenticRetrieveStreamを使うか、Retrieveで断片だけを受け取って自分でモデルに渡します。2024年頃の解説記事のサンプルを写すと、ここで止まります。
社内文書の取り込みで先に確認する形式・上限・同期
対応7形式と1ファイル50MBの上限
対応形式の一覧は、.txt、.md、.html、.doc／.docx、.csv、.xls／.xlsx、.pdfの7形式です。テキスト系はUTF-8が前提で、1ファイルの上限は50MB、JPEGとPNGの画像は3.75MBまでです。Managedでは詳細設定から、文書内の図、音声（.mp3・.wavなど）、動画（.mp4・.movなど）の索引も有効にできます。
取り込み前には、50MBを超えるファイル、選択したパーサーでは文字を抽出できないスキャンPDF、対応拡張子に含まれないファイルを確認します。取り込み前にサイズと拡張子で棚卸ししておきます。
台帳CSVを列単位で扱うmetadata.json
S3に置いた管理台帳の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": "受付日" }
]
}
}
}
}本文として指定できる列は1つだけです。fieldsToIncludeを書くと、列挙した列だけがメタデータになるため、担当者メールのような個人情報の列は書かなければ外れます。fieldsToExcludeとの両方に同じ列名を指定すると、検証エラーになります。この例では必要な列だけを列挙するため、fieldsToIncludeだけを使います。
同期スケジュールと権限のズレの上限
文書を追加・変更・削除したら、データソースを同期して索引に反映します。同期は差分だけを処理します。2026年8月にはデータソースごとの同期スケジュールが加わり、APIではbotocore 1.43.83（2026年8月28日公開）以降のsyncScheduleで指定します。
- オンデマンド（既定）：手動で開始したときだけ同期
- 毎日：1日1回。実行時刻はAWSが決め、指定できない
- 毎週：曜日を指定
- 毎月：1〜28日か月末を指定
自動で回せる最短の間隔は1日です。後述のとおりS3とCustomのコネクタは権限をリアルタイムで確かめないため、日次同期でも権限変更の反映には、次回同期までの待ち時間に加えて取り込みと権限情報の伝播の時間がかかります。異動の反映を当日中に済ませたいなら、人事システムの更新をきっかけにStartIngestionJobを自前で呼ぶ仕組みが要ります。
社内文書のチャンク設計と既定300トークンの限界
Managedのコンソールで選べるチャンク方式は、既定・固定サイズ・チャンクなしの3つです。階層チャンクとセマンティックチャンクは、Customer-managed構成でAPIのchunkingStrategyにHIERARCHICALやSEMANTICを指定したときの選択肢です。
既定チャンクで足りる文書・崩れる文書
既定のチャンクは約300トークンで、文の境界を保って分割します。FAQや操作手順のように1項目が短い文書は、既定設定で評価を始め、質問と回答や手順の前提条件が分断されないかを確認します。
崩れるのは長い規程です。第○条の見出しと但し書きが別のチャンクに割れると、「例外を除き」という条件だけが取り出され、本則の抜けた回答ができます。この場合は固定サイズに切り替え、最大トークン数（1〜8192）と重なり（1〜99%）を指定します。条文の平均長より少し大きい最大トークン数に、10〜20%の重なりを足すところから試すのが無難です。
表・図の検索結果に付くページ文脈と10,000字の条件
Markdownとして処理された文書で、ページに表や図がある場合、そのページ全体または表全体がチャンクの文脈として付きます。検索で当たったチャンクは文脈に置き換えて返され、同じ文脈を持つチャンクは1件にまとまります。付くのはページ全体か表全体が10,000字以下のときだけで、それを超えると当たったチャンクがそのまま返ります。料金表が途中で切れずに返る代わりに、返却件数が指定より少なく見える原因にもなります。
チャンクなしで失う引用のページ番号
1文書を1チャンクとして扱う「チャンクなし」は、事前に短いファイルへ分割済みの文書に向く設定です。代わりに、引用にページ番号が出なくなり、x-amz-bedrock-kb-document-page-numberでの絞り込みも使えません。回答に「就業規則 12ページ」と根拠を添えたいなら選べない設定です。Customer-managedで階層チャンクを使う場合は、S3ベクトルバケットとの組み合わせが推奨されていない点にも注意してください。親子合計で8,000トークンを超えるような設定では、メタデータのサイズ制限に当たる可能性があります。
部署・職位で見せる範囲を分ける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={
"managedSearchConfiguration": {"numberOfResults": 10}
},
)
for r in resp["retrievalResults"]:
print(r["score"], r["content"]["text"][:80])利用者を表すのは常にメールアドレスで、データソース側に登録されたものと完全に一致する必要があります。別名の解決も、IDプロバイダをまたぐ突き合わせもありません。1文字でも違えば、そのデータソースからは何も返らず、エラーにもなりません。
ACL対応検索のページによれば、userContextを省略するとACLを有効にしたデータソースは0件を返し、ACLの無いデータソースだけが通常どおり返ります。ACL情報が取れなかった文書は、公開文書であっても誰にも返りません。許可と拒否の両方に同じ利用者がいれば拒否が優先され、リアルタイム検証で外れた分は補充されないため、返却件数が指定より少なくなることもあります。なおuserContextはbotocore 1.43.32（2026年6月17日公開、Python 3.10以上）で追加された引数で、それより前の版ではパラメータ検証で弾かれます。
コネクタ別のリアルタイム検証可否
絞り込みは2段階で動きます。取り込み時に取得した権限による事前フィルタと、返す直前にデータソースへ問い合わせて今も閲覧できるかを確かめるリアルタイム検証です。公式の対応表を社内文書でよく使う接続先に絞ると、次のとおりです。
| コネクタ | 事前フィルタ | リアルタイム検証 |
|---|---|---|
| SharePoint・OneDrive | 対応 | 対応 |
| Google Drive | 対応 | 対応 |
| Confluence（Data Center含む） | 対応 | 対応 |
| Box・Zendesk・Salesforce | 対応 | 対応 |
| ServiceNow | 対応 | 一部 |
| Amazon S3・Custom | 対応 | 非対応 |
| Web Crawler | 非対応 | 該当なし |
S3とCustomにリアルタイム検証が無いのは、権限情報が利用者の用意した設定ファイル由来だからです。グループの所属も最後の同期時点のものが使われます。外部IDプロバイダの資格情報は最大1時間キャッシュされ、権限変更の反映は結果整合で通常は数分です。非常に大きなグループに属する利用者は、同期が終わってもしばらく文書が見えないことがあると公式は注記しています。
ACL点検APIによる検索結果0件の原因切り分け
0件が返ったとき、本当に該当文書が無いのか、ACLで外れたのかを推測で判断すると、権限を緩める方向の誤った修正につながります。botocore 1.43.72（2026年8月14日公開）以降には、取り込まれたACLを確かめるCheckIngestedDocumentAclとGetIngestedDocumentAclがあります。
chk = client.check_ingested_document_acl(
knowledgeBaseId="XXXXXXXXXX",
dataSourceId="YYYYYYYYYY",
documentId="DOCUMENT_ID",
userContext={"userId": "[email protected]"},
)
print(chk["hasAccess"])
acl = client.get_ingested_document_acl(
knowledgeBaseId="XXXXXXXXXX",
dataSourceId="YYYYYYYYYY",
documentId="DOCUMENT_ID",
)
print(acl["documentAcl"])hasAccessがfalseなら、取り込まれた許可・拒否リストをdocumentAclで見て、メールアドレスの表記揺れか、ACLの取り込み漏れかを確かめます。呼び出しにはそれぞれbedrock:CheckIngestedDocumentAclとbedrock:GetIngestedDocumentAclの権限が要ります。
認可はアプリ側に残る責任
この機能はフィルタであって認可ではありません。Bedrockは利用者を認証しないため、アプリ側で認証を済ませ、検証済みのIDだけを渡します。ACL対応検索だけをアクセス制御の唯一の仕組みにする設計は採るべきではありません。
グループ解決の失敗やリアルタイム検証のタイムアウトでは、該当文書は返りません。エラー応答でACLの解決失敗を見分けられるので、チャット画面では「見つかりませんでした」と「一時的に確認できません」を出し分けます。退職者のメールアドレスを別の人に再割り当てする運用は事故に直結するので避けてください。
ハイブリッド検索の可否を左右するベクトルストア選択
この章はCustomer-managed構成の話です。Managedではベクトルストアの選択自体が無く、比較表上は既定でハイブリッド検索になります。
ハイブリッド検索が成立する3つのストア
Customer-managedで選べるベクトルストアは、OpenSearch Serverless、Pinecone、Aurora PostgreSQL、S3 Vectorsなど8種類です。ベクトル検索と生テキスト検索を組み合わせるハイブリッド検索が使えるのは、Amazon RDS・Amazon OpenSearch Serverless・MongoDBのうち、フィルタ可能なテキストフィールドを持つものだけです。それ以外ではoverrideSearchTypeにHYBRIDを指定しても意味検索になります。
社内文書は型番や規程番号といった固有表記の塊で、「AX-2200の保守条件」のような質問では意味の近さより文字列の一致が効きます。製品ごとの料金体系はベクトルデータベースの価格とおすすめ｜3タイプの料金体系比較とRAG用途の選び方【2026年版】で比べています。
S3 Vectorsで下がるコストと外れる機能
Amazon S3 Vectorsは2025年12月2日に一般提供が始まり、総コストを最大90%削減するとされています。代わりに、ハイブリッド検索の対象外で、階層チャンクも推奨されず、BedrockのドキュメントではstartsWithとstringContainsのフィルタが使えないとされています。S3 Vectors本体には2026年9月30日に事前フィルタの拡張モードが加わりましたが、Knowledge Base経由の制約の記述は変わっていません。S3 Vectors単体の仕様はAmazon S3 Vectors APIとは？全21操作・boto3実装・東京の料金と事前フィルタを解説【2026年10月】で扱っています。数千万件規模の議事録やメールを意味検索だけで引ければ足りるならS3 Vectorsのコスト差が効き、固有表記の一致が回答品質を左右する用途ならOpenSearch Serverlessのほうが後から精度を取り戻す手間は小さく済みます。
精度が出ないときに順に試す手当て
検索結果の返却件数の調整
問い合わせに返る断片は、既定で最大5件です。関連条項が複数箇所に散る規程では、この5件が足りていないだけということがよくあります。件数はManagedならmanagedSearchConfiguration、Customer-managedならvectorSearchConfigurationのnumberOfResultsで指定し、どちらも最大100です。まず10〜20に上げて回答が変わるかを見ます。Customer-managedの階層チャンクではこの値が子チャンクの取得数を指し、親に置き換わる分だけ実際の件数は減ります。
メタデータフィルタの演算子制約と暗黙フィルタ
件数を増やしても古い版の規程が混ざる場合は、年度や文書種別のメタデータで絞り込みます。演算子はequalsやinなど11種類あり、andAllとorAllで組み合わせます。ただしクエリ設定のページでは、startsWithはOpenSearch Serverlessのベクトルストアでしか使えず、ManagedではstartsWithもstringContainsも使えません。部署コードの前方一致で絞る設計は多くの構成で成り立たないので、inで候補を列挙する形が共通解になります。Managedでは_source_uriや_data_source_idのような下線始まりの項目が予約されています。
利用者にフィルタを意識させたくない場合は、質問文からフィルタを生成させる暗黙フィルタがあります。公式に説明されているのはベクトルストア構成のRetrieveで、対応モデルはAnthropic Claudeです。
resp = client.retrieve(
knowledgeBaseId="XXXXXXXXXX",
retrievalQuery={"text": "2025年度の情報セキュリティ規程"},
retrievalConfiguration={
"vectorSearchConfiguration": {
"numberOfResults": 20,
"implicitFilterConfiguration": {
"modelArn": MODEL_ARN, # 利用するClaudeモデルのARN
"metadataAttributes": [
{
"key": "fiscal_year",
"type": "NUMBER",
"description": "文書が対象とする年度。例 2025",
},
{
"key": "doc_type",
"type": "STRING",
"description": "文書種別。regulation, minutes, manual のいずれか",
},
],
},
}
},
)属性の型はSTRING、NUMBER、BOOLEAN、STRING_LISTから選びます。descriptionはモデルへの指示そのものなので、「年度」とだけ書かず、値の形式まで書いたほうが生成されるフィルタが安定します。東京リージョンではClaude Haiku 4.5が素のモデルIDでのオンデマンド呼び出しに対応していないため、MODEL_ARNには自分のアカウントで呼べるモデルを指定し、検証環境で通ることを確かめてから組み込んでください。
リランカーによる順位調整と検索指示による回答制御
件数と絞り込みでも順位が噛み合わないときは、取得後の並べ替えを挟みます。Managedの組み込みセマンティックリランカーは、マネージド埋め込みモデルを使う構成で追加費用なしに利用できます。カスタム埋め込みモデルを使う構成では、Bedrockのリランカーモデルを指定するか、リランキングを無効にします。Customer-managedでは組み込みが無いため、Bedrockのモデルを自分で指定します。
ManagedのAgenticRetrieveStreamには、2026年10月にbotocore 1.43.115で検索指示（retrieval instruction）が加わりました。質問の解釈と検索で優先すること（retrievalGuidance）、口調や言語（persona）、回答と引用の形式（answerFormat）、根拠が弱いときや範囲外の質問への対応（answerPolicy）の4項目を、1アカウント1リージョンあたり50件まで登録できます。4項目の合計は24,000字が上限です。persona以下の3項目は回答を生成する設定のときだけ効きます。作成直後は内容の審査が終わるまで使えず、通ったものは番号付きの版として固定できます。「就業規則の質問には改定日の新しい条文を優先し、該当が無ければ人事部の窓口を案内する」といった社内ルールを、プロンプトに毎回書かずに済みます。検索工程の改善手法はリトリーバルとは？RAGの検索工程の仕組みと実装・精度改善の判断基準【2026年版】、効果の測り方はRAG評価とは？検索と生成を分けて測る指標・Ragasでの実装・運用への組み込み【2026年版】で扱っています。
社内RAGに向かない文書と、その代わりの置き場
社内文書を1つのKnowledge Baseにまとめる前に、権限変更の反映期限、集計の必要性、公開範囲の分離要件を確認します。次の3つは精度の問題ではなく、当てはめ違いです。
- 権限が日単位で動く案件フォルダ。S3とCustomにはリアルタイム検証が無く、自動同期の最短は1日なので、その間は古い権限で結果が返ります。
- 数値の集計が答えになる台帳。Amazon RedshiftかAWS Glue Data Catalogに接続する構造化データの経路なら、質問をSQLに変換して直接問い合わせます。
- 社外向けと社内向けで検索対象を分離したい情報。Web CrawlerではACL対応を有効にできず、その文書は
userContextにかかわらず全利用者への返却対象になります。
社外向けと社内向けで検索対象や運用担当を分離する要件がある場合は、公開情報用と社内権限付きの2つのKnowledge Baseに分け、アプリ側で問い合わせ先を切り替えるほうが、1つに詰め込んで例外処理を足すより短い実装で済みます。文書の棚卸しから権限設計、評価までを含めて社内RAGを立ち上げる場合は、RAG構築支援でも相談を受け付けています。チャットとして社内に出すまでの方式比較はAIチャットボットの作り方｜生成AI＋RAG・ノーコード・受託開発の方式選定と実装手順にまとめています。
よくある質問
ナレッジベースとRAGは何が違いますか？
ナレッジベースは文書やデータを蓄積・整理して参照できるようにした基盤です。検索方式は製品や構成によって異なり、文字列一致に限定されません。RAGは質問に意味の近い文書の断片を検索し、LLMに渡して回答を書かせる仕組みです。RAGはナレッジベースを置き換えるものではなく、その上に意味での検索と回答生成を足す関係にあります。
Amazon Bedrock Knowledge BasesはRAGそのものですか？
RAGを実装するためのサービスで、文書の取り込み・索引化・検索に加え、APIによって回答生成まで提供します。構造化データをSQLで問い合わせる構成もあります。回答の生成は、Customer-managed構成ならRetrieveAndGenerate、Managed構成ならAgenticRetrieveStreamか、Retrieveの結果を自分でモデルに渡す形で行います。Managed構成ではRetrieveAndGenerateは使えません。
AIのナレッジベース製品を比較するときは何を見ればよいですか？
精度の宣伝より先に、既存の文書の置き場に直接つなげるか、文書単位の権限を検索結果に反映できるか、同期の間隔をどこまで短くできるかの3点を確かめてください。Amazon Bedrockなら、SharePointやConfluenceへの直接接続とACL対応検索はManaged構成だけの機能で、自動同期の最短は1日です。
Amazon BedrockならManaged Knowledge Baseで可能です。Customer-managed構成では2026年9月30日以降、Confluence・SharePoint・Salesforce・Web Crawlerのコネクタを新しく作れません。既存コネクタは継続利用でき、新規連携にはS3経由やCustomデータソース経由の実装が選択肢になります。
社内チャットボットとして公開するとき、権限はどう扱いますか？
Managed Knowledge BaseのACL対応検索を使い、RetrieveのuserContextに利用者のメールアドレスを渡します。渡さない場合、ACLを有効にしたデータソースは0件を返します。これはフィルタであって認可ではないため、アプリ側で認証を済ませ、検証済みのIDだけを渡してください。
