AWSは、Amazon Bedrock Agents Classicを2026年7月30日から新規顧客へ提供しないと案内した。既存顧客は継続利用できるが、ClassicはMaintenance Modeとして扱われる。

これは即時停止ではない。しかし、新規導入、長期ロードマップ、採用技術の標準化に影響する。既存利用者は「動き続けるから何もしない」ではなく、継続利用の条件と移行可能性を評価する必要がある。

何が変わったか

Agents Classicは、Foundation Model、Instruction、Action Group、Knowledge Base、Lambdaなどを組み合わせてAgentを構築する従来のBedrock機能である。

2026年7月30日以降、新規顧客はAgents Classicへアクセスできなくなる。既存顧客は利用を継続できるが、Maintenance Modeでは重大な修正や維持が中心となり、新機能の主対象ではなくなる。

変更前後の差

項目2026年7月29日まで2026年7月30日以降
新規顧客利用開始可能新規受付終了
既存顧客利用可能継続利用可能
製品位置付け現行機能Maintenance Mode
新規案件採用候補原則再検討
長期投資通常評価移行リスクを加味

「既存顧客」の判定条件や対象アカウント・リージョンは、実際のAWSアカウントと公式案内で確認する。利用権を確保する目的だけで形式的なリソースを作る判断は、契約・運用・費用を含めて慎重に行う。

誰に影響するか

  • Agents Classicを本番運用している
  • 2026年下期に新規AgentをClassicで構築予定
  • 複数AWSアカウントやOrganizationへ展開予定
  • 顧客環境へテンプレートを配布するSaaS・SI
  • Classic固有のAction GroupやPrompt Overrideを多用する
  • 監査、評価、承認がClassic実装へ密結合している
  • 災害対策で別リージョン・別アカウントへ再構築する計画がある

既存アカウントで動くことと、将来別アカウントへ復旧できることは別問題である。

必要な対応

7月30日までに、次の三択を決める。

  1. 既存Classicを当面継続し、変更を限定する
  2. 新しいAgent基盤へ段階移行する
  3. Agent機能をアプリケーション側へ戻し、依存を減らす

判断材料には、機能差、リージョン、モデル、Tool連携、会話状態、監視、Guardrail、評価、費用、IAM、ベンダーロックインを含める。

実装・移行手順

1. 資産を棚卸しする

Agent ID、Alias、Version、Foundation Model、Instruction、Prompt Override、Action Group、OpenAPI schema、Lambda、IAM Role、Knowledge Base、Guardrail、Memory、Logs、評価データを一覧化する。IaCで再構築できるかも確認する。

2. 利用権の範囲を確認する

AWS Account、Organization、Region、Sandbox、本番の各環境でアクセス可能か確認する。DR用アカウントが未使用なら、将来Classicで復旧できない可能性を評価する。

3. 代替を比較する

代替候補は、Bedrockの新しいAgent関連機能、Responses互換APIを使う独自オーケストレーション、Step Functions・Lambdaによるワークフロー、他の管理型Agent基盤などである。

Classicの機能名をそのまま移すのではなく、推論、Tool選択、Tool実行、検索、状態、記憶、承認、Guardrail、監視、評価へ分解する。

4. Golden Setを作る

現在の本番会話と業務シナリオから、正常系、曖昧入力、Tool失敗、権限不足、Prompt Injection、タイムアウトを含む評価セットを作る。

5. 影運用する

新基盤へ同じ入力を送り、実操作は行わず結果を比較する。Tool選択、引数、回答、レイテンシ、費用、安全性を測る。

6. 読み取りから切り替える

検索・照会を先に移し、更新・送信・削除は後にする。高リスクToolは人間承認を残す。

失敗しやすい点

  • Agent定義だけを移し、Lambda、IAM、Network、秘密、監視を忘れる
  • 新規顧客制限をAWSアカウント・Region単位で確認しない
  • 出力文だけを比較し、Tool選択や引数を評価しない
  • 移行期間中もClassic側のPromptやToolを変更し続ける
  • 新しいPreview機能を可用性確認なしで本番標準にする

変更凍結と例外手順を設け、差分が増え続けないようにする。

評価方法

  • Golden Setのタスク完了率
  • Tool選択一致率
  • Tool引数正確性
  • 人間修正率
  • 誤操作率
  • P50・P95レイテンシ
  • タスク当たり費用
  • Prompt Injection耐性
  • IAM拒否と回復動作
  • 監査ログ完全性
  • DRアカウントでの再構築時間
  • Classic固有機能への残存依存数

移行完了条件には、機能比較だけでなく、障害対応、監査、ロールバックを含める。

ロールバック

段階移行中は、Classicを安定版として維持し、新基盤をFeature Flagで切り替える。書き込みToolの二重実行を防ぐため、両系統を同時Activeにしない。

  1. 新規SessionをClassicへ戻す
  2. 新基盤の書き込みToolを停止する
  3. 途中Sessionの状態を確認する
  4. 重複実行・未完了処理を照合する
  5. Classic側の容量・Quotaを確認する
  6. 新基盤の原因を修正する
  7. 限定トラフィックで再開する

7月30日以降もClassicが既存顧客へ提供される限りロールバック先になり得るが、将来の永続保証として扱わない。

編集部分析

Maintenance Modeは、停止日より判断が難しい。サービスが動くため、移行を先送りしやすい一方、採用人材、ドキュメント、周辺機能、将来のリージョン展開が徐々に制約される。

既存利用者にとって合理的な選択は必ずしも即時全面移行ではない。安定しており変更が少ない内部Agentなら、Classicを継続しながら出口計画と評価セットを整える方が低リスクな場合もある。

一方、新規事業や顧客向けSaaSでClassicを標準基盤にする判断は弱い。新規顧客制限により、将来のアカウント展開や災害復旧が設計上の制約になるためである。

実務チェックリスト

  • [ ] 全Classic Agentと関連リソースを棚卸しした
  • [ ] AWS Account・Region別の利用可否を確認した
  • [ ] DR・顧客環境の再構築可能性を評価した
  • [ ] Classic固有機能を能力単位へ分解した
  • [ ] 代替候補の要件比較表を作った
  • [ ] Golden Setに異常系と攻撃系を含めた
  • [ ] 影運用でTool選択と引数を比較した
  • [ ] 移行期間中の変更凍結ルールを決めた
  • [ ] Feature Flagと二重実行防止を実装した
  • [ ] 継続利用の場合も終了条件を定義した

一次情報