『Agents』は新規お断り、続きは『AgentCore』で──AWSが2年半で作り替えた、エージェントの土台
AWSが看板の「Amazon Bedrock Agents」を新規受付停止にし、名称に『Classic』を付けて後継の『AgentCore』へ主軸を移しました。一体型の完成品から、フレームワークもモデルも問わない組み替え式の基盤へ。移行の作業と、従量課金で請求が膨らむ注意点まで読み解きます。
AWSが、生成AIエージェントの看板サービスだった「Amazon Bedrock Agents」を静かに一段下げました。公式ドキュメントの冒頭に、こう但し書きが付いています。「Amazon Bedrock Agents（現・Amazon Bedrock Agents Classic）は新規のお客様の受け付けを終了しました。同等の機能は Amazon Bedrock AgentCore をご検討ください。既存のお客様は従来どおりご利用いただけます」。2023年に登場し、AWS上でエージェントを組む標準的な入口だったサービスが、名前に「Classic」を付けられ、次の世代へ席を譲った格好です。
「Classic」という一語が動かしたもの
変わったのは呼び名だけではありません。技術解説によれば、新規受け付けの停止は2026年7月30日付で、既存のデプロイは「メンテナンスモード」に入り、新機能の追加は止まります。すでに本番で動かしている分が急に止まるわけではなく、当面は使い続けられます。一方で、これから新しくエージェントを作る人の入口は、事実上 AgentCore 一本になりました。
Bedrock Agents は、基盤モデル・データソース・社内APIをつなぎ、ユーザーとの対話から必要な処理を呼び出す「一体型の完成品」でした。プロンプト設計・メモリ・監視・権限までAWSがまとめて面倒を見る代わりに、構成の自由度はその枠の中に収まる作りです。今回の線引きは、その一体型モデルに区切りを付け、部品を組み替える方式へ主軸を移す、という意思表示だと読めます。
単体の“完成品”から、組み替え式の基盤へ
後継の AgentCore は、自らを「本番エージェントのためのプラットフォーム。どのフレームワークでも、どのモデルでも、スケールしても安全に」と説明します。LangChain、OpenAI Agents SDK、Claude Agent SDK、Strands SDK、あるいは自作フレームワーク──いずれで書いたエージェントでも載せられ、モデルも縛られません。特定の作法に閉じていた Classic とは、設計思想が異なります。
AgentCore は一枚岩ではなく、役割ごとの部品の集合として提供されます。ドキュメントや解説から読み取れる主な構成は次の通りです。
| 構成要素 | 役割 |
|---|---|
| Runtime | 開発したエージェントのコードを本番まで載せて動かす実行環境 |
| Gateway | MCPサーバー・ナレッジベース・社内API・Lambda などへの接続と認証・アクセス制御を束ねる窓口 |
| Memory | セッションをまたいで文脈を保持する永続メモリ |
| Identity | アクセスポリシーをプラットフォーム層で強制し、自動推論で検証する権限管理 |
| Observability | エージェントがどの手順を踏み、何を呼び、どこでつまずいたかを可視化する観測機能 |
| Evaluation | 実トラフィックに対して構成の違いを試し、品質を測る評価の仕組み |
単一エージェント前提だった Classic に対し、AgentCore は複数エージェントの協調（オーケストレーション）を土台に据えます。1体のエージェントに全部を持たせるのではなく、実行・接続・記憶・権限・観測を独立した層に分け、必要な部品を選んで組む。近年のエージェント設計が「一体型」から「合成可能な基盤」へ寄っている流れに、AWSも足並みをそろえた形です。
移行という宿題と、「3倍の請求書」への注意
既存ユーザーがそのまま使える以上、当面あわてる必要はありません。ただ、いずれ AgentCore へ移すとなると、名前の付け替え以上の作業が伴います。ある技術解説は、移行の道筋を大きく三つに整理しています。
- ツールキットで変換（およそ2〜4週間）: AWS の Import-Agent ツールで LangGraph 形式へ変換する、最短ルート。
- 作り直し（およそ4〜8週間）: AgentCore ネイティブの機能に合わせてゼロから組み直す。
- 併用: Classic を動かしたまま、新機能から段階的に AgentCore を採り入れる。
いずれの道でも、Classic 側のツール設定は Gateway 層向けに書き直しが要り、メモリの状態は自動では引き継がれず、権限（IAM）も複数エージェント構成に合わせて設定し直す、と同解説は指摘します。
コスト面には注意もあります。同解説は「設計を誤った複数エージェント構成は、単体の Bedrock Agents より AgentCore の請求が3倍に膨らみうる」と警鐘を鳴らします。Gateway 経由のリクエストやツール連携の呼び出しに、これまで無かった従量課金が乗るためで、安易に部品を増やすと請求が跳ねる、という指摘です。数字はAWS公式の見解ではなく一つの試算ですが、「柔軟になった分、設計の巧拙がそのまま請求に出る」という方向性は押さえておきたいところです。
この線引きから読み取れること
個々の移行手順以上に見ておきたいのは、方向性です。クラウド大手が、自前の第一世代エージェント製品を「Classic」に格下げし、フレームワークにもモデルにも縛られない実行基盤へ主軸を移した──この動きは、エージェントの価値が「特定ベンダーの完成品」から「どこで書いても載せて運用できる土台」へ移りつつあることを示します。開発する側にとっては、選択肢が広がる好機であると同時に、実行・接続・権限・観測をどう組み、どこまで課金が乗るかを自分で設計する責任が増える、ということでもあります。まずは、既存のエージェントがどの入口に依存しているかを棚卸ししておくと、いざ移行の判断が要るときに慌てずに済みます。
参照: Amazon Bedrock ユーザーガイド（Agents Classic の告知） ／ Amazon Bedrock AgentCore（公式） ／ AWS News Blog: AgentCore adds quality evaluations and policy controls ／ ServerGurus: What AgentCore Means for Your AI Workloads ／ AWS in Plain English: AWS Just Retired Its Flagship AI Agent Product
