スタックトレースをAIに読ませる｜バグ調査を速くする渡し方
深夜、ビルドが通ったはずのコードが本番で落ちた。 ターミナルには、見上げるほど長いスタックトレース。とりあえず全部コピーして、AIに貼って「これ直して」——。
返ってきたのは、それらしい説明と、それらしい修正案。 でも、直らない。あるいは、直ったように見えて別の場所が壊れる。
このすれ違い、けっこうあります。 そして多くの場合、AIの賢さの問題ではなく、渡し方の問題なんです。スタックトレースを「丸ごと投げる」から、AIは足りない文脈を想像で埋め、もっともらしい的外れを返す。逆に言えば、渡し方を少し整えるだけで、AIはバグ調査のかなり心強い相棒になります。
この記事は、AIにスタックトレースを読ませてバグ調査を速くする渡し方の型をまとめたものです。長く見えますが、全部は要りません。まず効く所から拾えば回ります。
30–60秒のファストパス（最低ライン）
- まず自分で1行だけ読む：例外の種類とメッセージ、そして自分のコードが最初に出てくる行（30秒以内）
- 貼る前に絞る：全文＋その「自分のコードの行」周辺のソース。無関係なライブラリ内部の深い連なりは要点だけ（30秒以内）
- 聞き方を変える：「直して」ではなく「考えられる原因を可能性順に、確認方法つきで」（10秒）
※機密（トークン・パス・個人情報・社内URL）が混ざっていたら消してから貼る。迷ったら一旦保留でOK。
結論：スタックトレースは「AIに丸投げして答えをもらうもの」ではなく、「絞って・文脈を添えて・仮説の相棒として渡すもの」。AIは読解の速度を上げてくれますが、原因を断定する裁判官ではありません。まず効くのは、①自分で例外種別と自コードの行を1点だけ見る → ②その周辺のソースと環境情報を添えて渡す → ③断定でなく「可能性順＋確認方法」で聞く → ④仮説は必ず自分で1つ再現・確認する。
AIに頼るのは、手を抜くためではありません。 長いトレースの前で固まる時間を減らして、確かめる作業に集中するためです。
なぜAIのスタックトレース読解は的を外すのか
AIは、あなたの環境を見ていません。見えているのは、貼りつけた文字列だけです。だから外すときは、だいたい次のどれかです。
- 文脈が無い：言語・バージョン・フレームワーク・何をしようとしていたか、が分からず「よくあるパターン」で埋める
- トレースの一部しか見ていない：長すぎて途中を省略して貼ると、本当の根っこの行が欠ける
- 原因の行を取り違える：一番下（or 一番上）の派手な行に飛びつき、「自分のコードで最初に壊れた行」を飛ばす
- もっともらしい誤り（ハルシネーション）：存在しない設定や引数を、自信たっぷりに原因として挙げる（→AIのハルシネーションの見抜き方）
- 環境・バージョン差：手元の版では廃止済みの挙動を前提に説明する
裏を返すと、この隙間を埋めてあげれば精度は上がります。次から、その埋め方です。
まず自分で1行だけ読む——AIに渡す前の30秒
丸投げの前に、自分で「取っかかり」を1つ掴んでおくと、AIの答えの当たり外れを見分けられるようになります。全部を読む必要はありません。見るのは2か所だけです。
①例外の種類とメッセージ
トレースの中で、エラーの型名と、その一言メッセージをまず読みます。 NullReferenceException なのか TimeoutException なのか KeyError なのか——ここで「何系の故障か」の当たりがつきます。メッセージ末尾の「〜 not found」「〜 is not defined」「connection refused」なども強いヒントです。
②自分のコードが最初に出てくる行
長いトレースの多くは、ライブラリやフレームワークの内部フレームです。そこは今は飛ばしてよくて、「自分たちが書いたファイル」が最初に登場する行を探します。多くの場合、そこが調査の入口です。
ヒント：言語によって「読む向き」が違います。上から新しい順（Python など、一番下が発生元に近いことが多い）か、下から呼び出し順か。自分の言語での並びに慣れておくと、この30秒が一気に速くなります。
この2点を掴んでおくと、AIが見当違いの行を原因にしたとき「いや、自分のコードはここで落ちてる」と軌道修正できます。
AIに渡すときのコツ——4つの手順
手順1：何を渡すか——「絞る」けど「削りすぎない」
貼るのは、次の3点セットです。
- スタックトレースの全文（少なくとも「例外の型・メッセージ」と「自分のコードのフレーム」は欠かさない）
- 例外が出た自分のコードの該当箇所（その関数まるごと、前後数行）
- 関係しそうなら、呼び出し元や設定の該当部分
長すぎるトレース（フレームが何十段もある）は、ライブラリ内部の深い連なりは要点だけに畳んで、自分のコードのフレームを中心に残すと読みやすくなります。逆に、途中を勝手に省略して根っこの行を落とすのは避けます。「長いから」と例外メッセージだけ貼るのが、いちばん外れやすいパターンです。
手順2：文脈を添える——AIが見ていないものを言葉にする
ここがいちばん効きます。トレースと一緒に、短くていいので次を書き添えます。
- 言語・バージョン・フレームワーク（例：どの言語の何系、主要ライブラリの版）
- 何をしようとして起きたか（どの操作・どのリクエストで落ちたか）
- 再現条件（毎回か、特定の入力・タイミングだけか）
- 直近の変更（最後に触った所、上げた依存、変えた設定）——バグは変更点の近くにいることが多いです
- 環境の違い（手元では動く／本番だけ落ちる、など）
「直近で依存を上げた」「本番だけ落ちる」の一言があるだけで、AIの見立てはぐっと現実的になります。
手順3：聞き方を変える——「直して」より「可能性順に」
「これ直して」と聞くと、AIは1つの答えに飛びつきがちです。バグ調査では、候補を広げてから絞る方が速い。聞き方の例：
- 「このスタックトレースから考えられる原因を、可能性が高い順に3つ挙げて。それぞれどう確認すれば切り分けられるかもつけて」
- 「まず確認すべきログや値はどこ？」
- 「この例外が出る典型的なパターンを教えて。今回の文脈に当てはまるものはどれ？」
「確認方法つき」で聞くのがコツです。答えそのものより、次に自分が何を見ればいいかが手に入ると、調査が前に進みます。
手順4：仮説は必ず自分で1つ確認する
AIが挙げた原因は、あくまで仮説です。もっともらしくても、鵜呑みにしない。
- 一番あり得そうな仮説を1つ選ぶ
- ログ・デバッガ・該当行の値で、その仮説が本当かを確かめる
- 直したら、最小の再現手順でもう一度落ちないかを確認する（→生成コードの動作確認の型）
「動かなくなった原因」と「たまたま直ったように見える変更」は別物です。なぜ直ったかを一言で説明できるところまでいけば、その修正は信頼できます。
機密を消してから貼る——地味だけど大事な一手
スタックトレースには、思っている以上に中身が写り込みます。ファイルの絶対パス（＝ユーザー名やディレクトリ構成）、接続文字列、トークンやAPIキー、リクエストに含まれた個人情報、社内URLやホスト名——。
外部のAIサービスに貼る前に、ここはさっと伏せます。
- パス・ホスト名・ユーザー名は伏せる、または一般化する
- トークン・キー・パスワード・接続文字列は消す
- 例外メッセージに乗った実データ（メールアドレス・氏名など）はダミーに置き換える
「原因の切り分けに要らない情報は、そもそも渡さない」が基本です。何をどこまで渡してよいかの線引きは、社内データをAIに渡すときの線引きにまとめています。
ありがちな落とし穴
- 例外メッセージだけ貼る：一番外れやすい。根っこはトレースの下の方にいることが多い
- 一番派手な行を原因と決める：フレームワーク内部の行に飛びつき、自コードの発生元を飛ばす
- 文脈を書かない：バージョンも操作も書かず「エラーが出た」だけ渡す
- 最初の答えで満足する：可能性を広げず、1つ目の仮説を確かめずに実装
- AIの「たぶんこれ」を断定と受け取る：確認方法を聞かないまま修正して、別の所を壊す
- 機密が混ざったまま貼る：パスやトークンごとコピペしてしまう
- バージョン差を無視：AIが古い（or 新しい）版の挙動を前提に説明しているのに気づかない
明日からやること（小さく始める3つ）
- トレースを貼る前に、例外の種類・メッセージと自分のコードが最初に出る行の2点だけ自分で読む
- 貼るときは、全文＋該当ソース＋「言語/版・何をして・直近の変更」をワンセットで渡す
- 「直して」ではなく「可能性が高い順に原因と確認方法を」と聞き、1つは自分で再現して確かめる
この3つだけでも、的外れな答えに振り回される時間はかなり減ります。慣れたら、ログの絞り込みや最小再現の作り方を足していけば十分です。
スタックトレース×AI 調査チェックリスト
「関係する所だけ見る」が前提です。全部に○は要りません。いま扱っている状況に関わる所だけ、さっと確認します。
貼る前（30秒）
- 例外の型とメッセージを自分で読んだか
- 自分のコードが最初に出てくる行を見つけたか
- 機密（パス・トークン・個人情報・社内URL）を伏せたか
渡し方
- トレースを省略しすぎていないか（根っこの行が残っているか）
- 該当ソース（関数の前後）を一緒に渡したか
- 言語・バージョン・フレームワークを書いたか
- 何をして落ちたか／再現条件／直近の変更を添えたか
聞き方
- 「直して」ではなく「可能性順＋確認方法」で聞いたか
- まず見るべきログ・値を尋ねたか
受け取ったあと
- 仮説を鵜呑みにせず、1つ自分で確認したか
- 提示された関数・設定が実在するか確かめたか（ハルシネーション対策）
- 修正後、最小再現で再発しないか確認したか
- なぜ直ったかを一言で説明できるか
最後に
長いスタックトレースの前で固まる夜は、誰にでもあります。 AIは、その連なりを一緒に読んでくれる相棒になります。ただし、丸投げの相手ではなく、絞って・文脈を添えて・可能性を一緒に広げる相棒として。最後に原因を確かめるのは、やっぱり現場を知っている人の役目です。
今日ひとつ、「貼る前に例外の型と自コードの行を読む」ができたなら、それはもう、調査の主導権を自分の側に取り戻す確かな一歩です。
よければ、こちらも
- AIの「たぶんこれ」を見抜く型はAIのハルシネーションの見抜き方へ。
- 直したコードの確かめ方は生成コードの動作確認チェックリストへ。
- トレースに機密が混ざるときの線引きは社内データをAIに渡すときの線引きへ。