---
name: incident-customer-notice
description: 障害やサービス停止のお客さま向けのお知らせを、段階（調査中、原因特定、経過観察、復旧）ごとに書き、復旧後のポストモーテム（事後報告）の要約まで作る。何が起きたか、影響を受けたのは誰か、何をしたか、今後何を変えるかを書き、ぼかさずに一言でおわびする。障害や停止が起きたとき、ステータスページの更新、サービスの不具合、データや請求の事故のとき、または障害のお知らせメール、状況のお知らせ、お客さま向けの障害報告書を頼まれたときに使う。
---

# 障害のお客さま向けのお知らせ

障害の最中、お客さまがすぐに知りたいのは3つ。原因はこちら側か、自分に影響があるか、次の連絡はいつか。復旧後に知りたいのは、何が起きたか、誰が責任を持っているか、再発しないよう何を変えるか。早く出し、確認できたことだけを書き、毎回次の更新時刻を書く。

## 使う場面

- お客さまにとって何かが止まっている、遅い、おかしいときで、ステータスページの投稿かメールが要る。
- 障害が次の段階に進み、更新が要る。
- 復旧して、何が起きたかと何を変えるかの要約をお客さまに送る。
- 個人データの漏えいを伴うセキュリティ事故には使わない。法令上の通知ルールがあるため、弁護士やプライバシー担当と一緒に書く [要確認: 日本の法令。確認先の例: 個人情報保護委員会]。お客さま1社の問い合わせへの返信にも使わない（reply-in-our-tone を使う）。

## 用意するもの

- お客さまに見えている症状（エラー、遅延、誤ったデータ）、影響のある機能、対象のお客さまや地域、タイムゾーンつきの発生時刻。
- いまの段階と、チームが確認できたこと。確認できていない原因は、お客さま向けのお知らせに書かない。
- 復旧のお知らせと要約には、終了時刻、平易な言葉での原因、対処、今後変えること、お客さまに必要な作業（処理の再実行、請求書の確認など）。
- 足りない事実は「[要確認: …]」と書く。チームが出していない復旧見込み時刻は、決して推測で書かない。

## 手順

1. **段階を決める。** 次のどれかにする: 調査中（症状は見えているが原因は不明）、原因特定（原因がわかり、修正中）、経過観察（修正を入れ、様子を見ている）、復旧。お客さまへの影響がわかってから15分以内に、最初の「調査中」を出す。ポストモーテムの要約は、そのあと別のお知らせとして出す。
2. **影響をお客さまの言葉で先に書く。** 「一部のお客さまがログインできません」「本日送信した請求書の税額が誤って表示されている可能性があります」。機能名は、お客さまが知っている呼び方で書く。影響を受けた人がわかれば書き、わからなければ「一部のお客さま」とする。
3. **していることを書く。確認できたことだけ。** 調査中:「現在調査しています」。原因特定: 原因が確認できたら、平易な言葉で書く。経過観察:「修正を適用し、状況を見ています」。原因の推測は書かない。初期の更新で取引先のせいにしない。
4. **次の更新時刻を書く。** 毎回の更新を「次回は [時刻、タイムゾーン] までにお知らせします」で終える。このスキルの既定値: お客さまの作業が止まっているあいだは30分ごと。影響を受けている人がいるあいだは、更新の間隔を1時間より空けない。何も変わっていなくても、その時刻に「変化なし」と出す。
5. **復旧のお知らせを書く。** 開始時刻、終了時刻、継続時間、影響を受けたもの、何で直ったか、お客さまに必要な作業。おわびは1回、平易に:「申し訳ありません。[時間]のあいだ、[作業]ができない状態になっていました。」「ご不便をおかけした可能性があり」のようなぼかした言い方はしない。
6. **約束した期限内にポストモーテムの要約を書く。** 何が起きたか（3〜6行の時系列）、なぜ起きたか（平易な言葉での根本原因）、何をしたか、何を変えるか（担当者か期日がわかっていれば添えた具体的な対策）、問い合わせ先。このスキルの既定値: 5営業日以内に送る。
7. **短く、どの経路でも同じ内容にする。** ステータスページ、メール、アプリ内バナーで同じ事実を伝える。状況の更新は2〜4文。

## 出力の形式

```markdown
**[段階] — [機能／サービス]: [影響を短く]**
[日付、時刻、タイムゾーン]

[お客さまに見えている症状と、影響を受けている人。][対応状況。][お客さまに必要な作業があれば。]
次回は [時刻、タイムゾーン] までにお知らせします。
```

復旧と要約:

```markdown
**復旧 — [機能]: [影響]**
[開始]から[終了]まで（[継続時間]）、[誰に、何の影響があったか]。[何で直ったか。][お客さまに必要な作業。なければ「お客さま側での作業は必要ありません。」]申し訳ありません。[できなかったこと]ができない状態になっていました。

# [日付]に起きた[機能]の[影響]について
**概要:** [2〜3文]
**時系列（[タイムゾーン]）**
- [時刻] — [出来事]
**原因:** [根本原因を平易な言葉で]
**今後の対策:** [対策。日付があれば添える]
**お問い合わせ:** [連絡先]
```

## 例

**入力:**

> 18:12 JST: 決済画面で、カード決済のお客さまにエラーが返る。18:40: 決済代行会社との接続に使う証明書の期限切れと特定。18:55: 証明書を更新し、決済が通るように。19:30: 安定を確認し、復旧。決済の失敗はおよそ380件。お客さまは再度決済できる。対策: 証明書の自動更新と、期限の30日前に鳴るアラート。担当: 基盤チーム、月末まで。

**出力（抜粋）:**

```markdown
**調査中 — 決済画面: 一部のお客さまのカード決済が失敗しています**
6月4日（木）18:20 JST

決済画面でカード決済をすると、一部のお客さまにエラーが表示されています。現在調査しています。
次回は 18:50 JST までにお知らせします。

**原因特定 — 決済画面: 一部のお客さまのカード決済が失敗しています**
6月4日（木）18:45 JST

原因がわかりました。決済代行会社との接続に使うセキュリティ証明書の有効期限が切れていました。現在、更新しています。
次回は 19:15 JST までにお知らせします。

**復旧 — 決済画面: 一部のお客さまのカード決済が失敗していました**
18:12から18:55 JST まで（43分間）、カード決済のお客さまが決済画面で支払いを完了できない状態でした。期限の切れた証明書を更新し、現在は決済できます。決済が失敗した方は、お手数ですがもう一度お試しください。失敗した決済で料金は発生していません [要確認: 請求が発生していないことの確認]。申し訳ありません。43分間、お支払いができない状態になっていました。
```

## 送る前のチェック

- [ ] 1行目に段階、機能、影響が書いてある。
- [ ] どの更新にも、タイムゾーンつきの次回更新時刻がある。
- [ ] チームが確認する前の原因を書いていない。
- [ ] 復旧のお知らせに、開始、終了、継続時間、お客さまに必要な作業が書いてある。
- [ ] おわびは平易な1文で、「ご不便をおかけした可能性」のようなぼかしがない。
- [ ] 時刻、件数、対策はすべて入力にあるもので、ないものは「[要確認: …]」になっている。

## よくある失敗

- 原因がわかるまで投稿を待つ。まず「調査中」を出す。
- 約束した更新時刻を過ぎる。何も出さないより、「変化なし」と出す。
- 取引先のせいにする。お客さまが選んだのは自社。責任は自社で持ち、取引先の名前は、役に立つ場合に限って要約で出す。