Seer のおかげでバグ57個が1個に

GitHub のメール通知のスクリーンショット

GitHub に新しい Pull Request が来ています。でも、いつものとはどこか違う。どこから湧いてきたのか、まるで見当がつきません。どの自動化が引き金になったのかと慌てて考えるうちに、いやな想像が頭をもたげてきます……もしかして、ハッキングされた？！

コードタブを開いてみると、そこにあったのはまったく理にかなった修正でした。ユニットテストの更新まで、ひととおり揃っています。しかもリスクは低そうで、チェックもすべてグリーン。

歯科医がおそらく3度目に私の名前を呼ぶなか、私はパニックになり、（自分でもどうかと思いつつ）……私は「Squash and merge」を押してしまいました。スマホをポケットに戻し、歯科医にこうつぶやきます。「すみません、ちょっと集中してて…。」

どうせ直すつもりのなかったバグ

あなたは私なんかよりずっと頻繁に、歯医者から本番環境にデプロイしているかもしれません。それでも私にとって、これは大きな変化に感じられました。単にコードをマージした、という話ではありません。それが「安い」コードだったからです。自分が汗をかいたり、優先順位をつけたりする必要のなかったコードなのです。

いったい何が起きたのか。そもそも、あの PR はどこから来たのか。少しだけ待ってください。その前にバグと優先順位づけについて、正直な話をしておく必要があります。

本番システムに関わったことがあれば分かるとおり、Issue はどんどん積み上がり、いずれはバグのトリアージをする羽目になります。たいていはこんな問いを立てながら。

• 影響を受けるユーザーは何人か
• どんな影響があるか
• 直すのにどれくらいかかるか

これをもとに、ステークホルダーがバグに優先度を割り当てます。たいていの場合、「高」に満たないものはすべて、いわゆる「バックログ」行きです。

この世界に不慣れな方へ。エンタープライズでいう「バックログ（backlog）」とは、「Bottomless Abyss of Casually Kept, Long-Overdue Grievances（なんとなく放置された、とっくに期限切れの不満が沈む、底なしの奈落）」の略です。

とはいえ、そのバグを直すことに、<ここに CEO が夢中になっている機能名を入れる>と比べてどれだけのビジネス価値があるでしょうか。そのバグ1個が実際どれほどの害をもたらすというのか。なにしろ、もう何か月も付き合ってきたバグなのですから。

そう、このバグの運命は、優先度の高い機能と天秤にかけられた瞬間にすでに決まっていたのです。これは規律や意志の強さの問題ではありません。単純に、経済の問題です。新規顧客を大量に連れてくるかもしれない機能の追加と比べれば、バグ修正のコストはとても正当化できません。

そうして数年が過ぎると、（ご想像のとおり）バックログにはバグが57個たまっている、というわけです。これを1個まで減らした方法を、ぜひお見せしたいと思います！

バグ修正の経済が変わりつつある

ここまで書いてきたのは、これまで多くの企業に当てはまっていた話です。でも、もうそうではないと思っています。2026年の春ごろ、AI の分野でいくつもの要素が噛み合い、バグ修正の経済をすっかり塗り替えたと、確信しています。

• モデルの知能
• より大きなコンテキスト
• より優れたハーネスとツール呼び出し
• 新しい抽象化（スキル、フック、サブ／クラウドエージェントなど）
• より長く動き続けるエージェント

これらすべてが飛躍を生み、バグ修正の経済を「割に合わない」から「まあいいか、これもスプリントに入れちゃおう」へとひっくり返しました。

自分のすべてのシステムで Sentry を動かしておいてよかった、と心から思いました。というのも、いま挙げたものはすべて、コンテキストがなければ無価値だからです。十分なコンテキストさえあれば、たいていのバグ修正は、AI が直すことも、検証することも、造作なくこなせるようになります。そして Sentry は、そのなかでも最も濃く、最も価値のあるコンテキストを持っています。トレース、デバイス情報、ネットワーク、ログ——ほんの一例です。驚いたことに、Session Replayまでコンテキストに使うというのです。

hunted.space で起きたナビゲーションエラーの、Sentry 上の Issue。右側には Seer の Autofix が開いており、Session Replay を含む「Evidence（根拠）」フッターが表示されています。

ちょっとしたコツ：送るテレメトリ（トレース、プロファイル、ログ）が多いほど、その先の自動修正はどれも精度を増します。ぜひ Sentry で JavaScript のログを設定してみてください。

このコンテキストがあれば、仕事の3分の1は、指一本動かさないうちに片づいています。次の3分の1が、修正の実装。そして最後の3分の1が、その検証です。

理屈のうえでは、この3つの3分の1をすべて自動化できれば、たいていのバグは寝ている間に片づけられることになります。そして本記事で話したいのは、まさにそこです。いまやほとんどのバグは、自動で解決できると私は考えています。もしバグ修正が株式だったら、その株価は2008年のリーマン・ブラザーズよろしく急落するでしょう。ただし今回は、その暴落こそが朗報なのです。

では、その仕組みの作り方をお見せしましょう。

くつろぎながら、自分のバグを安く直す方法

正しいセットアップを選ぶには、まずバグの気持ちになってみる必要があります。いわば「バグになりきって考える」ことが求められるのです。

バグにも気持ちがある

バグはどれも平等、というわけではありません。気立てのいいバグは、洒落た髪型にサングラス。厄介なやつは、モヒカンにタトゥーです。おおまかに、バグは3つのカテゴリーに分けられます。

それぞれを詳しく見ながら、どうすれば最も安く直せるのかを探っていきましょう。

フレンドリーなバグ（Friendly）

直すのが簡単なバグたちです。独立していて、再現でき、検証もレビューも容易で、マージのリスクも低い。

例を挙げます。

• 不正なペイロードで API を呼び出してしまう
• null チェック漏れで、フィールドが空のときに例外を投げる
• off-by-one エラーで、リストの最後の要素が抜け落ちる
• モバイルでレイアウトが崩れる

とはいえ、油断は禁物です。見た目は無害でも、ユーザーにとっては強烈なストレスになり、サポートチケットの山につながることもあります。

嬉しいことにこの手のバグは、もう解決済みです。次のシンプルなセットアップで、まるごと自動化してしまえます。

1. ［前提］ 必要なコンテキストを得るために、アプリケーションに Sentry を追加する（Sentry のプラットフォーム設定ドキュメント）
2. GitHub リポジトリと連携する
3. Seer の設定を開き、プロジェクトを対応するリポジトリにひも付ける。Seer は、ここを読んで根本原因の分析とコード生成を行います。
4. 同じ設定ページで、Automation のステップを Stop after PR drafted（PR 作成後に停止） に設定する。

「Stop after PR drafted」は、3つある自動化レベルのなかで最も手離れのよい設定です。もっと早い段階で人の目を挟みたいなら、Root Cause 後（分析のみ）や Plan 後（修正案のみ、PR なし）で止めることもできます。

Seer の設定が見つからない場合は、組織の一般設定で「Generative AI Features」が有効になっているか確認してください。

これだけで、フレンドリーなバグはもう出てきません。実際にはどう回るのでしょうか。私の側から見ると、数日おきに PR が届くだけです。中身はたいてい、数行のコード修正。チェックがすべてグリーンかを確認して、マージボタンを押す。それだけで Sentry 側の Issue まで閉じてくれるので、私のように面倒くさがりな人ならきっと気に入るはずです。気の利いた点としては、Seer はルールファイル（Cursor や Claude Code など）を自動で読み取ります。そのため、分析も引き渡された先での修正も、あなた自身のエージェントと同じ規約に従ってくれます。

Sentry の側から見ると、もう少し込み入ったプロセスになっています。Issue は自動修正を「勝ち取る」必要があるのです。

• そのIssueに十分な数のイベントが記録されていて、まぐれでないことが明らかである
• そのIssueが最近のものである（現時点では、直近14日以内）
• そのIssueが十分な「修正しやすさスコア」を持っている。Sentry は解決のしやすさを見積もり、確度の高いものだけを先へ進めます

私の経験からいうと、これはつまりこういうことです。

• PR で埋め尽くされることがない。
• 届く PR は、たいてい文句なしの当たりである。

これを有効にするだけで、おそらくバグのかなりの部分がすでに片づいているはずです。なかなかすごいことです。では、もう一歩踏み込みましょう。

気難しいバグ（Grumpy）

もう少し手ごわいバグです。未知の要素が多く、たいていはより深い調査を必要とします。とはいえ、まだおおむね独立していて再現もでき、ただ修正が複数ファイルに及ぶようになった、という程度です。

例を挙げます。

• 2つの API 呼び出しのあいだで起きる競合状態で、低速な回線でしか現れないもの
• WebSocket の再接続後に状態が古いまま取り残されるもの
• 楽観的な UI 更新がリクエスト失敗時にロールバックされないもの
• ページ間でデータが変わったときに、項目を飛ばしたり重複させたりするページネーションのバグ

こうしたバグは、金銭的に正当化するのがぐっと難しくなります。たいていは「エッジケース」として片づけられ、優先度を下げられてしまいます。

ここで私が「でも、これも Seer が直してくれます」と書いて次の節に進むと思っているなら、それは外れです。正直に言うと、Seer だけでは直すことができません。Seer は素晴らしい「調査員」ですが、修正を適用して検証するための本格的な環境は持っていません。開発サーバーを立ち上げることも、データベースをつつくことも、フローを5ステップ進んだ先でバグを引き起こすボタンを押すこともできないのです。

ここまで来ればもう分かるはずです。エージェントが検証できないなら、そのタスクは終わっていないということです。

そこで気難しいバグでは、Seer には得意なこと（本番環境の濃いコンテキストを使った根本原因の分析）に専念してもらい、実際の修正は、環境を持っているエージェント——本格的なクラウドコーディングエージェント——に引き渡します。

現時点で選べるのは次のエージェントです。

• Claude Code、Cursor、GitHub Copilot。今後さらに増えていく見込みです。

この例では Cursor を選びます。セットアップは次のとおりです。

1. Sentry で、Settings → Integrations →「Cursor Agent」と進み、「Accept & Install」をクリック

注：Cursor には API 連携もあります。「Coding Agent」タグの付いたほうを選んでください。