ダッシュボードが赤くなった夜に：MSPの仕事と、アカウントは誰のものか

午前2時の赤い画面と、「誰の責任？」という問い

サービスをクラウドに移したあと、ある夜、状態の画面が赤くなります。グループチャットでは、誰が再起動し、誰が事業者に話し、誰が利用者に伝えるのかが飛び交います。その混乱は、コンソールより先に、契約の段階で生まれていることが多いです。

設計・移行・運用を担う人が足りないとき、夜間の対応を自前で置けないときに、マネージドサービスプロバイダー（MSP）を探し始めます。MSPは「請求書に書いてあるクラウドのブランド」そのものではありません。この記事では業者の順位も、市場シェアも書きません。

仕事の中身と、それでも自社に残るもの

作業範囲に入っていれば、現状の整理と構成、サーバーとデータの移行、ネットワークやデータベース、セキュリティの構築、日常の監視とパッチ、権限と脆弱性の手入れ、使っていない資源の整理などが典型です。基盤の利用料をまとめて請求するところもあります。自動ではなく、書面に書いたものだけが範囲です。

小さな案内サイトなら、通常のレンタルサーバーや1台の仮想サーバーで足りることがあります。MSPが意味を持ち始めるのは、稼働、認証、バックアップ、変動する請求をまとめて見る必要が出てからです。開発は自社、基盤の運用と監視はMSP、と分ける組織も多い。そのとき知見は二か所に分かれるので、手順書や図を自社の担当とどう共有するかを聞いてください。

行政や規制の強いデータを扱うなら、実際に適用される制度の経験があるかを尋ねてよい。日本ならISMAP、米国ならFedRAMP、韓国ならCSAP、あるいは自国の規制当局が名前を挙げている枠です。適性の確認であり、順位表ではありません。

人気投票なしで比べ、SLAを読む

比べるとよいのは地味な項目です。いま使っているクラウドへの習熟、近い規模や業種の経験、支援体制の形、必要ならコンテナやKubernetes、セキュリティの運用、障害時の道筋。技術者の資格は手がかりにはなりますが、実際に話せる紹介先の代わりにはなりません。

SLAは、重大度、応答と復旧の目標、知らせ方、約束の外（承認した変更、事業者全体の障害、MSPが触らないシステム）を名前で書く文書です。スライドの「24時間365日」と、署名した別紙の目標は別物です。クラウドアカウントの所有者・最上位権限は自社に残し、MSPには必要な役割だけを渡してください。権限の返し方、引き継ぎの期間、請求と割引の仕組みは、始める前に書いておきます。

提案資料より小さく始め、請求を読める人を一人残す

実務的な進み方は、いまの構成と痛みと目標を書き、複数のMSPに同じ依頼を出し、技術と費用を比べ、狭い移行か監視の一部から始め、定期の打ち合わせのあとで範囲を広げることです。依頼にはサーバーの数と形、おおよその利用者、データの大きさ、希望の時期、必要な障害対応、セキュリティ上の制約を具体的に書き、同じ条件で比べられるようにします。技術の読み手と費用の読み手を同じ席に。

稼働が始まったら、月次の報告を自分でも読んでください。件数、応答時間、費用の流れです。基本的な構成を理解している担当が社内に一人いるだけでも会話は楽になり、あとで乗り換えたり一部を内製したりしやすくなります。一般情報であり、特定の業者の推奨ではありません。署名の前に、目の前の契約をもう一度読んでください。

出典

1. MSP（マネージドサービスプロバイダー）がクラウド運用で担う範囲、SLA、アカウントの所有、契約時の確認事項。業者の順位やシェアは書きません。
2. クラウドアカウントの最上位権限は、利用する組織が持ち続けるのが安全です。MSPには合意した範囲に必要な権限だけを渡します。日本のISMAP、米国のFedRAMP、韓国のCSAPなどは、尋ねてよい制度の名前であり、業者ランキングではありません。
3. SLAは、応答・復旧の目標、報告、責任分担を書いた約束であり、宣伝文句ではありません。記憶した数字ではなく、署名した別紙を確認してください。
4. 元の韓国語記事は、MSPを初めて検討するチーム向けの案内です。流れを保ちつつ、他の国の担当者が契約レビューに持っていける質問を足しています。

確認日: 2026年11月14日