サイトの保守は何をどこまで頼むか｜止めないための取り決め

「保守費を毎月払っているのですが、何をしてもらっているのか社内に説明できません」「保守はサーバー代のことだと思っていました」。——公開から1年ほど経った会社との打ち合わせで、この2つはほぼ同時に出てきます。保守は、壊れたときのために積み立てておく費用ではありません。本当は、自社が何もしなくても外側の期限が勝手にやって来るので、その期限に合わせて手を入れ続けるための費用です。事故が起きていない平常時にこそ作業が発生する、という点がふつうの保険と違います。この記事では、公開後のサイトに発生する作業を5つの区分に分け、外に頼む範囲と社内に残す範囲の決め方、費用の形と桁、止まったときの動き方、契約に書いておく項目までを順に整理します。

保守は、壊れたときのための積み立てではない

見積書に「保守費」と1行だけ書かれていると、火災保険のような備えに見えます。何も起きなければ払い損で、何か起きたときに助けてもらう費用だ、という読み方です。この読み方をしていると、金額の大小しか見えません。実際には、保守として発生する作業の大半は、事故が起きていない平常時に発生します。理由は単純で、サイトが自社の持ち物だけで動いていないからです。

公開されたサイトは、少なくとも3つの外側に依存しています。依存先が3つあるということは、期限も3系統あるということです。1つ目は借りている場所で、サーバーとその上で動く言語の版がこれに当たります。2つ目は載せている仕組みで、記事を管理する本体と、機能を足すために入れた部品の集まりです。3つ目は証明する仕組みで、通信を守る証明書と、住所そのものであるドメインです。この3つはどれも、自社の都合とは無関係に期限が来ます。

だから保守の見積りは、「何かあったときにいくらか」ではなく「毎年必ず来る作業がいくつあり、そのうちどれが含まれているか」で読みます。読み方を変えると、比べ方も変わります。安く見えた見積りに期限の管理が入っていない、という状態が最も多く、そこが抜けたまま2年ほど動くと、切り替えの日に慌てることになります。

公開後に発生する作業を、5つの区分に分ける

範囲を決めるには、まず作業を分けます。分け方は5つで十分です。止まったときの復旧。中身の更新。土台の更新。安全のための更新。監視と控えの取得です。この5つは、頼み方も費用の形も、必要な速さもそれぞれ違います。ひとまとめに「保守」と書いてしまうと、何が入っていて何が入っていないのかを確かめる手がかりが消えます。

• 止まったときの復旧——表示されない、管理画面に入れない、注文が受けられない。速さが要るが、発生の頻度は読めない
• 中身の更新——文言の差し替え、画像の入れ替え、お知らせの追加。件数で見積もれる。社内でできる範囲が最も広い
• 土台の更新——サーバーの環境や言語の版の切り替え。年に1回か2回、期限のほうから日程がやってくる
• 安全のための更新——本体と部品の修正版を当てる。頻度が高く、緊急のものが混じる。放置した日数がそのまま危険になる
• 監視と控え——動いているかを見張る仕組みと、定期的な控えの取得。作業というより、常に動いている装置に近い

この5区分で見積りを読み直すと、抜けている行がはっきりします。よくあるのは、4つ目の安全のための更新が入っていない見積りです。文言の差し替えと、動いているかの見張りだけが入っていて、修正版を当てる作業が範囲の外に置かれている。見積りを比べる前に、5つの区分のどれが入っているかを1行ずつ確認するだけで、比較の土台がそろいます。

土台の更新は、自社の都合と無関係に期限が来る

いちばん見落とされるのが、この3つ目です。サイトを動かす言語には、版ごとに修正の提供期限があります。広く使われている言語の1つは、新しい版が出てから4年で提供が終わります。内訳は決まっていて、最初の2年は不具合と安全の両方を直し、続く2年は重大な安全の問題だけを直します。4年を過ぎると、穴が見つかっても修正が出ません。

具体的な日付で見ると、切迫しているのが分かります。2022年12月に出た版は、2024年末に前半の期間が終わり、2026年12月末で後半も終わります。2023年11月に出た版は2027年12月末、2024年11月に出た版は2028年12月末です。つまり、2026年のいま公開しているサイトの多くは、あと数か月から1年ほどで土台の切り替えの日程に入ります。この日程は交渉できません。決めているのは自社でも制作会社でもなく、言語を提供している側です。

切り替えると、動かなくなる箇所が出ます。古い書き方をしている部品、独自に足した処理、外部との連携部分が典型です。壊れるのは切り替えた瞬間なので、切り替え日を知らされていない社内は原因を別の場所に探しに行きます。だから土台の更新は「作業」ではなく「日程」として扱います。まず期限の一覧を作り、切り替えの2か月前に試す環境で動かし、壊れた箇所を直してから本番を切り替える。この段取りが保守の範囲に入っているかどうかが、実際の金額差になります。

安全のための更新は、放置した日数がそのまま危険になる

4つ目の区分の重さは、直近の事例で確かめられます。2026年7月22日、公的機関が、広く使われている記事管理の仕組みについて注意を呼びかけました。2つの問題を組み合わせると、権限を持たない第三者が、遠隔から任意のプログラムを実行できてしまうという内容です。影響する版が3系統にまたがっており、それぞれ別の修正版に上げる必要がありました。呼びかけの文面は「直ちに更新することが推奨されています」でした。

怖いのは、時間の余裕がなかったことです。公的機関が呼びかけを出す数日前の時点で、すでに実際に狙われている通信が観測されていました。しかもこの問題は、攻撃の前提条件がありませんでした。管理画面に入られていなくても、追加の部品を1つも入れていなくても、外から見えている状態であれば対象になる、という性質です。小さいサイトだから狙われない、という前提はここで崩れます。探しているのは人ではなく、自動で回り続ける仕組みだからです。

この種の問題が起きたとき、社内で最初に必要になるのは技術ではありません。いま自社のサイトがどの版で動いているのか、誰が更新できるのか、更新して壊れたときに誰が戻すのか、という3つの答えです。3つとも即答できない状態は、更新を当てるまでの時間が数日単位で延びます。延びた日数が、そのまま危険にさらされた日数になります。

更新の件数は、片手間で追える量ではない

では全部の情報を追えばよいのか、というと、量が現実的ではありません。ある専門企業がまとめた集計では、2025年の1年間に、この分野で新しく見つかった問題は11,334件でした。2024年の7,966件から42%増えています。内訳は、9割超が追加で入れる部品側、9%が見た目を作る着せ替え側で、本体そのものの問題はごく少数です。穴の大半は、本体ではなく後から足した部品から出ています。

このうち、大量の自動攻撃の標的になりやすい高深刻度と判定されたものが1,966件、全体の17%でした。さらに、公開された時点でまだ修正が出ていなかったものが46%あります。つまり、情報を知っても当てるものがない期間が、半分近くのケースで存在します。その間にできるのは、その機能を一時的に止める、前段で通信を絞る、といった別の手です。なお、この数値は特定の1社が自社の集計として公開したものであり、公的な統計ではありません。桁を見るための材料として扱ってください。

結論としては、全部を見るのではなく、自社が使っている部品の一覧を先に作ります。見る量を減らすのではなく、見る対象を自社に絞るという考え方です。名前、用途、提供元、いまの版、入れた理由の5列で十分です。一覧があると、届いた情報が自社に関係あるかを数分で判定できます。逆に、一覧がないまま保守を頼むと、相手側も何を見張ればよいのか決められません。

自動更新に任せられる範囲と、任せられない範囲

「自動更新にしてあるから大丈夫です」という説明は、半分だけ当たっています。広く使われている記事管理の仕組みでは、細かい修正の版と翻訳の更新が既定で自動的に当たります。この仕組みが入ったのはかなり前の版で、いまはほとんどのサイトで有効です。一方で、大きい版の切り替えは、いつサイトを作ったかによって既定の挙動が違います。ある版より後に新しく作ったサイトは大きい版も自動で上がり、それ以前から動いているサイトは元の設定を引き継ぎます。

そして最も重要なのが、追加の部品と着せ替えです。これらは既定では自動更新されません。例外として、重大な問題が見つかったときに提供元の判断で修正が配られる仕組みはありますが、あくまで特殊な場合に限られます。前のセクションで見たとおり、問題の9割は部品側から出ています。いちばん危ない側が、既定では自動更新の外にある、という組み合わせになっています。

• 自動更新の設定は、部品ごとに1つずつ確認する——一括で有効にしたつもりが、一部だけ外れている例が多い
• 自動で当たった記録を残す仕組みを入れる——いつ何が上がったかが分からないと、壊れたときに原因を絞れない
• 自動更新を有効にするなら、控えを毎日取る設定と組で入れる——戻せない状態での自動更新は、事故を早めるだけになる
• 使っていない部品と着せ替えは、無効ではなく削除する——無効のまま置いた部品からも問題は出る
• 自動更新を止めている部品は、止めている理由を一覧に書く——理由が残っていないと、次の担当者が判断できない

証明書の期限は、これから3段階で短くなる

保守の回数が増える理由が、もう1つあります。作業の中身は変わらないのに、同じ作業の回数だけが増えていく種類の変化です。通信を守る証明書の有効期間が、段階的に短くなることが2025年4月に業界団体の投票で決まりました。それまでの最大398日から、2026年3月15日以降に発行するものは200日、2027年3月15日以降は100日、2029年3月15日以降は47日になります。あわせて、ドメインの使用権を確かめた情報を使い回せる期間も短くなり、最後は10日まで縮みます。

今日の時点で、すでに1段目に入っています。年に1回の更新作業として組んでいた保守は、いまは年に2回、2027年からは年に4回、2029年からは年に8回に近い頻度になります。回数が増えると、手で申請して手で入れ替える方式は必ずどこかで落とします。落とすと、訪問者の画面に警告が出て、その日から問い合わせが止まります。証明書の期限切れは、原因も直し方もはっきりしているのに、被害が即日で出るという珍しい種類の事故です。

だから保守の範囲には、更新作業そのものではなく、自動で入れ替わる仕組みと、失敗したときに気づく通知までを入れます。買うのは作業ではなく、落とさない仕掛けのほうです。契約書に書くなら「証明書の更新」ではなく「証明書の自動更新の設定と、期限の30日前および失敗時の通知」と書きます。誰の連絡先に通知が届くのかも、あわせて決めておきます。

ドメインは、手放すときにも判断が要る

ドメインの保守というと、更新を忘れないことだと思われがちです。それも大事ですが、実務でより厄介なのは、意図して手放すときのほうです。サイトを統合した、サービスを終了した、社名が変わった。こうした場面で古いドメインを廃止すると、そのドメインは第三者が新しく登録できる状態になります。登録を管理している側も、この点を明示して注意を促しています。

何が起きるかも具体的に示されています。廃止したドメインであっても、他のサイトからのリンクや検索側の評価に関する情報は残るため、詐欺のサイトや誹謗中傷のサイトに使われる可能性があります。同じドメインで同じメールアドレスを作られ、素性を偽ったメールに使われることもあります。そして、商標の侵害などの事由がない限り、第三者による登録と使用を差し止めることはできない、とされています。手放した瞬間に、自社の名前が付いた住所が誰でも使える状態になる、ということです。

だから畳むときには順番があります。廃止は最後の手順であって、最初の手順ではありません。終了することを外部に知らせる。そのメールアドレスで登録したアカウントを整理し、連絡先を切り替える。転送や設定を消す。そのうえで廃止する。組織名の変更や合併の場合は、複数の属性型ドメインを続けて使うための手続きが用意されているので、廃止する前に確認します。この段取りは制作の範囲ではなく、保守の範囲に入る仕事です。

外に頼む範囲と社内に残す範囲を、区分ごとに割る

ここまでの5区分に、割り先を当てていきます。基準は2つで足ります。期限が決まっていて手順が毎回同じものは外に出せます。判断が要るもの、社内の事情を知らないと決められないものは社内に残します。この2つで割ると、金額ではなく仕事の性質で線が引けます。実際に割ると、次のような形になることが多くなります。

公開後の作業	外に頼む向き	社内に残す仕事
止まったときの復旧	向く。時間外の受付と一次対応まで含めて頼む	社外への告知と、いつ何を伝えるかの判断
中身の更新	件数が多いか、崩れやすい箇所だけ頼む	文言の決定と、公開してよいかの確認
土台の更新	向く。試す環境での確認まで含めて頼む	切り替え日の承認と、影響を受ける部署への連絡
安全のための更新	向く。情報の収集と、当てる作業まで頼む	止めるか当てるかの判断と、費用の承認
監視と控え	向く。仕組みの設置と通知の設定まで頼む	通知の届く先の維持と、戻せるかの年次確認
部品の追加と入れ替え	作業は頼める	入れる理由と、増やしてよいかの判断
証明書とドメインの管理	自動化の設定は頼める	名義を自社で持つこと。ここは渡さない

右端の列が空にならない点が要点です。全部の行に社内の仕事が残ります。表の右端をすべて外に渡してしまうと、費用は下がりますが、止まった日に社内で誰も動けなくなります。外に出すのは実施であって、決めることではありません。特に最後の行、証明書とドメインの名義は、契約が終わる日のことを考えると自社で持っておくのが安全です。

費用の形は3つ。月額固定、作業ごと、上限つき

範囲が決まったら、次は払い方です。形は3つあります。月額固定は、期限の管理と待機を買う形で、作業が発生しない月も同じ金額を払います。作業ごとは、発生したときだけ払う形で、更新の頻度が読めない場合に合います。上限つきは、月額に一定の作業時間までを含め、超えた分を別に請求する折衷の形です。安全のための更新のように、いつ来るか読めないが必ず来るものは、月額固定か上限つきに入れておかないと、緊急時に発注の手続きが挟まって遅れます。

金額の桁も見ておきます。見積りを仲介する会社が自社の取引実績として公開している目安では、場所とドメインと証明書の維持、基本的な安全対策までの最低限の管理で月額5,000円から10,000円ほど、そこに中身の更新、控えの取得、安全対策まで含めると月額10,000円から50,000円ほどとされています。内訳の目安としては、サーバーの管理が月額1,000円から4,000円、ドメインの管理が年額1,000円から5,000円、サイトの更新と修正が月額5,000円から15,000円と示されています。これは公的な統計ではなく、1社が自社の取引から出した目安です。桁を確かめる材料として使い、自社の見積りの妥当性を判断する根拠には使わないでください。

金額そのものより効くのは、含まれていない項目です。含まれている項目は見積書に書いてありますが、含まれていない項目はどこにも書かれません。漏れやすいのは4つで、土台の切り替え作業、時間外と休日の緊急対応、控えからの復旧作業、そして契約が終わるときの引き渡しです。4つ目は聞きにくいのですが、契約の入口で聞いておくのがいちばん安く済みます。

• 5区分に分けずに3社から見積りを取る——並ぶのは価格ではなく、各社が考える保守の定義になる
• 月額が最も安い見積りを選ぶ——安全のための更新と土台の切り替えが範囲外になっている確率が高い
• 証明書とドメインを制作会社の名義で取ってもらう——契約を見直す段で必ず不利になる
• 控えを取っているとだけ聞いて、戻せることを確かめない——戻せない控えは、無いのと同じ扱いになる
• 緊急時の連絡先を担当者個人の携帯番号だけにする——退職や異動で、その日から連絡がつかなくなる
• 更新の記録を残さない——次に壊れたとき、何を変えたせいなのかを絞り込めなくなる

契約に書いておく項目の一覧

範囲と費用の形が決まったら、書面に落とします。書く項目は4つに整理できます。窓口、応答の期限、対象範囲、引き渡す物です。この4つのうち、揉める原因になるのは応答の期限と対象範囲の2つに集中します。参考までに、公的機関が2020年12月22日に公開しているモデルの契約書には、受託開発だけでなく保守運用の類型も含まれています。自社の契約担当と一緒に見ておくと、抜けの確認に使えます。

応答の期限は、読み違えやすい項目です。ここで約束できるのは多くの場合「返事をするまでの時間」であって、「直るまでの時間」ではありません。原因が借りている場所の側にあるとき、復旧の時間を保守の会社が約束することはできないからです。だから、返事の期限と、復旧の見込みを伝える頻度を分けて書きます。受付から1時間以内に一次連絡、以降2時間ごとに状況を連絡、という書き方なら、双方が守れる約束になります。

• 窓口——連絡先と受付の時間帯、時間外の連絡手段、誰から連絡してよいか（社内の誰でもよいのか、決めた1人からか）
• 応答の期限——一次連絡までの時間、状況を伝える間隔、平日と休日で分けるかどうか
• 対象範囲——5区分のうちどれが入るか、部品の追加はどこまで含むか、時間や件数の上限はあるか
• 範囲外の扱い——範囲外と判断したときに誰がそう決めるか、追加費用の単価と概算の出し方
• 報告——月次で何を報告するか。当てた更新の一覧、止まった時間、控えの取得状況の3つが最低限
• 引き渡す物——手順書、設定の一覧、部品の一覧、控えのデータ、そして名義の移し方と引き継ぎ期間

止まったときの動き方を、契約より先に紙で決める

契約書があっても、止まった日には読みません。だから、1枚の紙にしておきます。書くのは、気づいてから記録するまでの5段です。紙を作る目的は、誰が判断するのかを事前に決めておくことです。判断者が決まっていないと、全員が連絡を待ち、最初の30分が消えます。

この紙は、年に1回、15分だけ読み合わせます。訓練という名前を付けると日程が取れなくなるので、読み合わせと呼びます。実際に止めて試す必要はありません。連絡先が生きているか、判断する人が今もその役職にいるか、お知らせのページの文面が古くなっていないか。この3点を確かめるだけで、当日の動きが変わります。

生成AIで軽くなる保守作業と、任せてはいけない判断

年に1万件を超える情報を人が読み切るのは無理があります。ここが生成AIの使いどころですが、使える範囲は思ったより狭く、はっきりしています。軽くなるのは3つで、更新の変更点を短くまとめること、その変更が自社のどこに当たるかを一覧と突き合わせること、監視から届く通知を仕分けることです。どれも、答え合わせができる作業だけを渡している点が共通しています。

実際に頼める形にすると、次のようになります。前提として、自社が使っている部品の一覧と、監視の通知の履歴が手元にあることが条件です。材料を渡さずに一般論を聞くと、どの現場にも当てはまる当たり障りのない答えしか返りません。

• 更新の説明文を渡し、動きが変わる箇所と、変わらない箇所を分けて列挙させる
• 自社の部品の一覧と、届いた注意喚起の対象を突き合わせ、一致する行だけを抜き出させる
• 1か月分の監視の通知を渡し、同じ原因で繰り返し出ているものを件数の多い順に並べさせる
• 保守の見積り2社分を渡し、同じ言葉が違う範囲を指している箇所を指摘させる
• 月次の報告書を渡し、前月と比べて記載が消えた項目を挙げさせる

一方、任せてはいけないのは判断です。更新を当てるか、当てずに機能を止めるか。止まったサイトを戻すか、原因を調べてから戻すか。どちらも、社内の事情と、いま何が動いているかを知らないと決められません。運用の約束事として3つだけ決めておきます。AIに良し悪しの判定だけを返させないこと。必ず根拠となった記述を書かせること。そして、人が確認する範囲を先に決めておくこと。3つ目が抜けると、確認する人によって見る範囲が変わり、記録が残りません。

頼んでも社内に残る3つの仕事

保守を外に出しても消えない仕事が3つあります。承認、優先順位、記録です。この3つまで渡してしまうと、費用は下がりますが、範囲を見直す交渉ができなくなります。承認は、止めるか当てるかを決める仕事と、追加費用を認める仕事です。技術的な正しさではなく、事業として今日止めてよいかどうかを決める役なので、社内にしか置けません。

優先順位は、同時に複数の話が来たときに、どれを先に片づけるかを決める仕事です。保守で詰まるのは、作業の速さではなく順番が決まらない時間です。更新も、崩れの修正も、新しいページの追加も同じ月に来ます。保守の会社は、どれが事業にとって重いかを知りません。ここを渡すと、頼みやすい順や作業しやすい順に並び替えられます。

記録は、地味ですが最も効きます。いつ、誰が、何を、なぜ変えたか。この4項目だけで構いません。記録が残っていないと、次の見積りの根拠が作れず、相手の提示額をそのまま受け取ることになります。1年分の記録があれば、実際に発生した作業量から、月額固定と作業ごとのどちらが自社に合うかを数字で選び直せます。

半年に一度、範囲を引き直す

最後に、続ける形にします。保守の取り決めは、一度決めたら終わりではありません。期限の側が変わり、使う部品が増え、担当者が入れ替わるからです。半年に一度、30分だけ時間を取って、3つを見ます。3つに絞ると続き、10項目にすると3回目で誰も見なくなります。

1つ目は、部品の一覧が現状と合っているかです。増えていないか、使っていないものが残っていないかを確かめます。2つ目は、期限の一覧が1枚にまとまっているかです。土台の切り替え、証明書、ドメイン、そして保守契約そのものの期限を、同じ紙に並べます。3つ目が最も重要で、控えから実際に戻せるかを試したかどうかです。

3つ目を実際にやると、かなりの確率で問題が見つかります。見つかるのは控えの仕組みの不具合ではなく、手順と人の側の抜けです。控えは取れているが古い版しか残っていない、データは戻るが設定が戻らない、戻す手順を知っている人が退職している。控えを取っていることと、戻せることは別の話です。1ページだけを別の場所に戻してみる程度で構わないので、年に1回は実際に試します。試した結果は記録に残し、次の契約更新のときに持っていきます。

• 半年に一度の点検は、保守の会社と一緒にやらない——自社だけで見ると、範囲外になっている作業に気づける
• 期限の一覧には、担当者の名前ではなく役割を書く——人が変わっても一覧が生き続ける
• 契約の更新月の2か月前に見直しの時間を置く——更新の直前だと、条件を変える交渉ができない
• 使わなくなった部品と、終わったキャンペーンのページは同じ日に片づける——保守の対象が減れば、費用も範囲も軽くなる

まとめ

サイトの保守は、壊れたときのための積み立てではありません。自社が何もしなくても、土台の言語にも、載せている部品にも、証明書にもドメインにも、それぞれ別の期限が来ます。その期限に合わせて手を入れ続けるのが保守です。だから見積りは金額の大小ではなく、5つの区分のうちどれが含まれているかで読みます。止まったときの復旧、中身の更新、土台の更新、安全のための更新、監視と控えの5つです。

期限の回数は増える方向にあります。ここ数年で変わったのは作業の難しさではなく、同じ作業が来る頻度です。通信を守る証明書は、2026年3月からの発行分で最大200日、2027年3月からは100日、2029年3月からは47日になります。年に1回で回していた作業が、数年で年に8回に近づくということです。安全のための更新も、公開された時点で修正が出ていないものが半分近くあり、当てる作業だけでは足りません。手作業で全部を追う前提の保守は、そのままでは成立しなくなりました。

割り方の基準は2つです。期限が決まっていて手順が同じものは外に出せます。判断が要るものは社内に残します。費用で割ろうとすると、判断まで一緒に外へ出ていきます。この基準で割ると、どの行にも社内の仕事が残ります。承認、優先順位、記録の3つです。そして証明書とドメインの名義だけは、契約が終わる日のことを考えて自社で持ちます。契約に書くのは、窓口、応答の期限、対象範囲、引き渡す物の4つで、応答の期限は返事までの時間であって直るまでの時間ではない、という点を先に確かめておきます。

生成AIは、この領域では作業を軽くする道具として使えます。更新の変更点の要約、自社の部品との突き合わせ、通知の仕分け。どれも答え合わせのできる作業です。反対に、当てるか止めるかの判断は人に残ります。判定だけを返させず根拠を書かせること、人が確認する範囲を先に決めることの2つを、運用の約束事として先に決めておきます。この取り決めが返してくれるのは、安い保守ではなく、止まった日に社内の誰かがすぐ動ける状態です。半年に一度、部品の一覧と期限の一覧と、控えから戻せるかどうかの3つだけ見直せば、その状態は保てます。

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