AIツールのエラーログ共有テンプレート｜再現条件と変更履歴の残し方

「AIが動きません」だけでは、次の担当者は最初から聞き直すことになります。一方で、画面やログを丸ごと送ると、APIキーや顧客情報まで含めてしまうことがあります。必要なのは、大量のログではなく、同じ条件で問題を確かめられる記録です。

ここではAiWiLLの記事制作・運用で重視している「入力・出力・確認する人を分ける」考え方を、障害の引き継ぎへ当てはめた記入例を示します。実在の顧客の障害や、実測した復旧時間を紹介するものではありません。

最初の連絡でそろえる六つの項目

1. 何の業務が止まっているか。納期や影響する範囲も記載します。
2. いつ、どこから実行したか。日時にはタイムゾーンを付けます。
3. 本来何が出るはずだったか。期待結果を一文で書きます。
4. 実際にはどうなったか。エラー番号と伏せ字にしたメッセージを残します。
5. 最後に成功してから変えたものは何か。不明なら不明と記載します。
6. 同じ入力で再現するか。未確認なら推測で埋めません。

そのまま使える障害メモ

【業務】
対象の処理：
影響範囲／期限：
一時的な代替手段：

【観測した事実】
発生日時とタイムゾーン：
実行場所（PC・エディター・定時処理など）：
ツール／バージョン／モデル：
期待した結果：
実際の結果：
エラー番号と共有用メッセージ：
最後に成功した日時：

【再現】
入力データの説明（秘密情報は含めない）：
操作1：
操作2：
再現した回数／試した回数：
最小サンプルでも再現するか：

【変更と判断】
直前の変更：
試した対処とその結果：
原因の仮説（事実と分ける）：
まだ試していないこと：
次の確認担当と期限：

「観測」と「原因の仮説」を混ぜない

たとえば、説明用の架空ケースとして「9月5日9時10分JST、Windowsの定時処理で報告書が生成されなかった。手動実行では生成された」と記録します。ここまでは観測です。「定時処理の認証が切れたのだろう」は仮説で、別欄へ書きます。

手動実行と定時処理で違うのは、アカウントだけとは限りません。作業フォルダー、環境変数、入力ファイルの状態も候補です。一つの仮説を確定したように書くと、次の担当者が他の可能性を見落とします。「認証は未確認」と書ける記録のほうが、調査を続けやすくなります。

ログを共有する前の伏せ方

エラー文に含まれるキー、トークン、メールアドレス、顧客名、ファイルの内容を確認します。認証ヘッダーは値を切り詰めるだけでなく、共有用コピーから値全体を外します。原本が調査に必要な場合は、アクセス範囲を管理できる保管先へ置き、一般のチャットに貼りません。

情報	共有メモでの扱い
HTTP 401、処理名、発生時刻	調査に必要な事実として記載
顧客の報告書本文	内容を再現できる架空サンプルに置き換える
認証情報を含むURL	クエリや署名を外し、必要なパスだけ示す
APIのリクエストID	共有先のサポート方針に従い限定して渡す

復旧したら、何をもって完了とするか

エラーが消えただけでは、業務に必要な出力が戻ったとは限りません。生成物を開けるか、件数が合うか、担当者が内容を確認できるかまで確かめます。定時処理の問題なら、通常の実行経路で再確認してください。

完了欄には「変更した設定」「確認した入力」「確認結果」「残る制約」を追記します。その後、同じ問題で最初に見る手順だけを運用マニュアルへ反映します。個別障害の長い会話をすべてマニュアルへ移す必要はありません。

AIに同じ指摘を繰り返す問題も、観測と指示を記録に残すことから整理できます。業務ごとの復旧担当や確認基準を決めたい場合は、AIの運用体制についてご相談ください。

参照した資料

• xAI：エラーの確認