Article by: （読了時間：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 コンポーネントは自分が何であり、どんな状態にあり、エージェントに伝える価値のあることは何かを把握していて、その情報を直接提供します。
この設計はいくつかの原則に沿っています。
- 視覚的ではなく、意味的に：エージェントが受け取るのは、グリッド座標上の文字ではなく、「編集モードのダッシュボード、production に絞り込まれた8つのウィジェット」といった意味です。こちらのほうが送信コストが低く、推論もしやすくなります。
- 組み合わせ可能でコンパクトに： 各コンポーネントは、タイトル、モード、フィルター、主要な値といった自身の事実をボトムアップで提供します。装飾は省かれ、新しいページは中央部分に手を加えることなく差し込めます。
- より多くのインタラクションを可能に：ページを説明するのと同じチャネルが何が操作可能かというヒントを運ぶことができ、やがては逆方向へ流れる指示も運べるようになります。これにより Seer はページをただ読むだけでなく、ページに対して働きかけられるようになります。
現在はこのような見た目になっています。
内部ではルートに置かれた React のコンテキストプロバイダーが、ノードのフラットなレジストリを保持しています。コンポーネントは自身を高階コンポーネントでラップすることで、この仕組みに参加します。マウント時にそのラッパーはノードを登録し、コンテキストから最も近い親ノードを読み取って階層関係を確立します。ネストはReact のコンポーネントツリーから自然に得られます。ダッシュボードの内側にレンダリングされたウィジェットは手作業の配線なしに、自動的に子ノードになります。そのうえで各コンポーネントはフックを使って、タイトル・モード・有効なフィルター・主要な値といった自身のデータを自分のノードへと送り込みます。エージェントがメッセージを送ると、フラットなレジストリはネストされたツリーへと組み立てられ、JSON へシリアライズされ、システムプロンプトに入る前にバックエンドで Markdown へ変換されます。まだ参加していないコンポーネントは、ASCII スナップショットにフォールバックします。
従来のアプローチでは関連しているかどうかにかかわらず、見えているものすべてをLLM に適さない形式で送っていました。新しいアプローチでは、狙いを定めたツール呼び出しのきっかけに使える構造化された形で、有用な情報だけを送ります。ページは自らを簡潔に説明し、エージェントがさらに多くの情報（テーブルの全行、特定のウィジェットの詳細、チャートの背後にある生データなど）を必要としたときには、ページ全体のコンテキストを前もって支払う代わりに、必要に応じてそれを取得します。
実際にどう変わったのか
会話そのもののために、より多くのコンテキストを残せる
構造化コンテキストは現在、Sentry でよく閲覧されるページの多くで稼働しており、それらのページで計測したトークンへの効果は大きなものです。
変更前、ページのコンテキストはシステムプロンプトの平均85〜93%を消費していました。意味的なコンテキストを使うと、その割合は対象ページ全体で50〜80%まで下がり、平均トークン数もページによって大幅に減少します。ダッシュボードでは、ページコンテキスト部分のトークンが平均で約5,500から約1,300へと減りました。最も閲覧される Issue 詳細ページでは、その削減幅はさらに大きく、約2,100トークンから約300へと減っています。ページコンテキストのサイズをプロンプトの中で小さく抑えられることは、エージェントがコンテキストの圧縮やコンテキストの劣化といった問題にぶつかることなく、より長い会話を続けられることを意味します。
同じ性能で、より低コストに
重要なのは「この効率化が品質を犠牲にして得られたものではない」という点です。意味的なコンテキストを用いた14,000回を超える実行にわたって、私たちは会話ごとに使われたツール呼び出しの回数と、各会話の後に LLM を評価者（LLM as a judge）として計測した満足度を測定しました。満足度も、会話ごとの平均ツール呼び出し回数も、従来のアプローチに頼る実行と同等でした。エージェントはデータを取得するためにほぼ同じ回数のツール呼び出しを行いますが、そこに至るまでにページを理解するために消費したトークンは、はるかに少なくなっています。
現在地とこれから
このパターンは現在、Dashboards、Issues、Explore、Traces、Logs、Replays、Performance をはじめとする、Sentry でよく閲覧される24のページで稼働しています。各ページは中央部分の変更を一切必要としない、独立した追加として実現できました。これはまさに、組み合わせ可能なアーキテクチャが狙いどおりに効果を発揮する形です。
このインフラの上に構築された最初のエージェントアクションもすでに準備が整っています。Seer は今や、あなたに代わってダッシュボードを作成・更新できます。見たいものを説明するだけで（たとえば「直近7日間のエンドポイント別 p95 レイテンシを、エラー率と並べて表示するダッシュボード」など）、エージェントが適切なレイアウト、クエリ、ウィジェットタイプを備えた、完全に設定済みのダッシュボードを生成します。他のチームもエージェントに意味的なコンテキストを提供する取り組みを進めており、エージェントが自分たちのページと対話し、UI 上でアクションを実行できるようにする選択肢を模索しています。今後数か月のうちに、これを土台とした新たな機能が Sentry 内で登場するので、ぜひご注目ください。
この取り組み全体を通じて導き、支えてくれた Jeremy Stanley と Jonas Badalic に感謝します。
Original Page: Your agent should understand what you see
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談は「お問い合わせ」からお気軽にお問い合わせください。
