【Flask × React】実装するチェックアウトフローの監視とデバッグ
Article by: Will McMullen チェックアウトフローが壊れると、顧客は「最先端」のJSメタフレームワークが廃れるよりも早く離れていきます。幸い、Sentry を使えば、顧客のチェックアウトのようなクリティカルパスにオブザーバビリティを設定するのは簡単です。ここでは、私たちがどのようにインスツルメントし、監視し、大きな問題を最小限の労力で修正したのかを順を追って紹介します。 チェックアウトフローのインスツルメント まず、ユーザーがチェックアウトプロセスとどのようにやり取りしているかを正確に追跡したいと考えました。Sentry の Distributed Tracing を使って監視ダッシュボードを設定するのは簡単でした。フロントエンドとバックエンドのアプリケーション（今回の場合は app.py と App.tsx のトップレベルファイル）でトレーシングを有効化し、/api/ エンドポイントを tracePropagationTargets に追加して Distributed Tracing をセットアップするだけで完了です。 これで、Flask と React の両方にわたって、パフォーマンスメトリクス、エラー、トレーシングデータを取得できるようになりました。 ユーザージャーニーの監視 Sentry にデータが集まるようになると、eコマースストアフロントで最も重要な要素であるチェックアウトフローを監視するためのダッシュボードを立ち上げるのは非常に簡単でした。 ここに到達するために、私たちはいくつかの主要な属性で Span データ を拡張しました。これらは Sentry で Span Metrics として可視化・監視できます。誰かが Cart.jsx コンポーネントを使うたびに、Sentry SDK でのインスツルメンテーションによって「カートに追加されたアイテム数」をそのアクティブな Span に付与し、その数を追跡できるようにしました。 実際のところ、次のような形になります。 まず、Sentry.startSpan() でスパンを作成し、次に checkoutspan.setAttribute を使って items_at_checkout を属性として追加します。ここにデバッグやパターン分析のために顧客データなど他の有用な情報を付与することも簡単にできますが、ここではシンプルに留めることにしました。 […]
【AI Code Review】バグを3万件削減、50%高速化
Article by: Lindsay Piper 先月、私たちは AI Code Review をリリースしました。これは、バグを自動で検出し、パフォーマンス問題を見つけ、PR をより速く出荷できるようにする開発者向けツールです。 リリースから30日、アップデートは次のとおりです。 自社コードでの AI Code Review の検証 これまでに、AI Code Review は3万件以上のバグを検出しました。そのうちいくつかは、Sentry のスタッフエンジニアである Ryan Brooks のサイドプロジェクト（持久系アスリート向けにトレーニング計画を作成・維持するアプリ）にも含まれていました。Strava のパフォーマンスに基づいてワークアウトを調整する、いわば「適応型のバーチャルコーチ」です。 AI Code Review はスケジューリングのロジックバグを検出しました。 「私のアプリの一部では、レース日から逆算してトレーニングの“フェーズ”を生成します。このアルゴリズムにいくつか手を入れたところ、Sentry が、2つのフェーズが潜在的に重なり得るという、起こり得ないはずのバグを正しく検出してくれました。PR のコメントをそのまま Claude Code に貼り付けたら、バグは修正されました。」 ユーザーに確実に影響していたはずのミスもありました。 「オンボーディングのフローに、3週間未満先のレースを追加できないようにするロジックを加えました。率直に言って、来週末にマラソンは走らないでしょうからね。ですが、レースの編集にも同じ React コンポーネントを使っており、Sentry がすでに予定されているレースの編集をブロックしてしまうバグを見つけてくれました。これは大きな指摘でした。」 コピペできるプロンプトで、コメントをより高速に パフォーマンスを50%改善 レビューにかかる時間が誰にとっても長すぎたため、レビューパイプラインを作り直し、平均レイテンシをおよそ50%削減しました。 実施内容は次のとおりです。 推論量が少なくてよいタスクについては、出力の一貫性を保つようプロンプトを調整しつつ、より高性能な（高速な）モデルへ切り替えました。 すべてのステップに「思考の上限（thinking budget）」を設け、仮説検証ステップには最大反復回数を設定して、考えすぎ（overthinking）を防ぎました。 評価（eval）とスポットチェックを実施し、パフォーマンス改善がレビュー品質に悪影響を与えていないことを確認しました。 要するに、レビューはこれまでより速くスリムになり、私たちはそのバランスの調整を継続しています。 […]
【Sentry Japan】HonoConf 2025 & Vue Fes Japan 2025 参加レポート ー サーバーサイド・フロントエンド両コミュニティで見えた開発者のリアル
Article by: Naru (Sentry Japan / Ichizoku 株式会社) Sentry Japanは2025年10月、2つの重要な技術カンファレンスにスポンサー参加しました。10月18日に開催されたHonoConf 2025ではGoldスポンサーとして、そして10月25日のVue Fes Japan 2025ではBronzeスポンサーとして、日本のWeb開発コミュニティとの接点を深める機会となりました。 1週間で2つのカンファレンス、合計90名の新フォロワー獲得、そしてサーバーサイドとフロントエンド、両方の開発者から得られた貴重なフィードバック。今回の参加を通じて見えてきた、日本のWeb開発市場の実態をレポートします。 🚀 HonoConf 2025: 急成長する軽量Webフレームワークのコミュニティ イベント概要開催日: 2025年10月18日会場: オンライン・オフライン ハイブリッド開催スポンサーレベル: Gold Sponsor HonoConf 2025は、エッジコンピューティング時代に注目を集める軽量Webフレームワーク「Hono」の第2回カンファレンスでした。Cloudflare Workers、Deno、Bunなど、様々なランタイムで動作するHonoは、モダンなサーバーサイド開発の新潮流として急速に支持を拡大しています。 📊 アンケート結果: サーバーサイドエンジニアのエラートラッキング事情 Goldスポンサーとして、私たちは67名の参加者から詳細なフィードバックを得ることができました。 参加者プロフィール:アンケート回答者: 67名サーバーサイドエンジニア: 51名（76%） Sentry使用経験あり: 40名（60%） この数字が示すように、HonoConfはサーバーサイドエンジニアが圧倒的多数を占めるイベントでした。エッジコンピューティングとサーバーレスアーキテクチャへの関心の高さが、参加者層にも反映されています。 エラートラッキング・監視ツール使用状況 Sentry: 55%CloudWatch: 46%その他のツール サーバーサイド開発者の間では、Sentryの普及率が55%と、モバイル開発市場（DroidKaigiでの23%）と比較して倍以上の高い認知度を示しました。これは、バックエンド開発においてSentryが既に標準的な選択肢として認識されていることを物語っています。 最も重視される機能 リアルタイム検知・アラート: […]
Sentry ハックウィークの舞台裏 壊すための口実
Article by: Hector Dearman, Nico Hinderling, Nelson Osacky Sentry ハックウィーク（社内開発週間）では、多くの「Sentaurs（Sentryのメンバー）」が、今後何年にもわたって価値をもたらす Sentry サービスの有用な拡張機能の構築にこの機会を活用しました。 しかし、私たちは違いました。 私たちは、混乱を引き起こし、クラッシュを誘発し、バグをあぶり出す機会として、初めて参加する Sentry ハックウィーク を利用しました。もっともらしさを最大化するために、プロジェクトの説明は「SaaS アプリケーション向けの LLM 主導型 Web ファジング」とし、愛称は「Gremlins（グレムリン）🧌」と名づけました。 Gremlins は、予測不能なユーザー操作を実行することでバグを発見するよう設計された、AI 駆動のファジングエージェントです。従来型のファジングが苦戦するのは、現代のアプリケーションがフロントエンド、バックエンド、データベース、補助的なサービスなど複数のコンポーネントにまたがっているためです。入力は単一のデータバッファではなく、ユーザー操作のシーケンスになっています。 Gremlins はこれを、Web エージェントを通じて意図的に混沌を作り出し、Sentry の SDK を活用してエラーを検出し、プロファイリング／トレーシングデータを収集し、セッションリプレイを取得して、何が明らかになったかを確認することで解決します。 グレムリンが見つけられるものは、実際のユーザーも同様に遭遇し得ます。 Gremlin ワークフロー 大まかには、Gremlins はシンプルな手順に従います。 ユーザーが対象サイトを設定し、必要に応じてエージェント設定を追加する エージェント（群）をサイトに放つ Gremlins があぶり出したエラーを Sentry が捕捉する 設定は軽量で、ユーザーは次の項目を指定できます。 対象サイト 任意のテスト指示（例：「設定ページを壊してみて」） 認証情報 Gremlins の数 など […]
【Unreal Engine】ゲームコンソールでクラッシュレポート提供開始 トレース連携ログに対応
Article by: Ivan Tustanivskyi, Steve Zegalia Sentry Unreal SDK の最初のメジャーリリース（現在 v1.2.0。インタラクティブなサンドボックスでも試用可能）に合わせて、クロスプラットフォームの Unreal 開発者を支援するため、プラットフォーム対応範囲、ユーザーフィードバックを用いたデバッグ、パフォーマンス監視の各面で重要な改善を行いました。 主な更新点は次のとおりです。 ゲームコンソール対応 Sentry Unreal SDK は、Unreal の platform extensions を用いてコンソール（Xbox、PlayStation 5、Nintendo Switch）をサポートするようになりました。これにより、開発機とリテール機を問わず、致命的・非致命的イベントの完全なコンテキスト（ネイティブクラッシュのフルサポートを含む）を 1 か所で取得できます。ゲームコンソール対応の詳細をあわせてご覧ください。 これまでの Unreal SDK のアーキテクチャでは、新しいプラットフォームを追加する作業が複雑でエラーが起きやすいものでした。今回の再設計により、（プラグインのように機能する）platform extensions を採用する基盤が整い、コンソール固有コードをモジュール式に統合できるようになりました。これにより、プラットフォーム API へのハードコード参照や SDK コア全体への大規模な変更を避けつつ、開発を簡素化し、NDA により保護された低レベルの実装詳細を適切にカプセル化できます。 構造化ログ Unreal SDK でも構造化ログが利用可能になりました。ゲーム内のエラーやクラッシュ、パフォーマンス問題に対して、ログ出力を取得し、関連付けることができます。つまり、プレイヤーがロード画面でスタックした場合や、アセットのストリーミング直後にクラッシュが発生した場合でも、障害に至るまでの正確なログの軌跡を把握でき、Issue ビューや Trace ビューから直接確認できます。 公開 […]
エラーメッセージを（偶然）営業マシンに変えてしまった
Article by: Dan Mindru Dan Mindru はフロントエンド開発者／デザイナーであり、Morning Maker Show の共同ホストでもあります。現在、PageUI、Clobbr、CronTool など複数のアプリケーションを開発中です。 毎日のように多くの AI スタートアップが生まれているのは、実に驚くべきことだと感じています。 私たちソフトウェアエンジニアの多くは、自らのソフトウェアが実際に何をしているのかを知りたがります。計画を立て、レビューを行い、自動テストを実施して、想定どおりに動作しているかを検証します。さらに念のため、手動テストも一巡行います。ただし、AIは例外です。 何か月も何か月もテストを重ねた末、私は落ち着かない状況に置かれることになりました。私のプロダクトは概ね正常に動作していたものの、タスクの遂行に完全に失敗することがあったのです。 実際、約90％の確率では正しく動作しました。しかし、成功率を0％から80％に到達するまでに1か月、80％から90％、あでは 3か月、そして90％から100％にするには、少なくとも12か月はかかりそうに思えました。 現在のスピード感では、「AIの時間」における12か月は、通常の時間でいうところのほぼ1世紀に相当します。ですから、毎日のように新たなスタートアップが登場する理由がすぐに理解できたのです。 結局のところ、皆すぐにローンチするのです 🤷♂️ その後、私たちは12,000人のユーザーを獲得しました。ここから、それがどのように私に有利に働いたのかを説明していきます。あわせて、最大の問題が何だったのかについてもお話ししますが、おそらく想像もつかないはずです。 どのように始まったのか 私はウェブサイト制作を変革するスタートアップを立ち上げたいと考えました。PageAI は、シンプルな説明文から本番運用レベルの Web サイトを、計画・デザイン・コーディングまで行うことができるビルダーです。聞こえは非常に壮大ですが、エラーもそれに匹敵するほど壮大でした。 予想どおり、うまくいかないこと（実際に起きたこと）も数多くありました。どのように壊れるか、すべてを把握していたわけではありませんが、少なくとも AI の出力を完全には信用できないことは分かっていました。これはセキュリティだけでなく、デザインやコード品質の観点からも同様です。 そのため、失敗を受け入れた上で、適切に対処できるようにする必要がありました。 ここで直面したのが、古典的な「鶏が先か卵が先か」の問題です。多くの人に使ってもらわない限り、どのような失敗が起こるかは明らかになりません。一方で、自分たちだけでそれを洗い出そうとすれば、資金が尽き、時代遅れのプロダクトをリリースする危険があります（ちなみに PageAI は自己資金で運営していたため、QA のスケールにも厳しい制限がありました）。 そこで、他の多くのスタートアップと同様に、私たちもローンチすることにしました。 とはいえ、私もそこまで奇抜ではありません。ローンチ前に、AI のエラーを囲い込み、可能な限り緩和しようとしました。私たちが実際に行ったことは以下のとおりです。 自前のパーサーを実装し、生成されたコードを解析したうえで「再構築」し、怪しい／危険な出力をすべてスキップ 出力を保護するために、プロンプト、チェック、エージェントフローを強化 クラッシュを防ぐために、フロントエンドで追加の処理とサンドボックス化を実装 ローンチはあらゆる指標でうまくいき、最初の1週間で2,000人のユーザーを獲得しました。 ところが、その後は静まり返っていました。誰からもクレームがないのです。何かがおかしい… 少なくとも10人に1人は問題に直面すると思っていたのに。これが最初の問題でした。 ❌ 問題1：どれほど深刻かが見えていなかった エラーが発生していることは把握できていましたが、ユーザーがわざわざその問題を報告してくれることはほとんどありませんでした。試してみてエラーが出たら、黙って競合サービスに移ってしまう。良くない状況です。 ✅ […]
段階的にブラウザのトレーシングを改善
Article by: Lukas Stracke ブラウザのトレーシングは、うまく機能しているあいだは「存在を感じさせないもの」です。しかし、一度それがうまく動かなくなると、たちまち強烈な存在感を放ちます。トレーシングが正しく機能していれば、実環境におけるアプリケーションの挙動を明確に把握でき、具体的で行動につながるインサイトが得られます。一方で、トレーシングがうまく機能していない場合、そこにあるのはノイズだらけのデータ、欠落したトレース、そして何も語ってくれないスパン。つまり、何の手がかりも得られない状況です。私たちはここ数か月、この問題に少しずつ取り組み、着実に改善を重ねてきました。 ここでは、Sentry の JavaScript SDK に施した改善を順に見ていき、ブラウザトレーシングを「より正確にする」だけでなく、「より有用にする」ための取り組みをご紹介します。ページロードスパンを明示的に制御できるようにすることから、リダイレクトのより賢い取り扱い、リソーススパンにおけるより深いタイミングデータの追加まで。これらの更新は、推測を減らし、本当に重要なものを前面に出すことに主眼を置いています。 ページロードスパンを明示的に終了する 提供開始：10.13.0 私たちの SDK では、規定でページロードやナビゲーションのスパンは「アイドルスパン」として開始されます。このアイドルスパンは、子スパン（例：fetch リクエストのスパン）が継続的に開始・終了されるかぎりアクティブな状態を維持し、一定時間アクティビティが途絶えると自動的に終了します。 なぜこの方式なのでしょうか。それは、「ページが完全に読み込まれた」と言える普遍的な指標が存在しないからです。 初回レスポンスの受信後でしょうか。すべてのスクリプトやリソースのロード完了後でしょうか。それともアプリケーションのハイドレーションやブートストラップ完了後でしょうか。 たしかに、ブラウザには domContentLoaded や readyStateChange のようなシグナルも存在しますが、初期の体感的なページロードに関わる処理がその後に続くケースも少なくありません。現実として、フレームワークや Web アプリの多様性、そして一般的な JavaScript のカオスを踏まえると、この問いに万能な答えはありません。 私たちのアイドル化とデバウンスの仕組みは、ユーザーの 95% にとって十分に機能しており、概ねページロードの所要時間に納得いただけています。しかし一部のユーザーからは、「ページの読み込み完了をアプリケーション側から Sentry に明示的に通知したい」という要望も寄せられていました。そこで用意したのが、Sentry.reportPageLoaded() です。 enableReportPageLoaded: true と Sentry.reportPageLoaded() を併用すると、アイドル機構の大部分が取り除かれ、代わりにユーザーが完全に制御できるようになります。 コールバック外でのアクティブなスパン 提供開始：10.15.0 バージョン 8 で NodeJS SDK に OpenTelemetry を導入した際、私たちは旧来のトランザクション中心の API を新しい […]
【バイブコーディング】トレーサビリティでフィードバックループを閉じる
Article by: Kyle Tryon ここ数か月で私は本気で「ヴァイブ・コーディング」を受け入れはじめ、メインのコードエディタとしては Cursor を、エージェントの LLM としては Claude Sonnet 4 を使っています。開発者にとっていまは刺激的な時代です。私たちは、生産性を100倍にしてくれるかもしれない何かを試しつつ、これらのツールを実装するための新しいワークフローや戦略を切り拓いているのです。 しかし、十分に大きなコードベースで LLM を使った本格的な開発をしたことがある人なら誰でも知っているとおり、それは「怯えた猫の群れをまとめようとするようなもの」です。 コードベースが複雑化・分散化するほど、管理すべきコンテキストは増え、ファイル固有のルールも増え、エージェントから高品質な出力を得ることが全般的に難しくなります。皮肉なことに、私たちがコードをきちんと整理すればするほど、LLM はそれを見つけるためのコンテキスト管理タスクをより多くこなさなければならなくなります。 PR のレビューやテスト生成といった AI ツール一式があっても、AI 生成コードを出荷するのは不安が残ります。ヴァイブ・コーディングで作った機能が本番を落とさないと、どうして言い切れるでしょうか。そもそも本当に動くのか、どうやって確かめればよいのでしょう。ビルドを通すためだけに、エージェントが巨大なコード片をコメントアウトしてしまうのを目にしたことさえあります。 エージェント主導のコードサイクルには盲点があります。しかし、それは修正可能です。 LLMの盲点：実行時の可視性 プロンプトを微調整したり、docstring を追加したり、エージェントのルールを洗練させたりしても、核心的な問題は解決しません。LLM は、自分が生成したコードが実際に走ったときに何が起きるのかを「見る」ことができないのです。暗闇の中で手探りでダーツを投げ、修正を重ねても照準を合わせ直せない。しかも、生成コードに現れたエラーは、LLM がその問題を見ないまま反復するほど増殖していきます。 現状のコンテキスト管理は、プロンプトにどのファイルを含めるかの管理に大きく依存しています。MCP（Model Context Protocol）は一歩先に進み、複数のデータソース間でコンテキスト情報をやり取りできるようにしてくれます。 いま Cursor や Claude Code のようなツールを、MCP 連携が限定的な形で使っているなら、あなたのコンテキストはおそらくアプリのソースコードと、多少のドキュメント、それにコピペした何かくらいに留まっているはずです。 コードを実行し、そのログを問題解決のために手動で LLM に食べさせたことがあるかもしれません。目指すべきはここにフィードバックループを組み込むことです。すなわち、コードを生成し、その実行からテレメトリ（計測情報）を収集し、その結果を LLM に知らせることで、ガイダンス付きで解法の反復を進められるようにするのです。 このフィードバックループをどう閉じるかを理解するために、まずトレースとは何か、そしてそれが欠けている「実行時の可視性」をどう提供できるのかを見ていきます。MCP サーバーを使えば、この重要なコンテキストを LLM エージェントに追加し、可視性のギャップを埋めることができます。 […]
【Session Replay】自分自身がデジタル上のシークレット・ショッパーになる
Article by: Kyle Tryon 本ブログの内容 リアルな顧客インサイトのために Session Replay を有効化する チェックアウト離脱とカート放棄の原因を診断する Session Replay を使って放棄カートを Sentry で確認する 自分のショップを次のステップへ 小売店が長年にわたってショッピング体験の測定と改善のために頼ってきた秘密兵器… それが「シークレット・ショッパー」です。 彼らは一般の客を装い、顧客体験を評価します。たとえば見つけにくい商品の特定、接客品質の評価、チェックアウトプロセスのスムーズさなど、摩擦が生じる箇所を見つけ出します。彼らが収集するデータは、偏りのない実践的なフィードバックの代理として機能し、店舗運営者はそれを基に顧客体験を改善し、コンバージョン率を高め、平均注文額を増やします。 しかし、eコマースでは小規模なサンプルや代理顧客に頼る必要はありません。Session Replay （セッションリプレイ）のようなツールを使えば、実際の購買者の行動を大規模に分析できるのです。さらに、ユーザーのセッションを「再生」して、彼らが実際に見たものをクリックごとに正確に確認することもできます。 リアルな顧客インサイトのために Session Replay を有効化する Session Replay は、ユーザー体験をまるで動画のように再現し、その時に発生したログ、エラー、トレースなどの関連情報をすべて紐づけて記録します。これにより、ユーザーが実際にどのような体験をしているのかを、当時のコンソールログなどと突き合わせながら確認することができます。 これは、ユーザー自身に報告を依頼せずに問題を診断できる非常に優れた方法です。詳細な説明やスクリーンショット、動画を求める代わりに、実際に何が起きたのかをそのまま見ることができるのです。 しかも、これは単なるエラーデバッグツールにとどまりません。「どこで迷い、どこで操作フローが途切れ、デザイン上の選択が体験にどう影響しているか」といったユーザーの行動パターンを可視化することもできます。 導入をするには、まず自分のオンラインストアのフロントエンドフレームワークに対応する正しい SDK を選び、Replays 機能を有効化した状態で Sentry を追加します。もし Shopify の Hydrogen を使ってアプリを開発している場合は、React Router SDK を利用することができます。 以下は、ご自身のアプリに簡単に組み込めるシンプルな React のセットアップ例となります。 エラー発生時や通常のセッションなど、状況に応じて Session Replay のキャプチャ率（録画割合）を個別に設定 […]
【第2回 Sentry 日本語記事投稿キャンペーン】豪華景品多数！参加者全員にプレゼント🎁
＼第2回「Sentry日本語記事投稿キャンペーン」／ ご好評頂いたキャンペーンの再開催が決定！ 今回は参加者全員にプレゼント贈呈が決定！ ＼ご参加お待ちしております／ ⭐️ Sentry に関する記事を書いて豪華景品を当てよう⭐️ キャンペーンのポイント 先着30名様限定！参加者全員に必ず当たる！ SHURE MV7+（高音質マイク）やShokz OpenComm2（大人気の骨伝導イヤホン）など、豪華景品を用意！ さらに、必ずもらえる参加賞はAmazonギフト券 1,000円〜10,000円 をランダムでプレゼント！ Sentryを使ったことがある方はもちろん、使ったことがない方にもチャンス！「Sentryをもっと便利に使うためのTipsや導入事例、活用方法を共有しましょう！」という企画！抽選でのプレゼントだけでなく、参加者全員プレゼントもあるのでぜひ気軽にご参加ください🚀 こんな人におすすめ Sentry を使い始められたばかりの方 既にご活用されていて、知見やアイデアをお持ちの方 Sentryを使っているが、新機能やカスタマイズ方法をキャッチアップしたい方 豪華景品ラインナップ ⭐️ カスタマイズが上手で賞 2名様 ⭐️ SHURE MV7+ ポッドキャストマイクロホン 新しいMV7+ポッドキャストマイクロホンは、カスタマイズ可能なLEDタッチパネルとさらに優れたDSP機能を搭載し、より高音質なオーディオでの配信が可能になります。 shure.com/ja-JP/products/microphones/mv7 ⭐️ 苦労したで賞 5名様 ⭐️ Anker MagGo Wireless Charging Station 折りたたみ式で軽量コンパクトな設計 旅行などの外出時の持ち運びにも便利です。 さらに、お好きな角度で充電しながらスマホ操作が可能です。 ankerjapan.com/products/b2557 Shokz OpenComm2 2025 […]