【Sentry AIコードレビュー】現在ベータ版：本番環境での問題発生を減少
Article by: Lindsay Piper これは防げたはずです。 これも防ぐべきでした。 これも同じです。 私たちは皆、PR（プルリクエスト）でタグ付けされるのが嫌いです。時間を取られ、必ず何かを見落とした時には責められ、そして「自分ならこうは書かなかった」という感覚が常につきまといます。LLM（大規模言語モデル）は、これをもっと簡単にしてくれると約束しました。私たちの代わりにやってくれると。しかし、ご覧のとおり、まだその段階には至っていません。 しかし、これこそが Sentry の本業です。私たちはバグを捕まえます、本番環境で。では、その専門性をコードレビューの段階に持ち込んだらどうでしょうか？天才的だと思いませんか？ そこで私たちは、AI コードレビューに新しい機能を追加しました。プルリクエストを開く際に、Sentry の Issue を取り込み、実際にバグを予測するのです。もちろん、すべてのエラーを防げるわけではありません。あなたが書いた（あるいはプロンプトで生成した）コード以外にも考慮すべき要因があまりに多すぎるからです。しかし、この機能を使えば、本番環境を停止させるような回避可能なミスを出荷してしまうことを防ぐことはできます。 Sentry のコンテキストをプルリクエストに持ち込む AI ツールにおいては、コンテキストこそがすべてです。これは、Seer がベータ期間中に開発者たちの累計2年以上の時間を節約できた理由でもあります。私たちの AI コードレビューも同じアプローチを取りますが、それを出荷（デプロイ）前に行います。具体的には、あなたが触れたコードに対して Sentry のコンテキストや、そのコードに関する過去のシグナルを活用します。対象となるのは、関数の残りの部分、リポジトリ内で呼び出される関数、そして依存するクラスやオブジェクトです。 この「ライブのコードコンテキスト」と「現実世界での Issue 履歴」を組み合わせることで、フィードバックは曖昧な警告や一般的なリンティングの助言ではなく、具体的で実行可能なものになります。 最も重要なエラーを予測し、防ぐ 自動化された PR レビューは、たとえリポジトリ全体のコンテキストを持っていても、しばしば実際の問題をスタイル上の細かい指摘やベストプラクティスに埋もれさせてしまいます。その結果、開発者は「consider inlining」や「prefer async/await」といった注意の洪水の中から UnboundExecutionError を探し出さざるを得なくなるのです。 しかし、Sentry のコードレビューはそうではありません。PR がレビュー可能（ready for review）とマークされたときに実行され、実際に本番環境を壊すものだけにフォーカスします。 したがって、もしあなたが次のような変更を含む PR を開いた場合、以下のようになります。 インポート文の後に空行を追加したほうがよい、といったコメントは表示されません。 Sentry が返すのは、次のように 具体的で実際に役立つデバッグコメント です。 これがどのように動作するかは、次のとおりです。 […]
分散システムのトラブルシューティングにトレース参照機能を備えた Sentry AI デバッガー
Article by: Rohan Agarwal デバッグは、すべての開発者にとって常に付きまとう課題であり、たとえAIがコードを書くようになったとしても、その負担が増す可能性さえあります。Sentry のようなツールは、長年にわたりエンジニアが問題を追跡し、デバッグを行う際に支援してきましたが、新たなAIツールを活用することで、こうしたプロセスをさらに迅速かつ容易にできる点が魅力です。 もちろん、Sentry から例外のスタックトレースをコピーして ChatGPT に貼り付けることも可能です。しかし、もし本当に賢いものが欲しいとしたら、どうでしょうか。AI が最善の仕事をするために、より多くのコンテキストを持ち、分散システムを深く理解し、本番環境でそれらをデバッグする能力を備えたものがあればどうでしょうか。 本記事では、私たちがどのようにして、トレーシングの力を活用して、Sentry の本番レベルの AI デバッグアシスタント「Seer」を構築したのかを説明します。 AI によるデバッグの欠点はどこにあるのか？ Seer とその Autofix 機能は、Sentry のIssues 詳細とコードベースとの緊密な統合を活用することで、問題の根本原因を突き止め、修正するための優れたツールとなっています。Autofix は開発者と協働しながら、問題の根本をより深く理解し、効果的な解決策を計画し、さらにはそれを修正するプルリクエストの下書きまで作成します。さらに、リグレッションを防ぐための単体テストも含まれます。これまでのところ、その裏側では主に Sentry のスタックトレースやパンくずリスト、そしてコードベース検索に依存して知見を得ていました。実際、Autofix はすでに数多くの開発者を助けており、さまざまなアプリケーションのバグを修正してきました。 Autofix 自身のバグさえもです。 しかし時には、Autofix が的を外してしまうこともありました。たとえば、フロントエンドから報告された「500 Internal Server Error」に対して Autofix を実行しても、バックエンドでの問題を特定することはできません。あるいは、2つのマイクロサービス間で認証の問題が発生した場合、Seer には実際に何が起きているのか把握できませんでした。さらに、複雑なアプリケーション全般においては、エラーの発生源となっているモジュールがどのように、なぜ利用されているのかについて、ほとんど理解できていませんでした。 ここで登場するのがトレースです。トレースを使うことで、Seer はマルチサービスシステム全体のフロー（フロントエンドとバックエンドといった複数階層を持つソリューションや、さまざまなマイクロサービスを利用するものを含む）、関連するエラー、エラー発生前後に実行された正確な処理（さらにプロファイリングを有効にすれば正確な関数呼び出しまで）を明確に把握できます。これにより Seer は、プロジェクトやリポジトリをまたいだ問題を非常に速く分析し、現実世界でエンジニアが直面する最も複雑な問題の一部を自律的にデバッグできるようになります。それに比べて、チャットボットにコピー＆ペーストするだけでは表面をなぞるに過ぎません。 トレースとは何か？どう活用できるのか？ すでに内容をご理解いただいている場合は、このセクションをスキップしていただいて構いません。そうでない場合は、ここで簡単にご説明します。 トレースとは、アプリケーションおよびその関連サービスを通じてリクエストがどのように流れるかを記録し、データの移動経路や潜在的な問題の発生箇所を可視化する仕組みです。トランザクションやリクエストに関与するイベントのシーケンスを追跡することで、分散システムにおけるパフォーマンスのボトルネック、エラー、依存関係などを特定するのに役立ちます。 トレース内の各ステップは「スパン」と呼ばれ、データベースクエリ、API呼び出し、関数の実行などの作業単位を表します。これらのスパンを組み合わせることで、初期リクエストから最終レスポンスまでの全トランザクションの経路を、包括的に視覚化することができます。トレースは複雑なマイクロサービスアーキテクチャのデバッグおよび最適化において、特に高い価値を発揮します。 Sentry を使えば、トレースを簡単に始められます。アプリに Sentry SDK を追加すると、多くの部分が自動的にインスツルメントされ、後からカスタムのスパンや属性を任意でインスツルメントすることもできます。たとえば Python […]
【Sentry＆エッジデプロイメント】レイテンシの測定と改善方法
Article by: Kyle Tryon 本ブログの内容 レイテンシの特定 なぜエッジコンピューティングが重要なのか エッジで計算するには？ TL;DR Google の研究者たちが 2017 年に行った調査によると、次のような結果が得られました。 ページの読み込み時間が 1 秒から 3 秒になると、ユーザーが離脱する確率は 32% 増加する。 これは8年以上も前の話です。そして正直なところ、それからユーザーの忍耐力が増したとは考えにくいでしょう。 Web Vitals とは、Google が定義した一連のパフォーマンス指標で、ユーザー体験を測定するためのものです。たとえば次のような要素に着目しています。 LCP（Largest Contentful Paint）：主要コンテンツが読み込まれるまでの時間 INP（Interaction to Next Paint）：ページが入力に反応するまでの速さ CLS（Cumulative Layout Shift）：アプリの視覚的な安定性（＝コンテンツが予期せずずれ動くかどうか） わずか 1 秒の遅延でさえ売上の減少や登録機会の損失につながる可能性があるため、あらゆる観点からレイテンシ（遅延）を調査することが重要です。 どれだけ最適化されたアプリケーションであっても、プルリクエスト（PR）だけでは解決できないボトルネックが少なくとも1つは存在します。それが「距離（distance）」です。 レイテンシの特定 見えないものは、直すことができません。 たとえば、あなたのサービスがアメリカ国内の単一サーバー上で稼働している場合、アジアやヨーロッパといったより遠方にいるユーザーは、単純にリクエストの移動距離が長くなるため、読み込み速度が遅くなるのは自然なことです。 ここでは、Sentry を使って地域ごとのレイテンシの影響を測定・可視化するための基本的なセットアップ手順を紹介します。 テスト環境の構築 今回は、フロントエンドアプリとバックエンド API […]
ベータ期間中に Sentry のユーザーフィードバックウィジェットを使って Logs を形作った方法
Article by: Jasmin Kassas Sentry では、私たちは公開の場で開発を行い、迅速に対応しています。しかし、スピードを重視することで、最初の試みで全てがうまくいくとは限りません。そこで役立つのがフィードバックです。フィードバックはうまくいっている点を検証し、不足している部分を特定し、エラートラッキングだけでは把握できない問題を明らかにする助けになります。 数か月前に Logs のベータ版をリリースしたとき（ちなみに先週 GA になったのでぜひご覧ください）、私たちはエラーやパフォーマンス監視だけでは明らかにならないもの（壊れているのに気付かれないもの、静かに失敗しているもの、あるいは単にユーザーを混乱させているもの）を見つける方法が欲しいと考えていました。そこで、Sentry のユーザーフィードバックウィジェットをプロダクトにそのまま組み込みました。 つまり、開発者がつまずいたとき、そのフィードバックにはリリースバージョン、環境、URL、さらには実際に起こったことのセッションリプレイといった、私たちに必要なすべてのコンテキストが付随していました。 その結果、Logs はより速く進化し、信頼性が高まり、開発者（私たち自身を含む）が実際に使いたいと思えるものへと変わりました。 フィードバックを機能と修正に変える ユーザーフィードバックウィジェットは単なる意見収集の箱ではなく、Logs ベータ期間中に私たちが実際に出荷したものを形作りました。 明確な例のひとつが 自動リフレッシュ機能 です。開発者から「ログストリームを自動的に更新してほしい」という要望が繰り返し寄せられていました。私たちもそれが重要であることは認識していましたが、優先順位を上げるには至っていませんでした。しかし、タグ付きのフィードバック提出が積み重なっていくうちに（製品固有のフィードバックを素早く確認するには、URL タグでフィルタリングしています）、その継続的なシグナルが優先度を押し上げました。そして、4週間でフィードバックから機能へと進化し、現在では稼働中の自動リフレッシュ機能をリリースするに至りました。 また、アラート機能に対する強い要望も寄せられました。これを受けて、ログベースのアラートをサポートし、認証エラーや設定の欠落といった重要なログが現れたときにユーザーへ通知できるようにしました。 しかし、このウィジェットは製品リクエストのためだけのものではありません。最も重要なのは、エラートラッキングだけではすぐに明らかにならなかった重大な SDK の問題を表面化させてくれた点です。それによって、私たちは次のような問題を特定し、解決することができました。 Python SDK のバグ：ログ属性を正しく収集していなかった。Python 標準ライブラリのロガーとのログ統合を最初に実装したとき、生成されたログメッセージに名前付きパラメータを付与していませんでした。この API がそのようにも利用され得ることを、ユーザーから指摘を受けるまで気付いていませんでした。 JavaScript SDK の問題：特定のオブジェクトのシリアライズが原因で、ログメッセージが正しくレンダリングされないことがありました。これは、JavaScript SDK でコンソール計測を通じて生成されたログを作成する際に、文字列を連結する方法に起因していました。修正自体は単純でしたが、[Object Object] が紛れ込んでしまうのは簡単だということを思い出させるものでした。 JavaScript SDK のより深刻なバグ：環境とリリースの属性がログに正しく付与されない問題がありました。原因は単純で、これらの属性をログに付与する際に正しいフォーマットを使用していなかったことです。しかし、私たちのプロダクトはリリース値や環境値をトップレベルのフィルタやデータの関連付けに依存しているため、ユーザーにとって多くの問題を引き起こしました。 フィードバック提出には、環境、組織ID、プロジェクト名、URL といった技術的なコンテキストが含まれていたため、私たちはサポート対象プラットフォーム全体に修正を出荷し、Logs をより信頼性の高いものにすることができました。その結果、Logs はフロントエンドの体験においても、基盤となる SDK インフラにおいても、開発者が期待する通りに動作するようになりました。 […]
【Laravel】デバッグとログ記録
Article by: Kyle Tryon 本ブログの内容 サンプルプロジェクトのセットアップ Monolog を使った Laravel のログ記録 Laravel をデバッグするために使うべきツール Laravel アプリのパフォーマンス問題をトラブルシュートし修正する 本番環境で Sentry を使って Laravel をデバッグ・ロギングする Laravel をよりスマートにデバッグする ロジックエラー、失敗した HTTP リクエスト、気付かれずに消えるバックグラウンドジョブ。ソフトウェアはあらゆる「楽しい」形で壊れます。強靭なシステムと脆いシステムの違いは、エラーを完全に回避できるかどうかではありません。何が問題だったのかを、いかに素早く、明確に把握し、修正できるかにかかっています。 Laravel はしっかりとした基盤を提供します。構造化ログ、リアルタイムでの内部観察、そして組み込みのパフォーマンス監視。開発やステージング環境では、dd()、Log::debug()、Monolog、Telescope、Debugbar、Xdebug といったツールを使って、内部を覗き込むことができます。しかし、本番環境はまったく別物です。 本番環境でフロントエンドとバックエンド両方のエラー、遅延、そして再現が難しいエッジケースにわたる完全な可視性を確保するために、Sentry は Laravel アプリに統合され、必要な時に必要なコンテキストを、異なるサービスを横断して提供します。 このガイドでは、いくつかの Laravel デバッグツールについて説明します。それぞれが何をするのか、どのような場面で使うべきか、そしてログを掘り返したり環境ごとに何が悪かったのかを推測したりせずに、適切なインサイトを得る方法を解説します。 前提条件 すでにお使いのコンピュータに Laravel 12 がインストールされている場合は、それを使用できます。 ただし、このガイドでは別のアプローチを取り、Docker コンテナ内でサンプルを実行します。Docker を使うことで、この記事内のコードはあらゆるオペレーティングシステム上で実行でき、セキュアなサンドボックス内で個人ファイルから安全に分離され、特定のバージョンの Laravel、Node、PHP をインストールする必要もありません。 また、このガイドでは Git がインストールされていることを前提としていますが、必要であればサンプルリポジトリを手動でダウンロードして解凍することもできます。 サンプルプロジェクトのセットアップ Laravel […]
ゲームコンソール向けクラッシュレポートが正式リリース
Article by: Bruno Garcia TL;DR：主要なゲームコンソール向けのエラーモニタリングとクラッシュレポートが、正式に利用可能になりました（加えて、Unreal Engine SDK v1.1 もリリース）。これ以上の説明が不要でしたら、以下はスキップして、『リリースに含まれるものは？』のセクションにジャンプしてください。 10年以上前、ある顧客が自分のPlayStation 3のゲームに Sentry をハックして組み込みました。そこから時を経て、Sentry はいまでは Web、モバイル、デスクトップを横断して数千ものゲーム開発者をサポートしています。 欠けていたピースはなんでしょうか。 それはコンソールです。開発者からの要望を受けて、私たちはそれを実現しました。今年初めにベータとして提供を開始した後、主要なすべてのプラットフォームでコンソールサポートが正式リリースとなり、開発者が優れたゲーム体験を構築・提供するための新たな道を切り拓きました。これでスタジオは、クラッシュダンプに溺れることなく、構築・ローンチ・成長に必要なツールを手に入れることができます。 さらに、Unreal SDK、Unity SDK、カスタムエンジン向けの Sentry Native SDK とも緊密に統合され、すでに大規模な本番環境で稼働しています。 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 「Sentry のクラッシュレポート機能は、私たちが VALORANT を Xbox Series や PS5 コンソールでローンチするうえで不可欠でした。Riot 規模で対象とするすべてのプラットフォームをサポートするカスタムクラッシュ収集ソリューションを構築するのは、非常に複雑になっていたでしょう。Sentry はその問題を解決してくれたため、私たちはプレイヤーにより良いゲームを届けることに専念できるのです。」— Daniele Giannetti, Riot Games Inc. リリースに含まれるものは？ このリリースにより、開発機や市販デバイスを問わず、致命的・非致命的イベント（完全なネイティブクラッシュ対応を含む）の全コンテキストを一元的に取得できるようになります。 もはやクラッシュダンプを手動で取得したり、リキャップサーバーを立てたり、プラットフォームごとに複数のクラッシュレポートツールを使い分けたりする必要はありません。 リリースに含まれるもの 可読性の高いスタックトレース：問題が何で、どこで発生したのかをすぐに特定できる 組み込みのシンボルサーバー：デバッグファイルを直接 Sentry にアップロード可能 カスタムシンボルサーバー対応：単一かつ統一されたフォーマットを含む、多様なシンボルサーバーレイアウトをサポート タグとデバイスコンテキスト：コンソールモデル、ビルド番号、リージョン、デバイスの状態などを取得し、特定の地域、リリース、ハードウェアで問題が発生しているかどうかを把握可能 クラッシュ時のスクリーンショット：問題が起きる直前にプレイヤーが何を見ていたかを正確に確認できる […]
【Sentry Japan】DroidKaigi初スポンサー参加で見えたモバイル開発市場の実態
Article by: Naru (Sentry Japan / Ichizoku 株式会社) Sentry Japan はこれまで様々な技術イベントにスポンサーとして参加してきましたが、2025年9月、ついに DroidKaigi 初スポンサーとして出展を果たしました。Android エコシステムの中核を担う開発者コミュニティとの初接触となった今回、372名もの参加者から得られたデータは、私たちにとって極めて価値ある洞察をもたらしました。 🎰 ガチャポン体験でコミュニティを盛り上げる 今回のブース戦略の中核は、ガチャポン×コミュニティ体験の組み合わせでした。アメリカ本社から取り寄せた限定スワッグ（特にパンケーキステッカーと Sentry キャップ）を用意し、その場で抽選結果がわかるゲーミフィケーション要素を導入することで、DroidKaigi というコミュニティイベントをより盛り上げることを目指しました。 この取り組みが成功し、通常のアンケートブースの3倍にあたる372名という多くの方にご参加いただくことができました。しかし、真の価値は参加者数ではなく、その過程で明らかになった Android 開発者のエラートラッキング事情にありました。 📊 Firebase Crashlytics の普及背景：「とりあえず無料だから」の実態 使用状況の数字とその背景 アンケート結果では、Firebase Crashlytics の高い普及率が確認されました。 エラートラッキング・監視ツール使用状況： Firebase Crashlytics: 285票（76%） Sentry: 86票（23%） その他ツール: 残り1% しかし、参加者との会話で見えてきたのは、Crashlytics の選択理由が必ずしも機能面での優位性ではないということでした。多くの開発者から「無料でとりあえず入れている」という声を聞くことができ、Android 開発における初期導入ツールとしての位置づけが強いことがわかりました。 Sentry の認知度：70%が未認知という現実 Sentryの認知度について調査した結果： Sentryを知らない + 使用経験なし: […]
LLM パフォーマンスのコア KPI（と追跡方法）
Article by: Sergiy Dybskiy 本ブログの内容 「良い」LLM KPIとは？ 抑えるべき LLM パフォーマンスの中核指標10選 Sentry の AI オブザーバビリティを始める 他にも追跡しておくべき LLM メトリクス 次のステップ LLM を制御下に置くために 数か月前、トロントのオープンデータポータル向けに MCP サーバーを構築し、エージェントがユーザーの質問に関連するデータセットを取得できるようにしました。最初のバージョンを急いで作り、コードをざっと確認したところ、問題なさそうに見えたので、Claude に「トロント市における交通関連のデータソースにはどんなものがありますか？」と尋ねました。 ツール呼び出しは動作し、関連する結果も得られました。ところが、すぐにエラーが出ました。 「会話が長すぎます。新しい会話を開始してください。」質問を一度しただけだったのに。 原因は、最初の呼び出しで API から返された巨大な JSON ペイロードでした。それがコンテキストウィンドウを埋め尽くしてしまったのです。見ればすぐに解決できる簡単な問題でした。 しかし、モニタリングがない AI アプリには他にも様々な落とし穴があります。ツールのタイムアウトが黙って発生する、トークン使用量が急増する無限ループ、遅い検索、JSON フォーマットを壊すモデルのダウングレード、あるいは単純な500エラーなどです。 こうした場面があるからこそ、私は重要な問題をすぐに表面化させるために監視しているいくつかの主要な指標をまとめています。 「良い」LLM KPIとは？ Rahul が言うように、「プロンプトを入力してレスポンスが返ってくる。それはオブザーバビリティではありません。ただの“雰囲気”です。」 良いKPIとは生のカウンター値ではなく、プロダクトの成果に結びついた方向性のシグナルです。特にAIエージェントのパフォーマンス指標において重要です。 3つの視点で考えてみましょう。 信頼性：正しく動作しているか コスト効率：妥当な範囲でコストを抑えられているか ユーザー体験：速くてレスポンシブに感じられるか 以下のメトリクスはこれらの視点に直接対応しており、あなたも経験したことがあるであろう実際の障害とも結びついています。例えば、ループによるトークンスパイク、不安定なベクターデータベースがレスポンスを遅くする問題、あるいは静かに行われたモデル変更で出力品質が大幅に低下するケースなどです。 また、これらは「LLM 評価指標（LLM evaluation metrics）」「LLM […]
【SvelteKit】オブザーバビリティが10倍強化 ー その全貌を解説！
Article by: Lukas Stracke Svelte チームは先日、 SvelteKit の完全なオブザーバビリティとトレーシングのサポートを追加したことを発表しました！ これは SvelteKit と Sentry のユーザーにとって朗報です。なぜなら、Sentryはすでにこの新機能と互換性があるからです。 さらに、このニュースは JavaScript エコシステム全体にとっても大きな意味を持ちます。SvelteKit は、ESM ベースのメタフレームワークとして初めて、インストゥルメンテーションとトレーシングを標準でサポートしたのです。 ここからは、なぜこれが重要な一歩なのか、そしてSvelteKitがどのようにして他のESMフレームワークのお手本となったのかを見ていきましょう。 何が起こったのか SvelteKit バージョン2.31.0 以降では、サーバーサイドインストルメンテーションと SvelteKit が生成するスパンを有効化できるようになり、サーバーサイドのトレースを大幅に強化できるようになりました。これは、SvelteKit アプリケーションにオブザーバビリティを追加したい人にとって大変朗報です。 理由は以下のとおりです。 まず、SvelteKit では instrumentation.server.js という専用ファイルを用いたテレメトリのインストゥルメンテーションがサポートされました。このファイルはサーバーサイドのインストゥルメンテーションを初期化します。ビルドの最終成果物に組み込まれ、OpenTelemetry のような自動インストゥルメンテーションが、サーバーサイドリクエスト処理の全体を確実に捕捉できるタイミングで評価されるようになっています。 さらに Svelte チームはそこで止まりませんでした。SvelteKit はリクエストハンドラー、load 関数、フォームアクション、さらにはリモート関数に対しても専用のスパンを発行するようになりました。これにより、アプリケーションのリクエストライフサイクルのどの部分が最も時間を消費しているのか、あるいはアプリケーション内の異なるパフォーマンス特性を理解することが、はるかに容易になりました。 そして極めつけに、Sentry の SvelteKit SDK はバージョン 10.8.0 以降で、この SvelteKit の公式インストゥルメンテーションとトレーシング機能に完全対応しています！ SvelteKit のオブザーバビリティを Sentry で使う方法 […]
Sentry Logs 一般提供開始（ログはログ…でもついに実用化）
Article by: Dhrumil Parekh 本ブログの内容 何も壊れていないように見えても、裏で起きていることがわかる ジョブの実行（あるいは失敗）をリアルタイムで監視 UI のリグレッションが雪だるま式に膨らむ前に検知 これまでの反響は？ Logs の始め方 私たちが Sentry に Logs 機能を構築し始めたとき、目標は一つでした。それは、単なる大量のテキストストレージではなく、実際のデバッグに役立つものにすることです。そのために、初日から「トレースと接続」させることにしました。 これにより、アプリケーション内で発生するアクションやパフォーマンスとログを密接に結びつけ、開発者がエラーやパフォーマンス、レイテンシの問題を調査するまさにその場所で活用できるようにしたのです。 現在、Logs はベータ版を終了し、すべてのユーザーに一般公開されました。さらに嬉しいことに、ベータ期間中に皆さんから要望のあった数多くの機能を追加しています。 ライブテーリング（Live Tailing）：ログをリアルタイムにストリーミングし、修正の確認、長時間実行されるジョブの監視、または問題が発生した瞬間の特定に利用できます。 アラート（Alerts）：特定のログパターン（例: 繰り返される payment_status=declined）に基づいてトリガーし、ユーザーが報告する前に失敗を把握できます。 ダッシュボード（Dashboards）：ログの傾向を時系列で可視化します。たとえば Safari でのエラーレートの上昇や、新しい機能フラグに関連する突然のスパイクを確認できます。 チェックアウトの失敗、不安定なジョブ、ページロードの遅延。どんなデバッグであっても、Logs は重要なコンテキストを提供します。そして、それらの Logs が他のテレメトリー（トレース、エラー、リプレイ）と結びつけば、根本原因をより早く突き止めることができます。タブの切り替えも、タイムスタンプの計算も不要。ただ答えがあるだけです。 ここからは、Logs がどのようにして面倒な問題のデバッグを簡単にするのか、その実例をご紹介します。あるいは、今すぐドキュメントを参照してログ送信を始めて頂いても構いません。 何も壊れていないように見えても、裏で起きていることがわかる トレースと接続されたログは、見過ごされがちなサイレントな失敗を見つける フロントエンドは checkout.request を送信し、バックエンドは 200 を返し、問題は記録されません。例外も投げられません。 しかし、ユーザーは注文確認を受け取っていないと報告してきます。 Sentry でトレースを開くと、checkout.request のスパンは正常に見えますし、処理は成功しています。しかし、本来その後に続くはずの非同期処理 order.processed のスパンがありません。 checkout.request のスパンをクリックすると、そのスパンにスコープされたログが表示されます。 […]