【AIエージェント】ハイプか現実か？
Article by: Dan Mindru 数年前はブロックチェーンが話題の中心でした。その前はIoT、その前はビッグデータ、さらにその前はクラウドでした。それぞれの時代が一種のパラダイムシフトをもたらし、大規模な投資と約束が生まれました。成功したものもあれば、そうでないものもありましたが、いずれもテクノロジーの進化を促進したといえます。 現在、私たちは2022年頃にOpenAIから始まったAIの誇大広告サイクルを全面的に受け入れています。しかし、今回はこれまでとは異なる感覚があります。マーケティングが優れているからではありません（「OpenAI」の「Open」と「AI」について議論の余地はあります）が、前例のない速度で実際のアプリケーションが次々と登場しているからです。これは未来の約束ではなく、「今」起きている現象です。そして、その進展は非常に速いのです。では、どのくらい速いのか。その速さは、2025年の現在、誰もが次のビッグトレンドである「AIエージェント」に飛びついていることからもよくわかります。 OpenAIは「Operator」を発表しました。これは自分のブラウザを使ってユーザーのためにタスクを実行できるAIエージェントです。中には2024年の時点で一足先にAIエージェントをリリースした企業（Chatbaseなど）もあります。 しかし、そもそもAIエージェントとは何でしょうか？ 初めて聞く方にもわかるように説明しましょう。14歳の子どもにも説明できると言いたいところですが、正直なところ、最近では私たちより彼らの方がAIエージェントについて詳しいかもしれません。 では、始めましょう！ AIエージェントとは？ 想像してみてください。 あなたの会社で極秘のエンタープライズアップグレードが導入されたとします。ITチケットも不要、ダウンタイムもなし、マニュアルもいりません。目に見えない裏方チームが、カスタマーサポートの対応、コードの記述、ドキュメントの翻訳、マーケティングコピーの作成など、あらゆる作業を同時にこなします。しかも月額200ドル、24時間365日稼働し、「至急」案件も数分で「完了」へ。ミーティングもオンボーディングも不要。まるでワークフローに誰も予想しなかったターボボタンを追加したようなものです。それがAIエージェントであり、どのように見ても魅力的です。 では、仕組みはどうなっているのでしょうか？ AIエージェントは、大規模言語モデル（LLM）を強化するためのシステムであり、タスクの計画、サードパーティサービスとの統合、プロンプトの連鎖による回答の洗練を行います。 LLMとは？LLM（大規模言語モデル）は、大量のテキストデータで学習されたディープラーニングモデルで、人間のような言語を理解し生成します。文章の次に来る単語を予測し、質問への回答、コンテンツの執筆、言語の翻訳、アイデア出しなどを、学習データ内のパターン認識を通じて実行します。 簡単に言えば、比較的シンプルなプロンプトを受け取り、それを複数のプロンプトとAPIコールの組み合わせに変換できます。もちろん、単一のプロンプト実行よりはコストが高くなります（この点については後述します）。話を複雑にしすぎずに言えば、AIエージェントのワークフローは「彼ら」が従うフローに基づいて大きく2つのカテゴリーに分かれます。 処方型ワークフロー 探索型ワークフロー これらについて詳しく見ていきましょう。 処方型ワークフロー 単一のレスポンスで完結 シンプルに言えば、AIエージェントは「通常の」プロンプトを連結したものです。魔法のようなものではありませんが、実用的な実装が可能になります。 例えば、AIエージェントのシンプルな実装は、好みのAIモデルに対して複数回のLLMコールを行うforループであり、その前後にサードパーティAPIコール（あるいはインテグレーション）を組み合わせる形です。 一部のAPIコールは他のサードパーティAPIへのアクセスでもあり、ユーザーの「ゲート」（入力待ち状態）によって制御される場合もあります。 これは、リアルタイムデータや他のシステムに隔離されたデータへアクセスするなど、LLMの本質的な制限を克服するのに特に有効です。 例えば、AIエージェントが従業員の休暇申請を処理するケースでは、内部APIを介して分離された人事データベースにアクセスし、残りの有給休暇を確認し、条件を満たせば自動承認する、という流れです。 他の例としては以下のようなものがあります。 カスタマーサポートFAQエージェントクエリの意図を特定するために4つのプロンプトを連鎖させ、内部ナレッジベースから関連情報を取得し、ユーザーにわかりやすい形で返します。 コンテンツ作成ワークフローブログ記事作成のために3つのプロンプトを連鎖し、アウトラインの生成、各セクションへの展開、最終稿のスタイル調整までを行います。 ミーティングスケジューラーAPIコール、プロンプト、再度APIコールを連鎖し、個人のカレンダーを確認し、最適な時間にミーティングを提案・予約し、Slackチャンネルへ通知します。 処方型ワークフローでは、タスクを小さなマイクロタスクに分割し、並列処理したうえで最終的に1つのレスポンスにまとめることもできます。このアプローチは非常に高性能かつ柔軟性があります。 さらに、各マイクロタスクがそれぞれ独自にAPIコールを行い、リアルタイムデータや隔離されたデータを取得することも可能です。 つまり、これらのワークフローは、私たちがよく知っていて好むLLMの特性（文脈理解、タスク非依存の多用途性、柔軟な推論、人間らしい対話など）を活かしつつ、それ単体では難しい、あるいは不可能な機能を補完しています。 処方型ワークフローの利点はコストが予測しやすい点です。単一のLLMコールよりは高くなりますが、APIの使用量やタスクの複雑さが一定ならコストは安定します。 しかし、統合数を増やすと難易度や非効率が増すこともあります。APIコールがすべて必要とは限らず、場合によっては動的なユーザー入力が求められることもあります。 では、もしエージェント自身がこれを判断できたらどうなるでしょう？ 探索型ワークフロー：適応的かつ動的 ここまで読んでこう思ったかもしれません。 「AIエージェントって、トレンチコートを着たLLMコール3回分の塊じゃない？」 しかし、実は時には冬用ジャケット、金融用ベスト、さらにはダサいクリスマスセーターにもなり得ると言ったらどうでしょう？実際、すべてのAIエージェントが同じように作られているわけではありません。多くのエージェントはプロンプトの連鎖に基づいていますが、それだけでなく計画、推論、反復、自己指向的なワークフローの遂行も可能です。 探索型ワークフローは動的で適応性があります。処方型ワークフローで可能なすべての経路をたどることができますが、あらかじめ定義されているわけではなく、APIやインテグレーション、人間からのフィードバックに基づいて自ら計画・実行・適応します。根本的には、プロンプト技法、ループ処理、APIコールの集合体です。そこにユーザー入力を少し加えることで、数年前には構築不可能だったようなシステムが実現できます。 このようなワークフローは、より汎用的になり、ツールやAPIコールの数に関わらずスケールし、何千もの個別かつ動的なワークフローを構築できる可能性があります。これも拡張手法の一つですが、より多くの工夫が加わっています。 動的な計画立案：エージェントが中央レジストリから使用するツールを自分で決定します。 ツール統合：OpenAPI仕様のようなコンテキストを利用して、CRMシステムや各種APIと統合します。 セキュアアクセス：OAuthのようなプロトコルを使い、エージェントが安全にプライベートデータへアクセスします。 反復的推論：結果を評価し、成功または失敗の基準に達するまで計画を調整します。 フィードバックループ：強化学習や人間のフィードバックを通じてパフォーマンスを改善します。 例えば、クラウドストレージやメールを横断検索するよう指示されたAIエージェントを考えてみましょう。このエージェントは、必要に応じてDropboxやGmailのAPIを呼び出し、実行ステップを動的に計画し、タスクが完了するまで結果に基づいて繰り返し処理を行います。実際のアプリは単純な入力インターフェースであり、ユーザーは「Dropboxを検索」といった特定のサービスを指定したり、「メールとカレンダー全体を検索」といった一般的な指示を出したりします。 […]
【React Native】ログ出力ガイド
Article by: Matthew C. コンソールによる基本的なログ出力は、アプリのデバッグや理解を始める上で良い出発点です。より大規模で複雑なアプリでは、追加情報の記録やログの永続化が有効になります。 このガイドでは、React Native においてログを作成・表示する方法、カスタムログをファイルに保存する方法を学びます。 JavaScript のログを中心に扱いますが、Sentry の React Native SDK を使用し、従来のログを超えたエラー・例外の自動報告やそれに至るイベントの可視化方法についても紹介します。 コンソールメソッドとログレベル React Native では、Web ブラウザと同じコンソールメソッドが使用できます。 ほとんどのコンソールメソッドには、重大度（Severity）のレベルが割り当てられています。以下の 4 段階があり、軽いものから重いものの順に、それぞれの用途を示しています。 Verbose（冗長）：デバッグ用のログメッセージ。 Info（情報）：コードが期待通りに動作しているときのログ（例：ユーザーが支払いを完了した時）。 Warning（警告）：問題につながる可能性のあるイベントのログ。 Error（エラー）：実際のエラーのログ。 以下の表はよく使われるコンソールメソッドと、それぞれに割り当てられたログレベルを示したものです。 console.debug メソッドは、console.log や console.info と同様に動作しますが、ログレベルが異なります。console.trace メソッドは、スタックトレース（関数の呼び出し履歴）をコンソールに出力するために使用されます。 console.time と console.timeEnd メソッドを組み合わせて使用することで、処理にかかる時間を測定できます。 オブジェクトのログ出力 本番環境のアプリケーションでは、文字列よりもオブジェクトをログに出力した方が良い場合があります。 構造化されたログ出力（Structured Logging）により、JSON としてパース可能なログファイルが作成されます。これにより、監査ツールでログをデータベースのように検索できます。可能であれば、あらかじめログプロパティのセットを定義しておくと、ログの整理や検索がしやすくなり、エラー追跡や分析がよりスムーズになります。 コンソールログの表示方法 React Native の開発サーバーを起動すると、Metro […]
PlayStation・Xbox・Switch・PC・モバイル どのプラットフォームでもSentry がバグの修正をサポート
Article by: Sasha Blumenfeld ボス戦でのフリーズでも、マルチプレイ中の突然の切断でも、クラッシュは没入感を壊し、プレイヤーを怒らせてしまいます。しかも各プラットフォームごとに異なるエラー報告システムがある中で、これらの問題をデバッグするのは非常に困難です。 Riot Games、Epic Games、Unity を含む 1,500 社以上のゲーム企業が Sentry を使用して自社プロダクトを監視しており、当社はゲームエンジンおよびコンソールとの統合サポートを継続的に拡充しています。Unreal Engine、Unity、Godot、社内エンジンのいずれで開発していたとしても、PlayStation、Xbox、Nintendo Switch 向けに出荷していても、Sentry は本番環境におけるクラッシュ、エラー、パフォーマンス問題を分散したログを探し回ったり、プラットフォーム固有のツールを切り替えたりすることなく追跡できます。 Sentry を使えば、すべてのプラットフォームで発生したネイティブクラッシュや例外を一箇所に集約できるため、こうした問題を簡素化できます。読みにくいメモリアドレス（長い 16 進数の数字列）と格闘する代わりに、Sentry はシンボル化されたスタックトレースを提供し、どの関数のどのコード行がクラッシュを引き起こしたのかを正確に示してくれます。 以下のような充実したコンテクスト情報を得ることができます。 読みやすいスタックトレースやパンくずリストにより、クラッシュ直前のプレイヤーの操作、エンジンイベント、システム動作を記録。何が壊れたかだけでなく「何が起きたのか」を把握できます。 ビルド番号やOSバージョンの追跡により、クラッシュが特定のアップデートに関連しているのか、古いシステムを使用しているプレイヤーのみに影響しているのかを判断できます。 クラッシュ時のスクリーンショットを記録し、ゲームが停止する直前のプレイヤーの視点を把握できます。 クロスプラットフォームでの可視化により、コンソールの問題を認証の障害となる前に解決できます（パブリッシャーに「なぜリリースできなかったのか」と説明することは、誰にとっても望ましくありません）。 開発用キットでは正常に動作していたにも関わらず、市販のハードウェア上で突然クラッシュが起き始めた… という場合でも、Sentry なら、原因（たとえば物理エンジン内のヌルポインタ例外）を正確に突き止め、プレイヤーの怒りが爆発する前に修正することができます。 Nintendo Switch 向けゲームで Sentry を使用するには、Nintendo のサーバーを設定してクラッシュ情報を Sentry に自動で転送するようにします。まずは Nintendo の CRPORTAL から始めてください。 Xbox 向けには、Microsoft の GDKX Middleware 認証ページで Sentry を見つけて、そこから導入を開始できます。 そして最後に、PlayStation 向けには Tools & […]
【Mobile Vitals】ユーザーがアンインストールする前にモバイルアプリの動作遅延を修正
Article by: Will McMullen, Markus Hintersteiner モバイル開発者なら、この苦労をよく知っているはずです。小さなリグレッションが本番環境では大きな問題につながることがあります。しかも、それを修正するのは簡単なパッチを即座に反映すれば済むというものではありません。Webアプリと違って、モバイルアプリの修正にはアプリストアの審査を通す必要があり、場合によってはクライアントとのミーティングに参加し、再現が難しい問題のデバッグに取り組むこともあります。 ★1レビューが届く前に、こうした問題を検知することが極めて重要です。幸いなことに、Sentry がこの作業をこれまでになく簡単にしてくれました。 Mobile Vitals ― インサイト機能に新たに追加されたこのツールは、アプリの起動や画面の読み込み、描画が遅い箇所をハイライト表示することで、フリーズやラグによる操作不良を、ユーザーが怒ってアプリを終了してしまう前に迅速に対処できます。React Native、Flutter、Android、iOS ― どのプラットフォームで開発していても活用できます。では、何ができるのか見ていきましょう。 （ちなみに「Mobile Vitals」については数年前にも取り上げています。この新ツールの仕組みに興味がある方は、こちらの記事もあわせて読むと面白いと思います。） Mobile Vitals は何を計測しているのか？ 1：アプリ起動のパフォーマンス インスタグラムでレシピを延々と見ていたら、突然カロリー計算アプリの良さそうな広告が表示されました。試しにダウンロードしてみたものの、なぜか初回の起動に20秒、2回目以降でも10秒かかる。さて、あなたはどうしますか？ オレオを食べながら、遅い起動に耐えるか、それとも体重計に戻るか… Sentry はユーザーがイライラしてアプリをアンインストールする「無駄なカロリー消費」を防ぐために、アプリ起動のパフォーマンスを計測します。ここで注目しているのは、コールドスタートとウォームスタートの2つの指標です。 コールドスタート第一印象は取り返しがつきません。Sentry はコールドスタートを個別に計測することで、最新のパッチが第一印象を台無しにしないかどうかを確認できます。 ウォームスタート iOS や Android のメモリ管理は複雑で、アプリをバックグラウンドで「ウォーム」に保ちながら、一部のタスクを停止することがあります。最近使用したアプリ一覧から再び起動するときには、アプリがすぐに立ち上がることが求められます。 重要なのは、上位の指標だけではありません。ウォームスタートにおいて、Sentry は iOS および Android アプリに対して非常に細かく自動で計測を行います。たとえば iOS では、実行前処理、UIKit、フレームレンダリングなど、さまざまなネイティブ処理を個別に確認でき、アプリの読み込みを遅らせているボトルネックを特定・修正できます。 各画面をクリックすると、その画面に至るまでの最新のアプリ読み込み状況が一覧で表示され、さらに詳細に掘り下げて、どの処理がボトルネックになっているかを確認できます。 2：画面読み込みのパフォーマンス コメントページを開くたびに毎回5秒かかるようでは、誰もコメントを残しません。話はそれだけシンプルです。 Sentry は各画面の読み込みについて TTID と TTFD を計測することで、UX の重さを軽減するのに役立ちます。 TTID（Time to Initial […]
React.js パフォーマンスガイド
Article by: Armin Ulrich 最もパフォーマンスが高い JavaScript フレームワークはどれでしょう？React、Vue、Svelte、Angular…？この問いに答えようとするとき、私たちはしばしばリアクティビティ、バンドルサイズ、メモリ使用量などのベンチマークの比較に迷い込んでしまいます。 もちろん、パフォーマンスの高いアプリを作るために最適なフレームワークを選びたいものです。しかし、React アプリに限らず、Web アプリ全般におけるパフォーマンス最適化のベストプラクティスに従わなければ、フレームワークの性能だけではアプリの恩恵は得られません。 では、どこから始めればよいのでしょう？パフォーマンスに影響するのは何でしょうか？ このガイドでは、Reactにおけるパフォーマンス最適化の基本を解説し、この分野をさらに深く学ぶためのツールやリソースを紹介します。 なぜパフォーマンスに投資すべきか パフォーマンス向上 = ユーザー体験の向上 遅いアプリに時間を割く人はいません。人々は素早く物事を済ませたいのです。あなたのアプリはそのための道具です。パフォーマンスはアプリとブランドへの信頼を築き、良好な体験を提供する助けになります。 パフォーマンス向上 = コンバージョン率と継続率の向上 優れたユーザー体験は、コンバージョン率と継続率（＝どれだけ多くの人が登録し、使い続けるか）を高めます。つまり、パフォーマンスはアプリの成功に直接貢献します。 パフォーマンス向上 = SEOの向上 検索エンジンはパフォーマンスの高いページを上位に表示し、ユーザーエンゲージメントも評価対象とします。ユーザーが必要な情報を効率よく見つけられて長く滞在するなら、それがSEOパフォーマンスにも良い影響を与えます。 パフォーマンス向上 = スケーラビリティの向上とコスト削減 パフォーマンスのベストプラクティスに則ったコードベースは、システムが複雑化しても保守や拡張がしやすく、インフラコストも少なくすみます。 React によくあるパフォーマンス問題 8選とその解決方法 パフォーマンスについて話すとき、通常はアプリの読み込み時間や応答性を測る指標を指します。 読み込み時間とは、アプリが必要とするコードやアセットをすべて読み込むのにかかる時間のことです。これには、FCP（First Contentful Paint）、LCP（Largest Contentful Paint）、TTI（Time to Interactive）などの指標が用いられます。 応答性または実行時パフォーマンスは、スムーズな（再）レンダリングに関わるすべての処理を指します。ここではReactコードそのもののパフォーマンスが大きな要因になります。応答性を測るための重要な指標にはINP（Interaction to Next Paint）があります。さらに、プロファイリングやモニタリングツールを使ってトランザクションの実行時間を測定したり、フレームレート、CPUやメモリの使用量を確認したりすることも可能です。 アプリの読み込みと操作感をどちらも高速に保つには、これら両方のパフォーマンス指標を考慮する必要があります。それでは、よくある問題とReact特有の、あるいはReactに限らない解決策を見ていきましょう！ 1. バンドルサイズが大きい アプリが大きければ大きいほど、読み込みに時間がかかります。これは当然のように聞こえますが、実際にはパフォーマンスを大きく改善できるポイントのひとつです。目標は常に、可能な限り少ないコード（およびその他のアセット）をブラウザに送ることです。 バンドラの使用と最適化Webpack […]
【Breakpoint まとめ】稼働監視・ロボット・豊富なフィーチャーフラグ
Article by: Sasha Blumenfeld バグは丁寧に現れることはなく、チェックアウト機能をクラッシュさせ、認証を破壊し、APIの応答速度を極端に低下させます。しかも多くの場合、CEOから進捗状況を尋ねられる直前に発生します…。さらに、エラー通知ボックスが「TypeError: cannot read property of undefined」の亜種で埋め尽くされると、真に重要な問題を見極めることが困難になります。 そのため、デバッグにおける推測作業を排除するためのアップデートを展開しました。調査に費やす時間を短縮し、開発に集中できるようにすることが目的です。ユーザーに影響が及ぶ前にダウンタイムの通知を受け取り、サイト上で関連する問題やユーザーからのフィードバックを直接確認できます。また、AIによるアラートのグルーピング機能により重複を整理し、AI支援による修正により、問題の迅速な解決が可能になります。 アプリ障害、上司より先に気づけていますか？ プロダクション障害はそれだけで問題ですが、それを CEO の Slack メッセージで知るのは最悪です。 現在一般提供中の Uptime Monitoring を使えば、SNS で炎上したり、全社ミーティングで取り上げられたりする前に、障害を検知することができます。 最短60秒間隔で実行されるグローバルチェックにより、障害発生の瞬間を即座に把握できます。 以下のことが可能です。 重要なフローの監視たとえば、購入処理が突然止まったかどうかを検出するためのチェックアウトページやユーザーがログインできなくなっているかを確認するログインエンドポイントなどです。 カスタム条件の設定たとえば、ダウンタイムが60秒を超えた場合にのみ通知を受け取るように設定可能です。 普段使用しているツールでの通知Slack、PagerDuty、Teams、または Webhook 経由です。 たとえば、チェックアウトページが突然タイムアウトし始めたとしましょう。顧客からの苦情を待つ代わりに、即座にアラートが届きます。障害ログを確認すると、サードパーティの決済サービスの応答が遅いことが分かります。Sentry のエラーやトレースと照合することで、その遅延がどこで発生しているのか（APIの障害か、ネットワークの問題か、自分たちのコード内の何かか）を正確に特定でき、売上の損失が積み重なる前に修正できます。 私たちはこれまでに 40,000件のダウンタイムを検知しており、それらが大量のサポートチケットに発展する前に、チームが問題を特定できるよう支援してきました。 モニターは1つ無料でご利用頂けます。追加はモニター1つあたり月額1ドルです。HTTPメソッド、ヘッダー、ボディパラメータなど、リクエストの詳細を完全にコントロールし、特定のURLに対するカスタムアラートを作成できます。ぜひ試してください。詳細はブログでもご覧頂けます。 重複したエラーを掘り返すのはやめましょう エラー受信箱が多数の通知で溢れていても、それが本当に10件の異なる問題なのでしょうか。それとも同じ問題の50通りのバリエーションでしょうか。現在受信しているアラートが、実は過去に対応済みのエラーの再通知である可能性もあります。 このように終わりのないアラートの中で混乱するのではなく、Issue Grouping を活用することで、関連するエラーを自動的にグループ化し、イズを削減できます。その結果、本当に修正すべき課題に集中することが可能になります。 例えばアプリケーションの複数箇所で API が、500 Internal Server Error を返している場合でも、Issue Grouping（AI Grouping）は、それらが単一の根本原因によるものなのか、複数の独立した問題なのかを判別します。また、ステージング環境と本番環境をまたいでエラーをグループ化できるため、同じ問題を重複して調査する無駄を防げます。 […]
アプリがダウン？今すぐ復旧！Sentry アップタイムモニタリングをご紹介
Article by: Sasha Blumenfeld, Gabriel Lopes Sentry もダウンタイムとは無縁ではありません。実は私たちはかつて、誤ったマイグレーションによって自社のアプリケーションを停止させてしまったことがあります。重要なデータベーステーブルにフィールドを追加しようとしたところ、そのマイグレーションがテーブル全体をロックしてしまったのです。このテーブルは Sentry の動作に不可欠だったため、アプリ全体が停止してしまいました。ウェブサイトは読み込めず、データの取り込みも止まり… すべてが完全に止まってしまいました… 私たちはすぐに問題のクエリを特定して停止させましたが、もし主要なページにアップタイムモニタリングを設定していれば、もっと早く異常に気づけたかもしれません。これこそが、Uptime Monitoring を開発した理由です。 開発者が障害の原因を突き止めようと右往左往しているその1秒ごとに、ユーザーはページをリロードし、苛立ち、あるいは離れていきます。にもかかわらず、通常の対応プロセス（あるツールでアラートを受け取り、別のツールでログを調べ、何が起きたかを手作業でつなぎ合わせる）は遅くて苦痛を伴います。 私たちはトラブルシューティングの断片化が復旧を遅らせることを身をもって体験しました。だからこそ、障害が発生した瞬間に検知し、その修正に必要なコンテキストまで一か所で得られる仕組みを作ったのです。 Sentry の Uptime Monitoring は、単に「何かが落ちた」と通知するだけではありません。バグのあるコード、失敗したAPI、またはまったく別の原因かどうかを特定し、根本原因へと導きます。 Sentry Uptime Monitoringは、すべてのユーザーにご利用いただけるようになりました。すべてのプランに1つの無料モニターが含まれています。ユーザーが気づく前に、あなた自身でダウンタイムを検知しましょう。 Sentry の Uptime Monitoring Sentryはサイトの稼働状況を監視し、ダウンタイムが検出された際に通知します。 設定されたURLに対して60秒ごとに HTTP リクエストでヘルスチェックを行い、Web サービスを能動的に監視します。タイムアウト、DNS 解決エラー、不正なレスポンスなど、問題が検出されれば即座に通知されます。 9月末のベータリリース以降、すでに約10万件のアクティブなアップタイムアラートが作成されました。さらに、皆さまからの要望が多かった機能も多数追加し、より使いやすくなっています。 チェック履歴「すべてが崩れる前にサイトが正常に動いていた証拠があれば…」と思ったことはありませんか？今ならあります。チェック履歴を使えば、過去のアップタイムチェックを確認したり、パフォーマンストレンドを追跡したり、ダウンタイムと他の問題との関連を見つけ出すことができます。詳しくはこちら アップタイム問題詳細画面のUXを改善インシデント調査時により多くの情報が得られるよう、問題詳細ページを全面的に刷新しました。これにより、チェック履歴のタイムライン表示、すべてのアップタイムチェックのクイックビュー、関連リクエストのトレースビューにアクセスできるようになっています。 分散トレーシング対応アップタイムチェックが失敗したとき、探偵のように手がかりを追いかけたくはありませんよね。バックエンドサービスがSentry SDK でインスツルメントされていれば、リクエストのトレースをアップタイムチェックに自動的に関連付けます。そのため、必要なスパンや問題にすぐにジャンプでき、手作業で情報をつなぎ合わせる必要はありません。 地理的に分散されたチェック午前3時の誤検知ほど、気分を台無しにするものはありません。ダウンタイムの見逃しと不要なアラートの両方を減らすため、現在は複数のロケーションからアップタイムチェックを実施しています。異なる地域で3回連続してチェックが失敗した場合にのみ、ダウンタイムとして認識される仕組みです。そのため、本当に対応が必要なときだけ、アラートが届きます。 モニター設定の追加オプションすべてのサービスが同じではないように、モニタリングのニーズも一様ではありません。今では、各スタックに最適な形で、チェック間隔やタイムアウトの設定をカスタマイズできるようになりました。 よくあるダウンタイムの原因 — Uptime Monitoring がどう役立つか 壊れたコードのプッシュ 一見無害に思えた変更をプッシュした結果、システム全体が危機的状況に陥ったという経験を、誰しも一度はお持ちではないでしょうか。あるチームでは、非同期ジョブ内の単純な型エラーが原因で、購入処理用の配信システムがクラッシュし、あわや大惨事という事態になりました。1つのジョブだけが失敗するはずが、クラッシュによってキュー全体がブロックされ、以降のすべてのジョブが実行されなくなったのです。 そしておなじみの JavaScript の典型的なミスといえば、1ページを更新したつもりが、サイト全体を壊してしまうことです。ある開発者はそれを痛い形で学びました。テストではすべて問題なく見えていたにもかかわらず、ほんの小さな見落としが大きな混乱を引き起こしたのです。そのコードは、特定の要素が常に存在すると仮定し、すべてのページで実行されていました。nullチェックがなかったため、該当の要素が存在しないページは即座にクラッシュが発生しました。 このコードは、なぜかPRレビューと社内テストを通過してしまいました。というのも、テスト対象となっていたのは、更新されたページのみだったからです。 […]
【PHP】デバッグとログの方法
Article by: Richard C. このガイドでは、PHP におけるエラーの仕組みと、それらをログ関数や Sentry を使って効率的にデバッグする方法を説明します。 このガイドの情報は PHP 8 に対して正確であり、将来の PHP バージョンの変更内容によっては、それ以降のバージョンにも適用できる可能性があります。 PHP のデバッグとロギングの前提条件 このガイドのすべてのコード例は、ホスト OS を問わず Docker 上で実行できます。Docker をお持ちでない場合は、こちらからダウンロードしてください。 すでに PHP がインストールされている場合、Docker は必須ではありません。ただし、Docker 上でコードを実行すると、以下のような利点があります。 Docker サンドボックス内で実行される悪意あるコードから、マシンを保護できます。 チーム内のすべてのプログラマーが、同じ IDE プラグインと PHP バージョンを使った共通の環境で作業できます。 物理マシンを再設定することなく、開発環境を本番サーバーと簡単に一致させることができます。 PHP の例外とエラー まずは、PHP における例外の仕組みを見ていきましょう。 エラーとはPHP 本体またはその拡張機能内で発生する内部的な問題です。例外とはPHP 開発者（つまりあなた）が書いた外部の PHP コードで投げたり捕捉したりできるオブジェクトの一種です。エラーと例外はどちらも Throwable オブジェクトです。 PHP が生成するすべてのエラーには型が含まれます。以下の PHP エラーの種類の一覧を見てください。それぞれの型の動作と、その原因となる状況について簡単に説明されています。 エラーには主に […]
Transformer ベースのテキスト埋め込みモデルで Sentry アラートを 40% 削減 ー ノイズを突破
Article by: Tillman Elser, Josh Ferge Sentry は Issue Grouping（イシューグルーピング） を使用して、同一のエラーを集約し、重複するイシューの作成やアラートの送信を防止しています。 しかしこれまでにユーザーから最も多く寄せられていた不満の一つは、既存のアルゴリズムでは一部のケースで類似エラーが十分にまとめられず、Sentry が別々のイシューやアラートを生成してしまうことでした。これにより、開発者にとって不要な混乱、あるいは少なくとも煩わしさが生じていたのです。 この課題に対応するため、私たちは過去最大規模のイシューグルーピングアルゴリズムの改良を行いました。新しいAI搭載のアプローチでは、Transformer ベースのテキスト埋め込みモデルを使用し、新規イシューの生成数を40%削減しつつ、エンドツーエンドの処理レイテンシーを100ミリ秒未満に維持しています。 本記事では、このAIを活用したイシューグルーピングの開発・テスト・デプロイのプロセスについてご紹介します。 なぜ重複イシューが発生するのか Sentryの主要な価値は、ログを延々と読むことなく、必要な情報に素早くアクセスできる点にあります。新たな問題が発生すると、イシューフィード、メール、メッセージングプラットフォームなどを通じて開発者に通知されます。この一連のプロセスの鍵を握るのが、グルーピングアルゴリズムです。 経験豊富な開発者であれば、2つのスタックトレースを比較し、それらが同一の問題かどうかを判断するのはそれほど難しくありません。しかし、この判断プロセスを堅牢なヒューリスティック（経験則）として実装するのは容易ではありません。 たとえば、Reactアプリケーションでは、同じ「Invalid prop」エラーが異なるスタックフレームの順序で出現することがあります。あるときは validateProp(Select.js:42) に続いて Anonymous Component(App.js:123) が現れたり、逆の順番になったりすることもあります。同様に、Python では一見同じ KeyError が、コードのリファクタリングによりわずかに異なる行番号（たとえば line 145 と line 147）で発生することもあります。 さらに、非同期処理（async） はより一層複雑になります。たとえば Python の async 関数内で ValueError が発生した場合、それが asyncio/tasks.py を経由するか asyncio/runners.py を経由するかで、同じエラーが異なる実行パスを通って表面化することがあります。 私たちのグルーピングアルゴリズムは、これらのバリエーションを同一の根本原因として扱いつつ、明確に異なるエラーは正しく区別できなければなりません。しかも、Sentry は高速かつ効率的である必要があります。イベントの取り込み速度の低下や処理コストの増大は許容されません。 従来のグルーピング手法の問題点 従来のグルーピングアルゴリズムは、段階的に広いマッチング戦略を適用しながら、各エラーに対してユニークなフィンガープリント（指紋）を生成することで動作します。最も精度の高い手法であるスタックトレースの分析から始まり、アルゴリズムは各フレームを検査します。その際、アプリケーションコードとサードパーティライブラリを慎重に区別し、さらにプラットフォーム固有のルールに従って正規化を行います。 たとえば、Python のトレースバックと、難読化された JavaScript […]
Sentry のゲームエンジン対応でスムーズなプレイ体験を実現
Article by: Bruno Garcia Sentry はすでにご利用中のツールと直接統合され、Unity、Unreal Engine、Godot においてリアルタイムのクラッシュおよびパフォーマンスインサイトを提供します。 Unity：Sentry の Unity SDK により、C# のエラー、ネイティブクラッシュ、複数プラットフォームにまたがるパフォーマンスのボトルネックを検出できます。自動エラートラッキング、スクリーンショットの添付、オフラインキャッシュ機能によりデバッグが簡単になり、プレイヤーのデバイスがオフラインであっても重要なクラッシュデータを失うことはありません。（ドキュメント） Unreal Engine：PC、モバイル、コンソール向けに開発を行っている場合でも、Sentry の Unreal Engine SDK はエンジンレベルでクラッシュやエラーをキャプチャします。Unreal の組み込みクラッシュレポーターと統合されており、すべてのコンソールでシームレスに動作します。（GitHub） Godot：Godot を使用した開発においては、Sentry は専用の SDK を現在開発中です。これにより、作業フローを中断することなく、エラーの検出とパフォーマンスの向上が可能になります。（GitHub） ご使用のエンジンが何であっても、Sentry はプレイヤーに影響が及ぶ前に問題を特定し、修正する手助けをします。 プラットフォームをまたぐデバッグで足を引っ張られるべきではありません ゲームが PC、モバイル、コンソールなどさまざまな環境で動作する一方で、異なるプラットフォームにわたるクラッシュの追跡は非常に困難です。たとえば、Android では発生する問題が iOS では正常に動作することもあり、PlayStation 上でのクラッシュが開発マシンでは再現できない場合もあります。Sentry はあらゆるの荷プラットフォームにおけるエラーとパフォーマンスを一元的に監視することで、このような混乱を整理します。 すべてのプラットフォームを一元管理するダッシュボードWindows、macOS、Linux、Android、iOS、PlayStation、Xbox、Switch におけるクラッシュやパフォーマンスの問題を一か所で確認できます。散らばったログを探し回ったり、プレイヤーからの報告を待つ必要はありません。 すべてのエラーに完全なコンテキスト何が起きたのかを推測で済ませるのは終わりにしましょう。Sentry はスタックトレース、パンくずリスト、デバイス情報、さらに Unity や Unreal Engine のゲームにおけるスクリーンショットまでも提供し、クラッシュ発生直前の状況を正確に把握できるようにします。 より速く修正し、より賢くデプロイどのクラッシュが最も多くのプレイヤーに影響しているかを把握し、優先順位を付けて対応できます。また、リリースの健全性を追跡することで、問題の早期発見・対応が可能です。 ゲームのモニタリングとデバッグを始めましょう Unity や Unreal Engine […]