やさしいAI仕事術
1. 今日の相談
「システム更新で2時間止まります。利用者へ、何が使えないかと代替手順を案内したいです」
計画停止の案内は、対象システム、停止日時、影響する機能、事前準備、停止中の代替手順、再開確認、次の案内を承認済みの運用計画からそろえます。
2. 大丈夫です
ほー先輩：技術の説明を全部せんでも、いつ何ができんかと、次の行動が分かればええで。
終了予定は書けますが、確認前に「必ず復旧します」と保証する必要はありません。
3. 今日使うAI・道具
使うのはChatGPT、承認済みの保守計画、機能一覧、利用者一覧、代替手順、連絡網です。管理画面URL、内部構成、パスワード、APIキー、脆弱性情報はAIへ渡しません。
4. 実際にやってみる
1. 停止日時と対象を確認する
開始・終了予定、対象環境、対象機能、影響しない機能を運用計画で確認します。時間帯と曜日のずれにも注意します。
利用者の所在地が複数ある場合は、時刻表記とタイムゾーンを明示します。停止開始前にログイン済みの画面がどうなるか、入力途中の内容や予約済み処理が保存されるかも確認します。「停止中は開けない」だけでなく、開始時刻をまたぐ操作の扱いを案内できると、データの取りこぼしを減らせます。
2. 利用者の行動へ言い換える
ログイン、入力、閲覧、送信、予約など、何ができなくなるかを利用者の言葉で整理します。
3. AIへ案内文を頼む
以下は架空のシステム計画停止メモです。
「対象システム」「停止日時」「影響する機能」
「事前にしてほしいこと」「承認済みの代替手順」
「再開確認と次の案内」の順で、短い案内を作ってください。
メモにない停止理由、影響、復旧時刻、代替手順、安全性の評価を付け足さないでください。
未確定の項目は「調整中」または「要確認」と残してください。
【計画停止メモ】
（内部構成や認証情報を除いた内容）
4. 代替手順を人が確認する
紙、別システム、後日入力などの代替は、保存先、担当、後処理まで承認済みか確認します。AIが考えた代替策をそのまま採用しません。
代替手順では、受付番号の付け方、重複確認、保管場所、再開後に入力する担当と期限まで決めます。停止中の紙や表計算ファイルを本番へ戻したあと、二重登録や入力漏れを確かめる方法も必要です。個人情報を一時保管する場合は、通常時と同じアクセス範囲を守ります。
5. 再開後の確認を案内する
正式な稼働確認が終わるまで「復旧済み」と断定せず、確認方法と次の案内時期を伝えます。
5. 完成例
以下は架空の例です。
件名：7月20日 予約システム計画停止のお知らせ
7月20日18時から20時まで、更新作業のため予約システムを停止します。
停止中は、予約の新規登録・変更・閲覧ができません。
18時までに入力中の内容を保存してください。
停止中に受けた予約依頼は、承認済みの受付票へ記録し、再開確認後に担当者が入力します。
作業状況は20時15分までに改めてお知らせします。
復旧を保証せず、停止中の記録と次の案内時期を明確にしています。
場面別のお知らせ例（そのまま使えます）
[ ] の中を、作業計画書や依頼元の連絡から写してください。「何ができなくなるか」を、機能名ではなく利用者の言葉で書くのが要点です。
① 事前告知（社内向け）
件名：[日付] [システム名]計画停止のお知らせ
[日付][時刻]から[時刻]まで、[作業内容]のため[システム名]を停止します。
【できなくなること】
・[利用者から見た操作1]
・[利用者から見た操作2]
【停止前にお願いしたいこと】
・[時刻]までに入力中の内容を保存してください
・[印刷・書き出しが必要なものがあれば]
【停止中の運用】
・[代替手段。なければ「[再開後]にまとめて入力します」]
作業状況は[時刻]までに改めてお知らせします。
② 事前告知（お客様向け）
【[日付] [サービス名]一時停止のお知らせ】
いつもご利用いただき、ありがとうございます。
下記の時間帯、[サービス名]を一時停止いたします。
【停止日時】[日付][時刻]〜[時刻]（予定）
【ご利用いただけないもの】[予約／注文／お問い合わせフォーム など]
【ご利用いただけるもの】[電話受付など。なければ書かない]
ご不便をおかけしますが、よろしくお願いいたします。
③ 前日・直前のリマインド
件名：[本日／明日][時刻]から [システム名]を停止します
[日付][時刻]から[時刻]まで停止します。
[時刻]までに作業中の内容を保存してください。
④ 作業開始のお知らせ
[時刻]より[システム名]の停止作業を開始しました。
再開予定は[時刻]です。
次のご連絡は[時刻]頃を予定しています。
⑤ 予定より延びるとき
件名：[システム名]の再開時刻の変更について
[時刻]の再開を予定しておりましたが、[確認できている状況]のため、
再開が[時刻]頃となる見込みです。
・現在の状況：[確認できていることだけ]
・原因：確認中です
・次のご連絡：[時刻]
ご不便をおかけしております。
原因は書きません。確認前の原因説明は、後で訂正すると信頼を損ないます。書くのは「今どうなっているか」「次にいつ連絡するか」です。
⑥ 再開のお知らせ
[時刻]に[システム名]を再開しました。
【停止中に発生した分の扱い】
・[停止中の依頼をどうするか]
・[入力し直しが必要なものがあれば具体的に]
お気づきの点がありましたら[連絡先]までお知らせください。
再開の宣言は、動作を確認した人が出します。作業が終わったことと、使える状態であることは別です。
停止のお知らせに書かないほうがよいこと
- 機能名だけの説明（「認証基盤を停止します」）— 利用者は自分が何をできなくなるか分かりません
- 「ご迷惑をおかけしますが」だけで、何ができないか書かない— 一番知りたいことが抜けています
- 確定していない再開時刻を断定する— 「[時刻]予定」と書き、延びたら早めに続報を出します
- 未確認の原因— 「サーバーの不具合により」は、確認が済んでから書きます
- 停止中の依頼をどうするか書かない— 現場が判断できず、二重入力や取りこぼしが起きます
6. 使うときの注意
保守理由の詳細が、脆弱性や内部構成を明かす場合があります。共有範囲を情報管理責任者と確認し、利用者には必要な影響と行動だけを伝えます。
予定外の障害や安全上の問題へ変わった場合は、計画停止案内ではなく正式な障害報告・緊急連絡へ切り替えます。
案内は、事前通知、開始時の通知、再開確認後の通知の三つに分けると状態が伝わりやすくなります。終了予定時刻を過ぎた場合は、古い予定を残したままにせず「確認中」と次の更新時刻を出します。正式な稼働確認をした人と確認項目は、保守記録の側へ残します。
7. 今日できたこと
- 停止日時と影響する機能を分けられた。
- 承認済みの代替手順だけを案内できた。
- 復旧時刻をAIに保証させなかった。
- 再開確認と次の案内まで決められた。
予定外の障害が起きた場合は、事実・影響範囲・回避策から共有する方法へ切り替えられます。
8. ほー先輩の一言
ほー先輩：止まる案内のゴールは、読んだ人が「今どうするか」を選べることやで。