Sixty と Sentry

Sentry が得意なこと

Sentry は存在する中で最良のエラートラッカーであり、それがやることについて反論の余地はありません。ソースを対応付け直したスタックトレース、始まったリリース、その行に触れたコミット、そこに至るまでの操作履歴、そしてセッションの記録 — アプリが例外を投げたとき、Sentry は場面そのものを丸ごと差し出します。しかも導入から数分でそうします。

エラーの先へもずいぶん進みました。N+1 のデータベースクエリを一級の問題として検出し、ルートごとに Web Vitals を追い、リリース間のパフォーマンス回帰を見張ります。そして Seer — いまは定額で使用量無制限、本番だけでなくローカル開発とコードレビューにも手を伸ばしています — はバグの原因を突き止め、パッチを提案します。このページにあるものの中で、Sixty がやることに最も近く、しかも多くの人にとってはすでに導入済みです。

Sentry は開発者1人は無料。Team は月額26ドルから、Seer は貢献者1人あたり40ドルからです。出典は 同社の価格ページ で、August 2026時点の掲載内容によります。Sixty はmonthあたり€14.99の定額です。

Sixty が違うこと

違いは、何を問題と見なすかです。Sentry はイベントを中心に組み立てられています — 何かが起きた、場所はここ、と。そのモデルはクラッシュにはまさに正しく、そして高くつくケースについては何も言えません。200 を返したリクエスト、成功して空で返ってきたクエリ、送信されて何も起きなかったフォーム、どのハンドラにもつながっていないボタン。何も throw していないので Sentry には何もなく、それでも誰かは動かない画面の前に座ったままです。

それは Seer の境界でもあります。ここは正確に言う価値があります。Seer は本当に優れているからです。Seer はデバッグのエージェントであり、デバッグは「自分から名乗り出た不具合」から始まります。何も throw していないアプリに向けても、原因を突き止める対象がありません — クエリの形を30行から3万行に変えた回帰は、出発点となるイベントを1つも生んでいないのです。

Sixty は代わりに比較を中心に組み立てられています。イベントという概念をまったく持ちません。この操作が普段どれだけ返し、普段いくつデータベース呼び出しをするかを知っていて、直近のデプロイがそれを変えたときに教えます。30行から3万行になったクエリは何も throw しませんが、フィードに出ます。すべてを絞り込み始めた行レベルセキュリティの規則も同じです — この種のアプリが壊れる最も一般的な形であり、どこにもエラーを残しません。

もう1つの正直な違いはプライバシーで、これは両方向に切ります。Sentry は既定でIPアドレスを収集し、付与すればユーザーIDを保持し、セッション記録は誰かがページ上で何をしたかを記録します — これは本当に役に立ち、だからこそ人は有効にします。Sixty はそのどれも収集せず、収集できません。URL は形に還元され、クエリの値はあなた自身のプロセスの中で取り除かれてから送られます。つまり Sixty は、誰がバグを踏んだのかを決して教えられません。同時にそれは、導入しても同意バナーに何も足さずに済むということでもあります。

横に並べて

比較の全体 がすべてのツールに投げかけるのと同じ12項目の質問を、Sixty が負けている2行も残したまま並べています。

どちらを選ぶか

この2つは排他的ではなく、正直な答えは「両方」であることが多いです。ここにあるもので Sentry と並んで動くのを拒むものはなく、実際そのまま使い続けている人は大勢います。

実際によく聞かれること

• Sixty と Sentry は併用すべきですか？

  それが一般的な答えで、衝突もしません — 見ているものが違うからです。Sentry は throw されたものを捕まえ、Sixty はデプロイをまたいで形が変わったものと、成功と報告しながら失敗しているものを捕まえます。どちらか1つだけにしたくて、アプリが定期的にクラッシュするなら Sentry を残してください。クラッシュしないのにうまくいっていないなら、それが Sixty の作られた理由です。

• Sentry も N+1 クエリを検出します。何が違うのですか？

  Sentry はトレースの内側で N+1 のパターンを見つけます — 1リクエストの中に似たクエリが14本、という具合に。それが新しいかどうかに関係なく指摘します。Sixty は前のリリースと比較します。1レンダーあたり1本だったクエリが14本になった、このデプロイで、この操作で、と。前者は「形が悪い」と教え、後者は「どの変更がそうしたか」を教えます。次に何をするかを決めるのは後者です。

• Seer はすでにエディタからバグを直してくれます。なぜ何かを足すのですか？

  Seer には出発点となるバグが必要で、この製品が存在する理由である失敗はそれを生まないからです。Seer は課題 — 例外、トレース、Sentry がすでに指摘した回帰 — に向けられたデバッグエージェントであり、そこからパッチへ進むのがとても得意です。Sixty の仕事はその1つ前の段階です。どこも問題を報告していないのに、このデプロイが操作の振る舞いを変えたことに気づくこと。価格の面でも同じ買い物ではありません — Seer は Sentry のプランに加えて貢献開発者1人あたり月40ドル、Sixty はアプリ単位で€14.99の定額です。

• Sentry には suspect commits があります。同じものですか？

  意図は同じで、たどり着き方が違い、その違いがそれぞれの効く場所を決めます。Sentry はスタックトレースが指す行を取り、その行に最後に触れたのは誰かを git に尋ねます — クラッシュには良い答えです。クラッシュには行があるからです。パフォーマンスの回帰には、しばしば行がありません。クエリは変わっておらず、呼び出す側が14回実行し始めただけだからです。Sixty は代わりにデプロイから出発します。1つの検出はあるリリースと1つ前の比較で、どちらもコミットです。だから候補の集合は、何かを絞り込む前にすでに完全です — そして絞り込むのは、どの変更が検出箇所のファイルに触れたか、です。

• Sixty にセッション記録はありますか？

  ありませんし、今後もありません。記録とは、人があなたのページで何をしたかを記録することであり、ここでの設計全体は「あなたのユーザーについて何一つアプリの外へ出さない」ことです — セッションIDも、URLも、ページのテキストも。これは意図した取引です。何が、どのくらいの頻度で壊れたかは伝えられますが、誰に起きたかは決して伝えません。

ほかの比較