はじめに
最近、Slackの公式Claudeアプリを使い始めました。チャンネルで@Claudeとメンションすると、直近の会話の文脈を読んだうえでスレッドに返信してくれる、というものです。
様々な使い方が思い浮かびますが、EasyBlocks 監視シリーズのSlack通知と相性が良いのでは？との思いから本記事を書くことにしました。
EasyBlocks 監視シリーズのSlack通知には、通知の際に特定の相手をメンションする設定があります。本来は担当者や@channelを呼び出すための機能ですが、ここにClaudeを指定すれば、障害通知が届くたびにAIが呼び出されて、その場で通知を読んでくれるのではないか。
試してみたところ、思っていた以上にきちんとした一次診断が返ってきたので、本記事では設定手順と実際の様子を共有します。プログラムは1行も書きません。
今回使うもの
使うのは以下の2つだけです。
EasyBlocks 監視シリーズ：弊社のネットワーク監視アプライアンスです。Ping死活監視やSNMPによるリソース監視をWeb UIから設定でき、通知手段としてメールのほかSlack通知(Incoming Webhooks)を備えています。監視対象や監視パターンに設定したメモ情報が通知に表示でき、この機能が後ほど地味に効いてきます。
Claude in Slack：Slack App Marketplaceから導入できるAnthropic公式アプリです。チャンネルに招待しておくと、メンションされたときにスレッドへ返信してくれます。Claudeの有料プランを契約していれば、追加費用なしで利用できます。
ポイントは、EasyBlocks 監視側の通知メッセージ自体がClaudeをメンションするため、人間が通知を見てからAIに聞き直す必要がない、という点です。
通知が届く→Claudeが呼ばれる→スレッドに一次診断、が自動で流れます。
構成
構成はシンプルです。
[EasyBlocks 監視]
(1) 障害を検知し、Slackへ通知
▼
[Slackチャンネル]
(2) 通知本文の先頭でClaudeをメンション
▼
[Claude in Slack]
(3) 通知内容を読んで、スレッドに一次診断を返信
▼
[運用者]
(4) スレッドを見て対処
環境
- 監視サーバー：EasyBlocks 監視(バージョン1.1.0)
- Slack：会社のワークスペース内に作成した検証用プライベートチャンネル
- Claude：Anthropic公式のSlackアプリ
- 監視対象：検証機1台(ICMP Pingによる死活監視)
なお、Claudeはプライベートチャンネルでも動作するので、検証は自分専用のプライベートチャンネルで行いました。周囲を騒がせずに試せます。
実行手順
STEP①：Claudeアプリをチャンネルに招待する
検証用チャンネルで /invite @Claude を実行します。招待できたら、試しに人間からメンションして応答することを確認しておきます。
Claudeアプリ自体が未導入の場合はSlack App Marketplaceから追加します（組織のSlackでは管理者の承認が必要な場合があります）。
STEP②：Incoming Webhook URLを発行する
EasyBlocks 監視のSlack通知はIncoming Webhooks方式なので、Slack側でURLを発行します。
- api.slack.com/apps を開き、「Create New App」→「From scratch」を選択。アプリ名（例：EasyBlocks監視通知）とワークスペースを指定して作成
- 左メニューの「Incoming Webhooks」を開き、スイッチをOnにする
- 「Add New Webhook to Workspace」をクリックし、投稿先に検証用チャンネルを選んで許可
- 発行されたURL（https://hooks.slack.com/services/… 形式）をコピー
なお、ここで1つエラーに遭遇しました。詳細は後述の「ハマったポイント」にまとめています。
また、このWebhook URLは、知っていれば誰でもそのチャンネルに投稿できてしまうものです。秘密情報として管理してください。
STEP③：ClaudeのメンバーIDを確認する
EasyBlocks 監視のメンション先には、Slackのメンション記法 <@メンバーID> でClaudeを指定します。そのためClaudeアプリのメンバーID(Uから始まるID)が必要になります。
このIDの確認方法も少し詰まったので「ハマったポイント」で触れますが、結論だけ書くと、本人に聞くのが一番早かったです。
STEP④：EasyBlocks 監視のSlack通知を設定する
EasyBlocks 監視のWeb UIでSlack通知を設定します。通知を「有効」にし、STEP②のWebhook URLを登録。メンションを「有効」にして、メンション先に <@U…（ClaudeのメンバーID）> を山括弧ごと入力します。
監視対象と監視パターンは普段どおりです。今回は検証機に対するICMP Pingの死活監視を設定しました。メモ欄も普段どおりの使い方のままで、設置場所や用途を書いてある程度です。AI向けの特別な仕込みは何もしていません。
設定はこれで終わりです。
動作確認：LANケーブルを抜いてみる
では、検証機のLANケーブルを抜いて障害を起こしてみます。
しばらくすると、チャンネルに障害通知が届きました。本文の先頭でClaudeがメンションされているのが分かります。
そして数十秒後。こちらは何も操作していませんが、通知のスレッドにClaudeの返信が付きました。
返ってきた診断の内容を見てみます。
- パケットロス100%という値から「部分的なロスではなく完全ロスなので、輻輳や瞬断ではなくホストまたは経路の完全ダウンの可能性が高い」と切り分けている
- 通知に表示されたメモの設置場所情報を拾って、「検証機ということもあり」と原因候補（電源オフ、ケーブル抜け、作業・再起動中など）の見立てに反映している
- 一次確認の手順を「本体の電源・LED→ケーブル→別ホストからのping→直近の作業有無」という順番で提示している
原因候補の1番目と2番目は実際の原因(ケーブル抜線)を含んでおり、一次診断としては妥当な内容でした。
個人的に良いと思ったのは最後の一文です。「社内NWの外からは私が直接到達確認できないため、これは通知内容ベースの見立てです」と、自分では到達確認できないことを断ったうえで、「回復通知が来たら追記します」と書いてありました。
AIの回答を業務で扱ううえで、こういう限界の明示はむしろ信頼できます。
なお、バージョン1.1.0で通知に表示されるようになったメモ情報が、そのままAIへの文脈供給として機能した形です。メモ欄は本来の用途(設置場所などの補足)のまま使えばよく、AIのために何かを書き足す必要はありませんでした。
復旧させてみる
ケーブルを戻して復旧させると、RECOVERY通知が届きました。このときのClaudeの動きが面白かったので紹介します。
復旧通知の投稿そのものには、✅のリアクションを付けただけ。続報は、元の障害通知のスレッドに書き込んでいました。
続報では、障害発生と復旧の時刻からダウン時間(約7分)を計算し、RTAの値を見て正常復帰と判断。さらに「頻発するようならNICやケーブル、電源設定を確認した方がよい」という再発時の観点も添えられていました。
障害の発生から復旧までが1つのスレッドにまとまるので、後から見返したときに通知の羅列ではなく、障害単位の記録として読めます。
ちなみにこの「復旧したら元のスレッドに追記する」という動きは、こちらが指示したものではなく、Claudeが障害対応時に自分で宣言し、そのとおりに実行したものです。
ハマったポイント
検証中にいくつかつまずいたので、同じ道を歩む方の参考になればと思い、共有しておきます。
ハマりポイント①：「インストールするボットユーザーがありません」エラー
STEP②のWebhook発行で「Add New Webhook to Workspace」をクリックしたところ、次のエラーが出ました。
これは、作成したアプリに「ボットユーザー(表示名)」が未設定の場合に出るエラーです。左メニューの「App Home」を開き、ボットの表示名とユーザー名を設定（この名前が通知の投稿者名になります）してから、改めて「Add New Webhook to Workspace」をやり直せば通ります。
ハマりポイント②：アプリのメンバーIDが見つからない
人間のメンバーIDはプロフィールの「︙」からコピーできますが、Claudeアプリのプロフィールを開いても同じ場所にIDが見当たりませんでした。
そこで発想を変えて、チャンネルでClaudeに「あなたをメンションすると生データでは <@U…> という形式になっているはず。そのIDを教えて」と聞いてみたところ、あっさり自分のIDを答えてくれました。Slackのメンションは内部的にメンバーID形式でアプリに渡っているので、本人が読み取れるわけです。ちょっとしたSlack小ネタですが、覚えておくと便利です。
運用に載せる場合の注意点
手軽に動いてしまうだけに、実運用を考えるなら押さえておきたい点があります。
AIの診断は参考情報です。
Claudeは通知の文面から推測しているだけで、実際に機器へ到達確認をしているわけではありません(本人も申告しているとおりです)。最終判断と対処は人間が行う前提で使うものだと考えています。
通知が連発するケースは要検討。
チェック間隔を短くしていると、障害が続く間は同じ通知が繰り返し届きます。その都度Claudeが診断を返すとノイズになる可能性があるため、チェック間隔・リトライ回数の調整も含めて設計する必要がありそうです。
組織のポリシー確認を。
監視通知にはホスト名やIPアドレスといった内部情報が含まれます。外部サービスであるSlackやAIに監視情報を渡すことになるので、自組織のセキュリティポリシーとの整合は事前に確認してください。
今後の展望
今回はEasyBlocks 監視のメンション機能を使って、通知のたびにClaudeを呼び出す形にしました。
一方でAnthropicからは、@Claudeに常設指示を与えてチャンネルを監視させる「Claude Tag」という仕組みの展開もアナウンスされています。
メンション設定なしでの自動化や、機器ごとの情報(過去の障害歴や復旧手順など)をAI側にどう持たせるかは、また改めて検証してみたいと思います。
まとめ
やったことを振り返ると、Slack側でWebhookを発行し、EasyBlocks 監視のSlack通知のメンション先をClaudeにした。実質これだけです。
プログラムは書いていませんし、EasyBlocks 監視側もメモ欄を含めてごく普通の設定のままです。
それでも、障害通知への一次診断と復旧確認がスレッドに自動で付くようになりました。通知を受けてから状況を読み解く「最初のひと手間」をAIが肩代わりしてくれるだけでも、監視当番の負担は変わってくるのではないでしょうか。
今後もEasyBlocksシリーズとAIの融合ネタがあれば記事にしていきたいと思います。