サイトの保守契約書に、こんな一文が入っていないでしょうか。「主要ブラウザの最新版において動作確認を行う」。
この一文だけでは、更新のたびに確認するのか、月次・四半期の点検なのかが分かりません。Chrome は2026年9月8日の153から、安定版のリリース周期を4週間から2週間に変更しました。
毎リリースの確認を契約しているなら、Chrome の確認の節目が増えます。一方、保守工数や料金が自動的に倍になるわけではありません。契約の頻度、変更内容、自動化の範囲で必要な作業が変わります。
増えたのは「リスクの量」ではなく「節目の数」
先に誤解を解いておきます。更新が速くなったからといって、サイトが壊れる確率が2倍になったわけではありません。
追加される機能の総量は、これまでと大きく変わりません。変わったのは、その機能が届くまでの時間と、区切りの数です。1回あたりの変更が小さくなり、その代わり回数が増えます。1回の更新で入る変更が小さいということは、1回あたりの事故の規模も小さくなる方向に働きます。
一方で、確認作業のほうは回数に比例します。ここに認識のずれが生まれます。
| 変わったこと | 実務への影響 |
|---|---|
| 更新の間隔が2週間に | 区切りの数が倍になる |
| 1回あたりの変更量 | むしろ小さくなる |
| セキュリティ更新 | 従来どおり別枠で随時 |
つまり、増える作業は「壊れていないことの確認」であって、修正そのものではありません。 ここを分けて考えると、保守の設計が変わります。
全部を確認しようとしない
現実的な打ち手は、すべての更新に同じ確認をしないことです。次の3つに分けます。
1つめは、基本的な静的ページ。 代表ページの表示とリンクを軽い自動チェックに含め、CSS やフォントに影響する更新時には目視も行います。静的ページなら無条件で確認不要、という意味ではありません。
2つめは、壊れると売上が止まるページ。 問い合わせフォーム、見積もり計算、決済、ログインです。ここは回数を増やすのではなく、人が見る確認から、自動で動かす確認に変える判断をします。テスト用の宛先や検証環境を使い、実際の営業通知や顧客登録を増やさずに送信経路を確認する仕組みを作ります。決済はテストモードを使います。
3つめは、新しい表現を使っている箇所。 最近実装したアニメーションやレイアウトが、まだ新しい仕様に依存している場合です。ここは制作会社に一覧を出してもらってください。
企業向けの「遅いチャンネル」は解にならない
ここで必ず出る提案が、更新の遅いチャンネルを社内に配るという話です。Chromeには8週間ごとに更新する企業向けのチャンネルがあります。
ただし、これは社内のPCの話であって、サイトを見に来るお客様には関係ありません。 自社の端末を遅いチャンネルに固定しても、訪問者のブラウザは2週間ごとに新しくなります。むしろ、社内だけ古い環境で確認して「問題なし」と判断してしまう危険があります。
社内端末の更新方針と、サイトの動作確認の方針は、別の話として設計してください。混ぜると、一番まずい「社内では見えない不具合」が生まれます。
確認より先に「気づける」ようにする
更新の頻度が上がったときに本当に効くのは、確認の回数を増やすことではなく、壊れたときに気づく仕組みを持つことです。
2週間ごとに人が見ても、見た翌日に壊れれば13日間気づきません。一方、問い合わせの件数推移とエラー率を見れば、異常の手がかりになります。ただし、もともと件数が少ないサイトではゼロ件が正常な日もあります。テスト送信や到達監視と併用します。
最低限、次の2つは持っておく価値があります。
- 問い合わせや資料請求の件数の推移。平常時の水準を知らないと、減ったことに気づけません。計測が抜け落ちている典型例は発注したサイト、成果はちゃんと測れていますかにまとめています
- ブラウザ上で発生したエラーの通知。訪問者の画面で起きた不具合は、サーバー側のログには残りません
この2つは、定期的な動作確認を補うものです。 ブラウザの更新サイクルに合わせて人の作業を増やす方向は、費用が上がり続けるわりに、事故の発見が遅いままです。
同じ議論は開発言語やフレームワークの側でも起きています。更新の頻度が上がったときに何を決めておくかはNode.js が年1回のメジャーリリースへでも扱いました。
契約と見積もりで確認すること
保守契約を結んでいる、あるいはこれから結ぶなら、次の3点を確認してください。
- 動作確認の対象が「最新版」で固定されていないか。 対象ブラウザと確認の頻度を、更新サイクルから切り離して定義し直します。「四半期に一度、主要ブラウザの当時点の安定版」のほうが実態に合います。
- 確認の対象ページが特定されているか。 「全ページ」と書くだけでなく、確認内容と自動化の範囲を明記します。売上に直結する数ページを名指しで書きます。
- 確認の回数増を理由にした値上げに、根拠があるか。 回数が倍でも、自動化されている部分は費用が倍になりません。保守費の内訳を確認する考え方は保守費の値上げ理由が「CI費用の高騰」だったにまとめています。
そもそも保守契約に何を書いておくべきかは納品されたら終わり、ではないで扱いました。放置した場合に何が起きるかは「作って終わり」のホームページが危険な理由のとおりです。
次にやること
まず、手元の保守契約書を開いて、動作確認に関する一文を読み直してください。 「最新版」という文言だけなら、いつ・何を確認する契約なのかを具体化します。
そのうえで、壊れたら困るページを3つ挙げて、制作会社に伝えてください。 全ページを均等に守る契約より、この3つを機械で毎日確かめる契約のほうが、同じ予算でリスクが下がります。ブラウザの更新を追いかけるのではなく、自社のどこが止まると困るのかから逆算するほうが早いです。
ホームページの保守内容の見直し、動作確認の自動化、リニューアルのご相談は、グリームハブで承っています。サイトの構成と機能によって必要な確認の範囲が変わるため、要件に応じて個別にお見積りします。お問い合わせからご相談ください。
