8月13日、Sentryが「Automated agent triage with Agent Tracing and Claude Routines」と題した記事を公開した。Sentryが自社運用するAIエージェント「Seer」が夜間に処理した会話ログ約800件を、チームが出社する前に自動でトリアージする仕組みの構築事例だ。集計エラー率を眺めるだけでは見えなかった「リポジトリ名のハルシネーション問題」が、このルーティンによって初めて可視化された点が特に興味深い。
一晩800件のログを、チームが起きる前に処理する
Sentryのチームは毎朝、誰もダッシュボードを開く前に、前夜の会話ログ約800件のトリアージを済ませている。担当するのは人間ではなく、Claude Routinesで動く自動化ルーティンだ。
SentryはエラーのトリアージとAI自動修正を担うSeerというAIエージェントを自社で運用している。このエージェントが夜間に処理した会話ログを、翌朝のルーティンが読み込み、問題のある会話にフラグを立て、新規の不具合はLinearにチケットを起票する。コーヒーを飲み始める頃には、トリアージがほぼ完了している。
それまでの課題：手動・場当たり的・連携なし
このルーティンが存在しなかった頃、エージェントの動作確認には専用の一発スクリプトが必要だった。SentryがホストするLangfuseインスタンスからデータを引き出し、生のJSONトレースを手でパースするしかなかった。誰かがそれを「やらなければ」と思い出す必要があり、実行も手動だった。自動化しようという話は何度も出たが、摩擦の多さから実現できないままだった。
チームが把握したかったのは以下のような事象だ。
- ツール呼び出しの失敗
- ハルシネーションを含む出力
- レイテンシのスパイク
- 通常より長く続くエージェントのループ
- コストの異常
Claude Routineの構成：プロンプトは意図的にシンプルに
ルーティンの仕組みはシンプルだ。Claude Routines（AnthropicがClaude.aiに提供するスケジュール実行機能）として毎朝実行され、Sentry MCP（ClaudeがSentryに直接クエリを投げられるModel Context Protocolサーバー）を経由してAgent Tracingデータを取得する。Agent TracingはAIエージェントの会話・ツール呼び出しをトレースするSentryの機能で、スパン単位の詳細なログをClaudeが参照できる形で提供する。
実行ステップは毎回同じだ。
- 対象期間の集計統計（会話数など）を取得
- ツールごとのエラー率を集計
- エラーのあったツールのスパンをサンプリングして傾向を把握
- ツールエラーあり・なし両方の会話をサンプリングし、エージェントの最終判断と推論の整合性を確認
- Seerのコードベース自体を参照して文脈を補完
- 新規の知見を1本のレポートにまとめる
- Linearの既存チケットを検索し、未追跡のものだけ新規起票
プロンプトは意図的にシンプルに書かれている。データ取得はSentry MCPに任せ、Claudeには判断を担わせるという役割分担が設計の肝だ。
Use the Sentry MCP to look at the last 24hr of <product> conversations
and analyze the results. In particular look for errors that might be
happening during the <product_stage>, say if our tools are broken. But
also sample some success conversations as well to see if they look
correct with secondary inspection.
If you come across new findings/errors, record them in a Linear ticket
for the <linear_project> project.
実際の出力例：集計だけでは見えなかった問題を発見
ルーティンが出力するレポートの実例がこちらだ。
Analyzed the last 24h of <feature> conversations (~445-551 total,
~11k tool calls). No verdict-quality problems found — spot-checked
several conversations and the agent's reasoning was well-grounded,
correctly downgrading when it lacked repo access rather than
fabricating.
Did find an efficiency issue worth tracking: ~21% of conversations
(83/400 sampled) hit at least one tool error, mostly self-corrected
retries. Root causes:
Search Code sometimes gets fed malformed repo_name values (e.g.
appending a monorepo subpath onto the real slug, like
"foo/bar/applications/integrations" instead of "foo/bar"), causing
"repository not found" until it retries.
Two conversations showed 30-56s hangs before an opaque "internal
error" — a real backend latency signal worth an engineering look.
Filed Linear ticket AIML-123 with full details...
この例で検出された「リポジトリ名のハルシネーション問題」は、集計エラー率だけを見ても、1件ずつ会話を読んでも発見できなかった。集計でSearch Codeのエラー率が高いことを把握し、スパンをサンプリングして傾向を掴み、全体の会話を読んで構造を確認する、この3つが揃って初めて見えてきた問題だ。原因が分かれば対処は単純で、「エージェントにリポジトリ名を推測させず、最初から渡す」だけで解決した。
実運用で得た教訓
毎日回すことでフィードバックループが十分に速くなり、問題を発見した当日に修正が入るようになった。
実践的な知見として2点が強調されている。
1. 成功した会話もサンプリングせよ：ツールエラーのある会話だけを見ていると見落としが生まれる。エラーゼロの会話でも、推論と最終判断が食い違うケースがあり、それはサンプリングしないと気づけない。
2. プロンプトは判断に集中させよ：データ取得ロジックをプロンプトに書かない。Sentry MCPがクエリを担い、Claudeは読んで判断することに専念させると、出力の一貫性が上がる。
自分のエージェントに適用する方法
同様の仕組みを自分のエージェントに導入する場合、以下の3ステップが出発点になる。公式レシピにはステップバイステップの手順がまとめられており、MCP認証の設定方法や推奨プロンプトの雛形も確認できる。
- Agent Tracingをエージェントに設定する
- Sentry MCPを参照するプロンプトでClaude Routineを追加する
- Sentry MCPコネクタ（およびLinearなど）の認証を設定する
ステップバイステップの手順は公式レシピにまとめられている。
詳細はAutomated agent triage with Agent Tracing and Claude Routinesを参照していただきたい。
