Ichizokuは日本唯一のSentry公認販売業者です。
日本語のドキュメント、動画、サポート窓口で日本のお客様のSentry活用を支援します。

ベータ期間中に Sentry のユーザーフィードバックウィジェットを使って Logs を形作った方法

09/19/2025

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 インフラにおいても、開発者が期待する通りに動作するようになりました。

私たちが実践し、推奨するベストプラクティス

コンテキストに埋め込む：フィードバックボタンを影響の大きい機能領域に直接埋め込みます。こうすることで、ユーザーが実際に作業している場所からフィードバックを送信できるようになります。私たちは Logs ストリームのページヘッダーに直接フィードバックボタンを追加しました。
適切に調整されたプロンプトを使う：「ここで何が分かりにくかったですか？」や「ログをより便利に使えるようにするにはどうすればよいですか？」といったコンテキストに沿ったプレースホルダーメッセージは、より有益で実行可能なフィードバックにつながります。

すべての投稿にタグを付ける：feedback.source:new-checkout-screen や feedback.type:negative といったタグを使うことで、フィードバックを機能や感情ごとに整理でき、迅速なトリアージが可能になります。
アラートをリアルタイムにルーティングする：特定のタグやURLが付いたフィードバックは、アラートルールを通じて適切なチャンネルに直接流すことができます。これによりエンジニアが即座に確認し、対応し、問題を修正できるようになります。Logs の場合、url:*logs* で提出されたフィードバックは、私たちの社内 Slack チャンネル proj-logs にルーティングされました。