AWSはAmazon Bedrock AgentsをAmazon Bedrock Agents Classicへ改称し、2026年7月30日から新規顧客への提供を制限する。既存エージェントが直ちに停止するわけではないが、過去12カ月に利用実績がないアカウントではCreateAgentとInvokeInlineAgentがAccessDeniedException、HTTP 403になる。新規開発の標準はAmazon Bedrock AgentCoreへ移る。

何が変わったか

Agents Classicはメンテナンスモードとなり、既存APIの運用とサポートは続く一方、新機能は追加されない。7月30日時点でモデルカタログも固定され、それ以降の新モデルはClassicのオーケストレーション層では利用できない。Amazon Bedrock本体、Knowledge Bases、Guardrailsは対象外で、引き続き更新される。

変更前後の差

従来は新しいAWSアカウントでもAgentsを作成し、IaCで同じ構成を展開できた。変更後は、過去12カ月のAgents利用実績に基づくアカウント単位のallowlistが適用される。既存のCloudFormation、CDK、Terraformはallowlist対象アカウントでは動くが、新規アカウントへ同じテンプレートを展開すると失敗する可能性がある。

誰に影響するか

複数アカウント戦略、ランディングゾーン、災害復旧、顧客別環境、短期検証アカウントでAgentsを作る組織が強く影響を受ける。既存アカウントでも、別アカウントへ複製する設計や、新しいリージョン・組織単位へ展開する計画がある場合は確認が必要である。例外申請の仕組みは提供されない。

期限

新規顧客の制限開始日は2026年7月30日である。既存顧客に移行期限や終了予定日は設定されていない。ただし新規アカウント利用の確保だけを目的に形式的な作成を行うのではなく、AWSの利用条件と社内承認に従い、実際の計画に基づいて判断する。

必要な対応

全AWSアカウントのAgents利用実績、CreateAgent、InvokeInlineAgent、IaC、モデル依存を棚卸しする。新規環境はAgentCoreを既定とし、Classicの構成要素をモデル、ツール、Knowledge Base、プロンプト上書き、セッション、multi-agentに分けて対応表を作る。既存環境は停止リスクよりも機能停滞と将来のモデル非対応を評価する。

実装・移行手順

  1. Organizations配下の対象アカウントを一覧化する
  2. CloudTrailや構成管理から過去12カ月のAgents利用を確認する
  3. 新規アカウントでCreateAgentを前提とするIaCを特定する
  4. AgentCoreの対応リージョン、IAM、CLI要件を確認する
  5. 単純なAgentをAgentCore managed harnessへ移す
  6. custom orchestratorとmulti-agentはruntime上の実装へ分離する
  7. Knowledge BasesとGuardrailsの接続方法を検証する
  8. 応答品質、tool call、session、費用、運用監視を比較する
  9. 新規環境テンプレートをAgentCoreへ切り替える

失敗しやすい点

Bedrock全体が終了すると誤解する、組織全体で一つの利用実績があれば全アカウントが許可されると思う、既存IaCが新規アカウントでも動くと仮定する、AgentCoreがClassicのmulti-agentを無変更で再現すると考える、といった問題が起きやすい。allowlistはアカウント単位であり、複雑なエージェントはコード変更が必要になる。

リスク

新規環境構築のHTTP 403、災害復旧先での再作成不能、モデル更新停止による品質差、移行時のプロンプト・ツール挙動差、AgentCore対応リージョン不足がある。Classicを長期維持すると、既存機能は動いても新しいモデルや運用機能へ追随できず、技術的な固定化が進む。

評価方法

  • allowlist対象アカウント率
  • Classic依存エージェント数
  • 新規IaCのAgentCore対応率
  • tool call成功率と応答品質
  • Knowledge Base・Guardrailの互換性
  • session継続とmemoryの差
  • 1タスク当たりの推論・runtime費用
  • 対応リージョンと復旧要件の適合率
  • Classic固有APIの残存数

ロールバック

既存Classicエージェントは停止せず、AgentCore移行を並行運用する。品質や機能差が大きい場合は、allowlist済みアカウントのClassic aliasへトラフィックを戻す。新規アカウントではClassicへ戻せないため、別の許可済み環境へ依存する設計ではなく、AgentCoreまたは自前runtimeの代替を用意する。

編集部分析

この変更の実務上の焦点は既存停止ではなく、新規アカウントと将来モデルの閉鎖である。複数アカウントを前提にするクラウド運用では、同じテンプレートをいつでも再展開できることが復旧性の基礎になる。Classicを使い続ける場合でも、新規環境を再現できない構成は早期に解消すべきである。

実務チェックリスト

  • [ ] アカウント別の過去12カ月利用実績を確認した
  • [ ] CreateAgentとInvokeInlineAgent依存を特定した
  • [ ] 新規IaCをAgentCoreへ切り替えた
  • [ ] Classicのモデル固定を考慮した
  • [ ] Knowledge BasesとGuardrailsが対象外と確認した
  • [ ] multi-agentの機能差を評価した
  • [ ] 7月30日前に新規環境方針を決めた
  • [ ] Classicへ戻せない新規アカウントの代替を用意した

一次情報