Article by: Paul Jaffre（読了時間：11分）
最近、さまざまな形でこの質問を受けることが増えました。主に Seer のプレビューウェビナーでのことです。参加者は違っても、聞かれることはだいたい同じです。
- 「Seer を使うべきですか？それとも MCP をエージェントにつなぐだけで十分ですか？」
- 「すでに Cursor を使っているなら、Seer を使う意味はありますか？」
- 「Claude Code に Sentry からデータを取ってこさせれば、それで済むのでは？」
3つまとめて、ここでお答えしておきたいと思います。
正直なところ、自分のためにも一度書き出しておく必要がありました。周りの状況は目まぐるしく変わっていて、答えも週を追うごとに複雑になっているように感じます。この記事では、それぞれの選択肢が何なのか、どのようなときにどれを選ぶべきかという違いを整理してみます。
要約： Seer、Sentry MCP（エージェントプラグインでセットアップ）、Sentry CLI、そしてコーディングエージェントとのインテグレーションは、競合する選択肢ではありません。目的に応じて、それぞれ異なる形でデバッグのワークフローを改善できます。問題はどれが一番かではなく、それぞれが他にはない何をしてくれるのかを知ることです。
まずは3つの問いから
1. どのように問題を診断していますか？
汎用エージェントに生のスタックトレースやイベントデータを渡すやり方でも、単純なバグなら対応できるかもしれません。しかし、それは診断とは別物で、アプリケーションの重要なコンテキストが抜け落ちています。Seer はエラー、トレース、ログ、プロファイル、連携したリポジトリをまとめて推論し、根本原因を突き止めます。チームやエージェントは、その結果をもとに対応できます。
2. コードを書くのは誰ですか？
まだご自身でコードを書いているかもしれません。職人技の光る手作り品を物々交換する Etsy ショップを開く日も近いかもしれませんが。あるいは、Seer の計画をクラウドエージェント（Claude、Cursor、GitHub Copilot）に渡し、普段使っているエージェントに実装を任せることもできます。受け渡しの手間を省きたければ、Seer 自身に PR を作成させることも可能です。
3. デバッグ中にいくつの場所を行き来していますか？
Sentry UI、Slack、コーディングエージェント、ターミナル。Seer Agent は最初の2つをカバーし、エージェントプラグインと MCP はコーディングエージェントやエディタに、CLI はターミナルに Sentry を持ち込みます。目指すのは、すでに使っているツールに Sentry を組み込むことです。自動化や Webhook 駆動のパイプラインを加えれば、それらがつながり、誰かがノートパソコンを開く前にドラフト PR が用意されている状態になります。
Seer：何が起きたのかを Sentry に突き止めてもらう
Seer は Sentry 独自のデバッグエージェントです。エラー、トレース、プロファイル、ログ、コードベースなど、Sentry のあらゆるテレメトリに深く連携した形でアクセスできます。データを取ってくるだけでなく、すべてをもとに推論し、なぜ壊れたのかを教えてくれます。
Seer Agent：何が問題なのかまだわからないときに
Seer Agent は Slack や Sentry UI で動くチャットインターフェースで、Sentry インスタンス全体を対象に推論できます。
たとえば、次のような質問が得意です。
- 「昨夜のデプロイ後に急増し始めたものは？」
- 「直近のリリースに入ったコミットと PR は？」
- 「未解決のイシューのうち、どれから先に直すべき？その理由は？」
- 「このトレースのレイテンシについて順を追って説明して」
Seer Agent は代わりにアクションを実行することもできます。
- 「チェックアウトの p99 が2秒を超えたらアラートを出すように設定して」
- 「過去7日間のこれらのデータベースエラーについて、新しいダッシュボードを作って」
- 「アカウント内で最も遅いスパンを見つける Explore クエリを作って」
- 「これをモバイルチームに再アサインして、理由をコメントで追加して」
その他の例は Seer Agent ユースケース Cookbook で紹介しています。
Slack では複数人で使えます。チームの誰でもスレッドに参加して、コンテキストを補足したり、調査の方向を変えたりできます。だからこそ、インシデント対応中に本当に役立ちます。すでに3人が同じチャンネルに集まって、どこで火が出ているのかを突き止めようとしている、そんな場面です。
Sentry で Slack インテグレーションを追加し、任意のチャンネルで @Sentry とメンションするか、Sentry の任意のページで Ask Seer をクリックすれば始められます。
Sentry UI では、Seer Agent との1対1の会話になります。コンテキストも把握していて、Sentry のどのページを開いているかを理解しているので、トレースを見ながら「これの原因は？」と聞けば、「これ」が何を指すのかをすでにわかっています。
/videos/posts/seer-mcp-cli-or-coding-agent/seer-agent-ask-seer.mp4
Autofix：問題のあるイシューから PR の作成まで
イシューが Sentry に届くと Seer が分析します。設定に応じて、根本原因や修正計画が用意されているか、レビュー待ちのドラフト PR が用意されている状態になります。
- イシューを開き、Seer Autofix の下にある Start Analysis をクリックします。Seer は自律的に動き、エラー、スタックトレース、分散トレース、スパン情報、構造化ログ、プロファイル、パフォーマンスメトリクス、連携リポジトリのコードを集めます。
- 完了すると、評価済みの根本原因が表示されます。エラーを投げたフレームだけではなく、実際に何が原因だったのかです。ショッピングカートのチェックアウト失敗が、実は2つ先のサービスにあるデータベースインデックスの欠落だった、といったことがわかるかもしれません。
- そこから、計画をコーディングエージェントに渡して実行させるか、Seer に修正を書かせて PR まで作成させるかを選びます。この受け渡しについては後ほど詳しく説明します。
Seer はクリック操作なしで自動実行することもできます。過去14日以内に10件以上のイベントがあり、修正可能性スコアがしきい値を超えたイシューで起動します。根本原因の特定後、計画の作成後、PR のドラフト作成後のどこで止めるかを設定できます。
すでにエージェントを使ったワークフローを本格的に取り入れているなら、Seer はエージェント向けに文書化済みのコーディング規約を読み込みます。AGENTS.md、CLAUDE.md、Cursor や Windsurf などのルールファイルにも対応しています。規約を新しい場所に書き直す必要はなく、Seer の修正はコードベースの他の部分と同じスタイルに仕上がります。
コーディングエージェント：Seer の計画を普段使っているエージェントに渡す
Autofix の最後のステップはコード生成ですが、これを Seer が担う必要はありません。コーディングエージェントを連携していれば、Seer は根本原因と解決策の計画を構造化されたプロンプトにまとめ、代わりにそのエージェントを起動します。
作業はローカルマシンではなくエージェント自身のクラウド環境で行われるので、エディタを開いておく必要すらありません。API キーの設定といった基本的な構成は、Sentry と連携するコーディングエージェントによって異なります。結果として返ってくるのは、レビュー用のブランチまたはドラフト PR です。使うエージェントに応じて、クラウドエージェントのセッション内や PR コメントで修正を重ねたり、ローカルで作業を引き継いだりできます。
この方法が向いているのは、実際にコードを実行しながら修正したほうがよい場合、修正が複数のリポジトリに関わる場合、あるいはチームですでに特定のエージェントに作業を回していて、こうした修正も同じ流れに乗せたい場合です。
Slack のアラートから修正を開始する
Slack では、アラートチャンネルに新しい Issue が届くと、スレッド内に Fix with Seer ボタンが表示されます。このボタンは Sentry の Seer 自動化設定に従って動作するので、ブラウザのタブを開く必要はありません。Autofix に作業させる前に、ここで Seer Agent に問いかけて、イシューのより詳しいコンテキストを確認することもできます。
手元のツールで Sentry を使う：MCP と CLI
ここで紹介するのは、Sentry のデータを普段作業している環境に取り込むための方法です。Sentry が持つ本番環境のインテリジェンスと、エージェント、ターミナル、パイプラインとをつなぐ橋渡し役になります。
Sentry Agent Plugin は、コマンド1つで MCP を接続し、さらに関連するスキルや機能を通じてツールに MCP の使い方を教えるセットアップ方法です。新しい Sentry CLI はターミナル向けのツールです。自然言語で話しかけるだけで、環境から対象のプロジェクトを判断し、ID の代わりにシンプルなセレクタを受け付けます。ブラウザを使わず、数回のキー入力で Seer の分析にアクセスできます。
どちらも Seer なしで動作しますが、Seer を有効にするとはるかに便利になります。生のイベントデータを取得するだけでなく、エージェントが根本原因分析をフルで実行し、構造化された診断結果を受け取れるようになるからです。
エージェントプラグイン：セットアップの手間を省く
MCP は Claude Desktop、Claude Code、Codex、Cursor、Amp、VS Code with Copilot、Warp、Windsurf、Vercel v0 のほか、OAuth とリモート MCP をサポートするあらゆるツールで動作します。
すでに AI コーディングツールを使っているなら、手動で接続する必要はありません。次のコマンドを実行します。
インストーラーがマシン上のコーディングツールを検出し、使いたいものを選ぶと、それぞれにプラグインを組み込みます。すでにインストール済みの場合は、同じコマンドで最新バージョンに更新されます。反映させるため、実行後にツールを再起動してください。
ただし、MCP の接続は簡単な部分にすぎません。このプラグインを使う価値は、一緒についてくるものにあります。それが Sentry のスキルライブラリで、ツールが必要なときに読み込む指示のセットです。
これが一番効いてくるのはセットアップです。プロジェクトに Sentry を追加するようエージェントに頼むと、フレームワークを検出して適切な SDK をインストールし、Sentry が管理する指示とリファレンスを使って、スタックに合った機能を有効にします。同じライブラリで、デバッグのワークフロー、アラート設定、OpenTelemetry、コードレビュー中に Seer が残した PR コメントへの対応もカバーしています。
たとえば、次のような依頼ができます。
一部のワークフロースキルでは、PR コメントの読み取りと返信のために GitHub CLI（gh）のインストールも必要です。全体が sentry-for-ai でオープンソースとして公開されているので、スキルの追加や修正も可能です。チーム全員が同じ動作になるようにスキルのバージョンを固定したい場合は、dotagents をご覧ください。
それでも MCP を手動でセットアップしたい場合は、mcp.sentry.dev からローカルにインストールせずに接続するか、MCP 互換のクライアントで次のように追加できます。
https://sentry.io/issues/CHECKOUT-P1 を修正して」）、MCP がスタックトレース、イベントの詳細、タグを取得し、エージェントがそれらをもとに作業できます。単純なバグなら、これで十分なことも多いです。Seer を有効にしている場合は、まず MCP 経由で Seer の分析ツールを呼び出すようエージェントに頼みます。Seer が完全な診断を行って構造化された結果を返し、エージェントはそのコンテキストを踏まえたうえで修正を実装します。コーディングエージェントやエディタから一度も離れる必要はありません。
CLI：ターミナルから離れずに Sentry を使う
Sentry CLI は自然言語で操作できる新しいコマンドラインツールで、人間にもエージェントにも使いやすいように作られています。DSN、.env ファイル、作業ディレクトリから組織とプロジェクトを特定するので、スラッグを覚える必要も、フラグを調べる手間もほとんどありません。@latest や @most_frequent といったセレクタを使えば、ID を探しに行かなくてもイシューを指定できます。
sentry issue explain はターミナル上で Seer の分析を表示し、plan はその続きを引き継ぎます。まだ分析が実行されていなければ、先に分析を実行します。
シェルコマンドを実行できるエージェントであれば、MCP に対応していなくてもこれらすべてを使えます。また、データ系のコマンドはすべて --json に対応しているので、スクリプトや CI ジョブで出力を活用できます。
ハンズフリー：ここまでの機能をすべてつなげる
ここまで紹介した選択肢は、基本的に人間が介在する前提です。今回の方法では、レビューの準備が整うまで人間の関与をなくし、オンコールのあり方を変えます。
仕組み自体に新しい要素はありませんが、Seer を中心に据えることでワークフローの信頼性が高まります。まず Seer の自動化が、Autofix のフローと同じようにトリアージを開始します。次に、Webhook が完成した診断結果を、すでに使っている自動化パイプラインに引き渡します。そしてコーディングエージェントが完了済みの根本原因分析を受け取り、足りない部分を MCP で補い、修正を書いてテストを実行し、ドラフト PR を作成します。あとはレビューしてマージするだけです。
Seer はループの中にとどまり、本来の役割を果たし続けます。複数のサービスに散らばった本番環境の問題、つまり夜も眠れなくなるような問題を解決するのに必要な深いコンテキストをすべて提供します。エージェントがスタックトレースだけを頼りに推論して行き詰まることもありません。
Cursor や Factory といったチームは、すでにこの仕組みのバリエーションを本番環境で運用しています。Cursor のクライアントインフラチームは、Sentry のクラッシュデータをもとに日次のループを構築し、メモリ不足によるクラッシュ率をピーク時から最大80%削減しました。アプリの安定性向上のおよそ30%は Sentry によるものだとしています。Factory のエージェントは、人間が一度もブラウザを開くことなく、Sentry のエラーにエンドツーエンドで対応しています。全体像は自己修復するソフトウェアをチームがどう構築しているかで詳しく紹介しています。
結局どう使えばよいのか
私が何度も立ち返るのはこの点です。ほとんどのツールは何が壊れたかを教えてくれます。Seer はファイルを1つも開かないうちに、スタック全体からなぜ壊れたのかを教えてくれます。実際、Seer に Seer 自身の障害をデバッグさせたこともあります。42,000件のエラーをたどってリージョンのブロックリスト処理のバグを突き止め、通常のモニタリングでは決して見つからなかった6行のコードの欠落にたどり着きました。
ほとんどのチームは、Seer とエージェントプラグインがあればすべてをカバーできます。アラートの量が多いチームやオンコールの負担に悩むチームにとっては、自動化パイプラインが最も効果を発揮します。
Seer が診断して自分で直す。Seer が診断してエージェントが直す。PR のレビューまで誰も関わらない。受け渡しの形は使いやすいものを選び、結果に応じて調整していけば大丈夫です。
どの形を選んでも、土台は同じです。診断が正しくなければなりません。間違った根本原因に対して見事な修正を出すエージェントは、エージェントがいないよりも悪い結果を招きます。迷っているようであれば、14日間の Seer トライアルを始めて、たまっているバックログを試してみてください。トライアル終了時に料金が発生することはありません。
FAQ
■ Claude Code や Cursor にすでに Sentry MCP を入れている場合でも、Seer は必要ですか？
単純なバグであれば、必要ないかもしれません。エージェントに Issue の URL を渡し、MCP にスタックトレースやイベントの詳細を取得させて修正を書かせる。それで十分機能します。
Issue が複雑になるほど、話は変わってきます。MCP がエージェントに渡すのはデータ、Seer がエージェントに渡すのは診断です。複数のサービスが関わるリグレッションで、根本原因がエラーの発生箇所から数ステップ離れている場合、生のイベントデータしか持たない汎用モデルでは、正しいリポジトリ、正しいファイル、正しい変更を特定するのに苦労するでしょう。何よりもコンテキストが重要です。Seer はまさにその関連付けを行うために作られています。
両方を組み合わせて使ってください。まず Seer を実行し、そのあとエージェントに修正を実装させます。自分のワークフローから離れることなく、Seer が診断を、エージェントが実装を担当します。本当に時間を節約できるのは、このワークフローです。
■ Sentry UI とコーディングエージェントのプラグイン、どちらを使うべきですか？
思っているほど差はありません。npx @sentry/ai install を実行すると、デバッグ用のスキルとともに Sentry MCP サーバーがセットアップされ、Claude Code、Cursor、Codex、Grok から直接 Seer の根本原因分析を呼び出せるので、Sentry を開く必要はまったくありません。基盤となるインテグレーションは同じなので、あとは好みの問題です。
ただし、この場合、次の2つはコーディングエージェントでは利用できません。
- 自動化 — Seer は分析する価値のある新着Issueを選び、根本原因をIssueに残します。誰かが開く前に作業が完了しているわけです。ルーティンで似たようなことはできますが、その場合はトリアージのロジックを自分で考える必要があり、結果もチームが普段見る場所ではなく、そのルーティンが保存した場所に置かれることになります。
- Seer Agent — 「Ask Seer」の対象は、エディタやハーネスで指定した範囲に限りません。組織内のすべてのプロジェクト、リリース、トレースを対象にでき、Sentry 内でも、インシデント中にチーム全員が参加できる Slack スレッドでも会話できます。
■ Seer はパフォーマンスの問題にも対応していますか？それともエラーだけですか？
両方に対応しています。Seer はエラーとパフォーマンスの問題をカバーしており、どちらを診断する際もプロファイルとパフォーマンスメトリクスを推論の材料にしています。
■ Seer の料金はいくらですか？また「アクティブコントリビューター」とは誰のことですか？
アクティブコントリビューター1人あたり月額40ドルで、使い放題です。アクティブコントリビューターとは、Seer が有効なリポジトリで、1か月に2件以上のプルリクエスト（GitLab の場合はマージリクエスト）を作成した人を指します。リポジトリが Sentry に接続され、Seer の機能が1つ以上有効になっていれば、そのリポジトリは Seer 有効とみなされます。カウントは毎月末にリセットされ、現在の人数は Subscriptions ページで確認できます。Seer を利用するには Sentry の有料プランが必要です。終了時に料金が発生しない14日間の Seer トライアルもあります。
■ Seer の動作は変更できますか？
はい。Seer がアクセスできるリポジトリの範囲を制限したり、PR の作成などの扱いを調整したりできます。詳しくは Seer Autofix のドキュメントをご覧ください。
■ 要件や制限はありますか？
まとめると次のとおりです。
- Autofix — GitHub.com と GitLab.com のクラウド版のみ。
- コーディングエージェントへの受け渡し — GitHub のみ。Seer が必要です。
- Seer Agent — オープンベータ。組織全体を対象にクエリを実行するうえ、まだ細かなアクセス制御がないため、組織で Open Team Membership が無効になっている場合は利用できません。Slack では、Sentry アプリを最新バージョンに更新してください。
- 自動化のトリガー条件 — 過去14日以内に10件以上のイベントがあり、修正可能性スコアがしきい値を超えていること。設定した停止ポイントより先に進むことはありません。
- セルフホスト — MCP 自体はセルフホストのインスタンスを参照できますが、Seer のツールは利用できないため、該当するスキルは無効にする必要があります。
- プラン — Seer には有料プラン（Team、Business、Enterprise）が必要です。
Original Page: Seer, the Sentry MCP and CLI, or your own coding agent: where each one fits
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談は「お問い合わせ」からお気軽にお問い合わせください。
