【Application Metrics】Unreal Engine のゲームパフォーマンスを監視する
Article by: Ivan Tustanivskyi あなたのUnrealゲームはエラーゼロの状態でリリースできたとしても、それだけで優れた体験になるとは限りません。戦闘中のスタッター、大型ボス戦での急激なフレームレート低下、マルチプレイヤーでのラバーバンディング。これらはいずれもクラッシュとしては現れず、Sentry にも表示されません。そのため、実際にプレイヤーが現場で何を体験しているのかを把握する手段がありませんでした。少なくとも、これまでは。 Unreal Engine には、ゲームパフォーマンスを測定し、実行時統計を収集するためのツールがすでに豊富に用意されています。しかし、そのデータはすべて開発者のマシン内に留まったままでした。 Unreal SDK の新しい自動パフォーマンスメトリクス機能は、このギャップを埋めます。FPS、フレーム時間、ネットワーク状態、そのほか一般的なゲームテレメトリを直接 Sentry に送信することで、どこでパフォーマンスが低下しているのか、どのハードウェアで発生しているのか、どのプレイヤーに影響しているのかについて、チームが実用的なインサイトを得られるようになります。Release & Health と組み合わせれば、各リリースが時間経過とともにパフォーマンスへ与える影響も追跡できます。 本題に入る前に、一点だけ触れておきます。すべてのゲーム開発者は、これまでに一度はプロファイラを使ったことがあるでしょう。自動パフォーマンスメトリクスはそれとは異なるものですが、関連するツールです。両者は同じ問題を異なるレイヤーから扱います。メトリクスは「どこでゲームが遅くなっているか」を見つけ、プロファイリングは「なぜ遅くなっているのか」を説明します。 Sentry が現在追跡するもの 現在、Unreal SDK は、全体的なパフォーマンスへ影響するいくつかの主要領域について、メトリクスを自動インストルメントします。対象には、フレーム時間、ネットワーク、ゲーム固有の統計などが含まれます。 フレーム時間 ゲームが快適に感じられるかどうかを最も直接的に示す指標です。フレーム時間は、「各フレームの処理にエンジンがどれだけ時間を使ったか」を示します。また、スレッドごとに分解することで、どのサブシステムがボトルネックになっているかを確認できます。 平均FPS 総フレーム時間 ゲームスレッド処理時間 レンダースレッド処理時間 GPUフレーム時間 ゲームスレッド、レンダリングスレッド、GPUの処理時間を比較することは、CPUがボトルネックになっているのかGPUがボトルネックになっているのか、そしてどのチーム（ゲームプレイ、レンダリング、コンテンツ）が修正を担当すべきかを判断する古典的な方法です。 FPSメトリクスの例（GPU別にグループ化） ネットワークインサイト マルチプレイヤーのパフォーマンスは、接続品質によって成否が決まります。しかし、クラッシュレポートだけではその状態を把握できません。これらのメトリクスによって、パケットロス、レイテンシ、帯域不足が、気づかれないまま体験品質を低下させていないかを確認できます。 送受信帯域幅 パケットスループットとパケットロス クライアントの ping と jitter アクティブ接続数 サーバービルドではさらに、ロードシェディング分析のために、クライアントごとの平均 ping、クライアントごとの帯域幅、飽和状態の接続数も取得できます（ネットワークメトリクスの完全な一覧を参照）。 これらのメトリクスは、マルチプレイヤーセッションがアクティブな間のみ存在します。ネットワーク機能を持たないシングルプレイヤーゲームでは、ここにデータは送信されません。また、一部の値はクライアント専用（ping、jitter）、あるいはサーバー専用（アクティブクライアント数、接続飽和）です。 Pingメトリクスの例 ゲーム統計 フレーム時間の内訳だけでは説明できないヒッチの原因を把握する際に役立つ、エンジンレベルのシグナル群です。 アクティブな UObject 数 […]
【Next.js】ロギングが難しい理由と解決策
Article by: Kyle Tryon 一般的なNext.jsのデプロイでは、最大で3つの異なるランタイム（Edge、Node.js、ブラウザ）でコードが実行される可能性があります。 サーバーサイドのコードからログをすでに取得しているかもしれませんが、ミドルウェアからサーバーレンダリング、そしてブラウザに至るまでのリクエスト全体を取得していない場合、問題が発生したときに多くのデバッグ情報を見逃していることになります。 要約：一般的なNext.jsのデプロイは、Node、Edge、ブラウザという最大3つの環境で実行されます。ほとんどのJavaScriptのロギングライブラリはNodeを対象としており、Edgeやブラウザに対応しているものははるかに少ないです。LogTapeとSentryはいずれも、ランタイムに依存しないJavaScriptのロギングを提供します。 なぜNext.jsでのロギングは難しいのか 課題 1：多くのロガーはNode.jsを前提としている 多くのロガーはNode.js専用に構築されており、ブラウザやEdgeランタイムでは利用できないAsyncLocalStorageやfsのようなAPIに依存しています。 Next.jsに最適なロガーとしてPino（またはNext-Loggerのようなラッパー）が推奨されることがよくありますが、実際にはどちらもNext.jsにとって良い選択ではありません。 Pino、ひいてはNext-LoggerはNode.js向けに設計されており、ブラウザで動作させるためにポリフィルを使用しています。しかしそのポリフィルにより、Nodeでのパフォーマンス上の利点は失われ、さらにEdge関数やミドルウェア（Edge上で実行される）ではログを取得することができません。 課題 2：クライアントサイドのロギングが欠落する クライアントサイドのログを取得する必要はないと考えがちです。なぜなら「フロントエンドのコード」はすべてサーバーサイドで動作していると思われがちだからです。 デフォルトでは、Next.jsはすべてのページとコンポーネントにServer Componentsを使用します。そのため、デフォルトでは「フロントエンドのコード」から出力されるログは、実際にはサーバーサイドのログとして取得されます。 しかし、インタラクティブなコンポーネントのためにuse clientの境界を追加すると、そのコードはブラウザで実行されるようになります。 「フロントエンドのコード」は、1つのページをレンダリングするために連携して動作するServer ComponentsとClient Componentsの混在であり、それぞれ異なる場所にログを出力します。 この分断を解消し、どこで実行されるかに関わらず、すべてのフロントエンドコードのログを同じ場所に集約する必要があります。 課題 3：トレースと結びついた構造化ロギング ロギングは可観測性の一部にすぎず、それ単体ではローカルでのデバッグ時に最も有用です。本番環境では、数十、数百、あるいは数千のリクエストからログを収集するようになると、関連するログ同士を結び付けて検索・集約する手段が必要になります。 トレーシングはアプリ内の各リクエストに一意のIDを付与し、そのIDを構造化データとしてすべてのログに付加します。これにより、後からそのIDに基づいてログを検索し、同一リクエストに関連するすべてのログを、Sentryのエラーなど他のテレメトリデータとあわせて確認することができます。 Next.jsへのトレーシングの導入自体は実際には簡単ですが、それでも実施すべきステップであり、いくつかの方法が存在します。 ここでは、JavaScriptのロギングライブラリとSentryを組み合わせて、トレースに紐づいたログをNext.jsに計測として組み込みます。別の記事では、OpenTelemetryを使用した別のトレーシング導入方法について解説・比較する予定です。 Next.js用のロガーに求めるべき要件 ロガーは何を満たすべきでしょうか。私は最近、主要なJavaScriptロギングライブラリを比較し、そもそもなぜロギングライブラリを使うべきなのかを整理しました。基本的な考え方はNext.jsでも同様ですが、より具体的に考える必要があります。 ランタイム対応：Node、ブラウザ、そして（Edgeを使用する場合は）Edgeランタイムで動作する必要があります。 トレーシング対応：Next.jsアプリはデフォルトでマルチサービス構成です。トレーシングにより、複数のソースからのログを単一のトレースに紐づけることができます。 本番向け機能：データのマスキングやノイズ削減のためのフィルタリング、コンテキスト管理や子ロガーによる構造化ロギングの強化、および後の検索・集約の容易化。 想像できる通り、機能面では各ライブラリは互いの優れた実践を取り入れ、似通ってきています。 それでもなお注目すべき最大の違いは、ランタイム対応とパフォーマンスです。 Next.jsアプリ全体をカバーできる現実的な選択肢は2つあり、これらは排他的ではありません。 LogTape（Sentryシンクと組み合わせる） Sentry.logger（Sentry Next.js SDKと組み合わせる） LogTape 前回の記事でも触れましたが、LogTapeは比較的新しいライブラリであり、専用のロギングライブラリとして急速に私のお気に入りになりつつあります。依存関係を持たずゼロから構築されており、すべてのJavaScriptランタイムでネイティブに動作します。 LogTapeのコンテキスト管理とカテゴリ機能は、後の効率的な検索のためにログへタグ付けし整理するのに特に有用です。 カテゴリとSentryシンクの設定 定義した各ロガーは、Sentry上でフィルタリング（たとえば category: next-app.client）することで、特定のカテゴリに属するログのみを取得できます。 […]
【Next.js】オブザーバビリティのギャップと解消方法
Article by: Sergiy Dybskiy このブログは、最近実施されたライブワークショップに基づいています。YouTubeでフルのライブ配信を視聴できます。 Next.js は多くの機能を当初から提供しています。サーバーサイドレンダリング、ファイルベースルーティング、エッジランタイムなどです。しかし、実際に本番環境で何が起きているのかを明確に把握する手段は提供していません。フレームワークの3つのランタイム構成（クライアント、サーバー、エッジ）により、エラーがあるレイヤーで発生しているように見えても、実際には別のレイヤーに起因していることがあります。また、データベースクエリはORMの抽象化の背後に隠れ、サーバーアクションは有用なエラーメッセージをブラウザに到達する前に飲み込んでしまいます。 本記事では、Next.jsアプリにおけるいくつかの具体的なオブザーバビリティ（可観測性）のギャップ、それらが存在する理由、そしてSentryを用いてそれらをどのように解消するかについて説明します。 要約 Next.js の本番ビルドでは、サーバーアクションからエラーの詳細が削除されます。クライアント側には「サーバーコンポーネントのレンダリング中にエラーが発生しました」とだけ表示され、コンテキストは一切提供されません。Sentryは完全なスタックトレース付きで元のサーバーサイド例外をキャプチャします。 Hydrationエラーは、Reactにおいて最も一般的でありながら最も役に立たないエラーのひとつです。SentryはHTMLの差分ビューを提供し、サーバーとクライアントのレンダリング間でどのDOMノードが不一致だったのかを正確に示します。 ログとメトリクスはトレースのようにサンプリングされません。tracesSampleRateの設定に関係なく、データは100%取得されます。データの欠落を避けたい場合はこれらを使用してください。 サーバーアクションはOpenTelemetryのスパンを生成しないため、トレースに表示させるにはwithServerActionInstrumentationを使用した手動のインストルメンテーションが必要です。 DrizzleのようなORMを通じたデータベースクエリは、デフォルトではトレーシングに表示されません。データベースクライアント（例：TursoのlibSQL）のインテグレーションを追加することで、すべてのクエリをスパンとして可視化できます。 Vercel AI SDKとのインテグレーションによるAIエージェントのモニタリングでは、モデルごとのトークン使用量、コストの内訳、ツールコールのトレースを、Sentryから離れることなく確認できます。 3つのランタイム、3つの設定ファイル Next.js は異なる環境でコードを実行します。Sentryのウィザードを実行することで、セットアップを開始できます。 ウィザードはそれぞれの環境に対して個別の初期化ファイルを作成します。ブラウザ用の instrumentation-client.ts、Node.js 用の sentry.server.config.ts、そしてエッジランタイム用の sentry.edge.config.ts です。 これにより、各ランタイム向けの設定ファイル、グローバルエラーバウンダリ（global-error.tsx）、そして withSentryConfig によってラップされた next.config.ts が生成されます。next.config.ts のラッパーは、可読性のあるスタックトレースのためのソースマップのアップロードを処理し、さらにトンネルルーティングを設定します。これは広告ブロッカーを回避するために、Sentryのデータを自分のサーバー経由で送信する仕組みです。 設定に関していくつか注意点があります。 サンプルレートは重要です。開発環境では tracesSampleRate を 1.0 に設定し、本番環境では 10〜20% に設定します。これを高くしすぎると、クォータを急速に消費します。 sendDefaultPii はリプレイやイベントにユーザーのIPアドレスを付与します。必須ではありませんが、セッションを実際のユーザーと関連付けるのに役立ちます。 エッジの設定は異なる場合があります。ミドルウェアがリクエストの再ルーティングのみを行う場合、ノイズを減らすためにエッジ設定でトレーシングを無効にしても問題ありません。 セットアップに関してもう一点あります。認証後に一度 Sentry.setUser() を呼び出すことで、エラー、ログ、トレース、リプレイ全体にユーザーコンテキストを伝播させることができます。 Hydrationエラー：一般的だがあまり役に立たない Hydrationとは、ReactがサーバーでレンダリングされたHTMLにイベントハンドラを紐づけ、インタラクティブにするプロセスです。Hydrationエラーは、クライアント側でReactがレンダリングしたマークアップが、サーバーで最初にレンダリングされたHTMLと一致しない場合、またはサーバーが無効なHTMLを返し、Reactがそれを修正できなかった場合に発生します。 典型的な原因は、localStorageから値を読み取るテーマ切り替えです。サーバーはライトテーマをレンダリングします（localStorageにアクセスできないため）が、クライアントは保存されたダークテーマの設定を読み込み、HTMLが一致しないためReactがHydrationエラーを投げます。 […]
【JavaScriptロギングライブラリの選び方】2026年決定版ガイド
Article by: Kyle Tryon AIがますます多くのコードを書くようになるにつれて、そのコードを適切に監視し、デバッグすることは、開発ワークフローにおいて無視できない重要な要素となっています。幸いなことに、そのための対応に適したツールを導入する時間は、これまで以上に確保しやすくなっています。 本番環境に対応したロギングソリューションの実装は容易であり、アプリケーション全体にわたって、ユーザーや環境を横断した豊富なデバッグ情報を、開発者およびLLMエージェントにもたらします。 なぜロギングライブラリが必要なのか もしデバッグにまだconsole.logを使っているのであれば、なぜロギングライブラリを使う必要があるのか疑問に思うかもしれません。 高パフォーマンスロギングライブラリは非同期で動作するため、ネイティブのconsoleログよりも高いパフォーマンスを発揮します。 構造化された出力文字列ではなく構造化オブジェクトとして出力でき、追加のコンテキストや子ロガーの管理を簡素化します。 トランスポートとシンクコンソール、ファイル、ストリーム、オブザーバビリティプラットフォームなど、1つまたは複数の宛先にログを送信できます。 フィルタリング重大度、カテゴリ、その他の条件でログをフィルタリングし、ノイズを削減できます。アプリケーション外に出る前に機密データをマスキングすることも可能です。 統合Webフレームワーク、ORM、その他のライブラリと統合することで、アプリケーションのすべてのレイヤーにわたり、一貫したAPIでコンテキストやエラーを自動的に記録できます。 トレース連携ログSentryでは、ログがエラーやその他のイベントと自動的にトレースで結び付けられ、デバッグや問題の相関関係の把握が容易になります。 ロギングライブラリの選定 主要な4つのライブラリをひと目で比較できるようにまとめました。 ライブラリ バージョン ランタイム リリース トランスポート／シンク Minified + gzip 依存関係数 ツリーシェイク可能 Pino 10.2.0 Node 2016 ✓ 3.3 KB 11 ❌ Winston 3.17.0 Node 2010 ✓ 38.3 KB 17 ❌ Bunyan 2015年8月1日 Node 2012 ✓ 5.6 […]
React Native SDK 8.0.0 が登場
Article by: Antonis Lilis React Native SDK 8.0.0 をリリースしました。 新機能と変更点をご紹介します。 前回のメジャーバージョンからしばらく経ちました。前回のメジャーリリースである 7.0.0 は 2025年9月2日 にリリースされています。マイナーリリース 13回 とパッチリリース 2回 を経て、ついに新しいメジャーバージョン 8.0.0 の登場です。今回のバージョンは、メンテナンスと機能拡張を目的としたメジャーリリースです。 具体的には以下を行いました。 ネイティブ初期化によるアプリ起動時エラーのキャプチャを追加 主要なネイティブ依存関係をアップグレード 最小バージョン要件を引き上げ アップグレードは概ねスムーズなはずですが、環境に応じて移行ガイドをご確認ください。 知っておきたい変更点 バージョン8の変更の多くは2つに大別できます。新機能と依存関係の更新です。 要点は以下のとおりです。 アプリ起動時エラーのキャプチャ Sentry は React Native ブリッジのセットアップ、バンドルのロード、ネイティブモジュールの初期化の最中に発生するクラッシュやエラーを、いまではキャプチャできます。JavaScript 側で Sentry.init() が実行された後だけでなく、その前の段階も対象です。従来のバージョンでは、これを実現するには複雑な設定やネイティブ初期化の手動対応が必要でした。 バージョン8では sentry.options.json 設定ファイルと新しいネイティブ API を使って、ネイティブ層で Sentry を初期化できます。これにより、アプリのライフサイクルの最初から、アプリ起動時のエラーやネイティブクラッシュを SDK がキャプチャできます。詳細は React Native のドキュメントをご覧ください。 更新されたネイティブ依存関係 Cocoa […]
ランダムなチャンクから本当のコードへ：SentryでNext.jsのソースマップをつなぐ
Article by: Sergiy Dybskiy, Anton Bjorkman Next.js アプリをリリースするとき、あなたが書いた React や TypeScript は、ユーザーが実際にダウンロードするものではありません。Next.js はパフォーマンスには優れている一方でデバッグには最悪な形で、コードをコンパイルし、ミニファイし、分割し、チャンクへとシャッフルします。 この記事では、そのパイプラインがどのように動くのか、ソースマップと Debug ID がそれらをどのように元のコードへ結び付けるのか、そして Sentry が読みにくいスタックトレースではなく、実際のファイル名と行番号を表示するように設定する方法を解説します。 コードに実際に何が起きるのか 一般的な Next.js アプリでは、React＋TypeScript のソースはビルドパイプラインを通り、JavaScript、HTML、CSS へコンパイルされます。その出力はミニファイされ、ユーザーが必要なものだけをダウンロードできるようにチャンクへ分割されます。 これらはページの読み込みには良いことです。しかしエラーが起きたとき、スタックトレースが app/page.tsx ではなく static/chunks/12345-something.js を指すようになると、あなたにとってはあまり良いことではありません。 あなたのコードは見覚えのあるものから、まったく見覚えのないものへと変わります。そこで登場するのがソースマップです。コンパイルされた各バンドルチャンクには、2つの重要なメタデータがあります。Debug ID と対応するソースマップを指す sourceMappingURL です。 Sentry はアップロードされたミニファイ済みファイル上の Debug ID を使って、アップロードされたソースマップ上の一致する Debug ID を見つけます。このペアがそろうと、Sentry はスタックトレースをデミニファイし、元のファイル、行、列へマッピングし直して、バンドラーが生成したコードではなく、あなたが実際に書いたコードを表示できます。 開発ツールではきれいなスタックトレースが出るのにSentry ではチャンクになる理由 開発時はブラウザ上では問題なく見えます。dev でアプリを動かし、サンプルのエラーを投げると、ブラウザの開発者ツールは実際のファイル名とソースを含む、読みやすいスタックトレースを表示します。 これは next dev を実行しているとき、ブラウザがローカルのソースマップと元のソースファイルに直接アクセスできるためです。Sentry なしでも、ブラウザだけで解決できます。 その同じ […]
【Next.js SDKがTurbopackに対応】少ないコードで高速ビルド、テレメトリーはそのまま
Article by: Sergiy Dybskiy 要約：Next.jsでTurbopackがデフォルトとなったため、バンドラーに依存しないようにSDKを再構築しました。その結果、コード量の削減、ビルドの高速化、そしてこれまでどおりのテレメトリーを実現しました。このブログでは、その過程を説明します。 何年もかけてツールを構築してきたのに、支えていたものが突然非推奨になり、アプローチ全体を見直さなければならなくなる。そんな経験はありますか？ そして念のためですが、これは Ralph Wiggum の話ではありません。私たちのコミュニティで合意してその名前で続けることにした、再帰エージェントプラクティスについての話でもありません。 これは、Next.js が Turbopack を展開し、Webpack を非推奨にしたこと（Next.js v16 からは Turbopack がデフォルトになっています）、SDK におけるテレメトリアプローチを見直したことについてです。 以前の状況 以前は next build を実行すると、Webpack ローダーがすべてのページ、API ルート、ミドルウェア、サーバーコンポーネントを横取りしていました。 このローダーは次のことを行っていました。 ファイルを解析し、タイプを判定する Rollup を使用し、 Sentry ラッパーテンプレートとバンドルする 元のコードを計装済みのバージョンに置き換える これはうまくいきました。しかし、それには6種類のラッパーテンプレート、360行の Webpack ローダー、約1,667行の計測コードを維持する必要がありました。Next.js の新機能が追加されるたびに、サーバーコンポーネントやルートハンドラー、App Routerといったものに対して新しいテンプレートを書く必要があり、Webpackの内部が最後に確認したときから変更されていないことを祈るしかありませんでした。 私たちは、すべてのファイルに「Sentryでラップされたドッペルゲンガー」が存在する並行世界を構築していました。こういったアーキテクチャはうまく機能する時には良いのですが、うまくいかなくなると、どの層が壊れたのかを追うのは至難です。 現在の取り組み Next.js には、組み込みの OpenTelemetry 計装機能があります。これにより、すべてのリクエスト、ミドルウェアの実行、レンダー処理ごとにルート情報つきの スパン を出力します。コードをラップする代わりに、それを受け取るようにしています。 上のスニペットは「きれいなバージョン」です。実際には、標準の […]
【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 Native を選択します。次に、インストールウィザードを実行して、ローカルのプロジェクトに必要な設定を追加します。 […]
【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 […]
【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 向け Sentry […]