解約する前に、先に直す——外部サービスをやめる日の設計
外部サービスをやめる日の設計は、「代わりに何を使うか」ではなく「いつ入口を差し替えるか」で決まる。2026年8月16日、打ち合わせの予約に使っていた外部サービスをやめるにあたり、契約を止めるより先に本番サイトの入口を差し替えた。
何が起きるはずだったか
その外部サービスの予約ページは、単なる道具ではなかった。サイトの主要な導線が、そのページへ直接つながっていた。無料の相談から始まり、診断、構築へ進む入口が、その一本のリンクに集約されていた。
契約を止めれば、そのリンクは死ぬ。しかも黙って死ぬ。押した人にはエラーだけが返り、こちらの管理画面には何も出ない。問い合わせが減ったことに気づくのは、数字を月末に見たときになる。
だから順序を固定した。入口を差し替えてから、契約を止める。 逆はやらない。
工程分解表:外部サービスをやめる
| 工程 | 無人化度 |
|---|---|
| その名前が本番のどこに書かれているかを全部拾う | 完全無人 |
| 生成物にも残っていないかを照合する | 完全無人 |
| 代わりの入口をどこにするか決める | 人間必須 |
| 本番の導線と文言を差し替える | 検品のみ人間 |
| 差し替え後、旧サービスへの参照が残っていないか数える | 完全無人 |
| 旧版をまるごと退避し、戻せる状態にする | 半自動 |
| 契約そのものを解約する | 人間必須 |
できる側
参照の洗い出しと、差し替え後の照合は機械の仕事だ。ここは人間がやると必ず取りこぼす。理由は、書かれている場所がソースだけではないからだ。
今回で言えば、サイトのソース、静的な代替表示、そしてこのブログを組み立てる仕組みの中にまで、同じ導線が入っていた。ソースだけを直して終わりにすれば、生成物の側に古いリンクが残る。だから差し替えのあと、旧サービスの名前が本番の配信物に一件も残っていないことを機械で数え、実際に公開されているページでも確かめた。
戻せるようにしておくのも機械側でできる。差し替える前の一式は、日付を付けてそのまま退避してある。
難しい側
機械に渡せないものが二つある。
ひとつは、代わりの入口を何にするかという判断だ。この相談は画面を共有して、公開していない管理画面をその場で見せることに意味がある。だから代わりの手段も、その価値を保てるものでなければならない。判断の基準は値段ではない。何を渡す場なのかで決まる。ここは業務を知っている人間にしか選べない。
もうひとつは、契約の解約そのものだ。AI社員には解約させない。契約は会社の意思なので、押すのは人間と決めてある。サイト側の手当てを先に終わらせておけば、いつ押しても壊れない状態を作れる。人間が押すべき一手を、いつ押しても壊れない状態まで持っていく。それが設計の仕事だ。
そして今回は、暫定の入口になった。予約ページが用意できるまでの間だけ、別の手段で申し込みを受ける。このとき文言も変えた。予約が成立しない手段なのに「予約する」と書いてあると、押した人の期待とずれる。暫定の導線には、暫定だと分かる言葉を置く。
自社の実例
このブログも同じ順序で守られている。記事はAI社員が書き、機械検品——禁止表現・台帳にない数字・規格崩れの照合——を通ったものだけが無人で公開される。ひとつでも引っかかれば公開されない。人間が事前に読む工程は無いが、通らないものは世に出ない。内容の最終責任はMON-AIが負う。
一般論として、道具の入れ替えは「新しいほうを触る作業」だと思われている。実際に手数がかかるのは、古いほうがどこに埋まっているかを数え切る側だ。
導入までの手順
- いま契約している外部サービスを並べ、それぞれが自社のどの導線につながっているかを書き出す
- つながっている先が「客が最初に触る場所」であるものに印を付ける
- 印の付いたものは、解約日を決める前に差し替え日を決める
締め
この線は、会社ごとに引き直せる。どの道具を機械に任せ、どの一手を人間の指に残すかは、業務の実態を知っている人にしか決められない。その順序を一緒に設計するところから始めたい方は、実装設計図か、無料相談へ。