Skip to main content

バグレポートをエンドツーエンドでデバッグする

Datadog のログとデータベースへのアクセス権を含むバグレポートを Devin に渡すだけで、根本原因の分析と修正を行う PR が返ってきます。
AuthorCognition
Categoryインシデント対応
FeaturesMCP
1

Datadog と連携する

Devin がバグに関連するエラーを検索できるようにするには、Datadog ログへのアクセスが必要です。まだ有効化していない場合は、Datadog MCP を有効にしてください:
  1. Settings > MCP Marketplace に移動し、Datadog を探します
  2. Enable をクリックし、次の 2 つのシークレットを設定します:
  3. Datadog インスタンスでカスタムサイト (例: datadoghq.eu) を使用している場合は、DATADOG_SITE も設定します
接続が完了すると、Devin はセッション内からログの検索、エラートレースの取得、デプロイとの問題の関連付けをすべて実行できます。完全なセットアップ手順については、MCP Marketplace を参照してください。
2

Devin にデータベースの読み取り専用権限を付与する

データ関連のバグ（値の誤り、フィールドの欠落、クエリの不具合など）の場合、Devin がデータの状態を直接検証できると、効果が飛躍的に高まります。読み取り専用の接続文字列を Secret として設定します:
  1. Settings > Secrets に移動し、新しいシークレットを追加します:
    • Name: DATABASE_READ_REPLICA_URL
    • Value: postgresql://readonly_user:password@read-replica.internal:5432/production
  2. 次のようなメモを追加します: 「本番環境のリードレプリカへの読み取り専用接続。SELECT クエリ専用で安全。」
または、Settings > MCP Marketplace でデータベース MCP（PostgreSQL、MySQL など）を接続します。Devin はどちらの方法でもデータに対してクエリを実行できます。
常にリードレプリカ、または SELECT のみが許可されたユーザーを使用してください。Devin がバグを調査する際に書き込み権限が必要になることはありません。高コストなクエリがパフォーマンスに与える影響が気になる場合は、Devin の接続先を本番データベースとは分離された専用のリードレプリカ、または既存の分析用レプリカに設定してください。
3

Devin にバグレポートを送信する

バグレポートをそのまま Devin セッションに貼り付けてください。発生し始めた時期、誰に影響しているか、何が問題か、どこで発生しているかなど、報告者が提供しているコンテキストをできるだけ多く含めます。体系的に調査したい場合は、!triage テンプレートプレイブック を使い、複製して自分のスタック向けに手順をカスタマイズしてください。レポートが具体的であればあるほど、Devin はより早く答えを見つけられます。「金曜日のデプロイ以降」と書くことで、Devin は Datadog の時間範囲を絞り込めます。「Pro plan users」と指定することで、どのレコードをクエリすべきかを正確に指示できます。
4

Devin が調査し、修正します

Datadog とデータベースへの接続が完了すると、Devin は一連の詳細な調査を実行します:Datadog のログを取得 — 金曜日以降の課金サービスのエラーを、サービス名とエラーステータスでフィルタリングして検索します。デプロイ当日の 18:12 UTC 以降に、TypeError: Cannot read property 'name' of undefined の発生が急増していることを突き止めます。データベースをクエリ — リードレプリカに対して SELECT id, company_name, plan FROM users WHERE plan = 'pro' LIMIT 20 を実行します。Pro ユーザーには company_name の値が 存在する ことを確認します。データ自体は正常なので、バグはコード側にあります。コード変更をトレース — git log --since="2026-02-13" を確認し、ユーザー API レスポンスをリファクタリングして company を organization にリネームしたコミット a1b2c3d を特定します。src/pages/billing/BillingHeader.tsx の課金ページは依然として user.company.name を参照しています。修正を実装 — BillingHeader.tsx を更新して user.organization?.name ?? 'Your Company' を使用するようにし、古い API レスポンス形式と新しい形式の両方でコンポーネントをレンダーするリグレッションテストを追加します。ブラウザで検証 — dev サーバーを起動し、Devin の組み込みブラウザで課金ページを開き、テストユーザーで会社名が正しく表示されることを確認します。PR を作成 — 修正内容とテスト、そして根本原因と影響範囲（すべての Pro と Enterprise ユーザー、約 350 アカウント）を説明する記述を含む PR を作成します。
5

フォローアップ

修正用の PR がマージされたら、Devin に関連する問題を洗い出したり、モニタリングを追加したりするよう依頼できます。今回の調査でわかったことのうち、次回以降も Devin に覚えておいてほしいことがあれば、そのまま伝えてください。例：“Remember that the user API uses user.organization, not user.company.” Devin は、あなたが確認して保存できる Knowledge エントリを提案します。こうしておくことで、今後のセッションは、あなたのチームがすでに学んだコンテキストを最初から持った状態で始められます。