AIにエラー原因を調べてもらうときは、エラー文だけでなく「どの操作で起きたか」「動作環境」「直前の変更」を一緒に渡します。AIの最初の回答は結論ではなく仮説です。再現条件とログをそろえ、仮説ごとの確認方法を決めてから、一つずつ切り分けてください。ログに認証情報や個人情報が含まれる場合は、共有前に伏せます。
目次
先に作るのは原因説明ではなく調査用の入力
ログは長いほどよいわけではありません。障害の直前から直後まで、問題を説明する範囲を残し、関係のない大量の出力を外します。最初の例外だけでなく、直前に出たwarning、HTTP status、request ID、時刻、処理対象の識別子（公開可能な範囲）を含めます。複数のエラーが並ぶ場合は、最初に発生したものと後続の派生エラーを分けます。画面に表示された文言だけでは、通信失敗なのかアプリケーション例外なのか分からないことがあります。
環境情報は再現に必要な範囲で具体的にします。OS、runtimeとversion、framework、主要package、browser、実行コマンド、localか本番か、発生時刻とtimezoneを書きます。「最新版」「いつもの環境」ではなく、lockfileや実行環境で確認できるversionを記録してください。個人PCとCIでだけ違う場合は、その差が原因候補になります。環境を特定できないなら不明と明記し、AIに埋めさせないでください。
再現条件を小さく固定する
「操作したら落ちる」では調査できません。初期状態、操作、入力、期待結果、実際の結果を順番に並べます。毎回起きるか、特定データだけか、権限やネットワークに依存するかも分けて記録します。可能であれば、失敗する最小の入力と成功する対照入力を一組用意します。個人データや本番データを含む再現例は、そのまま共有せず、構造を保った合成データへ置き換えます。
たとえば「保存ボタンを押すと失敗」ではなく、「ログイン済みの検証環境で、空の任意項目を含むフォームを送信すると、画面は保存中のままになり、NetworkではPOSTが422。必須項目を入れると保存できる」のように書きます。この例なら、UIのpending解除、validation、API responseのどこを調べるべきかを区別できます。実際の案件では、確認していないstatusや結果を例から転記しないでください。
AIに渡すログの整え方
Node.jsのErrorはmessageとstackを持ち、stackは通常エラー生成箇所と呼び出し経路の手掛かりです。ただしstackの表現やsource mapの有無はruntimeやbuild構成に依存します。AIにはstack全体と、該当する最初のアプリケーション側frameを渡し、ライブラリ内部の全行を無条件に貼る必要があるか判断させます。Node.js公式資料もErrorの性質を説明していますが、stackだけで根本原因が確定するわけではありません。
ログを共有する前に、Authorization header、Cookie、session ID、API key、access token、メールアドレス、電話番号、顧客ID、URL queryの個人情報を検索します。単純に文字列を置換すると、同じ値が別の意味で使われる場合があるため、値を一貫した仮名（USER_A、TOKEN_REDACTED）へ置き換えて文脈は保ちます。秘密の値をAIに見せずに、発生順序と項目名を残すのが目的です。公開前に、共有先の保存・学習・アクセス条件も所属組織の規定に従ってください。
仮説を検証可能な形で出させる
「原因は何？」と一問だけにすると、AIはもっともらしい説明を断定しがちです。次の表で、複数候補と確認手順を分けます。
表は横にスクロールできます
| 仮説 | ログ上の根拠 | 反証・確認方法 | 次の安全な操作 |
|---|---|---|---|
| 入力validationで停止 | responseがvalidation error | 同じ条件で必須値だけ変え再送 | 検証環境で一項目ずつ確認 |
| 外部依存がtimeout | 接続待ち後にtimeout | 同時刻の依存先statusとrequest IDを照合 | retry回数と影響を確認 |
| 直前変更の回帰 | 特定commit以降のみ発生 | 変更差分と再現テストを比較 | rollback可能性を先に確認 |
この表は原因を三択に限定するものではありません。証拠のない候補は「不足情報」として残し、確度や確認順を言語化させます。AIに修正案を求める際は、変更箇所、想定する副作用、追加するtest、戻し方も併記させてください。広い変更を提案されたら、最小の変更で仮説を検証できるか問い直します。
一度に一つの変更を試す
調査中に複数の設定やコードを同時に変えると、どの変更が効いたか判別しにくくなります。変更前の状態、試した操作、結果を短く記録し、一つずつ比較します。再起動やcache削除など元に戻せる操作でも、影響範囲を確認してから行います。本番環境では、利用者への影響、監視、承認、rollback手順を先に確認し、AIの提案をそのまま実行しません。
修正後は、元の再現手順をそのまま実施し、期待結果だけでなく関連する正常系も確認します。例外が消えてもデータが保存されていない、別の画面が壊れた、ログが出なくなっただけということがあります。testがない場合は、再現手順を最小の回帰testにできるかを検討します。原因が再現しないなら「解決」とせず、観測できた範囲と残る不確実性を分けます。
調査を続けるか、担当者へ渡すか
個人情報漏えい、権限昇格、データ破損、広範な停止の可能性がある場合は、AIとの試行錯誤を続けず、組織のインシデント窓口へ引き継ぎます。ログを外部AIへ送れるか不明な場合も、機密データを伏せるだけで足りるとは限りません。サービスの契約・社内ポリシーを確認し、必要なら匿名化済みの最小再現例だけを使います。
AIに原因を決めてもらうのではなく、確認可能な仮説と次の観測を整理させるのが安全です。診断結果には、根拠となったログ行、未確認の前提、再現条件、実施した検証を残します。これで別の担当者も同じ情報から追試できます。
AIものさしの判断
エラー解析で価値があるのは、断定的な原因名より、再現条件・根拠・反証手順の対応が取れていることです。まず秘密を除いた最小ログを作り、環境と直前変更を添えます。次に仮説を一つずつ検証し、修正後は同じ手順と関連する正常系を再確認します。情報が足りなければ、答えを作らせず「次に観測すべきこと」を出させてください。
そのまま使える調査依頼の枠
依頼文は、AIが不足情報を事実のように補わない形にします。以下の項目を分け、確認できない欄は「不明」とします。
-
目的：原因候補を切り分けたい。修正はまだ実行しない
-
発生時刻：timezone込み。複数回なら各時刻
-
環境：OS、runtime、framework、依存packageのversion
-
再現：初期状態からの操作を番号付きで記載
-
期待 / 実際：どうなる想定か、実際に何が起きたか
-
証拠：error全文、関係するstack、request ID、前後のlog
-
直前変更：commit、設定、依存更新など。分からなければ不明
-
制約：本番変更不可、機密を送れない、再起動不可など
-
欲しい出力：仮説、根拠、反証方法、追加で必要な情報
最後に「原因を断定せず、ログにない事実を補わない。仮説ごとに確認操作と、確認後に期待する観測を示す」と添えます。これにより、診断と変更の境界が明確になります。修正案が必要になった段階で、別の依頼として変更範囲とテスト計画を求めます。調査だけでよいときに、コード変更までまとめて依頼しないでください。
原因が分からないときの止め方
何度試しても再現しない場合、観測できた環境と観測できなかった条件を記録します。発生率、影響を受ける利用者、回避策、直前のdeployとの時間関係が分かると、次の観測を優先できます。AIが似たerror messageを根拠に別の案件の解決策を提案しても、versionやstackが異なるなら適用を保留します。
権限、データ消失、課金、顧客情報、セキュリティ事故が疑われるときは、自己判断で本番設定を変えず、担当者の承認と既定のincident responseへ進みます。AIへの入力に含めてはいけない情報の範囲が曖昧なら、社内のdata handling policyを確認します。ログを匿名化しても、時刻・route・IDの組合せで個人が特定できる場合があるため、必要最小限へ削ります。
切り分け結果を記録する
調査メモには、仮説の状態を「未確認」「支持」「反証」「保留」で記録します。支持とした理由は、再現したtestや観測値に結びつけます。AIが提示した候補でも、証拠が得られなければ未確認のままです。別の担当者へ引き継ぐ場合は、すでに試したこと、変えたもの、元に戻したものを分け、同じ操作の繰り返しや二重変更を防ぎます。
たとえば外部サービスのtimeoutが一度起きただけなら、恒久的な依存先障害とは結論できません。時刻、request ID、再試行の結果、依存先statusを突き合わせ、再発率や影響範囲を確認します。根拠が足りない状態でretryを増やすと、負荷や二重処理を招く場合もあります。安全な観測と復旧のどちらを優先するか、障害の影響に応じて担当者が決めます。