🌈

スクレイピングや自動処理など「エラーコツコツ潰していく系開発」に効く Sentry

に公開
2026/07/24
監視
Datadog
Sentry
ログ監視
tech

この記事は、スクレイピング/外部 API 連携などで例外が多発する処理を、効率よく潰すための監視ツール選びのメモです。

  • 対象: 「失敗パターンが多い処理」を運用している人
  • この記事で分かること: Sentry が刺さる条件、ログ基盤との住み分け、まず動く最小導入
  • 結論: 例外を優先度順に潰すなら Sentry、全ログの検索や可観測性全体ならログ基盤が軸です
  • 限界: 具体的な導入手順は環境で変わるため、最終は公式ドキュメントを参照してください

まとめ

エラーが頻発して「ログを眺める」だけでは追い切れない開発に、Sentry は効きます。 例外を自動でグルーピングして頻出順に並べ、優先度付けして潰す流れを作りやすいです。

Sentry が刺さる条件は次の通りです。

  • スクレイピングや外部 API 連携など、失敗パターンが多いです
  • 手動で「意味のある失敗」を探す時間が長いです
  • まずはエラー（例外）だけを確実に拾いたいです

一方で、全ログの検索や可観測性全体（メトリクス/トレース）をまとめて運用したい 場合は、CloudWatch や Datadog などのログ基盤が軸になりやすいです。

目的別のざっくり早見表です。

目的 まず見る候補
例外を自動でまとめて、頻出順に潰したい Sentry
全ログを検索して原因を掘りたい CloudWatch Logs / Datadog Logs など
メトリクス/トレースまで一体で運用したい Datadog / AWS（CloudWatch + X-Ray など）
最小導入（まず動くところまで）

環境ごとに手順は変わりますが、最短で迷わない形にすると次の順番が楽です。

  1. Sentry でプロジェクトを作ります（DSN を発行します）
  2. 対象環境の SDK を入れて DSN を設定します（公式ドキュメントに沿います）
  3. 意図的に例外を送って、イベントが届くことを確認します

公式ドキュメント: https://docs.sentry.io/

あるある開発過程

スクレイピングや自動処理など成功率の低いところから始まるプログラムにありがちな開発過程として、エラーをコツコツ潰していくというものがあります。

具体的には以下のような過程です。

  1. まず、もっとも理想的で綺麗な例について動くように作ります。
  2. 対応できた例と同じパターンのものについては成功しますが、そうでないものがたくさんあり、ほぼ失敗します。
  3. どういったものが失敗しているかは、エラーログから漁ろうとします。
  4. エラー処理やロギングもまともに作っていないので、自動で回しているときはなぜ失敗しているのか分かりません。
  5. 個別に手動でコツコツと起動し続け、失敗する例を見つけます。
  6. 見つけたらその例について詳しくデバッグして、どういうエラー処理・ロギングをすれば問題の原因が特定できたか考え、実装します。
  7. そしたらまた自動で回しますが、たくさん失敗します。
  8. さっき 6. で追加したところと同じところで落ちていれば原因を特定できるはずですが、その他のエラーが相変わらず多く、何が何やら分かりません。
  9. かろうじて見つけた意味の分かるエラーログから、そのパターンについての実装を追加します。
  10. 2 に戻ります。これを繰り返します。

この過程のうち、何も工夫せずにやると特に時間がかかるのは「大量のログから意味のある失敗を拾う」ことと、「修正後に次の失敗が出るのを待つ」ことです。できるなら、エラーを一括で把握し、頻出度順に優先度をつけて潰したいところです。

この部分はログ処理を助けてくれるサービスやアプリケーションを使うと効率化できるので、それを紹介したいというのがこの記事の意図です。
結論としては Sentry をおすすめしますが、まずはその他の選択肢から紹介します。

サービス紹介

CloudWatch Logs

AWS を利用する場合は、たいてい簡単に CloudWatch Logs に出力するオプションがあるので、利用する場面が多いです。
CloudWatch Logs Insights を使えば、さまざまな条件で検索できます。
CloudWatch Dashboard も作れますが、クエリを手で組み立てて調べていくイメージなので、やや大変です。

Datadog

Datadog はほとんど自動的に設定を行ってくれる汎用の監視サービスです。
AWS と連携させると EC2 や ECS コンテナなどの死活や、CPU/メモリ消費などのリソースを自動的に監視してくれます。他にもいろいろなイベントを設定して監視でき、例えばある URL にリクエストを定期的に送り、レスポンス速度を監視することもできます。

ログに関しても送信する設定さえできれば、あとは自動的に頻出パターンごとにグルーピングして表示できます。
設定が大変だったイメージでしたが、久しぶりに見たら簡単になっているようです。Python の場合は log を json 形式にするフォーマッタを logger に仕込む必要があります。

AWS Lambda(python)へのセットアップ方法:https://docs.datadoghq.com/ja/serverless/installation/python/?tab=serverlessframework

Sematext

Datadog の競合サービスです。UI は Datadog よりよいと感じる点もありますが、ユーザー数は Datadog の方が多いので、迷ったら Datadog が無難かもしれません。

Mezmo（旧 LogDNA）

ログの収集・検索・転送を扱うサービスです。この記事の初版時には LogDNA という名称でしたが、現在は Mezmo として提供されています。製品名や機能範囲が変わっているため、導入判断では現在の公式情報を確認してください。

Seq

LogDNA と似たような機能ですが、クラウドサービスではなく docker image が用意されているセルフホスト型です。もちろん管理コストはかかりますが、single-user license が無料なので個人開発では1つあると嬉しいです。筆者の環境では NUC 上で 24h 動いています。

Sentry

例外（エラーイベント）を中心に集めて、スタックトレースや環境情報と一緒に整理・追跡することに強いサービスです。
各言語の SDK が用意されており、導入が簡単です。例外をパターンごとに自動でまとめて、頻出度順に並べてくれるのが基本機能で、そのパターンに関して豊富な機能で管理できます。
例えば、アラートはもちろん、担当者を割り当てたり、GitHub Issues のように議論したり、無視/解決の状態をフラグで管理したりできます。

例えば python においては、コード内に数行仕込むだけで設定できるため、ローカルでも本番環境でも導入しやすいです。いろんな環境からエラーを送っても、どこから来たエラーなのかを整理して見分けられますし、どのデプロイのエラーかも管理できます。

紹介記事：
[楽々エラー監視]Sentry をつかって Lambda(python)のエラートラッキングを試してみる

総評

Sentry 以外の可観測性基盤（例: CloudWatch / Datadog）は、ログ・メトリクス・トレースまで広く扱える一方で、例外を「頻出順に潰す」体験は設定次第になりがちです（もちろん Datadog などでもエラー監視はできます）。
Sentry を使うとエラーを見逃しにくく、一目で優先度順に管理できるため、「エラーコツコツ潰していく系開発」には Sentry が効きます。

実務メモ（落とし穴・代替案・検証）

落とし穴

  • 例外を握りつぶしていると、そもそもイベントが上がりません（まずは意図的に例外を送って確認します）
  • 通知やグルーピングを詰めないとノイズが多く、見るのが辛くなります（最初は通知を絞って始めます）
  • ログも全部送ろうとするとコスト/ノイズが増えます（まずは例外中心で始めます）

ノイズ削減（最小）

  • 通知は最初は prod のみ + 重要度が高いものだけに絞ります（dev/stg は別チャンネル or 無通知にします）
  • 「既知で対応しない」エラーは無視（ignore）に入れます（例: 一時的なネットワーク断など）
  • 同じ原因が別 issue に分かれる場合は、グルーピング設定（fingerprint 等）を調整します

代替案と比較軸

  • 例外の優先度付け: Sentry
  • ログ検索/メトリクス/トレースまでまとめたい: CloudWatch / Datadog など（可観測性基盤）
  • 比較軸: 見たい対象（例外/ログ/トレース）、運用コスト（ノイズ/アラート）、料金（量/保持）

判断フロー（最短）

  • 「まずは例外だけ確実に拾いたい」: Sentry から始めます
  • 「ログ検索がボトルネック」: ログ基盤を先に整えます
  • どちらも必要: 役割分担（例外=Sentry、ログ=ログ基盤）で始めます

検証（最小）

  • 意図的に例外を送って、イベントが届くことを確認します
  • 環境（dev/stg/prod）やリリースを区別できることを確認します
  • 通知が「見たい人」に届くことを確認します（運用の当番/担当が決まります）

セキュリティ/コンプライアンス（最低限）

  • 例外メッセージや request 情報に個人情報/シークレットが混ざらないようにします（送信前にマスク/除外を検討します）
  • Sentry の DSN はイベント送信先を識別する公開前提の値で、データの読み取り権限は持ちません。ただし第三者による不要なイベント送信は起こり得るため、環境ごとに分け、必要ならレート制限や無効化で対処します
  • Sentry API の認証トークンなど、読み取り・変更権限を持つ値はシークレットとして管理し、リポジトリへ含めません

参考（一次情報）

更新: 2026-07-24（LogDNA の現名称を Mezmo に修正し、DSN と秘密の認証トークンの違いを明確化）

Discussion