こんにちは！開発現場の「夜間呼び出し」や「原因不明のエラーとの終わりなき戦い」に、そろそろ終止符を打ちたいと思いませんか？
新しいツールやフレームワークに触れ始めたばかりの頃は、「動くものを作る」だけで精一杯になりがちです。しかし、いざ本番環境にアプリをリリースした途端、ユーザーから「画面が真っ白になりました」「ボタンが反応しません」という報告が飛んできたら……。恐ろしいですよね。
今回は、そんな恐怖をワクワクに変える魔法の組み合わせ、「GitHub Actions」と「Sentry」を連携させた極上のCI/CDパイプライン構築術を伝授します。
これをマスターすれば、毎日のデプロイ作業が劇的に楽になり、「どのコミットがバグを持ち込んだのか」が秒速で特定できるようになりますよ。さあ、一緒にオブザーバビリティ（可観測性）の世界へ飛び込みましょう！
—
1. CI/CDパイプラインにSentryを組み込むメリット
まずは、「なぜSentryとCI/CDを連携させる必要があるのか」という本質からお話しします。
よくあるアンチパターンは、エラー追跡ツール（Sentryなど）をただコードに組み込み、デプロイはデプロイで手動、あるいは別ラインで行っている状態です。これだと何が起きるか？
- 暗号のようなエラーログに悩まされる：WebpackやViteなどでビルドされたJavaScriptは、変数名が難解に圧縮（難読化）されています。Sentryに届くエラーも「`at t.e (main.min.js:1:4820)`」のような、どこを指しているのか全く分からないものになります。
- 「誰が・いつ入れたバグか」が闇の中：エラーが発生しても、それが今日のどのプルリクエストで混入したものか分からないため、開発チーム全員で犯人探し（原因調査）の不毛な会議が始まります。
これらを一撃で解決するのが、CI/CDパイプライン（GitHub Actions）のビルドプロセスとSentryの「Releases（リリース）」機能の融合です。
ビルドの瞬間に「ソースマップ（元のコードと圧縮後を繋ぐ地図）」をSentryにアップロードし、「今からバージョン `v1.2.3` をデプロイするぞ！」とSentryに宣言する。これだけで、エラー発生時に「正確な元のコードの行数」と「混入させた犯人のコミット」が自動紐付けされます。もう暗号を解読する必要はありません。
—
2. GitHub Actionsでビルド時にソースマップを自動アップロードする方法
それでは、実際に手を動かしていきましょう。今回はモダンなWebフロントエンド（React / Vue / Next.jsなど）を想定し、GitHub Actions上でビルドとSentryへのソースマップ自動アップロードを行うワークフローを構築します。
ステップ①：Sentry側の準備
Sentryのダッシュボードから以下の2つを取得しておきます。
1. Organization Slug（組織名）
2. Project Slug（プロジェクト名）
3. Auth Token（APIトークン：`project:releases` や `org:read` などの権限が必要）
取得した Auth Token は、GitHubのレポジトリ設定（`Settings > Secrets and variables > Actions`）に `SENTRY_AUTH_TOKEN` という名前で登録してください。
ステップ②：GitHub Actionsのワークフローファイルを作成する
レポジトリの `.github/workflows/deploy.yml` に、以下の設定を記述します。
name: Production Deploy & Sentry Release
on:
push:
branches:
- main # mainブランチへのプッシュをトリガーにする
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
# 1. リポジトリのコードをチェックアウト
- name: Checkout code
uses: actions/checkout@v4
# 2. Node.jsのセットアップ
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: ’20’
cache: ‘npm’
# 3. 依存関係のインストールとビルド
- name: Install dependencies and build
run: |
npm ci
npm run build
env:
# フロントエンド側でSentryを使う場合はDSNなどもここで渡す
VITE_SENTRY_DSN: ${{ secrets.VITE_SENTRY_DSN }}
# — ここからがSentry連携の核心部分です —
# 4. Sentry CLIのセットアップとリリースの作成・ソースマップアップロード
- name: Create Sentry Release & Upload Source Maps
uses: getsentry/action-release@v1
env:
SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }}
SENTRY_ORG: “あなたの組織名”
SENTRY_PROJECT: “あなたのプロジェクト名”
with:
environment: ‘production’
# GitHubのコミットハッシュをリリースIDとして使うのが定石
version: ${{ github.sha }}
# ビルド成果物（ソースマップが含まれるフォルダ）を指定
sourcemaps: ‘./dist’
# ソースマップアップロード後にサーバー上の元ファイルを削除する（セキュリティのため）
validate: true
# 5. 本番サーバーへのデプロイ処理（例: AWS S3, Vercel, Firebaseなど）
- name: Deploy to Production
run: |
echo “ここにデプロイのコマンドを書きます（例: aws s3 sync …）”
echo “Deployment completed successfully!”
このワークフローの美しいところは、`github.sha`（一意のコミットハッシュ）をSentryのバージョンとして利用している点です。これにより、コードとエラーの世代管理が完全に一致します。
—
3. Sentry Releases機能を使った「どのコミットでバグが混入したか」の特定
無事にワークフローが回り始めると、Sentryのダッシュボードにある [Releases] タブに魔法のような景色が広がります。
ここで何が起きているかと言うと、SentryはGitHubと連携することで以下の情報を自動的に取得しています。
- Commits（コミット履歴）：今回のリリースに含まれる変更差分
- Authors（開発者）：誰がそのコードを書いたか
バグ混入の瞬間を暴く
万が一、本番環境でエラーが発生したとしましょう。Sentryを開くと、エラー詳細画面に 「Suggested Assignee（推奨される担当者）」 や 「Commit」 という項目が表示されます。
「あ、このエラーは昨日の夜、〇〇さんがプルリクエストでマージした、あのコードの書き方に原因があったんだな」と、エラーの発生源から直接、原因となったコミットの差分（Git Diff）まで1クリックで到達できるのです。
「誰のどのコードが原因か」を探すためのログ漁りや、デバッガーとの孤独な格闘はもう終わりです。Sentryがピンポイントで犯人（と救世主であるあなた）を導いてくれます。
—
4. デプロイ成功/失敗のSentryへの通知設定
「デプロイしたはいいが、実は盛大にビルドエラーや設定ミスがあった」という事故を防ぐため、Sentryに対して「今からデプロイが始まるよ（`encounters/commits` の通知）」や「デプロイが終わったよ」というライフサイクルを教えてあげましょう。
先ほどのGitHub Actionsのステップを少し拡張して、デプロイの「開始」と「完了」をSentryに明示的に伝えるベストプラクティスをご紹介します。
# 1. デプロイメントの「開始」をSentryに通知
- name: Notify Sentry – Deployment Start
uses: getsentry/action-release@v1
env:
SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }}
SENTRY_ORG: “あなたの組織名”
SENTRY_PROJECT: “あなたのプロジェクト名”
with:
version: ${{ github.sha }}
# デプロイ開始をステータスとして送信
set_commits: “skip”
# （必要に応じてカスタムアクションを追加）
# — (ビルドやデプロイ処理) —
# 2. デプロイの「完了」をSentryに通知（デプロイメントのトラッキング）
- name: Finalize Sentry Release
uses: gactions/sentry-release@v… # または公式アクションのfinalize機能
# デプロイが成功したタイムスタンプをSentryに教えることで、
# 「このリリース以降に発生したエラー」を正確に計測できるようになります。
これにより、Sentryの画面上で「リリースごとにエラー率がどう変動したか（リグレッション検知）」がひと目でわかるようになります。新しいバージョンを出した瞬間にエラーが急増したら、Sentryが即座に検知してSlackなどにアラートを飛ばしてくれるため、ユーザーからのクレームを受ける前に自分で気づいてサクッとロールバックできるようになります。
—
おわりに：今すぐあなたのパイプラインをアップデートしよう
お疲れ様でした！ ここまで読み進めたあなたなら、GitHub ActionsとSentryを組み合わせることで得られる「圧倒的な安心感」の正体が分かったはずです。
- ソースマップの自動アップロードで、難読化されたエラーを人間が読める形に。
- Releases機能で、どのコミットがバグを持ち込んだのかを完全可視化。
- CI/CD連携により、デプロイメントのライフサイクル全体をSentryに集約。
最初は設定項目が多くて少し難しく感じるかもしれませんが、一度このパイプラインを作ってしまえば、明日からの開発体験が劇的に、それはもう別世界のように楽になります。「エラーに怯えながらデプロイする夜」とは、今日でサヨナラしましょう。
あなたのエンジニアリングライフが、もっとスマートで楽しいものになりますように！