Amazon Bedrockのモデルライフサイクルを理解する

Amazon Bedrock は、より優れた機能、精度、安全性を備えた新しいファウンデーションモデル（Foundation Model: FM）のバージョンを定期的にリリースしています。Amazon Bedrock 上で構築された AI アプリケーションの効果的な計画と管理には、モデルのライフサイクルを理解することが不可欠です。アプリケーションを移行する前に、Amazon Bedrock コンソールまたは API を通じてこれらのモデルをテストし、そのパフォーマンスと互換性を評価することができます。

この投稿では、Amazon Bedrock における FM の移行を管理する方法を示し、モデルが進化しても AI アプリケーションが稼働し続けることを保証します。3つのライフサイクル状態、新しい拡張アクセス機能を用いた移行計画の立て方、そして中断なくアプリケーションを新しいモデルへ移行するための実践的な戦略について解説します。

Amazon Bedrock のモデルライフサイクルの概要

Amazon Bedrock で提供されるモデルは、以下の 3 つの状態のいずれかに存在します：Active（アクティブ）、Legacy（レガシー）、または End-of-Life (EOL)（サポート終了）。現在のステータスは、Amazon Bedrock コンソールおよび API 応答の両方で確認できます。例えば、GetFoundationModel または ListFoundationModels を呼び出す際、応答内の modelLifecycle フィールドにモデルの状態が表示されます。

以下の図は、各モデル状態に関する詳細を示しています。

状態の詳細は以下の通りです：

• ACTIVE（アクティブ） – アクティブなモデルは、プロバイダーからの継続的なメンテナンス、アップデート、およびバグ修正の対象となります。モデルがアクティブ状態にある間、InvokeModel や Converse などの API を通じて推論に使用したり（サポートされている場合）、カスタマイズを行ったり、AWS Service Quotas を通じてクォータの増額を申請したりすることができます。

• LEGACY（レガシー） – モデルプロバイダーがモデルをレガシー状態に移行する場合、Amazon Bedrock は EOL（サポート終了）日付の少なくとも 6 か月前に顧客に通知し、新しいまたは代替モデルへの移行を計画・実行するための十分な時間を提供します。レガシー期間中、既存の顧客はモデルを引き続き使用できますが、新規顧客はアクセスできない場合があり、15 日以上モデルを呼び出さない場合、既存の顧客も非アクティブなアカウントでのアクセスを失う可能性があります。組織は注意すべき点として、モデル単位によるプロビジョニング済みスループットの新規作成が利用不可となり、モデルのカスタマイズ機能に制限がかかる可能性があることを認識してください。2026 年 2 月 1日以降に EOL 日付が設定されているモデルについては、Amazon Bedrock はレガシー状態内に追加フェーズを導入します：

公開拡張アクセス期間 – モデルがレガシー状態に少なくとも 3 か月間留まった後、この拡張アクセスフェーズに入ります。アクティブなユーザーは EOL まで少なくともさらに 3 か月間、引き続きこれを使用できます。拡張アクセス期間中、AWS Service Quotas を通じたクォータ増額の申請は承認されない見込みであるため、モデルがこのフェーズに入る前に容量ニーズを計画してください。この期間中、価格が調整される場合があります（以下の「拡張アクセス中の価格」を参照）、顧客には移行日付および変更事項に関する通知が届きます。

• END-OF-LIFE（EOL、サポート終了） – モデルが EOL 日付に達すると、EOL リストで特に注記されていない限り、すべての AWS リージョンにおいて完全にアクセスできなくなります。EOL モデルに対する API 要求は失敗し、顧客とプロバイダーの間で継続的なアクセスに関する特別な取り決めがない限り、ほとんどの顧客にとって利用不可となります。EOL への移行には顧客の積極的な対応が必要であり、移行は自動的には行われません。組織は、EOL 日付到来前に代替モデルを使用するようにアプリケーションコードを更新する必要があります。EOL に達すると、モデルはほとんどの顧客にとって完全にアクセスできなくなります。

Amazon Bedrock でモデルが公開されると、公開後少なくとも 12 か間は利用可能であり、EOL 前にレガシー状態に少なくとも 6 か間留まります。このタイムラインは、顧客が焦らずに移行を計画することを支援します。

拡張アクセス期間中の料金

拡張アクセス期間中、モデルプロバイダーによって料金が調整される場合があります。料金の変更が予定されている場合、最初のレガシーアナウンス時およびその後の変更が発効する前に通知が行われるため、予期せぬ遡及的な値上げが発生することはありません。モデルプロバイダーと既存のプライベートな価格契約を結んでいる顧客、またはプロビジョニングスループットを使用している顧客は、拡張アクセス期間中も現在の価格条件の下で運用を続けます。これにより、モデルプロバイダーと特定の取り決めをしている顧客や、プロビジョニングされた容量に投資した顧客が、価格変更によって予期せぬ影響を受けることがないように保証されます。

モデル状態変更に関するコミュニケーションプロセス

モデルプロバイダーがモデルをレガシー状態に移行する際、顧客はモデルのEOL（サポート終了）日付の6ヶ月前に通知を受け取ります。このプロアクティブなコミュニケーションアプローチにより、モデルがEOLになる前に顧客が移行戦略を計画し実行するための十分な時間を確保できます。通知には、非推奨となるモデルの詳細、重要な日付、拡張アクセスの利用可否、およびモデルがEOLになる時期に関する情報が含まれます。AWSは、これらの重要な通信が適切な関係者に確実に届くよう、以下の複数のチャネルを使用します。

• メール通知
• AWS Health Dashboard
• Amazon Bedrockコンソール内のアラート
• APIを通じたプログラムmaticアクセス

これらの通知を受け取れるようにするには、アカウントの連絡先メールアドレスを確認し、設定してください。デフォルトでは、通知はアカウントのルートユーザーのメールと代替連絡先（運用、セキュリティ、および請求）に送信されます。AWS アカウントページの「代替連絡先」セクションで、これらの連絡先を確認および更新できます。追加の受信者や配信チャネル（Slack やメール配布リストなど）を追加するには、AWS ユーザー通知コンソールにアクセスし、AWS 管理の通知サブスクリプションを選択して、配信チャネルとアカウント連絡先を管理してください。期待される通知が届かない場合は、これらの設定でメールアドレスが正しく構成されていること、および health@aws.com からの通知メールがメールプロバイダーによってフィルタリングされていないことを確認してください。

移行戦略とベストプラクティス

新しいモデルへの移行時には、アプリケーションコードを更新し、サービスクォータが予想されるボリュームを処理できることを確認してください。事前に計画を立てることで、最小限の混乱でスムーズに移行できます。

移行スケジュールの計画

モデルがレガシー状態に入ったらすぐに計画を開始してください：

• 評価フェーズ – レガシーモデルの現在の使用状況を評価します。これには、そのモデルに依存しているアプリケーション、典型的なリクエストパターン、およびアプリケーションが依存する特定の動作や出力が含まれます。

• 調査フェーズ – 推奨される置換モデルを調査し、その機能、レガシーモデルとの違い、アプリケーションを強化できる新機能、および対象リージョンでの利用可能性を理解します。APIの変更とドキュメントを確認してください。

• テストフェーズ – 新モデルで綿密なテストを実施し、モデル間のパフォーマンス指標を比較します。これにより、アプリケーションコードやプロンプトエンジニアリング（prompt engineering）に必要な調整を特定できます。

• 移行フェーズ – フェーズ型デプロイメント（phased deployment）アプローチを使用して変更を実装します。移行中のシステムパフォーマンスを監視し、ロールバック（rollback）機能を維持してください。

• 運用フェーズ – 移行後、新モデルでアプリケーションが期待どおりに動作していることを確認するため、アプリケーションとユーザーフィードバックを継続的に監視します。

技術的な移行手順

移行を徹底的にテストしてください：

• API リファレンスの更新 – 新規モデル ID を参照するようにアプリケーションコードを変更します。例えば、anthropic.claude-3-5-sonnet-20240620-v1:0 から anthropic.claude-sonnet-4-5-20250929-v1:0、あるいはグローバルなクロスリージョン推論用エンドポイント global.anthropic.claude-sonnet-4-5-20250929-v1:0 への変更などです。新しいモデルのベストプラクティスに従ってプロンプト構造を更新してください。より詳細なガイダンスについては、Amazon Bedrock における Anthropic の Claude Sonnet 3.x から Claude Sonnet 4.x への移行に関するドキュメントを参照してください。

• クォータ増分のリクエスト – 完全な移行に先立ち、必要に応じて AWS Service Quotas コンソールを通じて増分をリクエストし、新規モデルに対して十分なクォータがあることを確認してください。

• プロンプトの調整 – 新世代モデルは、同じプロンプトに対して異なる応答を示す場合があります。新しいモデルの仕様に合わせてプロンプトを見直し、最適化してください。また、Amazon Bedrock のプロンプトオプティマイザーなどのツールを使用して、対象モデル向けにプロンプトを書き換える支援を受けることもできます。

• 応答処理の更新 – 新規モデルが異なる形式や特性を持つ応答を返す場合、それに対応して解析および処理ロジックを更新してください。

• トークン使用量の最適化 – 新世代モデルの効率改善を活用するため、トークン使用パターンを見直し最適化してください。例えば、プロンプトキャッシングをサポートするモデルを使用すれば、呼び出しのコストとレイテンシを削減できます。

テスト戦略

綿密なテストは、成功する移行にとって不可欠です：

• 並行比較 – レガシーモデルと新モデルの両方に対して同じリクエストを実行し、出力を比較してアプリケーションに影響を与える可能性のある差異を特定します。本番環境では、シャドウテスト（既存モデルとは別にエンドユーザーに影響を与えずに新モデルにも重複リクエストを送信する手法）を検討してください。このアプローチにより、完全な移行前にモデルのパフォーマンス、レイテンシ、エラーレート、その他の運用要因を評価できます。また、ユーザーへの影響を評価するために A/B テストを実施し、新モデルにライブトラフィックの制御された割合をルーティングしながら、ユーザーエンゲージメント、タスク完了率、満足度スコア、ビジネス KPI などの主要指標を監視します。

• パフォーマンステスト – レスポンス時間、トークン使用量、その他のパフォーマンス指標を測定し、新モデルがレガシー版と比較してどのように動作するかを理解します。ビジネス固有の成功指標を検証します。

• 回帰テストおよびエッジケーステスト – 新モデルにおいても既存の機能が期待どおりに動作し続けることを確認します。特に、モデルが困難なシナリオをどのように処理するかにおける差異を引き起こす可能性のある、異常または複雑な入力に注意深く対応してください。

結論

Amazon Bedrock のモデルライフサイクルポリシーは、FM（大規模言語モデル）の進化を管理するための明確なステージを提供します。移行期間には拡張されたアクセスオプションが用意されており、ファインチューニング済みモデルに関する規定により、イノベーションと安定性のバランスを取ることができます。

AWS Health ダッシュボードを通じてモデルのステータスに関する情報を把握し、モデルが Legacy（レガシー）状態に移行する際に移行計画を立て、新しいバージョンを十分にテストしてください。これらのガイドラインは、より優れた機能を持つ新モデルを活用しながら、AI アプリケーションの継続性を維持するのに役立ちます。

さらに質問や懸念がある場合は、AWS チームまでお問い合わせください。最新の FM（大規模言語モデル）技術の恩恵を継続的に受けられるよう、スムーズな移行をサポートし、お客様の成功をお手伝いします。

継続的な学習や実装サポートについては、包括的なガイドと API リファレンス を含む公式の AWS Bedrock ドキュメント をご参照ください。また、AWS Machine Learning ブログ や AWS Architecture Center を訪れ、実際のケーススタディ、移行のベストプラクティス、モデルライフサイクル管理戦略の最適化に役立つ参照アーキテクチャを確認してください。

著者について

imageSaurabh Trikande氏は、Amazon BedrockおよびAmazon SageMaker Inferenceのシニアプロダクトマネージャーです。AIの民主化という目標に情熱を注ぎ、顧客やパートナーとの協働を重視しています。複雑なAIアプリケーションのデプロイメント、マルチテナントモデルを用いた推論（inference）、コスト最適化、そして生成AIモデルのデプロイメントをより身近なものにするための核心的な課題に取り組んでいます。余暇には、ハイキング、革新的なテクノロジーの学習、TechCrunchのフォロー、そして家族との時間を楽しんでいます。

imageMelanie Li氏（PhD）は、オーストラリア・シドニーを拠点とするAWSのシニアジェネレーティブAIスペシャリストソリューションアーキテクトです。最先端のAI/MLツールを使用してソリューションを構築するよう顧客をサポートすることに注力しています。APJ地域全体で複数のジェネレーティブAIイニシアチブに積極的に携わり、大規模言語モデル（LLM）の活用を進めてきました。AWS入社以前は、金融および小売業界でデータサイエンスの役割を担っていました。

imageDerrick Chooは、AWSのシニアソリューションアーキテクトであり、クラウド採用、AI/ML（人工知能・機械学習）、および生成AIソリューションを通じて企業のデジタルトランスフォーメーションを加速させています。フルスタック開発とMLが専門であり、フロントエンドインターフェース、IoT（Internet of Things：モノのインターネット）アプリケーション、データ統合、MLモデルを含むエンドツーエンドのソリューション設計に携わっており、特にコンピュータビジョンとマルチモーダルシステムに焦点を当てています。

imageJared Deanは、AWSのプリンシパルAI/MLソリューションアーキテクトです。Jaredは業界横断的な顧客と協力し、効率性を向上させる機械学習アプリケーションの開発に取り組んでいます。彼はAI、テクノロジー、そしてBBQ（バーベキュー）に関心があります。

imageJulia Bodiaは、Amazon Bedrockのプリンシパルプロダクトマネージャーです。

imagePooja Raoは、AWSのシニアプログラムマネージャーであり、クォータおよびキャパシティ管理をリードし、Bedrock Go-To-Marketチームのビジネス開発をサポートしています。仕事以外では、読書、旅行、家族との時間を過ごすことを楽しんでいます。