「担当者しか直せない」「手順書はあるが、どこで止めればよいか分からない」。こうした状態では、同じトラブルが起きるたびに調査をやり直します。
ChatGPTは、過去の対応記録を読みやすい順番へ並べ、質問形式の手順書へ整える作業に向いています。ただし、原因や安全性をAIに推測させてはいけません。確認済みの事実は人が用意し、ChatGPTは再現できる手順へ整えるという役割分担が基本です。
この記事では、症状、対象、確認順、判断分岐、停止条件、エスカレーションを含むトラブルシューティング手順書を5ステップで作る方法を解説します。
トラブルシューティング手順書は「調査の順番」を共有する文書
トラブルシューティング手順書は、単なる解決策の一覧ではありません。症状から必要な確認へ進み、結果に応じて次の行動を選ぶための案内です。
| 文書 | 主な目的 | 向いている内容 |
|---|---|---|
| FAQ | よくある質問へ短く答える | 単純な疑問と回答 |
| 操作マニュアル | 正常時の操作を説明する | 始めから終わりまでの標準手順 |
| トラブルシューティング手順書 | 異常時の切り分けを助ける | 症状、確認、分岐、停止条件 |
| 障害報告 | 発生した事実を記録する | 影響、時系列、原因、再発防止 |
エラーの原因をその場で調べたい場合は、ChatGPTでエラー原因を調べる方法を参照してください。本記事は、確認済みの調査方法を次回も使える文書へする工程に絞ります。
作成前に集める「症状カード」
ChatGPTへ渡す前に、担当者が確認した情報を1枚にまとめます。
| 項目 | 記録する内容 |
|---|---|
| 症状 | 何が、どの画面で、どうなったか |
| 期待する状態 | 本来どう動くはずか |
| 対象 | 端末、OS、ブラウザー、プラン、権限 |
| 発生条件 | 毎回か、特定操作だけか |
| 直前の変更 | 更新、設定変更、データ投入など |
| 確認済み | 再現結果、ログ、スクリーンショット |
| 禁止事項 | 実行してはいけない操作 |
| 担当者 | 解決できない時の連絡先と必要情報 |
パスワード、APIキー、個人情報、顧客データは貼り付けません。ログを使う場合も、必要な行だけを匿名化します。
ChatGPTで手順書を作る5ステップ
1. 読者と対象範囲を決める
新人、一次窓口、開発担当者では、使える権限と知識が違います。「誰が」「どの環境で」「どこまで実行してよいか」を先に決めます。
対象外も明記します。たとえば「本番データの削除はこの手順の対象外」「管理者権限が必要なら停止」と書けば、危険な自己判断を減らせます。
2. 症状と期待する状態を分ける
「ログインできない」だけでは広すぎます。表示された文言、発生した画面、直前の操作、再現性を記録します。期待する状態も書くと、何をもって解決とするかが明確になります。
推測した原因は事実欄へ混ぜません。「確認済み」「可能性」「未確認」を分けます。
3. 安全で簡単な確認から並べる
最初は、画面の再読み込み、対象URL、入力値、通信状態など、影響が小さく元に戻せる確認から始めます。設定変更、データ更新、再インストールなどは後に回します。
各手順には次の4点を入れます。
- 確認すること
- 期待する結果
- 結果ごとの次の行動
- 中止して担当者へ渡す条件
4. ChatGPTで判断分岐を下書きする
症状カードと確認済みの手順を渡し、番号付きの流れに整えます。「成功なら次へ」「失敗なら別の確認へ」「危険条件なら停止」の3方向を基本にします。
ChatGPTが入力にない原因やコマンドを追加した場合は削除します。コードや設定変更を含む時は、ChatGPTでコードレビューする方法で確認観点を補えます。
5. 別の人が試し、更新責任を決める
作成者以外の人が、手順書だけを見て試します。迷った箇所、前提不足、古い画面名を記録し、修正します。
最後に所有者、最終確認日、対象バージョン、次回確認日を入れます。仕様変更時は、ChatGPTでリリースノートを作る方法と同時に更新すると古さを防げます。
そのまま使えるプロンプト
あなたは技術文書の編集担当者です。
以下の確認済み情報だけを使い、初心者向けのトラブルシューティング手順書を作成してください。
構成：
1. 対象読者と対象範囲
2. 症状と期待する状態
3. 事前確認
4. 番号付きの確認手順
5. 結果ごとの次の行動
6. 停止条件とエスカレーション
7. 解決確認
ルール：
- 入力にない原因、仕様、コマンドを推測しない
- 「確認済み」「可能性」「未確認」を分ける
- 影響が小さく元に戻せる確認から並べる
- 各手順に、期待する結果と次の行動を書く
- 権限不足、データ削除、課金、セキュリティ上の懸念がある場合は停止させる
- 不明点は「要確認」と表示する
確認済み情報：
（ここに匿名化した症状カードと過去の対応記録を貼り付ける）
プロジェクト全体の前提を説明する文書が必要なら、ChatGPTでREADMEを作る方法も併用してください。
判断分岐と停止条件の書き方
| 結果 | 次の行動の例 |
|---|---|
| 期待どおり | 解決確認へ進む |
| 同じ症状 | 次の安全な確認へ進む |
| 別のエラー | 新しい症状として記録し、手順を中止する |
| 権限がない | 管理者へ対象・時刻・結果を渡す |
| データ消失の恐れ | 操作せず、バックアップと担当者を確認する |
停止条件は目立つ位置に置きます。「分からなければ続ける」ではなく、「この条件なら止める」を明文化することが重要です。
失敗しやすい点と直し方
解決策から書き始める
症状が違うのに同じ操作を実行する危険があります。最初に対象、症状、期待する状態を確認します。
ChatGPTに原因を断定させる
自然な文章でも正しいとは限りません。原因候補と確認済みの原因を分け、ログや再現結果で確定します。
分岐が「うまくいかなければ次へ」だけ
何を確認して次へ進むのか分かりません。期待結果、失敗結果、停止条件を具体的にします。
危険な操作に注意書きがない
削除、初期化、権限変更、課金を伴う操作は通常手順から外し、担当者確認へ送ります。
作って終わりにする
画面名や担当者が古くなると、緊急時に使えません。所有者と確認日を記録し、障害対応後に更新します。
公開前の確認リスト
- 対象読者と必要な権限が明確
- 症状と期待する状態を分けた
- 確認済み事実と推測を分けた
- 安全で元に戻せる確認から並べた
- 各手順に期待結果と次の行動がある
- 停止条件とエスカレーション先がある
- 秘密情報・個人情報を除いた
- 作成者以外が試した
- 所有者と最終確認日を記録した
まとめ
ChatGPTは、過去の対応記録を、初心者が追える順番と判断分岐へ整える作業に役立ちます。しかし、原因、安全性、実行権限を決める役割は人に残します。
症状カードを作り、安全な確認から並べ、各手順を「確認・結果・次の行動・停止条件」で書き、別の人が試す。この流れを守れば、担当者の記憶ではなく、チームで再利用できるトラブルシューティング手順書になります。
コメント