【Seer・Sentry MCP・CLI】それともコーディングエージェント？それぞれの役割と使い分け
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 […]
【Seer Agent】大型アップデート
Article by: Peter McCarron（読了時間：4分） Sentryプロジェクトのあらゆる情報に問い合わせできるフレンドリーなAIエージェント、Seer Agentをリリースしてから、今日（2026年9月30日）でちょうど5か月になります（厳密には5か月と1日前ですが、誤差の範囲ということで）。その間、社内でもSeer Agentとたくさん会話してきました。最近SNSでそのやり取りを見かけた方もいるかもしれません。Seer Agentは今や、デバッグのワークフローや機能改善のプロセスに欠かせない存在です。 目標は一貫して、Seer Agentにもっと多くのことを任せられるようにすることでした。より多くのタスクをこなし、より多くのデータを集め、真っ先に頼れるデバッグアシスタントになること。今回、その目標に一歩近づく新機能を発表できることを嬉しく思います。 Sentryプロジェクトでできることが増えました これまでSeer Agentは、主に情報を集めるためのツールでした。もちろん、Seer AgentのアラートからSeer Autofixを起動することはできましたが、Sentry上で代わりに操作してもらおうとすると、たいていこんな返答が返ってきていました。 これではもどかしいですよね。データにアクセスでき、その使い方もわかっているのに、なぜ手伝ってくれないのか。でも、これからは手伝ってくれます。Seer AgentがSentry APIを直接操作し、ユーザーに代わって書き込み操作を実行できるようになりました。Seer Agentに任せられることの例をいくつか紹介します。 カスタムダッシュボードとウィジェットの作成 モニターとアラートの作成 Issueのアサイン、解決、アーカイブ ExploreクエリとIssueビューの保存 これだけ機能が増えると、Seer Agentにどんな権限があるのか気になるかもしれません。Seer Agentの権限は、デフォルトでユーザー本人と同じレベルに設定されています。適切な書き込みスコープが確認できない場合は、タスクを実行する前に明示的に許可を求めます。また、この権限は1回のチャットを超えて持ち越されないため、Sentry組織への恒常的なアクセス権をSeer Agentに与えてしまう心配もありません。 より多くのソースからデータを収集 Seer Agentを紹介した記事でも触れたとおり、アプリケーションで起きる問題が、必ずしもSentry内のIssueとして表れるとは限りません。フロントエンドにもバックエンドにも多くの構成要素があるため、エージェントが限られた範囲でしか動けないと、何が問題だったのかを正確に突き止めるのは難しくなります。 Seer Agentは、Sentry内のさまざまなデータを結び付けて全体像をつかむのが得意です。ただ、問題を完全に診断するには、アプリケーションの外にある情報が必要になることもあります。ネットワークに問題はないか。データベースがボトルネックになっていないか。ホスティングのリソースを使い切っていないか。こうしたデータはSentryでは取得しません。そもそも、そのために作られたものではないからです。 とはいえ、これらが重要な情報であることに変わりはありません。そこで、Seer Agentがインフラのデータも取り入れてIssueを診断できるようにしました。 まずはDatadogとGoogle Cloud Platformから、新しいSeer Connectors画面で外部の監視プラットフォームをSeer Agentに直接接続できるようになりました。Seer Agentはそれらのツールのデータを読み取って診断に活かし、アプリケーションのフロントエンドとバックエンドの両面から分析を検証できます。 接続の設定について、1点注意があります。現時点ではOAuthに対応していないため、代わりにAPIキーが必要です。接続を設定するSentry管理者が、必要な環境へのアクセス権を持っているか、必要なキーを受け取っているかを事前に確認しておくとよいでしょう。 ラバーダックからフルタイムのアシスタントへ 今回のアップデートは、Seer Agentにとって大きな進化です。これまでSeer Agentは、デバッグのラバーダックとして力を発揮してきました。Issueについて話したり、アプリケーションのパフォーマンスを掘り下げたり、質問に答えたりと、何でも気軽に相談できる壁打ち相手です。誰でもときには良いラバーダックが必要ですが、それが最終的なゴールだったわけではありません。思い描いていたのは、インシデントが起きたその瞬間だけでなく、日常的にサポートしてくれるフルタイムのデバッグアシスタントとしてのSeer Agentです。 では、実際にはどういうことなのか。新しい機能によって、たとえば次のようにSeer Agentとやり取りできるようになります。 「Seer、Sentryプロジェクトを確認して、Issueを深刻度ごとに整理してください。優先度を更新して、それぞれのIssueを最も関係の深いエンジニアにアサインしてください」 「Seer、すべてのSentryプロジェクトをまとめて見られるダッシュボードを作ってください」 […]
【エージェントトレーシング】 AI 検索アシスタントをデバッグする
Article by: Dominik Buszowiecki , Shaun Kaasten（読了時間：4分） Sentry に送られてくるデータをユーザーに最大限活用してもらうには、そのデータを簡単に見つけられるようにすることが重要です。私たちのチームは、検索クエリやフィルターを使って特定のイベントを探し出し、データを閲覧しやすくする機能を開発しています。検索バーでは、検索語を指定するだけでデータを見つけられます。 検索には Sentry Search Syntax を使いますが、これがユーザーにとって障壁になることがあります。そこで、最近の他のツールと同じように、自然言語で検索語を指定したいというユーザーもいます。そうしたニーズに応えるため、自然言語のプロンプトを Sentry Syntax の検索語に変換する Search Query Assistant を開発しました。 出力は非決定的なため、応答の性能を高め、測定するために eval を使っています。 必要な作業は2つです。中心となるユーザーシナリオの eval を書くこと、そしてそれを実行して、エージェントが正しいクエリをどれだけ生成できるかを確認することです。エージェントが期待どおりのクエリを一貫して生成できれば、それで完了です。 次のシナリオに進みます。クエリが誤っているときは、エージェントが何を見て、何をしたのか、そしてどうすれば正しい答えに導けるのかをデバッグします。 失敗した eval をデバッグする eval をローカルで再現してデバッグできる場合もあります。特定のデータが存在していることに依存しない場合やモックのツール呼び出しだけで問題を診断・修正できる場合です。そうしたケースでは、結果を確認するのに簡単なツールで十分です。たとえば、LLM の生成結果やツール呼び出しの JSON 出力を見る、といった具合です。 ただ、挙動がもっと複雑な場合もあります。ツール呼び出しから返ってくる特定のデータ、使用する LLM モデルのバージョンの違い、あるいはインフラのエラーが原因になっているケースです。そうした場合には、Sentry の AI Conversation ビューがデバッグに役立つツールになっています。 実際のクエリ生成バグ エンドツーエンドのテストを行っていたとき、指定したフィールドが数値型のカスタム属性である場合に、クエリが結果を返さないことに気づきました。 たとえば、あるショッピングサービスが、購入時にカート内の商品数を数えるカスタム属性を付けてイベントを送信しているとします。ユーザーはその数が10より大きい購入イベントをすべて見たいと考えるかもしれません。ところが検索アシスタントを使うと、イベントが1件も返ってきませんでした。 AI Conversation を見つける API エンドポイントのエラーをデバッグするなら、まず Sentry […]
【Agent Tracing と Claude Routines】エージェントトリアージの自動化
Article by: Trevor Elkins（読了時間：4分） 毎朝、チームの誰かがダッシュボードを見るよりも前に、Claude Routine はすでに前夜の会話を約800件、Seer（Sentry のエラーをトリアージして修正する AI エージェント）から読み込んでいます。おかしそうな会話にフラグを立て、新しく見つかったものについてはチケットを起票します。私たちがコーヒーを片手に席に着くころには、トリアージはほとんど終わっています。 課題 このルーティンが存在する前は、エージェントの挙動を確認するには、現在の eval システムからデータを取り出すための、場当たり的で使い捨てのフローが必要でした。クエリの選択肢は限られていたため、その大半は各 trace の生の JSON を解析するパーサーを自前で用意することに帰着していました。誰かが分析を実行することを覚えておき、手動でやらなければなりませんでした。自動化するという選択肢もありましたが、手間がかかるため結局着手できずにいました。さらに、私たちはこのデータを日々使っている他のツールにも送りたいと考えていましたが、当時の構成にはそうした連携性がありませんでした。 私たちが探していたのは、さまざまなものが入り混じったものでした。tool call の失敗、hallucination による出力、レイテンシのスパイク、必要以上に長く続いてしまうエージェントのループ、コストの異常。要するに、全部です。 主な目標は3つ。tool error を減らすことで信頼性を高めること、異常な実行のロングテール（通常より極端にコストがかかったり、一般的な会話よりはるかに多くの tool call を行ったもの）に目を配ること、良さそうに見える会話をサンプリングして、良いと決めつけるのではなく実際に良いことを確認することです。 Claude Routine このルーティンは Claude Routine として毎朝実行されます。Sentry MCP（Claude が Sentry に直接クエリを実行できるようにする Model Context Protocol server）を介して接続し、前夜の会話に対して Agent Tracing のクエリと、いくつかの一般的なクエリを実行します。 各実行は同じ手順を踏みます。 1. 期間の集計統計を取得する。つまり、夜間にどれだけの会話が実行されたか。 2. tool の集計統計を取得する。つまり、いくつの tool […]
Sentry で自動デバッグのワークフローを構築
Article by: Dhrumil Parekh（読了時間：6分） これからは AI が大量のコードを生み出し、それにともなってバグも大量に生まれていきます。これはもう分かりきったことですし、これまでにも触れてきました。より大きな課題はエージェントが書いた不具合だらけのコードの修正に、時間をすべて奪われずに済むようにすることです。 そうした問題をより簡単に修正できる仕組みが必要になります。幸い、自動化ワークフローを構築するためのソリューションは、世の中にたくさんあります。 Sentry では最近、デバッグと Issue のトリアージのプロセスを自動化する方法を模索してきました。自分でも試してみたいという方のために、その過程で得たヒントや学びをいくつか共有できればと思います。 すべては「何が・なぜ壊れているか」を知ることから始まる AI に問題を解決してもらうなら、まずは問題が発生したタイミングを把握する必要があります。当然ながら、Sentry では Sentry を大いに活用しています。アプリケーションをインストルメントして、あらゆるシグナルやメトリクスを出力できるようにしており、システムの稼働状況を詳細に把握できるようになっています。 ご想像のとおり、その分 Issues ページはかなり埋まりがちで、トリアージに多くの手作業が発生します。そこで登場するのが、AI を活用したデバッグエージェント Seer です。Seer の autofix は、コアの Sentry、ドキュメント、MCP サーバー、CLI ツールなど、いくつもの Sentry プロジェクトと、それぞれに対応する GitHub リポジトリに設定しています。 さらに Seer には、問題の根本原因を突き止め、修正計画を立て、PR（プルリクエスト）を自動で作成する権限も与えています。組織によっては、機械をそこまで信頼する準備が整っていないかもしれませんが、問題ありません。人間がプロセスに加わるまでに Seer をどこまで進ませるかは、自分で制御できます。自動化の目的はエンジニアの手作業を減らすことであり、エンジニアの人数を減らすことではありません。 PR の自動生成は便利ですが、ここで新たな疑問が生じます。レビューすべき PR があることを、どうやって知ればいいのか。そして、誰がレビューすべきなのか、という問いです。 レビューのためのルーティンをつくる 自動化で難しいのは、たいていタスクそのものの難易度ではなく、規模が大きくなるにつれてそれらのタスクをどう管理するかです。エージェントがコード修正のような小さな作業をこなせるのは便利ですが、その真価はシステム全体にもたらす効率にあります。私たちの場合、いまや Seer が大量の新しい PR を生成しています。では「最高委任責任者（Chief Delegation Officer）」のような新しい役職をつくらずに、それらをきちんと処理するにはどうすればいいのか。答えは「さらにエージェントを増やす」です。 このプロジェクトを始めたとき、注力した領域は2つありました。 1. […]
Seer のおかげでバグ57個が1個に
Article by: Dan Mindru（読了時間：16分） ゲスト投稿：Dan Mindru。インディー開発者、エンタープライズ向けのコンサルタント、Morning Maker Show の共同ホストでもあります。複数のオープンソースプロジェクトを手がけ、Crontap、Saventify、そのほか10社ほどのスタートアップの創業者です。 先日、歯医者で予約の順番を待っていたときのことです。待合室はやたらと豪華で、椅子はどれも別々のいかにも値の張るデンマーク人デザイナーの作品に見えました。これは相当ふんだくられるな……と覚悟し始めたそのとき、愛用のメールアプリから通知が届きました。 ＊＊＊ ポーン ＊＊＊ 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 の分野でいくつもの要素が噛み合い、バグ修正の経済をすっかり塗り替えたと、確信しています。 モデルの知能 […]
エージェントはあなたが見ているものを理解すべき
Article by: Mihir Mavalankar（読了時間：6分） Sentry の Seer Agent を使うと、Sentry 内のデータについてどんな質問でも投げかけ、そのデータを深く掘り下げ、Issue をより速く修正できます。 特に面白い機能の1つが、Sentry で今まさに見ている内容について直接質問できるものです。たとえば「このレイテンシの急上昇は何が原因？」や「このエラーの顧客別・リージョン別の内訳は？」といった質問です。こうした質問に答えるには、エージェントはその瞬間にあなたが Sentry の中で見ているものを、同じように見て理解しなければなりません。そのコンテキストを正しく捉えることは、実は非常に大きな意味を持ちます。答えの質だけでなく、コスト、会話の長さ、そして最終的にエージェントがあなたに代わって行える作業の幅にも関わってくるからです。 シンプルなアプローチ ─ ASCIIスナップショット 少し前まで、Seer は現在のページを理解するために、DOM 要素をスクレイピングして、いわばテキストで描画したスクリーンショットのようなものを取得していました。画面に見えているすべてを、1文字ずつの ASCII グリッドとして捉えるのです。粗い方法ですが、機能はします。人がピクセル化された画像に目を凝らして、おおよその形を認識できるのと同じように、エージェントもそのグリッドを見て、ページに何があるかを推測できます。 しかしこのアプローチには、互いに重なり合う3つの問題があります。 トークンコスト：ASCII グリッドは大きなものです。1つのダッシュボードや Issue フィードのページで、平均して数千トークンを消費することがあり、一部のページでは p95 の計測値が 50k トークン以上に達しました。どの会話にも少なくとも1つはページのスナップショットが含まれ、ユーザーがチャットの途中でビューを切り替えれば、その数はさらに増えます。このコストはエージェントにとって実際に有用な量ではなく、画面に表示されている量に比例して増えていきます。 コンテキストの劣化（context rot）：私たちは主に Claude Sonnet やそれに類するモデルを使っています。能力とコストのバランスが良いためです。これらのモデルはデフォルトで 200k トークンのコンテキスト長を持ち、それをシステムプロンプト、ページのコンテキスト、会話履歴、ツール呼び出しの結果で共有します。それが埋まっていくにつれて、モデルの性能は低下します。前のほうのやり取りが押し出され、エージェントは何を尋ねられたのかを見失い、応答の一貫性が失われていきます。 より豊かなインタラクションへの道がない： ASCII グリッドは何が見えているかは説明できますが、何が可能かは表現できません。「’Edit’ をクリックすればこのウィジェットを変更できる」といったヒントを付与する構造もなければ、どの要素が操作可能かを示す方法もなく、エージェントがあなたに代わってページを直接操作するような将来のエージェント的アクションの土台もありません。 以前はこのような見た目でした。（注：データはダミーのプレースホルダーに差し替えていますが、雰囲気は伝わるはずです。すべてが一度に詰め込まれた大きな壁のようなものでした。） 新しいアプローチ ─ 自らを説明するページ ASCII のスクリーンショットに代えて、私たちは各ページがエージェントに対して実質的に自らを説明できる、構造化されたコンテキストシステムへと移行しました。核心となる変化は、何をエージェントに見せるかを誰が決めるのかという点にあります。各 UI コンポーネントは自分が何であり、どんな状態にあり、エージェントに伝える価値のあることは何かを把握していて、その情報を直接提供します。 […]
Apple のアップデートによる不具合 ─ ユーザーより先に気づくための仕組み
Article by: Dan Mindru , Oleh Stasula（読了時間：9分） 本記事はフロントエンド開発者兼デザイナーであり、Morning Maker Show の共同ホストも務める Dan Mindru によるゲスト投稿です。Dan は現在、PageUI、Clobbr、CronTool をはじめとする複数のアプリケーションを開発しています。 リリースのたびに、綱渡りをしているようなものです。アプリは軽量で安定していなければならず、高いパフォーマンスも維持しなければなりません。その一方で、いつ予告なく変更されるか分からないAPIにも依存しています。160万ダウンロードを超えた今、私たちには品質を維持する責任があります。小さなチームでありながら、App Storeで4.7という評価を保ち続けられていることを誇りに思っています。では、それをどう実現しているのでしょうか。 答えはシンプルです。Sentryを使って築いたセーフティネットです。 本記事では、ユーザーが気付く前にクラッシュを修正する方法から、ビルドの問題を早期に検出する方法、さらにスタックトレースだけでは分からないユーザーの状況を把握する方法まで、私たちがSentryをどのように活用しているのかをご紹介します。 前提を整理する 今回取り上げるアプリは Usage という、iPhone・iPad・Mac で動作するシステムアクティビティモニターです。デバイスがCPU・メモリ・ネットワーク・ディスク・バッテリー・グラフィックスといったリソースをどのように使っているかを追跡します。これに加えて豊富な履歴データが得られることから、自分のデバイスを細かく把握したいパワーユーザーに人気があります。 これには、いくつもの難しさがあります。 Usageの役割はデバイスの動作を監視しながら、自らがその負荷にならないことです。この一見単純な要件が、少し変わったエンジニアリング上の制約を生みます。機能を追加するたび、依存関係を増やすたび、タイマーを1つスケジュールするたびに、その処理はユーザーに提供したい価値そのものとリソースを奪い合うことになります。自分自身のチャートに表示されてしまうシステムモニターなど、誰も望みません。 しかも、それはまだ序章にすぎません。足場そのものも安定していないのです。必要なデータの一部は、Appleが公開された代替手段を提供していないため、ドキュメント化されていないAPIに頼らざるを得ません。つまり、OSのアップデートによってデータ構造が予告なく変わり、どのデバイスでも、どのタイミングでも動作しなくなる可能性があります。非推奨になるという通知が届くわけでもありません。そのため、常に注意を払い続ける必要があります。 さらに、Usageは単一のプロセスではありません。メインアプリ、メニューバーアプリ、バックグラウンドサービス、そしてウィジェットが協調して動作する構成になっています。それぞれが独自のライフサイクルを持ち、障害もそれぞれ異なる形で発生します。そこで、各コンポーネントを個別のSentryプロジェクトとして構成し、それらを1つのワークスペースにまとめています。こうすることで、クラッシュやエラーは発生したプロセスに正確にひも付けられたまま、システム全体の健全性を一か所で把握できます。 こうした環境で、アプリ全体を軽快かつ高いパフォーマンスのまま維持するのは簡単ではありません。そのため私たちは、Sentryが提供するさまざまなツールを活用しています。 Crash Monitoring — あらゆる機能の土台となる基盤です。 Error Monitoring — OSアップデートによって依存しているデータ構造が変わることで起きるような、静かな失敗を検出します。 Size Analysis — ビルドごとの差分を追跡し、問題のあるリリースを見逃さないようにします。 Metrics — 最適化の取り組みが実際に成果を上げているかを測定し、検証します。 User Feedback — ユーザーがアプリ内から直接フィードバックを送れる窓口です。 それぞれをどのように使っているか、順に見ていきましょう。 Crash Monitoring クラッシュモニタリングは基盤です。どんなアプリにも必要であり、本記事の後半で紹介する […]
eval に下せない判断のために、エージェントのトレースを読む
Article by: Sergiy Dybskiy（読了時間：7分） ユニットテストを書くことにわくわくしていた（あるいは、キャリアの段階や勤め先によっては憂鬱だった）頃を覚えているでしょうか。あるいは、ユーザーが遭遇するユースケースをすべて網羅していると確信していた E2E テストや統合テストで、細部に汗を流していた頃を。 最近では、多くの UI が 1 つの入力フィールドと、UI と同じ価値を届けると約束するエージェントへと、少しずつ置き換わりつつあります。しかも「Jarvis」のようなエレガントさと駄洒落っぽさをまとって。 私たちは SOUL.md を練り、MEMORY.md を練り、システムプロンプトを練ります。ユーザーが実際にエージェントとやり取りする方法とは違うと分かっているプロンプトで eval を組み立て、それでも分かっているふりをします。しきい値を設定し、確信度スコアが満足のいく値で返ってくれば、承認してデプロイする。これで仕事は完了ですよね？ いえ、そうとも限りません。 Sentry は今週 AI Engineer World’s Fair に参加しており、私は参加者が自分の予定を組み立てられるよう、エージェント付きの小さなスケジュールビルダーを作ることにしました。（スピーカー、トーク、トラックのデータ、さらには embedding まで提供してくれた Swyx に感謝します。） ある程度スケールさせたかったのですが、AI SDK と Vercel の AI Gateway のおかげで、匿名の訪問者にはオープンウェイトで非常に安価なモデルを、サインアップしたユーザーにはより強力な SOTA 級のモデルを使うようエージェントを設定するのは、かなり簡単でした。 ツール呼び出しと優れたシステムプロンプトがあれば、小さくても賢いモデルがハルシネーションを起こすはずがない、ですよね？？ 「有名な登壇者は？」 このアシスタントにはルーターがあり、各質問を読んで「info」パスと「search」パスのどちらかに振り分けます。 私の登壇者に関する質問は info パスへ送られました。このパスが持つデータツールは getTracks ただ 1 つで、getTracks […]
シグナル：自己修復するソフトウェアの鍵
Article by: Milin Desai（読了時間：7分） いま、この業界の歴史上かつてないほど大量のコードが書かれています。1 年分のソフトウェアが 1 か月で生み出されるようになり、しかもその大半はもう人間が書いたものではありません。GitHub COO の Kyle Daigle は先日、こう述べています。 2025年のコミット数は10億件でした。現在は週2億7,500万件のペースで増えており、このまま線形成長が続くとすれば、今年は140億件に達する計算です（もっとも、線形成長のままにとどまるとは考えにくいですが）。 Anthropic、Cursor、OpenAI のコーディングエージェントは、スタックトレースを読み、絡み合ったコードを追い、人間が該当ファイルを見つけるより速く実際に機能する修正を書き上げます。この「速さ」こそ、いま誰もが語っている物語です。しかし、それ以上に重要なのは、コードがリリースされた後に何が起きるかです。 コードの量が増え、リリースが速くなるほど、実際のユーザーのもとへ届く不具合も増えていきます。そして、壊れたソフトウェアは技術的な問題であるだけでなく、ビジネス上の成果を左右する問題でもあります。顧客は離れ、解約し、その理由を周囲に語ります。Sentryは20万の組織にわたり、年間594兆件のイベントを処理しています。これこそが、自己修復を支える、他では得られないコンテキストです。つまり、ソフトウェアが実際に壊れた、その瞬間の記録です。ソフトウェアが現実世界と出会うことで生まれる、生のシグナルなのです。 だからこそ、いまソフトウェアは、これまで越えたことのない一線を越えつつあります。本番環境で、自らを修復し始めているのです。エラーを検知して人間のトリアージへ回すだけでも、修正案を提示して作業を人間に委ねるだけでもありません。自ら壊れていることに気づき、その理由を理解し、修正を書きます。もちろん、すべてが自動化されているわけでも、完全に実現しているわけでもありません。単純で原因の明らかな障害は自動的に解消される一方で、アーキテクチャ上の判断や複雑なインシデントは、依然としてエンジニアが担います。そして、その境界線は毎月動いています。この業界の歴史を通じて、信頼性は人間が担うものでした。それがいま、ソフトウェア自身の性質へと変わりつつあります。 業界はこれを自己修復するソフトウェア（self-healing software）と呼びます。もはや仮説ではありません。Sentry 社内でも、私たちが協働するチームの間でも、本番環境での実践は日ごとに現実味を増しています。これは、その意味を理解しているチームとそうでないチームとをはっきりと分ける転換点です。 何が必要か ここに到達するには 3 つの要素が必要でした。買うもの、自分で作るもの、そしてもう 1 つは自ら勝ち取らなければならないもの。実はすべてがこの 3 つ目に懸かっています。 Agent（エージェント） — モデルは急速に優秀になり、いまや基本的に「買う」ものになりました。ただしそれ単体では十分ではありません。速く何かを成し遂げることは、それが正しく、あるいは最善のやり方で成されたことを意味しないからです。モデルが正解にたどり着くのは、適切なコンテキストを与えられたときだけです。そして、エージェントの足を引っ張っているのがモデル自身であることは、めったにありません。 Harness（ハーネス） — 診断された修正をマージまで運ぶための配管であり、エディタ、CI、Slack、そして開発者自身のエージェントといった、開発者がすでにいる場所に届けるための仕組みです。これを構築するのは本物のエンジニアリングです。最も難しいのは修正を書くことではなく、それを検証することです。コードがコンパイルを通りテストが通ったことではなく、ユーザーが実際に踏んだ障害が消えたことを確かめなければなりません。そして、指し示すべき「真実」がなければ、そのどれもが機能しません。 Signal（シグナル） — ソフトウェアが自らを修復するには、まず自分が壊れていることを知らなければなりません。理論の上ではなく、現実世界で、です。あらゆるテストを通過したコードが、一晩で更新されたブラウザでは崩れ、広告ブロッカーがあなたのドメインを遮断した環境では動かず、一度もテストしていない端末で失敗する。その破綻はコードの中にはありません。あなたのリポジトリを見つめるだけのモデルには、それを見つけることはできません。そこには存在しないからです。それは、あなたが作ったものと、ユーザーが実際に体験しているものとの間にあります。エージェントは直感ではなく、シグナルに基づいて動きます。適切なコンテキストがなければ、推測に頼るしかありません。修正を試し、失敗し、また試す。本来なら避けられたはずの試行に、時間と費用を費やしてしまいます。一方、十分なシグナルがあれば、エージェントは賭けをやめ、何が、誰に対して、どのリリースから壊れたのかという実際の診断に基づいて行動します。 本当に希少なのはシグナルです。知性は買うことができ、ハーネスは作れます。しかしシグナルだけは、現実世界で本当にソフトウェアが壊れた、その瞬間からしか得られません。それこそがモデルを有用にし、ハーネスを現実に即したものにします。そしてこれこそ、Sentryが10年以上かけて築いてきたものです。 実際にどう動いているのか これは予測ではありません。ご存じの 3 社が、すでにこのループを回しています。 Cursor は、いまや多くのエンジニアが一日中開きっぱなしにしている AIエディタを作っています。それだけ多くのプロセスと、それだけ長いセッションをまたいでデスクトップクライアントを安定させるのは難しく、壊れるときは本番環境で壊れます。そこで Cursor のクライアントインフラチームは、Sentry […]