公開後の保守はどこまでやる？点検の頻度、更新通知、終了告知を先に決める

保守メモの全体像

まず、決めることを5つに絞ります。

• 点検の頻度、決め方の例(説明用)：月1回、第1日曜に30分まで
• 更新の知らせ方、決め方の例(説明用)：ページ下部の「更新履歴」に日付と一行を書く
• 対応すること、決め方の例(説明用)：表示崩れ、動かなくなった不具合、公開してはいけない情報の混入
• 対応しないこと、決め方の例(説明用)：個別の機能追加、古いブラウザへの対応、即日返信
• 終了の条件、決め方の例(説明用)：3か月連続で点検できなかった、費用や手間が負担になった

この表を、リポジトリのREADMEか手元のメモに貼っておきます。公開ページに載せるのは「対応しないこと」と「終了の可能性」の2点だけで構いません。

月1回の点検項目

点検は「壊れていないかを確認する作業」に限ります。改善は点検に混ぜず、やりたいときにやる別作業にします。

点検リスト(コピー用)

【月1回の点検(30分まで)】
□ 公開URLを開き、主な操作を1回通して試す(入力→結果表示)
□ スマホと PC のどちらかで、表示が崩れていないか見る
□ 外部サービス(API、フォーム、広告など)が動いているか確認する
□ 外部サービスの料金・利用上限の通知メールが来ていないか見る
□ ホスティングやドメインの請求・更新期限を確認する
□ 問い合わせや報告が溜まっていないか見る
□ 更新履歴に「○月点検済み」と1行書く(変更がなくても可)
□ 30分で終わらなかった項目は、次月に回すか「対応しない」へ移す

「更新履歴に点検済みと書く」のは、利用者への知らせであり、自分への記録にもなります。ただし、書くことで「毎月必ず見ています」という約束に見えないよう、「目安として月1回確認しています」と書きます。

外部サービスに依存している場合

AIのAPIや地図、フォーム送信などを使っているツールは、自分が触らなくても止まる可能性があります。仕様変更や利用条件の変更は、提供元の告知で知ることになります。使っているサービスの公式ブログや管理画面のお知らせの場所を、保守メモに1行ずつ書いておいてください。何を購読するかは、使っているサービスごとに違います。

対応しないことを先に書く

保守が重くなる原因の多くは、頼まれていない約束を自分で増やすことです。「対応しないこと」は、冷たい宣言ではなく、続けるための安全柵です。

公開ページに書く例(説明用)

このツールは個人が趣味で運営しています。
・動作の保証や、特定の環境での動作確認は行っていません
・個別の機能追加や、お問い合わせへの個別返信は約束できません
・確認は目安として月1回です。不具合のご連絡は受け付けますが、対応時期はお約束できません
・予告なく内容を変更したり、公開を終了したりすることがあります

なお、これは仕組みを説明する文面の例であり、法的な免責を保証する文章ではありません。個人情報を預かる、料金を受け取る、といった形で運営する場合は、別途の確認が必要になります。ここでは、データを預からない無料ツールを想定しています。

更新通知を最小限にする

更新の通知は、頻度を絞るほど続きます。おすすめは次の2段構えです。

• 通常の更新:ページ下部の更新履歴に日付と一行を足す
• 利用者に影響がある変更(使えなくなる機能、保存データの扱いが変わるなど):ページ上部に数週間表示する

SNSやメールでの告知を約束する必要はありません。「更新はこのページの履歴に書きます」と1か所に決めておけば、後から「見落とした」と言われても説明できます。

終了のしかたを先に決める

終了は失敗ではありません。決めておくと、気持ちよく閉じられます。手順は次の順で考えます。

1. 終了の条件を決める:点検を3か月続けて見られなかった、外部サービスの費用が負担になった、など
2. 告知期間を決める:たとえば終了の1〜2か月前に表示を出す(説明用の例です)
3. データの扱いを決める:利用者の入力を保存している場合は、削除する時期と、保存したい人が取り出す方法を書く
4. 閉じ方を選ぶ:下表を参照

閉じ方の選び方

• ページは残し、終了のお知らせに差し替える、向いている場合：検索やブックマークから来る人に事情を伝えたい、確認できた公式の説明：(編集上の提案)
• ホスティングを一時停止する、向いている場合：費用を止めつつ、戻す可能性を残したい、確認できた公式の説明：Vercelでは、プロジェクトを一時停止すると本番デプロイへのアクセスに503エラーが表示されます。再開は再デプロイ不要で、数分以内に復帰します(Vercel: Managing projects)
• プロジェクトを削除する、向いている場合：完全に閉じる、確認できた公式の説明：同ドキュメントによると、削除するとデプロイ、ドメイン、環境変数、設定も削除されます。残したいものは先に別プロジェクトへ移します(Vercel: Managing projects)
• ソースコードのリポジトリをアーカイブする、向いている場合：公開コードを読めるまま更新を止めたい、確認できた公式の説明：GitHubのアーカイブはIssueやコード等が読み取り専用になり、いつでも解除できます。事前にIssueを閉じ、READMEを更新することが推奨されています(GitHub Docs: Archiving repositories)
• 個別ページを「恒久的に消えた」と返す、向いている場合：完全に消したページがある、確認できた公式の説明：HTTPの410は「恒久的に利用できない」状態を示し、永続的か不明なら404を使うとMDNは説明しています(MDN: 410 Gone)

Vercel以外のホスティングを使っている場合は、同じ仕様とは限りません。ご自身の環境の公式ドキュメントで、一時停止や削除の影響を確認してください。

終了告知の文面(説明用)

【サービス終了のお知らせ】
「○○ツール」は、2027年○月○日をもって公開を終了します。
理由:運営を続ける時間を確保できなくなったためです。
・終了日以降は、このページにアクセスできなくなります
・入力内容を保存していた場合は、○月○日までに画面の「書き出し」からお手元に保存してください
・終了日以降、保存されていたデータは削除します
・ソースコードは○○に公開したままにします(更新は行いません)
ご利用ありがとうございました。

日付と保存データの項目は、実際の運営内容に合わせて書き換えてください。データを保存していない場合は、その2行は削除します。

AIに下書きを任せる依頼文

AIに任せるのは「文面の下書きと、抜け漏れの指摘」までです。何を約束するか、いつ終了するかは自分で決めます。

次の条件で、個人開発の無料Webツールの「保守メモ」を作ってください。
・ツール概要:(例)文字数を数えるだけの静的ページ
・外部サービス:(例)なし / アクセス解析のみ
・保存するデータ:(例)なし
・使える時間:月30分
・やらないこと:機能追加の約束、個別返信
出力:1) 月1回の点検リスト 2) 公開ページ用の「対応しないこと」 3) 終了告知文(日付は○で残す) 4) 私が決めていない項目の質問
法的な保証はしないでください。

人が確認すること

• 返ってきた点検項目が、本当に30分で終わるか(実際に1回試す)
• 「保証します」「必ず対応します」といった、守れない言い回しが混じっていないか
• 外部サービスの名前や仕様の記述を、AIの出力のまま信じていないか(公式ページで確認)
• 個人名、メールアドレス、APIキーなどの実データを依頼文に貼っていないか

保守メモの完成形

最後に、ここまでを一枚にまとめます。これをREADMEの末尾に貼り、○を埋めてください。

# 保守メモ(○○ツール)
公開日:○年○月○日 / 最終点検:○年○月

■ 点検:月1回(第○日曜・30分まで)。リストは上記の点検リストを使う
■ 更新通知:ページ下部の更新履歴のみ。影響が大きい変更は上部に数週間表示
■ 対応すること:動かない不具合、表示崩れ、公開してはいけない情報の混入
■ 対応しないこと:個別の機能追加、古い環境への対応、即日返信
■ 終了の条件:3か月連続で点検できない/費用・手間が負担になった
■ 終了の手順:告知を○週間表示 → 必要ならデータ書き出し期間 → 一時停止または削除 → リポジトリをアーカイブ
■ 外部サービス:(名前と、お知らせを見る場所)

最初の点検は、公開から1か月後にカレンダーへ入れておくのがおすすめです。1回やってみて30分を超えるなら、項目を減らすか、ツールの機能を減らすほうが、後々の負担が小さくなります。