画面は開くのに、数字が間違っている。AWSがAIでダッシュボード障害を見つけるまで

先に結論
システムが正常に動いていても、利用者が見るダッシュボードの中身が正しいとは限りません。AWSのBI・分析チームは、画面の空白やエラーをAIで見つける仕組みと、数字の一致をプログラムで確かめる仕組みを組み合わせ、障害の発見時間を最大72時間から1時間未満へ短縮したと報告しました。

企業の監視は、サーバーが応答するか、APIが動くか、データ処理が失敗していないかを中心に設計されがちです。しかし、すべての監視が正常でも、権限変更やフィルター設定、更新時刻のずれによって、最終画面だけが空白になったり、古い数字を表示したりすることがあります。

AWSは2026年9月2日、社内のダッシュボード群を対象にした「最後の表示内容」の検査事例を公開しました。本記事では、Amazon Bedrockを使ったこと自体ではなく、AIへ任せる判断と、プログラムへ残した判断をどう分けたかに注目します。

AWSのチームが見つけたのは、監視の「最後の空白」でした

今回の仕組みを構築したのは、AWS Insightsアプリケーション上の多数のダッシュボードを運用するBI・分析チームです。AWSによると、従来の基盤監視はページの応答や遅延を確認でき、データ層の検査は上流処理の失敗を捉えられます。一方、実際に表示された表やグラフの意味までは確認できませんでした。

例えば、フィルターの組み合わせによって本当にデータがゼロなのか、処理の失敗で空白になったのかは、HTTP 200という応答だけでは区別できません。また、グラフが正しく描画されていても、集計条件や単位の違いで数字が誤っている場合があります。

この問題は、ダッシュボードの内容を生成AIが読み取り、経営向けの説明を作る場面でさらに大きくなります。誤った数字が表示されたままなら、その後に生成される説明も誤るためです。AWSの事例は、AIを業務へ追加する前に、AIが読む情報の品質を監視する必要性を示しています。

30日で15万3,000回を検査し、802件の表示障害を検出

AWSによると、画面検査の本番運用30日間で15万3,000回の自動チェックを行い、802件の表示内容の障害を検出しました。障害率は0.52％で、99.48％は正常だった計算です。問題は一部の画面に集中せず、監視対象の広い範囲で発生していました。

検出した障害には、行単位のデータ権限エラー、フィルターによるレコード欠落、描画問題などが含まれます。そのうち利用者から報告があったものは1％未満でした。問い合わせを待つ運用だけでは、ほとんどの異常を把握できなかったことになります。

検査は1時間ごとに動くため、障害発見までの最長時間は検査間隔で区切られます。その結果、平均検出時間ではなく、AWSが記す「mean time to detection」は最大72時間から1時間未満になりました。これは復旧時間の短縮ではなく、発見までの時間を短縮した数字である点に注意が必要です。

LAST-MILE VALIDATION

AIに任せた部分と、プログラムに残した部分

SEEAIが画面を見て
空白や異常を読む

COMPAREプログラムが
単位と数値を比較する

REVIEW曖昧な結果は
人が確認する

5段階の仕組みは、画面を証拠として残すところから始まります

仕組みは5段階です。まずAmazon EventBridgeが定期検査を開始し、Amazon Redshiftの登録情報から対象画面と担当者を確認します。次に、ヘッドレスブラウザーが利用者と同じようにダッシュボードを開き、画面を撮影します。

保存前にはAmazon Rekognitionで画面内の文字と数字を検出し、文字を伏せ、数字を合成値へ置き換えます。機密情報を含む画面をそのまま保存しない設計です。画像はAmazon S3へ保存され、分析時に利用されます。

分析段階では二つの処理が並行します。表示検査ではAmazon Bedrock上のClaudeが、空白のパネル、エラー状態、欠けた図表などを読みます。数値検査ではAIが同じ指標を画面から探して値と単位を抽出し、その後の換算と一致判定を通常のプログラムが行います。

異常が確定すると、画面名、画像、AIの確信度、調査画面へのリンクを含む通知を担当者へ送ります。継続する障害はチケット化し、結果はRedshiftへ保存して傾向分析へつなげます。ここまでを一つの検査循環として設計している点が特徴です。

なぜ「数字の判定」をAIに任せなかったのか

当初は、値を抽出・比較するAIと、その結果を検証する別のAIを置き、両方へ計算機能を与えていました。それでも、本番では丸め方、許容差、単位の違いを扱う比較ルールに不整合が残ったとAWSは説明しています。

そこで、AIの役割を「画面から指標を見つけ、値と単位を読む」までに限定しました。単位の正規化や小数精度の処理、一致・不一致の最終判定は、同じ入力なら同じ答えを返すプログラムへ移しています。

その後のモデル更新により、画面上の値を読み違える誤警報が減り、再現率は0.88から0.95へ改善したと報告されています。重要なのは、AIの性能向上を待ったことではなく、誤りが信頼を壊す工程を先に分離したことです。

従来の監視と、今回追加された検査は何が違うのか

検査する層	主に確認すること	見逃しやすいこと
基盤監視	ページ応答、リンク、遅延	表示内容の意味や正しさ
データ層の検査	処理失敗、上流データの品質	フィルター後の最終表示
今回の表示内容検査	空白、エラー、数値の不一致	原因の完全な特定や自動復旧

今回の仕組みは既存監視の代替ではありません。AWSも、基盤監視とデータ品質検査を補うものだと説明しています。日本企業が取り入れる場合も、既存の監視を外してAIへ置き換えるのではなく、利用者が最後に見る画面を追加で検査する位置づけが安全です。

日本企業が応用するなら、まず問い合わせ前に気づきたい画面を選ぶ

最初からすべての社内画面を対象にする必要はありません。経営会議で使う売上ダッシュボード、店舗別の在庫表、顧客へ共有する運用レポートなど、「画面は開くが内容が間違うと判断へ影響する」ものから始めると、検査の価値を測りやすくなります。

評価指標もAIの正解率だけでは不足します。問い合わせより先に発見できた件数、誤警報率、人が確認した件数、発見までの時間、復旧までの時間を分けて記録する必要があります。特に誤警報が増えると、担当者が通知を信用しなくなるため、検出数を増やすことだけを目標にすべきではありません。

また、画面の撮影には個人情報や営業情報が含まれる可能性があります。AWS事例のような保存前のマスキング、保存期間、閲覧権限、利用モデルへ送る範囲を先に決めることが導入条件になります。

今回の公開情報だけでは分からないこと

AWSの記事からは、開発と運用にかかった総費用、導入前後の復旧時間、802件のうち重大障害が占めた割合、誤警報の絶対数までは確認できません。99.48％という数字も、業務上求められる可用性を満たすかどうかとは別の評価です。

数値検査は6か月以上、週次で50〜70のデータ点を確認し、公開時点まで人の確認を誤って通過したデータ問題はなかったとされています。ただし、これはAWSによる自社報告であり、第三者が同じ条件で再現した結果ではありません。

よくある質問

普通の死活監視があれば十分ではありませんか？

死活監視は「開けるか」を確認できますが、「表示された内容が正しいか」までは判断できません。両方を併用する必要があります。

画面の数値比較も生成AIだけでできますか？

値の発見や読み取りには使えますが、丸め方や単位換算を含む最終判定は固定ルールのプログラムへ任せる方が再現しやすい、というのが今回の事例の教訓です。

最初の実証では何を測るべきですか？

検出件数だけでなく、誤警報率、問い合わせ前の発見率、人の確認件数、発見時間と復旧時間を分けて測ります。

まとめ

AWSの事例が示したのは、AIで監視を置き換える方法ではありません。AIには画面の意味を読む仕事を任せ、数字の最終判定はプログラムへ、曖昧な結果は担当者へ戻す設計です。

生成AIが企業の判断材料を読むようになるほど、その入力となる画面が正しいかを確かめる工程は重要になります。AI導入の次の課題は、答えを作ることだけでなく、答えの根拠となる表示を継続的に検査することです。