障害の第一報が買い手に届かない構造
買収したサービスが、ある夜中の2時に落ちたとします。復旧したのは翌朝の9時。その7時間のあいだ、買い手側の人間は誰ひとりとして障害が起きたことを知りませんでした。では、その7時間、誰の携帯が鳴っていたのか。半年前にその事業を手放したはずの、旧オーナーのiPhoneです。こういう構図が、Webサービスの移管の現場で、まったく珍しくない頻度で発生しています。
監視は動いていました。閾値も正しく設定されていました。アラートは規定どおり発報しています。つまり、システムとしては何ひとつ壊れていません。壊れていたのは、その悲鳴が届く先が、もうこの事業とは何の関係もない人の手元だった、という一点だけです。
そして、この記事でいちばん伝えたいのはここからです。この状態は、障害が起きるまで絶対に発覚しません。理由は当たり前で、アラートは鳴らないのが正常な状態だからです。宛先が間違っていようが、退職者のアドレスだろうが、もう解約したSlackだろうが、平時の挙動は「何も来ない」で完全に一致します。正しく設定された監視と、宛先が壊れた監視は、平時においてまったく同じ顔をしているのです。
この記事では、なぜ監視の宛先だけが移管の棚卸しから構造的に漏れるのか、宛先が旧オーナーに残ったまま何が起きるのか、そして買い手と売り手が何をどう確認すべきかを、実務の順序で整理していきます。
「鳴らないこと」が正常な仕組みは、壊れていることを証明できない
まず、この問題の性質をはっきりさせておきます。監視の宛先が誤っているという状態には、他の移管トラブルにはない、決定的に厄介な特徴があります。
普通の設定ミスは、使えば分かります。決済の設定を間違えれば決済が通らない。DNSを間違えればサイトが開かない。DBの接続情報を間違えれば画面が真っ白になる。これらはすべて、「使ったときに壊れていることが分かる」という性質を持っています。だから引き渡し直後の動作確認で拾えます。
ところが監視のアラートは、使う機会が平時には一度も訪れません。障害が起きたときだけ使われる仕組みだからです。そして障害というのは、頻繁には起きません（起きたら困りますし）。つまり、この設定だけは、実際に必要になるその瞬間まで、正しいのか壊れているのかを誰も知らないまま放置されます。
もっと言うと、宛先が壊れていることは、日常の体験としては「平和」として現れます。買い手のチームは「引き継いでから一度もアラートが飛んでこない、安定したいいサービスを買ったな」と思っています。実際には、その半年でディスクは何度も逼迫し、バッチはこけ、証明書の期限は近づいていたかもしれません。その全部が、別の人の通知欄に積み上がっていただけです。
アラートが鳴らない静けさには2種類あります。本当に何も起きていない静けさと、悲鳴が別の家に届いている静けさです。この2つは、外から見て一切区別がつきません。そして人間は、区別がつかないものを、都合のいいほうに解釈します。
これは「システム宛ての通知」ではなく「人間宛ての通知」の話
ここで、混同されやすい隣接論点との切り分けをしておきます。移管において「通知の宛先」という言葉が指すものは、実は2層あります。
ひとつは、システムからシステムへ飛ぶ通知です。決済事業者からの入金通知が自社のAPIエンドポイントへPOSTされる、といった機械同士の配線がこれにあたります。Webhookの宛先が旧オーナーのURLを向いたままになる問題は、この層の話です。壊れているかどうかは、送信側の配信ログを開けば、少なくとも記録としては確認できます。機械は記録を残すからです。
もうひとつが、本記事で扱うシステムから人間へ飛ぶ通知です。監視が異常を検知したときに、いったい誰の端末が鳴るのか。誰のメールボックスに届くのか。誰の電話が夜中に叩き起こすのか。この層は、配線ではなく名簿です。そして名簿は、事業の資産としては誰も認識していません。
この2層は、確認の難しさがまるで違います。機械宛ての配線には、ログという物証があります。人間宛ての名簿には、物証がありません。「このアラートは、鳴ったら誰に届くんですか」という問いの答えは、監視SaaSの通知ポリシー画面の3階層下に埋まっているかもしれませんし、そもそも設定した本人の記憶の中にしかないかもしれません。
そして名簿の項目は、「その人の個人資産」に紐づいています。ここが本質です。宛先として登録されているのは、法人の何かではありません。旧オーナーの私用のGmail、個人契約の携帯番号、個人で立てたSlackワークスペース、本人のApple IDに紐づいたスマホのプッシュ通知。これらはどれも、事業譲渡の対象資産の一覧には絶対に載りません。載せようがない。譲渡できない他人の持ち物だからです。
つまり、事業の所有権は移ったのに、その事業が倒れたことを最初に知る権利だけが、旧オーナーの個人資産の中に残り続けているという状態が発生します。契約書上はきれいに完了した取引が、現実の障害対応の場面でだけ、まだ半分終わっていない。
宛先は、だいたいこの5つの経路で旧オーナーに残る
では具体的に、どういう形で残るのか。現場で繰り返し出てくるのは、おおむね次の5系統です。
1. 監視SaaSのアカウントに紐づいた通知先メール
最も多いのがこれです。監視ツールを契約した日に、契約した本人のアドレスがそのまま通知先になり、以後、誰も触りません。請求先メールと通知先メールが同一という構成は、個人開発や小規模チーム由来のサービスではほぼ標準です。そして移管でアカウント自体の名義を移しても、通知ポリシーの中に個別に書かれたアドレスは、名義変更に追随しません。名義は名義、宛先は宛先で、別々に管理されているからです。
2. サーバー・ミドルウェアが直接吐くメール
監視SaaS以前の世代の仕組みです。cronの失敗がMAILTOで飛ぶ、監視デーモンの設定ファイルにアドレスがベタ書きされている、エラーハンドラの中に例外通知先が直書きされている。この層はSaaSの管理画面をいくら探しても出てきません。サーバーの中の設定ファイルとコードの中にいます。逆に言えば、ここはgrepで拾える数少ない領域でもあります。
3. 個人の携帯番号へのSMS・電話
クリティカルなアラートを、メールではなくSMSや自動音声電話で飛ばしている構成があります。深夜でも確実に叩き起こすためです。当然、ここに登録されているのは個人契約の携帯番号です。事業を売っても、電話番号は売れません。売り手がとっくに別の事業へ移ったあとも、真夜中に「CPU使用率が95%を超えました」という電話で起こされ続ける構図が、そこそこの頻度で残っています。
4. 本人しか入っていないSlackワークスペース
ひとりで運営していた事業では、アラート用のSlackワークスペースが本人ひとりのために存在していることが普通にあります。#alerts チャンネルにメンバーは1人。そこへ流し込むIncoming WebhookのURLが、監視側に設定されています。
厄介なのは、このワークスペースそのものが譲渡対象になっていないケースです。買い手はそのURLを止められません。無効化できるのは、そのワークスペースの管理者、すなわち旧オーナーだけだからです。買い手にできるのは「送るのをやめる」ことだけで、「受け取るのをやめさせる」ことはできない。この非対称性は、後述する情報漏洩の観点でも効いてきます。
5. 退職者・外注先が握ったままのオンコール
PagerDutyのようなインシデント管理ツールを入れている場合、通知先は「人」ではなく「スケジュール」と「エスカレーションポリシー」で定義されています。ここには、もう会社にいない人、もう契約の切れた外注先のエンジニアが、当時のまま載り続けていることがあります。
この場合の壊れ方は少し違います。アラートは鳴ります。エスカレーションも走ります。ただ、一次受けが反応しないので規定の時間が過ぎて二次へ回り、二次も反応せず、最後は誰も出ないまま「未対応」としてクローズされます。プロセスとしては完璧に機能しているのに、誰も現場に来ないという、書類上いちばんタチの悪い形です。権限の棚卸しをやったつもりでも、オンコールのスケジュールまでは見ないことが多いので、ここは特に残りやすい。
善意で監視を見続けている旧オーナー、という最も難しいケース
ここまでは「宛先が誤って残っている」話でした。ところが実務でいちばん扱いが難しいのは、宛先が意図的に残されているケースです。
売り手が、引き渡し後もアラートを受け取り続けている。しかもそれは善意です。「引き継いだばかりで大変だろうから、しばらくは自分も見ておこう」「万一落ちたら連絡してあげよう」。実際、そのおかげで救われた障害が何度もある、というケースは現実に存在します。買い手の側も、それをありがたいと思っています。ここには誰の悪意もありません。
この善意は、まず正当に評価すべきだと思います。自分が何年もかけて育てたサービスが落ちるところを見たくないという感情は、極めて健全なものです。多くの売り手は、金額の交渉が終わったあとも、そのサービスを気にかけ続けています。それは職業倫理であり、作った人間の愛着であり、責められる筋合いのものではまったくありません。
ただ、それでもなお、この状態は構造として問題です。理由は3つあります。
ひとつめ。その善意には期限があります。旧オーナーにも次の生活があります。半年後、1年後、旧オーナーが別の事業に本腰を入れた瞬間、あるいは単に通知をミュートした瞬間、その安全網は予告なく消えます。しかも、消えたことは誰にも通知されません（安全網が外れたことを知らせる安全網は、どこにもないので）。買い手のチームは、外れたことを知らないまま、外れる前と同じように安心し続けます。事故は、たいていその後に起きます。
ふたつめ。これは事業が独立していない証拠です。買い手が買ったのは事業であって、旧オーナーの善意ではありません。旧オーナーの目がなければ障害を検知できない事業は、その時点で自立していません。この状態は、無給サポート地獄と地続きです。あちらは「聞かれるから答え続けてしまう」構図ですが、こちらは「届いてしまうから見続けてしまう」構図で、売り手が自分の時間を無償で差し出しているという点はまったく同じです。しかも監視のアラートは、質問と違って夜中でも容赦なく飛んできます。
みっつめ。アラートの中身は、事業の内部情報そのものです。エラー通知には、スタックトレースが載ります。失敗したリクエストのパラメータが載ります。場合によっては、ユーザーのメールアドレスや、決済の金額や、内部のホスト名が載ります。善意で受け取っている旧オーナーは、悪意なく、事業の内部を覗き続けている状態になります。旧オーナーが完全に誠実であっても、その通知が届いているデバイスやSlackワークスペースが5年後にどう管理されているかは、誰にも保証できません。
だから、対処は「見ないでください」ではありません。「見なくても大丈夫な状態を、買い手が自分で作る」ことです。そのうえで移行期間の支援を頼みたいなら、期間と範囲を決めて正式な業務として依頼すればいい。曖昧な善意に頼るのは、売り手にとっても買い手にとっても不健全です。感謝は感謝として、宛先は宛先として、別々に処理するべき話なのです。
棚卸しの実務 ── 一覧を作り、そして必ず鳴らす
ここからは処方箋です。やることは2段階しかありません。一覧を作ることと、実際に鳴らすことです。
ステップ1: 通知先の完全な一覧を作る
まず、事業が使っている「通知を発する可能性のあるすべての仕組み」を列挙します。捜索範囲は、監視SaaSの管理画面だけでは足りません。次の全部です。
- 監視・APM・エラートラッキングのSaaS: 通知ポリシー・アラートルールの宛先を1本ずつ開く。ルール単位で個別のアドレスが書かれていることがあるので、デフォルトの宛先だけ見て終わりにしない
- クラウドの標準機能: CloudWatchアラームのSNSトピック、その配信先のサブスクリプション。請求アラート、ヘルスダッシュボードの通知先も含む
- サーバー内の設定ファイル: crontabのMAILTO、監視デーモンの設定、ログ転送の通知先、mailコマンドを叩いているシェルスクリプト
- アプリケーションのコード: 例外ハンドラ、バッチの失敗通知、管理者向けメールの送信先定数。ここはgrepが効く数少ない領域なので、メールアドレスの形と、Slack Webhookの形を検索する
- 外部サービスからの障害・警告通知: ドメインの更新期限、SSL証明書の期限、決済事業者からの重要なお知らせ、ストアの審査結果。これらの宛先はアカウントの登録メールなので、名義移管と一緒に確認する
- インシデント管理ツール: オンコールのスケジュール、エスカレーションポリシー、各ユーザーの連絡方法（アプリのプッシュ／SMS／電話）
一覧の形式は、「アラート名 / 発報条件 / 宛先 / その宛先の持ち主」の4列で十分です。重要なのは4列目です。宛先の欄に [email protected] と書いてあるだけでは何も分かりません。そのアドレスが誰の受信箱に落ちているのかまで書いて、初めて棚卸しになります。
ステップ2: 全部、実際に鳴らす
そして、ここが本題です。一覧を作っただけでは、まだ何も確認できていません。
設定画面のUIは、正確には嘘をつかないのですが、「そう書いてある」ことしか教えてくれません。そのアドレスが生きているかは教えてくれません。そのSlack Webhook URLがまだ有効かも教えてくれません。そのメールが受信側のスパムフィルタに吸い込まれていないかは、絶対に教えてくれません。移管の過程でDNSやSPFをいじっていれば、送れているつもりのアラートメールが全部迷惑メール判定されている、というのも普通にあり得ます。
だから、一覧のすべての経路について、テストアラートを実際に発報し、自分の端末で受け取ってください。監視SaaSにはテスト送信機能がありますし、なければ閾値を一時的に極端に下げて意図的に発報させればいい。SMS通知が設定されているなら、その番号を自分のものに書き換えて、実際に自分の携帯を鳴らす。「届いたことにする」のではなく、目の前でバイブレーションが鳴るところまで確認する。それがこの作業の完了条件です。
ステップ3: 切り替えは「足してから、消す」
宛先を移す順序も決まっています。新しい宛先を追加し、テストで受信を確認してから、古い宛先を削除する。逆にすると、その間に起きた障害の第一報が空中に消えます。
そして削除するときは、削除したことを旧オーナーに伝えてください。これは礼儀ではなく実務の話です。善意で見続けていた旧オーナーの側からは、通知が止まった瞬間、ただ「見えなくなった」だけだからです。「この日から通知先を移しました、これまでありがとうございました」の一言があるかどうかで、両者の安全度がまるで変わります。
買い手が確認すべきことと、査定への織り込み方
買い手の立場では、通知の宛先確認は技術的DDの中でも、コスト対効果が異様に高い項目です。管理画面を開いて一覧を作り、テスト発報するだけなので、多くても半日。それで「自分の事業が倒れたことを、自分が最初に知る」という状態が手に入ります。
質問の仕方には注意が必要です。「監視は入っていますか」と聞けば、答えは「入っています」。「アラートは飛びますか」と聞けば、答えは「飛びます」。どちらも本当のことなので、売り手は何ひとつ嘘をついていません。ただ、その質問では「誰に飛ぶか」だけが永遠に確認できないのです。
正しい依頼はこうです。「設定されているアラートの一覧と、それぞれの通知先を見せてください。そのうえで、今この場でテストアラートを1本発報して、私の端末で受け取らせてください」。存在の有無は質問ではなく、実演で確認する類のものです。そしてこの依頼は、売り手に対する不信の表明ではありません。売り手自身も「そういえば、誰に飛ぶか確認したことがなかった」と気づく場面が、実際にはかなり多い。
判明した状態は、次のように査定へ織り込みます。
- 宛先がすべて法人管理のアドレス・チャンネルで、テスト発報も通る: この論点で減点する理由はありません。引き渡し時に宛先を差し替える段取りだけの話になります
- 宛先の一部が旧オーナー・退職者の個人資産を向いている: 切り替えと検証のコストを見込みます。加えて、切り替えに旧オーナー側の操作が必要な範囲（本人のSlackワークスペースの無効化など）を特定し、その協力義務を引き渡し条件に明記します。買い手が単独で完了できない作業が残っている取引は、まだ終わっていません
- そもそも一覧が作れない（誰も全体像を把握していない）: これは金額の問題ではなく、引き渡しの前提が整っていない状態です。このまま引き継ぐと、引き渡し後の事故が起きたときに、事故が起きたことにすら気づけません。原因調査どころか、調査の起点が存在しない
なお、監視まわりで議題になりやすいのはDatadogの座席課金のような費用の話ですが、あれと本記事はまったく別の問題です。費用は請求書という形で必ず表面化するので、遅くとも翌月には気づきます。宛先には請求書に相当するものが存在しないので、障害が起きるまで気づきません。金の話は自動的にバレて、宛先の話は自動的にはバレない。厄介さでいえば、後者が上です。
最初の一報が届く先が、その事業の所有者だ
事業を持つということの実務的な意味は、突き詰めると「その事業に何かあったときに、最初に知る立場にいる」ということだと思います。売上を受け取る権利と、障害を知る義務は、本来ワンセットです。
ところが移管の現場では、この2つがきれいに分離してしまうことがあります。売上は買い手の口座に入る。契約書には買い手の名前がある。それなのに、その事業が真夜中に倒れたことを最初に知るのは、もうその事業とは何の関係もない人です。権利だけが移って、第一報だけが残ったという状態です。
そして、この状態には自浄作用がありません。平時に鳴らないことが正常な仕組みは、壊れていても正常に見えます。誰も困らないまま、半年でも1年でも続き、いちばん困る夜に、いちばん困る形で表面化します。
売り手にとって、これは資産の証明でもあります。「うちの監視はこの3系統に合計12本、通知先はすべてこの法人アドレスとこのチャンネルで、テスト発報のログはこれです」と即座に出せることは、そのまま事業の管理品質の証明になります。逆に、引き渡したあとも自分の携帯が鳴り続けている状態は、善意であっても、その事業が自分から独立していないことを認め続けることになります。手放したものは、ちゃんと手放させてあげるべきです。売り手自身のためにも。
やることは、拍子抜けするほど地味です。管理画面を開いて、宛先を一覧にして、テストアラートを1本鳴らす。半日で終わります。ただ、この半日をやったかどうかが、次に何かが落ちた夜に、自分の枕元でスマホが震えるかどうかを決めます。
買った事業が倒れたことを、自分が最初に知る。それだけのことが、実は「所有している」という言葉の中身のほとんどなのだと思います。引き渡しの前に、一度だけでいいので、鳴らしてみてください。
