Quantum Metric導入で決める項目｜常時監視AIの任せ方

「ログインの不具合に、週明けの売上集計を見るまで誰も気づかなかった」「異常の通知は来るけれど、どれから手を付ければいいのか分からない」——Webサイトやアプリの担当者、分析の担当者から、よく聞く声です。サイトの不具合や導線の詰まりは、直す速さより先に、気づくまでの時間が損の大きさを決めます。夜中に壊れた決済の画面は、朝まで売上を取りこぼし続けます。その「気づくまで」を短くするため、常時見張るAIが異常を見つけ、原因の候補と売上への影響の見積もりまで出す製品が、2026年夏に一般提供になりました。見張りがAIに移っても、対応の順番を決める仕事は人に残ります。この記事では、米国の「Quantum Metric」の Felix Agentic を例に、導入の前に決めておく項目を整理します。

Quantum Metric は、サイトとアプリの利用者の動きを丸ごと記録して分析する基盤

Quantum Metric は、企業のWebサイトとスマホのアプリで、利用者がどこで迷い、どこで離れたかを記録して分析する基盤です。画面の操作の記録、導線ごとの離脱、表示の速さ、エラーの発生などを、あらかじめ全部取り込んでおく作りで、公式サイトは300を超える指標を最初から取れるとしています。

この基盤の上に載ったのが、AIの層である Felix です。もともとは、利用者1人分の操作の記録をAIが要約する機能として知られていました。2026年3月25日、公式ブログで Felix Agentic が発表されました。質問に答える Felix のチャット、常時見張る Background Agents、ダッシュボードの中で働く Copilot の3つが最初の構成です。

Felix Agentic は、Google の Gemini を土台に、Quantum Metric が集めた利用者の行動データと自社の分析の手順を組み合わせて動く、と製品ページに書かれています。この記事が扱うのは、このうち常時見張る Background Agents の通知と、売上への影響の見積もりをどう受けるかです。

作っている会社と、国内でまだ知られていない理由

Quantum Metric は、2015年に創業した米国コロラド州の会社です。金融業界の媒体の2026年3月の記事では、大手の送金会社やカナダの銀行が顧客として紹介され、提供元の発表では、米国の大企業番付である Fortune 500 の2割に使われているとしています。主な顧客は小売・航空・金融など、サイトやアプリの取引が売上に直結する大企業です。

国内で知られていない理由の1つは、この客層です。利用者の動きを丸ごと記録するには、それなりの取引量と、分析を回す人手が要ります。もう1つは言語で、2026年10月時点の公式サイトで、日本語の画面や日本の拠点を確かめることはできませんでした。国内の販売代理も公式の情報からは見えません。

それでも取り上げるのは、常時見張るAIが異常と売上影響まで出す、という作りが、これから国内の分析の道具にも広がると考えられるからです。通知の受け方を先に決めておく話は、どの製品を選んでも同じように当てはまります。

国内の会社が検討するときに、もう1つ確かめておきたいのが日本語の扱いです。利用者の行動の記録は言語に関係なく取れますが、AIが原因の候補や説明を返す文章が日本語でどこまで自然か、日本語の画面の文言を正しく読み取れるかは、公式の情報からは分かりません。試行では、日本語のサイトで実際に起きた過去の不具合を材料に、説明の質を確かめるのが確実です。

2026年夏の一般提供で、何が使えて何がベータか

2026年7月16日の夏の更新で、Felix Agentic は一般提供になりました。ただし、全部の機能が同じ段階にあるわけではありません。導入の判断では、提供中の機能とベータの機能を混ぜずに考えます。2026年10月時点の公式の発表とブログで確かめた状態は次のとおりです。

機能	何をするか	提供の状態（2026年10月時点）
Felix のチャット	言葉で質問し、数字の裏付けつきの答えを返す	一般提供
Background Agents	重要な指標を常時見張り、何が・なぜ・どこで変わったかを示す	一般提供
Copilot	ダッシュボードの中で、見ている数字の変化を説明する	一般提供（発表文による）
Skills と Workflows	指標の計算のしかたを教える／分析を定期や合図で自動で回す	夏の更新で紹介。提供の段階は明記なし
MCP	外部のAIや道具から Felix の答えを使う	ベータ
スマホのアプリ	同じ機能をスマホで使う	ベータ

表のとおり、外部のAIとつなぐ MCP はまだベータです。社内のAIの助手から異常の答えを引く使い方は、夏の時点では試験の扱いだと考えておきます。Skills と Workflows は段階が明記されていないため、導入前に提供元へ確かめる項目に入れておきます。

夏の更新では、ほかにも見張りに関わる追加がありました。アプリの異常終了を分析する機能はベータ、生成AIの助手や検索から来た流入を見分ける機能、アドビのデータ基盤とつなぐ機能も紹介されています。画面の熱分布や2つのページの比べ方をAIが読む Copilot の拡張は、ベータで近日提供の扱いです。発表の一覧に載っていることと、自社の契約で今日使えることは別なので、試行の前に使える機能の一覧を提供元から書面でもらっておきます。

「気づくまでの時間」が損を決める

サイトの不具合の損は、壊れていた時間に比例します。ログインの画面が1時間止まれば、その1時間に来た利用者の分だけ取りこぼします。従来は、担当者がダッシュボードを見る朝や、週の集計を見たときに初めて気づくことが多く、壊れてから気づくまでの時間が、直す時間よりずっと長いことが珍しくありませんでした。

Background Agents は、この「気づくまで」を短くする仕組みです。公式ブログによれば、重要な導線・ページ・指標を見張り、変化があると、何が変わったか、なぜ変わったか、どこに影響が出ているかを添えて知らせます。単に数字が下がったという通知ではなく、原因の候補まで調べた状態で届く、というのが従来の通知との違いです。

公式の説明では、こうした調べ方を一度作っておけば、誰かが毎回始めなくても動き続けます。夏の更新で紹介された Workflows は、分析を定期・合図・その場の依頼のいずれかで回す仕組みです。見張りが人の手を離れて回り続けるぶん、誰がその見張りを作り、いつ見直すのかを記録しておかないと、作った人が異動した後に持ち主のない見張りが残ります。

ただし、気づくのが早くなっても、直すのが早くなるとは限りません。通知を受ける人が決まっていない、受けた人に直す権限がない、どれから直すかで揉める。こうした詰まりが残っていれば、早く気づいた分は無駄になります。見張りの速さを損の削減に変えるのは、通知を受けた後の人の段取りです。マーケ指標の異常検知の設計そのものは別の記事で扱っているので、ここでは製品の通知を受けた後に絞ります。

項目1：見張らせる導線を選ぶ

最初に決めるのは、何を見張らせるかです。製品ページによれば、導線の離脱、ログインのエラー、NPSの傾向といった既製のエージェントがあり、自社で見張る対象を設定することもできます。全部を見張らせたくなりますが、最初は売上に直結する導線に絞ります。

選び方の目安は、「止まったら売上がすぐ減る導線」から順に並べることです。会員のログイン、カートへの追加、購入の手続き、問い合わせや資料請求のフォーム。止まったときに誰が直すかがはっきりしている導線から始めると、通知の行き先もそのまま決まります。逆に、持ち主のいないページを見張らせても、通知は宙に浮きます。

見張る導線を広げるのは、最初の導線で通知の受け方が回るようになってからにします。導線を増やすほど通知の本数が増え、受ける人の負担も増えます。四半期ごとに、見張っている導線の一覧と、それぞれの持ち主を見直す場を設けておくと、持ち主が異動したまま見張りだけが残る事態を防げます。

サイトとアプリの両方を持つ会社は、どちらを先に見張らせるかも決めます。アプリは端末の種類や版の違いで不具合が出る範囲が細かく分かれ、直す担当も別のチームであることが多いからです。アプリの異常終了の分析は夏の時点でベータなので、アプリの見張りは、サイトで受け方が回ってから加えるくらいの順番が扱いやすいでしょう。

項目2：「異常」の物差しを誰が書くか

AIが異常と判断する前提には、何を正常とみなすかの物差しがあります。夏の更新で紹介された Skills は、指標の計算のしかたや分析の枠組みを Felix に教える仕組みで、自社の定義による転換率を使わせる、といった使い方が例として挙がっています。どの導線が重要かという文脈も、Skills で渡せるとされています。

ここで決めるのは、物差しを書く人と、変える人を分けることです。転換率の定義や、どの導線を重要とみなすかは、分析の担当が下書きし、マーケの責任者が承認する、といった形にします。物差しを誰でも変えられると、通知が多すぎると感じた人が基準を緩め、本当の異常まで見逃すようになります。

もう1つ、セール・キャンペーン・メールの一斉配信のように、数字がわざと動く日をどう扱うかも決めておきます。施策で増えた流入をAIが異常と読むことがあるからです。施策の予定を事前に見張りの担当へ渡す流れを作っておくと、施策の日の誤報が減ります。指標の定義の承認をどう回すかは、AIアナリストを扱った別の記事でも触れています。

項目3：異常の通知を誰が受けるか

製品ページによれば、通知は Slack やメールなどに送れます。決めるのは、どの導線の通知を、どのチャンネルの誰が最初に受けるかです。全員が見るチャンネルに流すと、誰かが見ているだろうと思って誰も動かない、という状態になりがちです。

おすすめは、導線ごとに「一次の受け手」を1人か1つの当番に決めることです。一次の受け手は、通知を読んで、本物の異常か、誤報か、様子見かを判断し、本物なら直す担当に渡します。一次の受け手に求めるのは、直す力ではなく、振り分ける力です。直すのは開発やシステムの担当でも、振り分けはサイトの運用を分かっている人が向いています。

夜間と休日の扱いも決めます。決済やログインのように止まると影響が大きい導線は、夜間でも当番に届くようにし、それ以外は翌朝にまとめて見る、と分けます。全部の通知を夜中に鳴らすと、当番が疲れて重要な通知まで見落とします。どの導線を夜間の対象にするかは、売上の影響と直す担当の体制を見て人が決めます。

通知を受ける人には、製品の中で何が見えるかも合わせて決めます。公式のデータ保護のページによれば、役割に応じて見られる範囲を分けられます。一次の受け手に必要なのは、異常の要点と原因の候補を確かめる範囲で、個人情報の復号までは要りません。受け手を増やすときは、見える範囲を広げすぎないようにします。

項目4：売上影響の見積もりは優先度の参考で、確定額ではない

Felix Agentic の特徴は、異常に売上への影響の見積もりを添えることです。製品ページによれば、影響を受けた利用者の数、転換への影響、売上への影響を測って、体験の問題を事業の結果につなげます。複数の異常が同時に来たとき、どれから直すかを決める手がかりになります。

一方で、この見積もりの計算方法は、2026年10月時点の公式の公開情報では確かめられませんでした。異常がなければ買っていたはずの人数を推定する以上、仮定が入ります。見積もりの金額は、対応の順番を決める参考であって、取りこぼした売上の確定額ではないと、導入の時点で部門の中で共有しておきます。

使い方の目安は、金額の大小よりも桁を見ることです。同じ日に来た2つの異常の見積もりが10倍違えば、大きい方を先に直す根拠になります。しかし2割しか違わないなら、見積もりの誤差の中に入っているかもしれません。その場合は、直しやすさや、顧客の苦情が出ているかといった、見積もりの外にある事情で順番を決めます。

算定の方法が公開されていない以上、試行の段階で提供元に聞いておく点があります。比べる相手を前の週の同じ曜日にしているのか、季節の傾向を差し引いているのか、影響を受けた利用者の数をどう数えているのか、売上の単価は何を使っているのか。答えを書面で受け取り、部門の中で見積もりの前提として共有すると、数字の受け止め方がそろいます。答えが得られない項目は、見積もりの限界として報告の添え書きに残します。

• 見積もりは、異常が続いた時間が延びるほど大きくなります。気づいた直後の金額と、直し終えた後の金額は違うので、記録には「いつ時点の見積もりか」を必ず添えます

見積もりを経営に出すかは人が決める

売上影響の見積もりは、数字として分かりやすいぶん、そのまま経営への報告に載りやすい数字です。「今月の不具合で失った売上」として集計したくなります。しかし、確定額でない数字を集計すると、仮定の上に仮定が積み上がります。

経営に出すかどうかは、分析の担当とマーケの責任者が決めます。出す場合は、見積もりであること、計算方法が公開されていないこと、いつ時点の数字かを必ず添えます。見積もりを報告に使うなら、不具合の件数と続いた時間を主にして、金額は添え物にするくらいの扱いが無難です。

顧客への告知も同じです。決済の障害のように顧客に影響が出た異常で、告知するか、どこまで書くかは、AIの通知ではなく、顧客対応と広報の担当が決めます。AIが見つけた原因の候補は、告知の文面の根拠にする前に、直した担当が確かめた事実と突き合わせます。

項目5：直す担当への渡し方

一次の受け手が本物の異常と判断したら、直す担当に渡します。渡し方が決まっていないと、通知のリンクだけが送られ、直す担当がもう一度調べ直すことになります。Felix が原因の候補を付けて届けるのは、この調べ直しを減らすためです。渡すときに何を添えるかを決めておきます。

4つ目の「戻す」がいちばん抜けやすい手順です。AIの原因の候補が当たっていたか外れていたかの記録がないと、どの種類の異常ならAIの候補を信じてよいかがいつまでも分かりません。記録が溜まると、候補をそのまま直す担当に渡してよい種類と、必ず人が調べ直す種類を分けられるようになります。

直す担当は、異常の種類によって変わります。画面の表示や入力欄の不具合ならサイトの制作や開発の担当、決済の遅れなら外部の決済会社との窓口、文言や価格の誤りならコンテンツの担当です。異常の種類ごとの渡し先を一覧にしておくと、一次の受け手が迷わずに済みます。社外の制作会社に直してもらう場合は、連絡の窓口と、夜間に連絡してよいかを契約の段階で決めておきます。

項目6：誤報の扱いと、見張りの見直し

常時見張るAIは、誤報を出します。施策で増えた流入、計測のタグの不具合、外部の決済会社の一時的な遅れ。どれも数字は動きますが、サイトの問題とは限りません。最近は、生成AIの助手や検索から来る流入が増減して、導線の数字が動くこともあります。夏の更新で紹介された、こうした流入を見分ける機能は、誤報の切り分けにも使えます。計測そのものの不具合を見張る道具は別の記事で扱っているので、ここでは誤報を受けた後の扱いに絞ります。

誤報は、一次の受け手が「誤報」と印を付けて記録します。記録には、何が原因で数字が動いたかを1行書きます。月に1回、誤報の記録を見て、同じ理由の誤報が繰り返されていれば、物差しを直すか、施策の予定の渡し方を直します。誤報を減らすために基準を緩めるのは最後の手段にします。

見直しでは、逆の見逃しも確かめます。顧客の苦情や売上の集計で後から分かった不具合のうち、AIが通知しなかったものを拾い出します。見逃しがあれば、その導線が見張りの対象に入っていたか、物差しが合っていたかを確かめます。誤報と見逃しの両方を見ないと、見張りの質は測れません。

見直しの材料として、公式ブログは Felix の答えがどう導かれたかを後から確かめられると説明しています。原因の候補がなぜその結論になったかを読めれば、外れたときに物差しの誤りなのか、データの欠けなのかを切り分けられます。根拠が読めない通知は、当たっていても運用の改善には使えないので、試行の段階で根拠の表示を確かめておきます。

何が外に出るか：記録のデータとAIの行き先

利用者の動きを丸ごと記録する以上、入力欄の中身や個人情報の扱いは最初に確かめる項目です。公式のデータ保護のページによれば、記録する・記録しない・暗号化するを利用者の端末の側で選べ、パスワードや支払いの情報は既定で記録しません。個人情報は顧客ごとの鍵で暗号化され、提供元は復号できないと説明されています。

同じページによれば、顧客ごとのデータは Google Cloud の専用の区画に置かれ、通信中も保存中も暗号化されます。SOC 2 とハイトラストの監査、ISO/IEC 27001 の認証を持ち、SSOと役割による権限、復号したときの記録の機能があります。記録の中に誤って入った個人情報や決済の情報を探して、隠すか消す候補として示す機能もあるとされています。隠す設定の確かめ方そのものは、録画型の解析の記事で整理しています。

確かめられなかったこともあります。Felix Agentic が Gemini を使うことは公式に書かれていますが、AIに渡したデータが学習に使われるか、AIの処理がどの区画で行われるかは、2026年10月時点の公開情報では確かめられませんでした。ベータの MCP で外部のAIとつなぐ場合は、答えが外部の道具に運ばれます。導入前に、この2点を提供元に書面で確かめます。

費用の増え方と、止め方

2026年10月時点で、公式サイトに公開の料金表は見当たらず、見積もりで決める形です。増え方としては、記録する利用者やセッションの量、見張る導線とエージェントの数、使う人数で膨らむと考えておくのが無難です。数え方は契約ごとに違うので、見積もりの段階で、見張りの本数を増やしたときに費用がどう変わるかを確かめておきます。

試行の期間を設けるなら、何をもって続けるかの物差しを先に決めます。異常に気づくまでの時間がどれだけ縮んだか、通知のうち本物の異常の割合はどれくらいか、AIの原因の候補が当たった割合はどれくらいか。この3つを試行の前後で比べられるよう、試行の前の気づくまでの時間を記録しておくことが要です。前の記録がないと、効果を提供元の発表の数字で語るしかなくなります。

止め方も先に決めます。個々の見張りを止めるのは、その導線の持ち主と分析の担当が決められるようにし、見張り全体を止めるのはマーケの責任者の判断にします。夜間の通知が多すぎるからと、当番が自分の判断で見張りを止めない決まりも入れておきます。止めた見張りは、止めた理由と再開の条件を記録します。

契約をやめるときは、記録の保存期間と、自社に残すべき分析の結果を確かめます。誤報と見逃しの記録、原因の候補が当たったかの記録は、別の道具に移っても使える資産です。製品の中にだけ置かず、自社の側にも残しておきます。

AIに任せる工程と、人が決める工程

ここまでの線をまとめます。AIに任せるのは、常時の見張り、異常の検出、原因の候補の提示、売上影響の見積もりです。いずれも人が24時間はできない仕事で、間違っても一次の受け手が止められます。人が決めるのは、見張る導線と物差し、対応の優先順位、顧客への告知、見積もりを経営に出すかどうかです。

• 売上影響の見積もりの大きい順に、そのまま対応の順番を自動で決める
• 見積もりの金額を足し合わせて「今月の損失額」として経営に報告する
• AIの原因の候補を、確かめずに顧客への告知の文面に使う
• 通知が多いからと、当番の判断で物差しを緩めたり見張りを止めたりする

この4つに共通するのは、AIの出した数字や仮説を、人の判断を通さずに外へ出していることです。見張りをAIに任せるほど、外に出す前の関所は人がはっきり持っておく必要があります。顧客の声を常時見張るエージェントの記事でも同じ線を引いていますが、ここで見ているのはサイトとアプリの数字の異常です。

導入前に決める項目一覧

最後に、導入の前に部門で決めておく項目を並べます。製品の選定の前でも、試行の前でも、この一覧が埋まっていない項目があれば、そこが通知の詰まる場所になります。どれも、ほかの常時監視の道具を入れるときにもそのまま使える項目です。

• 最初に見張らせる導線と、それぞれの持ち主（止まったら直す人）
• 異常の物差し（指標の定義・重要な導線）を書く人と承認する人
• 施策の予定を見張りの担当へ渡す流れ
• 導線ごとの一次の受け手と、夜間・休日に通知を受ける対象
• 売上影響の見積もりの扱い（優先度の参考とし、確定額として集計しない）
• 見積もりを経営に出すかどうかを決める人と、出すときの添え書き
• 直す担当へ渡すときに添える項目と、直した結果を戻す決まり
• 誤報と見逃しの記録のしかたと、月1回の見直しの場
• AIの学習への利用・処理の場所・外部のAIとつなぐ範囲の書面での確認
• 見張りを止められる人と、契約をやめるときに自社に残す記録

一覧の中で最初に埋めるべきなのは、導線の持ち主と一次の受け手です。ここが決まれば、ほかの項目は誰に聞けばよいかが分かります。逆にここが空いたままでは、どれほど賢い見張りを入れても、通知は誰にも拾われません。

まとめ

Quantum Metric の Felix Agentic は、サイトとアプリを常時見張り、異常と原因の候補、売上への影響の見積もりまでを人に届けるAIです。気づくまでの時間は確かに短くなります。ただし、その速さを損の削減に変えるのは、見張る導線と物差し、通知の受け手、見積もりの扱い、直す担当への渡し方、誤報の見直しを、導入の前に人が決めておくことです。見張りはAIに任せ、対応の順番と外に出す数字は人が持つ。この線を一覧にして部門で合意してから入れることが、常時監視のAIを使いこなす近道です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。