【ハンズオン】Amazon Bedrock AgentCore Harness × Managed Knowledge Basesで作るマネージドRAGエージェント
目次
- はじめに
- 今回利用するAWSサービス
- 【アーキテクチャ解説】本記事で紹介するマネージドRAGエージェントアーキテクチャについて
- 【ハンズオン】HarnessとManaged KBでRAGエージェントを構築してみる
- 【考察】マネージドとセルフマネージド、どちらを選ぶべきか？
- 【料金】マネージドRAGエージェントのコストについて
- まとめ
1. はじめに
こんにちは！ベンジャミンの松延(まつのぶ)です！
2026年6月17日に開催されたAWS New York Summitにて、Amazon Bedrock AgentCore Harness（以下、Harness）とAmazon Bedrock Managed Knowledge Bases（以下、Managed KB）が一般提供(GA)されました。
AgentCore登場以前、エージェントの実行基盤は、LambdaやECSといったコンピュート、認証、ツール管理などを自分たちで組み合わせて構築する必要がありました。
その後、Amazon Bedrock AgentCoreの登場で実行基盤（AgentCore Runtime）はマネージドで利用できるようになりましたが、それでもStrands Agentsなどのフレームワークでオーケストレーションコードを実装し、デプロイする作業は残っていました。
一方、Harnessではエージェント実行基盤をフルマネージドで利用できるため、インフラ運用の負荷を抑えつつ、RAG（Retrieval-Augmented Generation：検索拡張生成）エージェントを構築できるようになりました。
個人的に熱いアップデートだなと感じています。
今回は、上記AWSサービスを活用したマネージドなRAGエージェントのアーキテクチャと、マネージド/セルフマネージドの使い分けについてシェアしていきたいと思います。
対象読者とこの記事でわかること
本記事は、次のような方を対象としています。
- Amazon BedrockでRAGエージェントを、できるだけ手間をかけずに構築したい方
- HarnessやManaged KBといった新しいマネージドサービスの概要をつかみたい方
- マネージドとセルフマネージドのどちらを選ぶべきか、判断材料がほしいインフラエンジニアやアプリケーション開発者の方
そして、この記事を読み終えると、次のことがわかります。
- Harness・AgentCore Gateway・Managed KBが、それぞれRAGエージェントの中でどんな役割を担うのか
- これらを使った、マネージドサービスを組み合わせたRAG基盤の構築手順（ハンズオン）
- マネージドとセルフマネージドの使い分けの考え方と、気になる料金・注意点
2. 今回利用するAWSサービス
1. Amazon Bedrock AgentCore Harnessとは
Harnessは、エージェントの実行環境を「設定」を中心に定義できるマネージドサービスです。
モデル・ツール・システムプロンプトなどを宣言的に定義すると、実行環境や認証、ネットワーク、オブザーバビリティなどの基盤はAgentCoreがマネージドで提供します。
インフラエンジニアの視点でうれしいのは、モデルの切り替えやシステムプロンプトの調整など、Harnessで管理する項目であればコードの書き換えではなく設定変更で対応できる点です。
主なAPIとしてCreateHarnessとInvokeHarnessが用意されており、コンソールからも簡単に作成・実行できます。
また、各セッションはステートフルかつセッションごとに隔離されたmicroVM上で動くため、エージェント専用のファイルシステムやシェルを持ち、短期・長期のメモリやファイルをセッションをまたいで保持できるのも特徴です。
公式ドキュメント：AgentCore harness – Amazon Bedrock AgentCore
2. Amazon Bedrock AgentCore Gatewayとは
Amazon Bedrock AgentCore Gateway（以下、AgentCore Gateway）は、エージェントとツール・外部サービスを仲介するレイヤーとして機能し、それらへの接続を一元化してくれる、フルマネージドのAIゲートウェイです。
既存のAPIやLambda関数、各種サービスをMCP（Model Context Protocol）対応のツールへ変換し、エージェントから統一的に呼び出せるようになります。
今回のRAGエージェントの文脈で特に便利なのが、後述するManaged KBを組み込みターゲットとして直接指定できる点です。
従来はナレッジベースとつなぐためにLambda関数や独自の連携コードを書く必要がありましたが、Managed KBを使えばそうしたコードを書くケースを減らせ、ナレッジベースIDを指定し、AgentCore Gatewayのサービスロールに検索権限（bedrock:Retrieve）を付与するだけで接続できます。
認証（inbound / outbound）やツールのセマンティック検索といった機能も備えており、多数のツールを安全かつ疎結合に扱えるのも強みです。
公式ドキュメント：Amazon Bedrock AgentCore Gateway
3. Amazon Bedrock Managed Knowledge Basesとは
Managed KBは、RAGに必要な仕組みをフルマネージドで提供してくれるナレッジベースです。
ベクトルデータベース（検索用インデックス）やデータ取り込みパイプライン、検索インフラを自前で管理することなく、社内データに根ざしたエージェントを構築できます。
データの取り込み、インデックス管理、検索までをサービス側が担います。
データソースはAmazon S3のほか、SharePoint・Confluence・Google Drive・OneDrive・Web Crawlerといったコネクタに対応しており、スケジュールまたはオンデマンドでデータを同期できます。
検索面ではハイブリッド検索やドキュメントのリランキングに加え、複雑な問い合わせに対して検索計画を立て、必要に応じて複数回の検索を行うAgentic Retrievalにも対応しています。
インフラ管理から解放され、データ取り込みから検索までをマネージドサービスで一貫して利用できる点が、従来のセルフマネージドなRAG基盤との大きな違いです。
公式ドキュメント：Amazon Bedrock Managed Knowledge Bases
【補足】Managed KBにおける検索を支えるベクトルストアの実態
Managed KBにおける検索を支えるベクトルストアの実態（OpenSearchなのか等）は、公式には公開されていません。
実機で確認したところ、コンソールの詳細画面には Knowledge base type: Managed vector store と表示されるのみで、OpenSearchコレクションやAuroraクラスターのようなリソースがAWSアカウント上に作成されることもありませんでした。Managed KBでは、ユーザー側がベクトルストア（OpenSearch Serverlessなど）の選定や運用を意識せずにナレッジベースを構成できます。
3. 【アーキテクチャ解説】本記事で紹介するマネージドRAGエージェントアーキテクチャについて
本記事で紹介するマネージドなRAGエージェントアーキテクチャは、下記のように実現できます。
このアーキテクチャの最大の特徴は、データの保管から検索（RAG）、思考・回答（エージェント）に至るまで、全レイヤーがサーバーレスかつマネージドで完結している点です。
- HarnessがAIエージェントの実行環境としてユーザーからの入力を受け付けます。
- AIエージェントが「社内データが必要だ」と判断すると、MCP（Model Context Protocol）を介してAgentCore Gatewayにアクセスします。
- AgentCore Gatewayは、設定されたターゲット情報を基に裏側でManaged KBにリクエストをルーティングします。
- Managed KBが、事前にS3から同期しておいたインデックスに対して検索（単発の
Retrieve、または多段階のAgenticRetrieveStreamによる自律検索）を実行します。 - Managed KBは検索結果（
AgenticRetrieveStreamの場合は引用付きの回答）を、AgentCore Gateway経由でAIエージェントに返します。 - AIエージェントは検索結果をもとに回答を生成し、ユーザーに返却します。
4. 【ハンズオン】HarnessとManaged KBでRAGエージェントを構築してみる
それでは、実際にマネージドなRAGエージェントを構築してみましょう！
今回は「S3に置いた社内ドキュメントを検索して、質問に答えてくれるエージェント」をゴールに、なるべくAWS CLIとAgentCore CLIを使ってコマンドで構築していきます。
全体の流れは次のとおりです。
- 検証用のドキュメントをS3バケットに準備する（データの保管庫づくり）
- Managed KBを作成し、S3のドキュメントを取り込む（検索の基盤づくり）
- AgentCore Gatewayに、作成したManaged KBをターゲットとして追加する（MCPツール化）
- Harnessからエージェントを起動し、AgentCore Gateway経由でManaged KBを検索させる（エージェント起動）
前提条件
ハンズオンを実施するにあたっての前提条件は下記になります。なお、Mac OSにて検証しているため、Windows OSを使用されている方は適宜コマンドを読み替えてください。
- AWSアカウント
- 本ハンズオンでは、東京リージョン(ap-northeast-1)を使用します。
- AWS CLI
- バージョン2以上を推奨します。インストール方法は公式ドキュメントを参照してください。あわせて、事前にAWS認証情報を設定しておきます。
- AgentCore CLI（Harnessの操作に使用）
- インストール方法は公式ドキュメントを参照してください。
- 検索対象のドキュメント
- Managed KBに取り込むサンプルドキュメントを用意します。（例：社内FAQのテキストやPDFなど）
ステップ1：検証用ドキュメントとS3バケットの準備
まずは、Managed KBの検索対象となるサンプルドキュメントを用意し、S3バケットにアップロードします。
作業用ディレクトリを作成します。
mkdir hands-on-managed-rag検証用のサンプルドキュメントを作成します。今回は社内FAQを模したシンプルなテキストファイルとします。
本ハンズオンで使用するドキュメントは、あくまで動作確認用のサンプルです。検証では実際の業務データや機密情報は使用せず、検証用に用意したダミーのドキュメントをご利用ください。
cat <<'EOF' > hands-on-managed-rag/sample-faq.txt
Q. 経費精算の締め日はいつですか？
A. 毎月末締め、翌月10営業日以内に申請してください。
Q. 有給休暇は何日前までに申請が必要ですか？
A. 原則3営業日前までに申請してください。
Q. リモートワークは可能ですか？
A. 上長の承認があれば週3日までリモートワークが可能です。申請は勤怠システムから行ってください。
Q. 交通費の上限はありますか？
A. 通勤交通費は月5万円までを上限として支給します。超過分は自己負担となります。
Q. 健康診断はいつ受けられますか？
A. 毎年9月に定期健康診断を実施しています。対象者には8月中に案内メールが届きます。
EOFAWS CLIを使用して、東京リージョンにS3バケットを作成します。S3バケット名はグローバルで一意になるようにしてください。
# 公式ドキュメント：https://docs.aws.amazon.com/cli/latest/reference/s3api/create-bucket.html
aws s3api create-bucket \
--bucket [S3バケット名] \
--region ap-northeast-1 \
--create-bucket-configuration LocationConstraint=ap-northeast-1以下のような出力結果が表示されればS3バケットが正常に作成されています。
{
"Location": "http://[S3バケット名].s3.amazonaws.com/",
"BucketArn": "arn:aws:s3:::[S3バケット名]"
}サンプルドキュメントをS3バケットにアップロードします。
# 公式ドキュメント：https://docs.aws.amazon.com/cli/latest/reference/s3/cp.html
aws s3 cp hands-on-managed-rag/sample-faq.txt s3://[S3バケット名]/正常にアップロードできているか確認します。（ステップ2のデータソース指定でこのバケットを使用します）
# 公式ドキュメント：https://docs.aws.amazon.com/cli/latest/reference/s3/ls.html
aws s3 ls s3://[S3バケット名]/以下のようにファイルが表示されればアップロード成功です。
2026-07-07 14:53:16 765 sample-faq.txtステップ2：Managed KBの作成（S3データソース指定）
続いて、検索の基盤となるManaged KBを作成し、ステップ1のドキュメントを取り込みます。
Managed KBは、ベクトルストアや埋め込みモデルをAWSが自動で選定・管理してくれるため、embeddingModelTypeをMANAGEDにするだけで作成できます。
その前に、Managed KBがS3データソースにアクセスするためのIAMロールを作成します。
Amazon Bedrockがこのロールを引き受けられるよう、信頼ポリシーのファイルを作成します。
[アカウントID]は使用されているAWSアカウントID（12桁）に置き換えてください。
cat <<'EOF' > hands-on-managed-rag/kb-trust-policy.json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "bedrock.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": { "aws:SourceAccount": "[アカウントID]" },
"ArnLike": { "aws:SourceArn": "arn:aws:bedrock:ap-northeast-1:[アカウントID]:knowledge-base/*" }
}
}
]
}
EOF信頼ポリシーを指定して、IAMロールを作成します。
# 公式ドキュメント：https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html
aws iam create-role \
--role-name hands-on-managed-kb-role \
--assume-role-policy-document file://hands-on-managed-rag/kb-trust-policy.jsonIAMロールを作成すると、下記のような結果になります。
{
"Role": {
"Path": "/",
"RoleName": "hands-on-managed-kb-role",
"RoleId": "XXXXXXXXXXXXXXXXXXXXX",
"Arn": "arn:aws:iam::123456789012:role/hands-on-managed-kb-role",
"CreateDate": "2026-07-07T12:00:10+00:00",
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "bedrock.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:bedrock:ap-northeast-1:123456789012:knowledge-base/*"
}
}
}
]
}
}
}次に、S3バケットの読み取り権限をロールに付与します。
[S3バケット名]はステップ1で作成したバケット名に置き換えてください。
cat <<'EOF' > hands-on-managed-rag/kb-s3-policy.json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": [
"arn:aws:s3:::[S3バケット名]",
"arn:aws:s3:::[S3バケット名]/*"
]
}
]
}
EOF作成したポリシーファイルを指定して、IAMロールに権限を付与します。
# 公式ドキュメント：https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html
aws iam put-role-policy \
--role-name hands-on-managed-kb-role \
--policy-name hands-on-managed-kb-s3-access-policy \
--policy-document file://hands-on-managed-rag/kb-s3-policy.json下記コマンドを実行することで、IAMロールにIAMポリシーが割り当てられたかを確認することができます。
# 公式ドキュメント：https://docs.aws.amazon.com/cli/latest/reference/iam/get-role-policy.html
aws iam get-role-policy \
--role-name hands-on-managed-kb-role \
--policy-name hands-on-managed-kb-s3-access-policy 下記のような結果になっていることを確認します。
{
"RoleName": "hands-on-managed-kb-role",
"PolicyName": "hands-on-managed-kb-s3-access-policy",
"PolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::[S3バケット名]",
"arn:aws:s3:::[S3バケット名]/*"
]
}
]
}
}続いて、ナレッジベースの設定ファイルを作成します。
cat <<'EOF' > hands-on-managed-rag/kb-config.json
{
"type": "MANAGED",
"managedKnowledgeBaseConfiguration": {
"embeddingModelType": "MANAGED"
}
}
EOFナレッジベースを作成します。
[アカウントID]は使用されているAWSアカウントID（12桁）に置き換えてください。
# 公式ドキュメント：https://docs.aws.amazon.com/cli/latest/reference/bedrock-agent/create-knowledge-base.html
aws bedrock-agent create-knowledge-base \
--name "hands-on-managed-kb" \
--role-arn "arn:aws:iam::[アカウントID]:role/hands-on-managed-kb-role" \
--description "Managed KB for hands-on" \
--knowledge-base-configuration file://hands-on-managed-rag/kb-config.json \
--region ap-northeast-1コマンドを実行すると、下記のような結果になります。
{
"knowledgeBase": {
"knowledgeBaseId": "YUNUEERIBE",
"name": "hands-on-managed-kb",
"knowledgeBaseArn": "arn:aws:bedrock:ap-northeast-1:123456789012:knowledge-base/YUNUEERIBE",
"description": "Managed KB for hands-on",
"roleArn": "arn:aws:iam::123456789012:role/hands-on-managed-kb-role",
"knowledgeBaseConfiguration": {
"type": "MANAGED",
"managedKnowledgeBaseConfiguration": {
"embeddingModelType": "MANAGED"
}
},
"status": "CREATING",
"createdAt": "2026-07-07T06:51:21.958721+00:00",
"updatedAt": "2026-07-07T06:51:21.958721+00:00"
}
}下記コマンドを実行することで、ナレッジベースの作成状況を確認できます。
# 公式ドキュメント：https://docs.aws.amazon.com/cli/latest/reference/bedrock-agent/get-knowledge-base.html
aws bedrock-agent get-knowledge-base \
--region ap-northeast-1 \
--knowledge-base-id [ナレッジベースID]"status": "ACTIVE"になっていれば作成完了です。
レスポンスのknowledgeBaseIdを控えておきます。（ステップ3で使用します）
{
"knowledgeBase": {
"knowledgeBaseId": "YUNUEERIBE",
"name": "hands-on-managed-kb",
"knowledgeBaseArn": "arn:aws:bedrock:ap-northeast-1:123456789012:knowledge-base/YUNUEERIBE",
"description": "Managed KB for hands-on",
"roleArn": "arn:aws:iam::123456789012:role/hands-on-managed-kb-role",
"knowledgeBaseConfiguration": {
"type": "MANAGED",
"managedKnowledgeBaseConfiguration": {
"embeddingModelType": "MANAGED"
}
},
"status": "ACTIVE",
"createdAt": "2026-07-07T06:51:21.958721+00:00",
"updatedAt": "2026-07-07T06:51:21.958721+00:00"
}
}次に、S3データソース用の設定ファイルを作成します。
[S3バケット名]はステップ1で作成したS3バケット名に置き換えてください。
[アカウントID]は使用されているAWSアカウントID（12桁）に置き換えてください。
cat <<'EOF' > hands-on-managed-rag/s3-connector.json
{
"type": "MANAGED_KNOWLEDGE_BASE_CONNECTOR",
"managedKnowledgeBaseConnectorConfiguration": {
"connectorParameters": {
"type": "S3",
"version": "1",
"connectionConfiguration": {
"bucketName": "[S3バケット名]",
"bucketOwnerAccountId": "[アカウントID]"
},
"deletionProtectionConfiguration": {
"enableDeletionProtection": false
}
}
}
}
EOFデータソースを作成し、ナレッジベースに紐づけます。--knowledge-base-idには先ほどの[ナレッジベースID]を指定します。
# 公式ドキュメント：https://docs.aws.amazon.com/cli/latest/reference/bedrock-agent/create-data-source.html
aws bedrock-agent create-data-source \
--name "s3-connector" \
--knowledge-base-id "[ナレッジベースID]" \
--data-source-configuration file://hands-on-managed-rag/s3-connector.json \
--data-deletion-policy "DELETE" \
--vector-ingestion-configuration '{"parsingConfiguration":{"parsingStrategy":"SMART_PARSING"}}' \
--region ap-northeast-1データソースが作成される("status": "AVAILABLE")と、以下のような結果が表示されます。
次のコマンドでデータソースIDを指定するため、dataSourceIdを控えておいてください。
{
"dataSource": {
"knowledgeBaseId": "YUNUEERIBE",
"dataSourceId": "SONE3YMS4A",
"name": "s3-connector",
"status": "AVAILABLE",
"dataSourceConfiguration": {
"type": "MANAGED_KNOWLEDGE_BASE_CONNECTOR",
"managedKnowledgeBaseConnectorConfiguration": {
"mediaExtractionConfiguration": {
"imageExtractionConfiguration": {
"imageExtractionStatus": "ENABLED"
}
},
"connectorParameters": "{\"deletionProtectionConfiguration\":{\"enableDeletionProtection\":false},\"type\":\"S3\",\"connectionConfiguration\":{\"bucketName\":\"hands-on-managed-rag-bucket\",\"bucketOwnerAccountId\":\"123456789012\"},\"filterConfiguration\":{\"maxFileSizeInMegaBytes\":\"500\"},\"aclEnabled\":false,\"version\":\"1\"}"
}
},
"vectorIngestionConfiguration": {
"parsingConfiguration": {
"parsingStrategy": "SMART_PARSING"
}
},
"dataDeletionPolicy": "DELETE",
"createdAt": "2026-07-07T12:07:18.341087+00:00",
"updatedAt": "2026-07-07T12:07:18.341087+00:00"
}
}最後に、S3のドキュメントを取り込む（同期する）ために、取り込みジョブを開始します。--knowledge-base-idには先ほどの[ナレッジベースID]を指定します。--data-source-idには前のコマンドで作成された[データソースID]を指定します。
# 公式ドキュメント：https://docs.aws.amazon.com/cli/latest/reference/bedrock-agent/start-ingestion-job.html
aws bedrock-agent start-ingestion-job \
--knowledge-base-id "[ナレッジベースID]" \
--data-source-id "[データソースID]" \
--region ap-northeast-1取り込みジョブが開始すると下記のような結果を取得します。
{
"ingestionJob": {
"knowledgeBaseId": "YUNUEERIBE",
"dataSourceId": "SONE3YMS4A",
"ingestionJobId": "GFQRPCFPTB",
"status": "STARTING",
"statistics": {
"numberOfDocumentsScanned": 0,
"numberOfMetadataDocumentsScanned": 0,
"numberOfNewDocumentsIndexed": 0,
"numberOfModifiedDocumentsIndexed": 0,
"numberOfMetadataDocumentsModified": 0,
"numberOfDocumentsDeleted": 0,
"numberOfDocumentsFailed": 0,
"numberOfDocumentsSkipped": 0
},
"startedAt": "2026-07-07T12:13:20.387261+00:00",
"updatedAt": "2026-07-07T12:13:20.387261+00:00"
}
}取り込みジョブの状況を確認するには、下記コマンドを実行します。
# 公式ドキュメント：https://docs.aws.amazon.com/cli/latest/reference/bedrock-agent/get-ingestion-job.html
aws bedrock-agent get-ingestion-job \
--knowledge-base-id "[ナレッジベースID]" \
--data-source-id "[データソースID]" \
--ingestion-job-id "[インジェストジョブID]" \
--region ap-northeast-1下記のように"status": "COMPLETE"になっていれば、取り込みジョブは完了です。
{
"ingestionJob": {
"knowledgeBaseId": "YUNUEERIBE",
"dataSourceId": "SONE3YMS4A",
"ingestionJobId": "GFQRPCFPTB",
"status": "COMPLETE",
"statistics": {
"numberOfDocumentsScanned": 1,
"numberOfMetadataDocumentsScanned": 0,
"numberOfNewDocumentsIndexed": 1,
"numberOfModifiedDocumentsIndexed": 0,
"numberOfMetadataDocumentsModified": 0,
"numberOfDocumentsDeleted": 0,
"numberOfDocumentsFailed": 0,
"numberOfDocumentsSkipped": 0
},
"startedAt": "2026-07-07T13:09:25.860891+00:00",
"updatedAt": "2026-07-07T13:11:57.802814+00:00"
}
}ステップ3：AgentCore GatewayでナレッジベースIDを指定（ターゲット追加）
次に、作成したManaged KBをAgentCore Gatewayのターゲットとして追加し、エージェントからMCPツールとして呼び出せるようにします。
Managed KBをAgentCore Gatewayのターゲット（コネクタ）として追加する際のポイントは下記のとおりです。
| 項目 | 内容 |
|---|---|
| ターゲット種別 | Managed KBコネクタ（組み込みターゲット） |
| 認証方式 | IAMベースのアウトバウンド認証（GATEWAY_IAM_ROLE） |
| 必要な権限 | AgentCore Gatewayのサービスロールに、bedrock:Retrieve（単発検索）とbedrock:GetKnowledgeBase（ターゲット検証時のManaged KB参照）をナレッジベースARNへ、bedrock:AgenticRetrieveStream（多段階検索の実行）をResource: "*" で付与 |
| 公開されるツール | Retrieve（単発検索）/ AgenticRetrieveStream（多段階のエージェント検索） |
手順は下記になります。
まず、AgentCore Gatewayが引き受けるサービスロールを作成します。
このロールは、AgentCore Gatewayが裏側でManaged KBを検索（bedrock:Retrieve）する際に使用します。
はじめに、AgentCore Gatewayがこのロールを引き受けられるよう、信頼ポリシーのファイルを作成します。
[アカウントID]は使用されているAWSアカウントID（12桁）に置き換えてください。
cat <<'EOF' > hands-on-managed-rag/gateway-trust-policy.json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "bedrock-agentcore.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": { "aws:SourceAccount": "[アカウントID]" },
"ArnLike": { "aws:SourceArn": "arn:aws:bedrock-agentcore:ap-northeast-1:[アカウントID]:gateway/*" }
}
}
]
}
EOF信頼ポリシーを指定して、AgentCore Gateway用のサービスロールを作成します。
aws iam create-role \
--role-name hands-on-managed-gateway-role \
--assume-role-policy-document file://hands-on-managed-rag/gateway-trust-policy.json作成に成功すると、レスポンスにロールのArn（arn:aws:iam::[アカウントID]:role/hands-on-managed-gateway-role）が含まれます。
このロールARNを、次のcreate-gatewayの--role-arnで使用するため控えておきます。
{
"Role": {
"Path": "/",
"RoleName": "hands-on-managed-gateway-role",
"RoleId": "XXXXXXXXXXXXXXXXXXXXX",
"Arn": "arn:aws:iam::123456789012:role/hands-on-managed-gateway-role",
"CreateDate": "2026-07-07T13:31:34+00:00",
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "bedrock-agentcore.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:bedrock-agentcore:ap-northeast-1:123456789012:gateway/*"
}
}
}
]
}
}
}次に、このサービスロールに、次の3つのアクションを付与します。
それぞれ役割とリソースの指定方法が異なる点に注意してください。
bedrock:Retrieve- 単発検索（Retrieveツール）の実行に使用します。対象のナレッジベースARNにスコープできます。
bedrock:GetKnowledgeBase- ターゲット追加時に、AgentCore Gatewayが「指定したManaged KBにアクセスできるか」を検証する際に使用します。
- これがないとターゲット作成が権限エラーで失敗します。
- こちらもナレッジベースARNにスコープできます。
bedrock:AgenticRetrieveStream- 多段階のエージェント検索（AgenticRetrieveStreamツール）の実行に使用します。
- 今回はこのツールを公開するため、実行時にこの権限がないとエージェントからのManaged KB検索が403エラーになります。
- なお、このアクションはリソースレベルの絞り込みに対応していないため、Resourceは
"*"を指定する必要があります（ナレッジベースARNに限定すると、権限があってもマッチせず拒否されます）。
[ナレッジベースID]はステップ2で控えたナレッジベースIDに置き換えてください。
[アカウントID]は使用されているAWSアカウントID（12桁）に置き換えてください。
cat <<'EOF' > hands-on-managed-rag/gateway-retrieve-policy.json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"bedrock:Retrieve",
"bedrock:GetKnowledgeBase"
],
"Resource": "arn:aws:bedrock:ap-northeast-1:[アカウントID]:knowledge-base/[ナレッジベースID]"
},
{
"Effect": "Allow",
"Action": "bedrock:AgenticRetrieveStream",
"Resource": "*"
}
]
}
EOFAgentCore Gatewayのサービスロールを作成します。
aws iam put-role-policy \
--role-name hands-on-managed-gateway-role \
--policy-name hands-on-managed-gateway-retrieve-policy \
--policy-document file://hands-on-managed-rag/gateway-retrieve-policy.json
下記コマンドを実行することで、IAMロールにIAMポリシーが割り当てられたかを確認することができます。
aws iam get-role-policy \
--role-name hands-on-managed-gateway-role \
--policy-name hands-on-managed-gateway-retrieve-policy 下記のような結果になっていることを確認します。
{
"RoleName": "hands-on-managed-gateway-role",
"PolicyName": "hands-on-managed-gateway-retrieve-policy",
"PolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"bedrock:Retrieve",
"bedrock:GetKnowledgeBase"
],
"Resource": "arn:aws:bedrock:ap-northeast-1:123456789012:knowledge-base/YUNUEERIBE"
},
{
"Effect": "Allow",
"Action": "bedrock:AgenticRetrieveStream",
"Resource": "*"
}
]
}
}続いて、AgentCore Gatewayを作成します（既存のAgentCore Gatewayを使う場合はこの手順はスキップします）。
今回は、インバウンド認証をIAMベース（AWS_IAM）、プロトコルをMCPとして作成します。--role-arnには、先ほど作成したAgentCore Gateway用サービスロールのARNを指定します。
[アカウントID]は使用されているAWSアカウントID（12桁）に置き換えてください。
# 公式ドキュメント：https://docs.aws.amazon.com/cli/latest/reference/bedrock-agentcore-control/create-gateway.html
aws bedrock-agentcore-control create-gateway \
--name "hands-on-managed-rag-gateway" \
--role-arn "arn:aws:iam::[アカウントID]:role/hands-on-managed-gateway-role" \
--protocol-type "MCP" \
--authorizer-type "AWS_IAM" \
--region ap-northeast-1下記コマンドを実行することで、AgentCore Gatewayの作成状況を確認できます。
# 公式ドキュメント：https://docs.aws.amazon.com/cli/latest/reference/bedrock-agentcore-control/get-gateway.html
aws bedrock-agentcore-control get-gateway \
--gateway-identifier "[GatewayのID]" \
--region ap-northeast-1作成に成功("status": "READY")すると、レスポンスにgatewayId・gatewayArn・gatewayUrlが含まれます。gatewayIdとgatewayArnを控えておきます（gatewayArnはステップ4でツールとして参照する際に使用します）。
{
"gatewayArn": "arn:aws:bedrock-agentcore:ap-northeast-1:123456789012:gateway/hands-on-managed-rag-gateway-xxxxxxxxxx",
"gatewayId": "hands-on-managed-rag-gateway-xxxxxxxxxx",
"gatewayUrl": "https://hands-on-managed-rag-gateway-xxxxxxxxxx.gateway.bedrock-agentcore.ap-northeast-1.amazonaws.com/mcp",
"createdAt": "2026-07-07T13:35:41.705549+00:00",
"updatedAt": "2026-07-07T13:35:41.705559+00:00",
"status": "READY",
"name": "hands-on-managed-rag-gateway",
"roleArn": "arn:aws:iam::123456789012:role/hands-on-managed-gateway-role",
"protocolType": "MCP",
"authorizerType": "AWS_IAM",
"workloadIdentityDetails": {}
}続いて、作成したAgentCore GatewayにManaged KBをコネクタターゲットとして追加します。connectorIdにbedrock-knowledge-basesを指定し、configurationsのretrieversにステップ2で控えたナレッジベースIDを設定します。
# 公式ドキュメント：https://docs.aws.amazon.com/cli/latest/reference/bedrock-agentcore-control/create-gateway-target.html
aws bedrock-agentcore-control create-gateway-target \
--gateway-identifier "[GatewayのID]" \
--name "managed-kb" \
--target-configuration '{
"mcp": {
"connector": {
"source": { "connectorId": "bedrock-knowledge-bases" },
"configurations": [
{
"name": "AgenticRetrieveStream",
"parameterValues": {
"retrievers": [
{
"configuration": {
"knowledgeBase": {
"knowledgeBaseId": "[ナレッジベースID]"
}
}
}
],
"agenticRetrieveConfiguration": {
"foundationModelType": "MANAGED"
}
}
}
]
}
}
}' \
--credential-provider-configurations '[{"credentialProviderType": "GATEWAY_IAM_ROLE"}]' \
--region ap-northeast-1下記コマンドを実行するとターゲットの作成状況を確認できます。
# 公式ドキュメント：https://docs.aws.amazon.com/cli/latest/reference/bedrock-agentcore-control/get-gateway-target.html
aws bedrock-agentcore-control get-gateway-target \
--gateway-identifier "[GatewayのID]" \
--target-id "[TargetのID]" \
--region ap-northeast-1ターゲットが作成("status": "READY")されると、AgenticRetrieveStreamがMCPツールとして公開されます。
{
"gatewayArn": "arn:aws:bedrock-agentcore:ap-northeast-1:123456789012:gateway/hands-on-managed-rag-gateway-xxxxxxxxxx",
"targetId": "NG1UQGWT4B",
"createdAt": "2026-07-07T07:12:16.935714+00:00",
"updatedAt": "2026-07-07T07:12:19.129056+00:00",
"status": "READY",
"name": "managed-kb",
"targetConfiguration": {
"mcp": {
"connector": {
"source": {
"connectorId": "bedrock-knowledge-bases"
},
"configurations": [
{
"name": "AgenticRetrieveStream",
"parameterValues": {
"agenticRetrieveConfiguration": {
"foundationModelType": "MANAGED"
},
"retrievers": [
{
"configuration": {
"knowledgeBase": {
"knowledgeBaseId": "YUNUEERIBE"
}
}
}
]
}
}
]
}
}
},
"credentialProviderConfigurations": [
{
"credentialProviderType": "GATEWAY_IAM_ROLE"
}
]
}ステップ4：HarnessからAgentCore Gatewayを呼び出す（エージェント起動）
最後に、Harnessでエージェントを立ち上げ、ステップ3のAgentCore Gateway（＝Managed KBのツール）を呼び出させます。ここではAgentCore CLIを使ってHarnessプロジェクトを作成します。
agentcore createはフラグを付けずに実行すると対話式ウィザードになりますが、今回は再現しやすいように、オプションを指定した非対話モードで作成します。
--project-nameなどのオプションを付けると、対話ではなくコマンドモードで実行されます。
まずは --dry-runを付けて、実際には作成せずに「何が作られるか」をプレビューします。
agentcore create \
--project-name handsOnRagAgent \
--defaults \
--model-provider Bedrock \
--model-id global.amazon.nova-2-lite-v1:0 \
--region ap-northeast-1 \
--dry-run--defaults- Harnessプロジェクトを既定設定で作成します。（Harnessが既定のプロジェクト種別です）
--model-provider Bedrock- モデルプロバイダーをAmazon Bedrockにします。
--model-id global.amazon.nova-2-lite-v1:0- 使用するモデルをAmazon Nova 2 Lite（グローバルクロスリージョン推論プロファイル）に指定します。
- 指定を省略すると、既定ではClaude Sonnet 4.6が使われますが、本記事ではAWS純正で手軽に使えるNova 2 Liteを利用します。
--project-name- 英字始まり・英数字のみ・最大23文字で指定します。
作成予定のファイル一式が表示されます（--jsonを付けるとJSONで確認できます）。
handsOnRagAgent/
├── agentcore/ # 設定・CDKプロジェクト
│ ├── agentcore.json
│ ├── aws-targets.json
│ ├── .env.local
│ └── cdk/
└── app/handsOnRagAgent/
├── harness.json # Harnessの設定（モデル・ツールなど）
└── system-prompt.md # エージェントへの指示文内容に問題がなければ、--dry-runを外して実際に作成します。
agentcore create \
--project-name handsOnRagAgent \
--defaults \
--model-provider Bedrock \
--model-id global.amazon.nova-2-lite-v1:0 \
--region ap-northeast-1[done] Create handsOnRagAgent/ project directory
[done] Prepare agentcore/ directory
[done] Initialize git repository
[done] Add harness to project
Created:
handsOnRagAgent/
agentcore/ Config and CDK project
app/handsOnRagAgent/ Harness config
Harness project created successfully!
To continue:
cd handsOnRagAgent
agentcore deploy作成が完了すると、harness.jsonにモデル設定が書き込まれます。
今回は--model-idでNova 2 Lite（モデルID：global.amazon.nova-2-lite-v1:0）を指定したので、そのモデルが設定されます。
{
"name": "handsOnRagAgent",
"model": {
"provider": "bedrock",
"modelId": "global.amazon.nova-2-lite-v1:0"
},
"tools": [],
"skills": [],
"memory": {
"mode": "disabled"
}
}続いて、作成されたプロジェクトディレクトリに移動します。以降のコマンドはこのディレクトリ内で実行します。
cd handsOnRagAgent生成された app/handsOnRagAgent/system-prompt.md（エージェントへの指示文）を編集し、「社内ドキュメントについて質問されたら、ナレッジベース検索ツールを使って回答する」といった指示を記述します。
（system-prompt.md の記述例）
あなたは社内ドキュメントに詳しいアシスタントです。
ユーザーからの質問に対しては、ナレッジベース検索ツール（Retrieve / AgenticRetrieveStream）を使って
関連する社内情報を検索し、その内容に基づいて回答してください。あわせて、エージェントが使うツールとして、ステップ3で作成したAgentCore Gatewayを追加します。
AgentCore GatewayはARNで参照でき、そこに設定されたツール（今回はRetrieveとAgenticRetrieveStream）がすべてエージェントから呼び出せるようになります。
agentcore add tool --harness handsOnRagAgent \
--type agentcore_gateway \
--name hands-on-managed-kb-gateway \
--gateway-arn [Gateway ARN]アウトバウンド認証（AgentCore Gatewayが裏側のツールを呼ぶ際の認証）は、指定を省略するとawsIamが使われます。今回はステップ3でGATEWAY_IAM_ROLEを設定しているため、この既定のままでOKです。
Harnessをデプロイします。
agentcore deploy下記のような結果になっている場合、AgentCore Harnessのデプロイが完了しています。
AgentCore Deploy
Project: handsOnRagAgent
Target: ap-northeast-1:123456789012
[done] Validate project
[done] Check dependencies
[done] Build CDK project
[done] Synthesize CloudFormation
[done] Check stack status
[done] Skip diff (new stack)
[done] Publish assets
[done] Persist deployment state
╭────────────────────────────────────────────────╮
│ ✓ Deploy to AWS Complete │
│ │
│ [████████████████████] 5/5 │
╰────────────────────────────────────────────────╯
Deployed 1 stack(s): AgentCore-handsOnRagAgent-default
Log: agentcore/.cli/logs/deploy/deploy-20260707-162058.log
Next: Run agentcore add to add an agent, or agentcore status to view deployment status
Esc back · Ctrl+C quit一通りの構築が完了したため、AWSマネジメントコンソールから動作確認してみましょう！
AWSマネジメントコンソールへアクセスし、東京リージョン（ap-northeast-1） を選択します。
AWSマネジメントコンソール上部の検索欄にて、[AgentCore]と入力して、AgentCoreコンソール画面を開きます。
左側のメニューからHarness（エージェント）の一覧を開き、先ほどデプロイしたhandsOnRagAgentを選択します。
画面右上の[ハーネスをテスト]からテスト用の実行画面（プレイグラウンド）を開きます。
プロンプト入力欄に社内FAQに関する質問を入力して実行します。今回はサンプルドキュメントに沿って、たとえば「経費精算の締め日はいつ？」と尋ねてみます。
エージェントがAgentCore Gateway経由でナレッジベース検索ツール（Retrieve / AgenticRetrieveStream）を呼び出し、S3上のドキュメントに基づいた回答（例：「経費精算の締め日は毎月末締めです。翌月10営業日以内に申請してください。」）を返すことを確認します。
エージェントトレースにも、ツール呼び出し（Managed-Kb AgenticRetrieveStream）のステップが表示されます。
サンプルドキュメントについて、その他の社内FAQに関する質問を入力して実行した結果も確認してみます。
エージェントが質問を受けると、AgentCore Gateway経由でManaged KBの検索ツールを呼び出し、S3のドキュメントに基づいた回答を返してくれます。コードを書かず、指示文とツールの設定だけでエージェントが動く、まさに「ノーコード」なRAGエージェントが完成しました！
今回はAWS純正の Nova 2 Lite（global.amazon.nova-2-lite-v1:0）を指定しています。
なお、Nova Microのような旧世代の軽量モデルもHarnessから指定はできますが、筆者環境では検証ではツール呼び出しに失敗（modelStreamErrorException：Model produced invalid sequence as part of ToolUse）したため、ツールを使うエージェント用途ではNova 2 Lite以上のモデルをおすすめします。
既定のClaude Sonnet 4.6（Anthropic）を使う場合は、初回利用時にモデルアクセスの有効化（利用用途フォームの提出）が必要になることがあります。
クリーンアップ
最後に、ハンズオンで作成したリソースは利用料金が発生する可能性があるため、クリーンアップしておきましょう！
「利用する側（Harness）」から「基盤側（Managed KB・S3）」に向かって削除していくとスムーズです。
Harnessを削除します。AgentCore CLIには単独の削除コマンドはなく、agentcore remove allで設定を空にしてから agentcore deployを実行すると、空の状態が検知されてAWS側のリソースが撤去されます。（プロジェクトディレクトリ内で実行します。ステップ4から続けて作業している場合は既にディレクトリ内にいるため、cdは不要です）
agentcore remove allを実行すると、本当に削除してよいか対話形式で確認されます。問題なければyを入力して進めてください。
cd handsOnRagAgent/
agentcore remove all
agentcore deploy削除が完了すると下記のような結果になります。
AgentCore Deploy
Project: handsOnRagAgent
Target: ap-northeast-1:123456789012
[done] Validate project
[done] Check dependencies
[done] Build CDK project
[done] Synthesize CloudFormation
[done] Check stack status
[done] Computing diff changes...
[done] Publish assets
╭────────────────────────────────────────────────╮
│ ✓ Deploy to AWS Complete │
│ │
│ [████████████████████] 6/6 │
╰────────────────────────────────────────────────╯
Log: agentcore/.cli/logs/deploy/deploy-20260707-004302.log
Next: Run agentcore add to add an agent, or agentcore status to view deployment status
Esc back · Ctrl+C quitAgentCore Gatewayのターゲットとゲートウェイ本体を削除します。
aws bedrock-agentcore-control delete-gateway-target \
--gateway-identifier "[GatewayのID]" \
--target-id "[ターゲットID]" \
--region ap-northeast-1
aws bedrock-agentcore-control delete-gateway \
--gateway-identifier "[GatewayのID]" \
--region ap-northeast-1Managed KBを削除します。
aws bedrock-agent delete-knowledge-base \
--knowledge-base-id [ナレッジベースID] \
--region ap-northeast-1S3バケットを中身ごと削除します。
aws s3 rb s3://[S3バケット名] --forceこのほか、作成したIAMロール（AgentCore Gatewayのサービスロールなど）も不要であれば削除しておきます。
5. 【考察】マネージドとセルフマネージド、どちらを選ぶべきか？
現在(2026年7月時点)のAmazon Bedrockでは、エージェントの実行環境（AgentCore）とナレッジベース（KB）の双方において、運用の手間を減らす「マネージド」と、自由度の高い「セルフマネージド」の選択肢が揃ったと考えています。
システム全体をマネージドに寄せるべきか、あるいはあえてセルフマネージドな部分を残すべきか、その判断基準をそれぞれの視点から整理してみました。
| パターン | エージェント（AgentCore） | ナレッジベース（KB） | 特徴とユースケース |
|---|---|---|---|
| A. 完全マネージド（本記事） | Harness（ノーコード・指示文のみ） | Managed KB | – 「手軽にRAGを作りたい」ケース。 – PoC、社内FAQ、一般的なRAG要件。開発の手間も待機コストも抑えたい場合。 |
| B. エージェント特化カスタム | Self-managed（Strands Agents） | Managed KB | – 「業務フローは複雑だが、検索は標準で良い」ケース。 – 「この条件のときは社内APIを叩く」といった厳密なプログラム制御をStrandsで書きつつ、DBの管理コストを抑えたい場合。 |
| C. 検索特化カスタム | Harness（ノーコード・指示文のみ） | Self-managed（Aurora(PostgreSQL) / OpenSearchなど） | – 「会話ロジックはシンプルだが、検索をしっかり作り込みたい」ケース。 – OpenSearchのカスタム辞書や検索比率などを細かく調整したいが、エージェントは指示文だけで手軽に動かしたい場合。 |
| D. 完全セルフマネージド | Self-managed（Strands Agents） | Self-managed（Aurora(PostgreSQL) / OpenSearchなど） | – 「細かな制御とチューニングをしっかり行いたい」ケース。 – 企業の基幹システムとの密な連携や、検索精度・セキュリティポリシーをきめ細かく調整したい場合。 |
本記事のハンズオンで使う組み込みKBコネクタ（bedrock-knowledge-bases）は、Managed KB専用です。
パターンC・DのようにセルフマネージドなKBをエージェントと繋ぐ場合は、パターンA・Bのようなコネクタ直結ではなく、Lambdaターゲットや独自のMCPサーバーなどの追加連携が必要になります。
なお、エージェント自体もセルフマネージドな場合（パターンD）は、AgentCore Gatewayを介さずにKBの検索API（Retrieve）を直接呼び出す構成も可能です。
また、多段階のagentic検索（AgenticRetrieveStream）はManaged KB固有の機能のため、パターンC・Dで同等の多段検索を行いたい場合は自前で実装する必要があります。
上の表はあくまで組み合わせの考え方の整理としてご覧ください。
補足：HarnessとStrandsは地続き
「Harness（マネージド）とセルフマネージド（Strandsを自分で書く構成）は別物」と身構えがちですが、実はこの2つは地続きです。
AWS公式ドキュメントによると、Harnessの実体は、AWSのオープンソースエージェントフレームワークStrands Agentsのループを、AgentCore Runtime（セッションごとに隔離されたmicroVM）の上でマネージド実行するものです。
つまり、Hanessは、「Strandsのコードを自分で書く代わりに、同じStrandsのループを設定（harness.json + system-prompt.md）で宣言している」状態と言えます。
そして、設定だけでは足りなくなったら、agentcore export harnessで等価なStrandsのPythonコードに書き出して、そのままAgentCore Runtime上で動かせます（＝セルフマネージドへの移行）。
この「まずはノーコードで動かし、必要になったらStrandsコードに“開いて”作り込む」という連続性こそ、Harnessのうれしいポイントだと感じています。
参考：AgentCore harness / AgentCore harness vs. Runtime / Export harness to code
補足：データガバナンスの観点も選択基準になる
マネージド/セルフマネージドの選択には、データガバナンスの観点も関わります。
Managed KBの場合、データソース（元データ）はS3を指定できるため、監査・管理は可能と考えられます。
一方で、インデックス（ベクトル化されたコピー）はManaged KB側のベクトルストア（AWS側管理）に置かれます。
そのため、「データのコピーを監査可能なリソースに置く」といった要件がある場合は、運用の手間とは別の軸で、セルフマネージドなKBを選ぶ理由になります。
6. 【料金】マネージドRAGエージェントのコストについて
本記事で紹介してきたマネージド構成の料金体系を整理しておきます。
結論から言うと、今回の構成はいずれも使った分だけ支払う従量課金で、事前のコミットや最低料金がありません。
各サービスの課金ポイント
| サービス | 課金の考え方 |
|---|---|
| Harness | Harness自体に追加料金はなく、裏側で使ったAgentCoreの各機能（Runtimeなど）に対して課金されます。 |
| AgentCore Runtime | エージェントが実際にCPUを使って処理している時間に対して、vCPU時間・メモリ（GB時間）ベースで課金されます。 |
| AgentCore Gateway | ツール呼び出しのAPIコール数（1,000コール単位）に応じた従量課金です。 |
| Managed KB | 「インデックスしたデータの保存量」と「検索（Retrieve）の実行回数」の2軸に応じた従量課金です。 |
待機コストがかかりにくい仕組み
このアーキテクチャのうれしいポイントは、待機している間はコンピュートの料金がかからない点です。
AgentCore Runtimeは、モデルの応答待ちや外部API待ちといったアイドル時間には課金されず、実際に処理している時間だけが対象になります。
セルフマネージドでベクトルDB（例：AuroraやOpenSearch）を常時起動しておくと、リクエストがゼロでも待機コストが発生し続けます。
マネージド構成なら、この「使っていないのに払い続けるコスト」を抑えやすいのが利点です。PoCや、アクセスが読めない立ち上げ期のワークロードと特に相性が良いと感じています。
見落としがちなコスト
一方で、「マネージド＝すべて激安」というわけではありません。以下のコストは別途かかるので、見積もり時に忘れないようにしたいところです。
- 基盤モデル（LLM）の利用料
- エージェントの思考や回答生成に使うモデルの入力・出力トークンには、通常どおり料金がかかります。
- RAGの回答生成で意外と効いてくる部分です。
- Managed KB経由の呼び出し
- Managed KBをAgentCore Gateway経由で呼び出す場合は、AgentCore Gatewayのツール呼び出し料金も加算されます。
- オブザーバビリティ
- トレースやメトリクスを有効化すると、標準のCloudWatch料金が発生します。
- AgentCore Memory
- 本記事の構成ではメモリを無効（
"mode": "disabled"）にしていますが、セッションをまたぐ記憶を有効化すると、AgentCore Memoryの料金が別途発生します。
- 本記事の構成ではメモリを無効（
- アイドル時のKBストレージ
- 「待機コストがかからない」のはコンピュートの話で、Managed KBのインデックスストレージは使っていない間も課金され続けます。
- PoC後に不要になったナレッジベースは削除しておきましょう。
- データソースのストレージ
- S3など、ナレッジベースの元データを保管しておくストレージのコストがかかります。
- データ量が増えるほど積み上がるため、意外と見落としがちなポイントです。
【概算例】小さく始めた場合の月額イメージ
「結局いくらかかるの？」がイメージしづらいと思うので、ごく小規模なPoCを例に、ざっくり試算してみます。
前提（社内FAQボットのPoC）は下記とします。
- リージョン：東京リージョン(ap-northeast-1)
- 問い合わせ数：月1,000回
- 1回あたりの入力：約3,000トークン（指示文＋検索でヒットした社内文書）
- 1回あたりの出力：約500トークン
- モデル：Amazon Nova 2 Lite（本記事で指定したモデル）
- 1回あたりAgentCore Gateway経由のツール呼び出し：1回
Nova 2 Lite（グローバルクロスリージョン推論・Standardティア・東京リージョン）の単価は、入力 $0.36 / 出力 $3.01（いずれも100万トークンあたり）です（Amazon Novaの料金ページ）。
| 項目 | 計算 | 月額（概算） |
|---|---|---|
| LLM入力トークン | 1,000回 × 3,000 ＝ 300万トークン × $0.36/100万トークン | 約$1.08 |
| LLM出力トークン | 1,000回 × 500 ＝ 50万トークン × $3.01/100万トークン | 約$1.51 |
| AgentCore Gateway（ツール呼び出し） | 1,000回 × $0.005/1,000呼び出し | $0.01未満 |
| AgentCore Runtime（処理時間） | 1回あたり数秒の処理 × 1,000回 | $1未満 |
| Managed KB（ストレージ） | 数百MB（約0.3GBと仮定） × $5.00/GB・月 | 約$1.5 |
| Managed KB（検索） | AgenticRetrieveStream 1,000回 × $4.00/1,000回（＋内部のRetrieve分） | 約$4〜5 |
| S3（データソースの保管） | 数百MB × 約$0.025/GB・月（東京リージョン） | $0.01程度 |
合計は、ざっくり月$10前後となります。
試算してみると、この規模ではLLMよりもManaged KBのagentic検索（AgenticRetrieveStream）が最大のコスト要素になります。
より高精度な回答が必要ならClaudeなどの上位モデルに切り替えられますが、Nova 2 LiteのようなAWS純正の軽量モデルを選ぶと、LLMのトークン料金自体をかなり抑えられます。
上記は2026年7月時点・東京リージョン基準の概算です。実際の料金は利用状況やモデルの選択によって変わるため、最新の単価はAmazon Bedrockの料金ページを、正確な見積もりはAWS Pricing Calculatorでご確認ください。
7. まとめ
本記事では、HarnessとManaged KBを活用したマネージドRAGエージェントについて紹介しました。
最初はマネージド構成(パターンA)でコストをかけずにサクッと立ち上げてユーザーの反応やプロンプトを検証し、将来的に「もっと業務フローを組み込みたい」「検索精度を限界までチューニングしたい」という要求が出てきた段階で、部分的にセルフマネージド構成へ移行していく(パターンB→C→D)、という流れが良いのかなと思いました。
皆さんの一助になれば幸いです！
