皆さん、こんにちは！オブザーバビリティの深淵をさまよう旅は、いかがお過ごしでしょうか？
今日もまた、現場で「なるほど！」と震えるほど役立つ、極限の知見を皆さんにお届けします。
今回のテーマは「エラートラッキング」の運用、特にRollbarをCI/CDパイプラインと連携させて、日々の運用を劇的に楽にする秘術です。
「エラー監視は大事だけど、過去のエラーが残り続けてノイズだらけ…」
「新しいリリースをするたびに、手動で過去のエラーを解決済みにするの、面倒くさい…」
そんなお悩み、ありませんか？
安心してください。この記事を読めば、その悩みは過去のものになります。
RollbarのPersonal Access Token（PAT）とAPI、そしてちょっとしたスクリプトを駆使して、リリースごとにエラーを自動的にクリーンアップし、常に真に「新しい」エラーに集中できる環境を構築する方法を、優しく丁寧に解説していきます。
これをマスターすれば、毎日の作業が劇的に楽になり、チームの生産性もグンと上がりますよ。さあ、一緒に「ノイズゼロ」の監視環境を目指しましょう！
—
導入：エラートラッキングの「真の」価値と、見過ごされがちな課題
システム開発において、エラートラッキングはもはや必須のツールですよね。Rollbarのようなサービスを導入することで、開発中のバグを素早く発見したり、本番環境で発生した障害をリアルタイムで検知したり、デバッグの時間を大幅に短縮したり…と、そのメリットは計り知れません。
しかし、その一方で、多くのチームが共通して抱える課題があります。それは、「エラートラッキングツールがノイズの温床になってしまう」という問題です。
- テスト環境での一時的なエラー
- 過去のバージョンで修正済みのエラー
- ユーザーの誤操作による軽微なエラー
これらがRollbarの「Active」リストに残り続けると、本当に今、対応すべき重要なエラーが埋もれてしまいがちです。まるで、散らかった部屋から本当に必要なものを見つけ出すようなもの。これでは、せっかくの素晴らしいツールも、その真価を発揮できません。
クリーンな監視環境への道：CI/CD連携
理想的な運用は、「新しいバージョンをリリースするたびに、それ以前に発生していたエラーはすべて解決済みとして扱い、監視リストをリセットする」ことです。これにより、デプロイ後に発生したエラーだけが「新しいエラー」として浮上し、チームは常に最優先で対処すべき問題に集中できます。
でも、これを手動でやるのは現実的ではありませんよね。数百、数千のエラーを手作業でResolvedにするなんて、考えただけでゾッとします。
そこで登場するのが、RollbarのAPIとCI/CDパイプラインの連携です。プログラムの力で、この面倒な作業を自動化してしまいましょう！
—
Step 1: Rollbarの基礎の基礎を知ろう！まずはHelloWorldから
Rollbarを初めて使う方のために、まずは基本的なエラー送信の流れを確認しましょう。すでに使いこなしている方は、このセクションは読み飛ばしても大丈夫です。
Rollbarとは？
Rollbarは、アプリケーションで発生したエラーをリアルタイムで集約・分析・通知してくれるサービスです。どの環境で、どのコード行で、どんなユーザーが、どんな状況でエラーに遭遇したのかを詳細に把握できるため、迅速な問題解決に役立ちます。
アカウント作成とプロジェクト設定（概要）
簡単なエラー送信の例（Python SDK）
Pythonを使って、Rollbarにエラーを送信する最も基本的な方法です。
1. Rollbar SDKのインストール
pip install rollbar
pip install requests # 後でAPIを叩くのに使うので、ついでにインストール
2. エラー送信スクリプトの作成
`send_error.py` というファイルを作成し、以下の内容を記述してください。
`YOUR_ROLLBAR_SERVER_ACCESS_TOKEN` の部分には、Rollbar UIでプロジェクト設定の「Access Tokens」から取得できる「Server-side Access Token」を貼り付けてください。
import rollbar
import os
# — 設定情報 —
# Rollbarのサーバーサイドアクセストークン。
# 環境変数から取得するのがベストプラクティスです。
# Rollbar UIの「Settings」→「Access Tokens」で確認できます。
ROLLBAR_SERVER_ACCESS_TOKEN = os.getenv(“ROLLBAR_SERVER_ACCESS_TOKEN”, “YOUR_ROLLBAR_SERVER_ACCESS_TOKEN”)
# エラーを送信する環境名（例: development, production, staging）
ROLLBAR_ENVIRONMENT = os.getenv(“ROLLBAR_ENVIRONMENT”, “development”)
# Rollbar SDKの初期化
rollbar.init(
ROLLBAR_SERVER_ACCESS_TOKEN,
ROLLBAR_ENVIRONMENT,
root=os.path.dirname(os.path.abspath(__file__)), # 現在のスクリプトのパスをルートとして設定
# その他のオプションも設定できます（例: level=’warning’）
)
def divide_by_zero():
“””
ゼロ除算エラーを意図的に発生させ、Rollbarに送信する関数
“””
print(f”[{ROLLBAR_ENVIRONMENT}]環境にエラーを送信します…”)
try:
result = 1 / 0 # ここでZeroDivisionErrorが発生
except ZeroDivisionError as e:
# 現在発生している例外情報をRollbarにレポートします
rollbar.report_exc_info()
print(“ZeroDivisionErrorをRollbarに送信しました。Rollbar UIで確認してください。”)
except Exception as e:
# その他の予期せぬエラーもキャッチしてRollbarに送信
rollbar.report_exc_info()
print(f”予期せぬエラーが発生し、Rollbarに送信しました: {e}”)
if __name__ == “__main__”:
divide_by_zero()
3. スクリプトの実行
# 環境変数を設定してから実行すると、コードに直接トークンを書かずに済みます。
# ここでは例として直接トークンを設定していますが、本番ではsecrets管理を推奨します。
# export ROLLBAR_SERVER_ACCESS_TOKEN=”your_server_access_token_here”
# export ROLLBAR_ENVIRONMENT=”development”
python send_error.py
4. Rollbar UIでの確認
スクリプトを実行後、Rollbarのダッシュボード（`app.rollbar.com/p/
「development」環境で、先ほど発生させた「ZeroDivisionError」が新しいアイテムとして表示されているはずです。
これが、Rollbarによる基本的なエラートラッキングの仕組みです。簡単ですよね！
—
Step 2: Personal Access Token (PAT) の準備
さて、ここからが本題です。RollbarのAPIを使ってエラーのステータスをプログラムから制御するには、Personal Access Token (PAT) が必要になります。これは、あなたのユーザーアカウントに紐づくAPIキーのようなもので、CLIツールやカスタムスクリプトからRollbarのAPIを認証・実行するために使います。
PATとは何か、なぜ必要か
PATは、ユーザーアカウントの認証情報を直接APIに渡すことなく、APIリクエストを安全に行うための仕組みです。特定の権限（スコープ）を付与できるため、必要な操作だけを許可し、セキュリティリスクを最小限に抑えることができます。
今回のように、CI/CDパイプラインからエラーステータスを更新するような「書き込み」操作を行うには、PATが不可欠です。
PATの作成手順
1. Rollbar UIにログインし、画面左下のあなたのユーザー名をクリックします。
2. メニューから「Personal Access Tokens」を選択します。
3. 「New Personal Access Token」ボタンをクリックします。
4. トークンの「Description」（説明）を入力します。例えば、「CI/CD Error Resolver」など、用途が分かるようにしておくと良いでしょう。
5. 「Scopes」（権限）を設定します。今回、エラーのリストを取得し、そのステータスを更新する必要があるため、以下のスコープにチェックを入れてください。
- `read_items`: アイテム（エラー）情報を読み取るため
- `write_items`: アイテムのステータスを更新するため
(画像はRollbar公式ドキュメントより引用)
6. 「Create Personal Access Token」をクリックすると、トークンが生成されます。
生成されたトークンは一度しか表示されません！ 必ず安全な場所に控えておきましょう。
セキュリティに関する注意喚起
PATは非常に強力な認証情報です。 漏洩すると、あなたのRollbarアカウントを悪用される可能性があります。
- コードに直接書き込まないでください。
- 環境変数やCI/CDサービスのシークレット管理機能を利用して安全に保管してください。
- 必要最小限のスコープ（権限）のみを付与してください。
—
Step 3: Rollbar CLIの導入とセットアップ (任意だが推奨)
Rollbar CLIは、Rollbar APIをコマンドラインから手軽に操作するためのツールです。今回の目的であるエラーの一括解決には直接APIを叩くスクリプトを使いますが、Rollbar CLIを導入しておくと、プロジェクトIDの確認や設定のデバッグなど、様々な場面で役立ちます。
インストール方法
Pythonのパッケージ管理ツール `pip` を使って簡単にインストールできます。
pip install rollbar-cli
PATを使った認証設定
Rollbar CLIを初めて使う際、PATを使って認証設定を行います。
rollbar configure
このコマンドを実行すると、あなたのRollbar Personal Access Tokenの入力を求められます。Step 2で作成したPATを貼り付けてください。
簡単なCLIコマンド実行例
設定が完了したら、いくつかのコマンドを試してみましょう。
- プロジェクト一覧の取得
rollbar projects list
これで、あなたのRollbarアカウントに関連付けられているプロジェクトの一覧が表示されます。このとき表示される`project_id`は、後でスクリプトで使うので控えておきましょう。
- 環境一覧の取得
rollbar environments list –project-id
`
これらのコマンドは、APIが正しく認証されているか、必要な情報が取得できるかを確認するのに非常に便利です。
—
Step 4: CI/CDパイプラインでのエラーステータス一括管理の実践
いよいよ本丸です！
ここでは、新しいバージョンをリリースするたびに、指定した環境（例: `production`）のアクティブなエラーをすべて「Resolved」（解決済み）状態に自動で更新するPythonスクリプトを作成し、その仕組みを解説します。
シナリオ説明
私たちの目標は、デプロイが成功した直後にこのスクリプトを実行することです。これにより、デプロイ前の「古い」エラーはすべて解決済みとなり、デプロイ後に初めて発生するエラーだけが、Rollbarのダッシュボードで「新しい問題」として認識されます。これにより、開発チームは常に最新の状況に集中できるようになります。
ロジックの概要
1. RollbarのPersonal Access Tokenを認証情報として使用します。
2. 指定されたRollbarプロジェクトと環境（例: `production`）のアクティブなアイテム（エラー）をすべて取得します。
3. 取得した各アイテムのステータスを「Resolved」に更新します。
エラーステータス一括解決スクリプトの作成
`resolve_rollbar_errors.py` という名前で以下のPythonスクリプトを作成してください。
このスクリプトは、`requests` ライブラリを使ってRollbarのREST APIを直接叩きます。
import os
import requests
import time
import sys
— 設定情報 —
Rollbar Personal Access Token。
環境変数から取得するのが最も安全で推奨される方法です。
事前に `export ROLLBAR_ACCESS_TOKEN=”your_pat_here”` のように設定してください。
ROLLBAR_ACCESS_TOKEN = os.getenv(“ROLLBAR_ACCESS_TOKEN”)
RollbarプロジェクトID。
環境変数から取得します。`rollbar projects list` コマンドで確認できます。
事前に `export ROLLBAR_PROJECT_ID=”your_project_id_here”` のように設定してください。
ROLLBAR_PROJECT_ID = os.getenv(“ROLLBAR_PROJECT_ID”)
解決済みにする対象の環境名。
環境変数から取得します。デフォルトは ‘production’ です。
例: `export TARGET_ENVIRONMENT=”staging”`
TARGET_ENVIRONMENT = os.getenv(“TARGET_ENVIRONMENT”, “production”)
Rollbar APIのベースURL
API_BASE_URL = “https://api.rollbar.com/api/1”
— 前提条件チェック —
if not ROLLBAR_ACCESS_TOKEN:
print(“エラー: ROLLBAR_ACCESS_TOKEN 環境変数が設定されていません。”, file=sys.stderr)
print(“Personal Access Tokenを `export ROLLBAR_ACCESS_TOKEN=’
sys.exit(1)
if not ROLLBAR_PROJECT_ID:
print(“エラー: ROLLBAR_PROJECT_ID 環境変数が設定されていません。”, file=sys.stderr)
print(“プロジェクトIDを `export ROLLBAR_PROJECT_ID=’
sys.exit(1)
— APIリクエストヘッダー —
Rollbar APIは `X-Rollbar-Access-Token` ヘッダーで認証を行います。
headers = {
“X-Rollbar-Access-Token”: ROLLBAR_ACCESS_TOKEN,
“Content-Type”: “application/json”
}
def get_active_items():
“””
指定されたプロジェクトと環境のアクティブなRollbarアイテムをすべて取得します。
Rollbar APIのページネーションに対応しています。
“””
url = f”{API_BASE_URL}/items”
params = {
“project_id”: ROLLBAR_PROJECT_ID,
“status”: “active”,
“environment”: TARGET_ENVIRONMENT,
“page”: 1,
“per_page”: 200 # 1ページあたりの最大取得数 (Rollbar APIの制限)
}
all_items = []
print(f”RollbarプロジェクトID: {ROLLBAR_PROJECT_ID}, 環境: {TARGET_ENVIRONMENT} のアクティブなエラーを取得中…”)
while True:
try:
response = requests.get(url, headers=headers, params=params)
response.raise_for_status() # HTTPエラーがあれば例外を発生させる (4xx, 5xx)
data = response.json()
items = data.get(‘result’, [])
all_items.extend(items)
print(f” ページ {params[‘page’]}: {len(items)} 件のアイテムを取得しました。合計: {len(all_items)} 件”)
if not items or len(items) < params['per_page']: break # 全てのアイテムを取得し終えたか、これ以上アイテムがない params['page'] += 1 time.sleep(1) # API Rate Limit対策: リクエスト間に少し間隔を空ける except requests.exceptions.RequestException as e: print(f"エラー: アクティブなアイテムの取得中に問題が発生しました: {e}", file=sys.stderr) sys.exit(1) except Exception as e: print(f"予期せぬエラー: {e}", file=sys.stderr) sys.exit(1) return all_items def resolve_item(item_id): """ 指定されたRollbarアイテムをResolvedステータスに更新します。 """ url = f"{API_BASE_URL}/item/{item_id}" payload = {"status": "resolved"} # ステータスを 'resolved' に設定 try: response = requests.patch(url, headers=headers, json=payload) response.raise_for_status() print(f" アイテム {item_id} をResolvedに更新しました。") except requests.exceptions.RequestException as e: print(f"エラー: アイテム {item_id} の更新中に問題が発生しました: {e}", file=sys.stderr) # 個別のアイテム更新失敗は処理を中断せず、次へ進む except Exception as e: print(f"予期せぬエラー: アイテム {item_id} の更新中に発生: {e}", file=sys.stderr) def main(): """ メイン処理: アクティブなエラーを取得し、Resolvedに更新します。 """ print("--- Rollbarアクティブエラー解決処理 開始 ---") print(f"対象環境: {TARGET_ENVIRONMENT}") active_items = get_active_items() if not active_items: print("解決すべきアクティブなエラーは見つかりませんでした。") print("--- Rollbarアクティブエラー解決処理 完了 ---") return print(f"\n合計 {len(active_items)} 件のアクティブなエラーが見つかりました。解決処理を開始します。\n") for i, item in enumerate(active_items): resolve_item(item['id']) # API Rate Limit対策: 個々のアイテム更新間にも少し間隔を空ける # 大量のアイテムがある場合は、より長い間隔が必要になることもあります。 if i % 10 == 0: # 10件ごとに少し長めに待つ time.sleep(0.5) else: time.sleep(0.1) print("\n全てのアクティブなエラーの解決処理が完了しました。") print("--- Rollbarアクティブエラー解決処理 完了 ---") if __name__ == "__main__": main()
スクリプトの実行方法
このスクリプトを実行するには、環境変数にPATとプロジェクトIDを設定する必要があります。
Personal Access Tokenを設定 (Step 2で作成したもの)
export ROLLBAR_ACCESS_TOKEN=”your_personal_access_token_here”
RollbarプロジェクトIDを設定 (rollbar projects list で確認したもの)
export ROLLBAR_PROJECT_ID=”your_rollbar_project_id_here”
対象環境を設定 (省略可能、デフォルトはproduction)
export TARGET_ENVIRONMENT=”staging” # 例: staging環境のアクティブエラーを解決
スクリプトを実行
python resolve_rollbar_errors.py
実行すると、指定された環境のアクティブなエラーが順次Resolved状態に更新されていく様子がコンソールに表示されます。Rollbar UIをリロードすると、これらのエラーが「Resolved」タブに移動していることを確認できるはずです。
—
Step 5: CI/CDパイプラインへの組み込み
この強力なスクリプトを、あなたのCI/CDパイプラインに組み込みましょう！
デプロイが成功した直後、つまり新しいコードが本番環境に反映された後にこのスクリプトを実行するのが理想的なタイミングです。
ここでは、一般的なCI/CDサービスであるGitHub Actionsを例に、組み込み方を示します。
GitHub Actionsのワークフロー例
`.github/workflows/deploy.yml` のようなファイルを作成し、以下の内容を記述します。
name: Deploy Application and Resolve Rollbar Errors
on:
push:
branches:
- main # mainブランチへのpushをトリガーとする
jobs:
deploy:
runs-on: ubuntu-latest # 実行環境の指定
steps:
- name: Checkout code
uses: actions/checkout@v3 # リポジトリのコードをチェックアウト
# — ここにアプリケーションのビルド、テスト、デプロイのステップを記述します —
# 例: Dockerイメージのビルド、クラウドプロバイダへのデプロイコマンド、など
- name: Simulate Application Deployment # デプロイのシミュレーション（実際のデプロイコマンドに置き換えてください）
run: |
echo “アプリケーションのデプロイを開始します…”
sleep 10 # デプロイにかかる時間をシミュレート
echo “アプリケーションが正常にデプロイされました！”
# — Rollbarエラー解決スクリプトの実行 —
- name: Set up Python environment
uses: actions/setup-python@v4 # Python環境をセットアップ
with:
python-version: ‘3.x’ # 使用するPythonのバージョンを指定
- name: Install Python dependencies
run: pip install requests # スクリプトで必要な ‘requests’ ライブラリをインストール
- name: Resolve Active Rollbar Errors
env:
# Rollbar Personal Access TokenをGitHub Secretsから安全に取得
ROLLBAR_ACCESS_TOKEN: ${{ secrets.ROLLBAR_PERSONAL_ACCESS_TOKEN }}
# RollbarプロジェクトIDもGitHub Secretsから取得
ROLLBAR_PROJECT_ID: ${{ secrets.ROLLBAR_PROJECT_ID }}
# エラーを解決する対象の環境を指定
TARGET_ENVIRONMENT: production # 環境に合わせて ‘staging’ などに変更してください
run: python ./resolve_rollbar_errors.py # 作成したスクリプトを実行
# エラー解決スクリプトが失敗してもデプロイ自体は成功としたい場合、
# continue-on-error: true を追加することも検討してください。
GitHub Secretsの設定
GitHub ActionsでPATやプロジェクトIDを安全に扱うために、リポジトリの「Settings」→「Secrets and variables」→「Actions」で以下のシークレットを設定してください。
- `ROLLBAR_PERSONAL_ACCESS_TOKEN`: あなたのRollbar Personal Access Token
- `ROLLBAR_PROJECT_ID`: あなたのRollbarプロジェクトID
これにより、機密情報が公開されることなく、CI/CDパイプラインから安全にRollbar APIを操作できるようになります。
—
Step 6: 発展的な活用と注意点
この自動化は非常に強力ですが、さらに効果的に運用するためのヒントと、いくつか注意すべき点があります。
発展的な活用
- 特定のバージョンより前のエラーだけResolvedにする:
Rollbar APIの`items`エンドポイントは、`v_gte` (version greater than or equal) や `v_lte` (version less than or equal) などのフィルタリングパラメータをサポートしています。
これを利用して、「デプロイするバージョンより前のエラーのみをResolvedにする」といった、よりきめ細かい制御が可能です。
これにより、例えば複数ブランチで並行開発している際に、特定のブランチのリリースだけが他のブランチのエラーに影響を与えないようにできます。
(例: `params[“v_lte”] = “1.2.3”` など)
- Resolved以外のステータスに更新する:
Rollbarアイテムは`resolved`以外にも`assigned`、`muted`、`archived`などのステータスがあります。
特定の条件（例: `development`環境での軽微なエラー）では`ignored`（無視）や`archived`（アーカイブ）にするといった運用も考えられます。
`payload = {“status”: “archived”}` のように変更するだけで簡単に対応できます。
- 通知との連携:
エラーを解決済みにしたことを、SlackやMicrosoft Teamsなどのチャットツールに通知する仕組みを組み込むこともできます。これにより、チーム全体で監視状況を共有し、安心感を得られます。
注意点
- API Rate Limitへの注意:
Rollbar APIには、短時間で実行できるリクエスト数に制限（Rate Limit）があります。
本記事のスクリプトでは`time.sleep()`を使って意図的に間隔を空けていますが、大量のエラーを一括で処理する場合、さらに間隔を広げる必要があるかもしれません。
Rollbar APIのレスポンスヘッダーにはRate Limitに関する情報が含まれているので、より堅牢なスクリプトではこれらをチェックし、動的に待機時間を調整するロジックを組み込むことも可能です。
- 「本当に解決したエラーだけをResolvedにする」という思想:
この自動化は非常に便利ですが、闇雲にすべてをResolvedにするのは避けるべきです。
`production`環境での自動Resolvedは有効ですが、`staging`や`development`環境では、開発中のバグを見落とさないように、手動での確認や特定の条件でのみ自動Resolvedを行うなど、環境に応じた運用ポリシーを確立することが重要です。
「エラーをクリアにする」こと自体が目的ではなく、「本当に対応すべきエラーに集中する」ことが目的であることを常に意識しましょう。
—
まとめ：クリーンなオブザーバビリティの実現へ
お疲れ様でした！今回はRollbarのPersonal Access TokenとAPIを駆使し、CI/CDパイプラインからエラーステータスを一括管理する高度な運用テクニックを学びました。
この手法を導入することで、あなたは以下の大きなメリットを得られます。
1. ノイズの劇的な削減: 過去のエラーに悩まされることなく、常に真に新しい問題に集中できます。
2. 運用負荷の軽減: 面倒な手動でのエラークローズ作業から解放され、より価値のある開発業務に時間を割けます。
3. 迅速な問題解決: 本当に重要なエラーが明確になるため、チームは素早く対応し、サービスの安定性を高めることができます。
オブザーバビリティは、単にデータを集めるだけでなく、そのデータをいかに「有効活用」するかが鍵となります。今回の自動化は、その有効活用の一つの形です。
ぜひあなたのプロジェクトにこの仕組みを導入し、ストレスフリーでクリアな監視環境を実現してください。
これからのあなたのオブザーバビリティの旅が、より快適で生産的なものになることを心から願っています！
それでは、また次の深淵でお会いしましょう！