こんにちは、K.Platinum代表の沼田です。
24歳でこの会社を立ち上げて、いま3期目。17人のITコンサルチームで、AI/RAG・受託開発・コンサルティングの3軸で日々動いています。
最近、社外の経営者や情シスの方と話していて、年明けから明らかに増えた質問があります。
「ぬまさん、MCPって結局、うちみたいな中堅企業も触ったほうがいいんですか？」
答えは即答で「触ったほうがいい、というか、もう触り始めたほうがいい」です。
ただ、なぜ触るべきか、いつから、どこから手を付けるか、というところが世に出ている記事だと意外と語られていません。
この記事では、僕らが17人組織で社内の業務システムを片っ端から"MCPサーバ化"してみた話を、わりと生々しめに書きます。Salesforce・Workday・Slackクラスのものを横断したいけどゼロから設計する余力はない、という中堅企業の方に届くと嬉しいです。
MCPって"標準化"のニュースだけど、いつ来るの？
念のために整理しておくと、MCP（Model Context Protocol）は2024年11月にAnthropicが公開した、AIエージェントが業務システムと安全につながるための共通プロトコルです。USB-Cの規格と同じで、各業務システム側に「MCPサーバ」を立てておけば、どんなAIモデルからでも同じインターフェースで叩ける。
ここまでは少し前の話。2026年のいま何が起きているかというと、ニュースとしては地味だけど、業界的にはかなり大きな動きが立て続けに来ています。
- 公開されているpublic MCPサーバはすでに1万超
- SDKの月間ダウンロードは9,700万を突破
- Salesforce・ServiceNow・Workdayの3大SaaSがMCPサーバを正式公開、もしくは2026年内に公開予定
- AccentureとDeloitteが「MCP導入」を主要なコンサルメニューに組み込み
- Forrester予測では、2026年内にエンタープライズアプリベンダーの30%がMCPサーバを公開
- Gartner予測では、2026年末までに業務アプリの40%が業務特化AIエージェントを搭載（現在は5%未満）
つまり「実験」から「本番」に切り替わったのがちょうど今。エンタープライズ側に対応する義務が静かに発生していて、SaaSベンダー側が先に動き出している、というのが2026年5月時点のスナップショットです。
中堅企業の現場では、MCPはまだ「他人事」
ところが、僕らがふだん受託で入っている売上数十億円〜数百億円規模の中堅企業に同じ話をすると、温度感が真逆です。
「MCP？ Anthropicの記事で名前は見ました」
「ウチに関係あります？ Slackとサイボウズしか使ってないですよ」
「来年とかでいいですか？」
気持ちはめちゃくちゃ分かります。中堅企業の情シスは慢性人手不足で、Microsoft 365 Copilotの社内展開もまだ道半ば、というところが多い。新しいプロトコルなんて翌期予算に乗せて静かに棚上げしたい、という空気は当然あります。
ただ、僕の感覚では、MCPは「いつ導入するか」の話ではなく「気付かないうちに業務に入ってくる」プロトコルです。具体的にはこういう順番で侵食してきます。
- 業務SaaS（Salesforce、サイボウズ、SmartHR、freee、楽楽精算など）が次のリリースでMCPサーバ機能を標準実装する
- 社員が使っているChatGPTやClaudeデスクトップアプリが、そのMCPサーバを自動検出して接続を提案してくる
- 気付いたら「営業がChatGPTに『今月の見込み出して』と聞くと、Salesforceから直接出してくる」状態になっている
- でも、その通信ログを情シスが追えていない／監査ログが残らない／権限が誰にどこまで開いているのか把握できない、という事故が表面化する
- 慌てて運用ルールを作る、その時にはもう全社使っている
ここまで来てから整備するのは、社内Wi-Fiが当たり前になってから情報セキュリティ規定を作るくらい遅いんですよね。先回りで触っておく価値が、ここにあると思っています。
17人ITコンサルが自社に"MCPサーバ化"を仕掛けてみた話
理屈ばかりだと現場感が伝わらないので、僕らK.Platinumが社内で実際にやった話をします。
17人組織なのでスケールはそんなに大きくありません。でも、扱っている業務システムは中堅企業とほぼ同じラインナップです。
- Slack（社内全コミュニケーション）
- Gmail（顧客とのやりとり）
- Google Drive（資料・契約書・議事録）
- Backlog（プロジェクト・タスク管理）
- レディクル（受託案件マッチング）
- 自社の経理SaaS（freee）
- 自社の人事SaaS（SmartHR）
今年に入ってから、これら全部を1個ずつMCPサーバ化していきました。順番は使用頻度順で、SlackとGoogle Driveから着手しています。
ゴール設定はわりとシンプルで、「社内のAIエージェントが、業務システムを横断して仕事を片付けられる状態」。たとえば「先月の上位5案件の議事録要約と、関連するBacklog課題を一覧化して」みたいな依頼が、人間が画面を10回切り替えずに片付くこと。これが達成できたら、コンサル先にも自信を持って同じ構成を勧められる、という建付けです。
3か月ほど運用してみて、想定通りいったところと、想定外にハマったところが両方ありました。
特にハマったところは、ぶっちゃけ規模が大きい会社ほど深刻になりそうなポイントだったので、後段で詳しく書きます。
ちなみに、こういう「まだ世に手順書が出ていない領域を、自社で先に踏んで中堅企業に持っていく」のが、僕らK.Platinumの仕事の面白いところだと思っています。手を動かしながら一緒に検証していけるエンジニアを募集しているので、ピンと来た方はエンジニア募集の詳細も覗いてみてください。
MCP導入でぶつかった5つの壁と、17人組織の折衷案
正直に言うと、社内で全システムを横断したAIエージェントが動き出した瞬間、現場のメンバーから一気に5系統の質問が飛んできました。
これは中堅企業に展開するときに必ず通る道だと思うので、僕らの折衷案とセットでメモしておきます。
壁① 監査ログ — 「誰がAI経由で何を見たか」が追えない
AIエージェントが業務システムを叩いた回数とパラメータは、各業務SaaS側のログには残っても、AI側のセッション単位で再構成するのは難しい。
「営業の誰々さんがClaudeに何を聞いて、その結果Salesforceからどのレコードが引かれたか」を一気通貫で追うのは、デフォルト機能ではほぼ無理でした。
僕らの折衷案は、MCPゲートウェイを自前で1枚噛ませる。ゲートウェイ層が全リクエストを受けて、AIエージェント側のセッションIDと、業務システム側の認証ユーザIDをログとして自前のDBに残す。3か月分のログがそのまま情シス監査の説明資料になりました。
壁② SSO統合認証 — Google OAuthだけで足りない問題
社内アカウントはGoogle Workspaceで統合済みなのですが、業務SaaSによっては独自のサービスアカウントを求めてくるものがあります。MCPサーバが要求する認証方式と、SaaS側の認証方式が一致しないと、結局「サービスアカウント1個で全員アクセス」みたいな雑運用になりがちです。
折衷案は、入口は全てGoogle SSOで揃え、ゲートウェイから先で各SaaS用のサービスアカウントに変換する。「誰が叩いたか」を入口で確定して、「どう叩くか」を出口で吸収する2層構造です。中堅企業に展開するときは、ここをIdaaS（Okta／HENNGEなど）で揃えると同じ構造が再現できます。
壁③ ゲートウェイ挙動 — タイムアウトと並列処理
これは完全にハマりました。MCPサーバの初期実装は同期通信を前提にしていることが多くて、AIエージェントが「Backlogの100件分タスクを引いてきて」みたいな依頼を投げると、3秒以内のレスポンスを期待しているのに普通に20秒かかる。タイムアウトして、AI側が「失敗した」と判断してまた叩く、というループに入ります。
折衷案は、ゲートウェイで非同期化／キャッシュ／レート制限の3点セットを最初から入れる。これも自前ゲートウェイを噛ませた副産物として後から効いてきました。MCP公式ロードマップでも2026年中に標準対応する見込みですが、それを待っていられない人は1枚自前で挟んでおくのが安全。
壁④ 設定の移植性 — 「うちの業務に合わせた設定」が乗らない
公開されているMCPサーバの多くは「とりあえずGET/POSTが叩ける」レベルで、業務に合わせた絞り込みやフィルタはアプリ層で別途実装が必要でした。
特に経理系SaaSの「取引先名でフィルタ」みたいなクエリは、SaaS側のAPI仕様を熟知していないとMCP越しでは使い物になりません。
折衷案は、業務文脈ごとに"MCPサーバ＋カスタムツール"のセットで作る。Slackの「議事録チャンネルだけ」を切り出した専用ツールとか、Backlogの「自分が担当の進行中課題だけ」を切り出した専用ツールを、業務メニューに合わせて10個くらい用意しました。
壁⑤ 権限粒度 — 「読み取りOK・書き込みNG」の制御
これは中堅企業展開時にいちばん刺さるポイントです。AIエージェントに「議事録を読んでサマリだけ作って」と頼むのは安全ですが、「Salesforceに新規商談を作って」は実行前に人間の承認を挟みたい。
折衷案は、MCPツールを「読み取り系／書き込み系」で物理的に分ける。書き込み系のツールは別ファイルに分離して、AIエージェント側のシステムプロンプトに「書き込み系を呼ぶ前は必ず確認を取る」というルールを焼き込んでおきます。コンサル先に提案するときも、この分割を強く勧めています。
これからITコンサルが中堅企業に推す「MCPサーバ化フェーズ0→3」
5つの壁を整理した上で、僕らが中堅企業に提案している伴走モデルがこれです。
フェーズ0：業務システム地図づくり（2〜3週間）
「うちの業務システムって、結局いくつ動いてるんだっけ？」という地図を作るところから始めます。情シスが管理しているSaaSだけでなく、現場が勝手に契約しているシャドーITも含めて棚卸し。MCPサーバを立てる優先順位を、使用頻度×データ機密性×AIエージェントとの相性の3軸で評価して並べます。
フェーズ1：1サーバから始める（4〜6週間）
優先順位1位のシステムを1個だけMCPサーバ化。多くの会社はここでSlackかGoogle Driveを選びます。ゲートウェイ・認証・監査ログの3点セットも同時に立てて、運用フローを最小単位で確立します。
フェーズ2：横断 — 3〜5サーバを連動させる（2〜3か月）
「議事録を読んで関連タスクをBacklogから引く」みたいな横断ユースケースを1つに絞って、必要なサーバを順番に追加。1個目で作ったゲートウェイがそのまま使えるので、追加コストは指数的には伸びません。
フェーズ3：エージェント化 — 業務メニューに乗せる（半年〜）
ここから先は、社員が日常的に使うエージェントを業務メニューとして配布します。「営業支援エージェント」「経理サポートエージェント」「採用候補ハンドリングエージェント」のように業務単位で切るのが、中堅企業規模では運用しやすいと感じています。
おわりに — MCPは「2027年の話」じゃない
ここまで読んで、「うちもそろそろ触らなきゃ」と思ってもらえたら嬉しいです。
僕らK.Platinumは17人と小さい組織ですが、だからこそ自社で全部試してから中堅企業に持っていける、という強みがあります。MCPは今年に入ってから明らかにフェーズが変わったプロトコルで、来年気付いたときには「もう全社員が使っている」状態になっている可能性が高い。
そうなる前に、フェーズ0の地図づくりだけでも始めておくと、社内の温度感が全然違ってきます。
「ちょっとうちの業務システム地図、書き起こすところから手伝ってほしい」みたいなご相談、最近めちゃくちゃ増えているので、気軽に投げてもらえると嬉しいです。
それでは、また次の記事で。
沼田海斗（ぬまた・かいと）
株式会社K.Platinum代表。24歳で同社を創業し、現在3期目。AI/RAG・受託開発・コンサルティングの3軸で、中堅企業のシステム活用とAI導入を支援している。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。