テスト・品質作成2026-08-16 01:02約13分

AIに障害の再現手順を整理させる｜報告と切り分けを速く

「動きません」。

チャットにその一行だけが届いた朝のことを、たぶん思い出せると思います。誰の環境で、いつから、何をしたときに、何が起きたのか。何も書いていない。それでも急ぎだと言われる。聞き返して、返事を待って、また聞き返して——気がつくと午前が終わっていて、まだ再現すらできていない。

こういう日に「AIを使えば早いのでは」と言われると、少し困りますよね。AIはあなたの本番ログを見られないし、利用者の画面も知りません。原因を当てさせようとしても、それらしい推測が返ってくるだけです。

ただ、AIがかなり役に立つ場所が、原因究明のもう一歩手前にあります。それが「再現手順を整える」ところです。この記事では、そこだけを切り出して整理します。

結論：AIに障害対応を手伝わせるなら、順番は3つです。①最初に聞くのは「原因は何か」ではなく「この報告に足りない情報は何か」。AIは質問を作るのが得意で、しかも遠慮しません。②集めた情報を、環境・操作・発生状況・結果の形に整える。ばらばらの文章のままでは、誰も同じ手順をたどれません。③再現できたら、手順を最小まで削らせる。短い再現手順は、そのまま調査の地図になります。

覚え方は 集める → 整える → 削る。原因の推測をAIにさせるのは、いちばん最後で構いません。

今日ぜんぶやる必要はありません。①の「足りない情報を出させる」だけでも、次の聞き返しが一往復で済むようになります。

何が起きているのか——再現手順が集まらないのは、誰のせいでもない

散らばった紙片を集める場面、枠のある紙に書き写す場面、並んだカードを減らす場面を並べた図 — 再現手順は「集める・整える・削る」の順で作る。原因の推測はいちばん最後でいい

報告が短いのは、報告する人の意識が低いからではありません。理由は3つあります。

1つ目は、異常は書けても前提は書けないこと。困っている人が気づいているのは「いつもと違う」という結果だけです。使っているブラウザの種類、ログインしていたアカウント、直前に押した順番——そういう前提は、本人にとっては空気のようなもので、書くべき情報だと思われていません。これは知識の差ではなく、立っている場所の差です。

2つ目は、情報が時間とともに消えること。ログは古いものから消えていきます。おかしくなったデータは、気を利かせた誰かが直してしまうことがあります。「さっきは出たのに、今は出ない」も普通に起きます。再現手順は、鮮度が落ちる材料でできています。だから、聞き返しの往復が長いほど不利になります。

3つ目は、切り分けの順番が人によって違うこと。ある人はまずログを見て、ある人はまず環境を疑い、ある人はまず利用者の操作を追います。どれも正しいのですが、順番が違うと、同じ情報を二度集めたり、誰も見ていない領域が残ったりします。焦っている時ほど、順番は崩れます。

ここでAIが効きます。AIは、あなたの現場のログにはアクセスできませんが、「この不具合を再現するには何を知る必要があるか」という質問のリストを作るのは得意です。しかも、聞きにくいことを聞くのに気を使いません。人間同士だと「そんな基本的なことを聞いたら失礼かな」と飲み込んでしまう質問を、平気で並べてくれます。

具体例——足りていないのは、たいていこの6つ

実際の報告で抜けやすいのは、次のあたりです。心当たりがあれば、この記事の手順はそのまま使えます。

環境：どの端末、どのブラウザやアプリの版、社内ネットワークか外からか、本番か検証か。「私のPCでは再現しない」の大半はここで説明がつきます。
アカウントと権限：どの利用者で起きたか。管理者では起きず、一般権限でだけ起きる、という形はよくあります。
操作の順番：「保存できない」だけでは足りず、どの画面から入って、何を入れて、どのボタンを押したかまで要ります。途中で戻ったか、二重に押したかも効きます。
発生した時刻と頻度：ログを探す入口になります。毎回なのか、たまになのか。「たまに」なら、原因の候補ががらりと変わります（たまに落ちるテスト（Flaky）の原因をAIに切り分けさせる手順と同じ扱い方が使えます）。
実際の結果と、期待していた結果：「エラーが出た」ではなく、画面に何と出たか。そして本人は何が起きると思っていたか。この2つが揃って初めて「不具合」と言えます。仕様どおりの動きだった、という結末も珍しくありません。
直前に変わったこと：リリース、設定変更、データの取り込み、他システムのメンテナンス。時間の近さは、それだけで有力な手がかりです。

逆に、報告に混ざっていても鵜呑みにしないほうがいいものもあります。報告者による原因の推測です。「たぶんサーバーが重いんだと思います」という一文は親切心から来ていますが、そこに引きずられると、確認の範囲が最初から狭まります。事実（見えたもの）と推測（思ったこと）は、受け取った時点で分けておくと安全です。

影響——遅れるのは調査ではなく、その前の待ち時間

再現できない時間は、外からは「調査中」に見えます。でも中身は、たいてい待ち時間です。

往復のたびに半日が溶ける：聞き返し1回につき、相手の返信を待つ時間が乗ります。3回聞き返せば、丸一日は簡単に過ぎます。手を動かしていないのに疲れる、あの時間です。
証拠が消えていく：待っている間にログは流れ、データは直され、状況は変わります。あとから完全な形で取り戻すのは、ほぼ無理です。
原因の推測から入ってしまう：情報が足りないまま「たぶんこれだろう」と当たりをつけると、外れたときに戻る場所がなくなります。AIに相談していると、これは特に起きやすくなります。もっともらしい仮説が、いくらでも返ってくるからです（AIのハルシネーションの見抜き方｜開発現場で気づく型、AIとの修正ループが終わらない｜堂々巡りから抜ける手順）。
報告者との関係がすり減る：何度も聞き返されると、相手は「責められている」と感じます。次から報告が来なくなるのが、いちばん困る結末です。

ただ、ここは希望のある話でもあります。この待ち時間は、聞き方を変えるだけで縮みます。原因を突き止める力ではなく、最初の1通で必要なことを聞ききる段取りの問題だからです。段取りは、今日から変えられます。

明日からやること（集める・整える・削る）

上から順に、小さく始められます。今日は「集める」だけで十分です。

1. 集める——AIに「足りない情報」を洗わせる

原因を聞かないでください。最初に頼むのは、質問リストです。

以下は、利用者から届いた不具合の報告です。原因の推測はまだ書かないでください。

この不具合をこちらで再現するために足りていない情報を、質問の形で挙げてください。優先度の高い順に、10個以内でお願いします。それぞれ、なぜその情報が必要なのかを一行添えてください。

あわせて、報告の中で事実として書かれていることと、報告者の推測を分けて整理してください。

前提：（システムの種類、利用者の範囲、本番か検証かを2〜3行で）
報告の本文：（ここに原文をそのまま）

出てきた質問は、そのまま送らないのがコツです。すでに分かっているものを消し、こちらで調べられるものを自分の作業に回し、相手に聞くしかないものだけを残します。3〜5問まで絞れると、返信率がはっきり変わります。

そして、残した質問は箇条書きにして、答えやすい形にして送ります。「ブラウザは何ですか」より「①Chrome ②Edge ③Safari ④その他（　）」のほうが、返事は速く正確に返ってきます。文面をAIに整えさせるときは、「責める調子にならないように」と一言添えると、ちょうどいい温度になります。

なお、報告にお客様の氏名や連絡先、業務データが含まれていることがあります。そのまま貼らず、置き換えてから渡してください。線引きの考え方は社内データをAIに渡す前の線引き｜情報漏えいを防ぐ型にまとめています。

2. 整える——4つの枠に書き写す

返事が集まったら、文章のままにせず、決まった形に整えます。枠は4つだけで足ります。

環境（端末・版・回線・アカウントの権限・本番か検証か）
操作（どの画面から、何を入れて、何を押したか。番号つきで）
発生状況（いつ、何回中何回、直前に変わったこと）
結果（実際に何が起きたか／何が起きると思っていたか）

この整形は、AIに任せて構いません。

以下のやりとりから、再現手順の下書きを作ってください。形式は「環境／操作（番号つき）／発生状況／結果（実際と期待）」の4項目です。

やりとりに書かれていないことは、埋めずに「不明」と書いてください。 推測で補完しないでください。最後に、まだ不明な項目を一覧にしてください。

「不明は不明と書く」を明示するのが要点です。これを言わないと、空欄をもっともらしい内容で埋めてしまい、あとで「そんなこと誰も言っていない」が発生します。ここはAIの善意が裏目に出やすい場所です。

そのうえで、あなた自身が下書きどおりに手を動かして、再現するか確かめます。ここは人がやるしかない工程です。再現したら、それが再現手順です。

3. 削る——最小の再現手順にする

再現できたら、そこで止めずにもう一手間かけます。手順を短くする作業です。

やり方は単純で、操作を1つ消してもう一度試す、を繰り返します。消しても再現するなら、その操作は無関係です。7手順が3手順になることは、珍しくありません。

AIには、どれから消すかの順番を相談します。

次の再現手順から、再現に関係なさそうな操作を、可能性の高い順に挙げてください。それぞれ、それを消して確かめる試し方も書いてください。

（ここに手順）

短い再現手順には、いいことが3つあります。調査範囲が狭まること。直したあとの確認がそのまま流用できること。そして、テストとして残せることです。最小まで削れた手順は、そのまま自動テストの一件に育てられます（境界値・異常系をAIに考えさせて漏れを減らす手順）。

再現しないまま終わることもあります。それも成果です。「この条件では再現しなかった」という事実を、条件つきで記録に残してください。次に同じ報告が来たとき、そこが出発点になります。原因の調査に進むときは、ログやスタックトレースの渡し方をスタックトレースをAIに読ませる｜バグ調査を速くする渡し方に、コードの前提の渡し方を既存コードにAIを馴染ませる文脈の渡し方｜実務の型にまとめています。

障害の再現手順チェックリスト（コピーして使えます）

不具合の報告を受けたときに、上から見ていくためのリストです。全部に○が要るわけではなく、気になった行だけで十分です。

① 集める（最初の30分）

原因の推測より先に、足りない情報を洗い出したか
報告の「事実」と「報告者の推測」を分けたか
自分で調べられる項目を、相手への質問から外したか
相手に送る質問を3〜5問に絞ったか
選択肢つきなど、答えやすい形にしたか
氏名・連絡先・業務データを置き換えてからAIに渡したか

② 整える（4つの枠）

環境（端末・版・回線・権限・本番／検証）が書けているか
操作が番号つきの順番になっているか
発生時刻と頻度（毎回／たまに）が入っているか
実際の結果と、期待していた結果の両方が書いてあるか
直前に変わったこと（リリース・設定・データ）を確認したか
不明な項目が「不明」と明記され、埋められていないか
自分の手で、下書きどおりになぞって再現を確かめたか

③ 削る（短くする）

操作を1つずつ外して、消せる手順を探したか
最小の手順を、他の人がそのまま実行できる文章にしたか
再現しなかった場合も、条件つきで記録に残したか
直したあとの確認手順として、この手順を使えるようにしたか
テストとして残す価値があるか、一度検討したか

この記事のまとめ

障害対応でAIに任せられるのは、原因の推測ではありません。再現手順を作るまでの、地味で時間のかかる部分です。

やることは3つ。①集める——「足りない情報は何か」を質問リストにさせ、絞って聞く。②整える——環境・操作・発生状況・結果の4つの枠に書き写し、不明は不明のまま残す。③削る——再現できたら、最小の手順まで短くする。

この3つが回り始めると、聞き返しの往復が減り、証拠が消える前に手が届くようになります。原因を当てる速さは変わらなくても、原因を探し始めるまでの時間は確実に短くなります。

「動きません」の一行から始まった朝は、正直しんどいものです。でも、そこから再現手順を1枚組み立てられる人は、現場でいちばん頼りにされます。誰も見たくない断片を、他の人が使える形にする仕事だからです。今日、次に届いた報告で「足りない情報は何か」を先に一度考えられたなら、それだけで午後の時間の使い方は変わります。