AIによるキャッシング戦略と計測
Article by: Lazar Nikolov, Ben Coe 最低限の製品（MVP）と本番対応のアプリを分けるものは、磨き込み、最終調整、そしてパレートの法則でいう「最後の20%」の作業です。ほとんどのバグ、エッジケース、パフォーマンス問題は、リリース後に実ユーザーがあなたのアプリケーションを使い込むようになって初めて表面化します。これを読んでいるということは、おそらく作業の80%地点にいて、残りに取り組む準備ができているはずです。 本記事では、アプリケーションのキャッシングを扱います。テールレイテンシの削減、データベースの保護、トラフィックのスパイクへの対処にキャッシュをどう使うか、さらに本番環境で稼働し始めてからそれをどのように監視するかを解説します。 本記事は、MVP を本番環境に持ち込む際に生じる共通の課題を扱うシリーズの一部です。 本番環境で大規模データセットをページネーションする：OFFSETの限界とカーソルの利点 AIによるキャッシング戦略と計測（本記事） キャッシングのメンタルモデルを構築する 適切なキャッシングはパフォーマンス、スケーラビリティ、コスト効率を何倍にも高めます。正しく行えば、ミリ秒未満の応答を実現し、オリジンサーバーを潰すことなくトラフィックの急増を吸収できます。一方、誤ったキャッシング（過度なキャッシング、不適切な無効化、誤った戦略）は、微妙なバグや古いデータ、デバッグが難しく、しかも多くのユーザーに影響が及んだ後になってようやく表面化する劣化したユーザー体験（UX）を生みます。 キャッシングの機会を探す前に、何をキャッシュすべきで、何をキャッシュすべきでないのかについてのメンタルモデルが必要です。 以下のチェックリストをご覧ください。 ✅ 大半が当てはまるならキャッシュを検討 高コスト：CPUが遅い、入出力（I/O）が遅い、DBが重い、大規模な結合／集計、外部API 高頻度：呼び出し回数が多い（1分あたりのリクエスト数（RPM）が高い）、またはホットパス上にある（ページ読み込み、コアAPI） 再利用可能：同じ入力が繰り返される（キーのカーディナリティが低い） ある程度安定：データが毎秒変わらない（または多少の古さを許容できる） スパイク負荷：突発的なトラフィックで、キャッシュがアクセス集中（サンダリングハード）を吸収できる テールが痛い：P95/P99が悪く、キャッシュミスが遅いリクエストと相関している 古いデータを返しても安全：ユーザー影響が小さい、または stale-while-revalidate（SWR）を使える 無効化が簡単：TTL（time to live）が機能する、または更新に明確なトリガーがある ペイロードが小さめ：メモリコストが妥当で、シリアライズが安い ❌ 次のいずれかに当てはまるならキャッシュしない（または慎重に） キーのカーディナリティが高い：ユーザーごと／ページごと／フィルターごとに爆発する → ほとんどがキャッシュミスになる（ページネーションは特殊ケース。後述の注記を参照） 変化が激しい：正確性のために鮮度が必須 個別対応／権限制御がある：キーのミスでデータ漏えいが起きやすい 無効化が難しい：明確なTTLがない、更新が予測できない すでに速い：5msの短縮は複雑さに見合わない キャッシュスタンピードのリスク：再計算コストが高い＋有効期限が同期される（ロック／ジッターが必要） ページネーションされたエンドポイントをキャッシュする際には特別なルールがあります。まずは1ページ目と一般的なフィルターをキャッシュしてください。1ページ目と少数の一般的なフィルターは通常ホットで再利用されるため、キャッシュの効果が大きくなります。一方、ページ番号が増えるほどキーのカーディナリティが爆発し、再利用は急落します。そのため、深いページは自然にキャッシュミスになりますが、それで問題ありません。全ページで均一なヒット率を達成することではなく、バックエンドの保護と入口（エントリーポイント）でのテールレイテンシ削減を最適化対象にしてください。 本番環境でキャッシング機会を見つける 何をキャッシュすべきかが分かったら、次に考えるべきは「キャッシュが実際に効く場所はどこか」です。本番環境のシステムでは、良いキャッシュ候補はたいてい「痛み」として現れ、通常は3つの形を取ります。 バックエンドでの問題（ここから始めましょう） バックエンドとフルスタックのシステム において、これが最も手を打ちやすいシグナルです。 […]
本番データを活用してバグを予測するコードレビューシステムの構築
Article by: Giovanni Guidini, Kush Dubey, Suejung Shin この投稿では、Sentry の AI Code Review が実際にどのように動作するのかを、より詳しく見ていきます。 Seer（Sentry の AI デバッガー）の一部として、Sentry のコンテキストを使用し、バグを正確に予測します。自動またはオンデマンドで実行され、出荷前に問題点を指摘し、修正案を提案します。 AI ツールはノイズが多くなり得ることを私たちは理解しています。そのためこのシステムは、誤検知や役に立たないスタイル上の指摘で埋め尽くすのではなく、実際の変更内容に含まれる本物のバグを見つけることに焦点を当てています。AI とアプリの Sentry データ（実行状況や、これまでどこで壊れてきたか）を組み合わせることで、将来新しいバグを出荷してしまうことを避けられるようにします。 高レベルアーキテクチャ このコードレビューシステムは、コード分析と Sentry データの両方を用いてバグを検出し、PR に対して提案を提示します。 以下は AI Code Review のアーキテクチャの概要です。 バグ予測パイプライン できる限り高い精度でバグを予測するために、仮説と検証に基づくマルチステップのパイプラインを採用しています。 フィルタリング：このステップでは PR の情報を収集し、PR 内のファイルを、最もエラーが発生しやすいものへ絞り込みます。特に大規模な PR では重要です。 予測：肝となる部分です。ここでは複数のエージェントを実行し、バグの仮説を作成して検証します。 パッケージングと出荷：提案を集約し、フィルタリングと解析を行ってコメントに整形したうえで、PR に送信します。 このあと、パイプラインが実際に動いている様子を示す例として、getsentry/sentry リポジトリのトレースをいくつか見ていきます。 フィルタリング 変更が少ない […]
.NET アプリで AI エージェントをより効果的にモニタリングする方法
Article by: Alex Sohn 今年の初めにエージェントモニタリングをリリースし、ユーザーがアプリケーション内での LLM の利用状況やツール呼び出しを計測できるようにしました。ただし当時、エージェントモニタリングに対応していたのは Python と JavaScript のみでした。そこで私たちは、.NET 向けのエージェントモニタリング SDK、具体的には Microsoft.Extensions.AI.Abstractions 向けの開発に取り組んできました。 Sentry.Extensions.AIのご紹介 Sentry.Extensions.AI は、Microsoft.Extensions.AI.Abstractions に基づく .NET の LLM パッケージ用のインストゥルメンテーションレイヤーです。このレイヤーを使用することで、以下の LLM 使用状況を計測できます。 LLM呼び出し 入力・出力 トークン数 モデル名 ツール呼び出しの入出力 LLM 呼び出しに関連する Issue 総コスト これらすべてを Sentry でスパンやイベントとして確認できるため、AI の挙動を他のアプリケーション部分、例えば HTTP リクエスト、バックグラウンドジョブ、データベースクエリなどと関連付けることが可能です。 Microsoft.Extensions.AI.Abstractions とは AI.Abstractions パッケージは、多くの他のライブラリにとっての低レベルな契約レイヤーです。これは .NET における生成 AI 用のインターフェースやデータモデルを含んでおり、他のライブラリによって実装されることを目的としています。依存関係が最小限に抑えられているため、ライブラリエコシステムの基盤として使用できます。 Microsoft.Extensions.AIとは混同しないでください。Microsoft.Extensions.AIには ChatClientBuilder […]
【Seer】開発の全工程でAIデバッグ
Article by: Indragie Karunaratne Seer という AI デバッグエージェントを立ち上げた際、ある中核的な信念に基づいて構築しました。現実のソフトウェアにおける複雑な障害モードを理解するには、本番環境のコンテキストが不可欠だという信念です。Seer は Sentry が収集する詳細なテレメトリー（エラー、スパン、ログ、メトリクスなど）を利用して、的確にバグの根本原因を特定し、修正します。このテレメトリーはトレースで紐付いているため、Seer は問題に関連するすべてのデータを決定的にたどることができ、曖昧な時間範囲検索に頼る必要がありません。 コーディングエージェントはソースコードを読むことで見つけられるバグもありますが、実行時の挙動を観察してはじめて、信頼性をもって特定できるバグもあります。分散システムでは、障害がネットワークの境界を越えて広がることがよくあります。健全でないサービスがタイムアウトや他の場所での連鎖的な障害を引き起こすことがあり、負荷がかかったときにのみ発生する問題も存在します。パフォーマンス特性を理解する場合も同様です。例えば、p95のレイテンシスパイクは、ロックの競合や接続プールの飽和、またはコードからは明らかでない他の根本原因に起因している可能性があります。実行時のコンテキストは、Seerがこうした現実世界の問題を正確に診断して解決するために必要な証拠を提供します。 本番環境でのバグ修正は常に重要なユースケースですが、最良のバグとは、そもそもリリースされないバグです。 今日は、ローカル開発やコードレビューの段階でもデバッグできるように Seer の機能をシフトレフトで拡張し、あわせて無制限利用を可能にする新しい定額料金も導入します。 ローカル開発中にデバッグを行う バグは導入された瞬間に修正するのが最も簡単です。Sentry MCP サーバー は、強力なデバッグフィードバックループを通じて、ローカルのコーディングエージェントを接続します。これにより、コードレビューや本番環境ではなく、開発中に問題を発見し解決することができます。ローカルでバグを再現すると、テレメトリがアプリケーションから Sentry に送られ、エージェントはコンテキストのための生のイベントにアクセスしたり、Seer を呼び出して完全な根本原因分析を実行することができます。コーディングエージェントは、コードがローカル環境を離れる前にパッチを生成するために必要なすべての情報を得ることができます。 本物の欠陥を発見するコードレビュー それでも、ローカル環境ですべてを捕まえられるわけではありません。すり抜けたバグに対しては、コードレビューのタイミングで Seer が介入し、プルリクエストに含まれる問題をマージ前に特定します。Seer が重視するのは、本番環境を壊しかねない実害のあるバグを見つけることです。信号の弱い提案やスタイルに関する些細な指摘には注力しません。レビューの段階でこうした欠陥を見つけ出すことで、インシデントは減り、リリースは速くなり、本番環境でのデバッグに費やす時間も短くなります。 すでに Seer をお使いの場合は、GitHub連携をインストールし、Seerの設定で GitHub リポジトリを接続して、コードレビュー機能をセットアップしてください。 本番環境での根本原因分析を自動化する これらの安全策を講じていても、いくつかのバグは本番環境に到達します。その際、Seer は最も対処しやすい問題を特定し、実行時のテレメトリを自動的に利用して、裏で根本原因を特定します。Seer がある問題を対処可能であると高く確信した場合、さらに踏み込んでバグを修正するコード変更を生成したり、Cursor などのコーディングエージェントに委任して、代わりに修正を実行させることもできます。 未知を調査 Sentry がすでに問題を特定している場合、Seer の自動根本原因分析は効果的に機能します。しかし、時には Sentry がフラグを立てたバグが原因ではない問題もあります。たとえば、顧客から「何かおかしい」という報告があったり、ダッシュボード上でメトリクスが望ましくない方向へ推移していたりすることがあります。こうした構造化されていない調査に対して、私たちは新しい実験的機能を開発しています。それは、Sentry […]
【MCPサーバー構築後】Sentryでクライアント・ツール・リクエストを追跡
Article by: Sasha Blumenfeld, Miguel Betegón 本日（2025/8/14）より、MCP SDK 実装に計測コードを1行入れるだけで、サーバーサイド JavaScript SDK ベースの MCP サーバーの多くを計測できるようになりました。 これを導入すれば、MCP 実装全体にわたって、プロトコルの利用状況、クライアントの利用状況、トラフィック、ツールの利用状況、パフォーマンスといった詳細を確認できるようになります。 2025年の初めに私たち自身の MCP（Model Context Protocol）サーバーを公開した際の目的はシンプルでした。AI エージェントが Sentry のコンテキストを使って、ユーザーのアプリケーション上の問題をリアルタイムにデバッグできるようにすることです。 共同創業者の David Cramer も、有名な辛口コメントをシェアしているように、標準が頻繁に変わる新技術を前提に開発するのは簡単ではありません。 ここ数か月の間に、MCP が Streamable HTTP に標準化され、OAuth サポートが改善され、新しい仕様（spec）が導入されるなど、（控えめに言っても）多くの「調整」が行われていくのを見てきました。 ユーザーが簡単に導入できること、そしてユーザーベースが直面する複雑なユースケースをサポートすることを念頭に、MCP サーバーを「最先端」で構築してきました。リモートホストされるステートフルな MCP サーバー、OAuth のサポート、Seer や自然言語検索といった機能の追加など、最先端の要素に踏み込むことには、モニタリングとオブザーバビリティの面で固有の課題が伴いました。 それに加えて、Sentry の規模もあり、MCP サーバーの利用は非常に速いペースで増加しました。数千のユーザーが利用し、月間 5,000 万リクエスト（そして増加中）に達しています。 Sentry MCP サーバーを構築する中で、MCP サーバー監視におけるギャップがどこにあるのかを把握し始めました。エラーの詳細や MCP 内で現れる厄介なエッジケースの詳細を捉えるのは容易ではありません。ツール呼び出しにおけるパフォーマンス問題は診断が難しく、さらにツール呼び出しの特定の入力・出力に関する課題も、MCP の監視という観点では現時点で未成熟な領域です。 […]
【Sentry MCP ＆ Cursor】デバッグをもっとスマートに
Article by: Cody De Arkland 本番の障害を Cursor でデバッグしていますか？ おそらくワークフローはこうです。Alt-Tab で Sentry に切り替え、エラーの詳細をコピーし、IDE に戻って Cursor に貼り付ける。コンテクストスイッチを 3 回もした頃にはフローは途切れ、実際の本番環境やコードベースを理解しているとは言えない… 一般的な提案を眺めることになります。 Cursor と LLM は良いコードを書けますが、本番のエラー、ユーザーの操作フロー、影響指標、デプロイ履歴、さらにはアーキテクチャのことも知りません。そのコンテクストがあるかどうかで、「パターンマッチングと一般的なエラーハンドリングを提案します」と「この API エンドポイントは、隣接するサービスの 1 つにデプロイされた昨日のコミット以降、ユーザーの 47% で失敗しています」という差が生まれます。 Sentry MCP Server を使えば、Cursor は Sentry が持つ、本番（および開発）アプリケーションのパフォーマンス周辺のコンテクストに直接アクセスできます。エラーメッセージやログをコピー＆ペーストしたり、分散トレーシングの構成やスタックトレースをチャットで説明しようとしたりする必要はありません。MCP は実際の問題を調査し、その影響を理解し、実際の本番コンテクストにもとづいて修正案を提案できます。 ただし、アプリケーションのアーキテクチャの複数領域にまたがるような複雑でシステム全体に及ぶ問題に直面したとき、「AI Debugger」として本領を発揮するのは Sentry の Seer です。Cursor 単体でもピンポイントな修正は得意ですが、MCP Server と併用する場合でも、問い合わせたアプリ性能の各要素を手作業で引き出して自分でつなぎ合わせる必要があります。しかも、MCP の結果が一貫しないこともあります。MCP はまだ完璧には程遠いのです。Seer はプロジェクト全体を横断して、自動的にパターンを見つけ、Sentry のコンテクストに対して深い調査を行い、根本原因の特定と実際に使える解決策の構築に取り組みます。 幸い、私たちは Sentry MCP […]
AIシステムを本番で監視するために本当に必要なこと
Article by: Rahul Chhabria 最新の AI エージェントをプロダクトに組み込み、リリースして、あとは寝るだけ。ところが起きてみると、空文字を返していたり、昨日より 5 秒も遅くなっていたり、あるいは「完璧な JSON」の体裁で堂々と嘘を出していたりしています。 当然、ログを確認します。 プロンプトはある。レスポンスもある。……でも、肝心の手がかりが何もない。 驚きますよね。プロンプト入力とレスポンス出力だけでは、オブザーバビリティとは言えません。あれは雰囲気です。 「LLM のオブザーバビリティ」は今かなり話題です。ただ、実態は「要らないチャート」と「そのうち見なくなるダッシュボード」が増えるだけ、というケースも少なくありません。もしあなたが実際に、チャットボットや社内エージェント、検索・取得アプリなど、LLM を組み込んだプロダクトを作って運用しているなら必要なのは観測です。しかも、肝心なところに差し掛かった瞬間に途切れるような観測ではなく、原因まで辿れる観測です。 何を追うべきか。いつ追うべきか。なぜそれが重要なのか。中身のない補完にうっかり 5,000 ドル払う前に、順番に整理していきましょう。 ステージ 1：本番前 （別名：「プロンプト墓場」） 今、プロトタイプを作っている段階だとします。ノートブック、ベクターストア、OpenAI API キー、そして夢もある。必要なのはダッシュボードではなく、壊れたプロンプトを必死に救い出すためのログです。 何をログに残すべきか この段階でデバッグしているのは、ユーザーというより自分自身です。なので、以下をログに残しましょう。 プロンプト全文とレスポンス全文 モデル名、temperature、function schema のバージョン トークン使用量とレイテンシ プロンプトのバージョンを特定できる情報（何でもいいので） プロンプトのバージョン管理に気の利いた仕組みは要りません。コミットハッシュで十分です。付箋でもいい。とにかく、何が変わったのか忘れる前に書き留めておきましょう。 当面はこれで済むツール類 JSON ファイル Postgres のテーブル 構造化ログを使った Sentry Traceloop（そういうのが好きなら） ここでの唯一の目的は「変な挙動」を再現できるようにすることです。何かが爆発しても、5 分以内に説明できるなら勝ちです。 ステージ 2：本番（Production） （いまや「誰か別の人」の問題） […]
【Sentry Seer】法務審査をクリアする方法 Seer をレビューする法務チーム向けガイド
Article by: Virginia Badenhope （本記事は法律の専門家が法律の専門家のために書いたものですが、法務担当者がいないまま Seer の利用を検討している方にとっても、安心材料になるはずです） 自社の法務部門が私たちと同じような状況にあるのであれば、事業側から「もっと多くの AI ツールを使いたい」というリクエストが次々と押し寄せてきているのではないでしょうか。開発チームは Cursor のようなコーディングエージェントを使いたがり、セキュリティチームは AI を活用した調査を導入し、セールスやマーケティングは通話内容のインサイトや競合調査に AI を活用しようとしています。私たちは各チームが試し、購入しようとしているツールに大きな変化が起きていることを目の当たりにしてきました。 サービスの主な機能自体は AI を前提としていない場合でも、いまやほとんどすべてのサービスが何らかの AI 機能を備えています。 ビジネス側も AI の利用には一定のリスクが伴うことは理解していますが、それでも「使わなければ取り残されてしまう」という強いプレッシャーを感じています。あなた自身も同じプレッシャーを感じつつ、自社のデータや知的財産はもちろん、顧客から預かっているデータや知的財産を守るという使命も負っています。 Sentry が Issue Scan や Issue Fix を含む自社の AI／ML 機能を支えるために開発してきた AI エージェントである Seer について法務レビューを依頼されているのであれば、本記事の目的は、Sentry の法務チームである私たちがサードパーティ製の AI ツールを評価する際に用いている基準を、Seer も同じように満たしていることを示すことにあります。 もし Seer の評価を依頼されたとしたら、私たちは承認します。理由は次のとおりです。 では、法務は実際のところ何を気にしているのか？ 私たちおよび顧客データと知的財産を保護しつつ、ビジネスの変化するニーズを引き続き支えていくために、Sentry では AI ツールの利用について次の要件に合意しています。 […]
AIにもっとデバッグをうまくさせるには？重要なのは「コンテキスト」
Article by: Milin Desai AI を活用したコード生成ツールによって、これまでになく大量のコードが次々とリリースされています。いまは開発者にとっての黄金時代と言っていいでしょう。 しかし、ひとつ重要な事実があります。ソフトウェアは依然として本番環境で壊れてしまいます。Microsoft が最近行った調査によると、AI モデルはソフトウェアのデバッグを苦手としていることがわかりました。その理由は、多くのコード生成ツールで、優れた開発者なら誰もが頼りにしているたった1つのもの、「コンテキスト」が欠けているからです。 何かをデバッグしようとするなら、コンテキストが必要です。AI ツールがあっても、この前提は変わりません。AI は学習データを超えて、実際のエラーやトレースデータ、ブレッドクラム、スタックトレース、コードベース全体、コミット履歴などにアクセスできる必要があります。 AI があるかどうかにかかわらず、デバッグにはコンテキストが欠かせないのです。 AI 時代のデバッグに不可欠なのはコンテキスト Sentry はこの10年あまりの間に、13万以上の組織がソフトウェアの不具合をすばやくデバッグできるよう支援してきました。Sentry 独自のコンテキストを提供することで、エンジニアリングチームが本番環境でのデバッグを従来の 10 倍の速さで行うことができるようにしています。 何かが壊れたとき、開発者は次のようなことを知る必要があります。 問題はいつ発生し始めたのか。 壊れる直前に「何が変わった」のか。 影響を受けているのは 1 人のユーザーか、それとも多数なのか。 どのプラットフォーム／デバイス／リリースに影響しているのか。 問題の起点はどこか。自分のコードなのか、それとも依存している外部要因なのか。 Sentry はこれらの問いに答えるだけでなく、次の情報もあわせて提示します。 どの関数やコード片が失敗しているのかを正確に把握するためのスタックトレース エラーの前後で、アプリケーションがエンドツーエンドでどう振る舞っているかを確認するためのトレースとログ フロントエンドでデバッグしている問題に、バックエンドエラーが関係しているかどうかを確認できるようなトレースでつながった関連 Issue 例外の前後でどのようなアクションが行われたかを把握するための Sentry のブレッドクラム 各関数がどのようなパフォーマンス特性を示しているかをよりよく理解するためのプロファイリングデータ こうしたコンテキストのすべてが、長年にわたって Sentry を開発者にとって非常に有用な存在にしてきました。そしてこれは、障害が発生したときに本当に問題を修正するために、他の AI ツールにも必要でありながら、まだ備わっていないまさにそのコンテキストでもあるのです。 Seer：Sentry の […]
【AI 機能アップデート】全 Sentry ユーザー対象
Article by: Lindsay Piper 今回のアップデートでは、また新たなチャットボットを提供するのではなく、チームの時間が浪費されがちな Sentry の箇所に AI を直接組み込み、すでにお持ちのデータを即座に活用できるコンテキストへと変換できるようにしました。 そして本日、すべての Sentry ユーザーが利用できるようになりました。 Trace Explorer で自然言語クエリを使って質問するだけ Trace Explorer は自然な言葉で書かれた質問をそのまま受け取り、実際のクエリに変換できるようになりました。演算子やフィールド名を覚えておく必要はなく、知りたい内容をそのまま言葉で説明するだけで構いません。 たとえば「うちの DB の p90 レイテンシはどのくらい？」のような質問を入力すると、その裏側で必要なクエリが自動生成され、関連する span を特定し、レイテンシの分布を表示してくれます。 構文を書く必要は一切ありません。クエリを組み立てる手間は大幅に減る一方で、これまでと同じ深さのトレースデータにアクセスできます。 Issue の原因にまず「あたり」をつける 新しい Issue に遭遇したとき、最初の疑問はたいてい「どこから手を付ければいいのか？」ではないでしょうか。 各 Issue に表示される Initial guess は、Issue のコンテキストを自動的に解析し、何が問題になっていそうかを初期的に推定します。これにより、ソースコードや追加の Sentry テレメトリを参照して根本原因をより正確に特定する Seer による詳細な分析に進む前の、出発点を提供してくれます。 Session Replay Summaries でインサイトに素早くたどり着く エラーが発生した瞬間にジャンプできること自体は便利ですが、ユーザーがそこに至るまでの経路を理解するには、依然として時間がかかります。長いセッションでは、多数のインタラクションやネットワークコール、UI […]