こんにちは、LINEヤフー株式会社の迫川です。社内システムのデータ基盤開発を担当しながら、Orchestration Development Workshopのギルドメンバーとしても活動しています。Orchestration Development Workshopは、AI活用の実践知識を組織横断で共有するコミュニティで、私はワークショップのテーマ企画や実践事例の提供を通じて、現場でのAI活用を後押しする役割を担っています。
本記事では、Orchestration Development Workshopで開催したワークショップ『Slack MCPで作る「次世代システム運用」: 生成AIを活用したインシデント対応支援とナレッジ自動生成の実践』の内容を紹介します。
社内の現状と課題
Slackに眠る情報と、構造化のギャップ
日々の業務の中で、Slackにはインシデント対応、問い合わせへの回答、プロジェクトの議論など、重要な一次情報がリアルタイムで蓄積されています。理想を言えば、これらをFAQや事故報告書、進捗レポートとして構造化し、ConfluenceやJiraに集約したいところです。
しかし現実 には、本来の業務に追われてドキュメント化が後回しになったり、対応者によって情報の質や粒度がバラバラになったりと、「まとめたいけど手が回らない」状態が続いていました。重要な議論がSlackの奥に埋もれてしまい、後から探せなくなるケースも少なくありません。
新技術導入の障壁と早期ワークショップの意義
2026年3月、社内で独自に提供されているMCPサーバーの一つとして、内製のSlack MCPが利用可能になりました。Slack公式が提供しているものではなく、社内の認証基盤と連携しているため、個人トークンの発行や複雑なOAuth設定なしに、AIエージェントから社内Slackの情報へ安全にアクセスできるのが特徴です。
しかし、新しい技術が登場しても、実際に試してみるまでのハードルは意外と高いものです:
- 時間の確保が難しい: 日々の業務に追われ、新しいツールを試す時間を作れない
- 導入の心理的障壁: 設定が複雑そう、使いこなせるか不安、といった懸念
- 情報の浸透に時間がかかる: 社内に新技術の情報が広がるまでに時間がかかる
ワークショップの狙い
このような課題を踏まえ、私たちはSlack MCPが利用可能になったタイミングを捉え、いち早くワークショップを開催しました。新しい技術は登場直後が最も関心が高く、「触ってみたいけど手が出ない」という声が多い時期でもあります。そこで、参加者自身が手を動かして「これは自分の業務でも使えそうだ」と感じられる場を作ることを最優先にしました。
具体的には、社内の認証基盤と連携済みのMCPサーバーを使うことで、セットアップの手間を最小限に抑えつつ、JiraやConfluenceなど既存のMCPとの組み合わせ方を含めた実践的な活用方法を提供しました。技術的に深い知見を届けることよりも、参加者が「今日から業務で使える」状態をゴールに据えた構成です。
ワークショップ内容

準備: Slack MCPの導入体験
まず参加者に、Slack MCPを使った最初の一歩を体験してもらいました:
- コーディングツール(Claude Codeなど)の起動
- 「指定のチャンネルに『Hello』と投稿してください」というシンプルな指示
- 実際にメッセージが投稿される様子を確認
この簡単な体験により、Slack MCPの基本的な使い方を体感してもらうことができました。
座学: Slack MCPでできること・他MCPとの組み合わせ

ハンズオンに入る前に、Slack MCPの全体像を共有しました。主な機能は「メッセージ・スレッドの取得」「投稿・リアクション」「チャンネル・ユーザー情報の取得」「検索」の4カテゴリーに分かれます。これらを組み合わせることで、インシデントレポートの自動生成や問い合わせ対応のFAQ化といったユースケースが実現できま す。
さらに、Slack MCPは他のMCPと組み合わせることで活用の幅が広がります。たとえば Slack + Confluence でプロジェクトの進捗報告資料を自動生成したり、Slack + Jira で議論からタスクチケットを自動作成したりといった連携が可能です。この後のハンズオンでも、Confluence MCPとの連携を実際に体験します。
ハンズオン1: 問い合わせ対応のナレッジ化

最初のハンズオンでは、日々繰り返される問い合わせ対応を題材にしました。同じような質問が何度も来るのにFAQが追いつかない、回答の質が担当者によってバラバラ――そんな現場の課題に対して、Slackの問い合わせチャンネルに蓄積されたやり取りをMCPで取得し、FAQ形式のマークダウンに変換したうえで、Confluence MCPを使って既存のナレッジベースに追加するまでの流れを体験します。
実施内容:
ステップ1: Slackからの情報収集
- 問い合わせSlackチャンネルから情報を抽出
- 抽出した情報からFAQ形式のマークダウンファイルを生成する
- 既存の問い合わせ管理ページ(Confluence)との重複チェックも同時に実施
スキル例
name: slack-to-faq
description: Slackスレッドから問い合わせFAQを自動生成してマークダウンファイルに保存
## 動作
1. SlackチャンネルURLとConfluenceページURLをユーザーに質問
2. 指定されたチャンネルから「問い合わせ」を含む最新N件のスレ ッドを検索
3. 指定されたConfluenceページの既存FAQと照合して重複チェック
4. 未FAQ化のスレッドのみFAQファイルを作成
## フォーマット
....
ステップ2: Confluenceへの転記
- 生成されたマークダウンファイルをConfluenceページの形式に変換
- Confluence MCPを使用し、問い合わせ管理ページの子ページとして作成
- 表形式で見やすく整理(症状・解決策・原因のカラム構成)
実際のアウトプット例
| 症状 | 解決策 | 原因 |
|---|---|---|
| ログインできない | パスワードリセット手順の案内 | 権限設定の不備 |
| レポート作成が進まない | データ更新処理の再実行 | バッチ処理の失敗 |
学びとポイント:
- 問い合わせスレッドから自動的にFAQを生成できる
- フォーマットを指定することで、チームの要件に合わせた形で出力可能
- ConfluenceのMCPと組み合わせることで、重複チェックから投稿までを一貫して実行できる
ハンズオン2: インシデント対応支援

2つ目のハンズオンでは、インシデント対応を題材に取り上げました。障害発生時は状況把握に時間がかかり、対応後のレポート作成にも手間がかかる――しかも情報は複数のスレッドに散在しています。このハンズオンでは、Slack上のやり取りを素早く要約する「クイック把握」と、対応完了後にフォーマットに沿ったレポートを自動生成する「レポート作成」の2つのケースを体験します。対応中の混乱した状況でこそ、MCPによる自動収集・構造化が力を発揮することを実感してもらう狙いです。
ケース1: インシデント状況のクイック把握
実施内容:
- 「システム障害についてまとめて」という自然言語での指示
- MCP側でスレッドを検索して情報を読み取り状況サマリーを生成
アウトプット例:
## 状況サマリー
- ✅ 解決済み
- ⚠️ 顧客影響: あり
## 影響内容
- 本日のレポートが作成中から進まない状態
## メンバーアクション
- [担当者A] データベース接続確認中
- [担当者B] ログ解析完了、原因特定
## タイムライン
- 10:15 障害検知
- 10:30 原因特定
- 11:00 対応完了
効果:
- マネージャーが途中参加しても、すぐに状況を把握できる
- メンバーへの確認前に、全体像を掴める
- 意思決定のスピードが向上
ケース2: インシデントレポートの自動生成
実施内容:
- 指定したフォーマットに合わせて出力
- 発生日時、原因詳細、影響範囲などを自動的に構造化
アウトプット例(サンプル):
## 原因調査・分析
### 発生日時
2026-03-31 10:15
### 検知日時
2026-03-31 10:15
### 発生期間
約45分間
### 原因の詳細
データ更新バッチ処理において、DBコネクションプールの枯渇が発生。
原因は前日のメンテナンスで設定変更が一部反映されていなかったため。
### 影響範囲
- 対象ユーザー: 約500名
- 影響機能: レポート作成機能
- データ損失: なし
### 対応内容
1. コネクションプール設定の修正
2. バッチ処理の再実行
3. データ整合性の確認
学びとポイント:
- フォーマットを指定することで、必要な形式に合わせた出力が可能
- 自然言語での指示で、必要な情報を自動的に収集・整理できる
- インシデント対応中と対応後で、それぞれの目的に合わせた機能を使い分けることで効率的に作業できる
ワークショップで扱ったコツと注意点
Slack MCPを業務で活用するうえで、ワークショップでは実践的なコツと注意点をいくつか共有しました。
まず強調したのが情報の事前整理です。Slackから取得した情報をそのまま使うのではなく、Confluence MCPで既存FAQと照合して重複を排除したり、リアクション(例えば特定の絵文字が付いたメッセージだけを対象にするなど)で分析対象を絞り込むことで、出力の精度が大きく向上します。
次に重要なのがレビュー可能な状態の確保です。AIが生成した文章をそのまま公開するのではなく、個人情報が含まれていないか確認すること、どのスレッドから取得した情報かという出典を明示すること、そして元の発言を拡大解釈していないかチェックすることが不可欠です。ワークショップ中にも、生成されたFAQの内容が元のスレッドの意図と微妙にずれているケースがあり、人間によるレビューの重要性を参加者と共有しました。
また、出力フォーマットの指定も効果的です。「表形式で症状・解決策・原因の3列にまとめて」のように具体的に指定することで、チームの既存ドキュメントと統一感のある出力が得られます。
最後に紹介したのがスキル化による効率化です。「スキル」とは、AIへの指示を再利用可能な形で保存したもので、本ワークショップでは slack-to-faq(FAQ自動生成)、faq-to-confluence(Confluenceへの投稿)、slack-incident-status(状況サマリー)、slack-incident-report(レポート生成)の4つを活用しました。一度うまくいったプロンプトをスキルとして定義しておけば、複雑な指示を毎回書く必要がなくなり、チーム内で一貫した品質の出力を得られます。まずは手動でプロンプトを試行錯誤し、うまくいったパターンをスキルとして保存、チーム内で共有してフィードバックをもらいながら継続的に改善していく、という流れが参考になるはずです。
ワークショップで得た学び
スピード感の重要性
新しい技術は、登場直後が最も関心が高く、学びのモチベーションも高い時期です。今回、Slack MCPが利用可能になったタイミングでワークショップを開催したことで、「まさに気になっていた」という参加者の関心をそのまま学びにつなげることができました。実際、ワークショップ後に私の周囲からも「試してみた」「こういう使い方もできそう」といった反応があり、鮮度の高い情報提供と早期のフィードバック収集が実現できたと感じています。
体験重視のコンテンツ設計
限られた時間の中で効果的な学びを提供するために、今回は「とにかく手を動かしてもらう」ことを重視しました。冒頭の「Hello投稿」で「AIがSlackに投稿できるんだ」という驚きを体感してもらい、そこからFAQ生成、インシデント対応と段階的に難易度を上げていく構成にしています。題材も、問い合わせ対応やインシデント対応など、参加者が日常的に時間を取られている場面を選びました。「できること」を体感してもらうこのアプローチにより、参加者が「自分の業務でも使えそう」という具体的なイメージを持てたことが大きな成果でした。
スキル化による再現性の確保
ワークショップの準備段階で最も時間をかけたのが、スキルの設計です。様々なプロンプトを試し、うまくいったパターンを記録し、再利用可能なスキルとして定義する、というプロセスを繰り返しました。この作り込みがあったからこそ、参加者は同じ手順を再現できる形でワークショップを体験でき、終了後も自分の業務に持ち帰って使い続けられる状態を作ることができました。
おわりに
本記事では、Orchestration Development Workshopで実施した『Slack MCPで作る「次世代システム運用」: 生成AIを活用したインシデント対応支援とナレッジ自動生成の実践』の内容を紹介しました。
ワークショップ後、参加者から「自チームの問い合わせチャンネルで早速試してみた」「インシデント対応のレポート作成時間が大幅に短縮できた」といった声が届いています。新しいツールは「何ができるか」を知るだけでなく、実際に手を動かして「自分の業務でどう使えるか」を体感することで、はじめて現場に定着します。今後もOrchestration Development Workshopでは、技術と実践知をセットで届けるワークショップを継続していく予定です。


