こんにちは！AWS MGNの名前変更ニュースを見て、初めて社内勉強会をやったのはCloudEndureだったなぁと懐かしんでいるSREチームの佐藤です。
AWS Healthの通知をトリアージしよう！
Healthの通知はさまざまな種類があり、重要度も様々です。
例えば、RDSのメジャーバージョンアップに関する通知の重要度は高いですが、CloudShellのデータが削除される通知の重要度は比較的低いと言えます。
また、Healthの通知件数は非常に多く、確認漏れからヒヤリハットが発生することも少なくありません。
そこで、Healthの通知をトリアージするための方法を紹介します。
（緊急度を判別し、通知先のSlackチャネルを分ける）
緊急度の判別
自分の中で無意識に判別していましたが、緊急度の定義や判別の仕方を言語化していきましょう。
緊急度の定義
緊急度は、以下のように分けられると考えます。
あくまで私の考えですので、異論は認めます。
| 緊急度 | 定義 | 例 |
|---|---|---|
| Black | 1か月以上かけて、ベンダーを含むプロジェクトとして対応が必要なもの（サービス停止を伴う） | RDSのメジャーバージョンアップ |
| Red | サービスの停止は伴わないが、影響調査などの対応を必要とするもの、また、期限があるもの | Amazon CloudWatch クロスアカウントクロスリージョンのサービスロールへの移行 |
| Yellow | 現状サービスや運用への影響はないが、対応は必要とされるもの | Lambdaのランタイムサポート廃止 |
| Green | 特段影響がないもの | CloudShellのデータ削除期限 |
判別の仕方
緊急度の判別にはBedrock Flowを使用します。
（Step Functionsと迷いましたが、使ってみたかったので、Bedrock Flowを採用）
問題はプロンプトをどうするかですが、こういう時に最適なサービスがこないだ出たじゃないか！
そう！Bedrock Advanced Prompt Optimizationです！
Bedrock Advanced Prompt Optimizationでプロンプトを作成する
直近のHealthの通知情報と正解データの組み合わせを作成します！
正解データは、筆者が独断と偏見でつけたものです。
もちろんサンプルが多ければ多いほどいいです。
| 通知情報 | 正解データ |
|---|---|
| (Aggregate) Health Event: AWS SDK PLANNED LIFECYCLE EVENT in us-east-1 on account 123456789123. - impacting 20 account(s) in the us-east-1 region ・・・ | YELLOW |
| [要対応] Amazon CloudWatch クロスアカウントクロスリージョンのサービスロールへの移行 ・・・ | RED |
| (Aggregate) [対応が必要な場合があります] 最終通知： Lambda ListTags の部分的な認証の変更 ・・・ | RED |
| [Notification] Upcoming routine retirement of your AWS Elastic Container Service tasks running on AWS Fargate beginning ・・・ | YELLOW |
| (Aggregate) [アクションが必要です] Amazon RDS MySQL 8.0 は、2026 年 7 月 31 日に標準サポートを終了する予定です ・・・ | RED |
| (Aggregate) [アクションが必要] Amazon RDS Performance Insights コンソールの廃止時期が 2026 年 6 月 30 日まで延長されました ・・・ | YELLOW |
| (Aggregate) [要対応] Bedrock モデル廃止のお知らせ – Claude 3.5 Sonnet v1 ・・・ | BLACK |
| 「Billing and Cost Management」コンソールの [Payments] ページでは、2026年8月19日より CloudTrail のイベントソースおよびイベント名が更新され、 ・・・ | GREEN |
| [要対応] 2026 年 6 月 12 日までに Amazon Redshift S3 監査ログバケットポリシーを更新してください ・・・ | RED |
| Your AWS CloudShell data is scheduled for deletion on ・・・ | GREEN |
| (Aggregate) [お知らせ] Amazon Inspector のマルチクラウドの検出結果と Security Hub CSPM について ・・・ | YELLOW |
| (Aggregate) [Notification] Route 53 Domains Pricing Changes ・・・ | GREEN |
| [対応が必要な場合があります] 2026 年 6 月 1 日から、Professional サブスクライバー向けにデータセットの参照と Q&A アクセスを提供開始 ・・・ | GREEN |
| Your certificate is renewed Greetings from Amazon Web Services, ・・・ | GREEN |
Bedrock Advanced Prompt Optimizationのテンプレートは以下のようにします。
前の記事でも書きましたが、jsonl形式である必要があります。
{
"version": "bedrock-2026-05-14",
"templateId": "health-triage",
"promptTemplate": "{{health_event}}を緊急度に基づき`BLACK`/`RED`/`YELLOW`/`GREEN`の4つに分類してください。判定基準は次の通りです。Black=1か月以上かけてベンダーを含めプロジェクトとして対応が必要なもの（サービス停止を伴う。例：RDSのメジャーバージョンアップ）、Red=サービス停止は伴わないが影響調査などの対応が必要で期限があるもの（例：Amazon CloudWatchクロスアカウント・クロスリージョンのサービスロールへの移行）、Yellow=現状サービスや運用への影響はないが対応が必要なもの（例：Lambdaのランタイムサポート廃止）、Green=特段影響がないもの（例：CloudShellのデータ削除期限）。",
"evaluationSamples": [
{
"inputVariables": [
{
"health_event": "(Aggregate) Health Event: AWS SDK PLANNED LIFECYCLE EVENT in us-east-1 on account 123456789123. - impacting 20 account(s) in the us-east-1 region ・・・ "
}
],
"referenceResponse": "Yellow"
},
{
"inputVariables": [
{
"health_event": "[要対応] Amazon CloudWatch クロスアカウントクロスリージョンのサービスロールへの移行 ・・・ "
}
],
"referenceResponse": "RED"
},
・・・
]
}
これをもとに、プロンプトを生成します。
生成されたプロンプトは以下のようになりました！
以下のAWS Healthイベントを`BLACK`/`RED`/`YELLOW`/`GREEN`の4つに分類してください。
**出力形式：分類ラベル（BLACK/RED/YELLOW/GREEN）のみを1単語で回答してください。説明・理由・箇条書き・見出し・推奨アクションは一切不要です。**
---
**判定は以下のデシジョンツリーに従い、Step 1から順に評価し、最初にYesとなったステップのカテゴリを選択してください：**
**Step 1 → BLACK**: 以下のいずれかに該当するか？
- 対応作業中にサービス停止・DBインスタンス再起動・ダウンタイムが発生する（例：OSアップグレード、DBメジャーバージョンアップ、OSインプレースアップグレード）
- 対応完了しない場合、将来的にAPIコール・サービス呼び出しが完全に失敗するようになる（例：モデルIDへのリクエストが失敗、エンドポイントが廃止）
- ベンダー・複数チームを含む1ヶ月以上のプロジェクト対応が必要（例：Windowsサーバーのバージョン移行）
→ 該当すれば **BLACK**
**⚠️ Step 2に進む前に必須チェック（GREEN優先ルール）：**
必要な作業が「SSMエージェント・CloudWatchエージェント等のエージェント更新」および/または「IAM権限の追加」のみである場合 → **即座にGREENを選択し、Step 2以降の評価をスキップする**。期限・緊急性・「アクションが必要」等の文言が含まれていてもこのルールは適用される。
- **⚠️ 重要な除外条件（このルールはGREENに分類しない）**：IAM権限の追加が「AWSサービス側のAPI仕様変更・認証動作変更・許可リスト削除」によって強制されており、かつ対応しない場合に既存のAPI呼び出しや機能が失敗・動作しなくなる場合は、GREEN優先ルールを適用しない。この場合はStep 2（RED）を評価する。
- 例（RED・GREENではない）：「GetFunction APIがタグデータを返すには lambda:ListTags 権限が必要になります。2026年7月7日以降、許可リストから削除します。対応しない場合、GetFunction APIのタグデータが返されなくなります」→ IAM権限追加が必要だが、AWS側のAPI認証変更が原因で既存ワークフローが壊れる → **RED**
- 例（GREEN）：「SSM Run CommandのためSSM Agentを最新バージョンに更新し、IAM権限（ssmmessages:*）を追加してください。2026年6月16日以降対応しない場合…」→ 作業がエージェント更新＋IAM権限追加のみ → **GREEN**
- 例（GREEN）：「SSM Agentを3.x以上に更新してください。期限：〇月〇日」→ **GREEN**
**Step 2 → RED**: 以下のいずれかに該当するか？（※ Step 1の条件を先に完全に確認した上で、該当しない場合のみStep 2を評価する）
- **【重要・Step 2評価不要】必要な作業がエージェント更新・IAM権限追加のみである場合は、Step 2より前のGREEN優先ルールが適用される。この行に到達した場合はStep 2評価対象外であり、GREENを選択すること。**
- **【AWSによる自動実行通知のREDパターン】**：ユーザーが期限内に対応しない場合AWSが自動で強制変更を実施し、料金ペナルティまたは意図しない設定変更が発生する通知（例：RDSサポート終了後のAWSによる自動メジャーバージョンアップグレードと延長サポート料金発生）→ ユーザーの必要作業はバージョン選択や設定変更のみでダウンタイム作業を自らは行わない場合はRED。
- 現在サービス・運用に影響が出ている、またはセキュリティ上の緊急対応が必要
- 既存の動作設定・ロール・APIパスの変更が必要で、明確な期限がある（例：サービスロールへの移行）
- **注意：アップグレード作業自体にダウンタイム・DB再起動が伴う場合は、期限があってもREDではなくStep 1のBLACKを選択する。**
→ 該当すれば **RED**
**Step 3 → YELLOW**: 以下のいずれかに該当するか？
- 現時点でサービス・運用への影響はないが、コンソール機能・UI・**ランタイム・SDK・ライブラリ・クライアントライブラリ**など周辺機能の廃止や変更に対する対応が将来必要（例：コンソール廃止、ランタイムサポート終了、**SDKバージョンのサポート終了**、クライアントライブラリのEOL）
- **重要パターン**：「既存アプリケーションは引き続き動作するが、SDKは今後セキュリティパッチ・バグ修正を受けない」→ 現在は動作しているが将来の移行が必要 → **YELLOW**（GREENではない）
- 例（YELLOW）：「AWS SDK for Java 1.x は2025年12月31日にサポート終了。既存アプリケーションは動作を続けるが、セキュリティパッチは提供されなくなる」→ **YELLOW**
- 例（GREEN × 誤り）：上記のSDK EOL通知をGREENと分類するのは**誤り**。「動作継続」の文言はYELLOWをGREENに変えない
- **プラットフォームバージョン・タスク・インスタンスのリタイアメント通知**（例：Fargate プラットフォームバージョン改訂によるタスク退役、EC2リタイアメント）。通知文に「no action required」「対応不要」と記載されていても、リタイアメント・廃止が伴う場合はYELLOW。
- **現在のツール・コンソール・APIで特定のデータや検索結果が今後表示されなくなる、または別ツールでのみアクセス可能になる変更**（例：Security Hub CSPMで新しいInspectorマルチクラウド検出結果が表示されない）
- **現在は正常動作しているが設定が非推奨・冗長構成でない状態であり、AWSが対応を推奨している**（例：VPN接続が片方のトンネルのみ使用中でAWSが両トンネル有効化を推奨）
→ 該当すれば **YELLOW**
**Step 4 → GREEN**: 上記いずれにも該当しない場合
- 例：証明書の自動更新完了通知、情報提供のみの通知、既存運用に影響のない新機能追加
- **GREENとYELLOWの境界（重要）**：「既存アプリ・機能は動作し続ける」という文言だけではGREENにならない。SDKのEOL・ランタイム廃止・ライブラリのサポート終了を伴う場合は、動作継続の記述があってもYELLOW。GREENは「将来的にも何のアクションも一切不要」な純粋な情報通知のみ。
- 例：対応がエージェント更新やIAM権限追加のみで、現在サービス影響なし・期限も遠い
- 例：新機能の展開通知で「ほとんどのユーザーは何もする必要なし」と明記されている
- 例：非アクティブリソースのデータクリーンアップ通知（ログインするだけで防げる軽微な対応）
- 例：CloudTrailイベント名・イベントソースの変更通知（監視スクリプト・ログパーサーの任意更新のみ、サービス本体への影響なし）→ **GREEN**（YELLOWではない。CloudTrailのメタデータ変更であり、サービス廃止・ランタイム終了・プラットフォームリタイアメントではない）
→ **GREEN**
---
**重要な判定ルール：**
**【BLACK vs RED の優先順位】**
- Step 1（BLACK）の条件を満たす場合、期限や料金ペナルティが記載されていてもBLACKを選択する。「期限＋料金ペナルティ＋アップグレード作業でDB再起動が発生」という組み合わせはBLACKであり、REDではない。
- 例（BLACK）：「RDS for Oracle の OS アップグレード（必須）。アップグレード中にDBインスタンスが再起動される」→ ダウンタイムが伴うためBLACK。
- 例（BLACK）：「Windows Server のインプレースアップグレード。作業中サービス停止が発生する」→ BLACK。
- 例（RED）：「RDS MySQL 8.0 は2026年7月31日に標準サポート終了。期限内に対応しない場合、AWSが自動でメジャーバージョンアップグレードを実施し、延長サポート料金が発生する。アップグレード自体はAWSが自動実行するため、ユーザーは設定変更・バージョン選択のみを期限内に行う必要がある」→ AWSによる強制自動アップグレードの通知であり、ユーザーの必要作業は設定選択のみ、かつ明確な期限あり → RED。
- 例（RED）：「サービスロールを新ロールに移行してください。期限は〇月〇日」→ 設定変更のみでダウンタイムなし、かつ明確な期限あり → RED。
**【GREEN vs YELLOW vs RED の境界】**
- 「将来のアップグレード作業にダウンタイムが伴う」場合はBLACK（将来予定でも対応作業自体がサービス停止を伴えばBLACK）
- 「期限まで余裕がある」「技術的に簡単な作業」であってもStep 1の条件を満たせばBLACK
- コンソール・UIのみの廃止でサービス本体への影響がない場合はYELLOW（REDではない）
- **単純なエージェント更新やIAM権限追加のみで対応完了する場合は、期限が記載されていてもGREEN**（例：SSM Agentを最新版に更新するだけで対応完了、現時点でサービス影響なし）。期限の存在だけではREDにならない。対応内容がエージェント更新・IAM権限追加のみであればGREEN。ただし、そのIAM権限追加がAWSサービス側のAPI仕様変更・認証変更によって強制されており、対応しないと既存機能が壊れる場合はGREENではなくREDを選択する（例：AWS APIの認証動作変更により明示的な権限が必要になり、期限内に対応しないと既存ワークフローが失敗する通知）。
- **新機能の追加・拡張で既存ユーザーの操作に変化がなく、対応は任意の場合はGREEN**（例：新しいユーザー種別へのデータセットアクセス拡張。既存運用は変わらず、管理者がアクセス制限したい場合のみオプションで対応）
- **イベントの本文に「何もする必要はありません（ほとんどの場合）」「アクション不要」と明記されている場合でも、以下に該当する場合はGREENではなくYELLOWを選択する：プラットフォームバージョン改訂・タスクリタイアメント・ランタイム廃止・設定非推奨・データアクセス変更を伴う場合。「アクション不要」の文言は変更の性質を上書きしない。純粋に情報提供のみで廃止・変更・リタイアメントを一切伴わない場合のみGREEN。**
- **コンソール・APIで特定のデータや検索結果が今後表示されなくなる、または別ツールでのみアクセス可能になる変更はYELLOW**（例：Security Hubの特定画面でInspector検索結果が表示されなくなる）
- 非アクティブリソースのデータ削除通知（例：CloudShellホームディレクトリ削除）は、サービス本体への影響がなく対応が簡単な場合はGREEN
---
{{health_event}}
やっぱこのサービス相当便利ですね！
正解データが増えたら自動的にプロンプトを生成しなおす（CI/CDのプロンプトエンジニアリング版）運用とか作ったら便利そうですね！
修正後のスコアが満点（1.0）ではなかったので、詳細を確認したところ、Bedrock モデル廃止のお知らせ – Claude 3.5 Sonnet v1のみ、修正後もスコアが悪かったです。アプリケーションで予期せぬエラーが発生する可能性があり、ベンダーにアプリケーション改修を依頼しなければならない可能性のある通知なので、個人的にはBLACKにしたかったですが、RDSのメジャーバージョンアップと同列かと言われると微妙な気もするので、一旦は良しとします。
左がオリジナルのスコア、右が修正後のスコア
Bedrock Flowの作成
プロンプトができたら、Bedrock Flowを作成します。
デフォルトのフローのプロンプトを編集します。
メッセージに上記で作成したプロンプトを入力します。
保存してテストしてみましょう！
サンプルイベントを入力値にして実行してみました。
GREENが返ってきてますね！よさそうです！
全体の構成
今回は、トリアージにフォーカスしているので、Lambdaなどの他の構成要素は割愛しますが、全体は以下のようなアーキテクチャになります。
（Event BridgeからBedrock Flowを直接呼び出せないため、Lambdaを挟む必要があります。）
さいごに
Bedrock FlowはStep Functionsに慣れている方なら直感的に使えるサービスだと思いました。
また、継続的プロンプト最適化（Continuous Prompt Optimization）的な考え方で自動的にプロンプトが改善され続ける仕組みを作れるといいと思いました。
Bedrock Advanced Prompt Optimizationガンガン活用したいですね！
継続的プロンプト最適化（Continuous Prompt Optimization）は造語です。
弊社では一緒に働く仲間を募集中です！
現在、様々な職種を募集しております。
カジュアル面談も可能ですので、ご連絡お待ちしております！
募集内容等詳細は、是非採用サイトをご確認ください。