はじめに、想像してみてください。
夜間やリリース直後、本番環境で「重大なエラー（Critical）」が発生しました。これまでは、Slackの通知に誰かが気づき、ログを追いかけ、エラー内容をコピー＆ペーストしてJiraやNotionに手動でバグ起票を行っていましたよね。これでは初動が遅れるだけでなく、開発者の精神的な負担も無視できません。
もし、「本番環境でCriticalエラーが発生した、まさにその瞬間に、裏側で自動的にJiraやNotionに美しいバグチケットが起票されている」としたらどうでしょうか？
エンジニアが確認したときには、すでにインシデントのコンテキスト（エラーメッセージ、発生箇所、スタックトレースのリンク）が綺麗に整理されたチケットが目の前にあります。あとは原因を突き止めて修正するだけ。毎日の運用が劇的に楽になり、トラブル対応のスピードは異次元のものになります。
今回は、世界中で愛されるエラートラッキングツール「Rollbar」のWebhook機能と、サーバーレスの代名詞「AWS Lambda」を組み合わせ、この「手動起票ゼロ」の夢の仕組みを構築していきましょう。
初心者の方でも迷わないよう、アーキテクチャの解説から、具体的なコード、そして感動の動作確認（HelloWorld）まで、一歩ずつ丁寧に進めていきますね。
—
1. 全体像：なぜこの組み合わせが「最強」なのか？
まずは、今回作成するシステムの全体像（アーキテクチャ）を見てみましょう。
[アプリケーション] (エラー発生！)
│
▼ (1) SDK経由でリアルタイム送信
[Rollbar] (Criticalエラーを検知)
│
▼ (2) Webhookをトリガー (JSONデータを送信)
[Amazon API Gateway]
│
▼ (3) HTTPリクエストを中継
[AWS Lambda] (Node.js / Python) ── (4) ペイロードを解析・整形
│
▼ (5) API経由で自動起票
[Jira / Notion] (チケットが即座に誕生！)
この構成が優れている理由は3つあります。
1. 完全なるリアルタイム性: エラーが発生してからチケットが作成されるまで、わずか数秒です。
2. 疎結合（ルーズ・カップリング）: アプリケーション自体に「Jiraに書き込むコード」を書く必要はありません。アプリはRollbarにエラーを投げるだけ。あとは裏側で非同期に処理されます。
3. 極めて低コスト: AWS LambdaやAPI Gatewayは、呼び出された分だけ課金される（従量課金制）ため、エラーが発生していない平常時はほぼ0円で運用できます。
—
2. Step 1: Rollbarの準備と「HelloWorld」エラーの送信
まずは心臓部となるRollbarをセットアップしましょう。アカウントをお持ちでない方は、無料プランで簡単に作成できます。
1. プロジェクトの作成
Rollbarにログインしたら、新しいプロジェクトを作成します。
- Project Name: `auto-ticket-demo` などの分かりやすい名前
- Platform: お使いの言語（今回はテスト用に `Python` または `JavaScript` を選択するのが手軽でおすすめです）
作成が完了すると、「Access Token（post_client_item または post_server_item）」が表示されます。これは後ほど、テストエラーを送信する際に使用するのでメモしておいてください。
2. ローカルからRollbarへ「初エラー」を送信してみる
まずはRollbarが正しく動いているか、手元からテスト用のエラーを送信して「HelloWorld」を確認しましょう。ここでは手軽なPythonを使ったコード例を示します。
pip install rollbar で事前にライブラリをインストールしておきます
import rollbar
Rollbarの初期化 (Access Tokenを貼り付けてください)
rollbar.init(
access_token=’YOUR_ROLLBAR_PROJECT_ACCESS_TOKEN’,
environment=’production’ # 本番環境を想定
)
try:
# 意図的にゼロ除算エラーを発生させます
result = 1 / 0
except ZeroDivisionError as e:
# Rollbarに「Critical（重大）」レベルでエラーを送信します
rollbar.report_exc_info(level=’critical’)
print(“RollbarにCriticalエラーを送信しました！”)
このスクリプトを実行し、Rollbarの管理画面（Itemsメニュー）を開いてみてください。
無事にエラーが1件、真っ赤な「critical」のラベルを伴って表示されていれば、第一段階はクリアです！
—
3. Step 2: 受信デポ（AWS Lambda）の実装
次に、Rollbarからの通知（Webhook）を受け取って、JiraやNotionへチケット起票のリクエストを送るAWS Lambdaを作成します。
今回は、開発者が最も親しみやすく、JSONの扱いが得意な Python 3.11 を使ってLambda関数を記述します。
1. Lambda関数の新規作成
1. AWSコンソールにログインし、Lambda のダッシュボードを開きます。
2. 「関数の作成」をクリックします。
- 関数名: `rollbar-webhook-to-ticket`
- ランタイム: `Python 3.11`（または最新のPython）
- アーキテクチャ: `x86_64`
3. 「関数の作成」をクリックします。
2. Lambdaコードの実装
作成された関数のコードエディタに、以下のコードを貼り付けます。
今回は例として、モダンでAPIが非常に使いやすい「Notion」にタスクページを作成するコードをベースに解説します（Jiraの場合も、宛先のURLとヘッダー、JSONの形を変えるだけで本質は全く同じです）。
import json
import urllib.request
import os
環境変数から設定情報を取得（ハードコードを避けるためのベストプラクティスです）
NOTION_API_KEY = os.environ.get(‘NOTION_API_KEY’)
NOTION_DATABASE_ID = os.environ.get(‘NOTION_DATABASE_ID’)
def lambda_handler(event, context):
# 1. API Gateway経由で届いたRollbarのWebhookボディを解析
try:
body = json.loads(event.get(‘body’, ‘{}’))
except Exception as e:
return {
‘statusCode’: 400,
‘body’: json.dumps(‘Invalid JSON payload’)
}
# RollbarのWebhookから必要な情報を抽出
# ※Rollbarのデータ構造から、エラーのタイトルや詳細、リンクを取得します
data = body.get(‘data’, {})
item = data.get(‘item’, {})
# エラー情報の抽出
error_title = item.get(‘title’, ‘Unknown Rollbar Error’)
error_level = item.get(‘level’, ‘unknown’)
rollbar_url = f”https://rollbar.com/item/uuid/?uuid={item.get(‘uuid’, ”)}”
print(f”検知したエラー: {error_title} [Level: {error_level}]”)
# 2. Critical（重大）エラー以外はスルーするフィルター（二重の安全弁）
if error_level != ‘critical’:
return {
‘statusCode’: 200,
‘body’: json.dumps(f”Ignored. Level is {error_level}, not critical.”)
}
# 3. Notion APIへのリクエストデータを作成
# Notionのデータベースに「タイトル」と「Rollbarへのリンク」を差し込んだページを作成します
notion_url = “https://api.notion.com/v1/pages”
headers = {
“Authorization”: f”Bearer {NOTION_API_KEY}”,
“Content-Type”: “application/json”,
“Notion-Version”: “2022-06-28”
}
# Notionデータベースのスキーマに合わせたペイロード
payload = {
“parent”: { “database_id”: NOTION_DATABASE_ID },
“properties”: {
“Name”: { # データベースのタイトル列の名前（環境に合わせて変更してください）
“title”: [
{
“text”: {
“content”: f”[🚨CRITICAL] {error_title}”
}
}
]
},
“Severity”: {
“select”: {
“name”: “Critical”
}
},
“Rollbar Link”: {
“url”: rollbar_url
}
}
}
# 4. HTTPリクエストの送信（外部ライブラリ不要の標準urllibを使用）
req = urllib.request.Request(
notion_url,
data=json.dumps(payload).encode(‘utf-8′),
headers=headers,
method=’POST’
)
try:
with urllib.request.urlopen(req) as res:
response_body = res.read().decode(‘utf-8’)
print(“Notionへの起票に成功しました！”)
return {
‘statusCode’: 200,
‘body’: json.dumps(‘Ticket created successfully!’)
}
except Exception as e:
print(f”エラー発生: {str(e)}”)
return {
‘statusCode’: 500,
‘body’: json.dumps(f”Failed to create ticket: {str(e)}”)
}
3. 環境変数の設定
Lambdaの「設定」タブ ＞ 「環境変数」から、以下の2つを登録します。
- `NOTION_API_KEY`: Notionのインテグレーションから発行したシークレットキー（`secret_…`）
- `NOTION_DATABASE_ID`: チケットを溜めたいNotionデータベースのID（URLから抽出可能）
4. API Gatewayの接続（トリガー追加）
Lambdaがインターネット経由でRollbarからリクエストを受け取れるよう、窓口を作ります。
1. Lambdaの画面上部にある「トリガーを追加」をクリック。
2. ソースに API Gateway を選択。
3. 「新しいAPIの作成」を選択し、「HTTP API」（軽量・高速で安価なため推奨）を選びます。
4. セキュリティは、テスト時は 「オープン」 にします（※本番運用ではWebhook署名検証を行うため、まずは疎通優先で進めます）。
5. 「追加」をクリックすると、画面に「APIエンドポイント（URL）」が表示されます。これをコピーしておきます。
—
4. Step 3: RollbarのWebhook設定
さあ、いよいよRollbarとLambdaを結びつけます。
1. Rollbarの管理画面で、対象のプロジェクトを開きます。
2. 左メニューの [Settings] ＞ [Integrations] ＞ [Notifications] を選択します。
3. サービス一覧から [Webhook] をクリックします。
4. 設定画面が開くので、以下のように入力します。
- URL: 先ほどAPI Gatewayで発行された「APIエンドポイント（URL）」をそのまま貼り付けます。
5. 【超重要】無駄な通知を減らす「フィルタリング」の設定
ここがプロの設計思想の肝です。すべてのエラーでチケットを起こしていると、開発者は「アラート疲れ」を起こし、重要なエラーを見逃すようになります。
RollbarのWebhook設定の下部にある [Rules] セクションで、通知の条件を絞り込みましょう。
- デフォルトでは `Every Occurrence`（すべての発生）や `New Item`（新しいエラーの初回検知）が設定されています。
- これを編集し、以下のように設定します。
- Trigger: `New Item`（新しいエラーが検知された時だけ起票する。同じエラーが1万回起きてもチケットは1枚だけにするため）
- Filters: `level == ‘critical’`（重大度がCriticalのものだけ）
設定が終わったら、[Save Settings] をクリックして保存します。
—
5. Step 4: 運命の「HelloWorld」動作確認テスト！
役者はすべて揃いました。いよいよ、自動起票の魔法が本当に動くかテストをしましょう。
先ほどのローカルテスト用Pythonスクリプトを、もう一度実行してみます。
python send_error.py
実行した瞬間に、裏側で以下の美しい連鎖リアクションが起きます。
1. スクリプトがゼロ除算の `Critical` エラーをRollbarに送信。
2. Rollbarがエラーを受信。「これはCriticalの新しいエラーだ！」と判断。
3. Rollbarが、設定されたAPI GatewayのURLへ、エラー情報を乗せたJSON（Webhook）を瞬時に送信。
4. API GatewayがLambdaを起動。
5. Lambdaがペイロードからエラー名とRollbarのURLを抜き出し、NotionのAPIを叩く。
では、あなたのNotionのデータベース（またはJira）を開いてみてください。
そこには……
(※画像はイメージです。実際には美しいチケットが1行追加されているはずです！)
「[🚨CRITICAL] division by zero」 というタイトルの新規ページが、自動的に作成されているはずです！
ページを開けば、そこにはRollbarの該当エラーページへ直接飛べる魔法のリンク（`Rollbar Link`）もきれいに格納されています。
「動いた……！」
この瞬間、あなたは手動でのバグ起票という退屈な作業から、永遠に解放されたのです。
—
6. 一歩先へ進むための「プロのアドバイス」
このシステムを本番環境で本格運用するにあたり、現場で役立つ実践的な知見を2つ共有しますね。
① Webhookの「署名検証」でセキュリティを強固に
現在のAPI Gatewayは「オープン（誰でも叩ける状態）」になっています。悪意ある第三者があなたのAPI URLを見つけると、嘘のチケットを大量に起票されてしまうリスクがあります。
RollbarのWebhook設定画面には、「Signing Secret（署名シークレット）」が表示されています。
Rollbarから送られてくるリクエストのヘッダー `X-Rollbar-Signature` には、このシークレットでハッシュ化された署名が入っています。Lambda側でこれを検証するコードを追加することで、「本当にRollbarから届いた安全なリクエストのみを処理する」という鉄壁のセキュリティを実現できます。
② 重複起票を防ぐ「状態管理」
今回は「New Item（初めて起きたエラー）」をトリガーにしました。しかし、一度解決（Resolved）にしたエラーが再発した際にも起票したい場合は、Rollbarのトリガーで `Reactivated Item` も有効にしておくと、運用の漏れが完全になくなりますよ。
—
まとめ：自動化がもたらす最高の開発体験
手動でのチケット起票は、時間だけでなく、開発者の「集中力」と「モチベーション」を奪うノイズです。
今回実装したRollbar × AWS Lambdaの自動起票システムがあれば、エラーの検知から起票までが完全自動化され、チーム全員が「今何が起きているか」をリアルタイムに、かつ整理された形で把握できるようになります。
「これをマスターすれば、毎日の作業が劇的に楽になりますよ」
ぜひ、あなたのプロジェクトでもこの自動化の魔法を導入し、インシデント対応の初動を最速に、そして日々の開発をもっとスマートに進化させてみてくださいね。応援しています！