サーバ認証情報を Slack に渡さず、Slackbot にアラートとエージェント引き継ぎを追加する

公開 2026-08-22

サービス停止にチームが最初に気づく場所は、多くの場合 Slack です。FrontierStack は障害を Slack へ投稿し、スレッドに必要な情報を残し、調査をエージェントワークフローへ引き継げます。ただし、Slack チャンネルをリモート root コンソールにはしません。

この境界が重要です。ボットはインシデント情報を担当者へ渡し、確認のため FrontierStack を開けます。サーバ認証情報、操作スコープ、最終承認は信頼済み端末上の FrontierStack に残ります。

Slack 対応は二つに分かれる

FrontierStack はアラート配信とエージェント承認を分離します。

1. Slack Messaging Gateway。一つ以上の Slack 受信 Webhook へ障害と復旧のメッセージを投稿します。Slack アプリを開発しなくても利用できます。
2. Slackbot ワークフロー引き継ぎ。MCP ペインから、担当者への通知、インシデント情報の引き継ぎ、FrontierStack を開く操作に使える、認証情報を含まない Slack／Teams レシピを書き出します。このレシピは新しい承認経路を作りません。

Messaging Gateway だけでも利用できます。引き継ぎレシピは、Slack アプリ、ワークフローボット、エージェントコーディネータをすでに運用し、その背後のサーバ管理者として FrontierStack を使いたいチーム向けです。

1. サーバアラートを Slack へ送る

Slack で受信 Webhook を作り、運用アラートを受け取るチャンネルを選びます。FrontierStack の Messaging Gateways を開き、Slack を有効にして Webhook URL を貼り付けます。複数のワークスペースやチャンネルへ同じアラートを送る場合は、1 行に一つずつ URL を入力できます。

FrontierStack は Webhook を Mac の Keychain に秘密情報として保存します。運用を始める前に Send Test を使ってください。Webhook が拒否された場合や失効している場合は、配信チェックが失敗を表示します。

Slack チャンネルには、FrontierStack が他の Messaging Gateway に送るものと同じヘルスイベントが届きます。サーバやサービスの障害と復旧、証明書期限、容量警告、選択したセキュリティイベントなどです。誰かが対応する必要のある通知だけを有効にし、チャンネルを読みやすく保ちます。

2. Slackbot 引き継ぎを追加する

MCP Server ペインを開き、Ecosystem Setup Kit を書き出します。Slack／Teams 引き継ぎレシピを選びます。レシピには役割、選択した MCP、A2A、CloudEvents、CLI の経路、ボットワークフローで置き換える安全なプレースホルダが記述されています。

キットには Slack トークン、FrontierStack ベアラートークン、SSH 鍵、パスワード、サーバ認証情報を含みません。任意の接続先は、対応する FrontierStack サービスが動作している場合だけ含まれます。リモートコーディネータには、対応するペアリング済み TLS 経路と、その呼び出し元に割り当てたスコープが必要です。

これはホスト済み Slackbot ではなく、設定レシピです。FrontierStack がワークスペースへ無断でアプリをインストールしたり、チャンネル履歴を読んだり、DM を購読したりすることはありません。会話は既存の Slack アプリやエージェントコーディネータが担当し、サーバ操作は FrontierStack が担当します。

リアクションは承認ではない

Slack メッセージ、絵文字リアクション、ワークフローボタンは、担当者への通知と FrontierStack を開く操作に使えます。再起動の承認、スクリプトの実行、エージェント権限の拡大には使えません。FrontierStack は呼び出し元スコープを確認し、必要な承認を信頼済み UI に表示します。

この規則は Slack アカウント、ボットトークン、ワークフローが侵害された場合にも役立ちます。攻撃者はもっともらしい文章を送れるかもしれません。それでも、FrontierStack が保持する SSH 鍵、sudo パスワード、クラウドトークン、ローカル承認権限は取得できません。

AI 管理者から設定済み Gateway へ投稿する

AI 管理者は設定済みのメッセージチャンネルを確認し、FrontierStack の send_notification ツールを通じて Slack へ通知を送れます。変更操作を有効にする必要があります。ツールは Slack をチャンネル ID で指定するため、モデルが Webhook URL を受け取る必要はありません。

モデルは観測したヘルス情報とログから簡潔なインシデント更新を作成できます。配信は、管理者が事前に設定した Gateway を使って FrontierStack が実行します。

実用的なインシデントの流れ

1. FrontierStack がピン留めしたサーバまたは監視対象サービスの障害を検出する。
2. Messaging Gateway が障害と根拠を運用チャンネルへ投稿する。
3. Slackbot が担当者を割り当て、会話をまとめ、要求を FrontierStack へ引き継ぐ。
4. 担当者が FrontierStack で現在の状態と提案された操作を確認する。
5. FrontierStack がローカル認証情報で許可済みの操作を行い、結果を記録する。
6. 新しいヘルスチェックで復旧を確認した後、Slack へ復旧メッセージを送る。

Slack スレッドはチームで共有するインシデント記録として残ります。認証情報の保管場所でも、サーバヘルスの判定元でもありません。

FrontierStack が行わないこと

• Slackbot をシェルとして扱わない。
• リアクション、メッセージ本文、承認済みと称するフィールドから変更を承認しない。
• サーバ認証情報を Slack、プロンプト、設定キットへコピーしない。
• 受信 Webhook 接続を使ってワークスペースのメッセージを読まない。
• オンコール予定、インシデント指揮、事後レビューが必要な場合に Slack ネイティブのインシデント製品を置き換えたとは主張しない。

incident.io や Rootly などは、Slack でインシデントの会話を続けながら、接続済み SaaS サービスとして FrontierStack から監視できます。サーバ操作には同じセキュリティ境界を適用します。

重要でないアラート一つから始める

専用の運用チャンネルを接続してテスト送信を行い、無害なヘルス警告を発生させます。Mac を開かなくても障害と復旧のメッセージを理解できることを確認してください。その後に Slack 引き継ぎレシピを書き出し、ボットワークフローへ追加する前に、すべての接続先と呼び出し元スコープを確認します。

Slack は適切な担当者を同じ会話へ集めることに向いています。FrontierStack は、ボットが要求できる操作を決め、実行時に認証情報を解決し、承認を求め、修復結果を確認します。この役割分担により、Slackbot を危険なサーバ管理者にせず、運用へ活用できます。

Slack サービスページ、アラート Gateway ガイド、エージェント基盤ガイド、エージェントワークフローのマニュアル章も参照してください。