Amazon Bedrock Agentsとは？機能や料金、使い方を解説

Amazon Bedrock Agentsは、AWSの生成AI基盤であるAmazon Bedrock上で、マルチステップの業務処理を自動化するためのエージェント構築機能です。基盤モデルの推論だけでなく、社内データの参照、API実行、会話の継続、ガードレール適用までをまとめて扱えるため、「答えるAI」から「動くAI」へ進めたい企業に向いています。


本記事では、Amazon Bedrock Agentsの基本概念、主要機能、使い方、導入事例、Amazon Bedrock FlowsやAgentCoreとの違い、料金の考え方、導入判断で詰まりやすい論点までを、2026年4月時点のAWS公式情報ベースで整理して解説します。

Amazon Bedrock Agentsとは？

Amazon Bedrock Agentsは、Amazon Bedrock Agentsの公式ページで案内されている、基盤モデルの推論、企業データの参照、API実行をまとめて扱えるエージェント構築機能です。AWSのドキュメントでは「Agents for Amazon Bedrock」と表記されることもありますが、製品ページでは「Amazon Bedrock Agents」と整理されています。

AWS News Blogによると、Agents for Amazon Bedrockは2023年7月にプレビュー、2023年11月28日に一般提供となりました。ユーザーの自然言語リクエストを複数ステップに分解し、必要なデータ取得やAPI呼び出しを組み合わせて最終応答まで持っていくのが中核です。

単なる生成AIチャットとの違いを整理すると、次のようになります。

方式	主な役割	物足りなくなりやすい点
基盤モデル単体のチャット	質問応答や文章生成	外部システム操作や状態管理は別実装が必要
RAG中心の構成	根拠付き回答	回答後の業務アクションは別に組む必要がある
固定ワークフロー	手順どおりの処理	想定外の質問や分岐への柔軟性が弱い
Amazon Bedrock Agents	回答、検索、API実行、会話継続を統合	指示設計、権限設計、周辺AWS構成は必要

要するにAmazon Bedrock Agentsは、「社内文書を読んで答えるAI」で終わらず、「答えたうえで次の処理も進めるAI」をAWS上で作りたいときの機能です。Amazon Bedrockが土台で、その上にエージェント層を乗せるイメージで捉えると分かりやすくなります。

---

Amazon Bedrock Agentsの主要機能

Amazon Bedrock Agentsの価値は、モデルを呼び出せること自体ではなく、業務実装に必要な構成要素があらかじめ整理されている点にあります。ここでは、特に押さえるべき機能を3つに分けて見ていきます。

アクショングループとオーケストレーション

Create and configure agent manuallyでは、エージェントの実行先としてアクショングループとKnowledge Baseが中核要素とされています。アクショングループは、エージェントがどのAPIや業務処理を呼び出せるかを定義する仕組みです。

典型的には、OpenAPIスキーマとAWS Lambdaを組み合わせて、在庫確認、申請更新、注文登録、顧客情報取得のような処理を実行します。AWSの説明では、エージェントはユーザー入力をもとにタスクを分解し、必要なアクションを順に選んで実行します。

2024年4月にはReturn of Control機能が追加され、すべてをLambda任せにせず、エージェントからアプリケーション側へ処理制御を返す構成も取りやすくなりました。さらに2024年11月にはcustom orchestrationも追加され、Lambdaで独自のオーケストレーション戦略を実装できます。

つまり、標準の自動推論に乗るだけでなく、必要に応じて「制御を返す」「計画ロジックを差し替える」までできるのがAmazon Bedrock Agentsの強みです。

ナレッジベース、Guardrails、メモリ保持

Amazon Bedrock Agentsは、API実行だけでなく、回答精度と安全性を上げるための機能もまとめて扱えます。

主な役割を整理すると、次の表になります。

機能	役割	実務上の意味
Knowledge Bases	社内文書やWeb、DB由来の情報を検索して回答へ反映	回答の根拠付けやRAG構成を簡素化しやすい
Guardrails	有害内容、機密情報、不要なトピックを制御	本番運用での安全性を上げやすい
Memory	セッションをまたいだ会話要約や履歴活用	継続対話やユーザー別文脈保持に向く

メモリ機能のドキュメントでは、メモリ保持期間は1日から365日まで設定できると案内されています。また、作成手順のドキュメントでは、アイドル状態のセッションタイムアウトは既定で30分です。

このため、FAQを返すだけのエージェントよりも、「前回の申請状況を踏まえて次の案内を出す」「継続的な問い合わせで必要情報を引き継ぐ」といった業務に向きます。安全性の観点では、AIガバナンスの設計と合わせてGuardrailsや権限境界を詰めることが重要です。

マルチエージェント、コード解釈、モデル選択

2025年3月にはAmazon Bedrock multi-agent collaborationのGAが発表され、スーパーバイザーエージェントの配下で専門エージェント同士を協調させる構成が一般提供になりました。

2026年4月7日時点の対応状況のドキュメントでは、マルチエージェント用の collaborator agent に使えるモデルとして、Anthropic Claude 3 Haiku、Opus、Sonnet、Claude 3.5 Haiku、Sonnet、Sonnet V2、Amazon Nova Pro、Nova Lite、Nova Microが挙がっています。また、同じドキュメントではcustom orchestrationを使うsupervisor agentとcollaborator agentはmulti-agent collaborationの対象外です。通常のAmazon Bedrock Agents自体は、対応Region一覧で示されるとおり、Amazon Bedrockが対応するモデルを広く利用できますが、マルチエージェントでは一部条件が付く点に注意が必要です。

また、code interpretationのドキュメントでは、エージェントがセキュアな環境でコード生成と実行を行い、分析や可視化、ファイル処理に使えると案内されています。ただし同じドキュメントでは、対応Regionは現時点で米国東部、米国西部、欧州フランクフルトの3か所です。東京リージョンでAmazon Bedrock Agents自体は使えても、この機能は別途確認が必要になります。

Amazon Bedrock Agentsの使い方

Amazon Bedrock Agentsは多機能ですが、最初のPoCは意外にシンプルです。チュートリアルでも、日時を返すLambda関数を呼び出す小さなエージェントから始めています。

最小構成で始めるなら、流れは次の5段階です。

1. まず、対象業務を1つに絞り、エージェントへの自然言語指示を決めます。例としては「社内申請の状況を確認し、必要なら差し戻し理由を返す」のような単機能が向いています。
   
   
2. 次に、Agent builderでモデル、サービスロール、指示文、必要ならKMSやセッション設定を構成します。
   
   
3. 続いて、アクショングループかKnowledge Baseを追加します。業務処理が主ならアクショングループ、回答根拠が主ならKnowledge Baseを先に作ると整理しやすくなります。
   
   
4. その後、エージェントをPrepareしてテストし、問題がなければaliasを切ってデプロイします。
   
   
5. 本番アプリからはInvokeAgentを呼び出し、必要に応じてsessionIdやmemoryIdを使って会話継続やユーザー別の文脈保持を行います。

PoC段階では、最初からマルチエージェントや複数ツールを盛り込みすぎないことが重要です。1エージェント、1ユースケース、1つか2つのアクションに絞ったほうが、失敗要因を切り分けやすくなります。

【関連記事】
AIエージェント(AI agent)とは？その仕組みや作り方、活用事例を解説

AIエージェントを企業に導入する全手順｜事例・費用も解説

---

Amazon Bedrock Agentsの活用例と導入事例

Amazon Bedrock Agentsは、単なる技術デモよりも「問い合わせ対応から業務実行までをつなぐ」場面で価値が出やすい機能です。AWS公式の事例や技術ブログでも、その傾向がはっきり出ています。

AstraZenecaのマルチエージェント活用

AstraZenecaのケーススタディでは、同社がAmazon Bedrock Agentsを使って研究開発向けのDevelopment Assistantを構築し、構造化データと非構造化データの両方を自然言語で引けるようにしています。

この事例のポイントは、1つの万能エージェントではなく、用語解釈、臨床、規制、データベース操作などの役割を分けたマルチエージェント構成を採ったことです。AWSの公開内容では、従来は数時間かかっていた洞察取得を数分単位に短縮し、6か月で本番化、1,000人超への展開を進めています。

医療業界の特殊事例に見えますが、実際には「用語が難しい部門」「複数データソース」「専門エージェントへの振り分け」が必要な企業ならかなり再現性のあるパターンです。

マーケティング施策の自動化

AWS Machine Learning Blogのマーケティング事例では、Amazon Personalize、Knowledge Bases、Lambdaなどを組み合わせたマーケティングエージェントが紹介されています。

この構成では、エージェントが顧客セグメントの抽出、商品情報の取得、クリエイティブ生成を段階的に進めます。同記事では、Chunghwa Telecomが同種の構成を活用し、クリック率が24倍になったと紹介されています。

ここで重要なのは、生成AIが文章を書いただけではなく、顧客データ、商品データ、ブランド文脈をまたいで複数のツールを順番に使っている点です。Amazon Bedrock Agentsは、こうした「データ取得と生成を一体で回す」場面と相性が良いです。

Amazon Bedrock Agentsが向いている業務

ここまでの事例を踏まえると、Amazon Bedrock Agentsが特に向いているのは次のような業務です。

• 社内ナレッジ検索に加えて、申請更新や顧客照会などの実行系アクションまで返したい業務
  
  
• カスタマーサポートの自己解決導線で、FAQ回答だけでなく注文確認やステータス更新までつなげたい業務
  
  
• マーケティング、営業、運用のように、複数の社内システムやデータソースをまたいで自然言語で処理を進めたい業務

逆に、単純な検索画面や定型フローだけで足りる場合は、エージェントまで持ち込まずに別手段のほうが軽く済むこともあります。AIワークフローやAIエージェント×データ基盤の設計論と合わせて考えると判断しやすくなります。

---

Amazon Bedrock AgentsはPoCを素早く始めやすい一方で、成果が出るかどうかは「どの業務に載せるか」「どこまで実行権限を持たせるか」で大きく変わります。技術検証だけで終わらせず、業務接続と運用設計まで含めて考えることが重要です。

Amazon Bedrock Agentsと周辺サービスの違い

Amazon Bedrock Agentsは便利ですが、AWSには近い名前の周辺機能も多く、混同しやすい領域です。ここは早めに切り分けておくと、設計判断を誤りにくくなります。

サービス	主な役割	向いている場面
Amazon Bedrock	基盤モデル、Knowledge Bases、Guardrails、Agentsなどを含む土台	生成AI基盤全体をAWSで使いたいとき
Amazon Bedrock Agents	推論、検索、API実行をまとめるエージェント層	自然言語で業務処理を進めるアシスタントを作りたいとき
Amazon Bedrock Flows	ノードをつないで定義済みワークフローを組む視覚的ビルダー	分岐や前処理を明示的に組みたいとき
Amazon Bedrock AgentCore	任意フレームワークや任意モデルで作ったエージェントを本番運用する基盤	長時間実行、複数フレームワーク、運用基盤まで含めて作りたいとき

Amazon Bedrock Flowsのドキュメントでは、Flowsはプロンプト、基盤モデル、Knowledge Bases、Lambdaなどを視覚的につないで生成AIワークフローを組む機能と説明されています。さらに対応ノード一覧ではAgent nodeも案内されており、Flowsの中にAgentsを組み込む構成も可能です。つまり、FlowsとAgentsは二者択一というより併用関係になることがあります。固定的な流れや分岐を見える形で設計したいならFlows、自然言語リクエストに応じた計画実行を中心にしたいならAgents、そのAgentsをFlowsの一部として呼び出したいなら組み合わせる構成が合います。

一方、Amazon Bedrock AgentCoreのGA告知では、AgentCoreは「任意のフレームワーク、モデル、プロトコル」で作ったエージェントを安全にデプロイ・運用する基盤と説明されています。LangGraphやCrewAIのような外部フレームワークや、Bedrock外のモデルも視野に入るなら、AgentsよりAgentCoreが本命になるケースがあります。

AWS外との比較なら、Microsoft Foundry Agent Serviceのような競合もあります。既存のクラウド基盤がAWS中心で、まずはマネージドに始めたいならAmazon Bedrock Agentsは有力ですが、マルチクラウドやMicrosoft 365中心の運用なら別の選択肢も検討する価値があります。

【関連記事】
AzureとAWSの料金、サービス、性能を徹底比較【2025年最新】

Amazon Bedrock Agentsの注意点と導入判断

Amazon Bedrock Agentsは「AWSがかなり面倒を見てくれる」サービスですが、それでも設計で詰まりやすい論点があります。PoCから本番へ進む前に、最低限ここは整理しておきたいポイントです。

東京リージョンでの前提を分けて考える

対応Region一覧では、Amazon Bedrock Agentsは東京リージョンに対応しています。一方で、前述のとおりcode interpretationは別で、現時点のドキュメントでは東京が含まれていません。

つまり「Amazon Bedrock Agentsが東京で使える」ことと、「使いたい付加機能まで東京で全部そろう」ことは別問題です。日本企業でリージョン制約が重要なら、基本機能と拡張機能を分けて確認したほうが安全です。

シングルエージェントで足りるかを先に決める

マルチエージェントは魅力的ですが、何でも最初から分業化すれば良いわけではありません。AstraZenecaのように専門領域が明確で、1つのエージェントに集約すると精度や保守性が落ちるケースで初めて効果が大きくなります。

反対に、問い合わせ分類、在庫照会、申請状況確認のような単純な業務は、まずシングルエージェントで十分なことが多いです。いきなり複雑化すると、プロンプト、権限、ログ、評価軸まで全部が膨らみます。

業務実行権限の境界を曖昧にしない

Amazon Bedrock AgentsはAPIを実行できるからこそ、設計で曖昧にすると危険です。特に次の3点はPoC段階から切っておくべきです。

• 読み取り専用のアクションと更新系アクションを分ける
  
  
• Guardrailsだけに頼らず、API側でも入力検証と権限制御を行う
  
  
• 誰の代わりにどの処理を実行したのかを追えるログ設計にする

このあたりはモデル精度よりも先に詰まるポイントです。エージェント導入では、精度検証と同じくらい権限境界と運用設計が重要になります。AIエージェントを企業に導入する全手順でも、この「PoCから本番に移るときの壁」がボトルネックになりやすいと整理しています。

Amazon Bedrock Agentsの料金体系

Amazon Bedrock Agentsの料金を考えるときは、「エージェントに月額固定費がある」という理解ではなく、基盤モデル推論と周辺AWSサービスの組み合わせで見積もるのが基本です。

基本は基盤モデル推論課金

AWS News BlogのGA告知では、2023年11月28日の一般提供開始時点で、エージェントが行うモデル推論に対して課金され、InvokeAgent API自体には別料金がかからないと説明されていました。一方、2026年4月7日時点のAWS公式のAmazon Bedrock pricingでは、Agents専用の独立料金表よりもモデルや周辺機能の課金が中心に案内されています。そのため、現在の見積もりでは、まず基盤モデル推論と周辺AWSサービスを合わせて見る理解が安全です。

料金の見方は大きく次の3つです。

• どの基盤モデルをオーケストレーションに使うか
  
  
• 入出力トークン量がどれくらい増えるか
  
  
• Regionや必要スループットに応じてオンデマンドかProvisioned Throughputか

また、Provisioned Throughputをエージェントに関連付けるドキュメントもあるため、一定以上の安定した処理量が見込める場合は、エージェント用モデル側のスループット確保も検討対象になります。

見積もりでは周辺サービス費用も含める

Amazon Bedrock Agentsは単独で完結するより、Lambda、Knowledge Bases、S3、ベクトルストア、CloudWatchなどと組み合わせて使う構成が一般的です。そのため、実務上の見積もりは次のように分解して考えます。

コスト項目	どこで発生するか	見積もりの勘所
基盤モデル推論	エージェントの推論、回答生成、補助的なモデル呼び出し	モデル選択、応答長、会話ターン数
Provisioned Throughput	高トラフィック時の安定処理	常時負荷が高いかどうか
アクショングループ側処理	Lambdaや接続先APIの実行	実行回数、処理時間、外部API料金
ナレッジ連携	Knowledge Basesやベクトル検索	ドキュメント量、同期頻度、検索回数
監視とセキュリティ	ログ、暗号化、監査	本番運用で要求される監査レベル

ここで重要なのは、Amazon Bedrock Agentsのコスト最適化は「一番安いモデルを選ぶ」だけでは終わらないことです。無駄なツール呼び出し、長すぎる出力、過剰なRAG検索、不要なマルチエージェント化のほうが、実務では効いてきます。

PoCでは小さく始めるのが安全

PoC段階では、まず1エージェント、1モデル、1つか2つのアクショングループから始めるのが無難です。最初から複数モデル、複数Knowledge Base、複数エージェントを束ねると、コストより前に挙動の原因分析が難しくなります。

本番化が見えてから、必要に応じてProvisioned Throughputやマルチエージェント、追加の監査設計を足すほうが、費用対効果を見極めやすいです。

---

Amazon Bedrock AgentsをPoCで終わらせないなら

Amazon Bedrock Agentsは、エージェントの試作まではかなり速く進められます。ただし、本当に難しいのはその先です。どの業務システムに接続するのか、誰にどこまで実行権限を渡すのか、ログと監査をどう残すのかを決めないと、便利な検証で止まりやすくなります。

特に、社内アシスタントや問い合わせ対応のように業務フローへ直結するテーマでは、モデル精度だけでなく実行導線と運用設計が成果を左右します。AI Agent Hubは、こうした既存AI基盤の検証を、実際の業務接続や管理基盤の整備までどうつなげるかを整理するための資料です。

AI総合研究所の資料では、BedrockやSageMakerのような既存のAI基盤を前提に、業務システム接続、権限管理、実行ログの一元化をどう設計するかを整理しています。Amazon Bedrock Agentsの検証を本番活用につなげる判断材料としてご確認ください。

まとめ

Amazon Bedrock Agentsは、AWS上で「答えるAI」から「動くAI」へ進めるためのマネージド機能です。Knowledge BasesやGuardrailsを組み合わせた回答生成だけでなく、アクショングループで業務処理までつなげられるため、社内アシスタントや顧客対応、業務自動化の土台として使いやすいのが強みです。

一方で、すべての機能が全Regionで同じではなく、コードインタープリテーションやマルチエージェントの条件、周辺AWSサービスを含めたコスト設計、権限境界の整理までは自分で詰める必要があります。AWS資産を活かしつつ、まずはマネージドにエージェントを作りたい企業にとって、Amazon Bedrock Agentsはかなり有力な選択肢です。