デバッグと根本原因分析 — ソフトウェアチームと技術チームのための人工知能

利益:

バグを再現可能な最小のインスタンスに削減し、完全な証拠を持って AI に移行する機能
最も安価なコントロールで証拠に基づいた仮説をテストし、根本原因を見つける能力
症状にパッチを当てるのではなく、根本原因を解決し、回帰テストで確実に解決する能力

デバッグは、ソフトウェアが予期せぬ動作をする理由を突き止め、それを修正するプロセスです。開発者が最も多くの時間を費やし、最も疲れる仕事です。なぜなら、ほとんどの場合、間違いは現れる場所ではなく、数歩後ろに隠れているからです。 AI はこの研究を加速する強力な思考パートナーですが、それは適切な証拠を提供した場合に限ります。証拠のないデバッグは、AI が最も多くの幻覚を引き起こす領域です。

この単元では、エラーの生成から根本原因に到達するまでの規律あるフローを確立します。つまり、症状の明確化、証拠 (エラーメッセージ、スタックトレース、ログ、エントリ) の収集、仮説の生成、仮説のテスト、修正の検証です。 AI はあらゆる段階で役立ちます。しかし、「修正された」という決定は、バグが実際になくなったことを確認することによって行われます。

なぜ証拠がすべてなのでしょうか?

LLM は、あなたが行うようにエラーを認識しません。彼はあなたが彼に何を言ったかだけを知っています。「アプリケーションがクラッシュする」のような文はモデルにほとんど情報を与えず、モデルはそのギャップを予測、つまり幻覚で埋めます。さらに、完全なエラーメッセージ、スタックトレース、エラーが発生した関数呼び出しの内訳、エラーをトリガーした入力、予想される内容などが表示されます。観察された動作を考慮して、モデルは真の確率をランク付けできます。

デバッグでは、AI を探偵のアシスタントとして考えてください。提示する証拠が多ければ多いほど、生成される仮説はより正確になります。証拠がない場合、アシスタントは推測するだけで、あなたを間違った道に導く可能性があります。

ヒント: バグを AI に移植する前に、バグを再現可能な最小の例に縮小します。エラーをトリガーする最小のコードと入力により、ユーザーとモデルの両方にとって作業が大幅に容易になります。ほとんどの場合、この減少中に自分で原因を見つけることができます。

ステップバイステップ: 根本原因分析フロー

症状を明確にします。「何が起こっているのですか、何が起こると予想していましたか？」この 2 つを 1 つの文で書きます。
証拠を集めましょう。完全なエラーメッセージ、スタックトレース、関連するログ行、トリガーエントリ、バージョン情報。
仮説を立ててもらいます。 AI より「この症状を説明する 3 つの考えられる原因と、それぞれをどのようにテストすればよいですか?」聞く。
最初に最も安価な仮説をテストします。ログを追加し、値を出力し、テストを実行します。証拠は仮説を裏付けていますか?
症状ではなく根本原因を解決してください。パッチで症状を抑えるのではなく、根本原因に対処してください。
回帰テストを検証して追加します。エラーが消えるのを確認してください。次に、そのエラーをキャッチしてエラーが戻らないようにするテストを作成します。

ミニケース3個

ケース 1 — スタックトレースにより、正しいファイルが見つかりました。アプリケーションは特定のリクエストで 500 エラーを返していました。開発者は完全なスタックトレースとトリガーリクエストを AI に渡しました。モデルは、日付解析レイヤーの None 値がエラーの原因であると仮定しました。開発者はその行にログを追加して検証し、15 分で解決しました。前日は実証されていない実験で2時間が無駄になった。

ケース 2 — 幻覚が間違った道を導きました。別の開発者は単に「データベース接続が切断されています」と書きました。 AI は何の証拠もなく接続プール設定を告発しました。開発者はこの設定をいじるのに 40 分を費やしました。本当の原因はネットワーク側のタイムアウトであり、ログを確認することでのみ判明しました。教訓: 証拠なしに立てられた仮説は、可能性があるだけであり、信頼できるものではありません。

ケース 3 — 不安定なエラーが検出されました。時々失敗するテストがありました。 AIにはテストコード、失敗メッセージ、そして「合格する場合もあれば失敗する場合もある」という情報が与えられました。モデルは、テストの時間と順序の共有依存性を示しました。レビューにより、テストがシステムの現地時間に基づいていることが確認されました。クロックが修正されると (モック化され)、テストは安定しました。

4 つのコピー可能なテンプレート

証拠に基づいた仮説の生成:

バグをデバッグ中です。以下の証拠。- 予想される動作: {{expected}}- 観察された動作: {{observed}}- エラーメッセージ / スタックトレース: {{trace}}- トリガー入力: {{input}}- 環境/バージョン: {{version}}この症状を説明する最も可能性の高い 3 つの根本原因をリストします。それぞれについて：テスト方法（最も安価なチェック）と、それが真実である場合にそれを修正する方法。証拠が不十分な場合は、さらに必要な情報を教えてください。

スタックトレースの解釈:

このスタックトレースを読んでください。おそらくエラーが (ルート) から始まる行と、チェーンの単なる継続である行を区別します。最初に探すべき場所を 1 ～ 2 か所提案します。関連コード:{{code}}トレース:{{trace}}

最小限の再現減算:

以下のコードではエラーが発生します。これを最小のインスタンスに減らしますが、それでもエラーは発生しますが、不要なものはすべて破棄されます。削除したすべての部分がエラーに影響しないとは考えず、「これを削除するとエラーが消えた場合は、それが原因です」というメモを追加してください。{{code}}

修正後の検証と回帰テスト:

根本原因は {{cause}} であると仮定し、次の修正を行います: {{fix}}。1) この修正は実際に症状を修正しますか?副作用はありますか?2) 将来このバグを検出する回帰テストを作成します。

弱いプロンプト / 強いプロンプト

弱者: 「コードが機能しないのですが、なぜですか?」

Strong: 「ノード 20 / Express。本体内の items が空の文字列の場合、POST /orders は 500 を返します。本来は 400 を返すはずです。スタックトレース: TypeError: 未定義のプロパティを読み取れません ('0' を読み取ります) — 完全なトレースと関連するハンドラーが添付されています。この症状を説明する最も可能性の高い 3 つの原因と、それぞれをテストする方法を教えてください。[トレース + コード]」

強力なバージョン。環境、エンドポイント、トリガー入力、正確なエラータイプ、および予期される動作が示されます。モデルは予測を行うことはできなくなり、分析を行うことができます。

ステップ

AIの貢献

あなたのコントロール

証拠を集める

どのような証拠が必要か、思い出させる

本格的に証拠を集めます

仮説生成

考えられる理由を列挙する

コンテキストに応じて優先順位を付ける

仮説検証

推奨するテスト方法

個人的に操作および観察します

修正

パッチが推奨する

根本的な原因は解決するのでしょうか？それは本当です。

回帰

テストを書きます

テストが壊れていることを確認します

症状ではなく根本原因を解決する

ほとんどの場合、AI は症状を素早く静めるパッチを提案します。つまり、try/catch を追加し、null チェックを入れ、エラーを飲み込みます。これは時には真実ですが、多くの場合は危険です。なぜなら、元の原因はそのまま残り、別の場所から再び噴出するからです。修正を行うたびに、「これでエラーの原因が修正されるのか、それともエラーが見えなくなるのか?」と自問してください。根本原因が見つかったら、通常、修正はより小規模で、より堅牢で、永続的なものになります。

注意: 例外 (空のキャッチ) を黙って飲み込んでもエラーは解決されません。それは単に隠蔽し、将来の診断を不可能にするだけです。 AI がそのような「解決策」を提案した場合、根本原因を疑うことなしにそれを受け入れないでください。

よくある間違い

証拠のない質問。あいまいな文はモデルを幻覚に陥らせます。完全なエラー、トレース、入力を提供します。
最初の仮説を確定します。 AI の最初の提案が最も可能性が高いわけではないかもしれません。最も安価な制御可能な仮説から始めます。
症状を修正し、根本原因を取り除きます。沈黙したエラーが返されます。
修正を検証せずに閉じます。運用環境と同様の状態で、エラーが実際に消えることを確認してください。
回帰テストは書かない。テストが追加されていない場合、以降のバージョンでは同じエラーが静かに返されます。

要約すると

デバッグでは、AI の能力は、AI に与えられた証拠に直接比例します。完全なエラーメッセージ、スタックトレース、トリガー入力、および予想される動作がなければ、モデルは推測するだけです。症状を明確にし、証拠を収集し、仮説を生成し、最も安価なコントロールでテストし、根本原因を修正し、検証し、回帰テストを追加するという規律あるフローにより、バグを迅速かつ永久に解決します。 AI は仮説を生成するものです。バグが実際に解決されたかどうかを判断するのはあなたです。

アプリケーションタスク

最近遭遇した実際のバグを選択してください (またはテストバグを再現します)。最初に「最小限の再現」ステップを実行します。エラーを引き起こす最小のコードと入力を削除します。次に、「証拠に基づく仮説生成」テンプレートを使用して、AI から 3 つの考えられる原因とテスト方法を取得します。最も安価な仮説を自分でテストし、根本原因を見つけて修正し、最後に将来このバグを検出する回帰テストを作成し、テストが実際に壊れていることを確認します。

チェックリスト

[ ] AI に移動する前に、誤差を再現可能な最小のサンプルまで削減します。
[ ] 完全なエラーメッセージ、スタックトレース、入力、および予期される動作をプロンプトに追加しています。
[ ] 単一の仮説に縛られることなく、最も安価で制御可能なものから始めます。
[ ] 症状にパッチを当てるのではなく、根本原因が解決されたことを確認します。
[ ] この修正により実際にバグが修正されたことがわかります。
[ ] 解決されたバグごとに回帰テストを追加します。