【React Native】Sentry にログを送る
Article by: Lewis D. Logs は、開発チームが問題を調査するときに最初に確認することが多い場所です。しかし、Logs は後回しで追加されることが多く、開発者は「ログを出しすぎる／出さなさすぎる」のバランスに悩みがちです。 経験豊富な開発者なら、調査を頼まれて 200MB のプレーンテキストのログファイルを渡された経験を覚えているかもしれません。3 時間と 4 本の Python スクリプトを費やした末に、問題が別のコンポーネントにあると分かる、というようなことです。 これまで、ロギングを簡単にするための多くの標準やライブラリが作られてきましたし、React Native にはロギング関数も豊富にあります。私たちの React Native ロギング入門ガイドは良い出発点です。ただ、さらに一段レベルを上げたいなら、このガイドで Sentry のロギング機能を使う方法を紹介します。これにより、ログが有用になり、必要な情報をすぐに取り出せるようになります。 Sentry に Logs を取り込む このガイドでは、シンプルな React Native（Expo）アプリを使って、Sentry のさまざまなロギング機能の例を示します。 このアプリは、フィールドに基本的なバリデーションがある問い合わせフォームです。手元で同じように試したい場合は、デモリポジトリ内にこのアプリがあります。 デモの React Native アプリのインターフェース 既存の React Native アプリケーションがある場合やこれから作る予定がある場合でも、このガイドでは、Sentry を使ったロギングを最大限に活用するために必要な手順を説明します。 セットアップ Sentry の機能を使い始めるには、まずプロジェクトに Sentry を導入する必要があります。最初に Sentry で新しいプロジェクトを作成し、プラットフォームとして React […]
【Logs と Next.js】壊れたものがすべてエラーとは限らない
Article by: Sergiy Dybskiy スタックトレースは便利ですが、教えてくれるのは「何が壊れたか」だけで、「なぜ壊れたのか」を教えてくれることはほとんどありません。例外が発生すると、物事が崩れた瞬間のスナップショットは得られますが、そこに至るまでのコンテキストは消えてしまいます。 そこで Logs の出番です。適切な場所に Logs があることで、何時間も悩む羽目になるか、5 分で直せるかの分かれ道になります。最近私が遭遇した実際のバグを例に、その意味をご説明します。 ボットから AI 搭載の Next.js エンドポイントを守る 私は WebVitals という、AI を活用した Next.js アプリケーションを開発していました。ドメインを入力すると、パフォーマンスデータを取得するために一連のツール呼び出しを実行し、その結果を AI エージェントが解析して、Web Vitals を改善するための実行可能な提案を返します。 フロントエンドでは会話のやり取りを扱うために、AI SDK の useChat フックを使っています。 /api/chat エンドポイントは標準的な Next.js の API ルートなので、誰でもどこからでもアクセスでき、各リクエストにはコストがかかります（OpenAI は無料ではありません）。そのため、ボットや悪意ある攻撃者がリクエストを大量に投げて請求額を跳ね上げようとするのを防ぐ仕組みが必要でした。 Vercel にはそのための良い解決策があります。 checkBotId 関数によるボット対策です。受信したリクエストを見て、ボットからのものかどうかを判定します。シンプルで効果的で、ユーザーに横断歩道を選ばせる CAPTCHA も不要です。 Firefox と Safari にだけ影響する本番バグ ローカル開発ではすべて完璧に動いていました。本番にデプロイして、Chrome でテストしても問題なし。ところが、Firefox […]
2025年もオープンソースのメンテナーに75万ドルを支援
Article by: Chad Whitacre 2025年も Sentry は日頃から頼りにしているオープンソースのメンテナーに、まとまった金額を拠出しました。これで5年連続（2024、2023、2022、2021）になりました。 これは私たちが Open Source Pledge を立ち上げて以来、最初のレポートです。 この Pledge は、コミュニティの独立したメンテナーに対する敬意を共有する企業を集めるものです。Pledge メンバーは立ち上げ以来、合計で 450 万ドルをオープンソースのメンテナーおよび財団に支払ってきました。もう言い訳はできません。企業がメンテナーに支払う時代は現実です。あなたもこの流れに参加してください。:-) いつもどおり、私たちの主要な配分（37.5 万ドル）の詳細は thanks.dev（TD）で確認できます。 これが一番簡単な方法です。thanks.dev にあなたの会社を登録して、依存しているプロジェクトのメンテナーに支払いましょう。Pledge の最低基準（開発者 1 人あたり年間 2,000 ドル）を満たし、さらにブログで発信してくれれば、私たちはあなたの会社をそのリストに追加します。参加する企業が増えるほど、参加する企業はさらに増え、オープンソースのエコシステムはより強く、よりレジリエントになります。 私たちは引き続き Open Source Collective / Ecosyste.ms Funds（7.5 万ドル）や GitHub Sponsors（5 万ドル）とも取り組んでいます。 thanks.dev と同様に、Ecosyste.ms Funds も複数のプロジェクトをまとめて支援しやすくしてくれますが、特定のエコシステムで私たちが実際に使っている依存関係を見て、どのプロジェクトを使っているかを判定する仕組みはありません。ただし、彼らの全体データは非常に優れているため、私たちは依存しているエコシステム全体に広く支援が行き渡るよう、10% を彼ら経由で拠出しています。 残念ながら、Microsoft はこの 1 年で Sponsors を事実上停止しました。Universe でも Sponsors 関連の発表はなく、AI […]
本番データを活用してバグを予測するコードレビューシステムの構築
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 リポジトリのトレースをいくつか見ていきます。 フィルタリング 変更が少ない […]
【Unity SDK 4.0.0】ゲーム機対応、ログ、ユーザーフィードバックなど
Article by: Stefan Jandl Sentry の Unity 向け SDK 4.0.0 をリリースしました。 これはこれまでで最大のアップデートです。このメジャーリリースでは、ゲーム機への包括的な対応、構造化ログ、ユーザーフィードバック機能、そしてあらゆるプラットフォームでより良いゲームを作るための重要な改善が追加されています。新機能は以下のとおりです。 ゲーム機対応 Unity 向け Sentry SDK は、Xbox と PlayStation をネイティブにサポートするようになりました。 これにより、Sentry のエラートラッキングの全機能がゲーム機にも提供されます。SDK は scope をネイティブ層へ自動的に同期するため、ゲームがゲーム機上でクラッシュした場合でも、取得された issue には C# の適切な行番号を含む完全なスタックトレースが付与されます。 さらに Sentry は、カスタムコンテキスト、タグ、breadcrumbs も提供します。こうした全プラットフォームで統一された体験により、問題がどこで発生したかに関わらず、トリアージと修正が容易になります。 構造化ログ 構造化ログが、Unity 向け Sentry SDK で本番利用可能になりました。つまり、ログ出力がゲーム内のエラー、クラッシュ、パフォーマンス問題に直接つながるようになります。 SDK は設定に応じてデバッグログの出力を自動的に取り込み、Sentry 上で閲覧・検索できる構造化ログエントリを作成します。プレイヤーがシーン読み込み中にクラッシュしたり、ロード画面で止まってしまったりした場合でも、問題に至るまでのログの流れをすべて追えるため、再現が難しい問題の診断が大幅に容易になります。 User Feedback（ユーザーフィードバック） User Feedback のサポートが、Unity 向け […]
.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 […]
【新機能】Web Vitals Performance Issue
Article by: Ben Coe 新しい種類の Performance Issue として、Web Vitals Performance Issues を導入しました。Web Vitals の指標が、パフォーマンスに関する当社の「meh」または「poor」のしきい値に下がった場合、アプリケーション内の改善余地が最も大きいページを対象に、これらの課題が作成されます。 これらの課題は Seer Issue Fix を念頭に置いて構築しました。私たちの目的は、Vitals スコアの低下を通知するだけではありません。スコアを改善するために取れる具体的な手順を提示し、可能な場合は問題の修正まで支援することです。 Web Vitalsとは？なぜ気にする必要があるのか Web Vitals は、サイトのユーザー体験がパフォーマンスの基準値と比べてどの程度かを把握するための標準指標です。Vitals の良いスコアを持つウェブサイトが必ずしも素晴らしいユーザー体験を保証するわけではありませんが、Vitals の評価が悪いウェブサイトはほとんどの場合、ユーザー体験も悪いと言えます。 とはいえ、たとえユーザー体験の向上にはそこまで関心がないとしても、Web Vitals は Google の検索ランキングや Shopify でのリスティングにも影響します。要するに、ビジネスの成果に直結します 🤑。 中でも、最も重視すべき 3 つの Core Web Vitals は次のとおりです。 Largest Contentful Paint (LCP)：ページ内で最も大きな要素が表示されるまでにどれくらい時間がかかるのかを測定します。読み込み速度の指標。 Interaction to Next Paint (INP)：ページ要素を操作したとき、次のフレームが表示されるまでにかかる時間を測定します。インタラクティビティの指標。 Cumulative […]
100ms未満のEC体験 Speculation Rules APIによる瞬時ロード
Article by: Lazar Nikolov Eコマースでは、スピードが収益に直結することは、皆さんご存じだと思います。私も知っていますし、皆さんも知っているでしょう。Amazonも、eBayも、Shopifyも、誰もが認識している事実です。この記事では、製品詳細ページやカートページ、チェックアウトページといった重要なページのパフォーマンスをどのように向上させることができるかをご紹介します。Speculation Rules API（SRA）を活用して、これらのページをプリレンダリング/プリフェッチし、さらにNext.jsのような特定のフレームワークが提供する独自のプリフェッチ機構についても説明します。 Speculation Rules API SRAは、現在 Chromiumブラウザでのみ利用可能な実験的な機能で、ウェブサイト側から「ユーザーが次にどのページを訪れる可能性があるか」をブラウザにヒントとして伝えることができます。ブラウザはそのヒントをもとに、あらかじめページをプリロードまたはプリレンダリングし始めます。これにより、そのページへの遷移がほぼ瞬時に感じられるようになります。 プリレンダリングルール（prerender rules）は、ブラウザに対して対象ページを「見えないタブ」の中で完全にダウンロードし、レンダリングし、読み込むよう指示します。これにはすべてのサブリソースの読み込み、すべての JavaScript の実行、さらに JavaScript から開始されるデータフェッチも含まれます。プリレンダリング済みページへの遷移は即座に完了します。文字通り、ブラウザが「すでに完全に読み込み済みのタブに切り替える」だけの動きになります。 プリフェッチルール（prefetch rules）は、ブラウザに対してページのドキュメント本体だけをダウンロードさせます。バックグラウンドでページをレンダリングしたり、JavaScript を実行したり、サブリソースを読み込んだりはしません。ナビゲーション時のメインドキュメントの HTTP リクエストをスキップするだけで、その後のレンダリングやリソースの読み込みは通常どおり必要になります。それでもパフォーマンスは大きく改善されますが、プリレンダリングルールに比べると処理はかなり軽量です。 これらのルールは、ページ内に <script type=”speculationrules”> 要素を追加し、その中で JSON 形式で定義します。 上記の speculation rules によって、そのページ内に存在する /products/* にマッチするすべての URL が積極的にプリフェッチされ、さらに /cart ページも 同様に処理されます。これらのルールをどのように追加するかは問いません。<head> の末尾にハードコードしてもよいですし、JavaScript でランタイムに動的生成してもかまいません。これらのルールには「締め切り」はなく、ブラウザは DOM 内でルールを見つけた瞬間にプリフェッチやプリレンダリングを開始します。 どれだけ積極的に先読みするかや、さまざまな種類のマッチャーやセレクタ、その他の注意点についてもオプションが用意されていますが、この記事では取り上げませんので、詳しくは必ずMDN の Speculation rules APIのドキュメントを確認してください。 […]
【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 […]
【Duolingo】アラート疲れを減らしてデバッグを12倍高速化
Duolingo は世界をリードする語学学習アプリであり、毎月何百万人もの学習者に、魅力的なレッスン体験を提供しています。ミッションはシンプルです。世界最高の教育をつくり、誰もが利用できるようにすること。 舞台裏では 200以上のマイクロサービスと、1日に複数回のデプロイを伴う高速なリリースサイクルがこれらの体験を支えています。これほど複雑なシステムを運用する以上、Duolingo は見逃されたバグや遅い問題解決がプラットフォームや「学習者第一」のミッションを損なわないようにする必要がありました。 暫定対応、分断されたデバッグ、生産性のボトルネック Sentry 導入前、Duolingo は同社のスケールに対応できるよう設計されていない従来型のエラー監視ツールに依存していました。その結果、煩雑なデバッグワークフローとUIがエンジニアの不満を招き、生産性を制限していました。 遅いデバッグ： 情報の検索は1回のクエリでも最大30分かかることがありました。さらに同時にクエリできるのは1人のエンジニアだけで、チーム全体に強いボトルネックが生まれていました。 ノイズ過多： 有効なフィルタリングやグルーピングがなく、無関係なデータが大量に流れ込み、重要な問題に集中することが難しくなっていました。 検索機能の制約： 短期的なスパイクのような細かなエラートレンドは、特定がほぼ不可能でした。エンジニアは手作業に頼ったり、勘に頼って原因を探したりすることがよくありました。 使いにくさと属人化： UIが扱いづらく、利用は経験豊富な少数のエンジニアに限られていました。その結果、「パワーユーザー」への依存が生まれ、他のメンバーは貢献に必要なツールやコンテキストを得られない状態でした。 コンテキストと可視性の不足： 取得できるメタデータが最小限で、エラーと根本原因の相関も弱かったため、開発者は複数の情報源からコンテキストを寄せ集める必要がありました。こうしたコンテキストの切り替えが解決までの時間を延ばし、生産性を下げていました。 さらに悪いことに、この従来ツールでは課題をすべて解決できず、ワークフローに重要な穴が残っていました。チームは暫定対応を素早く出せてはいましたが、それは場当たり的な対症療法になりがちで、根本原因は未解決のまま残り、同じ問題が後から何度も再発することがありました。 「単純なデバッグですらマラソンのように感じました。ツールが分かりにくく、デバッグできるのはパワーユーザーだけで、他の人は簡単に理解できなかったのです。全員にとってデバッグを効率化するためのツールがありませんでした。」と、Duolingo の Staff Site Reliability Engineer である David Amin 氏は言います。「単に時間を無駄にしていたという話ではありません。すべてのエンジニアが、素早く問題を解決できるという自信と能力を持つためのツールがなかったのです。」 システムとチームの複雑さが増すにつれ、Duolingo は、よりスケーラブルで開発者にやさしいエラー監視とデバッグのアプローチを求めるようになりました。 Duolingo が Sentry を選んだ理由：実装の簡単さ＆インサイトまでの時間の短縮 選択肢を評価した結果、Duolingo は最小限のセットアップで最大の課題に対処できることから Sentry を選びました。分かりやすい導入と開発者中心の設計により、チームは採用しやすく、すぐに効果を得られました。 200以上のマイクロサービスを2週間未満で移行： Sentry のAPI、Terraform 対応、分かりやすい設定により、200以上のマイクロサービスをわずか2週間で移行できました。 解決までの時間を12倍高速化： リアルタイムクエリ、直感的なダッシュボード、深いコンテキストにより、エンジニアはノイズを素早く絞り込み、トレンドを可視化し、問題箇所を特定できました。すべてを1つのツール内で完結できます。以前は原因の特定がほぼ不可能で、何時間、場合によっては何日もかかっていました。いまは数分の話です。 ノイズ削減： 組み込みのグルーピング、フィルタリング、Spike Protection、オーナーシップルールにより、ノイズを取り除き、重要な問題だけを検知して適切なチームへルーティングします。これによりアラート疲れが軽減され、重要なエラーに集中できます。さらに明確さを得たことで […]