運用監視の深淵：Sentry × GitHub Actionsで「デプロイの恐怖」を「信頼」に変える極意
君たちが日々戦っているのは、コードを書くことだけではないはずだ。真の戦場は「デプロイした瞬間に鳴り響くアラート」にある。
「どのコードが原因だ？」「ソースマップはどこだ？」「誰がいつデプロイした？」――この問いに即答できない状態は、オブザーバビリティの敗北を意味する。Sentryを単なる「エラー通知ツール」として使っているなら、今すぐその認識を捨てろ。
本稿では、SentryをCI/CDと完全統合し、デプロイごとの「解像度」を極限まで高めるための技術論を伝授する。
—
1. なぜ「リリース追跡」が聖域なのか
多くの現場では、Sentryにエラーが飛んでくるだけの状態になっている。これでは、「エラーが起きたこと」しか分からない。
真のテックリードが求めるのは、「どのコミットが、どの環境の、どのリリースで、誰によって投入されたか」の因果関係だ。これを自動化すれば、障害発生時の平均修復時間（MTTR）は劇的に短縮される。Sentryのリリース機能は、単なるラベルではない。エラーとコードを紐づける「最強の追跡デバイス」なのだ。
—
2. 【実践】GitHub Actionsによるソースマップ自動アップロード
フロントエンドのビルド成果物は難読化されている。ソースマップなしでSentryを見るのは、目隠しをしてジャングルを歩くようなものだ。以下のYAML構成を `.github/workflows/deploy.yml` に組み込め。
jobs:
sentry-release:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Create Sentry Release
run: |
# Sentry CLIの設定（環境変数で渡すのがベスト）
export SENTRY_ORG=${{ secrets.SENTRY_ORG }}
export SENTRY_PROJECT=${{ secrets.SENTRY_PROJECT }}
export SENTRY_AUTH_TOKEN=${{ secrets.SENTRY_AUTH_TOKEN }}
# リリースの作成（GitのコミットSHAを紐づけるのが鍵）
sentry-cli releases new $GITHUB_SHA
# ソースマップのアップロード（–rewrite を忘れずに）
# これにより、Sentry側で難読化コードを元のコードに変換可能になる
sentry-cli releases files $GITHUB_SHA upload-sourcemaps ./dist –rewrite
# リリースのデプロイ完了通知
sentry-cli releases finalize $GITHUB_SHA
【プロの知見】
- `–rewrite` オプションは必須: これにより、アップロード時にソースマップ内のパスを相対化し、Sentry側でのマッチング精度を向上させる。
- `sentry-cli` のキャッシュ: `actions/cache` を使い、ビルド済みソースマップの転送を最適化せよ。大規模プロジェクトではこれだけで数分の短縮になる。
—
3. 「どのコミットでバグが混入したか」を特定する魔法
Sentryの「Suspect Commits」を有効にすれば、エラー詳細画面で「このコミットが原因である可能性が高い」とSentryが教えてくれるようになる。
これを実現するには、Sentryにコミット情報を教える必要がある。
上記のYAMLに以下を追加
sentry-cli releases set-commits $GITHUB_SHA –auto
これだけで、SentryはGitHubのコミット履歴を解析し、スタックトレースとコード行を突き合わせる。「犯人」が誰で、どのPRで混入したかが一撃で可視化される。 チームメンバーに「君のコミットでエラーが出ている」と伝えるのは心苦しいが、それが最短の解決策だ。
—
4. チームを加速させる「現場の極意」
① エラーを「無視」する技術（Issue Owners）
全てのエラーを通知するのはノイズの元だ。`CODEOWNERS` ファイルとSentryを連携させろ。特定パスの修正担当者にのみ通知を飛ばす設定をすれば、チームの集中力は散漫にならない。
② 神ショートカットを叩き込め
Sentryの画面で以下のキーを試せ。
- `j` / `k`: Issueの高速移動（マウスを触るな、キーボードで制圧しろ）
- `?`: 全ショートカットの表示
③ 絶対に入れるべき神プラグイン
- GitHub Integration: これを入れないと始まらない。エラー画面から直接Issueを作成し、修正PRがマージされたら自動でSentryのIssueをクローズする。この「自動クローズ」のサイクルこそが、オブザーバビリティの完成形だ。
④ 設定の共有化ルール（.sentryclirc）
プロジェクトルートに `.sentryclirc` を配置し、環境依存の設定をGit管理しろ。
[defaults]
project = your-project-name
org = your-org-name
[auth]
token = … # ここは環境変数 SENTRY_AUTH_TOKEN を優先させること
—
最後に：エンジニアは「アラート」ではなく「改善」に向き合え
Sentryを正しく設定すれば、デプロイは「祈る作業」ではなく「確信を持って行う作業」に変わる。
エラーは「悪」ではない。システムが君たちに送っている「ここが弱いよ」という貴重なサインだ。
CI/CDの中にオブザーバビリティを組み込み、誰よりも早くエラーの芽を摘む。それが、プロダクトの寿命を延ばし、チームの誇りを守る唯一の道だ。
今日、この設定をプルリクに入れろ。明日の君は、アラートに追われるのではなく、プロダクトの未来を設計するエンジニアに戻っているはずだ。