まだ慣らし運転中。AWSのAgentCoreがエージェント開発を変えるのか探る

デモ完走に約1週間かかり、まだ様子を見極める局面です。AWSのAgentCoreは競合ツールも支える柔軟なエージェント基盤ですが、制御ルールとモデル間の連携など実務的な課題も残ります。 #エージェント #運用基盤

動画でサクッと！このブログ記事の解説

このブログ記事を動画で分かりやすく解説しています。
テキストを読む時間がない方も、映像で要点をサッと掴めます。ぜひご覧ください！

この動画が役に立ったと感じたら、AIニュースを毎日お届けしているYouTubeチャンネル「AIクリエーターの道」をぜひフォローしてください。
チャンネル登録はこちら：
https://www.youtube.com/@AIDoshi
🎧 音声で聴く：ジョンとリラが本記事をもとに、クリエイター実践の視点とAI活用戦略の視点から独自の見解をディスカッションしています。記事では詳細なツール情報と参照リンクをまとめています。

導入

Amazon Bedrock AgentCoreは、AIエージェントを企業規模で運用するためのインフラ・運用レイヤーとしてAWSが提供するサービスだ。モデルやフレームワークに依存しない設計を採りつつ、競合のモデルやSDKまで公式にサポートしている点が特徴的である。InfoWorldのMartin Heller氏が実際にデモを試し、約1週間をかけて複数のバグに遭遇しながらも完走したレビューが公開された。

モデル非依存・フレームワーク非依存。
競合含む主要エコシステムを公式サポート。
ただしデモは「まだ慣らし運転中」との評価。

背景と課題

AIエージェントの構築自体は、各種フレームワークの充実により以前よりも容易になった。問題はその先にある。本番環境への展開、セッション管理、認証、ポリシー制御、可観測性の確保といった運用面の課題が、企業導入の最大の障壁になっている。

Amazon Bedrockは生成AIアプリケーションの構築・スケーリングを支援するサービスだが、AgentCoreはその上位レイヤーとして、エージェントのデプロイと管理に特化した基盤を提供する。Martin Heller氏の記事によれば、AgentCore自体はモデル・フレームワーク・統合先について完全に非依存の設計だが、スターターキットCLIは主要なものに限定してサポートしている。

CLIが対応するモデルは、Amazon Bedrock、Anthropic、Google Gemini、OpenAIの各モデル。フレームワークとしてはStrands、LangGraph、Microsoft Autogen、OpenAI Agents SDK、Google Agent Development Kit、CrewAIをサポートする。統合先にはAgentCore Memory、AgentCore Observability、AgentCore Gatewayが含まれる。Heller氏が明示的に指摘しているとおり、これらの多くはAWSの競合企業が開発したものだ。

クラウドプラットフォーム上の直接的な競合としては、以下の3つが挙げられている。

• Google Cloud Agent SDK（ADK）：Vertex AI上に構築され、Geminiモデルとの深い統合を提供
• Azure AI Foundry Agents：Microsoftエコシステム・Azure OpenAI Serviceに深くコミットしている組織に適する
• Databricks Agent Bricks：Unity Catalogを活用し、企業データから直接エージェントを構築するデータ中心のアプローチ

さらに、競合であると同時に協力関係にもあるものとして、OpenAI Agents SDK、LangChain/LangGraph、CrewAI、SmythOSが挙げられている。エージェント基盤の競争は多層的であり、単純なプラットフォーム対決にはならない構図だ。

技術・内容解説

AgentCoreのコアサービスは全部で9つ。それぞれが独立して利用可能であり、エージェント開発に必要なものだけを組み合わせる設計になっている。ここでは各サービスの技術的な特徴を掘り下げる。

ランタイム

AgentCore Runtimeは、セキュアなサーバーレス実行環境だ。リアルタイムインタラクション向けの高速コールドスタート、非同期エージェント向けの長時間ランタイムサポート、完全なセッション分離、組み込みのIDサポートを備える。マルチモーダル・マルチエージェントのワークロードにも対応し、カスタムフレームワークや任意のオープンソースフレームワーク、Amazon Bedrock内外の任意の基盤モデルと統合できる。

メモリ

AgentCore Memoryは、コンテキストを意識したエージェントの構築を可能にする。マルチターン会話用の短期メモリと、セッションをまたいで永続する長期メモリの両方をサポート。エージェント間でメモリストアを共有でき、経験から学習する機能も持つ。LangGraph、LangChain、Strands、LlamaIndexと連携する。

ゲートウェイ

AgentCore Gatewayは、任意のAPI、Lambda関数、既存サービスをModel Context Protocol（MCP）互換のツールに変換するサービスだ。既存のMCPサーバーへの接続も可能で、数行のコードでゲートウェイエンドポイント経由でAIエージェントに提供できる。既存のバックエンドをコード書き換えなしでエージェントからアクセス可能にする点は、企業導入において実用的な価値が高い。

アイデンティティ

AgentCore Identityは、エージェントのID・アクセス・認証管理サービス。既存のIDプロバイダーや資格情報プロバイダーと互換性があり、ユーザー移行や認証フローの再構築が不要。

コードインタープリター

AgentCore Code Interpreterは、エージェントがコードを実行するための隔離されたサンドボックス環境だ。Python、JavaScript、TypeScriptをサポートする。デフォルトの実行時間は15分で、最大8時間まで延長可能。Strands Agents SDKをPythonまたはTypeScriptで、bedrock_agentcore SDKやBoto3をPythonで利用できる。セッション分離アーキテクチャにはFirecracker microVMsが使用されている。

ブラウザ

AgentCore Browserは、ローカルマシンではなく別環境で動作するリモートブラウザだ。AIエージェントが人間と同様にウェブサイトを操作し、フォーム入力、ボタンクリック、動的コンテンツの解析を行える。ライブビューの監視と必要に応じた介入も可能。Nova Act、Strands、Playwrightと統合してウェブ操作を自動化する。

可観測性

AgentCore Observabilityは、本番環境でエージェントのパフォーマンスをトレース・デバッグ・監視するための統合ビューを提供する。エージェントワークフローの各ステップの詳細な可視化が可能で、実行パスの検査、中間出力の監査、パフォーマンスのボトルネックや障害のデバッグに対応。OpenTelemetry（OTEL）形式をサポートする任意の可観測性スタックと統合できる。

評価

AgentCore Evaluationsは、エージェントとツールがタスクをどの程度うまく実行するか、エッジケースをどう処理するか、多様な入力・コンテキストにわたって出力の信頼性をどう維持するかを測定する自動化サービスだ。

ポリシー

AgentCore Policyは、エージェントが定義された境界とビジネスルール内で動作することを保証する決定論的制御を提供する。ルールは自然言語またはCedar（AWSのオープンソースポリシー言語）で記述可能。重要な点は、ポリシーがエージェントの外部で実行されるため、モデルが制約に違反できない設計になっていることだ。

よくある誤解

用語解説

MCP（Model Context Protocol）

AIエージェントが外部サービスやツールに接続するための標準プロトコル。AgentCore Gatewayはこのプロトコルに準拠したツール変換を行う。

Firecracker microVM

AWSが開発した軽量な仮想マシン技術。AgentCoreのコードインタープリターとブラウザのセッション分離に使用されており、高速起動とセキュリティ分離を両立する。

Cedar

AWSが開発したオープンソースのポリシー言語。AgentCore Policyでは自然言語に加え、Cedarでもルールを記述できる。

OpenTelemetry（OTEL）

分散トレーシング・メトリクス・ログの収集に関するオープンな標準仕様。AgentCore Observabilityはこの形式をサポートし、既存の監視スタックとの統合を可能にする。

CDK（Cloud Development Kit）

AWSのインフラストラクチャをコードで定義するためのフレームワーク。デモではCDKを使ってAgentCoreのスタックをデプロイしている。

インパクト・活用事例

AgentCoreの主要なユースケースは3つに分類される。エージェント構築、MCPサーバーの展開、そしてエージェントプラットフォームの構築だ。

エージェント構築では、カスタマーサポート、ワークフロー自動化、データ分析、コーディング支援といった用途にサーバーレスで展開できる。セッション分離、永続メモリ、組み込みの可観測性を備えた状態で稼働する。

MCPサーバーとしては、API、データベース、既存サービスをMCP互換エージェントが利用できるツールに変換できる。Lambda関数やOpenAPI仕様をラップするゲートウェイをデプロイし、コードの書き換えなしでバックエンドをエージェントからアクセス可能にする。

エージェントプラットフォームとしては、開発者や顧客が承認されたツール、共有メモリストア、企業サービスへのガバナンス付きアクセスを使ってエージェントをデプロイできるプラットフォームを構築できる。

カスタマーサポートエージェントのデモ検証

Heller氏はAWSのAgentCoreチームの推奨で、カスタマーサポートエージェントのデモを実際に試している。このデモは、エージェントのデプロイ、ユーザー認証、エージェントの呼び出し、そしてAgentCore Policyによる返金制限のリアルタイム適用を示すものだ。

デプロイスクリプトはCDKを使い、DockerイメージのビルドとAWS ECRへのプッシュ、CloudFormationスタックの作成を自動化する。デプロイ完了までの所要時間は、DockerImageStackが約15秒、AgentCoreStackが約41秒だった。

注目すべきは、Heller氏がこのデモの完了に約1週間を要した点だ。複数のバグやドキュメントの不備に遭遇し、報告と修正を繰り返しながらの作業だったと述べている。具体的な問題として、以下が挙げられている。

• デプロイスクリプトのチェック機能が信頼できず、問題を修正しても次回実行時に同じ警告が出続けた
• スクリプトの再実行時に新しいDockerイメージがビルドされ、古いものを手動で削除する必要があった
• エージェントステータス確認コマンドにuv runプレフィックスが必要だったが、ドキュメントに記載がなかった
• ステータス確認が当初は偽陰性を返していたが、AWSエンジニアがパース問題を修正して解消された

認証はAWSログインとCognitoログインの二重構造で、Cognitoのベアラートークンは1時間で失効する。AWSの説明では、二重ログインはエージェント開発の整合性を維持するための設計上の意図によるものとされている。

ポリシー制御の実証と限界

デモでは、ポリシー未適用の状態で399ドルのモニターの返金リクエストが承認されてしまう場面がある。本来は人間のサポート担当者に回すべきケースだ。ポリシー適用後に同種のリクエストを試すと、正しく拒否された。

ただしHeller氏が指摘した重要な設計上の問題がある。ポリシーがエージェントの外部で実行されるため、モデルはリクエストが拒否された理由を知らない。結果としてモデルが理由を「推測」（つまりハルシネーション）し、的外れな推奨事項を返してしまった。Heller氏は「拒否理由をモデルにフィードバックする安全な方法があるべきだが、このアーキテクチャでどう実現するかは自分のレベルでは分からない」と率直に述べている。

正直なところ、このポリシーモジュールの設計上の課題は、エンタープライズ導入において無視できない問題だと思う。セキュリティのためにポリシーをモデル外に置くのは正しい判断だが、拒否理由がモデルに伝わらないとユーザー体験が劣化する。この二律背反をどう解決するかは、AgentCoreに限らずエージェント基盤全般が抱える課題だ。

なお、Heller氏によれば、リトライを含むデモ全体のAWS利用料金はわずか0.35ドルだった。

競合との位置づけ

前述のとおり、Google Cloud Agent SDK（ADK）、Azure AI Foundry Agents、Databricks Agent Bricksが直接的な競合として位置づけられている。加えてOpenAI Agents SDK、LangChain/LangGraph、CrewAI、SmythOSも競合かつ協力関係にある。

AgentCoreの差別化ポイントは、モデル・フレームワークに対する非依存性と、競合のツールチェーンまで公式にサポートする間口の広さにある。これは自社エコシステムへの囲い込みが基本戦略であるGoogle（Geminiモデル中心）やMicrosoft（Azure OpenAI Service中心）とは対照的なアプローチだ。

個人的には、この「非依存」という設計思想のほうが、サポート対象のフレームワーク数よりも影響が大きいと見ている。日本の大企業ではマルチクラウド戦略を採るケースが増えており、特定ベンダーのモデルに縛られないインフラレイヤーへの需要は高い。ただし、CLIが「主要なもの」に限定しているという制約が、実際にどの程度の範囲をカバーするのかは、プロジェクトの要件次第で評価が分かれるだろう。

アクションガイド

AgentCoreの評価・導入を検討する際の指針を、対象者別に整理する。

インフラ・クラウドアーキテクト向け

• まずAgentCoreのコアサービス9つの中から、自社のエージェント運用に必要なものを特定する
• 既存のID基盤との互換性を確認し、AgentCore Identityでユーザー移行が不要かを検証する
• Firecracker microVMによるセッション分離が自社のセキュリティ要件を満たすか評価する
• OpenTelemetry形式のサポートにより、既存の可観測性スタックとの統合可否を確認する

エージェント開発者向け

• カスタマーサポートエージェントのデモから試すのが推奨。ただしHeller氏の報告によれば現時点でバグやドキュメント不備が残っている可能性がある
• コマンド実行時にはuv runプレフィックスが必要な点に注意
• Cognitoのベアラートークンは1時間で失効するため、長時間の作業ではトークン再取得の手順を把握しておく
• AgentCore Policyのルール記述にはCedar（AWSのオープンソースポリシー言語）と自然言語の両方が使える

保存用チェックリスト

未来展望とリスク

AgentCoreが狙うエージェント運用基盤の市場は、Google、Microsoft、Databricksに加え、OpenAIやLangChainといったフレームワーク提供者も参入する激戦領域だ。AgentCoreの「非依存」戦略が持続的な差別化になるかは、各競合が自社エコシステムの囲い込みをどこまで強めるかに左右される。

Heller氏が報告したデモのバグやドキュメント不備は、サービスが「慣らし運転中」であることを示している。Heller氏自身も、サンプルは現時点で「シェイクダウンクルーズ（慣らし航海）の段階にある」と評価している。エンタープライズ採用を検討する場合、サンプルコードやドキュメントの成熟度には注意が必要だ。

ポリシーモジュールにおける「拒否理由がモデルに伝わらない」問題は、今後のアーキテクチャ改善で対処されるかが注目点になる。セキュリティとユーザー体験のバランスをどう取るかは、エージェント基盤全体に共通する技術的課題であり、AgentCoreがここで先行できればプラットフォームとしての信頼性が大きく向上する可能性がある。

日本市場においては、国内のSIer案件でマルチクラウド構成を採用するケースが増えている状況を考えると、特定モデルに依存しないAgentCoreの設計思想は親和性が高い。一方で、ドキュメントが英語中心であること、デモの品質がまだ発展途上であることから、導入にはAWSに精通したエンジニアが社内にいることが前提条件になるだろう。

まとめ

Amazon Bedrock AgentCoreは、AIエージェントのエンタープライズ運用に必要な要素をひととおり備えた基盤サービスだ。Heller氏は「エージェントのための堅実な基盤」と評価しつつも、ポリシーモジュールの設計課題やデモの完成度について率直な懸念を示している。

強みは、モデル・フレームワーク非依存の設計、競合ツールチェーンまでカバーする間口の広さ、そしてポリシーをモデル外部で実行するセキュリティアーキテクチャだ。弱みは、ドキュメントの複数オプションによる分かりにくさと、サンプルの成熟度にある。

本番導入を検討する段階では、デモを実際に動かして現時点の品質を自分の目で確認することが不可欠だ。Heller氏の体験が示すとおり、バグ報告に対するAWSエンジニアの対応は迅速だが、それはつまりまだバグが出続ける段階にあるということでもある。

参照リンク・情報源

• InfoWorld – Martin Heller氏によるAgentCoreレビュー記事