【Sentry × Slack × ECS Rails】エラー監視ツール導入記｜DSNミスとAlert設定でハマった2つのポイント

はじめに

業務で運用しているECS上のRailsアプリケーションに、エラー監視ツール Sentry を導入しました。あわせてSlackへの通知連携も設定し、エラー発生時にすぐ気づける体制を構築できたので、その流れと途中で遭遇した2つのハマりポイントを記録に残しておきます。

同じ構成（ECS + Rails + Slack）でSentryの導入を検討している方の参考になれば幸いです。

Sentry導入の動機

これまでこのアプリケーションでは、エラーが起きていることに 気づけずに運用してしまっている という状態が続いていました。具体的には以下のような問題がありました。

• ユーザーやビジネス側から「動かない」と連絡をもらってから初めて障害に気づく
• 連絡があるまでの間、エラーが続いていてビジネス的な損失が拡大する
• 「いつエラーが起きているかわからない」という状態が、運用担当者にとって心理的にも辛い

💡 エラーモニタリングツールとは：本番環境で発生したエラーをリアルタイムに収集・通知するツール。代表的なサービスにSentry、Datadog、New Relic、Rollbarなどがあります。Sentryは個人開発から大規模プロダクションまで幅広く使われており、無料プランも充実していて導入しやすいのが特徴です。

「エラーが起こった瞬間に気づける体制」を作ることが今回の目的です。気づけさえすれば対応できますが、気づけなければ何もできません。心理的安全性の観点でも、エラーの可視化は重要だと感じていました。

構成

今回構築する全体像は以下のとおりです。

1. Rails アプリケーション（ECS上で稼働）にSentry SDKを組み込み
2. エラーが発生すると、SDKがDSN経由でSentryにエラー情報を送信
3. Sentry側で Issue（問題） が起票される
4. SentryからSlackの #sentry チャンネルに通知される
5. 通知でメンションされた担当者がSlackから即座に対応する

Sentry-Slackの連携設定

Sentry管理画面の Settings → Integrations から、Slackなど主要なサービスとの連携が設定できます。

ここからSlackを選び、認証フローを進めていけば連携自体は問題なく完了しました。Slack側で受信用のチャンネル（今回は #sentry）を事前に作成しておくとスムーズです。

ここまでは比較的サクッと進んだのですが、ここから先で 2つのハマりポイント に直面しました。

ハマりポイント1：DSNの設定ミス

起きていたこと

• Sentry-Slack連携自体は管理画面上で正常に「Connected」になっている
• しかし、Railsアプリ側でテストエラーを発生させても Sentryにイベントが届かない
• 当然、Slackにも通知が来ない

原因

Railsアプリ側で読み込んでいる 環境変数 SENTRY_DSN の値が間違っていました。

💡 DSN（Data Source Name）とは：Sentryで「どのプロジェクトにエラー情報を送るか」を決める接続文字列。https://[公開キー]@[組織].ingest.sentry.io/[プロジェクトID] のような形式で、Sentryプロジェクトの管理画面から取得できます。これが正しくないとSentryにイベントが届かないため、最初に確認すべきポイントです。

対処

ECS環境では機密情報をAWS Secrets Managerで管理しているため、修正手順は以下のとおりです。

1. AWS Secrets Managerで SENTRY_DSN の値を正しい値に更新
2. ECSタスクを再起動して、コンテナに新しい環境変数を読み込ませる

ここで 「ついでに動作確認もしたい」 と思い、テスト用のエラー発生APIをこのタイミングで実装してデプロイしました。

# config/routes.rb
Rails.application.routes.draw do
  # ...
  if Rails.env.production? || Rails.env.staging?
    # Sentry動作確認用（必要な期間だけ残す）
    get '/api/test_error', to: 'test#raise_error'
  end
end

# app/controllers/test_controller.rb
class TestController < ApplicationController
  def raise_error
    raise StandardError, "Sentry test error from #{Rails.env}"
  end
end

このデプロイ作業で自動的にECSタスクが再起動されるため、Secrets Managerの更新値も同時に反映 されました。「タスク再起動」と「テスト用API実装」を同時に済ませることで、追加の再起動作業を省くことができ、一石二鳥でした。

その後、/api/test_error にアクセスして意図的にエラーを発生させ、Sentry側のIssue一覧にイベントが届いていることを確認できました。

ハマりポイント2：Alert設定の正しい入り口

DSNの問題が解決し、Sentry側にイベントが届くようになりました。しかし今度は Slackには依然として通知が来ない という新たな問題が発生しました。

起きていたこと

プロジェクトのトップ画面にある大きな 「Create Alert」ボタン からアラートを作ろうとすると、以下のような画面に遷移します。

これは「Metric / Mobile Build / Cron / Uptime」の 新規モニター作成画面 で、私が作りたかった「新規Issueが起きたらSlackに通知する」設定とは異なる画面でした。Sentryには複数のアラート種別があり、それぞれ入り口が違うのです。

正しい入り口

エラー発生時のSlack通知（Issue Alert）を作りたい場合は、左側のサイドバーから Monitors → Alerts を開きます。

ここで右上の 「+ Create Alert」 ボタンからアラートを新規作成します。同じ「Create Alert」というラベルでも、入り口が違うと作成されるアラートの種類が異なる、という点に注意が必要です。

Alert設定の流れ

新しいAlert作成画面では、以下の3セクションを設定します。

• Source：どのプロジェクトのIssueを対象にするか（今回は ruby-rails プロジェクト）
• Filter Issues：環境による絞り込み（今回は All Environments）
• Alert Builder：「いつ」「どんな条件で」「何をするか」を組み立てるメインセクション

Alert Builderの中身（WHEN / IF / THEN）

Alert BuilderではWHEN / IF / THEN の3つを設定します。

• WHEN：トリガーとなるイベント。今回は A new issue is created（新規Issueが作成されたとき）
• IF：追加のフィルタ条件。今回は Any event（すべて通知）
• THEN：実行するアクション。Send a Slack message to the [Slackワークスペース] workspace, to [#sentry]

さらに通知メッセージに含めるタグや、メンションの設定もできます。

ここでは以下を追加で設定しました。

• Tags：environment, level（環境名とエラーレベルをメッセージに表示）
• Notes：@here（チャンネル全員にメンション）

最後に「Create Alert」ボタンを押す

設定が一通り完了したら、画面右下の 「Create Alert」 ボタンを押してアラートを保存します。

最初はこのボタンの存在に気づかず「設定を入力したけど保存ボタンがない…」と詰まっていました。スクロールしないと見えないUIなので、設定後はページ下部までスクロールするのを忘れないようにしてください。

Slack通知のテスト

Alert作成後、再度テスト用APIエンドポイント（/api/test_error）にアクセスし、エラーを発生させて挙動を確認しました。

結果：

• ✅ Sentry側でIssueが起票
• ✅ #sentry チャンネルにSlack通知が到達
• ✅ メッセージに environment と level のタグが含まれている
• ✅ @here で全員にメンションされている

これで「エラー発生 → 即座にSlack通知 → 担当者が対応」というフローが確立できました。

学んだこと

今回の作業で得られた知見をまとめておきます。

• DSNが間違っていると、連携が完了していてもエラー情報は届かない。Sentry-Slack連携の確認画面で「Connected」と出ていても、それはSentry-Slack間が繋がっているだけで、アプリケーション側からSentryへの送信は別問題
• ECS環境でSecrets Managerの値を更新したら、ECSタスクの再起動が必要。再起動のついでにテスト用のエラー発生APIを実装してデプロイすると、追加の再起動を省けて効率的
• SentryのAlert設定には複数の入り口がある。プロジェクトトップの「Create Alert」と「Monitors → Alerts」の「Create Alert」は別物。Issueベースのアラートが欲しい場合は必ず後者から入る
• Alert作成画面の「Create Alert」ボタンは右下、スクロール先にある。設定入力中は見えないので、最後に必ず下までスクロールする
• テスト用エラーAPIは導入時の動作確認に便利。if Rails.env.production? などで保護をかけて、必要な期間だけ残しておくのも一つの選択肢

おわりに

Sentryを導入したことで、エラー発生から気づくまでの時間が「ユーザーから連絡が来るまで」から「数秒〜数分」 に大幅に短縮されました。心理的にも「気づけなかったらどうしよう」という不安から解放されたのが大きいです。

今後の課題としては以下を予定しています。

• エラーレベルごとの通知先・メンションの使い分け（critical は @channel、info は通知のみ など）
• 同種エラーのレート制限（同じエラーで大量通知されないようThrottling調整）
• 担当者ローテーション（オンコール体制の構築）
• エラー対応フローの標準化（Sentryで検知 → 一次対応 → ポストモーテムまで）

技術的な詰まりポイントは多少ありましたが、得られる効果はそれ以上に大きいです。エラー監視を入れていない方には、強くおすすめします。

---

📌 関連記事

• 【2026年6月EOL】Amazon Linux 2からAL2023への移行記
• Hexoアプリケーションの初期設定
• GitHub ActionsでIAM Role認証を使う方法