誤警報を出さない異常検知：期待値の帯を作り、AIには仮説出しだけを任せる

毎週月曜に鳴るアラート：比較の取り方が間違っている

週ごとのリズムが安定しているネットショップを想定します（仮の例）。次の表は、曜日ごとの典型的なセッション数と、多くのダッシュボードが自然にやってしまう「前日との比較」で表示される差です。

まったく普通の1週間なのに、月曜には71%の急増（日曜より500セッション多く、500÷700）、土曜には22%の急落が表示されます。「前日比で20%を超える変動」を条件にした検知器は、理由もなく週に2回鳴ります。3週間もたてば、誰もアラートを読まなくなります。

異常検知の文献では、単発の外れ値と文脈的な異常が区別されています。ある文脈では平凡な値（月曜の1,200セッション）が、別の文脈（日曜の1,200セッション）では疑わしくなるという考え方です※2。

トレンド、季節性、残差に分ける

HyndmanとAthanasopoulosは、時系列を3つの要素に分解します。ゆっくり上下する水準である「トレンド」、繰り返すパターンである「季節性」（ここでは毎週、別の指標なら毎年）、そしてどちらでも説明できない「残差」です※1。異常とは、異常に大きな残差のことです。検知器の設計とは、残差を判定する前に、トレンドと季節性を取り除くことにほかなりません。

そのための最も単純な道具が7日間の移動平均です。ちょうど1週間分の周期を含むため、月曜から日曜までのパターンが打ち消し合い、トレンドだけが残ります。一方、特定の1日を判定するときは、周期の同じ位置と比べます。月曜なら、過去の月曜です。

スプレッドシートで「期待値の帯」を作る

方法は4つの列で済みます。ある月曜について、直前の8回分の月曜を取り、平均と標本標準偏差を計算し、「平均 ± k 標準偏差」の帯を引きます。8回分の月曜のセッション数を使った仮の例です。

1,180 ・ 1,220 ・ 1,260 ・ 1,140 ・ 1,200 ・ 1,240 ・ 1,160 ・ 1,200

1. 平均：合計は9,600で、8で割ると1,200。
2. 平均との差：−20、+20、+60、−60、0、+40、−40、0。
3. 差の二乗和：400 + 400 + 3,600 + 3,600 + 0 + 1,600 + 1,600 + 0 = 11,200。
4. 標本標準偏差：11,200 ÷ (8 − 1) = 1,600、その平方根は40。関数名は、Excelでは STDEV.S、Googleスプレッドシートでは STDEV です。

したがって、±2標準偏差の帯は [1,120 ; 1,280]、±3標準偏差の帯は [1,080 ; 1,320] になります。そこに、架空の月曜3回分を当てはめて読みます。

真ん中の行が、k の役割をよく表しています。2標準偏差ならアラートが鳴り、3標準偏差なら静かに通過します。k を小さくすれば本物の障害を拾いやすくなる代わりに誤警報が増え、k を大きくすればその逆になります。適切な設定は、見逃した障害のコスト（決済ページが止まっていた、など）と、無駄な確認のコスト（アナリストの10分）のどちらが重いかで決まります。

8点の帯が抱える限界

月曜8回分は、サンプルとしては少なめです。平均も標準偏差も推定値であり、8点で作った帯は見かけより脆くなります。よく使われる注意点は2つです。

• 過去の障害を除く。計測の不具合で600セッションだった月曜が混ざると、標準偏差が膨らんで帯が広がり、次の障害を見逃す検知器になります。こうした点を履歴から外すか、平均と標準偏差の代わりに中央値と中央絶対偏差を使います。後者は極端な値の影響を受けにくい指標です。
• トレンドに対応する。トラフィックが着実に伸びていると、8週間の平均は現実より遅れ、帯が低すぎる位置に出ます。窓を短くするか、各値をその週の7日移動平均で割って正規化すると、問題の一部は和らぎます。

多数の指標を監視しても、チームを警報で埋もれさせない

監視対象が1つから50に増えると、問題の規模が変わります。チャネル、デバイス、国、ランディングページ、主要イベントといった単位です。偏差が概ね正規分布に従い、指標どうしが独立だと仮定すると、ある指標が「偶然に」帯の外へ出る確率は、2標準偏差でおよそ4.55%、3標準偏差でおよそ0.27%です。50指標では次のようになります。

これは正規分布から導いた桁感です（2.28 ≈ 50 × 0.0455、1 − 0.9545⁵⁰ ≈ 0.90）。実際のトラフィックは裾が重く、指標どうしにも相関があります（計測の障害は複数のチャネルに同時に響きます）。この表から読み取るべきなのは定性的なメッセージで、監視する指標が増えるほど、厳しい閾値はノイズを増やすということです。

ノイズを減らす4つのフィルター

1. 優先順位をつける。監視するのは全体と、影響の大きい5つの指標であり、50の指標ではありません。小さな指標に検知器を置くのは、それが何かの判断につながるときだけです。
2. 最小ボリュームを決める。1日20セッションの指標は、割合で見ると大きく揺れます。あらかじめ決めた下限を下回るときは、アラートを出しません。
3. 差ではなく影響額で並べる。1セッションあたりの推定価値が50円の指標で30セッション減っても、1,500円分です。一方、粗利が1件9,000円のコンバージョンが8件減れば72,000円分です。標準偏差で測った外れ方は後者のほうが小さくても、リストの先頭に来るのは後者です。
4. 継続性を求める。「2日連続」を条件にすると、単発のスパイクの大半が消えます。引き換えに、1日の遅れが生じます。

統計学では、この問題が偽発見率（FDR）の制御という名で定式化されています（BenjaminiとHochberg）※3。ただ、週次の運用ルーチンであれば、優先順位づけと影響額での並べ替えでほとんどの場合は足ります。

とはいえ、閾値を厳しくすれば、逆方向の誤りが生まれます。3標準偏差の閾値では、ゆっくりした劣化は一度も検知されません。月曜が3回続けて1,160セッション（毎回−1標準偏差）だったとしても、すべて帯の内側です。ところが、同じ正規性の仮定のもとで、−1標準偏差を下回る値が3回連続する確率はおよそ0.4%（0.1587³）にすぎません。単発の閾値には映らない、本物の情報です。対策は継続性のルールを足すことで、「3点連続で平均の同じ側にあり、かつ1標準偏差を超えていればアラート」とします。

AIが担う部分：GA4のインサイトと対話型AI

GA4のインサイト

Google アナリティクスのヘルプによれば、GA4には、通常と異なる変化や新たな傾向を知らせる「自動インサイト」と、条件（指標、セグメント、想定する変化）を自分で設定する「カスタムインサイト」があります※4。確認すべき候補を拾う入口としては有用です。どの指標が対象か、期待値がどう定義されているか、評価の頻度はどうかは、現行のドキュメントで確認してください。重要な指標については、ルールを自分で把握している自前の帯を併用すると安心です。

仮説を整理するための対話型AI

対話型AIが役に立つのは3つの作業です。スプレッドシートで帯を作る数式を書くこと、アラートに対する考えられる説明を挙げること、そして状況を専門外の読み手向けに言い換えることです。ただし、AIはキャンペーンのカレンダーも、タグの実装バージョンも、在庫の状況も知りません。「なぜ下がったのか」と尋ねれば、もっともらしく自信ありげな説明が返ってきますが、それは診断ではありません。正しい使い方は、仮説の一覧と、それぞれを確かめる方法を挙げさせることです。

次は集計済みの日次セッション数です（個人データは含みません）。
[表：日付、チャネル、セッション数]
12日（月）のセッションは1,010件で、期待値は1,200件でした
（±2標準偏差の帯：1,120〜1,280）。
この減少について考えられる仮説を、可能性が高い順に6つ挙げてください。
それぞれ、確認または除外するために見るべきデータも書いてください。
不足している情報も挙げてください。
原因は断定せず、基準値を作り出さないでください。

返ってきた回答は、結論ではなくチェックリストとして使います。よくある確認事項は次のとおりで、AIには順序づけを手伝わせても、判断はさせません。

• 計測タグに変更はなかったか（Googleタグマネージャーのバージョン履歴、同意バナーの変更）。コンバージョン計測の不具合の診断を参照してください。
• キャンペーンが停止、上限到達、終了していないか。
• 不審なトラフィック（ボット、リファラースパム）に変化はないか。
• 祝日、サイト障害、在庫切れで説明がつかないか。
• バックオフィス（受注、受信したフォーム）の数字は、GA4で見えた減少を裏づけているか。

AIが出した平均や標準偏差は、自分でも手計算で検算してください。対話型AIは数式を書くのは上手でも、単純な算術では間違えることがあります。

送るデータと、手元に残すデータ

外部のAIツールに送るのは集計済みの系列（日別・チャネル別のセッション数、コンバージョン数）だけで、1件ごとの行は送りません。メールアドレス、ユーザーID、client_id、IPアドレス、フォームの自由記述は含めないでください。入力内容が保存・再利用されるかどうかは、ツールの利用規約と設定で確認します。個人情報保護委員会が2023年に公表した「生成AIサービスの利用に関する注意喚起等について」は、生成AIサービスに個人情報を入力する場合、特定した利用目的の範囲内かどうか、入力した情報が機械学習に使われないかどうかを確認するよう求めています（要旨。詳細は原文を参照）※5。総務省・経済産業省の「AI事業者ガイドライン」も、AIの利用者にプライバシー保護などの留意を求める指針を整理しています※6。迷ったときは、送らないのが原則です。

週次の検知ルーチン

この記事の成果物は、毎週同じ時間帯に、担当者を決めて行う20分ほどのルーチンです。

1. 帯を更新する。全体と優先する5つの指標について、障害があった日や特別な日を除いて更新します。
2. 帯の外にある点を一覧にする。標準偏差で測った外れ具合と、推定した影響額（差 × 単位価値）を添え、最小ボリューム、継続性、3点連続のずれといったフィルターを当てます。
3. GA4のインサイトを確認する。その期間のものを見て、優先指標に関わるものだけを残します。
4. 仮説をAIに出させる。主要な2〜3件のアラートについて、集計データだけを渡して依頼します。
5. 検証して記録する。各アラートを元データで確定または棄却し、結果を書き留めます。

この記録がいちばん価値のある部分です。数か月続けると、どのアラートが妥当だったか、どの閾値が厳しすぎるか、どんな原因が繰り返されるかが見えてきます。商売上の理由より先に、計測の不具合が出てくることが少なくありません。期待値の帯は、1ステップ先の予測でもあります。スプレッドシートで3つのシナリオを組み立てる手順は、同じ考え方を数か月先へ延ばし、幅の広がる予測区間を伴わせたものです。表示の面では、帯を灰色のリボンとして折れ線の背後に置くと、判断のためのマーケティングダッシュボードで読みやすくなります。分析の流れ全体のなかでAIに任せられる範囲を位置づけたい場合は、分析の流れの中でのAIの使いどころをご覧ください。

検知器が教えるのは「何かがいつもと違う」ことだけで、理由は教えてくれません。計測と分析を実践で身につけたい方には、マーケティング分析・AI実践コースがあります。