シグナル：自己修復するソフトウェアの鍵

Agent（エージェント） — モデルは急速に優秀になり、いまや基本的に「買う」ものになりました。ただしそれ単体では十分ではありません。速く何かを成し遂げることは、それが正しく、あるいは最善のやり方で成されたことを意味しないからです。モデルが正解にたどり着くのは、適切なコンテキストを与えられたときだけです。そして、エージェントの足を引っ張っているのがモデル自身であることは、めったにありません。

Harness（ハーネス） — 診断された修正をマージまで運ぶための配管であり、エディタ、CI、Slack、そして開発者自身のエージェントといった、開発者がすでにいる場所に届けるための仕組みです。これを構築するのは本物のエンジニアリングです。最も難しいのは修正を書くことではなく、それを検証することです。コードがコンパイルを通りテストが通ったことではなく、ユーザーが実際に踏んだ障害が消えたことを確かめなければなりません。そして、指し示すべき「真実」がなければ、そのどれもが機能しません。

Signal（シグナル） — ソフトウェアが自らを修復するには、まず自分が壊れていることを知らなければなりません。理論の上ではなく、現実世界で、です。あらゆるテストを通過したコードが、一晩で更新されたブラウザでは崩れ、広告ブロッカーがあなたのドメインを遮断した環境では動かず、一度もテストしていない端末で失敗する。その破綻はコードの中にはありません。あなたのリポジトリを見つめるだけのモデルには、それを見つけることはできません。そこには存在しないからです。それは、あなたが作ったものと、ユーザーが実際に体験しているものとの間にあります。エージェントは直感ではなく、シグナルに基づいて動きます。適切なコンテキストがなければ、推測に頼るしかありません。修正を試し、失敗し、また試す。本来なら避けられたはずの試行に、時間と費用を費やしてしまいます。一方、十分なシグナルがあれば、エージェントは賭けをやめ、何が、誰に対して、どのリリースから壊れたのかという実際の診断に基づいて行動します。

本当に希少なのはシグナルです。知性は買うことができ、ハーネスは作れます。しかしシグナルだけは、現実世界で本当にソフトウェアが壊れた、その瞬間からしか得られません。それこそがモデルを有用にし、ハーネスを現実に即したものにします。そしてこれこそ、Sentryが10年以上かけて築いてきたものです。

実際にどう動いているのか

これは予測ではありません。ご存じの 3 社が、すでにこのループを回しています。

Cursor は、いまや多くのエンジニアが一日中開きっぱなしにしている AIエディタを作っています。それだけ多くのプロセスと、それだけ長いセッションをまたいでデスクトップクライアントを安定させるのは難しく、壊れるときは本番環境で壊れます。そこで Cursor のクライアントインフラチームは、Sentry のクラッシュデータの上に日次の自動化を構築しました。Sentry からシグナルを取り出してエージェントに渡し、どの機能が壊れたのか、そしてスタックトレースが本当に修正可能な根本原因を指しているのか、それともたまたま近くで動いていただけのコードなのかを問います。エージェントの確信度が十分に高ければ、第2のエージェントを呼び出して修正案を作成させます。自動マージは一切ありません。すべての PR に人間のレビューが入ります。

最も頻発する障害であるメモリ不足によるクラッシュについては、このループによって発生率をピーク時から最大 80% 削減できました。アプリ安定性の改善のうち 30% が Sentry によるものとされています。

Factory はさらに一歩進んでいます。同社の製品は Droid と呼ばれる自律エージェントの集団で、実際のエンジニアリング業務をこなします。そして Sentry を、それらのエージェントが依拠する本番環境のコンテキストとして組み込んでいます。エラーが発生すると、Droid が issue を取得し、影響を受けたユーザー数を確認し、セッションをリプレイし、修正案を提示します。人間が一度もブラウザを開くことなく、です。同じことが顧客自身の Sentry 環境の中でも起こります。Droid がエラーを読み、根本原因をたどり、多くの場合そのままプルリクエストを作成します。Factory はプラットフォーム全体で、8 つのプロジェクトにわたり月間数億件のイベントを処理しています。

調子の悪い日には、こんなことが起こります。あるリリースの後、リリースされたばかりのコードパスから発生した missing-index エラーを Sentry が検知しました。修正内容、つまりそのクエリが必要としていたインデックスそのものが、エラーの中に含まれていました。そのため Factory のインシデントエージェントはインデックスを作成し、数分で issue を解決しました。Factory の Alvin Sng は、Droid にとってエラーは容易にアクセスできるものであり、エンドツーエンドで自律的に処理できると語っています。

Ramp は Inspect という独自のバックグラウンドコーディングエージェントを構築しました。そして最も難しい部分、すなわち検証に意識的に取り組みました。Inspect はコードを書くだけでなく、その変更が正しく機能することを証明するところまでループを閉じます。しかも Ramp のエンジニアが使うのと同じコンテキストとツールを使ってです。Sentry はそのツールの 1 つとして組み込まれており、エージェントは推測ではなく本番環境のテレメトリを確認できます。

Sentry を利用する数千社が、同じパターンを目にしています。シグナルが診断を運びます。エージェントは推測ではなく、それに基づいて動きます。人間は修正を探し回るのではなく、修正をレビューします。Factory の言葉を借りれば、モニタリングはエンジニアが開くダッシュボードであることをやめ、エージェントが消費するインフラストラクチャになるのです。

何が変わるのか

ソフトウェアを作り始めて以来ずっと、信頼性は人間が供給するものでした。コードが壊れ、人間がそれに気づき、手を止めて修復する。その仕組みが終わろうとしています。シグナルが十分に良質であれば、ループは自ら閉じます。破綻は実際のユーザーに届いたその瞬間にシグナルとして捉えられ、何が誰に対して壊れたのかというコンテキストの中で理解され、推測ではなく実際の診断に基づいてエージェントによって修正されます。そして人間のもとに届くのは、せいぜい承認すべき修正だけです。チケットもなく、スプリントもなく、ストーリーポイントもなく、キューで待ち続ける PR もなく、独立した QA フェーズもなく、リリーストレインもありません。

多くのチームが静かに払い続けてきたコストがあります。最も優秀な人材が、最も価値ある時間を、次を作ることではなくバグの追跡に費やすというコストです。そのコストは、もはや避けられないものではなくなります。そして、そこで生まれた余力が失われることはありません。その余力は、何を作るかを決め、それを作るという、本当に価値を生む仕事へと振り向けられます。

これらはすべて、シグナルなしには成立しません。自律的な「壊れる→直す」のループの質は、本番環境で何が壊れたのかをどれだけ理解しているかによって決まります。そしてその理解こそが希少な要素であり、既製品として買うことも、コードベースだけから生成することもできないものです。ソフトウェアが現実世界と出会ったその瞬間に、現実世界から捉えるしかありません。それこそ Sentry が存在してきた期間をかけて築いてきたものであり、Cursor、Factory、Ramp のエージェントが自らの仕事を検証し解決するためにすでに Sentry に依拠している理由です。Sentry はシグナルのレイヤーを担っています。自己修復するソフトウェアとは、そのシグナルが可能にするものであり、それはすでにここにあります。