💬

社内MCPを整備しても浸透しなかった。Slackに載せた途端に使われ始めた話

に公開
Slack
チーム開発
Model Context Protocol
Claude
AIエージェント
tech

この記事のまとめ（3行）

  • 観察: 数ヶ月かけて複数の社内向け MCP（Model Context Protocol）サーバーを整備したが、チームには浸透しなかった
  • 転換: 同じ MCP 群を Slack ボットの背後 に置き、利用者はメンションするだけの形に倒したら、使われ始めた
  • 対象読者: AI / MCP 推進を任されているが「便利だから使って」が効かない構造に悩んでいるエンジニア

対象読者

  • 社内向けに MCP サーバーや AI ツールを作っているが、作った割に使われていない
  • Claude Desktop / Claude Code の個人セットアップを全員に要求することに限界を感じている
  • PoC（概念実証）は成功するのにチーム展開で止まるパターンを見ている
  • Slack を日々の業務インターフェースにしている組織の AI 推進担当

ここまでの経緯 — MCP を次々に作ったが、使われなかった

2026年1〜2月の MCP 開発ラッシュ

過去数ヶ月、社内業務を支えるための MCP サーバーを連続して整備してきた。

各 MCP は単独の PoC としては十分に動いた。
自分が使うと効果を実感できた。
パイロット参加した数人からの反応も悪くなかった。

しかし広がらない

なのに、チーム全体には広がらなかった。
「便利そうですね」で止まる。
「試してみます」と言った人が一週間経っても試していない。

このパターンは、以前別記事で整理した。
ツール自体の問題ではなく、業務・知識・役割の構造的な問題が壁として効いている、という分析だった。

3つの壁

  • 摩擦の壁: 「面倒くさい」「どうせ手間がかかる」
  • 属人化の壁: 「◯◯さんに聞いた方が早い」
  • 役割混乱の壁: 「品質が落ちた」「AIには頼れない」

https://zenn.dev/dazoyee/articles/0fed3564bb3b22

本記事は、このうち 摩擦の壁 に対して、器の設計でどう応えたかの記録である。

なぜ浸透しなかったのか — 摩擦の壁の正体

「便利な MCP を用意した。あとは使ってもらうだけ」という前提が、そもそも間違っていた。

利用者が新しい MCP を使い始めるまでに必要な手順を並べてみる。

  1. Claude Desktop または Claude Code をインストールする
  2. 接続先 MCP の設定を mcp-servers.json にコピペする
  3. 社内ネットワーク経由の接続・認証を通す
  4. 使うモデルの API キーを払い出してもらう
  5. 初回起動でツールが呼べることを確認する
  6. どの MCP ツールが何用か、README と突き合わせて把握する
  7. やっと最初の質問ができる

個人の PC 状態・権限・ツール習熟度のどこかで確実にひっかかる。
ひっかかると「今日はやらなくていいか」になり、それきり戻らない。

これはスキルやモチベーションの問題ではなく構造の問題だ。
業務を止めてまで踏む価値のある手順には見えない。
MCP 側をどれだけ磨いても、この前段の7ステップを各人に背負わせる設計である限り、浸透しない。

以前の記事で書いた「摩擦の壁」とは、突き詰めればこの個人セットアップのコストのことだった。

転換点: Slack ボットに載せたら使われ始めた

やったこと

積み上げてきた MCP 群の前に、薄い仲介層として Slack ボットを Spring Boot で実装した。
利用者から見える景色を変える。

主要スタックは次のとおり。

レイヤ 技術
言語 Java 21（LTS）
フレームワーク Spring Boot 3.5
Slack 連携 Slack Bolt for Java（Socket Mode）
推論呼び出し Claude CLI（ProcessBuilder で subprocess 起動、JSON Streams をパース）
MCP 接続 .claude/mcp-servers.json による HTTP MCP 定義
ビルド Maven + Maven Wrapper
  • セットアップは運営チームが一度だけ行う。利用者の PC には何もインストールしない
  • 利用者がやるのは Slack でメンションするだけ
  • 新しいツール・ログイン・画面は何も増えない
@bot この仕様について教えて

裏で Slack ボットが Claude CLI を呼び、Claude CLI が既存の各 MCP を呼ぶ。
利用者はこの内部を一切知らなくていい。

起きた変化

器を変えただけで、使われ方が明らかに変わった。

  • 散発的に思い出して使う状態から、日常的な相談相手として扱われるようになった
  • 質問の幅が広がった（仕様確認から、障害調査・データ抽出・チケット解析まで）
  • 他人の質問と回答がスレッドに残るので、同じ質問が繰り返されにくくなった
  • 新規加入者がオンボーディング初日から自然に使い始める

技術的には「既存の MCP に Slack という器を被せただけ」に近い。
しかし利用者から見ると7ステップが1ステップになった。
それが全部の差だった。

なぜ Slack という器が効いたか

3つ効いた。

  1. セットアップを運営側に引き受ける: 利用者は鍵・設定・依存関係を一切管理しない
  2. 使われる文脈の中にエージェントがいる: 全員が既に毎日 Slack を開いている
  3. アラートが来る場所と調査する場所が同じ: 文脈を切り替える動作すら発生しない

特に3つ目が効いた。
監視アラートが流れてくる同じチャンネル・同じスレッドで、調査エージェントが初動レポートを返す。
人間が「別ツールを開いて調べる」という動作がそもそも発生しない。

Before / After を1枚で

ここまでの転換を、観点別に対比する。

観点 Before（MCP 個別利用） After（Slack ボット経由）
使い始める手順 7 ステップ（各人） 1 ステップ（メンション）
セットアップ負担 利用者個人が背負う 運営が一度だけ
使う場所 新ツールを開く Slack（常時開いている）
アラート対応 別ツールで調査 同じスレッドで調査
利用ログ 個人のローカル スレッドに全員が見える形で蓄積
新メンバーのオンボード 環境構築から 初日から質問できる
知識の流通 個人 → 個人（属人化） Slack 経由で自然に共有

技術仕様は一切変えていない。利用者から見た界面を変えただけだ。

アーキテクチャ（ざっくり）

器そのものは薄い。新しく書いたのは Slack ⇄ Claude CLI の仲介層だけで、その奥は積み上げてきた既存資産である。

Claude CLI を ProcessBuilder でサブプロセス起動し、JSON Streams 出力を1行ずつパースして Slack に流すだけだ。
MCP ツール呼び出しやセッション継続は Claude CLI 側が面倒をみるため、ステート管理（スレッドの文脈維持）を自前で頑張って実装する必要はなかった。

この薄さが、チーム導入まで素早く持っていけた理由でもある。
MCP 資産はそのまま、器だけ新しくした。

スキル駆動 — 手順を Markdown として外出しする

Slack 越しに呼ばれるエージェントには、調査手順が Markdown で書かれていることを要求する。

app-<domain>/.claude/
├── CLAUDE.md           # エージェントの振る舞い（最優先ルール）
├── mcp-servers.json    # MCP 接続定義
├── rules/              # 出力フォーマット・ツール選択・委譲ルール
└── skills/<name>/SKILL.md  # 個別タスクの手順書

SKILL.md に「このアラートが来たらこの順でこれを見る」と書いてあれば、エージェントはそれを再現する。
書いていなければ再現しない。

ポイントは、コード変更ではなく Markdown 書き込みだけで振る舞いが更新できることだ。
運用担当が自分の業務手順をそのまま書けばよい。
結果として、属人化していた「頭の中の手順」が、Slack の誰からでも呼べるエージェントの挙動に移っていく。

これは元記事の 属人化の壁 にも効いていく副作用だ。
主眼は摩擦の壁だったが、知識が個人からボット（＝ Markdown）に移ることで、
「◯◯さんに聞いた方が早い」が「ボットに聞けば同じ答えが返る」に変わる。

Slack AI Bot で実際にできること

器が変わって以降、チームが日常的にボットに任せている業務を、代表ユースケースと情報資源の組み合わせで整理する。

代表ユースケース

ユースケース 起動トリガー 主な情報資源 人が楽になる点
アラート一次調査 監視ツール → Slack ログ・コード・設計書・過去事例 初動整理が即座に返り、対応判断にすぐ進める
定期巡回（無人監視） 時刻起動（自動） ログ・監視 夜間・休日のチェックに人手が要らない
質問応答（仕様・実装） @bot メンション コード・仕様・構成 「人を捕まえて聞く」が不要になる
チケット起点の調査 チケット番号 チケット・コード・仕様 担当者の初動整理がチケット共有だけで済む
領域横断の調査 @bot メンション 他エージェント + 自領域 ドメイン分担を意識せずに質問できる

タスク × 情報資源マトリクス

どのタスクで、どの情報資源が主に参照されるかを示す。
自組織で同じ仕組みを組むときに、どの MCP を先に用意すればよいかの設計指標として使える。

タスク ＼ 情報資源 ソースコード 設計書・テーブル定義 ログ・監視 DB 構成管理 チケット 他エージェント
アラート一次調査 ○ ○ ○ △ △ △ △
定期巡回（無人監視） △ － ○ △ － － －
質問応答（仕様・実装） ○ ○ △ △ ○ △ △
チケット起点の調査 ○ ○ ○ ○ △ ○ △
領域横断の調査 ○ ○ ○ △ ○ △ ○

凡例: ○ 主に使用 ／ △ 必要に応じて使用 ／ － 使用しない

周辺の活用例

代表ユースケース以外にも、下のような使われ方が日常的に発生している。

  • 新規参画者の即時 FAQ: ドメイン用語・モジュール構成・設定値の質問にその場で答える。オンボーディング期間が短縮される
  • DWH からの実データ確認: 自然言語 → SQL → テーブル定義を踏まえた結果提示。データ実態の確認が「分析者に依頼」から「その場で確認」に変わる
  • 構成情報からの影響範囲特定: 特定ライブラリや脆弱性に該当するシステムを横断で洗い出す。セキュリティ対応の初動が軽くなる
  • 障害対応時の一括確認: 仕様・コード・過去事例・ログを同時に参照して、原因特定までの一次仮説を提示する

重要なのは、これらの能力の大部分は Slack ボット化する前からも MCP 単体としては存在していたということだ。
使われる場所が変わっただけで、同じ能力が日常の業務に溶け込んだ。

Slack という器がもたらした副産物

想定していなかった良い副作用もあった。

  • 利用ログが自然に溜まる: 誰がどんな質問をしたかがスレッドに残る。次に整備すべきスキルの優先順位が、推測ではなく観測で決まる
  • 使い方が伝染する: 他メンバーの質問・回答が可視化されるので「こんな聞き方もできるんだ」が自然に伝わる
  • オンボーディングが変わる: 新規加入者は「まず @bot に聞いてみる」を最初に覚える。先輩を捕まえる前にボットに聞くのが初期動作になる

器が変わっただけで、知識が流通する経路そのものが変わった。
これが最初の予想を超えた収穫だった。

まとめ — AI をチームに届けるために、ここまでやる

現実: 「便利だから使って」は伝わらない

AI はまだ十分に使われていない。
ツールを揃え、研修を開き、PoC を見せても、ほとんどの人の業務は変わらない。
「試してみます」と言った人が一週間経っても試していない。
このパターンは何度も見てきた。

これは個人の資質や意欲の問題ではない。
届け方の設計が足りていないというだけのことだ。（と、思うしかない。。）
どれだけ賢いモデルや MCP を用意しても、使われる形にまで降りていなければ届かない。

チームや会社の単位で見ると、放置できない

他人の働き方に口を出すのは、個人としては本来する話ではない。

けれどチームや会社の単位で見ると話が変わる。
AI を使う人と使わない人の差が、仕事の速度・射程・処理量を静かに変えていく。
調査の深さ、対応できる範囲、同じ時間に扱える件数が、少しずつ乖離していく。

この乖離は足元では見えにくい。
見えた頃にはもう追いつけない距離になっている。
だから、組織の仕事をふつうに回したいなら、他人任せにはできない。

だから、ここまでやる

チームに AI を届けるために、ここまでやる必要があった。

  • MCP サーバーを何本も整備する
  • 個人セットアップの手順を極限まで削る
  • Slack という既存の業務動線に、器ごと寄せる
  • 運用側がセットアップを肩代わりする
  • そこでようやく「使う」が日常になる

逆に言えば、ここまでやらないと AI はチームに届かない。

これが本記事の、もう一つの結論だ。

AI 推進の仕事は、賢いツールを作ることよりも使われる形まで届け切ること の比重が、自分が思っていたよりずっと大きい。

少なくとも自分のチームには、AI を届け切る

AI が仕事のやり方をどれだけ変えるか、体感していない人が世の中にはまだ多い。
一度触れば戻れないのに、触る手前で止まっている人がほとんどだ。

個人として AI を使わない選択をしている人を、咎める気はない。
ただ自分のチームには、AI の実力を一度は体験してほしい。
そしてそのために一番速いのは、感想を述べたり啓発したりすることではなく、触る手前の摩擦を全部消してしまうことだった。
Slack ボット化は、その手段の一つにすぎない。

同じ問題意識を持つ人には、MCP を作り込むより先に どう届けるかを設計することを勧めたい。
作ったものの価値は、届いて使われて初めて現実になる。

Discussion