サポート終了通知: 2027 AWS 年 6 月 30 日に、 は AMS Advanced のサポートを終了します。2027 年 6 月 30 日以降、AMS Advanced コンソールまたは AMS Advanced リソースにアクセスできなくなります。詳細については、「AMS Advanced サポート終了」を参照してください。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AMS Advanced から AMS Accelerate への移行

AMS Advanced は 2027 年 6 月 30 日にサポートを終了します。この日以降、AMS Advanced の運用機能は機能しなくなり、すべてのお客様はサービスからオフボードされます。基盤となる AWS インフラストラクチャとワークロードは影響を受けません。AMS Advanced 管理レイヤーのみが削除されます。

このガイドは、移行中に何が変化し、どのようなアクションを実行する必要があるかを理解するのに役立ちます。AMS Accelerate は、インシデント管理、パッチ管理、バックアップ管理、セキュリティモニタリングを既存の AWS アカウントに直接提供し続けます。ワークロードは移行を必要とせずに維持されます。

AMS Advanced と Accelerate の違い

AMS Advanced は予防モデルを使用します。事前審査済みの自動変更 (変更タイプ) のライブラリを通じてのみ環境を変更するか、AMS エンジニアが実行する手動変更をリクエストします。このアプローチにより、リスクのある変更がインフラストラクチャに到達するのを防ぐことができますが、独自のツール (Terraform、、 AWS CloudFormation AWS マネジメントコンソールなど) を使用して直接変更を行うことはできません。

AMS Accelerate はdetect-and-respondモデルを使用します。任意のツールとワークフローを使用して直接変更を行います。Accelerate は、変更を事前にブロックするのではなく、環境を監視し、リスクのある設定に対応します。各コントロールの設定方法に応じて、自動的に修正、通知、検出結果の報告を行います。これにより、AMS が引き続き環境を保護しながら、自分のペースで運用する速度と自律性が得られます。

どちらのプランも、モニタリング、インシデント管理、パッチ管理、バックアップ管理、コスト最適化、レポート、専用の Cloud Service Delivery Manager (CSDM) と Cloud Architect (CA) サポートという同じコア運用サービスを共有しています。AMS Advanced に固有の一部の機能 (RFC システム、マネージドアクセス、エンドポイントセキュリティなど) は直接引き継がれません。次のセクションの表では、Accelerate で利用できるものと自分で管理する機能について説明します。

また、AMS オペレーションエンジニアがインスタンスにアクセスする方法を理解することも重要です。AMS Advanced では、AMS Ops は内部認証情報を使用して同じ踏み台インフラストラクチャを介して接続します。Accelerate では、AMS Ops AWS Systems Manager Session Manager は を使用して、インシデント対応、パッチ適用、または運用タスクに必要なときにインスタンスにアクセスします。これには、SSM エージェントをインスタンスで実行し、 AWS Systems Manager サービスとの通信を許可する IAM インスタンスプロファイルが必要です。AMS Accelerate は、EC2 インスタンスに SSM エージェント (および CloudWatch エージェント) をインストールして維持する自動インスタンス設定を提供します。CA は、オンボーディング中にこれを有効にするのに役立ちます。SSM エージェントをデプロイ済みで、互換性のあるインスタンスプロファイルがある場合は、追加のセットアップは必要ありません。

移行の仕組み

ワークロードは移行されません。アプリケーション、データ、インフラストラクチャは、正確な場所にとどまります。AMS Advanced からアカウントをオフボードし、Accelerate にオンボードします。これは運用上の移行であり、ワークロードの移行ではありません。

移行はアカウントごとに実行され、複数のアカウントで並行して続行できます。CSDM と CA がスケジュールを調整し、オペレーションに適した日時を選択します。移行中、AMS Accelerate コンソールと APIs は最初に有効になり、AMS Advanced コンソールと APIs は完全に削除される前に機能しなくなります。Accelerate コンソールと APIs が有効になったら、すぐに使用を開始する必要があります。AMS Advanced リソースの削除にはアカウントあたり約 2 時間かかり、その間、古い AMS Advanced インターフェイスは機能しなくなります。ワークロードは、全体を通して正常に実行され続けます。

移行を通じてお客様をサポートする方法

AMS が Accelerate で引き続き管理する機能 (モニタリング、パッチ適用、バックアップ、インシデント管理) については、AMS がユーザーに代わって移行を処理します。これには、新しい設定のデプロイ、タグの適用、アラーム設定の変換、メンテナンスウィンドウの移行が含まれます。質問や問題が発生した場合は、プロセス全体を通して AMS エンジニアにもアクセスできます。

CSDM と CA は、全体の主要な連絡先です。これらは、特定のアカウントに関連する内容を理解し、移行日を調整し、必要に応じて適切なチームとつながるのに役立ちます。2027 年 6 月 30 日までにバッファを許可するには、2027 年 3 月 31 日までに移行を完了することをお勧めします。

追加の実践的な変更が必要な場合、Operations on Demand では、毎月 20 時間のブロックでチームと一緒に作業できるスキルのある AMS エンジニアにアクセスできます。また、四半期ごと (2026 年 9 月、2026 年 12 月、2027 年 3 月) にチェックインして、進捗状況を確認し、ブロック要因に対処し、タイムラインや優先順位が変わった場合は計画を調整します。

変更点の概要

AMS Accelerate には、13 以上のリソースタイプ (Amazon RDS、Elastic Load Balancing、Amazon EFS、Amazon EKS、OpenSearch Service、Amazon FSx、NAT Gateway、VPN)、自動リソースタグ付け (Resource Tagger)、コスト最適化のための自動リソーススケジューリング (Resource Scheduler)、エージェントのデプロイのための自動インスタンス設定のモニタリングなど、AMS Advanced では利用できないいくつかの機能が含まれています。これらはオンボーディング直後に利用できます。

次の表は、 Accelerate で利用できるものと AMS Advanced との違いをまとめたものです。

EC2 インスタンスアクセス

AMS Advanced では、インスタンスアクセスは規範モデルに従います。AMS が管理する踏み台ホスト経由で接続し、認証に AMS が管理する Active Directory を使用し、RFCs。AMS は、誰がどのインスタンスにどのくらいの期間到達できるかを制御します。

AMS Accelerate では、独自のアクセス方法を選択します。規定のパスはありません。使用したり AWS Systems Manager Session Manager、企業ネットワーク経由で RDP/SSH を誘導したり、セキュリティ要件に合ったその他のアプローチを実行したりできます。

移行の一環として、AMS 踏み台ホストを削除し、Active Directory インフラストラクチャをお客様に引き渡します。既存のインスタンスはドメイン結合されたままで、AD 認証情報を使用してアクセスできます。アクセスのダウンタイムなしで検証済みです。AD が組織で機能する場合は、長期的なアクセス方法として引き続き使用することも、別のアプローチを設定するときに一時的に使用することもできます。いずれにしても、AD の信頼、ネットワーク接続、ドメイン設定は保持する必要があります。

必要な作業

既存のインスタンスでは、企業ユーザーまたはグループを AMS AD アクセスグループに追加して、永続的なアクセス権を持つようにする必要があります。AMS Advanced では、RFC プロセスによって一時的な 8 時間のアクセスウィンドウが付与されました。移行後、自動化は利用できなくなります。代わりに、ユーザーをアクセスグループの永続メンバーとして追加します。ユーザーを追加するグループと追加するツールに関するガイダンスを提供します。

ユーザーがプロビジョニングされると、AD 認証情報を使用して既存のネットワークパス (Direct Connect、VPN、または Transit Gateway) に直接接続されます。

新しいインスタンスの場合、AMS ブートストラップスクリプトは起動時に実行されなくなるため、以前は自動だった 2 つの設定が必要になりました。

アクセス管理: インスタンスにアクセスできるユーザーの所有権を取得します。AD 管理者アカウント、管理者ワークステーション、ユーザープロビジョニング用の自動化ツールが用意されています。アクセスポリシーは、永続的なグループメンバーシップであるか、独自のガバナンスツールによる時間制限付きアクセスであるか、Session Manager IAM ポリシーであるかにかかわらず、決定します。

AMS Amazon マシンイメージ (AMIs)

AMS Advanced では、AMS はサポートされているオペレーティングシステム用に毎月更新された AMIs を作成し、管理ソフトウェア、セキュリティエージェント、ドメイン参加スクリプトで事前設定されています。これらの AMIs は アカウントと共有され、変更管理システムを介して新しい EC2 インスタンスを起動するときに使用されます。

AMS AMI の本稼働は AMS Accelerate の一部ではありません。移行後、AMS は毎月の AMIs を生成またはアカウントと共有しなくなります。新しいインスタンスの起動と Auto Scaling グループ (ASG) の起動設定には、オペレーティングシステム用の標準提供 AWSの AMIs を使用します (EC2 コンソールまたは AWS AMI カタログから使用可能）。これらは定期的なセキュリティ更新 AWS で によって維持され、すべての新しいインスタンスに推奨されるベースです。起動テンプレートで AMS AMIs を参照する ASGs を使用する場合は、それらの参照を AWS AMIsまたは独自のカスタム AMIs に更新して、スケーリングイベントによって起動される新しいインスタンスがサポートされているイメージを使用していることを確認します。

既に共有されている既存の AMS AMIs は、オフボーディング中にすぐに共有解除されることはありません。ただし、2026 年 6 月 30 日より前に作成された AMIs は、2027 年 6 月 30 日に廃止されます。2026 年 6 月 30 日から 2027 年 6 月 30 日までに作成された AMIs は、2027 年 6 月 30 日から 1 年間共有され続けます。

StandardAMI が提供するもの (事前ベイク済みアプリケーション、強化された設定、組織固有のツールなど) を超えるカスタム AWS AMIs 要件がある場合は、EC2 Image Builder を使用して独自のパイプラインを構築できます。AMS でこれを管理したい場合は、Operations on Demand カタログに AMI Building and Vending サービスが含まれています。このオプションについては、CSDM にお問い合わせください。

エンドポイントのセキュリティ

AMS Advanced では、AMS は EC2 インスタンスに Trend Micro エンドポイントセキュリティをデプロイおよび管理します。これには、エージェントのインストール (インスタンスの起動ごとにブートスクリプトによって自動化）、エージェントのアクティベーション、イベントモニタリング、インシデントの作成が含まれます。AMS は、アカウント設定に応じて Deep Security Manager (DSM)、Cloud One、または Vision One プラットフォームを通じてこのインフラストラクチャを管理します。

移行の一環として、エンドポイントのセキュリティパスを選択します。Vision One (Trend Micro がホストする完全な SaaS プラットフォームで、オンプレミスの DSM インフラストラクチャを排除) に移行するか、選択した別のセキュリティベンダーに移行して、Trend Micro を続行します。いずれの場合も、エージェントのデプロイ、ライセンスの管理、アクティベーションの設定など、選択したベンダーでエージェントのライフサイクルの所有権を取得します。AMS は移行中に EPS スタックをオフボードし、ブートスクリプトはインスタンスの起動時に Trend Micro エージェントをインストールまたはアクティブ化しなくなるため、これは Accelerate に移行する前に完了する必要があります。

オプション 1: Trend Micro Vision One (SaaS) の使用を継続する

Vision One は、 と統合されるクラウドネイティブの Trend Micro プラットフォームです AWS Security Hub。AMS は、オフボーディング前に現在のプラットフォーム (DSM または Cloud One) から Vision One への移行を支援します。Vision One では、Trend Micro と直接連携してエージェントのライフサイクル管理を行います。現在 DSM を使用している場合、移行パスはシーケンシャルです。DSM から Cloud One、Cloud One から Vision One です。Vision One では、セキュリティアラートが に送信されます AWS Security Hub。 AWS Security Incident Response (SIR) にもオンボードしているお客様は、 を通じて継続的なイベントモニタリングとインシデント対応を受けることができます AWS。

オプション 2: 別のエンドポイントセキュリティソリューションを使用する

選択したエンドポイントセキュリティソリューションを選択、デプロイ、管理します。AMS はインスタンスから Trend Micro エージェントを削除し、EPS スタックをオフボードします。選択したベンダーを立ち上げて実行するのはお客様の責任です。オプションで、選択したソリューションを と統合 AWS Security Hub して SIR カバレッジを実現できます。

どちらのオプションでも、エージェントライフサイクル全体を所有し、インスタンスへのエージェントのデプロイ (独自のオートメーション、SSM ステートマネージャー、カスタム AMIs、または設定管理ツールを使用）、ベンダーライセンスとアクティベーション認証情報の維持、ベンダーのダッシュボードまたは によるイベントモニタリングの設定を行います AWS Security Hub。

モニタリングとアラーム

AMS Advanced では、アラームマネージャーはすべてのマネージド EC2 インスタンスの CloudWatch アラームを自動的に作成し、しきい値を変更するサービスリクエストを送信します。AMS Accelerate では、AMS はユーザーに代わってアラームの作成と管理を続けますが、モデルはタグ駆動型であり、AMS はモニタリングタグが適用されたインスタンスを監視し、サービスリクエストを送信 AWS AppConfig せずに を通じてアカウント内で直接しきい値をカスタマイズします。また、カバレッジは EC2 と Redshift から、Amazon RDS、Elastic Load Balancing、Amazon EFS、Amazon EKS、OpenSearch Service、Amazon FSx、NAT Gateway、VPN など、13 以上のリソースタイプに拡張されます。

必要な作業

継続性のモニタリングに手動アクションは必要ありません。AMS は、移行中に既存の EC2 インスタンスにモニタリングタグを適用し、現在のアラームのカスタマイズを Accelerate 設定形式に変換します。CA は、移行を開始する前に、翻訳された設定を確認します。

変更点

アラーム名とデフォルトのしきい値は、AMS Advanced と Accelerate で異なります (AMS Advanced のデフォルトは ~85%、 Accelerate は ~95% でアラートノイズを低減します）。特定のアラーム名を参照するダッシュボード、ランブック、またはアラートルーティングがある場合は、移行後に更新します。AMS Advanced 固有のインフラストラクチャをモニタリングする 3 つの AMS Advanced 固有のアラーム (ログエージェントのハード障害、ルートボリューム Inode 使用率、壊れたセキュアチャネル) は削除され、Accelerate に引き継がれません。移行後、モニタリングカバレッジを受信するには、新しい EC2 インスタンスにタグを付ける必要があります。AMS Resource Tagger を使用して、定義したルールに基づいてタグを自動的に適用するか、手動で適用します。

バックアップの管理

既存の復旧ポイントは変更されず、移行中もアクセスできます。バックアップカバレッジにギャップはなく、データは削除されません。必要に応じて、既存の復旧ポイントから復元を続行できます。

移行後、AMS Accelerate はマネージドプラン、スケジュール、ボールト AWS Backup を使用して を通じてリソースを保護します。バックアップスケジュールと保持期間は、現在の設定と一貫しています。アカウントの既存のバックアップ設定によっては、Accelerate は既存のボールトを再利用するのではなく、更新された名前で新しいボールトを作成する場合があります。その場合、新しいバックアップが新しいバックアップに書き込まれる間、履歴復旧ポイントは元のボールトで引き続き使用できます。

保持期間、スケジュール、ボールト設定、暗号化キーは、 AWS Backup コンソールまたは任意の infrastructure-as-code ツールから直接設定できます。いずれかのボールトでボールトロックが有効になっている場合、ロックされた復旧ポイントは設定された保持期間に従って保持されます。

必要な作業

バックアップの継続性を維持するためのアクションは必要ありません。

変更管理と設定のコンプライアンス

AMS Advanced では、変更管理システムが環境で発生する処理を制御します。事前に審査された変更タイプのライブラリから変更のリクエスト (RFCs) を送信すると、AMS がユーザーに代わって変更を実行します。自動化されていない変更の場合、AMS エンジニアは手動で変更を確認して実行します。この予防モデルにより、承認されたテスト済みの変更のみがインフラストラクチャに到達しますが、ネイティブ AWS ツール (コンソール、CLI、Terraform AWS CloudFormation) を使用して直接変更を行うことはできません。

AMS Accelerate では、任意のツールとワークフローを使用して直接変更を行います。RFC システムは Accelerate に存在しません。代わりに、AMS は設定コンプライアンスを通じて環境を保護します。これは、セキュリティと運用のベストプラクティスに照らしてリソース設定を継続的に評価する AWS Config ルールのライブラリです。これはdetect-and-respondモデルです。変更が発生する前にブロックするのではなく、AMS は適用後にリスクのある設定を検出し、制御するルールに従って応答します。

Accelerate での設定コンプライアンスの仕組み

オンボーディング中に CA でレスポンスレベルを設定し、いつでも調整できます。

対象

Accelerate には、IAM とアクセスコントロール、ネットワークと VPC セキュリティ、暗号化 (EBS、Amazon RDS、Amazon S3)、ログ記録と監査証跡の整合性、データベースとストレージの設定、サーバーレスリソースをカバーする約 87 の AWS Config ルールが含まれています。これは、AMS Advanced よりも広範囲にカバーされています。AMS Advanced では、約 24～27 のルール (SALZ または MALZ によって異なります) がデプロイされ、その多くは、顧客のセキュリティ体制ではなく AMS 内部サービス動作の適用に関連しています。新しい AWS サービスとコンプライアンス標準がサポートされるため、時間の経過とともに追加のコントロールが追加されます。

必要な作業

移行にアクションは必要ありません。AMS は Accelerate オンボーディング中に AWS Config ルールをデプロイします。CA は、使用可能なルールを順を追って説明し、各ルールのレスポンスレベルを設定するのに役立ちます。現在 AMS Advanced アカウントにカスタム AWS Config ルールがデプロイされている場合、それらは保持され、オフボーディング中に削除されません。

ガバナンスのために RFC システムに依存していたお客様にとっての変更点

組織が RFC システムをガバナンスコントロールとして使用した場合 (変更を行う前に承認ワークフローを要求するなど）、独自のツールを使用して同等のコントロールを実装する必要があります。一般的なアプローチには、アクセス許可の境界を適用するための AWS サービスコントロールポリシー (SCPs)、機密性の高い API コールの AWS CloudTrail アラート、CI/CD パイプラインまたは変更管理ツール (ServiceNow、Jira など) の承認ワークフローなどがあります。CA は、現在の RFC ベースのワークフローにマッピングされるガバナンスパターンを特定するのに役立ちます。

変更の実践的な支援が必要なお客様向けに、Operations on Demand は、熟練した AMS エンジニアを通じて 20 時間の月次ブロックで厳選された変更サポートを提供します。これは、移行期間中、直接アクセスに精通している間、またはエキスパートサポートが必要な複雑な変更に対して継続的に役立ちます。

パッチ管理

AMS Advanced では、パッチ管理は、RFC システムを介して設定されたメンテナンスウィンドウを持つ AMS パッチオーケストレーターを使用します。AMS は、パッチベースライン、スケジューリング、通知、デフォルトのメンテナンスウィンドウを管理します。カスタムメンテナンスウィンドウは、変更タイプによって作成および更新されます。

AMS Accelerate では、パッチ適用スケジュール、ベースライン、メンテナンスウィンドウは移行中も保持されます。同じタグベースのパッチ適用モデルが適用され、インスタンスには同じスケジュールで引き続きパッチが適用されます。一部の運用詳細 (通知配信、デフォルトのメンテナンスウィンドウの管理方法、変更プロセス) は変更されますが、パッチ適用動作は一貫しています。

必要な作業

移行を開始する前に、CSDM と CA はパッチイベントの通知 E メールアドレスを確認します。通知は AMS Advanced 配信モデルから Accelerate 通知フレームワークに移行されるため、適切なアドレスで受信し続ける必要があります。また、既存のパッチコンプライアンスレポート履歴を保持するかどうかも確認します。

移行中の動作

移行は、アクティブなメンテナンスウィンドウの実行外でスケジュールされます。移行ウィンドウ中にパッチは実行されません。既存のメンテナンスウィンドウ、パッチベースライン、スケジュール、OS ごとの設定は Accelerate インフラストラクチャに移行されます。メンテナンスウィンドウの名前と動作は保持されるため、運用プロセスの一貫性が保たれます。

変更点

移行後は、以下の運用の詳細が変更されます。

継続性: 移行中にパッチ適用が停止することはありません。移行は、AMS Advanced インフラストラクチャが削除される前に、メンテナンスウィンドウとベースラインが Accelerate 側で機能するように順序付けられます。問題が検出された場合は、移行を元に戻して AMS Advanced パッチ適用を復元できます。

を使用したランディングゾーンガバナンス AWS Control Tower (オプション)

マルチアカウントランディングゾーン (MALZ) のお客様の場合、AMS Advanced はマルチアカウントランディングゾーンを今日管理し、アカウントプロビジョニング、予防ガードレール、組織全体の集中ロギングと設定コンプライアンスを処理します。AMS Accelerate への移行後、ランディングゾーン管理はカスタマー管理になります。組織、アカウント、ネットワーク設定はそのままであり、運用するユーザーです。このセクションは、シングルアカウントランディングゾーン (SALZ) のお客様には適用されません。

Accelerate で一元化された自動化されたガバナンスを維持するために、 AWS は AWS Control Tower、マルチアカウント環境専用の AWSネイティブサービスを提供します。 AWS Control Tower は、自動化されたアカウントプロビジョニング、予防ガードレール、一元化された設定コンプライアンスを提供し、現在依存しているガバナンスプラクティスを継続するためのサポートパスを提供します。必要に応じて、移行エンゲージメント AWS Control Tower の一環として AMS を有効にできます。

MALZ と は、同じ基本的なマルチアカウントアーキテクチャ AWS Control Tower を共有します。MALZ 環境には、セキュリティオペレーション専用のアカウント (セキュリティアカウント) と一元的なログ記録 (ログ記録アカウント) が既にあり、これは AWS Control Tower監査アカウントとログアーカイブアカウントに直接マッピングされます。管理アカウントは両方のモデルで同じです。これらのアカウントはすでに存在するため、新しいアカウントを作成するのではなく AWS Control Tower 、インポートとビルドを有効にします。既存のログストレージ、セキュリティツール、組織構造が引き継がれます。

AWS Control Tower が提供するもの

を有効にすると AWS Control Tower、次の機能を使用できます。

AWS Control Tower には、MALZ が提供する機能を超える以下の機能も用意されています。

有効にすると AWS Control Tower、複数のコンプライアンスフレームワークにまたがるコントロールAWS Control Tower リファレンスから適用するコントロールを選択できるため、AMS Advanced で保持していた保護を一致または拡張できます。

AWS Control Tower が提供していないもの

AWS Control Tower は MALZ ネットワークを再作成しません。ネットワークアカウントは、他のアプリケーションアカウントと同様に Accelerate に移行します。Account Factory は、新しいアカウントにスタンドアロン VPC を作成できますが、アカウントをトランジットゲートウェイにアタッチしたり、MALZ のように共有 Egress および共有サービス接続を設定したりすることはありません。クロスアカウントネットワークは引き続きお客様の責任となります。

移行中に予想されること

を有効にすると、新しい組織単位を作成せずに、現在の組織とアカウント AWS Control Tower をインポートできます。既存のセキュリティアカウントとログ記録アカウントは AWS Control Tower 同等のもの (監査およびログアーカイブ) にマッピングされます。 AWS Config と AWS CloudTrail の統合はセットアップの一部として有効になり、他のサービス統合が利用可能な self-service. AWS Control Tower では、AMS が調整するアカウントで事前に AWS Config 無効にする必要があります。セットアップ後、コントロールの追加または変更はセルフサービスです。

有効にすると AWS Control Tower、AMS は MALZ AWS CloudTrail セットアップを組織の証跡に置き換えます AWS Control Tower 。これは、監査ログの構造を変更する組織全体の単一の証跡への意図的な切り替えです。

これらの違いがワークフローに影響する場合は、オプトインする前に CA に相談してください。

Operations on Demand による追加サポート

AWS Control Tower は、day-to-dayガバナンスタスク用のセルフサービスとして設計されています。OU の再構築、SCP の変更、ドリフト修復、SSO ユーザー管理、 AWS Control Tower アップグレード、Account Factory が提供するものを超えるカスタムアカウント供給パイプラインの構築など、時折のカスタマイズや 1 回限りの運用ニーズに対して、AMS Accelerate は Operations on Demand (OOD) を提供します。OOD は、長期契約なしで 20 時間の毎月のブロックで購入されます。CSDM または CA に問い合わせて、エンゲージメントの範囲を設定します。

タイムラインとサポート

2027 年 6 月 30 日のシャットダウン前にバッファを許可するには、2027 年 3 月 31 日までに移行を完了することをお勧めします。CSDM と CA は移行中の主要な連絡先であり、環境に合わせた計画を作成するのに役立ちます。

移行期間中に変更を行うサポートが必要なお客様向けに、Operations on Demand は毎月のブロックで厳選された変更サポートを提供します。

AMS は四半期ごとのチェックポイント (2026 年 9 月、2026 年 12 月、2027 年 3 月) を実施して移行の進行状況をモニタリングし、必要に応じて追加のサポートを提供します。

関連リソース