【ITニュース解説】How to Use AI to Triage and Reproduce a Bug Report

システム開発において、ユーザーからのバグ報告は非常に重要だが、その内容が不完全だったり、曖昧だったり、あるいは多くの情報の中に埋もれていたりすることは少なくない。このような状態のバグ報告を前にして、まず修正に取り掛かる前に必要なのが「トリアージ」と「再現」のプロセスだ。トリアージとは、そのバグがどれくらい深刻なのか、どの担当チームやシステム部品（コンポーネントやサービス）が対応すべきかを判断すること。そして再現とは、報告されたバグが実際にどのような手順で発生するかを開発者自身が確認できる状態にすることだ。特に再現は、多くの場合、バグ修正プロセスの最も難しい部分となる。しかし、近年進化しているAIを適切に活用することで、「ユーザーからバグ報告のチケットが発行された」という段階から「バグを発生させるテストケースが目の前にある」という段階までの時間を大幅に短縮できるようになった。以下に、AIを駆使してバグ対応を効率化するための具体的なワークフローを説明する。

まず最初のステップは、AIに生のバグ報告を与え、その要約とトリアージに関する情報を求めることだ。ユーザーから送られてきたバグ報告には、プログラムがエラーで停止した際の実行履歴（スタックトレース）、ユーザーが感じた問題の説明、システムが出力した記録（ログ）など、あらゆる情報が混在していることが多い。これら全ての情報をAIにそのまま入力し、次のような情報を要約してほしいと指示する。一つ目に「何が問題で失敗しているのか」を簡潔な一文で説明すること。二つ目に、そのバグの「重要度（P1/P2/P3といった、緊急度に応じた分類）」を推定し、その理由も述べること。P1は最も緊急度が高く、P3は比較的低いバグを指す。三つ目に、そのバグが最も関連性の高い「システム部品や担当サービス」を特定すること。そして四つ目に、「バグを再現するために何の情報が不足しているか」を明確にすることだ。このAIからの出力は、バグの全体像を素早く把握するための構造化された出発点となる。特に「不足情報」の出力は非常に価値があり、これはバグ報告者に対して追加で尋ねるべき情報や確認すべき事項のチェックリストとしてそのまま利用できる。

次に、AIに対して、そのバグを再現するための最小限のシナリオを生成するよう依頼する。ステップ1で得られたトリアージ要約に基づき、もし関連するプログラムコード、データベースの設計情報（スキーマ）、システムの設定ファイル（コンフィグスニペット）などがあれば、それらも一緒にAIに提供する。その上で、AIに「このバグ報告と提供されたコードに基づいて、開発者がゼロの状態から始められる、ステップバイステップの再現手順を作成してほしい」と指示する。この際、「作成した再現手順の中で、どのような仮定を置いているか明示すること」という指示を加えることが非常に重要だ。なぜなら、AIが作成する手順には、開発者が当たり前だと思って見過ごしてしまうような前提条件が含まれている可能性があるためだ。もしこれらの仮定が実際と異なっていれば、その再現手順を試すために30分も無駄な時間を費やしてしまうことになる。AIに仮定を明示させることで、そうした時間の浪費を防ぎ、再現パスのギャップを事前に発見できるのだ。

ステップ2で作成された再現手順を元に、今度はAIに「バグを発生させて失敗するテスト」を作成させる。これはAI活用の真骨頂と言える部分だ。作成された再現手順をAIに渡し、特定のプログラミング言語やフレームワーク（例えば、Pythonのpytest、JavaのJUnitなど）で、単体テストまたは結合テストを作成するよう指示する。このテストは、以下の要件を満たす必要がある。まず、「バグを発生させる正確な事前条件を整える」こと。次に、「バグが引き起こされるプログラムの経路（コードパス）を呼び出す」こと。そして最後に、「バグによる誤った挙動を明示的に検証し、バグが修正されるまでテストが失敗し続ける」ようにすることだ。このステップを完了することで、実際にバグを修正するコードを一行も書く前に、そのバグが再発しないことを確認するためのテスト（リグレッションテスト）を手にすることができる。バグ修正よりも先に、そのバグを検出するテストが手元にある、これは正しい開発プロセスと言えるだろう。

そして最後のステップでは、再現可能なバグと失敗するテストケースが揃った状態で、AIにバグの「根本原因」を仮説立てさせる。バグの全体像と失敗するテストコードをAIに提供し、「最も可能性の高い根本原因を3つリストアップし、それぞれの原因について、どのようなコード変更を加えればその原因が正しいか、あるいは間違いであるかを検証できるか」を具体的に記述するよう求める。これにより、何から手をつけて良いか分からないデバッグ作業が、明確な作業順序を持った構造的な調査へと変化する。AIが提示する原因候補と検証方法は、開発者がデバッグに費やす時間を大幅に削減し、より効率的に問題解決へと導いてくれるだろう。

これら四つのステップは、連動したパイプラインとして機能する。まず生のバグ報告がAIに入力され、それがトリアージ要約として出力される。次にこの要約が再現手順の生成へと引き継がれ、さらにその再現手順が失敗するテストの作成へとつながる。そして最終的に、バグの説明と失敗するテストが根本原因の仮説立てに活用される。このように、各ステップの出力が次のステップの入力となるため、AIは常に適切な文脈（コンテキスト）を持って処理を進めることができる。筆者もこのワークフローを使って、通常であれば1時間以上かかるような複雑な非同期処理の競合状態に関するバグを、わずか20分足らずで再現テストまで作成できた経験があるという。このワークフローを実践する上で特に重要なのは、最初のステップである「トリアージ要約の取得」を飛ばさないことだ。構造化されたトリアージ要約を作成することで、実際にプログラムコードに手を付ける前に、そのバグについて自分が正しく理解しているかを確認する規律が生まれるのである。