2026 年 5 月 11 日に Zenn で公開された Ubie 社の Slack 上でインフラのトラブルシューティングができる Agent の設計と実装 は、Slack メンションだけで AI エージェントがインフラ調査・問い合わせ対応を自律実行する実践報告です。
これまで弊社の SRE 運用代行受託案件でも、**「夜間 / 休日のインフラ問い合わせを誰が一次対応するか」が大きな運用負荷でした。ChatOps と AI エージェントを組み合わせることで、「Slack メンション → AI が一次対応 → 必要時のみ人間にエスカレーション」**という現実的な業務分担が見えてきています。これは Salesforce Slackbot と Workspace Intelligence の比較 で扱った ワークプレイス AI と相補的に、SRE / 運用領域に特化した活用です。
なぜ「Slack ChatOps × AI Agent」が SRE 受託で刺さるか
| 課題 | ChatOps × AI Agent の効果 |
|---|---|
| 夜間 / 休日の一次対応 | AI が常時稼働で初動を担う |
| 属人化したインフラ知識 | エージェントに集約 |
| 問い合わせの分散 | Slack に集約 + 自動分類 |
| オンコール疲弊 | 不要呼び出しを 50〜70% 削減 |
| 記録の散逸 | スレッドが自動的に対応ログに |
特に 「夜間 / 休日のオンコール疲弊」は、人材定着率と直結する重大な経営課題です。AI エージェントによる 一次対応の自動化は、SRE チームの離職防止に直結します。
Ubie 事例の 3 つの構造的工夫
工夫 1: 自律実行を「ネットワーク層」で安全制御
エージェントが 任意のコマンド / API を呼ぶ前に、ネットワーク層で許可ドメイン / 許可コマンドを制限する設計です。これにより 「エージェントの暴走」を 下層で物理的に止めることが可能になります。これは AWS セキュリティエージェント受託 で議論した 「エージェントの境界設計」の運用版です。
工夫 2: Slack スレッドを「対応ログの一次情報」にする
エージェントの調査ログ・推論プロセス・実行コマンドを Slack スレッド内に時系列で残す設計で、ポストモーテム / 監査 / ナレッジ化を 追加工数なしで実現します。
工夫 3: 「人間への引き継ぎ」を自然な UX で
「自信なし」と判断したら、エージェントが 自動で人間にメンションします。スレッドコンテキストがそのまま引き継がれるため、人間側は 「最初から状況を把握した状態」で対応できます。
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| Slack 統合 | Slack Bolt + Block Kit | Socket Mode |
| エージェント基盤 | Claude Agent SDK / Mastra | LangGraph |
| LLM | Claude Sonnet / GPT-5.5 | Gemini 2.5 |
| ツール統合 | MCP サーバー | OpenAI Function Calling |
| ネットワーク制御 | Cilium / NetworkPolicy | VPC Security Group |
| 可観測性 | OpenTelemetry + Langfuse | Datadog |
| 監査ログ | Slack Audit API + S3 Object Lock | CloudTrail |
特に MCP サーバーによる 「ツール統合の標準化」は、MCP 完全ガイド で扱ったとおり、ベンダーロックインを避けつつ統合範囲を拡大する標準パターンになりつつあります。
受託で構築する 4 つの実装フェーズ
フェーズ 1: 現状調査（3 週間）
過去 3 ヶ月の Slack 問い合わせを分類し、「AI 一次対応で完結できる比率」を実測します。ROI 試算の根拠を顧客と握ります。
フェーズ 2: ツール群実装（6〜8 週間）
Kubernetes / AWS / GCP / Datadog / PagerDuty など、よく使う調査ツールを MCP サーバー化します。最初は読み取り専用で範囲を絞ります。
フェーズ 3: エージェント実装 + 安全制御（4〜6 週間）
エージェント本体を実装し、ネットワーク層 + IAM 層で 二重の安全制御を入れます。ステージング環境で 2〜3 週間の シャドー運用を行い、本番投入を判断します。
フェーズ 4: 運用引き渡し + 継続改善（月次）
エージェントの 「自信なし」判定から、「次に MCP 化すべきツール」を逆算し、継続的に対応範囲を拡大します。
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| エージェント権限範囲 | 読み取り / 書き込み / 実行の境界 | 既存 IAM との整合 |
| エスカレーション SLA | 自信なし時の通知速度 | 業務影響の許容範囲 |
| 対応ログ保管 | Slack スレッド + 監査ログ | 保管期間と費用 |
| モデル更新追随 | LLM 変更時の再評価頻度 | 評価工数の責任 |
| インシデント時の停止 | 暴走時の即停止フロー | 連絡経路と権限者 |
| データ持ち出し範囲 | LLM に送る情報の機密区分 | コンプライアンス要件 |
価格モデル — SRE 運用代行 + AI Agent 受託パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| PoC | 60 万円〜 | 4 週間 | 1 ツール統合 + 効果測定 |
| Lite | 450 万円〜 | 8 週間 | 3〜5 ツール統合 + 一次対応自動化 |
| Standard | 1,400 万円〜 | 3 ヶ月 | 上記 + 監査基盤 + シャドー運用検証 |
| Care（運用代行） | 月 80 万円〜 | 12 ヶ月〜 | エージェント運用 + 24/365 オンコール |
どの案件で刺さるか / 刺さらないか
| 向く案件 | 向かない案件 |
|---|---|
| Slack を社内コミュニケーション基盤にしている | Microsoft Teams 専業 |
| インフラ問い合わせが日次 5〜30 件 | 月数件で AI 導入のペイバックが出ない |
| オンコール疲弊が経営課題化している | 既に十分な SRE 体制がある |
| MCP / Agent SDK にチームが慣れている | エージェント技術への抵抗が強い |
| 監査ログ要件が明確 | 監査要件未整備で迷走中 |
ハマりやすい 4 つの落とし穴
落とし穴 1: 「最初から書き込み権限」を付与
エージェントが 「とりあえず再起動してみました」で 本番障害を拡大させる事故が発生しています。最初は読み取り専用 → シャドー運用 → 段階的に書き込み権限の 3 ステップを必須にします。これは AI Agent 本番 DB 削除事故 で扱ったガードレールと同じ思想です。
落とし穴 2: エスカレーション基準を曖昧にする
「自信なし」の判定基準を 「LLM の判断に任せる」と、重要な障害を AI が抱え込むケースが頻発します。確信度 + キーワード + 時間帯の 3 軸で機械的に判定するルールが必須です。
落とし穴 3: 監査ログを Slack だけで保存
Slack の保存期間は 顧客プランに依存するため、90 日で消えるケースがあります。S3 / GCS への自動アーカイブを別途実装することが必須です。
落とし穴 4: 運用代行契約を月額固定にしてしまう
問い合わせ件数の変動が大きいため、完全月額固定だと 受託側が損する月 / 顧客側が損する月が交互に発生します。ベースライン + 件数超過分の ハイブリッド課金を推奨します。
まとめ — 「SRE の人手」から「Slack に住む AI 同僚」へ
Slack ChatOps × AI Infra Agent は、SRE の一次対応を 「人間が常時待機」から 「AI が常時稼働 + 例外時のみ人間」へ転換するパターンです。Ubie 事例で示された ネットワーク層の安全制御は、エンタープライズ受託でそのまま適用できる 標準パターンです。
弊社では PoC / Lite / Standard / Care の 4 段階で SRE 運用代行 + AI Agent 受託パッケージを提供しています。「夜間オンコールで SRE が疲弊している」「Slack で完結する一次対応を AI に任せたい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
