Amazon Bedrock エージェント Classic、新規顧客の利用開始を7月30日から制限

AWS は従来の Amazon Bedrock エージェントを「Amazon Bedrock エージェント Classic」と位置付け、2026年7月30日から新規顧客による利用開始を制限します。既存のエージェントが同日に停止する変更ではありませんが、新しいAWSアカウントでエージェント環境を増やす計画や、今後のモデル更新を取り込む計画には影響します。

要点

• 従来の Amazon Bedrock エージェントは Amazon Bedrock エージェント Classic となり、2026年7月30日から新規顧客は利用を開始できなくなります。
• 過去12カ月に CreateAgent または InvokeInlineAgent を呼び出した実績のあるAWSアカウントは対象外で、既存エージェントは継続して動作します。
• 利用実績の判定はAWSアカウント単位です。複数アカウントを使う組織では、既存環境が動いていても、新設アカウントが同じ扱いになるとは限りません。
• Bedrock エージェント Classic のモデルカタログは7月30日時点で固定され、それ以降の新モデルは AgentCore 側で提供されます。
• Amazon Bedrock 全体、基盤モデル、Knowledge Bases、ガードレールは今回の制限対象ではありません。

今回の更新で変わること

今回の変更で最も重要なのは、Amazon Bedrock エージェント Classic の既存利用と新規利用を分けて考える必要がある点です。AWSの説明では、既存顧客のエージェントは従来どおり利用でき、UpdateAgent、GetAgent、PrepareAgent、InvokeAgent などのAPIも継続します。一方、過去12カ月に CreateAgent または InvokeInlineAgent の利用実績がないAWSアカウントでは、7月30日以降、新しいエージェントの作成やインラインエージェントの呼び出しが制限されます。利用実績は組織全体ではなくアカウントごとに判定されるため、開発環境で使っていた実績を、新しい本番アカウントや別部門のアカウントへそのまま引き継げるわけではありません。

既存のCloudFormation、CDK、Terraformの定義も、利用対象となっているアカウントでは引き続き機能します。ただし、同じ構成を新設アカウントへ展開すると、CreateAgent が制限される場合があります。マルチアカウント構成、災害復旧用アカウント、顧客ごとの分離環境を用意しているチームは、テンプレートが正しいかだけでなく、各アカウントに利用実績があるかを確認する必要があります。AWSは例外申請を用意しないと説明しているため、7月30日以降に新しいアカウントで従来型エージェントを使い始める前提は見直した方がよいです。

もう一つの境界は、機能の継続と機能拡張の停止です。Bedrock エージェント Classic に終了期限は示されておらず、既存環境を直ちに移行する必要はありません。しかし、モデルカタログはメンテナンスモードの発効日時点で固定され、新しいモデルは AgentCore 側で利用する方針です。Bedrock エージェント Classic を長期運用する場合、現在のエージェントが動き続けるかだけでなく、今後必要になるモデル、オーケストレーション、観測、メモリ、ツール接続をどちらの基盤で実現するかが判断材料になります。なお、今回の制限はエージェントのオーケストレーション層に限られ、Amazon Bedrock のモデル推論、Knowledge Bases、ガードレール自体がメンテナンスモードになるわけではありません。

対象になりそうなユーザー・チーム

• Amazon Bedrock エージェントを本番運用しているAI基盤・クラウド基盤チーム
• 開発、本番、災害復旧、顧客環境を複数のAWSアカウントに分けている管理者
• CloudFormation、CDK、Terraformでエージェント環境を横展開しているプラットフォーム担当
• 新しい基盤モデルを継続的に採用したい生成AIアプリの開発責任者
• Bedrock エージェント Classic から AgentCore への移行時期を判断するアーキテクト

既存環境と新規アカウントを分けて確認する

まず、Bedrock エージェント Classic を使う全AWSアカウントを一覧にし、過去12カ月の CreateAgent と InvokeInlineAgent の利用実績を確認します。既存エージェントが稼働しているアカウントだけでなく、将来の本番切り替え先、災害復旧先、新規リージョン展開用のアカウントも含めることが大切です。

既存アカウントでは、現在のAPIやIaCを直ちに書き換える必要はありません。新規アカウントへの展開を予定している場合は、Bedrock エージェント Classic を前提にせず、AgentCoreで同じ要件を満たせるかを先に評価した方が安全です。

AgentCoreへの移行で見比べるポイント

AWSは移行先として AgentCore を案内し、設定中心のマネージドハーネスと、独自の実装を持ち込むコード定義型エージェントの2つの方向を示しています。前者はモデル、ツール、指示を宣言し、実行環境、メモリ、ID、観測などをマネージドで扱う構成です。後者は独自のオーケストレーションやフレームワークを維持したい場合に向いています。

ただし、Bedrock エージェント Classic の機能がすべて同じ設定項目へ一対一で移るわけではありません。たとえば、処理段階ごとのプロンプト上書き、アクショングループ、Knowledge Basesとの接続、ユーザーへの聞き返し、複数エージェントの連携は、AgentCoreで構成方法が変わります。移行判断では、機能名の対応表だけでなく、現在のエージェントがどのAPI、ツール、メモリ、ガードレール、追跡情報に依存しているかを棚卸しする必要があります。

今すぐ対応が必要か

既存エージェントが7月30日に停止するわけではないため、緊急の全面移行は不要です。ただし、新規AWSアカウントでの利用開始や、7月30日以降の新モデル採用を予定している場合は、早めの確認が必要です。

短期的にはアカウント別の利用実績と新設計画を確認し、中期的には AgentCore での再現方法を小さく検証するのが現実的です。特にIaCで多数の環境を作る組織では、デプロイ時に初めて制限へ気付く事態を避けるため、対象アカウントを事前に分類しておきたいです。

結局、この更新をどう見るべきか

今回の更新は、Amazon Bedrock 全体の終了や、既存エージェントの即時停止ではありません。Bedrock エージェント Classic を既存環境の維持基盤として残し、新規導入と今後の機能拡張を AgentCore へ移す境界を明確にした変更です。

既存利用者は慌てて移行するより、アカウント単位の利用資格、モデル更新の計画、現在のエージェント構成を確認することが先です。新規環境を作るチームは、Bedrock エージェント Classic を新たな標準にせず、AgentCoreを前提に設計を比較する必要があります。