開発の「責任の所在」を瞬時に特定せよ：Sentry × GitHubで実現する「自動アサイン」の極意
エラーが起きる。Slackに通知が飛ぶ。チームの誰かが「これ誰の担当だ？」と呟く。この数分間の「名もなきコミュニケーション」が、開発チームのベロシティをどれだけ削いでいるか考えたことはあるだろうか？
オブザーバビリティとは、単に「何が起きているか」を知ることではない。「誰が解決すべきか」をコンテキストを含めて瞬時に提示することだ。今回は、Sentryの `Commit Author Email` 機能を魔改造し、エラー発生時に「該当コードの執筆者」を特定して、Slackで直接メンションを飛ばす自動アサイン・ワークフローを構築する。
—
1. なぜ「Commit Author」なのか？
Sentryのデフォルト設定では「誰かが見るまで放置される」か「特定のチャネルに流れて埋もれる」かの二択になりがちだ。しかし、エラーのスタックトレースからGitのBlame情報を引き出し、コードを書いた本人に直接通知が届けば、コンテキストスイッチのコストは最小化される。
これは単なる自動化ではない。「自分の書いたコードには責任を持つ」というカルチャーを、Sentryの通知エンジンで強制的に実装するという試みだ。
—
2. 実装の神髄：GitHub連携とWebhookのハブ機能
このワークフローを組むには、以下の3ステップが必要だ。
STEP A: Sentryの「Suspect Commits」を有効化する
SentryがGitHubと統合されていることが前提だ。プロジェクト設定の「Suspect Commits」を必ずONにすること。これにより、スタックトレースに含まれるコードの最終コミット者が自動的に抽出される。
STEP B: Slackの「Block Kit」を活かした通知設計
Sentryの標準通知だけで満足してはいけない。我々が欲しいのは「誰が直すべきか」の明示だ。
Sentryの「Alert Rules」で、条件を満たした際に「Webhook」を叩くように設定する。このWebhook先として、Cloud FunctionsやAWS Lambdaを中継し、GitHubの `email` からSlackの `Member ID` へ変換するマッピングを走らせるのがベストだ。
// 中継サーバーで受信するペイロード例 (Sentry -> Webhook)
{
“issue”: {
“title”: “Uncaught TypeError: Cannot read property ‘map’ of undefined”,
“culprit”: “src/components/UserList.tsx”,
“authors”: [
{
“email”: “dev-a@example.com”,
“name”: “Taro Yamada”
}
]
}
}
STEP C: Slack自動メンション実装のベストプラクティス
サーバーサイドで以下のロジックを実装する。
1. Email -> Slack ID マッピング: `email_map.json` で管理する。
2. メンション生成: `<@U12345678>` の形式に変換。
3. 通知送信: Slack API `chat.postMessage` で送信。
—
3. 生産性を極限まで高める「神設定」とハック
隠れたキーボードショートカット
SentryのUIをマウスで触っているうちは二流だ。
- `Shift + ?`: ショートカット一覧。
- `J / K`: イシューの前後移動。
- `Space`: イシューの選択。
- `A`: アサイン（これを使う回数を減らすのが今回の目的だが、基本中の基本）。
絶対に入れるべき設定：`CODEOWNERS` の徹底活用
GitHubの `CODEOWNERS` ファイルとSentryの「Issue Owners」を同期させよ。
Sentryのプロジェクト設定で `Issue Owners` を設定すると、特定のファイルパスに対する自動アサインルールを定義できる。
/.github/CODEOWNERS の構成例:
フロントエンドの責務を特定する
/src/components/ui/ @frontend-team
/src/api/ @backend-team
重要な認証系はテックリードへ
/src/auth/ @tech-lead
—
4. プロの現場で使う「Sentry運用」の鉄則
1. 「ノイズ」をコードで排除せよ:
`sentry.config.js` で `ignoreErrors` を設定するのではなく、フロントエンドであれば `beforeSend` を使い、環境変数に応じて動的にフィルタリングせよ。
Sentry.init({
beforeSend(event) {
// 既知のサードパーティ広告スクリプトのノイズを全カット
if (event.exception?.values?.[0]?.value?.includes(‘AdBlock’)) return null;
return event;
},
});
2. 「Issue Owners」の共有化ルール:
設定をSentryの管理画面でポチポチするのは禁止だ。Sentryの管理は「Infrastructure as Code」の対象とする。`sentry-cli` を使い、プロジェクト設定をコードベースで管理し、CI/CDパイプラインに組み込むことが、長期的な運用負荷を減らす唯一の道だ。
—
最後に：エンジニアへの提言
この自動アサインを導入すると、最初はチーム内に「通知がうるさい」という反発が起きるかもしれない。しかし、それは「今まで見えていなかった負債が可視化された」という証拠だ。
エラー通知は「誰かを責めるための道具」ではない。「プロダクトの健全性を最速で取り戻すためのシグナル」であるべきだ。自分の書いたコードがエラーを出していると即座に気づける環境こそが、最高のエンジニアリングチームを創り上げる。
さあ、今すぐGitHubとSentryを繋ぎ、その通知に命を吹き込め。君たちのコードが、より強固なものになることを期待している。