情シス代行の乗り換え手順と失敗しないベンダー変更の引き継ぎ術

情シス代行の乗り換え（ベンダー変更）で業務停止や引き継ぎ拒否トラブルを防ぐには、「旧ベンダーへ解約通知を出してから次を探す」のではなく、契約満了の3〜6ヶ月前から自社のIT資産・特権IDの所在を棚卸しし、新ベンダーの選定と1〜2ヶ月の並行運用（シャドウイング）計画を固めたうえで正式通知する手順が不可欠です。特にMicrosoft 365やGoogle Workspaceの全体管理者権限（Global Admin）とドメイン（DNS）管理権を自社名義で確保しておけば、万が一既存ベンダーが非協力的でも安全に移行できます。

既存の情シス代行やIT保守ベンダーに対して「対応が遅い」「担当者が変わるたびに品質が落ちる」「毎月数十万円払っているのに何をしているか見えない」と不満を抱えながらも、引き継ぎトラブルを恐れて契約更新を繰り返してしまう中小企業は少なくありません。

本記事では、公的ガイドライン（IPA・経済産業省・JEITA）と情シス現場の実務データに基づき、トラブルゼロで新ベンダーへ移行する5ステップから、回収必須の特権ID・ドキュメント一覧、引き継ぎ拒否への法的・実務的対処法、新ベンダー選定のSLA評価基準までを体系的に解説します。

合わせて読みたい
ひとり情シスの業務負担軽減や、情シス代行・アウトソーシングの費用相場とサービス比較を先に確認したい方は、以下の記事もあわせてご覧ください。
→ 「ひとり情シス」の限界と情シス代行・アウトソーシングおすすめ比較｜費用相場と失敗しない選び方（※順次公開予定）

あわせて読みたい

【2026年最新】「ひとり情シス」の限界と情シス代行・アウトソーシングおすすめ比較｜費用相場と失敗し... 社内SEが1人しかいない「ひとり情シス」体制は、単なる担当者の業務過多にとどまらず、「担当者の突然の退職・休職で全社業務が完全停止する」「ランサムウェア被害時に...

情シス代行の乗り換えが増えている背景と主な不満原因

情シス代行やIT運用保守の乗り換えを検討する企業が増えている背景には、従来の「機器販売を起点としたオンプレミス保守モデル」と、現代の「クラウド・SaaS中心の業務環境」との間に大きなギャップが生じている実態があります。

ここでは、現場の情シス担当者や経営者がベンダー変更を決断する3つの主要な不満原因と、それを放置した場合のリスクを整理します。

対応遅延や担当者のスキル不足による業務停滞

情シス代行の乗り換え理由として最も多く挙げられるのが、障害発生時や日常のヘルプデスク問い合わせに対する「レスポンスの遅さ」と「技術力のミスマッチ」です。

全社ネットワークの停止やメール送受信トラブルが発生しているにもかかわらず、窓口に電話しても「担当者から折り返します」と言われたまま半日〜数日間放置されれば、社内の業務は完全にストップしてしまいます。また、オンプレミスの複合機や古い社内サーバーの保守から始まったベンダーの場合、Microsoft 365やGoogle WorkspaceのID管理、EDR・ゼロトラストといった最新のクラウドセキュリティ設定に対応できないケースが目立ちます。

電子情報技術産業協会（JEITA）のSLAガイドラインでも、サービス提供時間と障害対応・問い合わせ対応の応答性能を明確に分けて定義する重要性が示されています（出典: JEITA「SaaS向けSLAガイドライン」）。直近3〜6ヶ月分の問い合わせ履歴から「何にどれくらい待たされたか」を数値化しておくと、新ベンダーへの提案依頼書（RFP）にそのまま活用できます。

運用マニュアル不在とブラックボックス化への危機感

2つ目の深刻な原因は、設定変更の履歴や障害対応手順書が一切残されておらず、既存の代行会社（あるいは特定の担当者1人）の頭の中にしか情報がない「ブラックボックス化」です。

自社のITインフラでありながら、社内の誰もルーターやファイアウォールの管理者パスワードを知らず、どのSaaSに何ライセンス契約しているかの台帳すら手元にない状態は、典型的な「ベンダーロックイン」と言えます。

実際にX（旧Twitter）上の情シス実務者の声を調査しても、引き継ぎ書や管理権限が整理されないまま担当者が離れた結果、深刻なトラブルに陥る事例が数多く報告されています。

この投稿が指摘するとおり、社内にITの判断軸や管理台帳を残さないまま外部業者へ丸投げすると、いざ体制を変えようとした際に「誰も仕様が分からないため別業者へ引き継げない」「言われるがまま追加費用を払ってコストが3倍に膨らむ」という事態を招きかねません。また、別のX上の事例（@baw_peca）では、取引先との受発注データ連携を担っていた社内担当者を「パソコンの面倒くらい外の業者で十分」と外注に切り替えた結果、取引先との暗黙知や信頼関係まで失われ、自動発注の仕入先から外されてしまったケースも共有されています。

契約内容と実態の乖離によるコストパフォーマンスの悪化

3つ目の原因は、毎月十数万〜数十万円の固定保守費を支払っているにもかかわらず、実態が「聞かれたことだけに答える受け身の保守」にとどまり、費用対効果が悪化しているケースです。

さらに注意したいのが、「契約範囲の曖昧さ」による追加費用の発生です。基本契約の業務範囲（スコープ）が曖昧なまま運用を続けると、PCの初期設定（キッティング）やアカウント追加、軽微な設定変更のたびに「それは基本保守の対象外です」として高額なスポット見積もりを請求される傾向があります。

主な不満の類型	現場で起きている具体症状	放置した場合の経営リスク	新契約で盛り込むべき再発防止策
対応遅延・スキル不足	障害連絡から半日〜数日放置、クラウド・SaaS設定に非対応	業務停止の長期化、シャドーITの蔓延	重大度別の初動応答SLA（15〜30分等）と複数担当制
ブラックボックス化	構成図や手順書がなく、管理者IDをベンダー側だけが保有	乗り換え不能（ロックイン）、重大インシデント時の復旧不能	自社名義での特権ID保有、月次での台帳・構成図更新義務
費用対効果の悪化	受け身の窓口対応のみ、「対象外」として都度追加費用が発生	保守コストの高止まり（丸投げによるコスト2〜3倍化）	標準スコープ（定型作業）とオプション単価の明文化
担当者交代による品質低下	優秀なSEが外れ、引き継ぎ不十分な新人がアサインされる	毎回ゼロから社内環境を説明する社内調整工数の増大	主担当・副担当のチーム制とベンダー内引き継ぎ責任の明記

現在のベンダーに対する課題を整理できたら、次は業務を一切止めずに新ベンダーへ移行するための具体的な5ステップとスケジュール設計を確認していきましょう。

トラブルゼロで移行する情シスベンダー切り替えの5ステップ

情シス代行の切り替えで失敗する企業の多くは、準備不足のまま既存ベンダーへ解約を伝えてしまい、引き継ぎ期間が足りなくなったり、回線やライセンスまで誤って解約されたりするトラブルに直面しています。

ここでは、契約満了の3〜6ヶ月前から本稼働切り替えまでを安全に進める5つの実務ステップを解説します。

ステップ1：現行契約書の解約予告期間（3ヶ月前ルール）の確認

最初のステップは、現在締結している業務委託契約書・保守規約を取り出し、「契約満了日」「自動更新条項」「解約予告期限（更新拒絶の通知期限）」を正確に確認することです。

法人向けのIT保守や情シス代行契約では、「期間満了の3ヶ月前（または90日前）までに書面で通知がない限り、同一条件で1年間自動更新する」という条項が多く見られます。ただし、「解約は一律3ヶ月前」という法律上の共通ルールがあるわけではなく、たとえばラディックスの保守契約規約のように「1ヶ月前までの文書通知」と定めている事業者もあります（出典: ラディックス「保守契約規約」）。

独立行政法人情報処理推進機構（IPA）が公開している「情報システム・モデル取引・契約書（保守・運用）」でも、契約終了時の通知手続きや移行協力の範囲を契約ごとに確認する重要性が示されています（出典: IPA「情報システム・モデル取引・契約書」）。

ステップ2：社内IT資産とアカウント権限の棚卸し

既存ベンダーへ解約を通知する前に、自社側で把握できる範囲のIT資産・クラウド契約・アカウント権限をリストアップ（棚卸し）します。

解約の意向を伝えた後に「うちが何を使っているか全部教えてください」と依頼すると、既存ベンダーの協力姿勢によっては情報回収に時間がかかるため、平時の通常業務として最新の管理台帳や構成図の提出を求めておくのが賢明です。

ステップ3：新ベンダーの選定と見積もり比較（RFP作成）

ステップ1・2で整理した「現状の不満課題」と「社内IT資産リスト」をもとに、新ベンダー候補（2〜3社）へ提案依頼書（RFP）を提示して見積もりと移行計画を比較します。

情シス代行の乗り換えでは、単なる「月額保守料金の安さ」だけで選ぶと失敗しやすくなります。初年度のトータルコストには、新ベンダーの初期セットアップ・環境調査費用、1〜2ヶ月間の新旧ベンダー並行運用費用、ライセンス移管手数料、そして社内担当者の調整工数が含まれるためです。

移行スケジュール時期	主な実施タスク	関与する当事者	次のフェーズへ進む完了判定条件
終了6〜4ヶ月前	現行契約書の解約条項確認、不満課題の数値化、IT資産・特権IDの事前棚卸し	自社（移行責任者・法務）	解約予告期限と更新条件、自社保有権限の範囲が明確になっている
終了4〜3ヶ月前	RFP（提案依頼書）作成、新ベンダー2〜3社の比較・選定、移行計画と費用の合意	自社＋新ベンダー候補	新ベンダーのSLA・移行スケジュール・初期費用が確定している
解約予告期限前（3ヶ月前等）	旧ベンダーへの正式な更新拒絶（解約）通知、終了対象と継続契約の書面合意	自社➔旧ベンダー	旧ベンダーから解約通知の受領確認と契約終了日の合意を得ている
終了3〜2ヶ月前	三者キックオフ会議、構成図・管理台帳・特権IDの回収、未解決課題の洗い出し	自社＋旧ベンダー＋新ベンダー	引き継ぎ資料の不足項目と各担当者の提出期限が確定している
終了2〜1ヶ月前	並行運用（シャドウイング・リバースシャドウイング）、バックアップ復元・代表作業の検証	新ベンダー主導＋旧ベンダー並走	新ベンダーが単独で日常運用・障害切り分けを実行できると確認できた
切り替え当日〜直後	窓口・監視通知先の切り替え、旧ベンダーの特権ID・VPN・遠隔ツールの完全削除、データ消去確認	自社＋新ベンダー（旧ベンダー撤去）	旧認証情報でのアクセス遮断と業務の正常稼働が確認できた

新ベンダー各社の移行支援体制や最短初動スピード（たとえば「情シス365」のように60〜90日の標準移行プロセスを提示しているサービスや、最短3営業日・月額18万円から引き継ぎに対応する運用代行サービスなど）を比較し、自社の解約期限までに無理なく並走できるパートナーを選定しましょう（出典: 情シス365「情シスアウトソーシングの引き継ぎ期間目安」）。

ステップ4：新旧ベンダーの並行運用（シャドウイング）と引き継ぎ

新ベンダーが決定し、旧ベンダーへ正式な解約通知を出したら、契約終了前の1〜2ヶ月間を使って新旧ベンダーの「並行運用（並走期間）」を実施します。

ここで最も重要なのは、旧ベンダーと新ベンダーに「直接やり取りして引き継いでおいてください」と丸投げしないことです。発注企業側に必ず「移行責任者」を置き、三者会議でスケジュールと成果物を管理します。また、並行運用中に新旧両社が勝手にシステム設定を変更すると障害の原因になるため、変更作業の主担当は以下の3段階で計画的に移管します。

• 第1段階：シャドウイング（観察・記録）：旧ベンダーが主担当として通常運用を行い、新ベンダーのSEが同席して作業手順・社内ルール・承認フローを観察し手順書に記録する
• 第2段階：リバースシャドウイング（実作業移管）：新ベンダーが主担当として入退社アカウント発行やPCキッティング、障害切り分けを実行し、旧ベンダーが横で確認・助言を行う
• 第3段階：切り替え判定テスト：バックアップからのデータ復元試験、緊急連絡網のテスト、メーカー・回線窓口への問い合わせ権限確認を実施し、本番切り替えの可否を判定する

「資料を受け取った日」ではなく、「新ベンダーが自力で代表作業を遂行でき、自社が管理画面を掌握した状態」を引き継ぎ完了の定義に据えることが不可欠です。

ステップ5：旧ベンダーのアカウント完全削除と本稼働切り替え

並行運用での検証をクリアし、本稼働切り替え日を迎えたら、旧ベンダーが保有していたすべてのアクセス権限とリモート接続経路を即座に遮断・削除します。

万が一、契約終了後も旧ベンダーの共有IDやリモート管理エージェント（RMMツール）が社内PCやサーバーに残存していると、そこから不正アクセスや設定ミスによる情報漏洩が発生した際に責任の所在が曖昧になってしまいます。

遮断・変更対象カテゴリ	切り替え当日に実施する具体的な処置内容	確認・証跡管理のポイント
① クラウド全体管理者・委任権限	旧ベンダー用Global Admin削除、M365等のパートナー委任権限（GDAP/DAP）解除	管理センターの監査ログで旧IDからのアクセス遮断を確認
② 社内サーバー・VPN・NW機器	ADドメイン管理者PW変更、SSL-VPN証明書失効、ルーター/UTM管理PW更新	旧認証情報・旧拠点IPからのVPN接続が拒否されるかテスト
③ 遠隔管理ツール・APIキー	旧ベンダー導入のRMM常駐エージェント削除、サービスアカウント・APIキー更新	端末管理画面から旧エージェントのアンインストール完了を確認
④ 監視通知先・預託データ消去	死活監視・アラート通知先を新ベンダーへ変更、旧ベンダー保管データの消去証明受領	個人情報保護委員会の基準に則りデータ消去完了報告書を保管

個人情報保護委員会のガイドライン（Q&A）でも、委託契約終了時には委託先から個人データを返還または完全に消去させ、消去が確実に行われたことを書面等で確認する義務が明記されています（出典: 個人情報保護委員会「委託終了時の個人データの取扱いQ&A」）。

合わせて読みたい
不要なVPNアカウントや古いリモート接続経路を放置したままにすることは、ランサムウェア感染の最大の原因となります。中小企業における実際の被害コストと防衛策は以下の記事で詳しく解説しています。
→ 中小企業のランサムウェア被害実態と復旧費用の内訳｜身代金以外の隠れコストと対策（※順次公開予定）

あわせて読みたい

中小企業のランサムウェア被害実態！復旧費用の内訳と倒産を防ぐ対策 国内のランサムウェア被害報告の約64%は中小企業が占めており、感染時の調査・復旧費用は被害組織の60%で1,000万円以上に達しています。身代金を支払ってもデータの完全...

移行の全体ステップを押さえたところで、次は引き継ぎ現場で最も揉めやすい「回収必須の重要情報リスト」と、既存ベンダーが非協力的な場合の対処法、そして新ベンダーのSLA評価基準を掘り下げます。

引き継ぎで回収すべき重要情報リストと新ベンダーのSLA評価基準

ブラックボックス化したIT環境を透明化し、二度とベンダーロックインに陥らないためには、回収すべき情報を明確なリストとして定義し、新ベンダーとの契約時にSLA（サービス品質保証）を数値で合意しておく必要がありるのが実情です。

クラウドサービス・サーバーの特権IDと管理者パスワード

引き継ぎにおいて最優先で回収・確認しなければならないのが、クラウドテナントや社内サーバーの「最高管理権限（特権ID）」と「多要素認証（MFA）・回復手段」です。

特にMicrosoft 365やGoogle Workspaceでは、既存の保守ベンダーが「全体管理者（Global Admin / 特権管理者）」を独占しており、発注企業の社員には一般ユーザー権限や下位の管理権限しか付与されていないケースが少なくありません。

Microsoftの公式ドキュメント（Partner Center）でも、顧客テナントのロックアウト（締め出し）を防ぐため、異なる認証情報とMFA手段を持つ少なくとも2つの全体管理者アカウント（緊急アクセス用アカウントを含む）を顧客企業側で確保することが強く推奨されています（出典: Microsoft Learn「Preventing tenant lockouts」）。

ネットワーク構成図・社内PCキッティング手順書・ライセンス一覧

特権IDと並んで回収必須となるのが、社内ネットワークの物理・論理構成図、PCキッティング手順書、および各種ライセンス・保守契約台帳です。

単に機器の型番が並んだリストではなく、障害発生時に新ベンダーが即座に切り分けを行える粒度のドキュメントを揃える必要があります。

回収対象カテゴリ	引き継ぐべき具体的な資料・データ項目	引き継ぎ時の実地検証ポイント
① クラウド・ID権限	M365/GWSテナントID、全体管理者ID、AD特権ID、MFA登録端末、APIキー・サービスアカウント一覧	自社管理者がログインでき、旧ベンダーの不要な委任権限が把握できているか
② ネットワーク構成	物理配線図（設置場所・ポート）、論理構成図（固定IP表・VLAN・VPN経路・FWポリシールール・Wi-Fi暗号化キー）	構成図の記載内容と、現在のルーター・UTMの実設定値が一致しているか
③ ドメイン・証明書	ドメイン登録事業者（レジストラ）名義、DNSゾーン設定（A/MX/TXTレコード）、SSL証明書と更新期限	ドメイン所有名義が自社になっており、DNSレコード変更権限があるか
④ PC・ライセンス台帳	PCキッティング手順書、必須ソフト一覧、ライセンス証書・契約番号・数量・更新日、メーカー保守窓口連絡先	新ベンダーが手順書どおりにPC初期設定とメーカー問い合わせを行えるか
⑤ バックアップ・障害履歴	バックアップ対象・保存先・世代管理・復号鍵、直近1年の障害チケット履歴、未解決の既知課題リスト	実際にバックアップからテスト復元が可能で、未処理案件の引き継ぎが完了しているか

もし既存ベンダーの運用中に構成図や手順書が更新されていなかった場合は、無理に推測で埋めさせず、「現時点で判明している設定値」と「未確認・要現地調査の項目」を明確に区分して新ベンダーへ引き渡します。

既存ベンダーが引き継ぎに非協力的な場合の法的・実務的対処法

万が一、解約を伝えた途端に既存ベンダーが非協力的になり、「管理者パスワードは社外秘なので渡せない」「引き継ぎ資料を作るなら追加で数百万円かかる」と拒否された場合は、感情的に対立せず「法的根拠に基づく返還請求」と「技術的な権限奪還」の2軸で冷静に対処しますね。

まず法的な観点として、一般的な情シス代行や運用保守契約は「準委任契約（民法第656条）」に該当します。準委任契約では、受任者（ベンダー）に対して民法第645条（受任者による報告義務）および民法第646条（受任者による受取物等の引渡し・権利移転義務）が準用されます（出典: e-Gov法令検索「民法」）。したがって、自社の費用で取得したアカウント権限、自社環境の現行設定データ、既に契約内で作成済みの管理台帳などを引き渡すことは委託者の正当な権利です。

レスポンス時間と一次解決率を保証するSLAの重要性

無事に既存ベンダーからの引き継ぎ準備が整ったら、新しく契約する情シス代行会社との間でSLA（Service Level Agreement：サービス品質合意書）を具体的な数値で締結します。

経済産業省の「SaaS向けSLAガイドライン」でも、サービス提供時間・障害通知時間・平均復旧時間などの評価指標を契約前に合意しておく重要性が解説されています（出典: 経済産業省「SaaS向けSLAガイドライン」）。情シス代行（人による運用サービス）を選定する際は、特に以下の3つのKPIと「次回の出口条項」を確認しましょう。

SLA・契約評価項目	確認すべき具体的な定義内容	実務上の目標目安（設計例）	チェック時の注意点
① 初動レスポンス時間	問い合わせ受付から、自動返信ではなく「担当エンジニアが状況確認の連絡を返すまで」の時間	重大障害（P1）：15〜30分以内 通常依頼（P3/P4）：1〜4営業時間以内	電話・チャット・メールのどの窓口でも計測対象になるかを確認する
② ヘルプデスク一次解決率	社員からの問い合わせに対し、たらい回しにせず一次窓口（電話・チャット）で解決できる割合	70%以上	一次解決の範囲（パスワードリセット、SaaS設定、PC不具合切り分け等）を明記する
③ オンサイト駆けつけ基準	リモートで解決しないハードウェア故障やネットワーク断の際に現地へ到着する時間と代替機手配	重大障害時：当日（2〜4時間以内）または翌営業日駆けつけ	対象エリア、出張交通費が月額内か別料金か、予備機保管の有無を確認する
④ 文書更新・出口条項（終了支援）	構成図・台帳の定期更新頻度と、将来契約終了する際の引き継ぎ協力義務・データ返還ルール	台帳更新：月次更新・自社格納 終了時協力：無償範囲と単価を事前合意	次の乗り換え時にロックインされないよう、最初から契約書に終了支援条項を入れる

まとめ：情シス代行の乗り換えとベンダー変更は手順と引き継ぎで決まる

情シス代行の乗り換え（ベンダー変更）は、単なる委託業者のすげ替えではなく、ブラックボックス化した社内IT環境を可視化し、セキュリティと業務生産性を抜本的に強化する絶好の機会です。

最後に、本記事で解説した失敗しない移行手順と引き継ぎの鉄則を振り返ります。

• 解約通知より先に「契約確認」と「資産棚卸し」を行う：契約満了の3〜6ヶ月前に自動更新条項・解約予告期限を確認し、回線やライセンス契約を巻き込まないよう切り分ける
• 特権IDとドメイン管理権を必ず自社保有に戻す：Microsoft 365やGoogle Workspaceの全体管理者（Global Admin）、AD特権、DNS管理権限を自社名義で確保し、ロックアウトを防ぐ
• 1〜2ヶ月の並行運用（シャドウイング）で実地検証する：「資料の受領」ではなく「新ベンダーが自力で運用・復旧できる状態」を完了条件に設定し、切り替え当日は旧権限を完全削除する
• 新ベンダーとはSLAと出口条項を明文化する：初動レスポンス（15〜30分以内目安）や一次解決率（70%以上目安）に加え、将来の契約終了時の引き継ぎ協力義務を最初から契約書に盛り込む

もし現在、「既存ベンダーの対応が遅い」「設定がブラックボックス化していて不安」と感じているなら、まずは次回の契約更新日と解約予告期限を契約書で確認し、複数社の情シス代行サービスから移行プランの提案を受けることから始めてみてください。

よくある質問

情シス代行ベンダーを乗り換える際、既存ベンダーから引き継ぎを拒否されたらどうすればいいですか？

まずは契約書および民法上の準委任規定（第645条の報告義務・第646条の受取物引渡義務）に基づき、「自社環境の現行設定値・管理者IDの返還」を項目別・期限付きで書面請求してください。元々存在しない手順書の新規作成まで無償要求するのではなく、新ベンダーによる現地調査（リバースエンジニアリング）と組み合わせるのが実務的です。また、自社でドメイン（DNS）の管理権限を保有していれば、TXTレコード認証によってMicrosoft 365やGoogle Workspaceの管理者権限を自社側へリセット・奪還できる場合があります。

情シス代行の切り替えには準備から完了までどれくらいの期間が必要ですか？

現行契約の確認から新ベンダー選定、解約通知、並行運用、本稼働切り替えまで含めると、全体で3〜6ヶ月程度を見込むのが一般的です。多くのIT保守契約では契約満了の3ヶ月前（90日前）が解約予告期限となっているため、満了の4〜6ヶ月前から資産棚卸しと新ベンダー比較を始め、解約通知後の1〜2ヶ月間で並行運用（シャドウイング）を行うスケジュールが安全です。

新しい情シス代行会社を選ぶ際、SLAで確認すべきポイントは何ですか？

「迅速に対応します」といった抽象的な言葉ではなく、①重大障害時の初動レスポンス時間（15〜30分以内など、自動返信ではなく担当者応答までの時間）、②ヘルプデスクの一次解決率（70%以上など）、③リモートで復旧できない場合のオンサイト駆けつけ基準、④構成図や管理台帳の月次更新義務と自社環境への保存、の4点を数値と具体的な条件で確認することが重要です。