エラー原因をAIで切り分けるプロンプトテンプレート ログ・状況・仮説を整理して次の確認に進む
エラー対応でAIに頼むなら、「直して」ではなく、原因候補を分け、確認順を決めてもらう使い方が向いています。
この記事では、システム障害、業務ツールの不具合、データ処理の失敗、メール配信やフォーム送信のトラブルなどで使える、原因切り分け用のプロンプトテンプレートを紹介します。対象は、開発者だけでなく、社内システム担当、業務改善担当、Web担当者、カスタマーサポート担当者です。
最初に押さえる要点は次の3つです。
- AIには「結論」だけでなく「原因候補」「確認順」「追加で必要な情報」を出させる
- ログやエラーメッセージは、個人情報や秘密情報を伏せてから貼る
- AIの回答は確定診断ではなく、次に人が確認するための整理表として使う
ここがポイント: エラー調査のプロンプトは、答えを当ててもらうものではなく、調査の順番を崩さないためのメモ係として使うと安定します。
どんな場面で使うプロンプトか
このテンプレートは、エラーの発生状況が散らばっていて、何から確認すべきか分からないときに使います。
たとえば、次のような場面です。
- Webフォーム送信後にエラーが出る
- CSV取り込みで一部の行だけ失敗する
- 社内ツールで特定ユーザーだけ操作できない
- API連携でステータスコードやレスポンスが返ってくる
- メール配信、予約投稿、ファイルアップロードなどが途中で止まる
AIに期待する出力は、いきなりの修正案ではありません。まずは、情報を次のように整理してもらいます。
- 可能性が高い原因
- 確認すべき順番
- 追加で集めるべき情報
- 急ぎで避けるべき操作
- 担当者に渡す説明文
エラー調査では、思いついた箇所から手を付けると、確認済みの範囲が分からなくなります。AIには「どこから見るか」を表にしてもらうと、チーム内でも共有しやすくなります。
コピペ用：エラー原因切り分けプロンプト
まずは、幅広い業務トラブルで使える基本形です。ChatGPT、Claude、Gemini などの汎用LLMで使える書き方ですが、各サービスに入力できる文字数やファイル添付の扱いは執筆時点でもサービスごとに異なります。長いログを扱う場合は、利用中のサービスの仕様を確認してください。
あなたは、業務システムやWebサービスのエラー原因を切り分ける支援者です。
以下の情報をもとに、原因を断定せず、確認すべき順番を整理してください。
# 目的
{エラーの原因候補を整理し、次に確認する作業を決めたい}
# 発生している問題
{何が起きているかを1〜3文で書く}
# 発生した日時・頻度
{例: 2026年7月8日 10:15頃から / 毎回 / 特定条件だけ / 1回のみ}
# 影響範囲
{例: 全ユーザー / 特定部署 / 特定ブラウザ / 1件のCSVファイルだけ}
# 操作手順
1. {実行した操作}
2. {次に行った操作}
3. {エラーが出た操作}
# エラーメッセージ・ログ
```log
{個人情報・APIキー・パスワード・トークンを伏せたログやエラーメッセージ}
直前に変更したこと
{例: 設定変更、リリース、CSV形式変更、権限変更、ネットワーク変更、特になし}
すでに確認したこと
- {確認済みの内容}
- {試した対処}
出力形式
以下の形式で出力してください。 1. 現時点で考えられる原因候補を、可能性が高い順に5つまで 2. 各原因候補について、そう考える理由 3. 次に確認する作業を、上から順番にチェックリスト化 4. 追加で必要な情報 5. やってはいけない可能性がある操作 6. 担当者や開発者に共有するための短い説明文
注意
- 原因を断定しないでください
- ログに書かれていない事実を作らないでください
- 危険な操作やデータ削除を伴う対応は、必ず注意書きを付けてください
- 初心者にも分かる言葉で説明してください
このテンプレートの中心は、「原因を当ててください」ではなく「確認順を作ってください」と頼む点です。エラー原因は、ログだけでは決めきれないことが多くあります。だからこそ、AIには仮説と確認方法を分けて書かせます。
## 入力時に変える部分と固定する部分
テンプレート内の `{}` は、実際の状況に合わせて書き換える場所です。一方で、「原因を断定しない」「確認順を出す」「危険な操作に注意書きを付ける」といった条件は、できるだけ固定して使います。
### 変える部分
エラーごとに変えるべき項目は、次の通りです。
- `{発生している問題}`: 画面上で何が起きたかを短く書く
- `{発生した日時・頻度}`: いつから、毎回か、ときどきかを書く
- `{影響範囲}`: 誰に、どのデータに、どの環境で起きるかを書く
- `{操作手順}`: エラーが出るまでの操作を順番に書く
- `{エラーメッセージ・ログ}`: 秘密情報を伏せて貼る
- `{直前に変更したこと}`: 設定、権限、ファイル形式、リリースなどを書く
特に大事なのは、影響範囲です。「全員で起きる」のか「特定ユーザーだけで起きる」のかで、疑う場所が変わります。全員ならサービス側や設定変更、特定ユーザーだけなら権限、入力値、ブラウザ、アカウント状態などを先に見る流れになります。
### 固定した方がよい条件
次の条件は、毎回入れておくと出力が安定します。
- 原因を断定しない
- 可能性が高い順に並べる
- そう考える理由を書く
- 次の確認作業をチェックリストにする
- 追加で必要な情報を分けて出す
- 危険な操作には注意書きを付ける
AIは、強く聞かれると断定調の回答を返すことがあります。エラー対応では、その断定が危険です。まだ見ていないログ、設定、実行環境があるなら、回答は「確定」ではなく「確認の候補」に留める必要があります。
## NG例と改善例
エラー調査で失敗しやすいプロンプトは、情報が少ないまま答えだけを求める形です。
### NG例
```text
このエラーの原因を教えてください。
ログはこれです。
{ログ}
この聞き方では、AIはログに出ている単語からそれらしい原因を返しがちです。発生条件、直前の変更、影響範囲がないため、優先順位を付けにくくなります。
改善例
以下のエラーについて、原因を断定せずに切り分けを手伝ってください。
# 状況
{何をしたときに、どの画面・処理で、どんなエラーが出たか}
# 発生条件
- 発生する環境: {本番 / 検証 / ローカル / 不明}
- 発生するユーザー: {全員 / 一部 / 自分だけ / 不明}
- 再現性: {毎回 / ときどき / まだ未確認}
# ログ
```log
{秘密情報を伏せたログ}
直前の変更
{変更内容。なければ「確認できている範囲ではなし」と書く}
出力してほしいこと
- 原因候補を可能性が高い順に並べる
- それぞれの確認方法を書く
- 追加で必要な情報を書く
- すぐ実行すると危険な対応があれば注意する
変えた点は、原因そのものではなく、調査に必要な周辺情報を足したことです。これにより、AIは「設定変更の可能性が高い」「特定データだけなら入力形式を確認する」など、次の行動に落とし込みやすくなります。
## 業務カテゴリ別のテンプレート
ここからは、業務でよくある場面別に、少し短めのテンプレートを用意します。基本形を毎回使うのが重い場合は、近いものを選んで貼り付けてください。
### メール・通知が届かないとき
メール配信や通知の不具合では、「誰に届かないか」と「送信側・受信側のどちらを見るか」を分けることが重要です。
```text
メールまたは通知が届かない問題について、原因候補と確認順を整理してください。
# 問題
{例: 予約完了メールが一部のユーザーに届かない}
# 対象
- 届かない相手: {全員 / 特定ドメイン / 特定ユーザー / 不明}
- 届く相手: {分かっていれば書く}
- 送信タイミング: {即時 / 予約後 / バッチ処理後}
# 確認済み
- {迷惑メールフォルダ確認済み、など}
# エラーやログ
```log
{送信ログ、エラーコード、管理画面の表示など}
出力形式
原因候補、確認順、追加で必要な情報、利用者向けの案内文に分けて出してください。
期待できる出力は、送信設定、宛先、ドメイン、配信制限、テンプレート設定などの確認順です。利用者向けの案内文も一緒に出すと、問い合わせ対応に使いやすくなります。
### CSV取り込みで失敗するとき
CSVエラーでは、ファイル全体が悪いのか、一部の行や列だけが悪いのかを分けると進めやすくなります。
```text
CSV取り込みエラーの原因を切り分けたいです。
以下の情報から、確認すべき列・行・形式の候補を整理してください。
# 取り込み先
{例: 顧客管理システム、在庫管理ツール、WordPress投稿インポートなど}
# エラー内容
{画面に出たメッセージ}
# 失敗する範囲
{全行 / 一部の行 / 特定列を含む場合 / 不明}
# CSVの先頭数行
```csv
{個人情報を伏せたCSVサンプル}
仕様として分かっていること
- 文字コード: {UTF-8 / Shift_JIS / 不明}
- 区切り文字: {カンマ / タブ / 不明}
- 必須列: {分かっていれば書く}
出力形式
- 疑うべき原因候補
- 確認する列・行
- 修正前にバックアップすべき内容
- 再取り込み前のチェックリスト
CSVでは、文字コード、改行、カンマ、ダブルクォート、必須列、日付形式などが原因になります。AIには修正後のCSVを丸ごと作らせる前に、まず「どの列を疑うか」を出してもらうと安全です。
### 会議や問い合わせ内容から原因を整理するとき
現場からの聞き取り内容が長い場合は、まず事実、推測、未確認を分けます。
```text
以下の問い合わせ内容から、エラー原因の切り分けに必要な情報を整理してください。
# 問い合わせ本文
{問い合わせメールやチャット内容を貼る。個人名や社外秘は伏せる}
# 出力形式
- 事実として書かれていること
- 推測または感想と思われること
- まだ確認できていないこと
- 追加で質問すべきこと
- 担当者に渡す調査依頼文
# 注意
本文にない事実は補わないでください。
このテンプレートは、技術的なログがない段階で使えます。問い合わせ本文には「急に使えなくなった」「昨日から変」などの表現が混ざります。AIに分類させると、追加質問が作りやすくなります。
開発・API連携のエラーを調べるとき
API連携では、リクエスト、レスポンス、認証、権限、入力値を分けて見る必要があります。
API連携エラーの原因候補を切り分けてください。
# やりたい処理
{例: 注文情報を外部サービスへ送信する}
# 発生しているエラー
- ステータスコード: {例: 400, 401, 403, 404, 500, 不明}
- エラーメッセージ: {表示された内容}
# リクエスト概要
- メソッド: {GET / POST / PUT / DELETE / 不明}
- エンドポイント: {URL。ただし秘密情報を含むクエリは伏せる}
- 送信データの概要: {個人情報を伏せて書く}
# レスポンス
```json
{秘密情報を伏せたレスポンス例}
直前の変更
{APIキー変更、権限変更、仕様変更、コード変更など}
出力形式
原因候補を「認証・権限」「入力値」「接続先」「仕様変更」「一時的な障害」に分けて整理し、次の確認順を出してください。
APIのエラーは、同じステータスコードでも原因が複数あります。401なら認証、403なら権限、400なら入力値という見方は出発点になりますが、実際にはサービスごとの仕様確認が必要です。AIの回答だけで判断せず、最終的には利用しているAPIの公式ドキュメントや管理画面のログを見ます。
### 法務・契約まわりの業務エラーを整理するとき
契約書作成ツール、電子署名、申請ワークフローなどのエラーでは、AIに法的判断をさせず、操作・権限・入力項目の整理に限定します。
```text
契約・申請業務で発生したツール上のエラーについて、原因切り分けの観点を整理してください。
法的判断ではなく、操作・権限・入力情報・承認経路の確認に限定してください。
# 起きている問題
{例: 承認依頼を送信できない、電子署名依頼が相手に届かない}
# 関係者
{申請者、承認者、取引先など。個人名は役割名に置き換える}
# 操作手順
{エラーが出るまでの手順}
# エラー表示
{画面の文言やログ}
# 出力形式
- 操作ミスの可能性
- 権限・承認経路の可能性
- 入力不足の可能性
- システム側の可能性
- 担当部署に確認すべき質問
# 注意
法律上の結論は出さず、システム操作上の確認項目として整理してください。
この使い方では、AIに契約内容の有効性を判断させません。扱うのは、申請経路、権限、入力漏れ、通知設定などの業務プロセスです。
出力を安定させるコツ
エラー切り分けの回答を安定させるには、AIに「何を出すか」だけでなく「何をしないか」も指定します。
1. 原因候補と確認作業を分ける
原因候補だけを並べると、次の作業に移りにくくなります。必ず、候補ごとに確認方法を書かせます。
各原因候補について、次の3点を必ず分けてください。
- そう考える理由
- 確認する方法
- 確認結果によって次に進む判断
これにより、「設定ミスの可能性があります」で止まらず、「管理画面のどの設定を確認するか」まで出しやすくなります。
2. 未確認情報を明示させる
ログが少ないときほど、AIは推測を補いやすくなります。そこで、分からないことは分からないと書かせます。
情報不足で判断できない点は、推測で埋めずに「追加で必要な情報」として列挙してください。
この一文を入れるだけで、回答の使い方が変わります。AIの推測を読むのではなく、次に集めるログや確認事項のリストとして使えるからです。
3. 危険な操作を先に止める
エラー対応では、焦ってデータ削除、設定初期化、再送信、再取り込みを行うと状況が悪化することがあります。
データ削除、設定初期化、一括再送信、再取り込み、権限変更など、影響が大きい操作が含まれる場合は、実行前の注意点を先に書いてください。
特に本番環境では、この指定を入れておくと安心です。AIの提案は作業指示書ではなく、確認メモとして扱います。
4. 出力形式を固定する
毎回同じ形式で受け取りたい場合は、Markdownの表よりも、スマホで読みやすい箇条書き形式が扱いやすいです。
出力は以下の見出しで固定してください。
## 可能性が高い原因
## まず確認すること
## 追加で必要な情報
## すぐに実行しない方がよい操作
## 共有用メモ
表は比較には便利ですが、ログや説明文が長いと崩れやすくなります。スマホで読む想定なら、短い見出しと箇条書きの方が確認しやすい場面も多くあります。
活用例：問い合わせから開発者への共有文を作る
原因切り分けのプロンプトは、自分で調べるだけでなく、担当者へ渡す情報を整える用途にも使えます。
たとえば、問い合わせ担当者が次の情報を持っているとします。
- ユーザーから「CSVが取り込めない」と連絡が来た
- 失敗するのは特定のファイルだけ
- 画面には「日付形式が不正です」と出ている
- 先週までは同じ手順で取り込めていた
この場合、AIには次のように頼めます。
以下の情報を、開発者またはシステム担当者に共有しやすい形に整理してください。
原因の断定はせず、確認してほしい点を明確にしてください。
# 現在分かっていること
- {ユーザーからの報告}
- {画面に出ているエラー}
- {発生範囲}
- {直前の変更や気づいたこと}
# 出力形式
- 件名
- 概要
- 再現手順
- 期待する結果
- 実際の結果
- 確認してほしい点
- 添付すべき情報
この使い方なら、AIの役割は「原因を当てること」ではありません。担当者が調査を始めやすいように、情報の抜けを減らすことです。
使う前のチェックリスト
最後に、実際にプロンプトを送る前の確認項目です。エラー対応では、入力する情報の質がそのまま回答の質に影響します。
- 個人情報、APIキー、パスワード、トークンを伏せたか
- エラーが出るまでの操作手順を書いたか
- 発生日時と頻度を書いたか
- 影響範囲を書いたか
- 直前に変更したことを書いたか
- すでに試した対応を書いたか
- AIに原因を断定させない指示を入れたか
- 危険な操作への注意書きを求めたか
- 最終確認は人が行う前提にしているか
エラー調査で次に見るべき分岐点は、再現性です。毎回起きるなら設定や入力値を優先して確認し、ときどき起きるなら時間帯、負荷、外部サービス、特定データの違いを見ます。AIには、その分岐を整理させる。そこまでできれば、調査は「なんとなく探す」状態から一歩進みます。