Show HN: ユーザーセッションを監視し、重要なバグを見つけて修正します

皆さん、こんにちは。 私はAbhishekです。Opslaneを構築しています。これは、ユーザーに直面する問題を特定し、調査するオープンソースのエージェントです。修正を確認できる場合にのみPRを作成します。 デモ: https://youtu.be/ccuOTYQMeYg ドキュメント: https://docs.opslane.com Robinhoodでの前職では、四半期ごとにバグ修正会を実施していました。Sentryのバックログを確認し、できるだけ多くのバグを修正しようとしていました。顧客から報告されたバグのみを修正していました。数百のバグがあり、Sentryのデフォルトの優先度レベルは意味をなしませんでした。バグ修正会の後、私たちは「破産宣言」を行い、残りのすべてのバグを選択して解決済みとしてマークしました。 コーディングエージェントがより一般的になったため、この問題はさらに悪化しています。 そこで考え始めました。Sentryが2026年に構築されたとしたら、どのようになっているだろうか？ 私にとって、エラー追跡には2つの失敗モードがあります。 1. 誤検知: 何千ものエラーが表示され、ユーザーへの影響を判断できません。 2. 誤検知: 多くのユーザーに影響する問題は例外を発生させないため、見過ごされます。 Opslaneは、エラー追跡とセッション記録を組み合わせます。そして、両方に対応するエージェントがあります。開始するには、Opslane SDKをインストールします。エラー、コンソールログ、ネットワークリクエスト、セッション記録など、ユーザーが行ったすべてをキャプチャします。 Opslaneは、特定の問題に直面しているユーザー数に基づいて問題をランク付けすることで、誤検知を減らします。また、コードを読み、セッション記録を監視することで、製品について学習します。 誤検知はより困難です。Opslaneは、フラストレーションを示すセッション記録をレビューします。ラチェクリック、デッドクリック、放棄されたフォームを探します。 最近、初期顧客のオンボーディングフローでバグを検出しました。ドロップダウンがクリックすると自己閉鎖するというものでした。例外もバグレポートもありませんでした。記録を見ると、ユーザーがそれをクリックし、何も選択せず、オンボーディングから離脱していました。Opslaneがそれをフラグ立てし、チームが修正しました。 Opslaneを構築する際の3つの指針: 1. オープンソース: 1つのDocker Composeファイルでセルフホストできます。 2. エージェントファースト: エラーダッシュボードを再び開きたくありません。OpslaneはMCPサーバーを出荷するため、Claude Codeから「今週ユーザーに何が壊れたか」と質問できます。注意が必要な問題が返され、解決を推進します。 3. 製品について知っている: Opslaneは継続的に製品について学習しています。すべての調査は、製品について知っていることから始まります。 まだ初期段階です。現在、フロントエンドアプリはエンドツーエンドで動作しています。信頼性と精度を向上させることに注力しています。 リポジトリへのリンクはこちらです: https://github.com/opslane/opslane この問題へのアプローチについて、皆さんのフィードバックをぜひ聞かせてください！