こんにちは！チームの拡大とともに「誰の担当かわからないエラー通知」がSlackに流れ続け、誰もメンションに反応しなくなっていく……そんなカオスな状況に頭を抱えていませんか？
「また俺のエラーかよ」「いや、これ隣のチームの領域じゃん」——。
そんな不毛な押し付け合いを終わらせ、「エラーが起きた瞬間、コードを書いた本人のSlackに直接・正確に通知を飛ばす」ための究極の仕組みが、Sentryの Ownership Rules（CODEOWNERS連携） です。
今回は、初心者の方でも今日から迷わず導入できるように、ツールの役割から実際のセットアップ、そして実務で即座に使える高度なルーティング設定まで、優しく丁寧に解説していきます。これをマスターすれば、あなたのチームの障害対応スピードは劇的に変わり、毎日のアラートチェックが驚くほど楽になりますよ！
—
1. なぜ「Ownership Rules」が必要なのか？（ツールの役割）
Sentryは単なるエラーログ収集ツールではありません。モダンな開発において、Sentryは「アプリケーションの健康状態を、責任を持つべき開発者にダイレクトに繋ぐルーター」であるべきです。
開発チーム拡大の罠
小さなチームの間は、「全員が全コードを把握している」状態なので、Sentryの共通チャンネルにエラーが流れても「あ、これ俺直すわ」と阿吽の呼吸で解決できました。
しかし、チームが5人から20人、50人と拡大し、モノリスからマイクロサービス、あるいは巨大なモノレポ（Monorepo）へ移行するとどうなるでしょう？
- 共通チャンネルに1日数百件のエラーが流れる。
- 「決済モジュール」のエラーなのか、「認証機能」のエラーなのか、タイトルを見ないと分からない。
- 結局、誰もメンションされないエラーは放置され、ユーザーからの問い合わせで発覚する。
CODEOWNERSとの融合による解決
ここで登場するのが、GitHubなどのバージョン管理システムが持つ `CODEOWNERS` ファイルとSentryの連携機能です。
「このディレクトリのコードを書いた人はこの人（またはチーム）」というコードの所有権定義を、そのままSentryのエラー通知のルーティングルールとして流用するのです。これにより、人間が手動でアサインルールを設定・メンテする手間から完全に解放されます。
—
2. GitHubのCODEOWNERSとSentryを連携させる手順
それでは、実際に手を動かして連携の設定をしていきましょう。
ステップは大きく分けて3つです。
Step 1: SentryとGitHubの連携（Integrations）
まず、SentryのプロジェクトとGitHubリポジトリを連携させます。
1. Sentryのダッシュボード右上の「Settings」 > 「Integrations」を開く。
2. 「GitHub」を見つけて「Install」または「Configure」をクリック。
3. 対象の組織（Organization）やリポジトリへのアクセスを許可します。
Step 2: リポジトリ側に `CODEOWNERS` ファイルを配置する
GitHubの仕様に基づき、リポジトリの `.github/` ディレクトリ（またはルート）に `CODEOWNERS` ファイルを作成します。これがそのままSentryのルーティングの基礎データになります。
.github/CODEOWNERS
担当者やチームのGitHubハンドルを指定します
リポジトリ全体はコアインフラチームが担当
- @neko-infra-team
認証・ユーザー管理周りはセキュリティチーム
/src/features/auth/ @security-lead @auth-devs
決済・課金周りはフィナンシャルチーム
/src/features/billing/ @finance-backend-team
Step 3: Sentry側でOwnership Rulesを有効化する
Sentryがリポジトリの `CODEOWNERS` を読み込めるように設定します。
1. Sentryのプロジェクト設定から 「Issues」 > 「Ownership」 を開きます。
2. 「Rules」タブにおいて、ルールソースとして 「Code Owners」 を選択します。
3. 連携したGitHubのリポジトリと、参照するブランチ（例: `main`）を指定します。
たったこれだけで、Sentryはコードの変更と所有者の紐付けを自動的に理解し始めます！
—
3. モジュールごとに担当エンジニアへ直接Slack通知を飛ばす高度な設定法
「CODEOWNERS連携はできたけれど、Slackの通知が相変わらず全体チャンネルに飛んでしまう……」
ここからが本番です。SlackインテグレーションとOwnership Rulesを組み合わせ、「担当者のDM、またはチーム専用チャンネルへダイレクトに飛ばす」高度な設定を行っていきましょう。
SlackとSentryのユーザーマッピング
まず大前提として、Sentryのユーザーアカウントと、Slackのアカウントが正しく紐付いている必要があります。
- Sentryの「Settings」 > 「Members」から、各メンバーが自身のSlackアカウントと連携していることを確認してもらいましょう。これをしておかないと、せっかくアサインされてもSlackでメンション（`@username`）が飛びません。
Ownership Rulesの高度な記述法
Sentryの「Ownership」画面では、GitHubのCODEOWNERSをインポートするだけでなく、Sentry独自のルール（Ownership Rules）を直接記述することも可能です。これにより、よりきめ細やかなルーティングが可能になります。
実際に現場で最も重宝する、実用的な設定例を見てみましょう。
— 1. 深刻なインフラ・DBエラーは専用アラートチャンネルへ —
パスやエラーメッセージに含まれるキーワードでルーティングを上書き
url:/api/v1/checkout/ error:TimeoutException -> #alert-critical @infra-team
— 2. フロントエンド（React）のクラッシュはUIチームへ —
ファイルパスを指して直接アサイン
path:src/components/ui/ -> @taro-frontend #channel-frontend-alerts
— 3. バックエンドのドメインロジックエラーはコードオーナー（CODEOWNERS自動連携）に委譲 —
CODEOWNERSファイルに定義された所有者をそのまま適用するキーワード
（これが最もメンテナンスコストが低い黄金律です）
codeowners:@github
— 4. 上記のいずれにもヒットしないフォールバック（デフォルト） —
迷子になったエラーは、開発部全体のトリアージ用チャンネルへ
- -> #dev-triage-room
この設定ファイルをSentryのダッシュボード上のエディタに貼り付けて保存するだけで、エラーの宛先ルーティングが見事に機能し始めます。
—
先輩エンジニアからの実務アドバイス：運用を軌道に乗せるコツ
この仕組みを導入した直後によくある「落とし穴」と、その対策をシェアしておきますね。
1. 最初は必ず「緩めのフォールバック」から始める
いきなり厳密にルーティングしようとすると、設定ミスで「どこにも通知されないエラー」が生まれてしまいます。最初は最後の行に ` -> #all-errors` のようなキャッチオール（受け皿）を残し、徐々にルールを洗練させていきましょう。
2. CODEOWNERSは組織変更に合わせて更新する
チーム替えやメンバーの異動があった際、GitHubの `CODEOWNERS` が古いまま放置されると、前任者に夜中アラートが飛び続けるという悲劇が起きます。「チームのメンバー変更＝CODEOWNERSのPRを出す」をチームのルールとして定着させましょう。
まとめ
いかがでしたか？
SentryのOwnership RulesとCODEOWNERS連携をマスターすれば、「誰がこのエラーを見るべきか」というチーム内の無駄なコミュニケーションコストがゼロになり、開発者は「自分が書いたコードの品質」に集中できるようになります。
これを設定したその日から、あなたのSlackの通知は「ノイズの海」から「信頼できるシグナル」へと生まれ変わります。ぜひ、次のスプリントの合間に試してみてくださいね。あなたの運用ライフが快適になることを、心から応援しています！