先に結論
SageMaker AIのエンドポイントをCloudFormation/CDKで更新するとき、CDKコンストラクトで更新失敗を回避する設計が実務的です。AWSの手法（同社によると）は、3つのカスタムリソースで自動的にAuto Scalingの登録解除→エンドポイント更新→再登録→ポリシー適用を行い、手動操作やロールバックのリスクを下げます。導入判断は、（1）既存のデプロイワークフローと権限分離の整合、（2）カスタムリソースが作る追加リソース（Lambda／Step Functions）の運用負荷、（3）ConfigHashなどの変更トリガ設計の可否――この三点を検証した上で限定展開してください。なお、最小運用でまずはConfigHashを試せという進め方が運用負荷を下げます。
GLOBAL AI BRIEF ・ COMPARISON
どの段階を自動化すべきか？
- STEP 011) DeregisterカスタムリソースがAuto Scalingを解除する初回は存在しない場合エラーを無視する
- STEP 022) Endpoint updateCDKがEndpointConfigやインスタンスタイプを更新するCloudFormationの通常更新がここで走る
- STEP 033) Register Scalable Target非同期プロバイダがInServiceを待って登録total_timeoutは目安で1時間
- STEP 044) Attach Scaling Policyscalable targetが問い合わせ可能になったらポリシーを適用total_timeoutは目安で15分
- STEP 05運用考慮追加されるLambda/StepFunctionsの監視を組み込む失敗時は自動停止して人が介入するワークフローへ
今回の一次情報とこの記事の焦点
一次情報はAWS Machine Learning Blogの技術記事（Orchestrating SageMaker AI endpoint auto scaling with AWS CDK、公開日：2026-10-23）です。同社によると、SageMaker AIエンドポイントの設定変更時にApplication Auto Scalingが登録されたままだとCloudFormationやCDKのデプロイが失敗する問題があるため、同社はCDK用の再登録ワークフローを提案しています。
この記事では、仕組み（何が起きるか）、コンストラクトが自動化する手順、運用上のコストとリスク、日本企業が判断すべき実務条件を具体的に説明します。出典は該当ブログ（下部にURL）で、企業発表は必ず「同社によると」で帰属しています。
問題の定義：なぜデプロイが失敗するのか
CloudFormation／CDKはエンドポイント更新とApplication Auto Scaling（スケーラブルターゲット／スケーリングポリシー）の管理を同一テンプレート内で扱うと、更新順序の競合により失敗することがあります。具体的には、エンドポイントのインスタンス構成やインスタンスタイプを変更しようとした際、既存のスケーラブルターゲットが登録されたままだとSageMaker側が更新を拒否するためです（同社によると）。
一般的な回避策としては手動でスケーラブルターゲットを解除→エンドポイント更新→再登録という手順がありますが、これは人的作業とミス、ロールバック失敗を招きます。AWSの提案はこの手順をCDKデプロイの一部として自動化することです。
AWSの提案：CDKコンストラクトがやること（高レベル）
同社によると、提案するCDKコンストラクトは次の順序で動きます：Deregister（登録解除）→Endpoint update（エンドポイント更新）→Register Scalable Target（再登録）→Attach Scaling Policy（ポリシー適用）。この順序を明示的に制御することで、CloudFormationの更新失敗を回避します。
実装上のポイントは、Register Scalable TargetとAttach Scaling Policyを非同期カスタムリソース（プロバイダのasync completionパターン）にして、エンドポイントがInServiceになるのを待ってからスケーラブルターゲット登録・ポリシー適用を行う点です。同社によると、この待機は同プロバイダのtotal_timeoutで拘束しています（後述の数値参照）。
技術的詳細：コンストラクトの構成要素
同社によると、コンストラクトは次の主要要素で構成されます。
- Deregister（同期プロバイダ）：更新前にscalable targetをderegisterする。初回デプロイで存在しない場合は例外を無視します。
- Endpoint update：既存のエンドポイント／EndpointConfigの更新をCDK側で行います。
- Register Scalable Target（非同期プロバイダ）：EndpointがInService状態になるまで待ち、scalable targetをregisterします。total_timeoutは1時間に設定されています（同社によると）。
- Attach Scaling Policy（非同期プロバイダ）：scalable targetが問い合わせ可能になるまで待ち、スケーリングポリシーを適用します。total_timeoutは15分です（同社によると）。
さらに、デプロイの再実行や構成変更を検知するために、ConfigHashというプロパティを各カスタムリソースに渡し、設定が変われば再実行される仕組みを入れています（同社によると）。
実装で発生する追加リソースと運用負荷
同社によると、開発例ではコンストラクトのデプロイによりスタック中に「3つのカスタムリソース」が作られ、プロバイダの性質上バックエンドに複数のLambda関数やStep Functionsが生成されます。ブログの実例では結果として2つのStep Functionsと12個のLambda関数が含まれたと報告されています。
これは「リソース数が増える＝運用の監査点が増える」ことを意味します。特にLambdaのログ・権限・実行時間の課金、Step Functionsの状態管理、そしてカスタムリソースのタイムアウト設計は事前に運用ルールを整備すべき箇所です。
比較表：選択肢とトレードオフ
| 方式 | 利点 | 欠点 | 向く状況 |
|---|---|---|---|
| ネイティブCloudFormation | 追加コード不要、テンプレート一貫 | 更新順序で失敗しやすい、手動介入が必要 | 小規模・設定変更が稀な環境 |
| 手動ドリブン（CLIによるderegister→update→register） | 実装が単純、即時対応可 | 人手依存、運用ミス・ロールバックリスク | 運用チームが手順を厳密に守れる場合 |
| CDKコンストラクト（本稿で解説） | 自動化で人的エラー低減、再現性あり | 追加リソース（Lambda/StepFunctions）で運用負荷増 | 頻繁にエンドポイント更新する／大規模組織 |
日本企業が導入前に検証すべき実務判断項目
導入の可否判断は単に「失敗を減らせるか」だけでなく、運用・監査・コストを含む総合評価で決めるべきです。以下は必須の確認項目です。
- 権限と責任の分離：DeregisterやRegisterを行うIAMロールの範囲を最小化する。Troubleshooting時の復旧手順に誰が関与するか定義してください。
- リソース監視：追加されるLambdaやStep Functionsのメトリクス（Error, Duration, Throttles）をダッシュボードに組み込むこと。
- デプロイのテストプラン：まずは非本番環境でConfigHash変更による再適用、タイムアウト発生、失敗時のロールバック動作を検証してください。
- コスト影響：追加Lambdaの実行回数やStep Functionsのステップ数により運用コストが増えるため、見積もりを提示してください。
導入ステップ（実務的なPoC案）
短くて確実なPoCの進め方：
- ステージングに同構成のSageMaker AIエンドポイントを用意する。
- CDKコンストラクトをデプロイし、初回は手動でのderegister→update→registerと結果を比較する。
- ConfigHashを変えて再デプロイし、自動シーケンスと監視ログ（CloudWatch）を確認する。
- 失敗ケースを作り（例：意図的にEndpointConfigを無効化）、タイムアウト時の振る舞いと復旧手順を検証する。
- 運用ドキュメントを作成し、SRE/DevOpsと稼働合意を取る。
この流れで、まずは「自動化しても運用が回る」ことを安全に確認します。削除と再登録を自動化して品質を保つという目的が満たされるかをPoCで定量化してください。
運用上の注意点と停止条件
実運用で注意が必要な点を列挙します。
- タイムアウト設計：Register側のtotal_timeoutが1時間、Attach側が15分の想定です（同社によると）。これらはスタック全体の待機時間に影響します。
- 再デプロイの競合：別プロセスが同時にEndpointを更新するとデッドロックやロールバックが発生するため、デプロイトリガを直列化する運用が望ましいです。
- ログと証跡：deregister/registerのイベントは監査ログに必ず残し、誰がいつ何を行ったか追跡できる状態にする必要があります。
- 停止条件：Lambdaのエラー率が閾値を超える、Step Functionsが一定回数失敗する、またはEndpointがFailed状態になる──これらを満たしたら自動で新しいデプロイを停止して人が介入するワークフローを用意してください。
FAQ（よくある質問）
Q1：ネイティブのCloudFormationだけではなぜ駄目なのか？
A：CloudFormationはリソースの依存関係を解決しますが、SageMaker AIの更新拒否（scalable targetが登録されたままではインスタンスタイプやDesiredInstanceCountが更新できない）というサービス側の制約により、単純なテンプレートでは順序競合が発生するためです（同社によると）。
Q2：CDKコンストラクト導入で必ず成功するのか？
A：いいえ。コンストラクトは失敗要因を減らしますが、実運用ではIAM・ネットワーク・quota（APIレート）・既存運用との整合が原因で新たな問題が出る可能性があります。まずはステージングでの十分な検証が必要です。
Q3：ConfigHashとは何を意味するか？
A：ConfigHashは、エンドポイントやオートスケーリング設定を表すハッシュ値で、これが変わるとカスタムリソースの再評価を強制します。手動変更やテンプレート差分を確実に反映するための仕組みです（同社によると）。
出典と検証範囲
出典：AWS Machine Learning Blog, “Orchestrating SageMaker AI endpoint auto scaling with AWS CDK”（公開日：2026-10-23、確認日：2026-10-26）。本記事は同社が公開した手順、設計上の注意点、実装例（プロバイダのasync completion、total_timeoutの目安、作成されるバックエンドリソースの構成など）を基に編集部が実務判断に必要な観点を整理したものです。
検証済み範囲：同社による記事本文の説明（構成、フロー、非同期プロバイダの使い方、ConfigHashの利用、実例のリソース数）を確認しました。
未検証：実際の貴社環境での動作、追加リソースの運用コスト、第三者による再現ベンチマークは本稿で未検証です。導入前にステージングでの運用試験を強く推奨します。
編集部の短い提言（実務で次にやること）
1) ステージング環境でConfigHash差分を使った再デプロイを3回以上試す。 2) 追加されるLambda/StepFunctionsを含むコスト見積りを算出する。 3) IAMロールと監査ログの権限設計をSREと合意する。これらが整わない限り、本番への一斉適用は避けてください。
FAQ補足：障害発生時の最小復旧手順（例）
1. CloudFormationのSTACKイベントを確認し、どのカスタムリソースが失敗したか特定する。
2. 失敗したリソースのLambdaログ（CloudWatch）から例外原因を抽出する。
3. 一時的に自動化を停止し（例えばConfigHashをロック）、手動でderegister→update→registerを実行してサービスを再稼働させる。
4. 原因を修正し、再度コンストラクトデプロイを行う。問題が再現する場合は、デプロイ頻度の抑制や並列デプロイの排除を検討する。
要点まとめ（導入可否を判断するための3点）
・技術的にはCDKコンストラクトによる自動化は有効（同社によると）。
・ただし追加リソースの運用コストと監査点が増えるため、組織的なSRE対応が必須です。
・まずは限定PoCでConfigHashトリガ、タイムアウト、権限スコープを検証し、運用ドキュメントを整備したうえで段階展開してください。
よくある追加質問（短答）
Q：LambdaやStep Functionsの増加はどの程度深刻ですか？
A：同社の実例では最終的に12個のLambda関数と2つのStep Functionsが含まれたと報告されています。これがすべての導入で発生するわけではありませんが、リソース管理の負荷増は現実的なリスクです（同社によると）。
Q：オンプレミス環境や厳格なガバナンス下では適用できますか？
A：原則は可能ですが、IAMやネットワーク、ログ保存の要件がクラウド標準の前提と異なる場合は、カスタムリソースの実装や権限設計を追加で調整する必要があります。
出典一覧：
確認日：2026-10-26。検証範囲は記事本文の設計・数値・実装例に限定しています。第三者による本番再現は未検証です。