社内規程や業務マニュアルを根拠に回答するAIを作るとき、RAGの検索処理だけでなく、認証、セッション分離、ツール権限、監査ログまで考える必要があります。
本記事では、Amazon Bedrock AgentCoreのHarnessを会話の実行基盤にし、AgentCore GatewayからAmazon Bedrock Managed Knowledge Basesを呼び出す最小構成を作ります。検証用文書には架空企業の規程を使い、実在企業のデータは使用しません。
画面名や仕様は更新される可能性があります。本稿は2026年8月18日に東京リージョンの実環境で操作し、公式ドキュメントと照合しています。
今回、実際に確認したこと
架空の「サンプル株式会社」のMarkdown文書3件だけを使い、次の経路を実際に構築しました。顧客資料や実在企業の社内文書は使っていません。
| 項目 | 検証内容 |
|---|---|
| データ | 出張旅費規程、情報セキュリティ規程、入社初日ガイド |
| Knowledge Base | Managed KB、S3データソース、標準パーサー |
| ツール接続 | AgentCore GatewayのKnowledge Base connector |
| 実行 | AgentCore Harness＋Amazon Nova 2 Lite |
| 質問 | 国内出張の宿泊費上限と精算期限 |
| 結果 | 1泊12,000円（税込）、帰着日の翌日から5営業日以内、根拠文書名を表示 |
完成構成
処理の流れは次の通りです。
- ユーザーの質問をBackend APIが受け取る
- Backendが会話単位のSession IDを付けてHarnessを呼ぶ
- Harnessが必要に応じてGateway上のKB検索ツールを選ぶ
- Managed Knowledge Basesが関連チャンクを返す
- モデルが検索結果を根拠に回答し、出典を表示する
ブラウザからAWS APIを直接呼ぶ構成にはしません。認証、レート制御、権限判定、監査ログはBackend側に集約します。
前提
- AWSアカウント
- AgentCore、Amazon Bedrock、S3を利用できる同一リージョン
- 利用する基盤モデルへのアクセス
- 最小権限のIAM実行ロール
AgentCore Harness自体に追加料金はなく、モデル推論、Gateway、Knowledge Basesなど利用した基盤リソースに応じて課金されます。検証終了後に不要なリソースを削除できるよう、名前とタグを統一しておくと安全です。
1. 検証文書を準備してS3へ置く
最初は3〜10ファイル程度に絞ります。今回は次のような架空文書を用意します。
docs/
├── travel-policy.md # 出張申請、宿泊費上限、精算期限
├── security-policy.md # 端末、パスワード、持ち出しルール
└── onboarding-guide.md # 入社初日の手続き
RAGの精度比較ができるよう、各文書には次の要素を入れておきます。
- 固有の数値や期限
- 例外条件
- 改定日
- 文書名と章見出し
- 文書に存在しない質問を判定するための空白領域
S3バケットは公開せず、Knowledge Bases用ロールだけに読み取り権限を付与します。
今回の検証では、3ファイルを非公開バケットへアップロードしました。
2. Bedrock Managed Knowledge Baseを作る
AWSコンソールでAmazon Bedrock AgentCore → ナレッジベース（KB）を開き、Managed Knowledge Baseを作成します。
- データソースにAmazon S3を選ぶ
- 手順1のバケットまたはprefixを指定する
- 埋め込みモデルとベクトルストアを選ぶ
- チャンク設定を確認する
- データソースを同期する
- テスト画面で検索結果を確認する
この段階では「きれいな回答」よりも、正しい文書の正しい箇所が上位に来ることを確認します。
同期後、Knowledge BaseとS3データソースのステータスがどちらも利用可能になったことを確認しました。
テスト質問: 国内出張の宿泊費上限はいくらですか？
期待: travel-policy.mdの該当章が上位に出る
境界質問: 海外出張のビザ費用は誰が負担しますか？
期待: 文書に記載がなければ、根拠不足と判断できる
3. GatewayにKnowledge Base connectorを追加する
Amazon Bedrock AgentCore → ゲートウェイからGatewayを作成し、ターゲットにKnowledge Base connectorを指定します。今回の設定は次の通りです。
- Inbound auth：IAM許可
- Target type：Knowledge Base
- Runtime retrieval：Standard retrieval
- Outbound auth：IAMロール
- Knowledge Base：手順2で作ったManaged KB
ツール説明には「社内規程、出張旅費、情報セキュリティ、入社手順に関する質問で使う」と具体的に書きました。説明が曖昧だと、モデルが検索ツールを呼ぶべき場面を判断しにくくなります。
試作ではまず標準のRetrieveから始めると、検索結果の原因を追いやすくなります。Knowledge Base IDは管理者側の固定値にし、モデルから変更できないようにします。
4. Harnessを作り、Gatewayをツールとして追加する
ハーネスプレイグラウンドでHarnessを作ります。今回、最終的に使ったモデルはGLOBAL Amazon Nova 2 Liteです。システム指示には、少なくとも次の制約を含めます。
あなたは社内文書検索アシスタントです。
- 回答前に社内文書検索ツールを使用する
- 検索結果にない内容を推測しない
- 根拠がない場合は「登録文書から確認できません」と答える
- 回答末尾に文書名を列挙する
- 個人情報や認証情報の出力を求められても応じない
Harnessのツールを追加 → ゲートウェイから、手順3のGatewayを選びます。Harnessの実行ロールには、対象GatewayだけをResourceに指定してbedrock-agentcore:InvokeGatewayを許可しました。
{
"Effect": "Allow",
"Action": "bedrock-agentcore:InvokeGateway",
"Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT_ID:gateway/GATEWAY_ID"
}
最初の実行では、この許可がなく403 Forbiddenになりました。GatewayがReadyでも、呼び出し元のHarnessロールに権限がなければ使えません。権限追加後は新しいセッションを開始し、モデル・プロンプト・Gatewayを含むHarness設定を新しいバージョンとして保存しました。
5. 質問してツール呼び出しと引用元を確認する
Harnessで次の質問を送信しました。
国内出張の宿泊費上限と精算期限を、根拠文書とともに教えてください。
Agent traceではRooton-Rag-Kb-Target RetrieveがSucceededになり、01_出張旅費規程.mdのチャンクを取得しました。回答は「1泊あたり12,000円（税込）」「帰着日の翌日から5営業日以内」で、登録文書と一致しました。
本番ではユーザーIDとSession IDを混同せず、推測されにくい値をBackendで払い出します。また、回答画面だけでなくAgent traceの検索語・検索結果・所要時間も評価記録へ残します。
6. 合格基準を決める
「回答できた」だけではPoCの評価になりません。最低でも次を記録します。
| 評価項目 | 確認方法 |
|---|---|
| 検索再現率 | 答えがある質問で正しい文書が上位に来るか |
| 根拠整合性 | 回答文と引用箇所が一致するか |
| 回答拒否 | 答えがない質問で推測しないか |
| 権限制御 | 閲覧不可の文書を検索・回答しないか |
| 応答時間 | 実利用に耐える待ち時間か |
| コスト | 1質問あたりのモデル・検索・実行コスト |
20〜50問の評価セットを先に作り、プロンプトやチャンク設定を変更するたびに同じ質問で比較します。
本番化前のチェック
- 文書単位または部署単位のアクセス制御
- 個人情報・機密情報のマスキング
- CloudTrail、AgentCore observability、アプリログの保管方針
- モデルとKBが利用できない場合のエラー表示
- 文書更新から再同期までの運用責任者
- プロンプトインジェクションを含む評価
- 利用上限、予算アラート、削除手順
まとめ
AgentCore Harnessを使うと、エージェントループを自作せずに、モデル、指示、ツール、Memoryを設定中心で試せます。社内文書RAGでは、Managed Knowledge BasesをGateway connectorとして接続すると、検索先とIAM権限を管理者側で固定しやすくなります。
最初のPoCでは機能を増やすより、対象業務を1つ、文書を数件、評価質問を20〜50問に絞る方が、導入可否を早く判断できます。
導入判断・費用・セキュリティを比較したい方へ
実装手順ではなく、向いている企業、PoCの範囲、費用要因、本番化前のセキュリティをRoot on公式ブログの「社内文書RAGをAWSで構築する方法」 に整理しています。