Skip to main content
Sentry インテグレーションの詳細なガイドについては、こちらをご覧ください。
1

Sentry MCP を有効にする

Devin がトリアージ中にスタックトレース、ブレッドクラム、イベントメタデータを取得できるようにするには、Sentry アカウントへのアクセス権が必要です。
  1. Settings > Connections > MCPサーバー に移動し、Sentry を探します
  2. Enable をクリックし、あなたのプロジェクトにアクセスできる Sentry アカウントで OAuth フローを完了します
  3. 接続をテストします — セッションを開始し、プロジェクトの 1 つについて最近の Issue を一覧表示するよう Devin に依頼します
接続が完了すると、Devin はあなたのアカウントからアクセス可能な任意の Sentry プロジェクトに対してクエリを実行できます。Issue の詳細、完全なスタックトレース、イベントのブレッドクラム、リリースタグなどを取得できます。セットアップの詳細については、MCP Marketplace ドキュメント を参照してください。
2

Sentry の内部インテグレーションを作成

Sentry は Internal Integrations を通じて webhook を配信します。Sentry ダッシュボードで Settings > Developer Settings > Custom Integrations に移動し、Create New Integration > Internal Integration をクリックします。次のように設定します:
  • Name: Devin Auto-Triage
  • Webhook URL: 次のステップでデプロイするサービス (例: https://your-domain.com/sentry-webhook)
  • Alert Rule Action: on に切り替え — このインテグレーションがアラートルール内のアクションとして利用可能になります
  • Permissions: Issue & EventProject への読み取り権限
インテグレーションを保存したら、アラートルールを作成します。プロジェクトで Alerts > Create Alert Rule > Issue Alert に移動します:
  • When: 新しい issue が作成されたとき
  • If: その issue に 1時間50 件を超える event がある場合 (トラフィックに応じて調整してください)
  • Then: Devin Auto-Triage 経由で通知を送信します
3

Webhook を Devin API に接続する

Sentry のアラートペイロードを受け取り、Devin セッションを開始する小さなハンドラを作成します。Settings > Service UsersManageOrgSessions 権限を持つサービスユーザーを作成し、そのトークンをハンドラの環境変数 DEVIN_API_KEY に保存します。DEVIN_ORG_ID には組織 ID を設定します。組織 ID は、トークンを指定して GET https://api.devin.ai/v3/enterprise/organizations を呼び出すことで取得できます。
HTTPS トラフィックを受信できる任意の場所 (Cloudflare Worker、AWS Lambda、または小さな VPS など) にデプロイします。Sentry の Internal Integration の webhook URL としてこのエンドポイントを指定してください。上記のコードは、各セッションに sentry-auto-triage と Sentry プロジェクト名のタグを付けます。これにより、Devin のダッシュボードでこれらのセッションをフィルタリングし、tags クエリパラメータを使って API 経由で取得 できるようになります。プロジェクトごとに Devin がトリアージしたエラー数を追跡するのに便利です。パイプラインが動作していることを確認するには、Sentry でテストアラートをトリガーするか (一時的にしきい値を下げてから) 、app.devin.ai を開き、新しく sentry-auto-triage がタグ付けされたセッションがあるかどうかを確認します。
4

各アラートに対してDevinが行う対応

新しいエラーがしきい値を超えて webhook が発火すると、Devin がセッションを開始し、次のように問題へ対処します。
  1. MCP 経由で Sentry にクエリを送信 — フルスタックトレース、breadcrumb (クラッシュに至るまでのユーザー操作履歴) 、影響を受けたブラウザ / OS / リリースタグ、およびイベント頻度を取得します
  2. 根本原因を特定 — スタックトレースの該当行のソースファイルを読み、データフローを追って値が undefinednull になっている理由を把握します
  3. 的確な修正を作成 — 既存のコードベースのパターンに合わせたエラーハンドリング (オプショナルチェイニング、デフォルト値、入力バリデーション) を実装します
  4. リグレッションテストを追加 — 元のクラッシュシナリオを再現するテストケースを作成し、その修正で再発が防げることを検証します
  5. PR を作成 — PR の説明に Sentry の issue の URL を記載し、レビュアーが元のエラーコンテキストとイベントボリュームを突き合わせて確認できるようにします
PR 説明の例:
5

プレイブックと Knowledge でトリアージを強化

パイプラインが稼働し始めたら、自動トリアージをさらにスマートにしましょう。トリアージ用のプレイブックを作成する。 まずは !triage テンプレートプレイブック から始め、複製したうえでチームのエラーハンドリング規約 (エラーバウンダリ、null チェックパターン、ログ形式) に合わせてカスタマイズします。その後、リクエストボディに "playbook_id": "your-playbook-id" を追加して、webhook ハンドラーからプレイブック ID を渡します。また、トリアージワークフローの説明からプレイブックを生成するよう Devin に依頼することもできます。API コントラクトや既知のエッジケースに関する Knowledge を追加する。 例: “/api/users からのレスポンスでは、オンボーディングを完了していないユーザーに対して { profile: null } が返される場合があります。必ずこのケースを考慮してガードしてください。” 既存ドキュメントから Knowledge エントリを作成するのを Devin に支援させましょう。Devin がドメインについて持つコンテキストが多いほど、修正はより正確になります。アラートのスコープを慎重に設定する。 Sentry のアラートルール条件を使って、どのエラーで Devin を起動するかを制限します — プロジェクト、環境 (production のみ) 、エラーの発生数などでフィルタします。よい出発点としては、インパクトの大きいエラーに集中できるよう、最初の 1 時間で 50 件以上のイベントが発生した課題のみを対象にトリガーする設定です。週次レビューのスケジュールを設定する。 スケジュール を作成し、週に 1 回実行して自動トリアージセッションの結果をレビューし、その学びをプレイブックと Knowledge にフィードバックします: