Amazon Bedrock AgentCoreは、AIエージェントを試作から本番運用へ移すために、実行環境、記憶、外部ツールとの接続、権限管理、監視などを組み合わせて使えるAWSのサービス群です。
AWSの公式概要では、各サービスを一緒にも個別にも利用でき、特定のモデルやエージェント開発フレームワークに限定されない構成として説明されています。
AIエージェントとは、言語モデルが回答するだけでなく、目的に応じてツールを呼び出し、状態を引き継ぎ、処理を進める仕組みです。基本から確認したい場合は、AIエージェントの仕組みと安全な運用も参考になります。
AgentCoreは回答を作るモデルそのものではありません。モデルを業務システムにつなぎ、誰が何を実行できるかを制御し、問題が起きたときに追跡できる状態を整えるための基盤です。
プレビューから正式提供へ
Amazon Bedrock AgentCoreは2025年7月にプレビューとして発表され、2025年10月に正式提供へ移行しました。
したがって、プレビューの終了日やプレビュー中の無料条件を前提に導入を判断することはできません。利用前には、現在の公式料金ページと対象リージョンの最新情報を確認する必要があります。
正式提供後も機能は追加されています。以下では全機能を列挙せず、AIエージェントを本番運用する際に役割を理解しやすい七つの中核サービスに絞ります。
試作と本番運用で異なる要件
社内デモでは、モデルが期待どおりの回答を返せば目的を達成できることがあります。しかし、本番環境では、その回答をどの利用者に見せるか、どのデータや操作を許すか、失敗をどう検知するかまで設計しなければなりません。
| 確認領域 | 本番運用で必要になること |
|---|---|
| 実行環境 | 処理の分離、負荷への対応、停止や再実行の手順を決める |
| 状態管理 | 会話や作業の履歴を、必要な範囲と期間に限って保持する |
| 権限 | 利用者とエージェントが参照または更新できる対象を分ける |
| 外部連携 | APIや業務ツールを安全に呼び出し、失敗時の扱いを決める |
| 監視 | 実行経路、エラー、遅延、利用量を追跡できるようにする |
AgentCoreは、これらの要件を一つの巨大な機能で解決するのではなく、必要なサービスを選んで組み合わせる考え方です。
七つの中核サービスと役割
| サービス | 役割 | 平易な説明 |
|---|---|---|
| Runtime | エージェントの実行 | エージェントのコードを管理された環境で動かし、運用時の負荷に対応します。 |
| Memory | 状態と文脈の保持 | 短期の会話履歴や、後の処理で参照する長期的な情報を扱います。 |
| Gateway | ツールとの接続 | 既存のAPI、AWS Lambda、MCPサーバーなどを、エージェントが利用できるツールとして接続します。 |
| Identity | 認証とアクセス管理 | 利用者やエージェントの身元を確認し、AWSや外部サービスへアクセスするための権限を扱います。 |
| Observability | 追跡と監視 | どの処理が実行され、どこで失敗したかを、ログやトレースから調べられるようにします。 |
| Browser | Web操作 | Webページの閲覧、入力、情報取得などを、分離されたブラウザ環境で実行します。 |
| Code Interpreter | コード実行 | 計算やデータ処理に必要なコードを、隔離された環境で実行します。 |
MCP（Model Context Protocol）は、エージェントが外部のデータや機能をツールとして呼び出すための共通方式です。エージェント同士をつなぐA2Aとの区別は、MCPとA2Aの違いを整理した解説で確認できます。
AgentCoreには、このほかエージェントの行動範囲を制御するPolicyや、品質を継続的に測るEvaluationsなどの機能もあります。機能構成は更新されるため、採用時には公式FAQの最新一覧を確認してください。
業務での使い方と設計上の境界
カスタマーサポート
問い合わせ内容を分類し、社内情報を検索して回答案を作る流れでは、Memory、Gateway、Identity、Observabilityを組み合わせられます。
ただし、回答案の作成と顧客への送信は別の操作です。誤回答や個人情報の扱いが問題になり得るため、送信前の確認者と、参照を許すデータを先に決めます。
営業と調査
BrowserやGatewayを使えば、Web上の情報収集、社内データの参照、顧客管理システムへの記録を一連の作業として設計できます。
この場合も、公開情報の取得と社内システムの更新では必要な権限が異なります。情報源の記録、著作権への配慮、更新前の承認を作業ごとに分ける必要があります。
開発支援
Code InterpreterやRuntimeは、テストコードの実行、ログの解析、修正案の検証に利用できます。
リポジトリへの書き込みや本番環境への反映まで任せる場合は、最小権限、レビュー、差し戻し手順を用意します。コードを実行できることは、変更の妥当性まで保証することを意味しません。
導入を小さく始める五つの手順
- 対象業務を一つに絞る：「問い合わせを分類して回答案を作る」のように、開始条件と完了条件を明確にします。
- データと操作を分ける：読む情報、書き換える情報、外部へ送る情報を一覧にし、それぞれの権限を決めます。
- 必要なサービスだけを選ぶ：Web操作が不要ならBrowserを使わないなど、用途に関係しない機能を増やしません。
- 失敗を試す：権限不足、外部APIの停止、誤った入力、処理の長期化を想定し、ログと復旧手順を確認します。
- 段階的に範囲を広げる：最初は提案や下書きに限定し、精度、費用、担当者の負担を確認してから実行権限を広げます。
Amazon Bedrock自体のモデル選択やAPI連携から確認したい場合は、Amazon Bedrockの特徴と使い方を先に読むと、AgentCoreとの役割分担を理解しやすくなります。
料金を見積もるときの確認項目
AgentCoreは従量課金を基本とし、利用するサービスごとに課金対象が異なります。単一の月額料金だけで見積もるのではなく、構成全体を確認します。
- Runtime、Browser、Code Interpreterで消費する計算資源
- Gatewayの呼び出しやMemoryの保存と取得
- CloudWatchで扱うログ、メトリクス、トレース
- Amazon Bedrockまたは外部プロバイダーで利用するモデル推論
- 利用構成に含まれる他のAWSサービス
試算では、正常時の平均だけでなく、処理の再試行、長時間実行、ログ量の増加も含めます。料金単価は変わる可能性があるため、導入時点の公式料金を基準にしてください。
導入判断のチェックリスト
| 項目 | 確認する問い |
|---|---|
| 業務目的 | エージェントに任せる作業と、人が判断する作業を分けたか |
| 権限 | 参照、更新、外部送信の権限を別々に設定したか |
| データ | 保存する情報、保存期間、削除方法を決めたか |
| 品質 | 成功条件、誤りの検知方法、確認者を決めたか |
| 監視 | 実行経路と失敗理由を追跡できるか |
| 費用 | モデル、計算資源、ログ、再試行を含めて試算したか |
| 復旧 | 外部サービス停止や誤操作から戻す手順があるか |
AgentCoreが適する場面
Amazon Bedrock AgentCoreは、AIエージェントの実行、記憶、ツール接続、権限、監視を、用途に合わせて組み合わせたい組織に適した選択肢です。
一方で、基盤を採用するだけでは業務上の責任分担やデータ管理は決まりません。対象業務を小さく区切り、最小限の権限と人の確認を入れ、ログと費用を見ながら段階的に広げることが、本番運用への現実的な進め方です。
公式情報
この記事に関連する株式会社greedenの取り組み
AIエージェントを本番で生かすには、基盤選定だけでなく、業務範囲、権限、確認手順まで設計する必要があります。株式会社greedenは、生成AIを用いた施策を、相談からシステム実装、現場への定着まで支援しています。