エラー追跡ツールとは

ログは「全部の出来事」を書きますが、エラーだけを集めて整理してくれる道具があります。エラー追跡ツールです。Sentry が有名で、naminori は Sentry と同じ仕組みで動く GlitchTip を使っています。

エラー追跡ツールは、次のことをしてくれます。

• 同じ種類のエラーを1つにまとめる（まとまりを issue と呼ぶ）
• 何回起きたか、最初と最後はいつか
• どの画面（URL）で、どのブラウザで起きたか
• エラーが起きた場所（スタックトレース）

スタックトレースを読む

スタックトレースは、エラーが起きた瞬間に「どの処理が、どの処理を呼んでいたか」を並べたものです。次は、手元の Ruby で実際に出したものです。

apply.rb:9:in 'ApplyNotifier#build_message': undefined method 'name' for an instance of Job (NoMethodError)
    from apply.rb:5:in 'ApplyNotifier#call'
    from apply.rb:18:in 'ApplyController#create'
    from apply.rb:22:in '<main>'

読み方は3つです。

1. 1行目が、壊れた場所とエラーの内容。 apply.rb の9行目で、Job に name を聞いたが、そんなものは無い
2. 下へ行くほど、呼び出し元。 応募の受付（18行目）→ 通知（5行目）→ 通知の文面作り（9行目）の順に呼ばれていた
3. 本物のアプリでは、間にフレームワークやライブラリの行が何十行も挟まる。自分たちのコードの行を上から探す

この例なら「通知の文面に求人の名前を入れようとしたが、求人が持っているのは title だった」と読めます。

着手する前に確かめる2つ

(1) 今も起きているか。 issue の「最後に起きた日時」と回数を見ます。3か月前に1回だけ起きて止まっているものを、今から掘り返す必要はあまりありません。

(2) 自分たちが出したものではないか。 naminori では、2026年9月の調査で、直近に届いていた5件がすべてアプリの不具合ではないもの（調査用に打ったコマンドの打ち間違いなど）でした。また、直す前に「本当に再現するか」を確かめようと自分で送ったリクエストが、新しい issue を3件作ったこともあります。どちらもアプリの不具合ではありません。

届かないエラーがある

エラー追跡ツールで一番大事な注意点です。ツールに無い ＝ 起きていない、ではありません。

naminori で実際にあったことです。求人への応募の処理で、プログラムがエラーを捕まえて、ログに書き、「失敗しました」の画面を出す作りになっていました。エラーを捕まえて処理しているので、エラー追跡ツールには何も送られません。

• 応募の後の通知処理の誤りで、応募は保存されているのに「失敗しました」と表示された
• エラーはアプリのログには毎回書かれていたが、ログは見に行かない限り何も知らせてくれない
• 2026年8月10日の変更から、別の作業の途中で偶然見つかる10月11日まで、約2か月続いた

エラーを捕まえて画面を出し分けること自体は、悪いことではありません。後から困るのは、捕まえたエラーを、誰も見ない場所にしか書かないことです。捕まえたら、エラー追跡ツールにも送るか、少なくとも「どこに書いたか」を決めておきます。

同じように、ボットのノイズを減らすために「この種類のエラーは送らない」と決めたものも届きません（第6回にその実例があります）。送らない設定は、何を見えなくしたのかを書き残しておきます。

閉じるときは、理由を言えるようにする

直したら、issue を「解決済み」にします。naminori では、閉じる前に1件ずつ中身を読み、「なぜ閉じてよいか」を言えるようにしています。まだ起きているものを閉じると、本当の異常が一覧から消えてしまいます。

• エラー追跡ツールがしてくれること
• スタックトレースの読み方
• 今も起きているか、自分が出したものではないか
• ツールに届かないエラーがある
• 閉じる前に理由を言えるようにする