サイト売買の失敗は引き渡し後に始まる
サイト売買の失敗談には、奇妙な時間的な偏りがあります。交渉が決裂した、契約書の文言で揉めた、という話ももちろんありますが、当事者が「あれは失敗だった」と口にする案件の多くは、交渉も契約も入金も、すべて問題なく終わっています。壊れるのは、いつも引き渡しが終わったあとです。それも当日ではなく、数週間から数ヶ月ほど遅れて、忘れた頃にやってきます。
理由は身も蓋もありません。引き渡し日には、全部動いて見えるからです。サイトは表示され、フォームは送信でき、管理画面にはログインできて、数字も見える。買い手も売り手も画面を並んで見て頷き、握手して終わる。それはそうで、目の前で止まっているものを渡す売り手はさすがにいません。
問題は、その日に確認できたものが、その事業のごく一部でしかないということです。事業には、1秒に何度も動くものから、1年に1回しか動かないものまで、いくつもの周期が同居しています。クロージング日の動作確認が触れられるのは、そのうち一番速く回っている層だけです。月に1回動くものは、当日には絶対に動きません。年に1回動くものは、なおさらです。
この記事では、サイト売買の失敗がなぜ引き渡し後に集中するのかを「時間軸」という一点に絞って構造から解きほぐし、買い手と売り手がそれぞれ何を仕込んでおけば防げるのかを、実務の手順として整理していきます。
「引き渡し日に動いた」は「引き継げた」の証明にならない
まず、言葉の整理から始めます。M&Aの現場で「引き渡しが完了した」と言うとき、そこには意味の違う2つのものが混ざっています。ひとつは、資産の所有権が移ったということ。ドメイン、サーバー、ソースコード、データベース、各種アカウント。もうひとつは、事業が回り続ける状態が移ったということです。
前者は、書類とパスワードの受け渡しで完結します。1日あれば終わります。後者は、時間が経たないと確認しようがありません。そして事故の大半は、前者だけを終えて後者も終えたつもりになった案件で起きています。
クロージング日の動作確認というのは、要するにスナップショットです。ある一瞬の状態を撮って、正常だと判定している。ところが事業は動画であって静止画ではありません。1コマだけ見て「この映画に問題はない」と言っているようなもので、90分後に何が起きるかについては、何ひとつ検査していないわけです。
ここで大事なのは、この構造が「売り手が何かを隠していた」という話とは完全に別物だという点です。悪意ある買い手や不誠実な売り手の話ではありません。双方が誠実で、双方が真剣に確認して、それでも起きます。なぜなら、当日に観測できない事象は、誠実さでは検出できないからです。それを検出できるのは、時間だけです。
だから「引き渡し日に動いた」は「引き継げた」の証明にはなりません。それは「引き渡し日に動いた」ということの証明でしかない。トートロジーに聞こえますが、この当たり前が実務では驚くほど守られていません（動いているものを目の前で見せられると、人はそれ以上を疑えない生き物なので、これは意志の問題というより認知の問題です）。
事業には周期がある——当日に見えるのは一番速い層だけ
抽象論を続けても仕方がないので、事業を「周期」で切り分けてみます。ひとつのサイトの中では、だいたい次のような時間の層が同時に走っています。
- 秒〜分: ページの表示、フォーム送信、決済のオーソリ、検索、外部APIの応答
- 日次: バックアップ、集計バッチ、在庫や価格の同期、ランキング更新、日報メール
- 週次: レポート配信、キャッシュの再構築、メルマガ、インデックスの再生成
- 月次: 締め処理、請求、アフィリエイト成果の確定、サブスクの更新、月次レポート、外部システムへのデータ連携
- 四半期〜半年: 決済事業者の審査、提携先の規約更新、SDKやライブラリのサポート期限
- 年次: ドメイン更新、証明書の更新、ライセンス更新、各種契約の自動更新、税務
クロージング日に画面を見て確認できるのは、この表の1行目だけです。日次のものは、翌日まで待てば一応は観測できます。しかし週次から下は、当日には物理的に発生しません。存在するのに、絶対に見えない。
そして、この層の分かれ方には残酷な傾向があります。収益に直結する処理ほど、周期の長い場所に置かれているのです。ページの表示は秒単位ですが、そのページで発生した成果が金額として確定するのは月次の締め処理を通ったあとです。サブスクの売上は更新のタイミングで初めて立ちます。広告の入金は翌月末です。
つまり、当日に確認できる層は、事業の見た目を担っている層であって、事業の収益を担っている層ではない。ここがサイト売買という取引の、構造的な非対称です。買い手はサイトを見て買っているつもりで、実際には見えていない周期を買っています。
最初の30日で来る「月次の壁」
引き渡し後の最初の関門は、たいてい月が変わったタイミングでやってきます。
月次で動くものというのは、たとえばこういうものです。会員課金の一括処理、アフィリエイト成果の確定と支払い、マスタデータの更新、月次レポートの生成と配信、締めた売上のCSV出力、提携先へのデータ送信。どれも地味です。地味なうえに、普段は誰も見ていません。正常に回っているかぎり、存在すら意識されないのが定期処理という仕組みです。
これらの大半はサーバー上の定期処理として仕込まれています。ここでcronジョブの引き継ぎが漏れると、引き渡しの翌月に、静かに何かが起きなくなります。
「静かに」というのが本当に厄介なところです。処理が動かないというのは、エラー画面が出るのとは違います。何も起きないだけです。請求が飛ばない、成果が確定しない、レポートが届かない。誰かが「そういえば今月のあれ、来ていないな」と気づくまで、画面上はどこまでも平穏です。
しかも、移管作業そのものが引き金になります。サーバーを移した、実行ユーザーを変えた、PHPのバージョンを上げた、タイムゾーンの設定が初期値のUTCに戻った。移管では環境が必ず変わり、変わった環境で「日次までのもの」は数日で気づけますが、「月次のもの」は次の実行日まで不具合が眠り続けます。1ヶ月分の請求が飛ばなかったと分かるのは、その翌月です。
処方箋はひとつしかありません。クロージングの前に、時計を手で進めてください。月次バッチを本番相当の環境で手動実行し、出力される請求データやレポートを目視する。「動くはずです」ではなく「動かしました、これが出力です」というところまで持っていく。所要時間はせいぜい数十分です。その数十分をやったかどうかが、翌月に発覚する事故の有無を分けます。
90日から1年で切れるもの——証明書・ドメイン・トークン
月次の壁を越えると、次は「期限」の層に入ります。ここは月次よりさらに遅れて効いてくるぶん、発覚したときには関係者の記憶も薄れていて、原因の特定にも時間がかかります。
TLS証明書
いまどきの証明書は自動更新が当たり前で、だからこそ引き継ぎの対象として認識されません。しかし自動更新は、DNSやWebサーバーが特定の状態にあることを前提に成立しています。移管でDNSの管理先が変わり、更新に必要な認証が通らなくなっていても、すでに発行済みの証明書は有効期限まで平然と動き続けます。仕組みは壊れているのに、90日近く正常に見える。そして期限当日、サイト全体がブラウザの警告画面に置き換わります。
ドメイン
更新料の支払い方法が旧オーナーのカードのまま放置され、ドメインが失効する事故は、移管から半年、1年と経ってから起きます。カードは移管の時点ですでに無効になっているのに、次の更新日が来るまで何も起きないため、誰も気づけません。
OAuthトークンとAPIキー
外部サービスとの連携は、多くがリフレッシュトークンによって維持されています。トークンには有効期限があり、失効の条件も提供者ごとに違います。アカウントの所有者を変える、パスワードを変更する、二段階認証を入れ直す——こうした操作で既存トークンが無効になる仕様のサービスは珍しくありません。そして連携が切れるのは、その操作をした瞬間ではなく、次のリフレッシュが走るタイミングです。移管作業から数十日後、心当たりのない時期に、突然データが流れてこなくなります。
これらに共通しているのは、壊れた瞬間と、壊れたと分かる瞬間が、大きくずれていることです。原因は移管日にあり、結果は数ヶ月後に出る。この時間差があるせいで、多くの現場では移管と障害が因果として結びつけられず、「買ってから調子が悪い」という漠然とした不信だけが残ります。買い手が売り手を疑い始めるのは、たいていこの段階です。
ここも検査は難しくありません。期限のあるものをすべて洗い出し、期限日そのものを一覧にするだけです。証明書の有効期限、ドメインの更新日、ライセンスの更新日、契約の自動更新日、SDKのサポート終了日。日付が並んだ表を1枚作れば、「引き渡しから3ヶ月後に3件重なっている」といった事実が視覚的に出てきます。
定期課金は、1周するまで壊れたかどうか分からない
継続課金を収益の柱にしている事業を売買する場合、時間軸の問題はさらに厄介になります。
継続課金は、全ユーザーが同じ日に更新されるわけではありません。契約日が人それぞれなので、更新は毎日どこかで少しずつ起きています。ということは、契約者全員が1周するまでに、月次課金なら1ヶ月、年次課金なら丸1年かかるということです。
「引き渡し月のMRRは正常でした」というのは、だから何の証明にもなりません。それは引き渡し日以降に更新日を迎えた一部のユーザーを見ているだけで、残りの大半はまだ一度も検査されていないからです。年次プランの契約者に至っては、最悪の場合11ヶ月後まで誰ひとり更新を迎えません。その間ずっと、売上は何事もなかったかのように立ち続けます。
ここで起きる典型が、決済アカウントの移管にまつわるものです。決済事業者のアカウントは事業の名義が変わればStripeの再審査のような本人確認をやり直すことになりますが、この審査は申請した瞬間ではなく、しばらく経ってから入金の保留という形で表面化することがあります。売上は立っているのに、口座に入ってこない。キャッシュフローだけで回している事業には、これは直撃します。
さらに深刻なのが、決済アカウントを新規に作り直した場合です。既存の継続課金に紐づくカード情報は、原則としてそのまま持ち出せません。カード番号そのものは決済事業者側が保持している資産であり、事業者間の移行には所定の手続きが必要です。手続きを踏まずに新しいアカウントへ切り替えると、既存の契約者全員に「カードを再登録してください」とお願いすることになり、そこで何割かが黙って離脱します。これはシステムが壊れたわけではなく、仕様どおりに動いた結果です。壊れていないぶん、誰も責任を問えません。
したがって、継続課金事業の検査は「今月の数字」ではなく「1サイクル分の更新が実際に成功したか」で行う必要があります。具体的には、引き渡し後の最初の更新バッチが成功したことを確認するまでは、代金の一部を留保する。年次契約の比率が高いなら、留保の期間はそれに合わせて長く取る。数字の綺麗さではなく、時計の針で条件を切るという発想です。
気づけない構造——通知はいつまでも旧オーナーへ飛ぶ
ここまで挙げた事故には、共通する増幅装置があります。異常を知らせる通知が、買い手ではなく売り手のもとへ届き続けることです。
思いつくままに挙げてみます。サーバーの監視アラート、定期処理のエラーメール、証明書の期限通知、ドメインの更新通知、決済事業者からの審査依頼、Search Consoleの手動対策通知、広告アカウントのポリシー警告、提携先からの規約変更連絡、クラウドの請求アラート、ライブラリの脆弱性通知。これらの宛先は、ドメインでもサイトでもなく、個人のメールアドレスや個人の電話番号に紐づいています。
そして、移管の対象リストに通知の宛先は入っていません。IDとパスワードは引き継ぎ資料に必ず書きますが、「このサービスからの警告メールが誰に届くのか」を書く欄がある引き継ぎ資料は、ほとんど見かけません。アカウントは移ったのに、そのアカウントの叫び声だけが前の持ち主に届き続けるという、なかなかシュールな状態が生まれます。
その結果、買い手は「異常がない」と思い込みます。正確には、異常を受け取っていないだけです。この2つは、引き渡しから数ヶ月のあいだ、まったく同じ顔をしています。区別がつくのは、区別がつかなくなるほど手遅れになってからです。
売り手にとっても、これは不幸な構造です。もう自分のものではない事業のアラートが延々と届き、かといって無視すれば、あとから「知っていたのに黙っていた」と言われかねない。引継ぎマニュアルを丁寧に書き上げたはずの売り手が、半年後もなお他人の事業の障害通知を転送している、という状況が現実に起きています。善意でやっているうちに、それが義務として扱われ始めるのが最悪のパターンです。
ここも対処は単純です。通知の宛先の棚卸しを、引き渡し作業の独立した項目にする。各サービスの通知先設定画面を1つずつ開き、宛先を買い手のものに書き換え、書き換えた画面を証跡として残す。地味ですが、これをやるだけで前の章までに挙げた事故の発覚が数ヶ月早まります。壊れることそのものは防げなくても、壊れたことを知るまでの時間は買えるのです。
時間軸をDDと契約に織り込む
ここまでの話を、買い手と売り手それぞれの手順に落とします。難しい作業はひとつもありません。ただ、やる人がほとんどいないというだけです。
買い手がやること
- 周期の棚卸しを、独立した項目として立てる: 「この事業で、日次・週次・月次・年次に動くものを全部挙げてください」と質問します。項目を網羅する形の技術的DDではこの問いが抜け落ちがちで、個々の技術要素は全部チェックしたのに、それがいつ動くのかを誰も聞いていない、ということが起こります
- 時計を進めた検査をする: 月次バッチを手で実行して出力を見る。期限のあるものを日付付きの一覧にする。「動くはずです」を「動かしました」に変える作業です
- 通知の宛先を全部書き出させる: サービス名と、現在の通知先アドレスの対応表を出してもらいます
- 観測期間を契約に書く: 表明保証の存続期間を「引き渡し後◯日」という慣習で決めず、主要な周期が最低1周する期間で設計します。月次処理が収益の中心なら最低60日（2サイクル）、年次契約が柱なら13ヶ月。代金の一部の支払いを、最初の1サイクル完了に紐づけるのが最も素直な形です
売り手がやること
- カレンダー資産の目録を1枚作る: 期限があるもの、周期で動くものを表にします。列は「名称／周期または期限日／通知の宛先／支払い方法／止まったときに何が起きるか」の5つで十分です
- 通知の付け替えを、引き渡しの作業項目にする: 引き渡し当日のチェックリストに入れてしまえば、忘れようがありません
- 自分が把握していない定期処理を掘り出す: これが実は一番多い。crontabを出力する、決済事業者の管理画面でスケジュールを確認する、外部サービスの連携一覧を開く。「昔の自分が仕掛けたまま忘れていた処理」は、たいてい出てきます
この目録は、売り手にとっては防衛の道具でもあります。渡すものを事前に紙にした売り手と、聞かれてから探し始めた売り手とでは、買い手からの信頼がまるで違います。そして万が一あとで揉めたときに、「この表を渡した」という事実そのものが、誠実さの証拠になります。
クロージング日は、終わりではなく時計のスタート
サイト売買の失敗の多くは、誰かが嘘をついたから起きているのではありません。検査した時間の長さが、事業の周期より短かったから起きています。1日で確認して、1年かけて壊れるものを買っている。それだけの話です。
この構造が理解されると、DDの設計が少し変わります。「何を確認するか」というリストの前に、「それはいつ動くのか」という列が1本増える。たったそれだけで、当日には見えなかった層が輪郭を持ち始めます。逆に言えば、その列がないチェックリストは、どれだけ項目が並んでいても、事業の一番速い層しか検査できていません。
そして売り手の側にも、この視点を持つ理由があります。引き渡し後に事故が起きれば、いくら契約書で守られていても、連絡は来ます。交渉は蒸し返されます。数ヶ月かけて育てた買い手との関係が、自分が数年前に仕掛けたまま忘れていた月次バッチひとつで壊れる。それはあまりに割に合いません。
クロージングの日に鳴るのは、終了のブザーではなく、スタートの号砲です。その日から時計が動き始めて、月次が1回、証明書が1回、更新が1回と、順番に検査が実行されていく。買い手も売り手も、その時計が何周かするまでは、まだ取引の途中にいます。
だから、握手をする前に、カレンダーを開いてください。この事業には、どんな周期が眠っているのか。次に何かが起きるのは、いつなのか。その問いを一度でも口に出した取引は、たとえ地味な数十分を追加しただけでも、静かに壊れる未来からずいぶん遠いところに着地します。
引き渡しまで見据えた準備ができているかを確かめたら、あわせて売却額の目安も押さえておきたいところです。WEBサイト売却の無料査定で、想定売却額のレンジを確認できます（登録不要）。
