Amazon Bedrock AgentCore、Managed Knowledge Base・最適化・harness 一般提供をまとめて発表

AWS は 2026年6月17日、Amazon Bedrock AgentCoreの新機能群を発表しました。組織内データ、Web、paid ナレッジへエージェントを接続する機能、production tracesを使った改善ループ、ポリシー/ガードレール連携、マネージド harnessの一般提供がまとめて案内されています。

要点

• Bedrock マネージド ナレッジ ベース がAgentCoreで利用でき、SharePoint、Google Drive、Confluence、S3、社内ウィキなどの非構造データをエージェントへ接続しやすくなります。
• Web Search on AgentCoreにより、公開Webの最新情報をAWS境界内で扱う導線が示されました。
• AgentCore 支払いとAWS WAF AI traffic monetizationにより、有料コンテンツや有料APIへエージェントがアクセスする仕組みも説明されています。
• AgentCoreの失敗 / intent / trajectory insightsはプレビュー、recommendationsとA/B testingは一般提供として案内されています。
• Bedrock ガードレール 連携とAgentCore harnessは一般提供として示され、harnessはモデル非依存のマネージド orchestration layerとして位置づけられています。

今回のブログ記事で語られていること

この発表は、AgentCoreを「エージェントを動かす場所」から、知識接続、改善、統制、実行基盤まで含むプラットフォームへ広げるものです。AWSは、エージェントがうまく動かない理由を、モデルの能力不足だけではなく、必要な知識へ届かないこと、本番で何が失敗しているか分からないこと、強い権限を持つエージェントをどう制御するかにあると説明しています。今回の更新群は、それぞれの穴を埋める方向です。

知識接続では、3つのレイヤーが示されています。組織内知識にはBedrock マネージド ナレッジ ベース、外部の最新情報にはWeb Search、そして有料データや有料サービスにはAgentCore 支払いとAWS WAF AI traffic monetizationが対応します。特にマネージド ナレッジ ベースは、SharePoint、Google Drive、Confluence、S3、社内ウィキなどに散らばる非構造データを、エージェントが使える形にするための機能です。AWSは、vector store、埋め込み、re-ranking、レート制限などの運用を管理し、エージェント型 retrieverが複数の知識ベースをまたいで検索計画、結果評価、再ランキングを行うと説明しています。

Web Searchは別記事でも扱った通り、公開Webの変化する情報をAgentCoreから扱うための機能です。このAgentCore全体発表では、Web SearchがAmazonの検索インフラとナレッジ グラフを使い、エージェント型 検索に最適化された抜粋を返すものとして位置づけられています。内部文書だけでは答えられない規制変更、市場情報、競合発表、公開仕様の確認などで、マネージド ナレッジ ベースと組み合わせる意義があります。

改善ループも重要です。AgentCoreのinsightsは、失敗、intent、trajectoryを本番トレースから見つける機能として説明されています。エージェントの失敗は、例外やエラーだけで表れないことがあります。たとえば、注文変更を実行していないのに完了したように返す、API失敗時に在庫を作り話で補う、承認ステップを飛ばす、といった問題はダッシュボード上の成功率だけでは見えません。失敗 insightsはこうしたパターンを検出し、intent insightsはユーザーが何をしようとしていたかをまとめ、trajectory insightsはエージェントの経路をグループ化します。recommendationsとA/B testingは一般提供として、プロンプトやツール descriptionの改善提案、バッチ 評価、本番トラフィックでの比較検証につなげるものです。

統制面では、AgentCore ポリシーにBedrock ガードレール 連携が一般提供で入ります。発表では、プロンプト injection、harmful content、sensitive data exposureをゲートウェイ layerで評価し、エージェントの文脈外で制御することが強調されています。これは、エージェント自身が見ているコンテキスト内の指示だけで安全性を保つのではなく、ゲートウェイで決定的な許可/deny判断を行う設計です。今後はCheck Point、Zscaler、Rubrik、Netskope、SentinelOneなどの検出シグナルも同じポリシーへ入れられる予定とされています。

最後に、AgentCore harnessが一般提供になりました。harnessは、orchestration loop、tools実行、コンテキストウィンドウ管理、turnをまたぐ状態、失敗 recovery、セッション isolationなどを担うマネージド layerとして説明されています。設定でモデル、ツール、skills、手順を定義し、必要に応じてコードへエクスポートできるとされています。重要なのは、harnessが特定モデルに閉じず、モデルを選び替えられる基盤として打ち出されている点です。

今回のブログ記事が関係する人

AgentCore Knowledge を使うエージェント開発者、検索基盤担当、評価パイプラインを持つチームに関係します。検索品質を勘ではなくデータで改善したい場合、評価 harness と最適化の流れを確認する価値があります。

実務で確認したいポイント

• 社内文書はマネージド ナレッジ ベース、公開WebはWeb Search、有料データは支払い/WAF monetizationというように、情報源ごとの境界を設計する。
• insights、recommendations、A/B testingを使う場合、トレースに含めるデータ、匿名化、保存期間、評価データセットを決める。
• ガードレール 連携をゲートウェイ層で使うとき、検出スコアとポリシー enforcementのしきい値を明確にする。
• マネージド harnessを使う場合、モデル非依存でどこまで動かすか、custom orchestrationへエクスポートする基準を決める。
• 一般提供とプレビューが混在しているため、本番導入対象と検証対象を分ける。

結局、今回のブログ記事をどう読むべきか

今回のAgentCore発表は、エージェントの能力を「モデル選び」だけで語らない方向へ進めるものです。知識へ届くこと、失敗を見つけて直すこと、ゲートウェイで制御すること、harnessで実行基盤を標準化することがまとめて提示されています。AgentCoreを検討するチームは、個々の機能名より、自社のエージェント運用でどの層が欠けているかを点検する材料として読むと価値があります。