AIへバグ調査を頼む。再現手順と期待結果をどう渡すか

既存不具合の調査では、何が起きたか、どの条件で起きたか、どの条件では起きなかったかを先に確定します。「直して」とだけ頼むと、原因の推測、修正案、コード変更が一度に進みます。人が検証していない前提まで差分へ入り込み、直った理由をレビューしにくくなります。調査の途中でコードが変われば、最初に観察した状態も失われます。

2026年9月21日時点で確認した[Microsoftの公式チュートリアル](https://code.visualstudio.com/docs/agents/guides/fix-a-bug-with-agents)は、コード変更の前にバグ報告を検証し、同じ入力に対する実際の結果と期待結果を具体化する流れを示しています。最初の依頼では調査を求め、既存テストの実行、関連コードの追跡、ファイル参照付きの原因説明、回帰テスト案を編集前にレビューできる形にしています。

この原則をチーム運用へ移すと、依頼は「再現・原因調査」と「修正」の二段階になります。前半ではファイル編集を禁止し、再現可否、既存テストの結果、関係するコード経路、原因仮説、回帰テスト案を成果物にします。後半を始めるのは、人が調査記録を受け入れた後です。この二段階は出典を基にした実務上の提案であり、原典が定めた義務や分類ではありません。

調査を終える判定も先に決めます。AIが原因を一つ挙げた時点では保留です。台帳と同じ条件で症状が現れ、原因仮説を参照箇所から追え、対象不具合を捉える検査案がそろった時点で、人が修正の可否を判断します。

2026年9月21日時点の[GitHub公式Issueフォーム構文](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms)では、Current Behavior、Expected Behavior、Steps To Reproduce、Environmentが別々の入力欄です。別のバグ報告例には、ソフトウェアのVersion、問題が起きるBrowser、Relevant log outputの欄もあります。症状を一文に圧縮するより、観察内容を役割ごとに記録するほうが調査条件を固定できます。

自社の台帳には「再現入力と操作」「基準環境と差分」「期待結果」「実際の結果と証拠」の4欄を置きます。この4欄は、公式資料の一般原則から組み立てた実務上の提案であり、公式フォーム所定の必須様式ではありません。再現入力と操作には、対象へ渡した値、前提状態、実行順を記します。別の担当者が同じ順番で試せる粒度が基準です。

基準環境と差分の欄では、正常側と不具合側を対にします。製品、ランタイム、ブラウザ、設定などから調査に関係する項目を選び、版と設定値を両側に残します。分からない項目は「未確認」と記録します。空欄をAIの推測で補うと、観察済みの事実との境界が消えるためです。

期待結果は、同じ入力なら何が返るべきかを比較可能な言葉で書きます。実際の結果には、画面、返値、エラーなど観察した差を置き、関係するログや診断出力を対応付けます。「動かない」「期待どおりにならない」だけでは再現の成否を判定できません。4欄が埋まって初めて、AIへ渡す調査単位ができます。

依頼文では、観察済みの事実と、AIに調べてほしい内容を分けます。原因候補を事実の欄へ書くと、調査経路を早い段階で狭めます。情報を一括投入した依頼も、環境差の比較や再現確認が後回しになりがちです。次の文面は、確認済みの原則から組み立てた転記用の例であり、GitHubやMicrosoft所定のテンプレートではありません。角括弧の中を観察済みの情報へ置き換えます。

**再現入力と操作**: [対象へ渡した入力]、[操作前の状態]、[実行した操作]、[結果を確認した操作]を順に記す。同じ入力を再利用できる添付物があれば、その参照先を示す。

**基準環境と差分**: 正常側は[製品・ランタイム・ブラウザ・設定の版や値]、不具合側は[同じ項目の版や値]。確認できていない項目は「未確認」と記す。比較中は入力と操作を固定する。

**期待結果**: [同じ入力と確認操作に対して得られるべき結果]。**実際の結果と証拠**: [観察した画面・返値・エラー]。[その操作と対応するログや診断出力の参照先]。

**依頼内容**: ファイルを編集せず、上記の条件で再現可否と既存テストの結果を報告してください。続いて、関係するコード経路、参照ファイル付きの原因仮説、対象不具合を捉える回帰テスト案を示してください。入力または環境情報が足りない場合は、推測で補完せず、不足項目を返してください。

この依頼の停止条件は明確です。情報不足なら追加条件の確認で止め、再現できても原因仮説をコードから追えなければ調査を継続します。AIが編集を始める前に人が結果を読めるため、再現の取り違えを修正差分へ持ち越さずに済みます。

短い再現操作が得られても、「最小の失敗」ができたとは限りません。セットアップ不備で落ちる検査や、問題の周辺だけを見る検査では、修正後に何が変わったかを判断できません。Microsoftの同じ公式チュートリアルは、実装を変える前に回帰テストを追加し、期待値と実値の不一致が失敗理由であることを確かめるよう案内しています。HTTPステータスだけを確認する検査が、報告された問題を再現できない例も示しています。

チーム内では、最小の失敗を「固定した入力と環境で、期待値と実値の差を一つの検査として示し、その検査が対象不具合を理由に失敗する状態」と定義します。この定義も、公式資料の原則を実務へ移した提案であり、原典が定めた義務ではありません。テストコードを作れる場合は失敗する回帰テストを候補にします。まだ自動化できない場合は、同じ比較を反復できる確認手順と証拠を残します。

レビューでは、入力が台帳と一致するか、比較対象外の環境差が混ざっていないか、期待値に仕様上の合意があるか、実値が報告された症状そのものかを照合します。赤いテストが一つ増えたという事実だけで通過させると、別のエラーを対象不具合と誤認する余地が残ります。

検査がHTTPステータスの成功だけを確認し、報告された本文の違いを見ていないなら、調査は未完了です。期待値と実値のどの差が消えれば直ったと言えるのか。その答えを検査へ落とせることが、修正を許可する一つ目の関門になります。

入力、モデル、利用可能なツールを同時に変えると、どの差が結果へ影響したのか切り分けられません。2026年9月21日時点の[VS Code公式トラブルシューティング](https://code.visualstudio.com/docs/agents/agent-troubleshooting/troubleshooting)は、比較する実行でプロンプト、モデル、利用可能なツールを一定に保つよう案内しています。未解決問題の報告項目として、VS Codeのバージョン、明確な再現手順、期待結果と実結果、関連する診断出力も挙げています。

自社の調査では、再現入力、操作、期待値、検査方法を固定します。比較対象は、台帳で選んだバージョン、ブラウザ、ランタイム、設定などの環境条件です。複数項目を一群として変える必要がある場合は、その組み合わせを一つの実行として記録します。途中で条件を変えた結果を以前の記録へ上書きしません。再現しなかった実行も、発生しない条件を絞る証拠になります。

診断出力には別の境界があります。同じ公式ページは、共有前に機密情報を取り除き、認証情報や秘密を含めないよう警告しています。ログ、設定、入力内容をAIへ渡す前に、実際の結果と対応する範囲へ絞り、認証情報や不要な機密情報を除去します。情報量を増やす判断より、症状との対応と安全な共有を優先します。

入力範囲やツール権限も含めて運用を決める場合は、Claude Codeのセキュリティ｜法人導入前に決める権限とデータ管理で確認項目を整理できます。バグ調査の台帳には、共有可否を確認した担当者と、除去した情報の種類も残すと、同じ証拠を再利用するときの判断が安定します。

修正開始の可否は、再現、失敗、調査、安全の4点で判定します。再現の判定では、台帳どおりの入力と環境で報告された実結果を確認します。失敗の判定では、期待値と実値の差を検査が直接示し、セットアップ不備など別の理由で落ちていないことを確かめます。

調査の判定では、関連コード、原因仮説、回帰テスト案を参照箇所とともにレビューします。安全の判定では、共有する入力と診断出力から認証情報、秘密、不要な機密情報が除去されていることを確認します。いずれかが保留なら、修正許可も保留です。再現できないケースは、情報不足、環境差、別の失敗のどれに当たるかを記録し、調査依頼を更新します。

修正へ進んだ後も台帳と最小の失敗を残します。変更案が同じ検査を通過するか、既存テストへ影響しないかをレビューする共通基準になるためです。AIが作る差分を工程のどこで人が確認するかは、AI駆動開発の開発フロー｜レビュー・テスト・CIで人の判断を残すへつなげて設計できます。

自社でAIによるバグ調査を実行できる条件は、再現入力と操作、基準環境との差、期待結果、実際の結果と安全に共有できる証拠がそろい、対象不具合による最小の失敗を人が確認できることです。その条件を満たした後に、編集前の原因調査をレビューし、修正を別工程として許可します。条件を満たせない案件では、人が台帳を補い、観察できる差を確定するところから始めます。

自社の案件に合わせて調査台帳や承認条件を設計したい場合は、AI駆動開発の研修、導入支援、技術顧問の相談対象です。研修は30万円、導入パッケージは50万円から、技術顧問は月15万円で、初回60分の相談は無料です。個別の生産性や品質向上を保証するサービスではありません。利用するAIや開発環境を確認したうえで支援範囲を決めます。