機能廃止のお知らせの書き方|終了日・代替手順・移行案内の文例
機能廃止のお知らせでは、何がいつ変わるか、利用者に必要な対応、データの扱い、相談先を分けて伝えます。通知を送るだけで終わらせず、移行できない条件が残っていないかも確認します。
提供側にとっては一つの機能の整理でも、利用者にとっては日々の手順や外部システムを変える作業かもしれません。今回は、終了の方針が決まった後の案内を扱います。廃止するかどうかを検討する段階は、使われていない機能の見直し方を参照してください。
- 終了する範囲と、変わらない範囲を分ける。
- 相手の役割ごとに、必要な作業と確認方法を書く。
- 代替できない用途や未解決の相談を隠さず残す。
終了が決まった範囲と影響を確認する
最初に、何を終了するのかを具体的にします。「旧機能を終了します」だけでは、画面を使えなくなるのか、保存済みデータを見られなくなるのか、外部連携も止まるのかが分かりません。
GOV.UKのサービス終了ガイドは、変更内容と理由、利用者に必要な行動、データの扱いを説明することを挙げています。本記事では機能単位の終了案内に応用し、次の確認表を提案します。政府向けの運用期間などを一般的な基準として使うものではありません。
| 確認項目 | 案内前に確定すること |
|---|---|
| 終了対象 | 機能名、画面、操作、プランなどの範囲 |
| 終了日時 | 日付、時刻、必要に応じたタイムゾーン |
| 利用者への影響 | できなくなる操作と、変わらない操作 |
| 代替方法 | 新しい手順、必要な権限、代替できない用途 |
| データ | 閲覧・出力・移行の可否、保存・削除の扱い |
| 外部連携 | 連携先の変更、形式の違い、確認する担当 |
| 支援 | 問い合わせ先、案内資料、対応する範囲 |
実際に必要な予告期間は、契約や利用状況、移行作業などを踏まえて確認します。終了日と利用者側の対応期限が異なる場合は、二つの日付を分け、その理由も説明します。「何日前に送れば十分」という一律の目安は置かず、契約・情報管理・開発・顧客対応の担当者で整合を取ってください。
最初のお知らせに入れる項目
以下は、架空の「旧CSV出力」を新しい出力方法へ切り替える文例です。実在するサービスの終了予定や、アーコレ!の仕様変更ではありません。角括弧は読者が実際の確定条件へ差し替える欄です。
件名:[旧CSV出力]提供終了と移行のお願い
いつも[サービス名]をご利用いただきありがとうございます。
[終了理由]に伴い、[旧CSV出力]の提供を[終了日時]に終了します。
終了する操作
[対象画面・操作]からの旧形式の出力ができなくなります。[変わらない操作や機能]には変更ありません。お願いしたい対応
[対象者]の方は、[対応期限]までに[新しい方法]をご確認ください。移行手順は[手順書へのリンク]をご覧ください。新しい方法との違い
[列名・形式・権限などの相違点]があります。[代替できない用途]については、同じ方法では対応できません。ご利用中の場合は[相談先]へご連絡ください。保存済みデータの扱い
[閲覧・出力・保存・削除について、確認済みの内容]です。必要な作業がある場合は[手順と期限]をご確認ください。ご不明点や移行が難しい事情がある場合は、[問い合わせ先]までご相談ください。
[署名]
理由は提供側の事情だけを長く説明するより、利用者が変更を理解できる具体性を優先します。一方、「より便利になるため」とだけ書いて、今の用途を満たせなくなる点を省略しないようにします。
新機能の紹介メールと違い、機能廃止では「何ができなくなるか」と「いつまでに何をするか」が重要です。追加機能の案内はアップデート告知メールの書き方と分けて考えましょう。

対象者別に対応を分ける
同じ会社でも、契約窓口、設定を行う管理者、日々使う担当者が別の場合があります。契約窓口へ一通送ったことと、必要な担当者が内容を理解したことは同じではありません。
管理者・利用者に必要な対応
管理者には権限や設定の変更、利用者には日々の操作の変更を案内します。転送をお願いする場合は「社内の皆さまへ」だけでなく、「旧形式を使って月次報告を作る方」のように対象を説明します。
次の表は、架空の移行を整理した例です。完了の根拠を「メールを送った」だけにしない点に注目してください。
| 対象 | 必要な作業 | 確認担当 | 完了の根拠 | 未解決点 |
|---|---|---|---|---|
| 管理者 | 新しい出力権限を確認 | 管理担当 | 対象者が操作できることを確認 | 権限の追加対象 |
| 月次報告の担当 | 新しい形式で報告書を作る | 業務担当 | 必要な項目を転記できた記録 | 旧列名を使う数式 |
| 外部連携の担当 | 取込処理の対応を確認 | システム担当 | 新形式で取込を試した結果 | 未対応の形式差 |
自社で使う場合は、次の一行を必要な対象者の分だけ複製できます。
| 対象 | 必要な作業 | 確認担当 | 完了の根拠 | 未解決点 |
|---|---|---|---|---|
| [役割] | [行うこと] | [確認する人] | [確認できた記録] | [残っている条件] |
利用者側の確認が必要なのに、提供側の推測だけで完了へ変更しないようにします。
外部連携の担当者に必要な対応
出力ファイルやAPIを他のシステムに取り込んでいる場合、画面上で新しい方法が使えても移行が終わるとは限りません。項目名、文字コード、日時の表現、認証方法など、今回変わる箇所を具体的に示します。
変更のない項目まで網羅する必要はありません。影響する仕様の差分と、確認用の資料や試せる環境があるならその案内を用意します。利用者側にも調査・修正・確認が必要になることを見込み、担当者と連絡できる状態にします。
期限前の確認と相談への返信
確認メールでは初回案内を丸ごと再送するより、期限と未確認の作業を見つけやすくします。
件名:[旧CSV出力]終了に向けた対応状況のご確認
[終了日時]の提供終了に向け、[対象の作業]の確認状況を伺いたくご連絡しました。現時点で、[未確認の項目]の完了を確認できていません。
すでに対応済みの場合は、行き違いとなり失礼しました。[確認方法]で状況をお知らせいただけますと幸いです。
移行が難しい場合は、差し支えない範囲で[困っている用途・条件]を[窓口]へお知らせください。手順は[案内リンク]から確認できます。
相談を受けたら、何ができないのかと業務への影響を確認します。その場で終了延期や追加開発を約束せず、確認する担当と次の連絡予定を伝えます。未決定の対応をどう返すかは、機能要望への返信の考え方も参考になります。
終了後の案内先を残す
終了後に古いブックマークや手順書から訪れる人もいます。案内先では、終了したこと、現在使える方法、問い合わせ先を確認できるようにします。代替がない場合はその旨を明記し、新しいページへ移せば解決するように見せないでください。
変更の履歴はリリースノートに残します。記録の続け方はリリースノートの運用を参考にし、今後の計画との関係はプロダクトロードマップと整合させます。各案内で終了日時や対象範囲が食い違っていないかも確認します。
まずは対象者別の移行表を一件作ってください。「誰が、どの作業を終えれば移行できたと言えるか」を説明できると、お知らせの文面も具体的になります。
参考資料
- GOV.UK:Retiring your service:利用者への説明、移行時の支援、データの扱いを参照。文例と移行表は本記事独自の提案で、法的な通知要件を満たすことを保証するものではありません。