社内システムの障害を、事実・影響範囲・回避策から共有する

1. 今日の相談

「社内システムへ入れません。原因は分かりませんが、問い合わせが増えています」

障害共有は、発生時刻、確認できた症状、影響範囲、試したこと、公式の回避策、問い合わせ先、次の更新時刻を分けます。原因や復旧時刻をAIに推測させません。

2. 大丈夫です

ほー先輩：原因が未確認でも、いま起きてることと次の連絡は出せるで。

緊急性や安全への影響がある場合は、AIより先に職場の障害・事故対応手順へ連絡します。

3. 今日使うAI・道具

使うのはChatGPT、監視画面、公式ステータス、問い合わせ記録、障害対応手順です。AIは実際の障害・内部構成を含まない空の共有様式を作る用途に限り、システム名、時刻、症状、影響範囲、ログ、内部URL、認証情報、顧客データはAIへ渡しません。

4. 実際にやってみる

1. 安全と正式報告を先にする

業務停止、決済、個人情報、安全設備へ影響する場合は、正式な緊急連絡先と管理者へ報告します。

2. 確認できた症状をそろえる

発生時刻、画面、対象機能、再現条件、影響を受けた範囲を確認します。推測した原因と分けます。

「全員が使えない」と広げず、確認できた利用者、拠点、端末、機能だけを記録します。反対に、影響しないと確認できた機能も分けておくと、止めなくてよい業務が見えます。問い合わせ件数は障害範囲そのものではないため、監視情報や正式な確認結果と混ぜません。

3. AIへ空の共有様式を頼む

実際の障害・内部情報を入力せずに使える、社内システム障害共有の空の様式を作ってください。
項目は「発生時刻」「確認できた症状」「影響範囲」「試したこと」「公式に確認できた回避策」「問い合わせ先」「次の更新時刻」とします。
原因、責任、復旧時刻、安全性、回避策を推測せず、未確認事項を「確認中」と残せる形にしてください。

できた空の様式を正式な障害連絡画面へ移し、監視情報と管理者が確認した記録から人が記入します。実際の障害情報をAI画面へ戻しません。

4. 回避策を公式情報と照らす

AIが提案した一般的な操作をそのまま配らず、管理者または提供元が確認した手順だけを案内します。

回避策には、対象者、使える期間、保存先、後で戻す作業、問い合わせ先を添えます。再読み込みや再ログインを何度も促すと負荷や重複処理を増やす場合があります。決済・送信・予約の再実行は、処理済みかを正式画面で確認してから行います。

5. 復旧後も記録を閉じる

復旧時刻、確認者、残った影響、再発時の窓口を正式な障害記録へ残します。

5. 完成例

以下は架空の例です。

発生：7月16日 9:10ごろ
症状：ログイン後に画面が読み込まれない
影響：受注一覧の閲覧ができない
回避策：確認中。再ログインの連打はしない
窓口：社内ヘルプデスク
次の更新：10:00

原因と復旧見込みを作らず、次に情報を出す時刻を示しています。

6. 使うときの注意

障害対応は、原因調査、権限変更、再起動、データ復旧など不可逆または高リスクの操作を含みます。正式な管理者が手順に沿って実行します。

エラー画面やログには個人情報、トークン、内部URLが含まれることがあります。内容を隠したつもりでも実際の障害を推測できるため、外部AIへ貼らず正式な障害対応経路で扱ってください。

共有文は一度で完成させず、初報、経過、復旧確認に分けます。各連絡に「確認できた時刻」と「次の更新時刻」を付け、古い初報だけが残らないよう同じ掲示場所を更新します。復旧後は主要な操作を人が確認し、残っている影響と問い合わせ先を示してから閉じます。

7. 今日できたこと

• 安全確保と正式報告を先にできた。
• 症状と推測を分けられた。
• 公式に確認した回避策だけを残せた。
• 次の更新時刻と復旧後の記録を置けた。

個人のパソコンに出たエラーを安全に相談したい場合は、画面の情報を隠してAIに聞く方法も確認できます。

8. ほー先輩の一言

ほー先輩：障害の時は、断定より「確認中」と次の連絡が役に立つで。