こんにちは！開発現場の「夜間呼び出しアラート」に怯える日々に、そろそろサヨナラしませんか？
優秀なエンジニアほど、プロダクトの価値を上げるコード書きに集中したいはずなのに、障害が起きた瞬間に「これ、一体どのデプロイで混入したバグだ…？」とGitの履歴を漁る泥沼の犯人探しに時間を溶かしてしまいます。
これを一発で解決するのが、今回紹介する「GitHub Actions × Rollbar デプロイ追跡（Deploy Tracking）の自動化」です。
これをマスターすれば、毎日の作業が劇的に楽になりますよ。
今日は、エラートラッキングツール「Rollbar」の本質的な価値を引き出し、CI/CDパイプラインと完全に融合させるための極意を、優しく丁寧に、そして骨太にお伝えします。
—
なぜ、ただのエラー通知では不十分なのか？（オブザーバビリティの思想）
多くのチームは、エラー検知ツールを導入しただけで満足しています。「エラーが出たらSlackに飛ぶ。よし、完璧だ」と。
しかし、現場の現実はこうです。
Slackに「NullPointerExceptionが発生しました」と通知が飛んできたとしましょう。あなたはそのエラー画面を見て、すぐに原因のコミットを特定できますか？ おそらく、直近のプルリクエストのリストを眺め、「うーん、このへんのどれかかな…」と冷や汗をかくことになります。
ここでデプロイ追跡（Deploy Tracking）の出番です。
Rollbarに「今、この瞬間に、このGitコミット（ハッシュ値）を含んだバージョンが本番環境にデプロイされた」という事実を正確に伝えることで、Rollbar側は以下のような魔法のような恩恵をもたらしてくれます。
1. エラーとコードの完全な紐付け: 「このエラーは、3時間前にマージされたPR #42（コミット `a1b2c3d`）で導入された」とピンポイントで指し示してくれる。
2. デプロイごとの品質比較: 新しいバージョンをリリースした途端にエラーレートが跳ね上がった場合、即座に「今回のデプロイが原因である」と断定できる。
3. 自動ロールバックの判断材料: 健全なCI/CDパイプラインにおいて、デプロイ後のエラー急増を検知するトリガーになる。
それでは、この強力な仕組みをGitHub Actionsを使って数分で構築していきましょう！
—
ステップ1：前提知識とRollbar側の準備
まずは、Rollbar側で「デプロイ情報を受け入れるためのパスポート」を発行します。
1. Rollbarプロジェクトの作成
Rollbarにログインし、プロジェクトを作成します（言語・フレームワークは何でも構いません。今回はNode.jsやPython、Goなど、あらゆる構成を想定した汎用的な手法を解説します）。
2. Access Tokenの取得
Rollbarのダッシュボードから、Settings > Access Tokens へ移動します。
ここで重要なのは、通常の「post_server_item」トークンではなく、デプロイメント情報を書き込むための権限を持ったトークンが必要だという点です。
- Token Name: `deploy-bot` などわかりやすい名前
- Scopes: `deploy` にチェックを入れる（ここが超重要！）
生成されたトークンをコピーし、GitHubリポジトリの Settings > Secrets and variables > Actions に `ROLLBAR_ACCESS_TOKEN` という名前で登録してください。
—
ステップ2：GitHub Actionsワークフローの構築
ここからが本題です。GitHub ActionsのCI/CDパイプラインに、デプロイ通知ステップを組み込みます。
多くのエンジニアは「独自のシェルスクリプトでRollbarのAPIを叩く」か「よくわからないサードパーティ製の巨大なアクション」を使おうとしますが、私たちはもっとシンプルで堅牢な方法をとります。Rollbar公式が提供している軽量なAPI、あるいはスマートなコミュニティアクションを活用しましょう。
以下に、実戦でそのまま使えるGitHub Actionsのワークフローファイル（`.github/workflows/deploy.yml`）の模範解答を示します。
name: Production Deploy & Rollbar Tracking
on:
push:
branches:
- main # mainブランチへのマージ（デプロイ）をトリガーにする
jobs:
deploy-and-track:
runs-on: ubuntu-latest
steps:
# 1. リポジトリのコードをチェックアウト（Gitの履歴も取得することが極めて重要）
- name: Checkout Code
uses: actions/checkout@v4
with:
fetch-depth: 0 # 全てのコミット履歴を取得し、誰が何を書いたか追跡できるようにする
# 2. （ここに実際のビルドやデプロイの処理が入ります例：AWS、GCP、Vercel、Dockerなど）
- name: Run Build and Deploy
run: |
echo “🚀 アプリケーションのビルドとデプロイを実行中…”
# 例: docker build & push や サーバーへのデプロイコマンド
echo “Deploy completed successfully!”
# 3. Rollbarへデプロイメント情報を送信（★ここが今回の主役！）
- name: Notify Deploy to Rollbar
uses: rollbar/github-actions-deploy@v2
with:
environment: ‘production’ # デプロイ先の環境名（staging, productionなど）
access-token: ${{ secrets.ROLLBAR_ACCESS_TOKEN }}
# GitHub Actionsが標準提供する環境変数から、コミットや作者情報を自動抽出
revision: ${{ github.sha }}
local-username: ${{ github.actor }}
comment: “Deployed via GitHub Actions (Run ID: ${{ github.run_id }})”
💡 先輩エンジニアからの極上のアドバイス（ハマりどころの回避）
上記のコードで最も注目してほしいのは、`actions/checkout@v4` の設定にある `fetch-depth: 0` です。
通常、GitHub Actionsのデフォルト設定では「直近のコミット（depth: 1）」しか取得しません。しかし、これだとRollbar側が「どのコミットからどのコミットまでの差分（Changelog）でこのエラーが起きたのか」を計算できなくなってしまいます。
`fetch-depth: 0` を指定してすべての歴史をフェッチさせることが、精度高いデプロイ追跡の絶対条件です。
—
ステップ3：動作確認（HelloWorld的検証）
設定が完了したら、実際にコードを修正してmainブランチにプッシュし、動作を確認してみましょう。
1. 適当なファイルを少し修正し、PRを作って `main` ブランチにマージします。
2. GitHubの Actions タブを開き、ワークフローが正常にグリーン（成功）になったことを確認します。
3. `Notify Deploy to Rollbar` のステップのログを開き、Rollbar APIから `200 OK` が返ってきていることを確認します。
4. Rollbarのダッシュボードを開き、左メニューの Deployments をクリックします。
ここに、たった今あなたがデプロイしたGitのコミットハッシュ、ブランチ名、そしてデプロイを実行したあなたのGitHubユーザー名が美しくリストアップされていれば……完全勝利です！お疲れ様でした！
—
まとめ：エラーは「敵」から「改善の羅針盤」へ
いかがでしょうか？
たったこれだけの数行の設定を加えるだけで、Rollbarは単なる「エラーのゴミ箱」から、「どのコードがプロダクトを壊したかを正確に教えてくれる優秀なナビゲーター」へと生まれ変わります。
障害が起きたとき、もう慌ててGitのログを遡る必要はありません。Rollbarを開けば、犯人のコミットとプルリクエストがあなたを優しく待っています。
この小さな自動化の積み重ねが、あなたの開発ライフを劇的に快適にし、心理的安全性を最高潮まで高めてくれます。
さあ、今すぐあなたのパイプラインにもRollbarのデプロイ追跡を組み込んで、優雅な開発ライフを手に入れましょう！