【要約】Sentry エラーを Claude API で自動修正してみたら、3-Retry が効いた話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
単発のLLM呼び出しでは、以下の課題が発生する。
- ・エラー箇所を
dict.get()等で握りつぶす不適切な修正。 - ・コンテキスト不足により、呼び出し元や依存関係を無視した修正。
- ・修正後のコードが既存テストを破壊し、CIが失敗する事態。
// Approach
以下の2つの仕組みで解決を図る。
1.3-Retryによるフィードバックループ
- ・最大3回まで「修正→テスト実行→結果をプロンプトへ追加」を繰り返す。
- ・会話履歴を保持し、失敗の経緯をLLMに理解させる。
2.依存関係グラフによるコンテキスト拡張
- ・
astを用いてimportを解析。 - ・BFS（幅優先探索）で関連ファイルを最大100件まで収集。
- ・リポジトリの構造や型定義をLLMに提示し、修正の的確性を高める。
// Result
導入後の成果は以下の通り。
- ・3回までの最終的な修正成功率が向上。
- ・修正の方向性が改善し、根本原因へのアプローチが可能に。
- ・CIでのテスト失敗件数が減少。
- ・APIコストは増大するが、エンジニアの工数削減効果が上回る。
Senior Engineer Insight
> LLMを単発の回答者ではなく、デバッグの対話相手として扱う設計は極めて実戦的だ。コンテキストを最大100ファイルまで広げる判断は、トークンコストよりも推論の質を優先した賢明な選択と言える。ただし、APIコストは試行回数とコンテキスト量に比例して増大する。運用においては「3回で諦める」といった、コストと精度のトレードオフを制御する仕組みが不可欠だ。