2026年9月7日
副業サービスを終わらせると決めてから3週間、まだ消していない。畳む前に確認した6つと、まだ終わっていない4つ
2026年8月16日、自分で作った献立アプリを終わらせると決めた。個人で作ったWebアプリで、冷蔵庫の中身を撮るとAIが献立を返す。7月18日に公開して、ちょうど30日だった。
有料プランは用意していたが販売前で、売上はゼロ。登録者は自分を含めて4人。招待して使ってもらった3人が、全員別々の場所で離脱した。それが終了を決めた理由だ。
今日は9月7日で、そのアプリはまだ動いている。
3週間、消していない。この記事は、その期間に確認したことをそのまま書いたものだ。確認しただけで、まだ実施していない項目のほうが多いので、最後にどれが済んでいてどれが済んでいないかの表を置いた。
なぜすぐ消さなかったのか
最初は「ドメインの契約が2027年7月まで残っているから」だと思っていた。払ってあるものを捨てるのはもったいない、という理由だ。
ただ、それだけならアプリを止めて、1枚の終了ページに差し替えれば済む。ドメインは保有したまま、動くものを消せばいい。
実際に手を動かそうとして、止まった理由は別だった。消す順番を調べていたら、順番を間違えると別の稼働中のシステムが止まると分かったからだ。詳しくは後半に書く。
急いで消す理由が特にない一方、急いで消すと壊すものがある。それで、まず調べることにした。
1. 置いておく費用（確認済み）
私の構成は Cloudflare Workers + D1（データベース）で、使った分だけの従量課金だ。無料枠の内側なら請求は立たない。
何が動いているかを確認した。
| 動いているもの | 実態 |
|---|---|
| Webサイト本体 | リクエストは多い時間帯で1時間25程度（Cloudflareの管理画面で確認） |
| データベース | 読み取りのみ。新しい書き込みは発生していない |
| 毎時の監視処理 | 1時間に1回起動して、その日のAI利用額を1回読む |
| AIの呼び出し | 使う人がいないので発生しない |
| ドメイン | 2027年7月22日まで支払い済み |
このアプリのコストは、ほぼ全部がAIの従量課金だった。稼働していた30日間でも、AI利用料は概算で140円（1回あたりの単価から計算した推計値で、請求書の実額ではない）。使う人がいなくなれば、ここはゼロになる。
毎時の監視処理は中身を読んだ。「その日のAI利用額が閾値を超えたらLINEに通知する」というもので、AIは呼ばない。その日の利用が0件なら、データベースを1回読んで即座に終了する実装になっている。月720回でも無料枠の誤差だ。
ここまでは確認できた。ただし「月0円だった」と請求画面で確かめたわけではない。 3週間ぶんの請求がどうなっているかは、次の請求で見る。
2. ドメインの自動更新（実施済み・これが一番危なかった）
費用がほぼゼロだと分かった時点で、「じゃあ忘れていい」と思いかけた。ここが分かれ目だった。
0円で置けることと、何も決めなくていいことは違う。
ドメインの自動更新は、既定で有効になっている業者が多い。私が使っているCloudflare Registrarもそうだ。つまり「もう更新しない」と頭の中で決めていても、設定を変えなければ勝手に更新される。管理画面に出ていた更新価格は年10.46ドル（1ドル148円として1,550円ほど）だった。
そして調べて分かったのだが、引き落とされるのは有効期限の当日ではない。
最初の自動更新の試行は有効期限の約30日前に行われます
Cloudflareの公式ドキュメントにこう書いてある。私のドメインは2027年7月22日が期限なので、課金は2027年6月22日ごろだ。1か月早い。しかも同じページに「無効化は有効期限の30日以上前が推奨」とある。つまり実質、6月に入る前に決めておく必要がある。
正直に書くと、私はこの記事を書くまでこの設定を見ていなかった。管理画面に「有効期限 2027年7月22日」と出ているのを見て、勝手に「そこで終わる」と思い込んでいた。終わるのではなく、そこで更新されるのが既定の動作だった。
もうひとつ勘違いしていたのは、期限切れ後のことだ。更新しなければその瞬間に他人が取れると思っていたが、実際は**30日間の復旧猶予期間（Redemption Grace Period）**がある。この間なら追加料金を払って取り戻せる。
止め方は、Cloudflareの場合はこうだった。ゾーンの概要ページを下にスクロールすると右側に「ドメイン登録」の枠があり、そこの**「ドメイン登録の管理」**から登録の詳細ページへ移る。「概要」タブに 状態／有効期限／更新価格／自動更新 が横並びで出ているので、いちばん右のトグルを切る。実際にやってみて15秒だった。
切ったあとの見え方に、ひとつだけ引っかかる点がある。有効期限の表示は「2027年7月22日」のまま、まったく変わらない。 変わるのはトグルの状態だけだ。切れたかどうかは、期限の表示ではなくトグルを見て判断する。
.com の年額そのものの比較は独自ドメインはどこで取ると安いのかに書いた。ここで言いたいのは金額ではなく、「更新しない」は設定を変えないと成立しないということだ。
3. 決済の受け口（確認済み）
月500円の有料プランを用意していたので、そこが本当に塞がっているかを確認した。
画面から購入ボタンを消すだけでは足りない。URLを直接叩かれたときにサーバーが決済を受け付けるかどうかが本体だ。私の場合は設定で販売スイッチをオフにしていて、決済用のAPIもサーバー側で拒否するようになっていた（コードを読んで確認した。本番URLを叩いての動作確認まではしていない）。
実際にサブスクリプションを販売していた場合はもっと直接的で、サービスを止めても課金は止まらない。止めるのはサービス側ではなく決済事業者側の設定になる。ここは残す残さない以前の問題だ。
4. 預かったデータ（未実施・方針だけ決めた）
ログイン機能をつけていたので、利用者の記録がデータベースに残っている。4人のうち3人は私以外だ。
終了を決めたとき、データベースは丸ごと手元に落としてある。判断の根拠を残すためだ。ただし手元にコピーがあることと、本番から消すことは別で、後者はやっていない。
今回決めた方針はこれだ。
他人の記録は先に消す。自分の記録は残す。
10か月そのままにする理由がない。判断の根拠としては手元のコピーで足りる。
ただし決めただけでは片づかないことが2つある。ひとつは、ログイン経路を残したままだと、消した人がもう一度ログインした時点で記録が作り直されること。もうひとつは、手元に退避したコピーをいつまで持つかを決めていないこと。「消す」と言い切るなら、ログインごと止めるのか、告知ページに差し替えるのかまで決める必要がある。ここはまだ決まっていない。
5. 人が来なくても、機械は来る（確認済み）
管理画面のアクセス記録を見ていて、意外な数字が出ていた。
利用者はゼロのはずなのに、深夜4時でも訪問者が2〜4人いる。1時間あたりのリクエストは5〜25で、24時間途切れない。
アクセス元まで調べたわけではないので断定はしない。ただ、深夜も昼も一定の間隔で来ていて、人間の生活時間の形をしていない。検索エンジンのクローラーと、脆弱性を探して回る自動スキャンだろうと考えている。ドメインが生きて応答を返す限り、これは止まらない。
これに気づいて、4番の優先度が上がった。「誰も使っていない」と「誰も来ていない」は別のことだった。 使う人がいなくても、外から叩かれ続けるものを10か月置くなら、中に他人のデータを入れたままにする理由はない。
6. 消す順番（未実施・ここが一番の学び）
最後に、冒頭で「調べていたら止まった」と書いた件だ。
アプリを消すというと、普通はこう考える。
- アプリ本体（Worker）を削除する
- データベースを削除する
- ドメインを解放する
この3つだけなら、他には何も起きない。問題は、片づけのついでにやりたくなる4番目のほうだった。
AIのAPIキーを、複数のプロジェクトで使い回していた。 費用の管理を簡単にするつもりで1本しか作っておらず、この献立アプリと、毎週日曜に売上レポートを送ってくる別のプログラムが、同じキーを共有していた。
ここに2つの落とし穴がある。
アプリを消しても、キーは消えない。 キーの本体はAI提供元のアカウントにあり、アプリ側にはそのコピーが置いてあるだけだ。アプリだけ消すと、有効なキーが「どこで使われているか分からないまま生き続ける」状態になる。私の場合はさらに悪いことに、過去の設定ミスで、設定名の中にキー文字列がそのまま残っている項目がある。
逆にキーを失効させると、共有している別のプログラムが止まる。 しかもこの手の無人で動くプログラムは、止まったことを自分から報せてこない。私は別件で、無人のプログラムが2週間おかしくなっているのに気づかなかったことがある（その失敗はZennに書いた。原因はキーではなくエラーの拾い方だが、「無人のものは黙って壊れる」という点は同じだ）。
つまり、消す順番はこうなる。
- どのキーがどこで使われているか、先に洗い出す
- 残すほうのプログラムに新しい専用キーを発行して差し替える
- 差し替えたプログラムが動くことを確認する
- アプリ本体・データベース・ドメインを削除する
- 最後に、古い共有キーを失効させる
ポイントは2番だ。消すほうに新しいキーを入れても意味がない。 古いキーは残るほうでも使われているので、失効させれば結局止まる。新しくするのは「残すほう」だ。ここを逆にしかけた。
畳む作業でいちばん危ないのは、消す対象そのものではなく、それが黙って支えていたもののほうだった。
いまの状態
| 項目 | 状態 |
|---|---|
| 置いておく費用の確認 | 確認済み（請求画面での実額確認は次回請求時） |
| 決済の受け口 | コード上は確認済み（本番での動作確認は未実施） |
| アクセスの実態 | 確認済み（アクセス元の特定まではしていない） |
| 消す順番の整理 | 確認済み |
| ドメインの自動更新を切る | 実施済み（2026年9月7日。期限2027年7月22日で失効予定） |
| 残すプログラムのキーを分離する | 未実施 |
| 他人のデータを本番から消す | 未実施（方針だけ決定） |
| アプリ本体・DB・ドメインの削除 | 未実施（上の3つが終わってから） |
「サービスを終了しました」と書いてその日のうちに全部消すほうが、記事としてはきれいに終わる。ただ実際には、終了を決めた日と、消す作業をする日と、契約が切れる日は、それぞれ別の日にやってくる。その間の期間に何もしないと、決めたはずのことが勝手に進む。
畳むのを先延ばしにしているなら、まず自動更新の設定だけ見に行くことをすすめる。私の場合はそこが、いちばん静かにお金が出ていきかけた場所だった。