Playbooks
継続監視でUI品質の後退を検知する
一度直したUI品質は、キャンペーン更新、CMS変更、タグ追加、デザイン改修で後退します。継続監視は、悪化を早く検知し小さく直すための運用です。
ui.design: monitorui.design: technical
まず確認する症状
- 修正後しばらくして、CTAやフォームの表示が崩れる。
- 外部タグ追加後に速度やレイアウトシフトが悪化する。
- 診断結果はあるが、業務の意思決定、担当分担、納品物、次回検証へ変換されていない。
- 業種やページ種別の違いを見ず、全ページを同じチェック順で扱っている。
なぜ問題か
- 定期スキャンと差分があれば、いつ何が悪化したかを追いやすくなります。
- 重大所見だけ通知するルールにすると、1人運用でも確認負荷を抑えられます。
- プレイブックは知識記事を実務に変える手順です。見る順番、成果物、完了条件があると少人数でも繰り返せます。
- 人間が判断する部分とAIが修正する部分を分けることで、品質と速度の両方を管理できます。
診断で見る指標
定期スキャン間隔
新規serious/critical所見
スコア差分
Core Web Vitals
通知先
対象ページ種別
最初に見る導線
成果物一覧
担当者と期限
次回スキャン条件
監視頻度
重大度閾値
差分Issue化
外部タグ変更
修正方法
最小修正
監視対象ページを絞る
トップ、主要LP、フォーム、購入導線など、事業影響が大きいページから始めます。
推奨修正
通知ルールを決める
新規重大所見、スコア大幅低下、診断不能、成果物生成失敗だけ通知します。
さらに改善
差分を修正Issueへ変換する
前回との差分を、修正ガイド付きの小さなIssueへ起票します。
受け入れ条件
- 01PCとスマホの両方で目視確認し、主なCTAまたは操作対象が迷わず見つかる。
- 02キーボード操作、読み上げ補助、または自動検査で再発しやすい項目を確認する。
- 03修正後にui.designで再スキャンし、同じ所見が残る場合は原因を分解する。
- 04その業務で最初に見るべき3から5項目、当日直す項目、保留する項目、次回検証方法が分かれている。
- 05レポート、タスク、証跡、修正指示を、顧客または開発者がそのまま使える粒度で残している。
- 06監視対象は事業影響が大きいページから始まり、新規重大所見、スコア大幅低下、診断不能など通知条件が明確である。
- 07差分は、前回から悪化した原因、影響ページ、修正ガイド、担当者、期限へ変換されている。
コーディングエージェント向け修正指示
目的: 継続監視の対象URL、頻度、通知条件、差分レポート、修正Issue化の流れを設計してください。全ページ監視に広げすぎず、事業影響が大きい導線から始めてください。 追加確認: 継続監視は全所見通知にせず、重大悪化、CV導線、成果物生成失敗、Core Web Vitals悪化に絞って運用を始めてください。
参考資料
よくある失敗
- 全所見を毎回通知し、重要な悪化が埋もれる。
- 見た目だけを整え、見出し、リンク、フォームラベルなどの意味構造を直さない。
- 1つの指摘だけを直し、同じ原因から出た別画面の再発を確認しない。
- スコアを説明して終わり、誰がいつ何を直すかを決めない。
- 全ページを同じ深さで見ようとして、事業影響が大きい導線の修正が遅れる。