横尾杏之介
セールスエンジニア
2026 年 8 月 20 日、Datadog Japan は Cursor との共催ウェビナー「AI チームメイトは開発体験をどう変えるか｜Datadog × Cursor で実現する自律的な DevOps」をオンラインで開催しました。
AI コーディングエージェントの普及によって、コードを「書いて出す」速度は劇的に上がりました。一方で、本番で問題が起きたときの調査 → 修正 → 検証のループは、いまも人手の作業として残っています。アラートが鳴ってから修正に着手するまでに 30 分から数時間。その 1 分 1 分、実際のユーザーが影響を受け続けています。
このウェビナーのテーマは、まさにその隙間を埋めることでした。Datadog が本番環境で起きている事実を示し、Cursor がコードを動かす。そのあいだを MCP がつなぐ —— 登壇は Cursor の Field Engineer : Amrita Venkatraman と、Datadog の Sales Engineer : Annosuke Yokoo。本ブログでは、当日の内容を振り返りながらお届けします。
なぜ「修正ループ」が課題なのか
冒頭、Datadog パートの問題提起として提示されたのが下図です。インシデント対応で最もコストが高いのは、修正そのものではなく その手前の調査フェーズ です。スタックトレースを読み、直近のデプロイと突き合わせ、ログを調査する。この作業は 30 分から数時間を占めます。
AI がコードを速く届ける時代には、修正ループも同じ速さで回さなければ追いつきません。そして必要なのは 2 つ ——「エラーによるユーザー / サービス影響を把握すること」と「高速な修正ループを持つこと」。この 2 点が、当日のセッション全体を貫くテーマになりました。
セッション 1：Cursor が変える開発体験
登壇者 : Amrita Venkatraman（Cursor - Field Engineer）
前半は Cursor の Amrita 氏によるデモセッション。ローカル / クラウド / Automations の 3 つの文脈で Datadog プラグインをどう使うか という軸で進行しました。
Cursor のプラグインとは「MCP と Skill をまとめたもの」
まず Marketplace から Datadog プラグインの中身が示されます。
「Cursor のプラグインとは、要するに MCP と Skill をひとまとめにしたもの、というだけです」
「Datadog、Figma、Atlassian のプラグインの良い点は、各サードパーティ自身が公開していることです」
プラグイン詳細画面では、Datadog MCP 経由で Cursor が使えるツールの一覧が表示され、個別に有効 / 無効を切り替えられます。たとえば「Datadog の Notebook を作成・編集させたくない」といった場合はそのツールだけをオフにできる。MCP がどこまで触れるのかを把握し、その場で制御できる仕組みです。
ローカル：顧客の不具合を Datadog のログから診断する
空のフォルダでチャットを開き、「team ID XXXXX の顧客が Cursor の Agents Window 上で問題を抱えている。原因を診断し、ログを確認して修正案を出してほしい」というプロンプトを投入。モデルには Cursor Grok 4.5 を選択しています（タスクに応じてモデルを自動振り分けする新機能 Cursor Router も紹介されました）。
実行が始まると、エージェントが Datadog プラグイン同梱の セットアップ Skill、可視化 Skill、さらに Amrita 氏自身の文体を再現するカスタム Skill を自動で呼び出していく様子が可視化されます。
Canvas：Datadog のデータが「生きたドキュメント」になる
同時に 2 本目のエージェントを起動し、「Cursor で最も一般的な顧客エラーを経営層に示したいので、そのデータを表す Canvas を作ってほしい」と依頼。2 つのエージェントをタイル表示にして並列で進捗を追う という使い方も紹介されました。
出来上がった Canvas には、操作可能なチャート、エラーコード、影響を受けたセッション数、エラー元の内訳が並びます。興味深いのは 1 本目のエージェントの挙動でした。
「Canvas を作ってとは明示的に頼んでいないのに、自分から作ってくれました。それで構いません」
さらに Canvas の一部をハイライトして「棒グラフに変えて」と指示すればその箇所だけが更新され、Publish で共有リンクを発行したあとも、Cursor 側で「円グラフに変更」→ Sync でブラウザ側に反映されます。
「Canvas の良さは、共有でき、変更がそのまま反映される『生きて呼吸するドキュメント』である点です」
そして、ここで種明かしがありました。
「今や Cursor の社員がスライドやビジュアルをチームで共有する新しい方法が Cursor Canvas です。そしてこのデータはすべて Datadog から取得したものです」
Canvas に描かれていたグラフは、Datadog MCP 経由で取得した RUM のユーザーセッション データでした。
Cloud Agents と Automations：アラートから PR まで
後半は自律実行の話へ。cursor.com 上の Cloud Agents はリモート VM で動くため、ローカル環境から切り離されます。
「このエージェントは起動すれば、ノート PC を閉じても動き続けます」「離席中も作業してくれますし、寝ている間も作業してくれます」
そして Automations（時刻またはイベントをトリガーに動く Cloud Agents）。デモでは 2 パターンが示されました。
1 つ目は Slack トリガー。alerts チャンネルの新着メッセージを起点に、コードベースにリグレッションが入っていないかを調査し、Datadog MCP でも既存の問題と照合したうえで、初期調査結果を Slack DM で送る、という構成をゼロから作成。
「誰かを叩き起こす代わりに、初期調査の結果を Slack DM で送ってもらいたいのです」
2 つ目は Cursor が実運用している 「Triage new Datadog error」。トリガーは Datadog の Webhook です。Datadog 側の設定手順（Integrations → Webhook → New → Cursor が発行した URL を貼り付け）もその場で実演されました。さらに Atlassian MCP で Confluence に実装方針を書く、Sentry とクラッシュを突き合わせる、といった マルチ MCP への拡張も示されています。
印象的だったのは Run History に残っていた実際の実行ログでした。Datadog の高頻度アラートを起点に、エージェントは次のように動いていました。
「Git の履歴と blame を調べ、原因と思われる PR を特定し、修正を実装し、テストで検証して、最後に誰でもマージできる PR を出しました」
セッション 2：Datadog と Cursor で実現する 3 つのユースケース
登壇者 : Annosuke Yokoo（Datadog - Sales Engineer）
後半は Datadog 側から、Cursor と組み合わせた 3 つのユースケースを紹介しました。
01. Error Tracking：エラーから修正まで最短で
Error Tracking は、類似する大量のエラーを 1 つの Issue にまとめてノイズを削減し、いつから発生しているのか・継続中なのか・どのくらいの頻度なのかを時系列で追跡します。ボリュームの急増や新規 Issue 発生時のアラートも設定可能です。
デモでは、Error Tracking で原因を特定してからパッチを当てるまでの流れを実演しました。
ここで Datadog / Cursor 両者の役割分担が明確になります。
Datadog（ランタイムの可視化）：クラッシュした瞬間の変数の値、エラーの原因となったデプロイ、影響を受けたユーザーやサービス
Cursor（コードベースの操作）：リポジトリを読み構造をたどる、関連コードを文脈込みで理解する、修正を生成し PR として発行する
その 2 つをつなぐのが MCP
02. Code Security：ゼロデイ時代のパッチマネジメント
2 つ目はセキュリティです。ここでは現状のデータが共有されました。2025 年頃から、CVE のおよそ半数は TTE（Time To Exploit）が 0 以下 —— つまり CVE が公表される前にすでに攻撃が観測されている、という状況です。
対応すべきパッチの数と頻度は加速度的に増える一方、従来の「事前検証 → 本番実装 → 影響確認 → 影響の修正」というサイクルには数週間かかります。ここがボトルネックです。
Datadog Code Security は SCA / SAST / IAST により、リポジトリから CI/CD、本番までを通してコードとライブラリをスキャンし、稼働環境のコンテキストを踏まえて対応優先度を提示します。デモでは、SAST で検出した脆弱性を「Fix with Cursor」から Cursor に転送し、MCP で調査したうえでパッチを適用。
適用後に Datadog 側の Finding が AUTO-CLOSED になることを確認し、さらに MCP 経由でパッチ適用後のレイテンシ増加とエラーレートの推移を Cursor の Canvas 上で検証 するところまでを、検知から検証まで通して見せました。
Cursor がパッチを作る。Datadog が本番環境の事実で確かめる。このループが、AI 時代のセキュリティ運用を速くする。
03. Agent Console：AI チームメイトも "タダ" ではない
3 つ目は Preview 機能の Agent Console。Cursor、Claude Code、GitHub Copilot など複数のコーディングエージェントを横断して、利用状況・コスト・生産性を一元的に可視化します。
AI エージェントを開発現場に迎えることは、新しいチームメイトを雇うことに近い判断です。どれだけ使われているのか、効果的な活用になっているのか、投資に見合っているのか。支出管理・利用状況の把握・ROI の証明を一箇所で行えることは、組織レベルで AI エージェントの導入を進めるうえで欠かせません。
セッションを通じて見えたこと
両セッションが最後に同じ結論に着地したことが印象的でした。
Datadog はランタイムを可視化し、Cursor はコードベースを操作する。そして両者をつなぐのが MCP。静的なコード解析だけでは「クラッシュ時の変数の値」も「先週のデプロイ以降に始まった」ことも分かりません。逆に、本番のテレメトリーだけを見ていても修正は生まれません。MCP はその受け渡しの層として機能します。
アラートの検知から、影響把握、修正案の作成、適用前後の検証まで —— このループを高速かつ安全に回せるようになったとき、AI エージェントは単なるコード生成ツールではなく、本当の意味での「チームメイト」になります。
参加者の皆さまからの反響
当日は多くのご質問とフィードバックをいただきました。
「Datadog により開発過程を可視化することで脆弱性の検知が容易になり、Cursor による AI コーディングで脆弱性の修正が自動化・迅速化されるメリットを実感できました」
「Cursor での具体的な利用方法を見れたので、積極的に活用していきたいと思います」
また、「Bits AI と Cursor のチャット、どちらから修正を行うのが適しているか」「Error Tracking の画面から Cursor へ連携するにはどう設定すればよいか」といった、実践に踏み込んだご質問も多くいただきました。ご関心をお寄せいただき、ありがとうございました。
最後に
Datadog と Cursor の組み合わせは、「AI がコードを速く書けるようになった」その先にある、運用のループそのものを速くする取り組みです。今回のウェビナーが、皆さまの開発体験が変わるきっかけになれば幸いです。
Datadog では、今回のようなイベント・ウェビナーを定期的に開催しています。Datadog のイベント・ウェビナー一覧から、日本語開催のものを絞り込んでご確認いただけます。ぜひご参加をご検討ください。
Datadog をまだお使いでない方は、14 日間の無料トライアルからお試しいただけます。
