Claudeとincident.ioを連携して障害の振り返りを下書きする方法
incident.ioの公式コネクタでインシデントの経過・調査結果・フォローアップをClaudeに読ませ、振り返りとタイムラインの下書きを作る手順です。接続方法、使うツール、書き込みが起きる操作、プランの条件をまとめます。
Claudeとincident.ioを連携して障害の振り返りを下書きする方法
incident.ioのコネクタをClaudeに繋ぐと、インシデントの状況、ステータス更新の履歴、調査結果、ポストモーテムをClaudeが直接読めます。振り返り文書のタイムライン部分を、チャットやダッシュボードを往復して拾い集めずに下書きできます。
この記事では、接続手順、振り返りに使うツール、読み取りだけで済む範囲と書き込みが起きる操作、プランの条件を順に説明します。
incident.ioコネクタとは — 障害対応の全データを会話で引く公式コネクタ
incident.ioコネクタは、incident.io自身が提供するClaude向けの連携です。Claudeのコネクタ一覧では「Anthropic verified」の表示が付き、カテゴリは「Developer tools」、追加時期は2026年4月です。サインインは必須で、接続先のURLは https://mcp.incident.io/mcp です。
ディレクトリの説明は、インシデントの宣言とトリアージ、ページへの応答、オンコールの確認、フォローアップの管理を挙げています。加えてインシデントの傾向やアラートのノイズの分析、接続済みの監視ツールへの問い合わせ、構造化した運用レビューも含まれます。
振り返りの下書きに効くのは、このうち「過去のインシデントを読む側」です。同じ領域にはPagerDuty連携のように検知とエスカレーションが主題の記事がありますが、incident.ioは経過の記録そのものを持つため、事後の文書づくりに向きます。
前提 — 必要なプランとツールの条件
incident.io側の条件が2つあります。
- リモートMCPサーバーはTeam・Pro・Enterpriseプランで使えます。Basic(無料)プランでは使えません
- 一部のツールは、対応する機能を契約していないと呼べません。ツールの一覧には残りますが、呼ぶと不足している機能を知らせるエラーが返ります
振り返りの文脈では、依存先が3つに分かれます。
| 機能 | 必要な契約 |
|---|---|
| インシデント本体・ステータス更新の読み取り | 必要な契約条件なし |
| フォローアップ・所要時間や対応工数の集計 | 必要な契約Response |
| 調査結果の取得・社内文書の検索 | 必要な契約Investigations |
Claude側のプラン条件は、ディレクトリのページに記載がありません。Team・Enterpriseの組織では、管理者の設定で使えるコネクタが制限されていることがあります。
接続手順 — ディレクトリから追加する
Claude.aiやデスクトップ版では、コネクタ一覧から追加するのが最短です。
Claudeからincident.ioを接続する流れ
- 1
コネクタ一覧でincident.ioを探す
CustomizeのConnectorsで「incident.io」を検索して選びます。
- 2
incident.ioのアカウントで承認する
ブラウザでサインインし、要求された権限を確認して許可します。
- 3
会話でオンにする
チャットの「+」メニューからConnectorsを開き、incident.ioをオンにします。
OAuthで接続すると、操作はあなたのincident.ioユーザーの名前で行われ、見えるデータもあなたの権限の範囲です。
ディレクトリに無い環境や手で追加したいときは、カスタムコネクタとして上のURLを入力します。incident.ioの管理画面のSettings → MCPからも、リモートMCPサーバーを有効にできます。
Claude Codeから使う場合
Claude Codeには1行で追加できます。初回の利用時にブラウザで認可を求められます。
claude mcp add incident-io --transport http \
https://mcp.incident.io/mcpコードの変更履歴と障害の経過を突き合わせたいときは、こちらが向きます。調査結果とコミットを同じ会話で並べられるからです。
自動化にはAPIキーを使う
定期実行のエージェントのようにユーザーが介在しない用途では、OAuthの代わりにAPIキーを使います。Settings → API keysで必要なスコープを選んで作成し、Bearerトークンとして渡します。APIキーはユーザーではなくサービスとして認証され、削除するまで失効しません。振り返りの下書きを毎週自動で作る構成では、このキーの権限を最小に絞ることが前提になります。
振り返りに使うツール — stats、list、showの順に絞る
incident.ioのドキュメントは、分析の定石として「stats → list → show」の順を挙げています。件数や傾向を先に取り、気になる群を一覧で絞り、最後に個別の詳細を開く順番です。インシデントを1件ずつ辿るより効率がよいとされています。
振り返りに使う主なツールは次のとおりです。
| 目的 | ツール | 返るもの |
|---|---|---|
| 全体像をつかむ | ツールincident_stats | 返るもの重大度・ステータス・チームなどの軸での件数と工数 |
| 対象を絞る | ツールincident_list | 返るものフィルタ付きの一覧。工数順の並べ替えも可能 |
| 1件を読む | ツールincident_show | 返るもの詳細。調査結果とポストモーテムを含められる |
| 経過の時系列 | ツールincident_update_list | 返るものステータス更新の全履歴 |
| 調査の全体 | ツールinvestigation_sync | 返るもの調査の全記録をアーカイブで取得 |
| 後始末の確認 | ツールfollow_up_list | 返るものインシデント後のフォローアップ |
要になるのは incident_show の include です。調査結果とポストモーテムを含めない呼び出しでは、基本のメタデータしか返りません。ドキュメントは調査時に両方を要求するよう勧めています。
incident_show(id: "INC-123", include: ["investigation", "postmortem"])なお、ディレクトリのページでは「35個のツール」と表示され、冒頭の24個が見えます。一方、incident.ioのドキュメントのツール表にはそれより多くの名前が並びます。ツールの数は更新のたびに変わりうるので、ここでは個数でなく役割で選びます。
時系列の下書きにはステータス更新の履歴を使う
振り返りのタイムラインの材料は、インシデントのステータス更新の履歴です。incident_update_list が全履歴を返し、incident_show の include にも更新履歴を含められます。誰が、いつ、何と報告したかが並ぶので、Claudeにはその並びを時刻順の表に整える作業を任せられます。
調査の記録まで必要なら、investigation_sync が調査の全記録を取り出します。調査の結果、確認の履歴、会話、根拠がまとまった形です。ドキュメントは、これを自動化したエージェントや、コード変更と調査結果を突き合わせる用途に向けたツールとして説明しています。
頼み方の例 — 読み取りだけで下書きを作る
以下はドキュメントが挙げる使い方に沿った、プロンプトの一例です。実際の応答は、あなたのワークスペースの設定とデータで決まります。
INC-123 の振り返りを下書きしてください。
1. incident_show で調査結果とポストモーテムを含めて読む
2. incident_update_list の履歴から、検知・初動・原因特定・復旧の
4つの節目を時刻付きの表にする
3. 記録に書かれていない事実は推測せず、「記載なし」と書く
4. 未完了のフォローアップを follow_up_list で拾い、末尾に並べる
出力は Markdown で、書き込みは行わないでください。効果が出る工夫は3つあります。
- 「記録に無いことは書かない」と明示する。時系列の穴を埋めたくなる生成を抑えられます
- 「書き込みは行わない」と添える。読み取りだけで完結する指示にします
- 対象をIDで固定する。「最近の障害」と書くと、どれを指すかが曖昧になります
複数件をまとめる四半期の振り返りなら、先に incident_stats で傾向を出し、工数の大きい件を incident_list で選び、そこだけ incident_show で開く流れが自然です。
構造化された運用レビューも用意されている
定期レビュー向けには、analysis_start があります。運用レビュー、アラートのノイズ、オンコールの負担、チームの健全性、対応の有効性といったプレイブックと、組織の設定、HTMLのレポート雛形を含む作業用のフォルダを取得します。AIはプレイブックの段階に従って、集計、掘り下げ、テーマの抽出、提言の順に進みます。
1件の振り返りではなく、期間をまとめたレビューを作るときに使う入口です。
書き込みが起きる操作 — 読み取りだけでは終わらない
このコネクタは読み取り専用ではありません。振り返りの下書きだけなら不要な書き込みの操作も、同じ接続で呼べます。
| 操作 | ツール | 影響 |
|---|---|---|
| インシデントの作成・更新 | ツールincident_create / incident_update | 影響状態や重大度が変わる |
| フォローアップの作成・更新 | ツールfollow_up_create / follow_up_update | 影響担当者に残る項目が増える |
| インシデントのチャンネルへの投稿 | ツールincident_message | 影響対応者全員に見える |
| ページへの応答 | ツールescalation_respond | 影響確認・辞退が記録される |
| 調査の開始・誘導 | ツールinvestigation_start / investigation_steer | 影響チャンネルと調査の履歴に残る |
調査の開始はインシデントのチャンネルへメッセージを投稿し、あなたをそこに招待します。誘導も調査の履歴に残ります。どちらも対応者から見える操作です。
ステータスページの更新は例外的な設計です。status_page_update は下書きだけを作り、公開は人が行います。公開すると購読者全員にメールやSMSが届くためです。
ポストモーテムの文書そのものを書き換えるツールは、ドキュメントの表に載っていません。下書きはClaudeの会話に出力され、貼り付けて整えるのは人の作業になります。
読み取りだけに絞るには
書き込みを避けたい場合は、次の3つが使えます。
- 指示で書き込みを禁じる(上の例のとおり)
- Claudeのコネクタ設定で、ツールごとに許可を絞る。方法と面ごとの違いはコネクタの読み取り専用運用にまとめています
- APIキー運用なら、スコープを読み取りに限って発行する
指示だけに頼る運用は、指示の読み落としで崩れます。設定側で絞るほうが確実です。
つまずきやすい点
- ツールを呼んだらエラーになる。Response・On-call・Investigationsのどれを契約しているかを確認します。契約していない機能のツールは一覧に出るのに呼べません
- Basicプランで接続できない。リモートMCPサーバー自体がTeam以上のプランの機能です
- ポストモーテムが空に見える。
includeにpostmortemを渡していない可能性があります。基本のメタデータだけが返った状態です - 見えるインシデントが人によって違う。OAuth接続はユーザー本人の権限で動くため、閲覧権限の無い案件は読めません
- 監視ツールのデータが取れない。
ask_telemetryのようなテレメトリ系は、Investigationsに監視ツールを接続していることが前提です
複数の監視ツールを同時に繋いだときの権限設計は、監視ツール連携による障害対応ワークフローの設計が詳しいです。コネクタの一般的な権限の落とし穴はコネクタの権限設定でよくある失敗も参考になります。
向く使い方・向かない使い方
| 場面 | 向き | 理由 |
|---|---|---|
| 1件の振り返りの時系列の下書き | 向き向く | 理由更新履歴と調査結果を一度に読める |
| 四半期の傾向のレビュー | 向き向く | 理由incident_stats とプレイブックがある |
| 当番中の初動対応 | 向き条件次第 | 理由書き込みの操作があり、承認設計が前提 |
| 振り返り文書の自動確定 | 向き向かない | 理由文書を書き換えるツールが無く、最終確認は人が行う |
下書きを作る作業は任せやすく、公開や確定を伴う作業は人が担う分担が、このコネクタの設計とも合っています。
まとめ
incident.ioコネクタは、障害の経過と調査結果を会話で読み、振り返りとタイムラインの下書きに変えるための入口です。incident_show に調査結果とポストモーテムを含めて読ませ、incident_update_list の履歴を時刻順に整えさせると、下書きの骨格は短時間で揃います。
ただし同じ接続で書き込みも呼べます。振り返りだけが目的なら、読み取りに絞る設定をしてから使い始めてください。