Article by: Neel Shah（読了時間：4分）
Sentry の SDK チームは、幅広い言語とフレームワークのエコシステムにわたって SDK を開発・サポートしています。公開パッケージの正確な一覧はリリースレジストリをご覧ください。現在、エコシステム全体で 159 のパッケージを公開しています。あなたが使っているものも、Sentry がサポートしているものかもしれません。
これらの SDK はすべてオープンソースであり、それぞれ独自の GitHub リポジトリ（JavaScript 版はこちら）として日々メンテナンスしています。そしてどのオープンソースプロジェクトとも同様に、大量のバグ報告や Issue が寄せられます。
この記事では、再現フローをスムーズにしてトリアージの時間と疲労を軽減するために活用してきた Claude スキルについてお話しします。
バグのトリアージフロー
null チェックの漏れ、条件分岐の見落とし、その他の小さなミスなど、修正が簡単なバグもあります。
しかし、そうではないバグも多く存在します。理由はさまざまです。
- 環境を整えるだけでも面倒な「ボイラープレート」
- 難解なコードパス
- レガシーバージョン
- 誰も想定しなかったエッジケースの組み合わせ
- データ競合などの並行処理の問題
- 異なる契約を持つフォーク済みライブラリ
ボイラープレート
特に SDK のバグでは、ボイラープレートコードが多いことが大きな負担です。
最近の例を見てみましょう。このバグを再現するには、以下のセットアップが必要です。
- 正しいバージョンの Python venv
- 正しいバージョンの Django ボイラープレートアプリ
- 正しいバージョンの Sentry SDK
- HTTPS プロキシ限定の問題を再現・確認できる Django View の作成
- すべてを起動し、View をトリガーして、問題が再現されることを確認
これらはすべて、元のユーザーが報告した問題が実際に再現可能であることを確認するためだけに必要な作業です。再現さえできてしまえば、実際の修正を展開するのは格段に容易になります。
再現の記録
チーム内でもう一つ繰り返し議題に上がっていたのは、SDK ロジックのテストやバグの再現・修正に使った「使い捨てのボイラープレートアプリ」をどう管理するかという問題でした。
理想的には、Issueへのバックリンク付きでこれらのアプリを集約した共有リポジトリがあればよいのですが、他にも優先すべき作業が山積みで、さらにアプリ群を管理・保守する負担を引き受けたい人はいませんでした。そのため、多くのSDKエンジニアは日々のSDK開発に必要な独自のアプリをその都度作成し、整理されないまま蓄積していました。
repro スキル + リポジトリ
そこで LLM の登場です。LLM は上記のような面倒な作業を行うことが得意であることが分かりました。
問題の根本原因にたどり着けないとしても、少なくともボイラープレートをセットアップし、正しいパラメーターが揃ったプレイグラウンドを用意してくれます。そこから先は自分で進められるので、手間が大幅に削減されます。
そこで私は Claude スキルを作成し、反復を重ねました。このスキルは以下を行います。
- GitHub Issue の URL を入力として受け取る
- SDK の言語と Issue 番号を解析する
- 言語バージョン・フレームワークバージョン・SDK バージョンのメタデータを収集する
言語/issue番号の形式で新しいディレクトリとブランチを作成する- 各言語の標準ツール（
uv・npm・bundleなど）を使って最小限の再現コードを作成する - 再現コードの実行を試み、複雑すぎる場合は中断する
- 再現手順を分かりやすく記述する
- PR を作成する
- 任意で Claude の
AskUserQuestionツールを使って、元の Issue にその PR へのバックリンクを追加する
注目すべきは、LLM に再現を「試みる」よう指示し、複雑すぎる場合は中断するようにしている点です。この種のロジックはエージェントとの連携において非常に効果的です。求めすぎるとエージェントはよくつまずきます。逃げ道を与えることで、無理に進もうとせず、難しい点を説明してくれるようになります。
Python の Issue での実行例
先ほどの Python の例に戻ると、このスキルがこの再現コードを作成しました。最小限の Django アプリが作られ、再現手順も非常に明確に示されています。この基本セットアップを使って、その後の修正を非常に素早く展開できました。HTTPS プロキシで Django を正しくセットアップする方法を調べ、それが SDK ロジックとどう絡み合うかを分析する作業で、おそらく数時間は節約できたと思います。
スキルを書くときに学んだこと
スキルは非常に汎用的な Markdown ファイルであるため、信頼性を高めて暴走を防ぐ方法がやや分かりにくいところがあります。
このスキルを書いて得たいくつかの知見を紹介します。
- 他のシステムとのやりとりには CLI を使う。ここでは GitHub 操作に
ghCLI を使用 - 作業を明確なステップに分割する
- 許可されていないことや不正な入力への対処を説明する
Error Handlingセクションを追加する - ユーザー入力や確認には
AskUserQuestionなどの組み込みツールを活用する
完全自動化は？
将来的には、GitHub Issue 上でこのフローを完全に自動化することも試みる予定です。ただし、チームの複数のエンジニアが懸念しているのが、ボットによるノイズの増加です。すでにさまざまな場面でボットの通知に埋もれている状態なので、どれを自動化するかは慎重に判断したいと思っています。あらゆる問題領域において、適切な自動化の量が完全自動化とは限りません。適切な箇所に人間の目が入ることは絶対に必要です。
Original Page: https://blog.sentry.io/ai-bug-reproduction/
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談は「お問い合わせ」からお気軽にお問い合わせください。
