BugByBug

ここが製品の中核だ。エラーが届くと、BugByBug のパイプラインが手がかりを分析し、ありそうな原因を名指しする。生のスタックトレースだけを残さない。故障を取り巻く条件や依存関係も伝えるため、得られるのは「何が起きたか」だけでなく「なぜか」だ。開発元はこの多段パイプラインを、まとめと分類で止まる一般的なログツールとの違いとして示す。

上位プランでは、BugByBug が具体的なコード変更を提案し、調査に最も関係するファイルを指す。リポジトリをつなぐと、目を通す価値のあるフレームとファイルが浮かび、エラー報告からコードの該当箇所までの距離が縮まる。ダッシュボードはこれを推奨として表示し、適用するかはチームが決める。

捉えたエラーには、再現に要る情報が付く。スタックトレース、そこへ至るユーザーの breadcrumb、リクエストデータ、セッション文脈だ。エラーが起きた時点で BugByBug は例外と性能データを記録するので、当て推量ではなく出来事の順番を組み直せる。この手がかりが AI 分析の土台になる。

BugByBug はスタックトレースとメッセージをハッシュ化し、別々のエラーごとに 1 件の項目を作り、繰り返しは自動でまとめる。千回鳴るクラッシュは、追える 1 件になる。千行をスクロールする必要はない。グルーピングはパイプラインの最初の段階で、アプリが育ってもダッシュボードを読みやすく保つ。

BugByBug は OpenTelemetry の OTLP HTTP プロトコルでテレメトリを受け取る。OpenTelemetry が対応する言語やフレームワークならどれでもデータを送れる。エンドポイントを BugByBug のトレース URL にし、API キーをヘッダーで渡す。Bearer トークンでも x-api-key でもよい。Collector は必須ではない。exporter が OTLP HTTP を話すなら、トレースを BugByBug へ直接送れる。

すべては単純な階層に収まる。ユーザーがログインして組織を持ち、その中にプロジェクトを足す。各プロジェクトは 1 つのアプリかサービスで、専用の API キーを携える。エラーとエラーイベントはプロジェクトの下に並ぶ。BugByBug は今のところ 1 ユーザーにつき組織 1 つ、プロジェクト 2 つまで。有料プランは大きめのチーム向けにプロジェクト数と席数の上限を引き上げる。

Pro プラン以上で Slack 連携が加わり、新しい問題や調査がチームの普段の作業場所に届く。上位プランは席数を増やし、高度な AI 調査とサンドボックス検証を備える。提案された変更が本番に届く前に確かめられる。Enterprise は SSO とカスタム連携を加え、要件の厳しい組織に向く。