Grafana OnCallをClaudeで操作しオンコール対応を自動化する

障害の一次対応で「今、誰が当番か」「このアラートグループは誰かが確認済みか」を調べるためだけにGrafanaの画面を開く手間は、Claude Codeに任せられます。mcp-grafanaのOnCallツール群は、スケジュール・シフト・当番ユーザー・アラートグループの参照から、アラートグループの確認応答・解決までを扱います。

Grafana OnCall MCPツールでできること

mcp-grafanaはOnCallカテゴリとして8つのツールを持ちます。スケジュール一覧の取得と管理、特定シフトの詳細取得、指定スケジュールの現在の当番ユーザー取得、OnCallのチーム・ユーザー一覧、条件を指定したアラートグループの検索、特定アラートグループの詳細取得、そしてアラートグループの確認・確認解除・解決・未解決化です。ダッシュボード操作やLoki・Prometheusのクエリ実行とは独立したツール群で、障害対応の「今の状態」に特化しています。

Claude Codeでの有効化

インストール手順とRBACスコープ設計の全体はmcp-grafanaの導入とRBAC設計にまとめてあります。OnCallツールは既定で有効なカテゴリに含まれるため、--disable-oncallを付けない限り追加設定なしで使えます。OnCall対応の役割に絞ったサービスアカウントを別に用意するなら、--enabled-toolsでカテゴリを絞り込みます。

claude mcp add-json grafana-oncall \
  '{"command":"uvx","args":["mcp-grafana","--enabled-tools","oncall,alerting,incident"],"env":{"GRAFANA_URL":"https://myinstance.grafana.net","GRAFANA_SERVICE_ACCOUNT_TOKEN":"<サービスアカウントトークン>"}}'

今シフトに入っているのは誰か

指定したスケジュールの現在の当番ユーザーはget_current_oncall_usersで取得します。「オンコールスケジュール〇〇の今の当番は誰?」と聞けば、Claudeがこのツールを呼んで答えます。スケジュール自体の一覧・管理はlist_oncall_schedules、特定シフトの開始・終了時刻や担当者といった詳細はget_oncall_shiftが担当します。

チーム・ユーザーの一覧が要るときはlist_oncall_teamsとlist_oncall_usersを使います。エスカレーション先のチーム構成を確認してからアラートグループに対応する、という順序で聞くと自然に流れます。当番交代直後の引き継ぎ確認にも、このやり取りをそのまま使えます。

複数チームのスケジュールを横断して確認する

チーム単位でオンコールスケジュールを分けている組織では、まずlist_oncall_teamsでチーム一覧を取得し、対象チームのスケジュールをlist_oncall_schedulesで絞り込んでからget_current_oncall_usersで当番を引く、という2段階の流れになります。「インフラチームとアプリチーム、それぞれの今の当番を教えて」のように複数チームをまとめて聞いても、Claudeが必要な回数だけツールを呼んで答えをまとめます。

エスカレーション先を横断的に把握したいときは、list_oncall_usersでユーザー一覧を取得したうえで、担当スケジュールと突き合わせる聞き方が有効です。一次対応者が応答しない場合に誰へエスカレーションすべきかを、Grafana OnCallの画面を開かずに、チャットの延長で確認できます。

アラートグループを検索して対応する

発生中の障害を洗い出すにはlist_alert_groupsを使います。状態(firing / acknowledged / resolvedなど)、インテグレーション、ラベル、時間範囲でフィルタできるため、「過去1時間で未確認のアラートグループ」のような絞り込みをそのまま自然言語で投げられます。個別のアラートグループの詳細はget_alert_groupで取得します。

対応そのもの、つまり確認(acknowledge)・確認解除(unacknowledge)・解決(resolve)・未解決化(unresolve)はupdate_alert_groupが担当します。読み取り専用のツールが多いOnCallカテゴリの中で、書き込みが発生するのはこの1つだけです。

list_alert_groupsのフィルタ条件は状態・インテグレーション・ラベル・時間範囲の4種類が組み合わせられます。

「過去1時間でfiring状態のアラートグループを、環境ラベルがprodのものだけ」のように複数条件を重ねて絞り込めます。障害対応の初動で「今どれだけの規模で発生しているか」を把握する用途に向きます。

アラートグループから障害を起票する — Incidentツールとの組み合わせ

update_alert_groupで確認応答したあと、そのまま障害として起票して関係者を巻き込みたいことがあります。mcp-grafanaはGrafana Incidentのツールも別カテゴリとして持っていて、OnCallと組み合わせると「アラートグループを確認 → Incidentを作成 → 対応履歴を記録」という一連の流れを1つの会話で進められます。

Incidentのツールはlist_incidents(検索、カスタムフィールドの値も含めて取得可能)、get_incident(1件取得)、list_incident_custom_fields(設定済みカスタムフィールドの一覧)、create_incident(作成)、add_activity_to_incident(活動履歴の追加)、update_incident(ステータス・重大度・タイトル・カスタムフィールドの更新)の6つです。

OnCallのツールがプラグイン固有のパーミッションで制御されるのに対し、Incident・SiftのツールはGrafana本体の基本ロールで制御されます。参照系(list_incidents、get_incident、list_incident_custom_fields)にはViewerロール、作成・更新系(create_incident、add_activity_to_incident、update_incident)にはEditorロールが要ります。同じサービスアカウントでOnCallとIncidentの両方を扱うなら、OnCallプラグインのパーミッションとGrafana本体のロールを両方設定する必要がある、という点は見落としやすいところです。

用途別に有効化するツールの組み合わせ

OnCall対応で任せる範囲によって、有効化すべきカテゴリとRBAC権限の組み合わせは変わります。

OnCallツールに必要なRBACパーミッション

OnCallのツールはGrafana本体のRBACではなく、OnCallプラグイン固有のパーミッションで制御されます。

参照系のスケジュール確認だけをClaudeに任せるなら、schedules:readとuser-settings:readだけを持つサービスアカウントで足ります。アラートグループへの確認応答までさせたいときだけalert-groups:writeを追加してください。書き込み権限を持つサービスアカウントを作らない選択もでき、その場合はGrafana側の画面で最終的な確認応答を行うことになります。

読み取り専用で運用する

障害の状況把握だけをClaudeに任せ、実際の確認応答は人間が行いたい場合は、MCPサーバー起動時に--disable-writeを付けます。update_alert_groupだけが無効になり、スケジュール・シフト・当番・アラートグループの参照系ツールはそのまま使えます。

uvx mcp-grafana --enabled-tools "oncall" --disable-write

よくあるつまずき

パーミッション不足で一覧が空に見える: サービスアカウントにgrafana-oncall-app.user-settings:readが無いと、list_oncall_teamsやlist_oncall_usersは空の結果や権限エラーを返します。OnCallプラグイン固有のパーミッションはGrafana本体のRBACスコープ(teams:*など)とは別物なので、両方を混同して設定漏れが起きやすい箇所です。

確認応答したつもりが未解決のまま: update_alert_groupはacknowledge・unacknowledge・resolve・unresolveの4操作を1つのツールが担います。「対応した」という自然言語の指示だけでは、確認(acknowledge)止まりで解決(resolve)まで進んでいないケースがあります。対応後はget_alert_groupで状態を確認する一手間を挟むと、こうした事故を減らせます。

書き込みを止めたつもりがカテゴリごと無効化していた: --disable-oncallはOnCallツール自体を丸ごと無効にします。参照はさせたいが確認応答だけ止めたいときは、--disable-oncallではなく--disable-writeを使う必要があります。両者を混同すると、当番確認まで一緒に止まってしまいます。

チームIDとユーザーIDを混同する: list_oncall_teamsとlist_oncall_usersが返すIDは別の名前空間です。エスカレーション先を指定する際にチームIDをユーザーIDの欄に渡すと、意図した相手に届きません。複数チームを横断する運用ほど、どちらのIDを参照しているかをClaudeとのやり取りの中で毎回確認する癖をつけておくと安全です。

OnCallツールがプラグイン固有の権限で分離されている理由

OnCallのパーミッションだけがGrafana本体のRBACスコープ(dashboards:*のような形式)と切り離され、grafana-oncall-app.schedules:readのようなプラグイン専用の名前空間に分かれているのは設計として理にかなっています。ダッシュボードや通知ポリシーへの広いアクセス権を持つサービスアカウントを使い回していても、OnCall側の権限を別途付与しない限り、当番情報やアラートグループへは触れません。当番表という個人の勤務に関わる情報を、監視ダッシュボードの権限管理から独立させて絞り込める構造です。

裏を返すと、OnCallツールを使わせるつもりでEditorロールだけ割り当てても、プラグイン権限が別途無ければ動きません。この分離を知らずに「権限は足りているはず」と思い込むと、原因調査に時間を取られます。サービスアカウントを新規発行する段階で、Grafana本体のロールとOnCallプラグインのパーミッションを1つのチェックリストにしておくと、この種の見落としを防げます。導入時に一度整理しておけば、後からメンバーが増えても同じ手順を再利用できます。

まとめ

Grafana OnCallのMCPツールは、当番確認とアラートグループの状況把握を自然言語のやり取りに置き換えます。書き込み操作はupdate_alert_group1つに集約されているため、参照専用のサービスアカウントと、確認応答まで任せるサービスアカウントを分けるかどうかだけを決めれば運用に組み込めます。ダッシュボード操作やアラートルールの設定まで含めた全体のRBAC設計はmcp-grafanaの導入とRBAC設計を、ログ調査を組み合わせるならmcp-grafanaでLokiのログをLogQLなしで検索するを合わせて確認してください。