Webサイトの公開後には、情報が変わり、利用者の疑問が集まり、動作上の問題が見つかります。AI検索が話題になる前から必要だった運用を、いまの提供条件と体制で続けられるようにすることが出発点です。
30秒で要点
- 動作、情報、導線、計測を分け、重要な問題から確認します。
- 変更の仮説、担当、期限、戻し方を記録します。
- 時間価値と現金支出を分け、順位やAI掲載、売上を保証しません。
公開後の四つの点検領域
表が収まらない場合は、横にスクロールできます
| 領域 | 具体的な確認 | 必要な情報 |
|---|---|---|
| 動作 | 問い合わせが届くか、重要な操作が止まらないか | 動作確認・障害報告 |
| 情報 | 料金、提供範囲、担当、注意事項が現状と合うか | 社内の責任者による確認 |
| 導線 | 必要な情報を見つけ、理解し、行動できるか | 質問・観察・問い合わせ内容 |
| 計測 | 定義や設定が変わっていないか | 変更履歴・欠測・重複の確認 |
更新する記事数だけでは、どの問題を減らしたか分かりません。日付だけの更新や、同じ内容の量産ではなく、読者の判断に必要な情報が変わった時に見直します。Googleのpeople-firstの資料も、内容を変えずに新しく見せる日付更新を有益な作業としていません。
データ、相談、実際の操作を組み合わせる
アクセス解析は入口や行動の傾向を示しますが、それだけで利用者の心理は分かりません。相談で繰り返される質問、応対者が困った点、必要な作業の観察を合わせると、調べる仮説を絞れます。
「料金ページの離脱が多い」なら、価格が高い以外にも、情報を読み終えた、対象外だと分かった、別の端末で相談した、計測できなかったなどの可能性があります。離脱率だけで恐怖や不満を断定せず、追加の確認方法を決めます。
表が収まらない場合は、横にスクロールできます
| 材料 | 分かることの例 | それだけでは分からないこと |
|---|---|---|
| アクセス | どこから、どの画面へ進んだかの観測 | 全利用者の意図や原因 |
| 問い合わせ | 実際に言語化された疑問 | 問い合わせなかった人の事情 |
| 操作の観察 | 課題中に迷った箇所 | 市場全体の発生率 |
| 技術の監視 | エラーや処理時間の観測 | 事業成果の因果関係 |
小さな変更にも責任と戻し方を付ける
改善を始める時は、対象、仮説、担当者、確認者、期限、観測するもの、戻す条件を記録します。たとえば申込条件が分かりにくいという仮説なら、条件の説明を変更し、相談内容と利用上の問題を確認します。複数の大きな変更を同時にした場合は、その限界を残します。
重要な申込や個人情報の扱いに触れる変更は、担当者だけで公開可否を判断せず、必要な責任者と確認します。段階的な公開や戻せる状態の保持も、影響に応じて検討します。改善の速度だけを優先して、確認を省くことは継続運用ではありません。
記入済みの変更票で、作業を引き継ぐ
ここでは「サービス対象外の地域から相談が届く」という架空の問題を使います。料金ページを見た人が誤解したと決めつけず、受付記録と案内文を照合してから変更を提案します。
表が収まらない場合は、横にスクロールできます
| 変更票の欄 | 記入例 |
|---|---|
| 観察した問題 | 相談記録に対象地域の確認が必要な案件がある。発生数と入口はまだ確認途中 |
| 仮説 | 申込ボタンの前で対象地域が分かれば、対象外の人が無駄な入力をせずに済む可能性がある |
| 変更範囲 | 既存の対象地域説明を申込ボタン直前にも短く掲示し、詳細条件へのリンクを置く。受付条件そのものは変えない |
| 承認者・作業者・確認者 | サービス責任者が条件を承認、制作担当が配置、受付担当が案内と到達確認を点検する |
| 開始と期限 | 承認後をD0、D+14を最初の確認日とする。14日で因果効果が確定するという意味ではない |
| 観測 | 地域の問い合わせ理由、有効相談と対象外相談、条件不明の案件、重要な操作の不具合を同じ定義で記録する |
| 戻す条件 | 対象地域の誤表記、ボタンが操作できない、条件と違う案内が出る場合は、責任者へ連絡して保存済みの前版へ戻す |
| 保留条件 | 入口の計測や地域の分類が確認できない場合は効果判定を保留し、欠測理由を記す |
制作担当は、変更前の文章と設定、戻すために必要な素材を確認してから着手します。戻した後にも、古い料金やリンクを復活させていないかを点検します。「元に戻せるはず」と「必要な条件で復旧を試した」は別の状態です。この例は変更票の書き方であり、実際の公開や復旧試験を完了した記録ではありません。
確認日には「対象外相談が減った」の一行だけで終えません。対象外だと正しく分かった結果なのか、有効な相談まで進めなくなったのか、案内や計測が変わったのかを調べます。判断がつかなければ、追加で必要な観測と担当を決めて保留します。
影響、緊急性、作業量を別々に並べる
改善候補を単一の点数で順位付けすると、安全上の問題を「作業量が大きいから後回し」にしてしまうことがあります。まず重大な不具合を切り分け、その後に影響する作業と確認の負荷を比較します。次の見積もりも架空です。
表が収まらない場合は、横にスクロールできます
| 候補 | 影響と緊急性 | 作業量の仮見積もり | この例の順序 |
|---|---|---|---|
| 問い合わせが担当へ届かない | 受付が止まる。発生確認と暫定案内が急務 | 原因が未確定で見積もれない | 最優先で調査し、代替連絡先など実施可能な対応を責任者が判断 |
| 対象地域の案内が分かりにくい | 不要な入力を減らせる可能性。誤表記の有無を先に確認 | 文章・配置・確認で半日を仮置き | 障害対応と並行可能かを確認し、上の変更票で範囲を絞る |
| 見出しの装飾をそろえたい | 今の情報理解への支障は未確認 | 一日を仮置き | 先の二件を圧迫しない範囲へ保留 |
半日や一日は効果量ではなく、担当が更新する作業見積もりです。影響が分からなければ小さな調査を先に入れ、見積もりが変わった理由を残します。短い作業から機械的に実施することも、すべてを緊急と呼ぶことも避けます。
頻度より先に担当と情報の変化を決める
毎週更新が必要かどうかは、情報の変化と影響に依存します。サービス停止など迅速な対応が必要な問題と、月単位で傾向を見る内容を同じ周期にしないでください。
社内は提供条件、顧客の質問、業務上の判断を持ち寄ります。制作側は実装、調査方法、技術的な影響を説明します。どちらかへ丸投げせず、承認者、作業者、確認者と、障害時に戻す判断をする人を決めます。
英国GDSの運用段階の資料も、公開後の利用者調査、品質、セキュリティ、性能、指標と、状況に見合う持続可能な体制を扱っています。行政サービス向けの方法論を参考にするもので、すべての企業に同じ人数や会議周期を義務付けるものではありません。架空の時間削減をどう評価するか
ある月に作業を6時間短縮できた一方、確認と修正が2時間増えたと仮定します。正味は4時間です。社内で置いた評価単価が1時間3,000円なら、時間価値は12,000円と計算できます。
これは現金が12,000円浮いたという意味ではありません。給料や契約の支出が変わらなければ現金削減は別です。追加ツール、外注、初期実装、教育などの費用も確認し、時間価値を二重に計上しないでください。仮想計算だけでROIや実際の改善効果を断定しません。
少ない観測で結果がばらつく場合は、期間や対象を変える前に条件を記録します。季節、広告、商品、計測設定が変わったなら、変更前後の数値だけを原因の証明として使わないでください。
AI検索を特別な成果保証にしない
AIが答えを作る機能でも、内容の信頼性や読者の役立ち方を点検することは重要です。しかし、「構造化データがないとAIは理解できない」「更新すれば必ず引用される」とは言えません。
GoogleのAI機能向けガイドは、通常の検索の基礎を示し、Google向けに特別なAIマークアップやllms.txtが必要だとはしていません。Google以外のサービスや実アカウントの条件を一括りにせず、現在の公式条件を必要範囲で確認します。予測記事の割合を、現在の実測や自社への影響として使わないことも大切です。AIを原稿や分析の補助に使う場合も、事実、計算、権利、機密、業務条件を人が確認します。説明が流暢であることと、自社の判断に使えることは別です。
継続、保留、戻す判断を残す
変更が狙った問題を減らし、別の問題を増やしていないかを確認します。結果が不明なら保留し、重大な不具合や誤情報があれば戻します。採用した変更だけでなく、採用しなかった理由も残すと、次の担当者が同じ検討を繰り返さずに済みます。
Web制作の全体像で役割と工程を整理し、性能の問題にはCore Web Vitalsと事業上の判断、情報の迷いにはプロトタイピングを使って、次の確認を具体化してください。