第一世代のエージェント基盤は、もう店じまいを始めた——AWSがBedrock Agentsを『Classic』化した意味

エンタープライズのAIエージェント導入で、いま静かに効いてくる問いがあります——そのエージェント基盤は、何年もつのか。モデルの世代交代が話題になりがちですが、実務でより痛いのは「基盤ごと乗り換え」です。作り込んだエージェント定義、オーケストレーション、ツール接続がベンダー都合で作り直しになると、コストは一気に膨らみます。homula はエンタープライズ向けの AIエージェント・インテグレーターとして日本企業のPoC〜本番運用を支援していますが、この「基盤の寿命」を軽視した設計が、後から最も高くつくと見ています。

その懸念を裏づける動きが、2026年夏に起きました。AWS が、2023年11月に提供を開始した Amazon Bedrock Agents を 「Bedrock Agents Classic」 と改称し、2026年7月30日をもって新規顧客の受け付けを停止、既存ユーザー向けには**保守モード（maintenance mode）**へ移すと告知したのです。後継として推奨されるのは、まったく別設計の Amazon Bedrock AgentCore。第一世代の統合エージェント基盤が、登場から約2年半で"次へ進んでください"と言われた——この事実が、企業の基盤選定に突きつけるものを整理します。

何が起きたのか——事実の整理

AWS のドキュメントが示す変更点は明快です。Bedrock Agents 本体は消えるわけではありませんが、実質的に「これ以上ここに乗せないでください」という位置づけに変わりました。

ポイントは「サービス停止」ではなく「新機能を止めて後継へ誘導する」段階に入ったことです。モデルカタログが凍結されるということは、今後の新しいモデルは Classic では使えないということでもあります。AWS はまだ強制終了(EOL)の期日を公表していませんが、保守モード入りは、その基盤上での長期投資を推奨しないという明確なシグナルです（出典: Amazon Bedrock Agents Classic maintenance mode）。

なぜ「後継」は乗り換えなのか——AgentCoreは改名ではない

紛らわしいのは、AgentCore が Bedrock Agents の"新バージョン"ではない点です。AgentCore は**再設計（re-architecture）**であり、思想からして別物です。2025年10月に一般提供(GA)が始まった AgentCore は、エージェントを本番で動かすための構成要素を5つに分解して提供します。

• Runtime: フレームワーク非依存で、隔離されたmicroVM上でエージェントを実行（長時間セッション対応）
• Memory: 短期の会話文脈と長期記憶を保持
• Gateway: 社内API・SaaS・MCPサーバーなどのツールをエージェントに接続
• Identity: エージェントのアクセス制御と資格情報を管理
• Observability: 実行トレースを記録し可観測性を担保

第一世代の Bedrock Agents が「単一エージェント＋基本的なツール呼び出し」を1つのマネージドサービスに束ねていたのに対し、AgentCore は複数エージェントの協調・共有メモリ・統一ゲートウェイを前提とした部品群です（出典: Amazon Bedrock AgentCore is now generally available、Introducing AgentCore Gateway）。設計思想が変わった以上、Classic 上の資産をそのまま持ち込めるわけではありません。だからこそ AWS は「継続利用」ではなく「移行(migrate)」という言葉を使っています。

移行コストはどこに出るか——壊れるもの・残るもの

AWS の告知が親切なのは、何が影響を受けないかを明示している点です。基盤モデル・Knowledge Bases・Guardrails は影響を受けません。逆に言えば、そこに含まれないもの——エージェントの定義、アクション（ツール）連携の作り込み、オーケストレーションのロジック——が、移行で作り直しになりやすい領域です。

この非対称性は、他ベンダーの基盤にも一般化できます。エージェント基盤を「乗り換え耐性」の観点で分解すると、おおむね次のように分かれます。

つまり、乗り換えで痛むのは「ツール接続」「ガバナンス」「エージェント定義」の3層です。そして、このうち上2つはやり方次第で守れる——ここが設計の勝負どころになります。

「固定すべきもの」と「捨ててよいもの」を切り分ける

エージェント領域は技術移行が速く、AWS の事例が示すように基盤の世代交代は2〜3年で来ます。だとすれば、企業の戦略は「最強の基盤を1つ選ぶ」ことではなく、基盤が入れ替わっても残る資産を、基盤の外に置くことです。具体的には次の3点です。

1. ツール層を標準プロトコルで固定する。 社内システムやSaaSへの接続を、ベンダー独自のアクション定義ではなく MCP（Model Context Protocol） のような標準で持てば、基盤を乗り換えてもツール層はそのまま再利用できます。AgentCore の Gateway が MCP サーバー接続を前面に出しているのは、この方向性の裏返しです。
2. ガバナンスを制御面として分離する。 承認フロー・監査ログ・権限（RBAC）・DLP を特定の基盤の内蔵機能に依存させると、移行のたびに統制がリセットされます。エージェントの手前に独立した「制御点」を置き、どの基盤で動いても同じポリシーが効く形にします。
3. 業務ロジックをベンダー非依存に保つ。 何を・どの順序で・どんな判断基準で実行するかという業務知識は、プロンプトやコードにベタ書きせず、移植可能な形（仕様・スキル・ワークフロー定義）で管理します。

この3つを外側に持てるかどうかで、次の「Classic化」が来たときの被害額が桁で変わります。

homula の観点——統合層と統制層を、基盤から切り離す

homula がエンタープライズ支援で一貫して勧めているのは、まさにこの「基盤から独立した統合層・統制層」の設計です。

• ツール接続は Agens で標準化する。 Agens は MCP を活用したエンタープライズ向け統合プラットフォームで、200以上のツールと構築ゼロで接続します。接続をこの層に集約しておけば、下のエージェント基盤が Bedrock でも AgentCore でも別ベンダーでも、ツール資産は載せ替えられます。
• 統制は Agens Control に寄せる。 承認フロー・DLP・5年分の監査ログ・RBAC を、エージェント基盤の外側の制御面として持ちます。基盤を移行しても、誰が何をできるか・どこまで監査が残るかという統制は連続します。
• 業務の型は内製化とセットで残す。 homula の AIエージェント・ブートキャンプは、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で完結させ、業務ロジックを"自社の資産"として言語化します。基盤に依存しない形で型を持てば、乗り換えは「実行先の差し替え」で済みます。

要は、**移り変わる部分（実行基盤・モデル）**と、**長く残すべき部分（ツール接続・ガバナンス・業務知識）**を最初から分けて設計しておく。この一手が、基盤ライフサイクルの短さを"想定内"に変えます。「実行基盤はどこで動かすのか」という論点はマネージド・エージェント・ランタイムでも扱いましたが、本稿の含意は、その実行基盤すら数年で入れ替わる前提で上位層を組む、ということです。

まとめ

AWS が第一世代の Bedrock Agents を Classic 化し AgentCore へ誘導した動きは、単なる一社の製品更改ではありません。エンタープライズ向けエージェント基盤は、2〜3年で世代交代するという現実を、業界最大手が身をもって示した出来事です。

• 事実: Bedrock Agents（2023年11月）→ Classic 化、2026年7月30日で新規受付停止・保守モード、AgentCore へ移行推奨。
• 教訓: 基盤は入れ替わる前提で、ツール接続・ガバナンス・業務ロジックを基盤の外に置く。
• 実務: MCP でツール層を標準化し、承認・監査を制御面として分離し、業務の型を内製資産として残す。

「どの基盤が最強か」を追い続けるより、「どの基盤に移っても資産が残る構え」をつくる方が、長期のTCOでは効きます。次のClassic化は、あなたのベンダーでも起こり得ます。

---

基盤の乗り換えに強い統合層・統制層をどう設計するか、自社の状況に即して整理したい方は、まずは気軽にご相談ください。

無料相談を予約する

Agens Controlで承認・監査・ガバナンス設計を見る

MCP活用支援の詳細を見る