フロントエンドカンファレンス関⻄ 2026 ブラウザとサーバーから考える AI時代のフロントエンド監視 2026.10.12 Shogo Fukami 

⾃⼰紹介 略歴 複数のメガベンチャー‧スタートアップを経て、 2024年10⽉にカナリーへジョイン 現在はフルスタックで開発中 直近の出来事 深美 翔悟 休みの⽇は⼦どもと遊んで息抜きしています Shogo Fukami 株式会社カナリー 『CANARY』テクニカルリードエンジニア X: @react_nextjs つぶやき 今年も東京から参加させていただきました 関⻄出⾝なので、関⻄弁を交えながら話していきます 

去年もこの場で登壇させていただきました • 「堅牢なフロントエンドテスト基盤を構築す るために⾏った取り組み」 • フロントエンドカンファレンス関⻄2025 • ビジネス上の最重要導線を特定し、そこにテ ストを集中させる話 去年は「リリース前」の品質の話。今年は「リリース後」の品質の話です 

会社紹介 ── 株式会社カナリー BtoC 不動産マーケットプレイス「カナリー」 • アプリ版 累計DL数 650万（Web版もあります！） • カテゴリ内ユーザー評価 No.1（App Store ★4.8）* • TVCMも全国で放映 BtoB 不動産仲介会社向けSaaS「カナリークラウド」 • 累計利⽤者数 300万⼈を突破 • 後発ながら、全国の地⽅⼤⼿企業様を軸に急成⻑ * 主要部屋探しアプリにおけるユーザー評価（iOS / Google Play） BtoC / BtoB 両軸でプロダクトを展開しています 

アジェンダ 導⼊ • 監視とは何か∕なぜ今それが必要なのか 1 • フロントエンド監視の守備範囲 2 • 監視設計 ── 何を拾い、拾った後どうするか 3 • AIで運⽤を回す まとめ • 持ち帰っていただきたいこと 実際の取り組みと、うまくいかなかったところを交えてお話しします 

みなさん、 アプリケーションの監視してますか？ 

監視とは 可視化 • システムの稼働状況を⾒えるようにする 検知 • 異常やユーザーへの影響を素早く⾒つける 対処 • ⾒つけたものに迅速に対応する この3つが揃ってはじめて「監視している状態」と⾔える 

ところが2年前のCANARYには、 障害に気づける仕組みがありませんでした 

リリースして壊れていても気づけなかった 4⽇ リリースしてから、不具合に気づくまでにかかった時間 気づいたきっかけは、不動産会社様からのご指摘だった 

当時は、ほかにもこんなことが起きていた 時期 何が起きたか どう気づいたか 2024年11⽉ API のレスポンスサイズが上限を超えて 、TOP‧検索結 果ページが表⽰できない 発⽣から約2時間半後に検知 2025年1⽉ ABテストの⽚側で undefined を参照し、SSR が失敗して 500 アラートは鳴らなかった 2025年2⽉ ライブラリ更新の破壊的変更で、新規ユーザーの問い合 わせが失敗 検知が遅れ、233⼈の問い合わせが失敗 どれも、誰かが気づくまで壊れたままだった 

しかも、売上に直結する導線で起きていた トップ 検索 物件詳細 お問い合わせ • CANARYは、お問い合わせが成功した仲介会社から成果報酬を得ている • この導線が壊れると、ユーザーはそのまま離脱する • つまり不具合が、そのまま売上の毀損になる 監視があれば、影響は最⼩限にできた 完了 

AI時代、速さを保つには「守り」が要る 攻め 守り 速く作って速く届ける 壊れたことにすぐ気づける仕組み ‧コード⽣成からテストまで AI が担う ‧壊れたものが世に出る頻度も上がった ‧開発のリードタイムが短くなった ‧気づく頃には、影響が広がっている ‧リリース頻度も上がった 監視の価値は「検知までのリードタイムを縮めること」 

1. フロントエンド監視の守備範囲 

まず思い浮かぶのは、ブラウザ側のエラー • JavaScript のランタイムエラー • ブラウザ / OS / バージョン依存のエラー • API 通信の失敗やネットワークエラー • ブラウザ拡張機能に由来するエラー 

CANARYのアプリケーション構成 • Next.js（Pages Router） • CSR と SSR を併⽤ • GKE 上のコンテナとして デプロイ • Datadog で監視 ⾚枠が Canary-Web （Next.js / SSR を実⾏） SSR は Node.js の SSR サーバーで動いている 

SSR が普及したことで、責任範囲が動いた SPA が主流だった頃 SSR が普及してから ブラウザ ブラウザ サーバー（SSR） サーバー（SSR） インフラ（コンテナ） インフラ（コンテナ） ＝ フロントエンドエンジニアが気にしなければいけない範囲 サーバーやインフラの監視も、フロントエンドの持ち物になった 

監視対象は3つの層にまたがる ブラウザ サーバー（SSR） インフラ（コンテナ） • JavaScript ランタイムエラー • ブラウザ / OS / バージョン依存 • 拡張機能由来のエラー • サーバー実⾏時の JavaScript エラー • API 通信失敗によるレンダリングエラー • タイムアウト‧遅延 • コンテナのメモリ超過 • CPU 使⽤率のスパイク • スケーリングの問題 フロントエンドを名乗る以上、この3層すべてが守備範囲になる 

同じ障害でも、サーバーを⾒ていたかで結果が変わった 画⾯で⾒えたエラー サーバーで起きていたこと 「セッションの有効期限が切れたため、お問い合わせに失敗 しました」という画⾯だけ。 ブラウザのエラー監視には何も出ない 1秒に最⼤13件の 500 エラー 2025年2⽉ 2026年4⽉ サーバーを⾒ていたか ⾒ていなかった ⾒ていた 結果 233⼈の問い合わせが失敗 エラー急増から2分で検知 ブラウザから⾒える「結果」は同じ。違いはサーバーを⾒ていたかどうか 

2. 監視設計 

監視って、 たくさん⼊れればいいんでしょうか？ 

監視も「たくさんすればいい」 ものではありませんでした 

とりあえずブラウザ監視を⼊れてみた • まずは⾒えるようにしよう、と全部拾う設定にした • アラートも⼀通り設定した 結果、通知が鳴り⽌まなくなった 

鳴っていたのは、アプリケーションと関係ないエラー 実際に鳴ったエラー 何だったか Load failed / Network Error ユーザー側の回線 Script error. 外部スクリプトのエラー（中⾝が⾒えない） AbortError: AbortError 画⾯遷移などでリクエストが中断された UnknownError: Connection to Indexed Database server lost ブラウザ内部のエラー Error: La ブラウザの Google 翻訳が DOM を書き換えた 対応しようのないものばかりが並んでいた 

当時のアラート件数 ⽉ 約500件 2025年4⽉〜10⽉の7ヶ⽉間で合計 3,515件 

いわゆる「狼アラート」状態 17:45 Triggered 新しい issue 20:55 Triggered エラー数が増加 22:25 Recovered エラー数が増加 23:35 Triggered 新しい issue 17:55 Recovered 新しい issue 21:02 Warn 22:36 Warn 23:44 Warn 18:15 Triggered 新しい issue 21:03 Triggered エラー数が増加 22:37 Recovered エラー数が増加 23:45 Triggered エラー数が増加 19:25 Triggered 新しい issue 21:19 Warn 22:44 Warn 23:47 Warn 19:48 Warn 21:25 Recovered エラー数が増加 22:45 Recovered エラー数が増加 23:48 Triggered エラー数が増加 20:11 Triggered エラー数が増加 21:50 Warn 22:46 Warn 00:20 Warn 20:17 Warn 21:51 Recovered エラー数が増加 23:21 Triggered エラー数が増加 00:27 Recovered エラー数が増加 20:26 Recovered エラー数が増加 21:52 Warn 23:22 Warn 00:40 Warn 20:28 Warn 22:05 Recovered 新しい issue 23:23 Triggered エラー数が増加 20:43 Recovered エラー数が増加 22:13 Triggered エラー数が増加 23:24 Warn 20:44 Warn 22:16 Warn 23:31 Triggered エラー数が増加 エラー数が増加 エラー数が増加 エラー数が増加 エラー数が増加 エラー数が増加 エラー数が増加 エラー数が増加 エラー数が増加 エラー数が増加 エラー数が増加 エラー数が増加 エラー数が増加 エラー数が増加 エラー数が増加 鳴っても誰も⾒ない。アラート運⽤が形骸化していた エラー数が増加 エラー数が増加 エラー数が増加 エラー数が増加 

監視にも「選択と集中」が必要だった 

何を通知させ、どう対応するか Q1 ⾃分たちで 直せるか？ Q2 壊れたら、お客様や売上に響くか？ 響く 響かない Slack にアラートで迅速対応 アラートは鳴らして別途対応 例：問い合わせ送信が全件失敗 例：軽微なバグ アラートは鳴らすが記録のみ フィルタなどで対応不要 例：バックエンド‧外部サービスの障害 例：Google 翻訳‧拡張機能‧CSP 直せる 直せない アラートにするのはアプリケーションで発⽣したエラーのものだけ 

CANARY で実際に鳴らしているアラート 層 アラート 何が起きたら鳴るか ブラウザ＋SSR 【Web】新しい issue が発⽣しました 新しいエラーが1件でも出たとき ブラウザ＋SSR 【Web】エラー数が増加しています 1つのエラーが30分で300件を超えたとき サーバー（SSR） 【Web】SSRサーバーでエラーが発⽣していま す SSR サーバーへのリクエストのエラー率が上 がったとき インフラ（コンテナ） 【Web】メモリ使⽤率‧CPU 使⽤率が 80% を 超えています コンテナのメモリや CPU が上限に近づいた とき（OOM で落ちる前に気づける） 3つの層それぞれに、すぐ鳴らすものを置いた 

拾うものを絞って、 はじめてアラートが意味を持つ 

通知は⾶ぶようになった。で？ 

このアラート、誰が対応するの？ チャンネルには 全員いる でも、担当は 決まっていない 全員が「誰かが ⾒ているだろう」 と思う 全員に届く通知は、誰にも届いていない 結局、 誰も⾒ない 

鳴るようになっても、運⽤は回らなかった • エラーの重要度を判断する基準がなかった • 誰が‧いつまでに‧どう対応するかが決まっていなかった • 結果、重要なバグが他の通知に埋もれた 通知を送ることは、ゴールではない 

⽬的は「継続的な品質改善」 ── チームで回せる運⽤にすること 

そのために決めた3つ 優先度の基準 担当の決め⽅ 対応⼿順 • P1 は即時、P2 は当⽇中、P3‧P4 は24時間以内 • 「いつまでに」を決めて、鳴った瞬間に動けるようにする • 平⽇⽇中はローテーション、時間外はテックリード • 「⾃分の番かどうか」を考えなくていい状態にする • Runbook として書き、属⼈性を下げる（次ページ） 基準‧担当‧⼿順。この3つがないと通知は流れていくだけ 

3つめの「対応⼿順」＝ Runbook Runbook とは 何を書くか なぜ要るか • 障害やアラートが起きたときの対応⼿順書 • インフラ‧SRE の現場で広く使われている⼿順書 • どこを⾒て切り分けるか∕どう直すか∕誰に上げるか • 「この順番でこう動く」を⼿順として書き下す • 当番が誰であっても、同じ初動が取れる状態をつくるため 属⼈化をなくすための⼿順書 

3. AIで運⽤を回す 

これまでは、すべて⼈間がやっていた 検知 調査 要約 優先度判定 対応要否の判断 修正 すべて⼈間がやっていた 基準と⼿順は決めた。でも、⼿を動かすのは全部⼈間だった レビュー‧ マージ 

例えば、このアラート 鳴ったのは Error: La ⼈がやったこと 監視ツールで エラーを開く エラーの 内容を読む 検索や AI に ⾃分で聞いて 調べる ブラウザの Google 翻訳が DOM を書き換えて いたと分かる 「対応不要」と分かるまでに、⼯数がそれなりにかかる 結論は 「対応不要」 

判断と修正まで、AIに渡す 

数ある AI エージェントの中から、Devin を選んだ理由 1 2 → 監視ツールの AI に 縛られない 領域ごとに AI を 使い分けない だから、 汎⽤的な Devin 1つの監視ツールに依存する メンバーはフルスタックで開発 どの領域のアラートも、同じ と、破壊的変更が⼊ったときに する。領域ごとに違う AI だ AI‧同じ流れで任せられる 運⽤ごと⽌まってしまう と、コンテキストスイッチが起 きる Devin は Cognition 社が開発する⾃律型の AI ソフトウェアエンジニア。コードを読み、書き、テストし、PR を出せる ツールにも領域にも縛られない AI を選んだ 

Devin Automations とは 仕組み 設定するもの 今回使っているもの Slack のメッセージ、GitHub の Webhook、Linear のチケット更新などの外部イベ ントを、⾃動で始まる Devin のセッションにつなぐ 「何が起きたら（トリガー）」と「Devin が何をするか（アクション）」 Slack チャンネルを⾒張り、対応が必要なものに⼦セッションを起動する常駐型の Devin（Triage Devin） 「調べるAI」ではなく「直すAI」を置いた 

Devin Automations の全体像 Step 1 Step 2 Step 3 Step 4 Step 5 アラート通知 Triage Devin が 拾う Runbook を開く 調査‧判定 スレッドに返信 アラートが Slack のチャンネルに届 く 対応が必要なもの に⼦セッションを 起動する アラート本⽂に 貼ってある Runbook のリンク から⼿順を読む Runbook に沿って 原因を調べる 判定と根拠を返 す。修正は頼めば Devin が PR まで アラートが鳴ってから⼈が⾒るまでの間を、AIが埋める 

Devin の判断は3つに分かれる 対応不要 • 判断の根拠を添えて、対応不要としてクローズする 要対応 • 原因を特定して返す。修正は Devin に頼んで PR を出す 判定不能 • 調査結果をまとめて、当番にエスカレーションする ⼈間は「決めること」だけに集中できるようになった 

肝は、Devin に読ませる Runbook 

Runbook ①：これは何か‧対応が不要な条件 # 【Web】新しい issue が発⽣しました / エラー数が増加しています 実際の Runbook より抜粋 ## これは何？ - 新しい issue が1件でもできたとき：P1。Devin の判断を待たずに担当者にメンションする - 1つの issue が30分で300件を超えたとき：P2。判断が出てからメンションする ## 対応が不要な条件 ページが表⽰できない場合と、bot 以外の利⽤者に 500 が出ている場合を除き、 次のいずれかに当てはまるとき - 「対象の特定」の表で、対応が「対応不要」の⾏に⼀致する - UA が bot だけで、SSR のタイムアウトが⼀時的に出ている - 対応ブラウザの範囲外のブラウザだけで出ている - 同時刻に鳴ったバックエンドのアラートと同じ原因 「捨ててよい条件」より先に「捨ててはいけない例外」を書く 

Runbook ②：既知のエラーと対応（抜粋） エラーメッセージ 原因 対応 SecurityError: history.replaceState() more than 100 times per 10 seconds 検索結果の無限スクロールが、API エラー時にループす る（⾃分たちのバグ） 修正（Draft PR） Error: La ブラウザの Google 翻訳が DOM を書き換えた 対応不要 findLastIndex is not a function 対応ブラウザバージョンの範囲外 対応不要 csp_violation を含むもの ブラウザ拡張や外部タグが CSP でブロックされた 対応不要 Error: Database is closing 認証ライブラリ内部の競合 対応不要 timeout of 10000ms exceeded（SSR） bot のクロールで API が⼀時的に遅れた bot だけなら不要 / 他は ⼈へ 実際の Runbook より抜粋（9種類のうち6種類を掲載） 9種類のうち、コードを直す必要があったのは1種類だけ 

⼈間向けの Runbook との違い • 曖昧な⾔葉を使わない：「必要に応じて」「適宜」ではなく、条件を事実で書く • 禁⽌事項を明⽰する：⼈なら常識で避けることも、AIには書かないと伝わらない • 根拠を残させる：クローズするときも理由を書かせ、⼈が後から検証できるようにする ⼈間なら「雰囲気」で補える部分を、全て⾔語化する 

Runbook は育てるもの 01 02 03 Devin が判断 ⼈がレビュー Runbook を直す Runbook に沿って対応‧報告 する PR やクローズの判断を確認す る 判断ミスは出⼒ではなく⼿順 書を直す 04 次から反映 同じミスを繰り返さなくなる AIの精度を限りなく近いものにするために、Runbook を直す 

AIと⼈間の境界が、ここまで動いた 検知 調査 要約 優先度判定 対応要否の判断 修正 AI がやる ⼈間が触るのは、最後のレビューと判定不能のものだけ レビュー‧ マージ ⼈間がやる 

Devin が実際に返した判定 実⾏した Runbook の⼿順まで書いて返してくる ⼈は根拠を読んで「対応不要」ボタンを押すだけ 

導⼊してどう変わったか 放置されたアラート 49% → 13% ⼈が誰も対応しなかった割合 ⼈が動き出すまで 31分 → Devin の⼀次判定 16分 ⼈の最初の対応まで（中央値） Devin の判定の内訳 対応不要 13 ∕ 判定不能 13 ∕ 要対応 6 0件 → 32件 全件を判定。判定まで中央値 4.4分 修正は Devin に頼んで PR まで 運⽤前 8/26〜9/17（69件）→ 運⽤後 9/18〜10/8（32件）。時間は⼈が対応した件のみで集計。件数が少なく、アラートの種類も変わっているため参 考値 アラートが放置されなくなり、⼈が動き出すまでの時間は半分に 

AIに任せられる範囲は、 ⼈が書くドキュメントの精度で決まる 

まとめ • フロントエンド監視はブラウザだけでは⾜りない。サーバーまで⾒る • 監視も「選択と集中」。全部は拾わない • 通知を送ることはゴールではない。チームで回せる仕組みにする • AIに任せられる範囲は、⼈が書くドキュメントの精度で決まる お客様に教えてもらうまで4⽇ → 今はエラー急増から2分でアラートが鳴る 

ご清聴ありがとうございました！