- サーバー正常でも画面が壊れる「沈黙の障害」を監視する仕組み
- 視覚検証と数値検証を並列実行。LLMと決定的コードを役割分担
- 障害検知の時間を最長72時間から1時間未満に短縮した実績
監視が届かない表示内容の障害
BIダッシュボードは、データを可視化して経営判断を支えるために使われます。しかし、AWSによると、サーバーやAPIが正常に稼働していても、画面に表示される表やグラフだけが壊れているケースがあります。こうした「コンテンツ層の障害」は、ダッシュボードを見たユーザーが報告しない限り検知されず、既存の監視では見落とされるのが問題です。
AWSチームは今回の記事で、この課題を解決する自動検証ソリューションを紹介しました。対象はAWS社内のInsightsアプリケーション上でホストされている数百のダッシュボードです。30日間の運用で802件の表示障害を検出した一方、ユーザーから能動的に報告されたものは1%未満にとどまったと報告しています。ユーザー報告頼みの運用では、本当に起きた障害の大部分を把握できないことが分かります。
五段階のサーバーレス構成
処理は、スケジュール管理・スクリーンショット取得・AI分析・通知・履歴保存の5段階で構成されます。Amazon EventBridgeが視覚検証を1時間ごと、週次のデータ更新後に数値検証を起動し、監視対象の一覧はAmazon Redshiftの設定レジストリが管理します。スクリーンショットは、AWS Lambdaがヘッドレスブラウザを操作して、ユーザーが見るのと同じ表示で取得します。
スクリーンショットは、AI分析の前にAmazon Rekognitionで文字と数値を検出し、プレースホルダーや合成値に置き換えるマスク処理を通過します。これにより、実データが画像として保存されるのを防ぎます。画像本体はAmazon S3に保存され、Amazon CloudFrontを通じて分析時に読み出されます。各ステップがサーバーレスで構成されているため、検証を実行していない時間帯はスケールがゼロになり、コストは実際の利用量に比例します。
視覚と数値の二系統検証
AI分析の段階では、2つの検証が並行して動きます。1つは視覚検証で、Amazon Bedrock上のAnthropic Claudeモデルがスクリーンショットを1枚ずつ分析し、空白のタイルやエラー表示、グラフの欠落を検出します。重要なのは、フィルターの組み合わせによって本当に表示するデータがない「正常な空」と、パイプラインの障害による「異常な空」を文脈から区別する点です。
もう1つは数値の突き合わせで、同じ指標が複数のダッシュボードに登場する点を利用します。LLMが指標の位置を特定して値を読み取り、単位の正規化や小数の比較は決定的コードが実行します。LLMは丸め方や許容誤差の比較ルールを一貫しにくいため、値の読み取りだけを担当させ、判定はコード側に任せる設計です。
本番投入の教訓と効果
実運用へ移す過程で得られた教訓は、誤検知(偽陽性)を最初に設計で防ぐことです。誤ったアラートが続くと、ダッシュボードの所有者は通知を信用しなくなるため、判定に迷うケースは自動通知せず、人間のレビューへ回す方式を採っています。数値検証では当初、LLMを2層にして比較と検証を行っていましたが、比較ロジックの一貫性に課題が残ったため、判定部分を決定的コードへ置き換えました。
この変更で、値の抽出を担うLLMを更新した際に、誤検知につながる読み取りミスが減り、再現率は0.88から0.95へ改善したと報告されています。30日間の本番運用では、数百のダッシュボードに対し15万3,000件の自動チェックを実行し、802件のコンテンツ障害(0.52%)を検出しました。障害を検知するまでの時間は、従来の最大72時間から1時間未満に短縮されています。
検出結果は、セクションの所有者へのSlack通知や、継続する障害のチケット自動起票につながります。AWSはこのソリューションを、既存のインフラ監視やデータ品質検証を置き換えるものではなく、補完するものだと位置づけています。また、Amazon Bedrockで利用できるモデルはAWSリージョンによって異なるため、採用時には対応状況の確認が必要です。
| 項目 | 従来の監視 | 今回のソリューション |
|---|---|---|
| 監視対象 | サーバー・APIの稼働状況 | ダッシュボードの表示内容 |
| 障害の検知方法 | ユーザー報告待ちが中心 | AIによる定期スキャンで自動検知 |
| 検知までの時間 | 最大72時間 | 1時間未満 |
That last-mile, semantic judgment is what this solution adds. It supplements both infrastructure monitoring and data-quality validation. It does not replace either.
この最後の1マイルに当たる意味的な判断こそ、このソリューションが付加する価値です。インフラ監視とデータ品質検証を補完するものであり、どちらかを置き換えるものではありません。
今後の見通し
今回の記事はAWSによる社内ツールの紹介であり、この仕組みがそのままAmazon BedrockやQuickSightの一般機能として提供されるかは未発表です。今後、誤検知率や障害種別ごとの詳細、マネージドサービスとしての提供有無が明らかになれば、自社導入を判断しやすくなるとみられます。また、LLMに画像認識と文章理解をさせ、数値判定をコードに固定する「役割分担」の考え方は、ほかの品質検証や監視システムにも応用できます。実際の精度に影響するRedshiftの設定やCloudFrontのキャッシュ構成などは原文には詳細がないため、導入時には個別の検証が必要です。
日本の開発者・IT企業にとっての意味
日本のIT企業にとって、この記事は「監視の対象をインフラから表示内容へ広げる」実装例として参考になります。ダッシュボードを運用している現場では、パイプラインは正常なのに数値がおかしい、グラフが空になるといった障害は珍しくありません。ユーザー報告に頼ると発見までに時間がかかるため、今回のようにスクリーンショットとLLMを組み合わせた定期検証は実務ですぐ試せる選択肢です。特に、LLMに値の比較や演算をさせず、抽出だけを担当させて判定は決定的コードに委ねる設計は、生成AIを検証系システムに使う際の参考になります。一方、原文の対象はAWS社内のダッシュボードであり、Amazon Bedrockのモデル提供リージョンやコストの試算などは別途確認が必要です。
気になる点
- 追加の機械学習モデルを用意する必要はありますか。
- ありません。OCR処理にはAmazon Rekognitionの学習済みモデルを、画面分析にはAmazon Bedrock上のAnthropic Claudeを利用します。独自モデルの開発や追加学習は不要で、LambdaやEventBridgeといったマネージドサービスで構成されます。
- 費用はどのくらいかかりますか。
- 具体的な金額は原文に示されていません。ただし、各処理はサーバーレスで構成され、検証サイクルの合間にはスケールがゼロに落ちるため、コストは利用量に比例しやすいと説明されています。自社のダッシュボード数とチェック頻度で試算する必要があります。
- 日本リージョンでも使えますか。
- Amazon Bedrock上で利用できるClaudeなどのモデルはAWSリージョンごとに異なるため、対応表の確認が必要です。原文は「モデルはリージョン別の対応状況を参照してほしい」と案内しており、日本リージョンでの利用可否は明記されていません。
用語解説
- Amazon Bedrock
- 生成AIモデルをマネージドで利用できるAWSサービス。Claudeなど複数の基盤モデルをAPIで呼び出せる。
- LLM
- 大規模言語モデル。大量のテキストから学習し、読解や文章生成ができるAIモデル。
- ヘッドレスブラウザ
- 画面を持たないブラウザ。サーバー上でページを描画し、ユーザーが見る状態のスクリーンショットを撮るために使う。
- Amazon Rekognition
- 画像・動画分析のAWSサービス。学習済みのOCR機能でスクリーンショット内の文字や数値を検出する。
- 再現率(recall)
- 実際に起きた異常のうち、検出できた割合。0.95なら95%の異常を拾えたことを示す。
- 決定的コード
- 同じ入力には必ず同じ結果を返すプログラム。ランダム性や確率を含むLLMの推論と対比される。
出典
How an AWS team detects dashboard content failures at scale using Amazon Bedrock
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する