Claudeで障害のお知らせ文とサポート想定問答を作る — Projectsで一度に

自社サービスの障害や仕様変更が起きたとき、顧客向けのお知らせ文とサポート窓口の想定問答は、同じ元メモから同時に作るのが安全です。別々に書くと、告知では「調査中」の原因を、窓口の返答では言い切ってしまうといったズレが出ます。ここでは、Claudeのプロジェクトに元メモを1枚置き、告知文・返答案・「言えること/まだ言えないこと」の表を一度に組み立てる手順を説明します。

障害の初動でお詫びの声明を出す場面はClaudeでお詫び文と謝罪リリースの初動声明を下書きする手順、社内向けの顛末書は障害報告書(顛末書)をClaudeで起こす手順にあります。この記事は、その間にある「顧客とサポートに向けた日々の情報提供」を扱います。

3つの成果物を同じ元メモから作る

作るのは3点です。それぞれ読み手も、載せてよい情報の深さも違います。

順序は表が先です。表で「何を言ってよいか」を決めてから、告知文と想定問答はその表だけを材料に書かせます。表を飛ばして告知文から頼むと、Claudeはメモの情報をすべて使える材料として扱い、社内事情まで文面に混ぜることがあります。

プロジェクトを作って資料と指示を置く

プロジェクトは、独自のチャット履歴とナレッジベースを持つ作業空間です。障害対応のたびに指示を貼り直さずに済むよう、平時に1つ作っておきます。

Team・Enterpriseプランでは、作成時に公開範囲も選びます。「自分と招待した人だけ」か「組織全体」かです。障害対応の下書きには未公表の情報が入るため、最初は招待した人だけにしておくと扱いやすくなります。

ナレッジに置く資料

置くのは、事案が変わっても使い回せる資料です。個別の障害のメモは、プロジェクトではなく事案ごとのチャットに貼ります。

顧客の氏名や契約内容といった個別の情報は、ナレッジに置きません。個別の問い合わせに答えるときは、返答案の雛形だけをClaudeに作らせ、顧客固有の部分は担当者が入れます。

プロジェクト指示の例

指示には、成果物の順序と、書いてはいけないことを入れます。以下は一例です。

あなたはカスタマーサポート部門の文書下書き係です。
障害・仕様変更の元メモを受け取ったら、次の順に作ります。
1. 「言えること/まだ言えないこと」表。メモの各項目を
   「言える」「条件付き」「まだ言えない」に仕分け、根拠のメモ行を添える
2. 公開用のお知らせ文。表の「言える」だけを事実として書く
3. サポート向け想定問答。返答案ごとに、使った表の項目を示す
守ること:
- メモにない日時・数値・原因・補償内容は書かない。不明は【要確認:○○】と残す
- 原因と復旧見込みは、メモに確定と明記されたものだけ断定する
- 補償・返金は、ナレッジの対応方針にある範囲だけを案内する。方針にない約束はしない
- 最終承認は人が行う。承認済みとは書かない

技術者のメモを同じ型にそろえる

技術者のメモは、時系列のログだったり、チャットの断片だったりと、書き手ごとに形が違います。Claudeに渡す前に、同じ欄に揃えておくと、表への仕分けがぶれにくくなります。

【事象】
【検知した日時】
【影響を受ける機能・利用者の範囲】
【影響を受けない範囲】(確認済みのものだけ)
【現在の状況】(調査中 / 対応中 / 復旧済み)
【暫定の回避策】
【原因】(確定 / 推定 / 不明 のいずれかを必ず付ける)
【復旧の見込み】(確定 / 目安 / 未定)
【次回更新の予定時刻】
【社内限りの事情】(外に出せない理由も書く)

欄を埋めるのは技術者です。埋められない欄は空欄にせず「未確定」と書いてもらいます。空欄のままだと、Claudeが前後の文脈から埋めてしまう余地が残ります。

仕様変更の場合は、欄を次のように入れ替えます。

手順1: 「言えること/まだ言えないこと」表を先に作る

新しいチャットを開き、メモを貼って表を頼みます。

次のメモから、「言えること/まだ言えないこと」表を作ってください。
列は 項目 / メモの内容 / 区分 / 根拠のメモ行 / 言えるようになる条件。
区分は「言える」「条件付き」「まだ言えない」の3つです。
- 確認済みと明記された事実だけを「言える」にする
- 推定や目安は「条件付き」にして、書き方の注意を条件の列に書く
- 社内限りの事情は「まだ言えない」にして、理由を条件の列に書く
メモにない項目は追加しないでください。

返ってきた表は、例えば次のような形になります。内容は架空の例です。

ここで人が表を直します。区分を決める責任は、Claudeでなく広報・法務・サービス責任者にあります。Claudeの仕分けは案です。表の「言える」に入った項目だけが、告知文と想定問答に使える材料になります。

手順2: 表を材料にお知らせ文を書かせる

表が固まったら、同じチャットで続けて頼みます。

確定した表の「言える」と「条件付き」だけを材料に、公開用のお知らせ文を作ってください。
構成は 件名 / 現在の状況 / 影響を受ける方 / 今できること / 次回更新 / 問い合わせ先。
- 「条件付き」の項目は、表の条件の列に従って「推定」「目安」を文面に残す
- 「まだ言えない」の項目は、文面に書かない
- 次回更新の時刻は、メモにあるものだけを書く
- 掲載先がステータスページ、メール、アプリ内の3種類なので、それぞれの長さで3種類出す

仕様変更なら、構成を「変更の内容 / 適用日 / 影響を受ける方 / 必要な対応 / 問い合わせ先」に差し替えます。

媒体別の3種類は、事実の欄が同じかどうかを人が横に並べて確かめます。短い文面で時刻や範囲が削られたり、言い換えで意味が変わったりしていないかを見ます。

手順3: サポート向けの想定問答を作る

次に、同じ表から窓口の想定問答を作らせます。根拠資料を置いて想定問答を作る型は、Claudeで議会答弁案と想定問答を作る手順と共通です。障害時に多い問い合わせは、おおむね次のように分かれます。

上の表を材料に、サポート担当向けの想定問答を作ってください。
問い合わせの型ごとに、次の4点を出します。
- 想定される質問(顧客が実際に使いそうな言い方で2〜3パターン)
- 返答案(お知らせ文と矛盾しない表現)
- 根拠にした表の項目
- 担当者に回す条件(補償の個別判断、データ損失の訴え、法人契約の問い合わせなど)
「まだ言えない」項目への質問には、理由を説明せず、
次回更新の時刻だけを案内する返答案にしてください。

「根拠にした表の項目」の列は、窓口の担当者が返答の拠りどころを確かめるために付けます。この列が空の返答案は、表にない内容をClaudeが足した可能性があるため、使う前に差し戻します。

補償や返金の可否は、Claudeに判断させません。ナレッジに置いた対応方針の範囲を案内する文面までを任せ、方針にない約束が含まれていないかを人が見ます。

状況が変わったら、更新を足して作り直す

障害は、一度書いて終わりになりません。復旧の見込みが動いたり、原因が確定したりするたびに、表も告知文も想定問答も更新されます。

ここで押さえておきたいのは、プロジェクト内でもチャットをまたいで文脈は共有されないことです。共有されるのは、ナレッジに追加した情報だけです。第一報のチャットで固めた表は、第二報の新しいチャットからは見えません。

更新のたびに、次の流れで進めます。

「条件付き」だった項目が「言える」に変わる瞬間が、更新の中心です。たとえば「原因はデータベースの負荷と推定」が確定に変わったとき、告知文の「推定」を外し、想定問答の「調査中」の返答を差し替えます。差分の指示は、この書き換え漏れを拾うために使います。

公開前に人が確かめる6点

Claudeの出力は、そのままでは公開しません。確認の担当と観点を決めておきます。

• 時刻、範囲、件数が、技術者のメモと一字一句合っているか
• 「推定」「目安」を、メモの区分どおりに残しているか
• 「まだ言えない」に入れた項目が、文面や返答案に紛れ込んでいないか
• 補償・返金・SLAに触れる箇所が、対応方針と食い違っていないか
• 3つの媒体向けの文面と想定問答で、同じ事実の表現が揃っているか
• 次回更新の時刻と問い合わせ先が、実際に運用できる内容か

最後の項目は、文面として整っていても実態が伴わないことがあります。更新時刻を書いたなら、その時刻に担当者がいなければなりません。

サポートチームに共有する

Team・Enterpriseプランでは、プロジェクトを組織内で共有できます。管理者が共有をオフにしている場合は使えません。共有時の権限は2段階です。

• 閲覧のみ: ナレッジと指示を見て、プロジェクト内でチャットできる。編集はできない
• 編集可: 指示とナレッジを変更できる

表と指示の編集権限は、広報・法務・サービス責任者に限り、窓口の担当者は閲覧のみにする運用が考えられます。閲覧のみの担当者でもチャットは使えるため、想定問答を見ながら個別の問い合わせの返答案をその場で作れます。

無料プランでも、プロジェクトは最大5つまで作れます。有料プランでは、ナレッジが多くなるとRAGモードが自動で有効になり、容量が広がります。過去の告知文を大量に置く場合は、有料プランのほうが扱いやすくなります。

メモリーを使っているTeam・Enterpriseでは、プロジェクトごとに専用のメモリーが保たれます。障害対応のチャットを他の業務の記憶に混ぜたくないときは、プロジェクトの中で作業します。プロジェクトに入れ忘れたチャットは、後から「Add to project」で移せます。

まとめ

表を先に固め、告知文と想定問答をその表から導くことで、三者の食い違いを防げます。プロジェクトに置くのは、平時から使い回せる文体の見本と対応方針で、事案ごとの事実はチャットに貼ります。事実が動いたら、日付付きの表をナレッジに足し、差分だけを直します。