ブローガスト4日目: Sentry 調査が捗った話

最近お仕事で、エラートラッキングツールでお馴染みの Sentry を使ったエラー調査が捗りました。
その出来事を書こうと思います。

調査はしんどい

緊急性が高くないケースの調査をしていたのですが、ほったらかしにしていた大量のissueを捌いていました。
issue で発生しているエラーの調査ってしんどいです。
エラーがなぜ発生したのかを再現する手順を確定させた上で、どのようにして修正するのか方針を決めて、
修正検証して issue を閉じる、までが長くてしんどいです。

原因調査をする要因を絞り込んでいく作業だけでなくて、ライブラリ起因などの不具合や振る舞いを深く理解しないといけないのも、しんどいです。

両面から攻める

AI (Codex) を使って、Sentry の API や MCP を利用することで、一緒に調査を手伝ってくれます。
私はトップダウン式で攻めて AI にはボトムアップ式に攻めます。

私の方で、以下のような情報を整理します。

どこから辿ってきたか
- 状態遷移に依存したロジックがあるか？
誰が実行したのか
- ユーザーの属性に依存したロジックがあるか？
いつ実行されたのか
- 実行タイミングに依存したロジックがあるか？
どのデータが使われたか
- データに依存したロジックがあるか？

『xロールの人が、yの日に、zのページにアクセスして...、』と状況整理します。

AI ボトムアップ式

私が状況整理している間には、AI にボトムアップ式に調べさせます。
エラーが発生している箇所は確定（error throw）しているので、そこがなぜ発生したのかを逆算させます。
そうすると、さまざまなパターンの発生ルートを列挙してくれます。
『xxの分岐を通るには、yyの条件が成立する必要があり...』など。

またこれが個人的にありがたいのですが、ライブラリへの深い調査です。
今のWebアプリは、さまざまなOSSを使わさせ貰って成り立っていることが多いです。
Webフレームワークやルーティング、APIクライアントなど巨大なライブラリだと、調査が大変なんです。
ローカル環境では、ライブラリのソースコードが難読化などして読みにくかったりすることもあったりで、
ライブラリを手元にチェックアウトして調べる、みたいなことを昔はよくしていました。
あとは issue などで上がっていないかを漁ったりしてバグなのか仕様なのかを調べたり。

この作業はできるのですが、負担が大きいんです。
よく知っているコードのリバースエンジニアリングでもしんどいのに、
あまり知らないコードのリバースエンジニアリングは予測推測するので、
頭の中で分岐がたくさん生まれて記憶するのがしんどいです。

ITヲタクな AI は、こういう調査が得意と思っていて、
逆算する際にライブラリの挙動についても調べてくれるのです。
具体的なソースコードをGitHub リンク付きで『ここの挙動が影響して...』などと教えてくれます。

さらに良いのは、issue 発生時のライブラリのバージョンで調べてくれます。
今なんでか再現しないけど昔は発生していた、というときにライブラリが直してくれた、
というのもよくあるので、こういうのも AI はSentry のイベント発生時点でのソースコードをgit 履歴を調べて、
その当時のライブラリバージョンで調査してくれます。
『ライブラリ v1.1 では問題が発生していましたが、v1.2 で yy という修正が入ったため、解決されたようです』というのも教えてくれます。

技術的な側面をボトムアップ式にAI が、
業務ドメイン的な側面をトップダウン式に私 が調べることで、
Sentry エラー調査が捗った、また勉強になった今日この頃でした。

もちろん、ボトムアップ式な選択肢が全て間違っているというのもよくあるので、
選択肢を疑ってかかり、自身が納得できるロジックで再現性を確認する必要があります。