「保守契約を結ばずにサーバだけ用意してしまった」─ 制作会社であれば、身に覚えのある状況かもしれません。サイト制作のタイミングで「サーバ、どうされますか?」と聞くものの、クライアントが自分で契約するのも大変そうだったので、制作会社側でレンタルサーバーを契約し、代わりに管理画面を用意した。保守契約は結んでいない。請求書には「サーバ費用」として毎月一定額を乗せているか、あるいはクライアントのクレジットカードをそのまま登録して終わっている。
この状態で放置している案件はありませんか？
前回の記事では、これから移行を提案する場面のトークと資料を扱いました。本記事は逆で、すでにこの状態にある案件を、どう整理して手放すか、あるいはどう正式な形に引き上げるかを扱います。
参考：制作会社がクライアントにホスティング移行を提案するときのトークと資料
目次
なぜこの状態が量産されるのか
原因は、悪意でも手抜きでもありません。サイト公開という単発のタスクの中に、サーバ契約という継続的な責任が紛れ込んでしまうという、業務の性質そのものに起因します。
納品時点では、サーバの契約は「公開作業の一部」に見えます。ドメインを取る、DNS を設定する、サーバを契約する、WordPress をインストールする ── これらは一連の作業リストの中の項目でしかなく、「契約後も誰がこのサーバの責任を持つのか」という問いは、納品のチェックリストに入っていないことが多いのです。保守契約の話は別途「ご相談ください」と伝えたつもりでも、クライアントが「サーバ代を払っているのだから、何かあれば見てもらえるはず」と理解していれば、その時点で認識はすでにズレています。
そして、何も起きなければこの状態は何年でも延命します。障害が起きるまでは誰も困らないからです。困るのは、障害が起きたとき、担当者が退職したとき、契約更新のタイミングで料金が上がったとき ── つまり、後始末が最も面倒なタイミングでだけ表面化します。
放置するとどうなるか
先送りのコストを具体的に並べます。
障害対応がすべて無償化する
契約に書かれていないので、対応しても請求根拠がありません。無償で対応するか、対応しないかの二択になり、後者を選べば関係が壊れます。
担当者の異動・退職で引き継ぎが破綻する
サーバの契約情報、管理画面のログイン情報、DNS の管理者情報が、退職した担当者の個人のメールアドレスや、当時使っていたパスワード管理方法に紐づいていることがあります。数年後、当時の担当者に連絡が取れなくなってから気づくケースが最も深刻です。
契約更新時の値上げに対応できない
レンタルサーバー各社は数年おきに料金改定を行います。保守契約がない状態では、この値上げをそのままクライアントに転嫁するのか、制作会社が飲み込むのかという方針が決まっておらず、都度その場での判断になります。
クライアントがサーバの存在を認識していないケースがある
特に、制作会社名義で契約し、請求書に「Web サイト運用費」のような曖昧な項目でまとめて請求している場合、クライアントは自社のサイトがどこで動いているかを把握していません。この状態で制作会社が事業を終了したり、担当が変わったりすると、クライアントは何も知らないまま自社サイトが消える可能性があります。
いずれも、今すぐ問題になるわけではないという点が、対応を遅らせる最大の要因です。だからこそ、問題が起きていない今のうちに仕分けておく価値があります。
まず現状を仕分ける
対応方針は案件ごとに変わります。最初にやるべきは、手元の案件を次の3つの軸で分類することです。
| 確認軸 | 確認内容 |
|---|---|
| 契約名義 | サーバ契約は誰の名前・誰の支払い方法で契約されているか（クライアント名義/制作会社名義） |
| 請求形態 | クライアントへの請求はサーバ会社への支払いをそのまま透過しているか、制作会社がマージンを乗せて請求しているか |
| クライアントの認知 | クライアントは自社サイトがどのサーバで動いているか、費用の内訳を認識しているか |
この3軸を組み合わせると、対応の緊急度と難易度が違う、大きく3つのパターンに分かれます。
パターンA：契約名義もクライアント、費用の透過性も高い
サーバはクライアント自身の名義・支払い方法で契約されており、制作会社は初期設定を代行しただけ。請求書にも「サーバ費用の立て替え」のような形で明示されている。
このパターンは、実は最もリスクが低い状態です。契約上の責任者はクライアント自身であり、制作会社が抱えているのは「保守契約がないので障害時に無償対応してしまう」という運用上の問題だけです。出口はシンプルで、前回の記事で紹介したホスティング移行の提案、あるいは保守契約の新規提案に進めば済みます。「サーバ費用の立て替え」というだけの関係を、責任範囲を明記した契約に置き換える提案です。
パターンB：契約名義は制作会社、費用は透過（マージンなし）
サーバは制作会社の名義・支払い方法で契約されているが、クライアントへの請求はサーバ会社の料金そのまま。制作会社が便宜上代理契約している状態。
ここから難易度が上がります。契約者が制作会社である以上、法的にはサーバに関するすべての責任(規約違反、支払い遅延時の停止リスク、契約者情報の管理)を制作会社が負っています。 クライアントがこの構造を認識していない場合も多く、まず現状を正しく開示することが最初のステップです。「現在、御社のサイトのサーバ契約は弊社名義になっており、これは本来クライアント様ご自身で契約・管理いただくべきものです」と伝えることは、気まずくても必要な作業です。
出口は2つに分かれます。ひとつは契約名義をクライアントに移管する方向。サーバ会社によっては契約者変更の手続きが用意されています。もうひとつは、保守契約を正式に結び、制作会社が名義を持ち続けることを契約上の役務として明文化する方向です。後者を選ぶ場合、単なる「サーバ費用の代行」ではなく「インフラの管理責任を負う保守サービス」として料金体系を見直す必要があります。
パターンC：契約名義も請求も制作会社、クライアントは費用の内訳を認識していない
サーバは制作会社名義で契約され、クライアントへの請求は「Web サイト運用費」のような包括的な項目にまとめられている。クライアントは自社サイトがどこで、いくらのサーバコストで動いているか把握していない。
最もリスクが高いパターンです。ここには2つの問題が重なっています。ひとつはパターンBと同じ契約者責任の集中。もうひとつは、クライアントの知らないところで自社の重要な資産（サイト・データ・ドメイン）が管理されているという透明性の問題です。この状態が長く続くほど、後で開示したときの「なぜ今まで教えてくれなかったのか」という不信感は大きくなります。
出口の第一歩は、内訳の開示です。金額を含めた開示は気が重いかもしれませんが、先に述べたリスク（制作会社の事業終了時にサイトが消える可能性）を考えれば、開示しないことのリスクのほうが大きいと判断すべきです。開示のタイミングは、前回の記事で紹介した「サイトリニューアルの計画時」「担当者交代」などの自然なきっかけに合わせると、唐突感を減らせます。開示後は、パターンBと同じ2つの出口（名義移管/保守契約化）のいずれかに進みます。
出口を選ぶときの判断基準
「名義移管」と「保守契約化」、どちらを選ぶべきかは、次の観点で決まります。
| 観点 | 名義移管が向くケース | 保守契約化が向くケース |
|---|---|---|
| クライアントの IT リソース | 情報システム部門がある、または今後保有する予定 | 専任の担当者がおらず、外部委託を前提としている |
| 制作会社の意向 | インフラ管理から手を引きたい、保守収益を追わない方針 | 保守契約を安定収益として位置づけたい |
| サイトの重要度・複雑さ | 構成がシンプルで、クライアント側の対応で十分 | 動的機能や重要データを含み、専門的な運用が必要 |
| 関係の将来性 | 契約終了や取引縮小が見込まれる | 継続的な関係を前提としている |
名義移管を選ぶ場合、クライアントが自身で運用するか、あるいは別のホスティング事業者と直接契約する形に落ち着きます。制作会社としては保守収益を手放しますが、責任も同時に手放せます。決して「後ろ向きな選択」ではなく、自社の専門領域に集中するための整理と位置づけるべきです。
保守契約化を選ぶ場合、ここが前回の記事とつながります。インフラの責任範囲を明確にするために、Amimoto や Shifter のような、責任共有モデルを公開しているホスティング事業者への移行を同時に検討する価値があります。現状の「制作会社が個人的にレンタルサーバーを管理している」状態から、「責任範囲が契約上明記されたホスティング事業者に任せ、制作会社はその窓口を担う」体制に切り替えることで、パターンB・Cで問題になっていた責任の集中そのものを構造的に解消できます。
移管・切替の実務ステップ
どちらの出口を選んでも、実務上のステップは似ています。
- 現状の棚卸し
契約名義、支払い方法、ログイン情報の所在、ドメインの管理者情報を一覧化する - クライアントへの開示と合意
現状と、今後の選択肢(名義移管/保守契約化)を説明し、方針を合意する - 契約の締結
名義移管の場合はサーバ会社所定の手続き、保守契約化の場合は新たな保守契約書の締結 - アカウント・データの移管
ドメインの管理者情報変更、支払い方法の変更、必要に応じて新環境への移行 - 旧契約の解約
移管・移行が完了し安定稼働を確認したうえで、旧サーバ契約を解約する（解約を急ぐと、切替中に問題が起きた際の後戻りができなくなる）
このうち5番目を焦って進めると、切替直後に不具合が出た際に戻る場所がなくなります。旧環境は最低でも3ヶ月、サイトの重要度や更新頻度によっては半年程度残しておくのが妥当です。「動いているように見える」だけでは不十分で、月次の締め処理や季節依存のコンテンツ更新など、頻度の低い運用が一巡して問題が出ないことを確認できてから解約するくらいの余裕を見てください。
契約書に必ず入れておきたい項目
これを機に保守契約を結ぶ場合、次の項目は最低限入れておくべきものです。
- 責任範囲の明記
インフラ層と WordPress・コンテンツ層のどちらが誰の責任か - 対応時間・対応方法
障害発生時にどのような手段（メール/チャット/電話の有無）でどの時間帯に対応するか - SLA の有無
稼働率の保証があるかないか。ない場合はその旨を明記し、過剰な期待を防ぐ - データの所有権
コンテンツ・データの所有権がクライアントにあることの確認 - 契約終了時の取り扱い
契約終了時のデータ引き渡し方法と期限 - 料金改定時の取り扱い
サーバ会社側の値上げが発生した際、誰がどう負担するか
これらの項目は、Amimoto や Shifter が公開している責任共有モデルの文書が、実際の書き方の参考になります。特に「SLA を設定していない」という事実をあえて明記する姿勢は、過剰な期待を防ぐという点で参考にする価値があります。
参考： Amimoto テクニカルサポートおよび保守に関するご案内 / Shifter 責任共有モデル
まとめ
保守契約のないままサーバだけ用意してしまった案件は、多くの制作会社が抱えている、ただ表に出にくい問題です。放置のコストは障害が起きたときにしか見えないため、優先順位が上がりにくいのが実情ですが、対応が最も難しくなるのも、まさにその「何かが起きたとき」です。
まずは手元の案件を契約名義・請求形態・クライアントの認知の3軸で仕分けること。そのうえで、名義移管（手を引く）か保守契約化（引き上げる）かを、クライアントとの関係性を踏まえて選ぶこと。この2段階で進めれば、後始末は着実に前に進みます。
自社の案件の仕分けや、保守契約化する場合のホスティング選定（Amimoto/Shifter のどちらが適するか）について相談したい場合は、LabWorks へお問い合わせください。個別の案件の状況を確認しながら、進め方を一緒に整理できます。
関連リンク
当社へご興味をお持ちいただきありがとうございます。
「こんなことやってみたい！」と、ぜひ気軽にご相談ください。
担当者よりご連絡差し上げます。