LASSIC Media らしくメディア
マルチベンダーとシングルベンダーの違いと保守窓口のまとめ方
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- マルチベンダーは、分野ごとに複数の会社へシステムの開発や保守を任せる形です。
- シングルベンダーと違い、各社の役割を整理して全体をまとめる責任が発注する会社に残ります。
- 保守の窓口を1つにまとめ、責任分界点を表にしておくと、障害時の切り分けが進めやすくなります。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
システムが止まったのに、どの保守会社に連絡すればよいか分からない。連絡した会社からは「当社の担当ではない」と言われてしまう——。業務システム、ネットワーク、サーバーを別々の会社に任せている会社では、こうした食い違いが起こりがちです。マルチベンダーとは、システムの開発や保守を、分野ごとに複数の会社に分けて任せる形のことです。
得意な会社や製品を分野ごとに選べる一方で、会社と会社のあいだの作業が誰の担当でもなくなることがあります。ただし万能ではなく、1社にまとめれば解決するとも限りません。本記事では、情報システムの担当者に向けて、マルチベンダーの意味、シングルベンダーとの違い、保守の窓口をまとめる進め方、そして外部に頼むときに確認したい点を整理します。
目次
マルチベンダーとは
経済産業省の「情報システム・モデル取引・契約書」は、情報システムが多くの世代の言語や技術の積み重ねでできているため、専門の技術を持つ複数の会社の連携が求められ、多くの開発がマルチベンダー方式になっていると説明しています。*1 同じ資料は、複数の会社が連携する形を次のように分けています。
- サブシステムごとに分ける形：業務アプリ、ネットワーク、基盤などを別々の会社が受け持つ*1
- 工程ごとに分ける形：要件定義と設計・開発を別々の会社に発注する
- サブシステムごとに分ける形には、すでに保守や運用に入っている別のシステムとつなぐ場合も含まれる
- 全体のまとめ役は、発注する会社が自分で（またはコンサルタントの支援を得て）務めるか、1社のプライムベンダー（元請）に任せるかのどちらか*1
開発だけの話ではありません。導入した時期も会社も違うシステムを使い続けていれば、保守の段階で自然とマルチベンダーになります。デジタル庁も、自治体の基幹業務システムで、複数の会社のシステムをつなぐ連携の検証事業を公募しました。*4
シングルベンダーとの違い
シングルベンダーは、システムの開発から保守までを1社にまとめて任せる形です。どちらが優れているというより、何を自社で受け持つかが変わります。モデル契約は、マルチベンダー方式では発注する会社の責任に、参加する会社の体制を組み、役割と責任を整理し、各社の作業を統制することが加わるとしています。*1
| 比べる点 | マルチベンダー | シングルベンダー |
|---|---|---|
| 契約の相手 | 分野ごとに複数の会社 | 1社 |
| 製品や技術の選び方 | 分野ごとに得意な会社や製品を選べる | その1社が扱う範囲から選ぶ |
| 全体をまとめる責任 | 発注する会社（任せるならまとめ役の会社と契約する） | 主にその1社 |
| 障害時の問い合わせ先 | 原因が分かるまで、どの会社に連絡するか迷いやすい | 1か所 |
| 注意したい点 | 会社と会社のあいだの作業が誰の担当でもなくなる | 特定の1社に頼りきりになり、乗り換えが難しくなる |
1社に頼りきりになる問題への備えはベンダーロックインの対策で扱っています。本記事では、マルチベンダーで使い続けるときに起きやすい、保守の窓口の分かれ方に絞って見ていきます。
保守の窓口が分かれると起きること
総務省の検討会では、自治体のシステムをマルチベンダーで進める場合に、自治体側が間に立って調整役を担う必要があるという意見が出ています。あわせて、各社との責任分界点（どこまでが誰の責任かの境目）とSLA（サービスの水準の取り決め）が適切かを確かめる必要も挙がりました。*3 民間の会社でも、保守の窓口が会社ごとに分かれていると、次のようなことが起こります。
- 画面が開かないとき、アプリ・ネットワーク・サーバーのどこが原因か分からず、利用部門が何社にも電話する
- 各社が「当社の範囲では異常なし」と答え、原因の切り分けが止まる
- 受付時間や連絡の手段が会社ごとに違い、夜間や休日の連絡先が分からない
- 障害の記録が各社に散らばり、同じ障害が繰り返されても気づけない
こうした混乱を減らす方法が、保守の窓口を1か所にまとめる体制です。利用部門からの問い合わせを一次受けの窓口がすべて受け付け、原因を切り分けてから担当の会社へ連絡し、対応の記録をまとめて残します。各社との保守契約はそのままでも、連絡の入口と記録の置き場所は1つにできます。
窓口を1つにまとめる進め方
窓口をまとめる作業は、新しい仕組みを入れるより先に、いまの契約と連絡先を表にすることから始めます。次の4つの段階で進めると、抜けている作業に気づきやすくなります。
- ステップ1：保守契約を棚卸しする（各社の担当範囲・受付時間・連絡先・契約の期限を一覧にする）
- ステップ2：責任分界点を表にする（障害の種類ごとに、最初に調べる会社と次に連絡する会社を決める）
- ステップ3：一次受けの窓口と切り分けの手順を決める（受付の方法、緊急度の決め方、各社への連絡の順番）
- ステップ4：記録と報告の場を決める（障害の記録を1か所に集め、定例の打ち合わせで各社と一緒に見直す）
つまずきやすいのはステップ2です。会社と会社の境目にある作業、たとえばシステム間のデータ連携や、ネットワーク機器とサーバーの設定の食い違いは、どの契約にも書かれていないことがあります。こうした作業を表の上で見つけたら、どの会社が受け持つかを決めて、必要なら契約を見直します。SLAの決め方は保守契約のSLA設計でも扱っています。
外部に頼むときに確認しておきたい点
社内にまとめ役を置けない場合は、全体の管理と調整を1社に任せる方法があります。モデル契約は、まとめ役を担う会社にはほかの会社の体制を組み、役割と責任を整理し、作業を統制する責任が生じるため、その業務が委託の範囲に含まれることを契約に書くよう求めています。この業務の契約形態は準委任契約（作業の遂行を約束する契約）とされています。*1
- どこまで任せるか：問い合わせの一次受け、原因の切り分け、各社への連絡、障害の記録と報告のうち、どれを頼むか
- まとめ役の権限：ほかの保守会社に調査や作業を依頼できるか。各社との契約にその旨を入れるか
- 受付の時間と方法：夜間や休日の連絡をどう受けるか。各社の受付時間との差をどう埋めるか
- 記録の持ち主：障害の記録や手順書を自社が受け取れるか。まとめ役を替えるときに引き継げるか
- 見直しの場：定例の報告で、繰り返す障害や境目の作業をどう話し合うか
2020年に公開された第二版では、第一版で「プロジェクトマネジメント」と呼んでいた複数社の調整業務を、混同を防ぐために、調整であることが分かる呼び名に改めています。*2 まとめ役に頼むのは、各社の作業を代わりに引き受けることではなく、この調整です。保守会社そのものの比べ方はシステム保守会社の選び方にまとめています。
まとめ：マルチベンダーで確かめておきたい3つの点
マルチベンダーのシステムを使い続けるうえで、確かめておきたい点は3つに整理できます。第一に、各社との保守契約を一覧にして、担当範囲・受付時間・連絡先を1枚の表で見られるようにすること。第二に、会社と会社の境目にある作業を責任分界点の表で見つけ、受け持つ会社を決めること。第三に、問い合わせの窓口と障害の記録を1か所にまとめ、まとめ役を社内に置くか外部に任せるかを決めることです。この3点を踏まえておけば、「障害のたびに何社にも電話して、結局どこも原因を調べてくれない」という事態を避けやすくなります。窓口のまとめ方や切り分けの手順に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
社内のシステムが少なくてもマルチベンダーにあたりますか
あたります。会計のパッケージは販売会社、社内のネットワークは通信会社、PCは別の保守会社というように、保守の契約先が2社以上に分かれていれば、規模にかかわらずマルチベンダーの状態です。まずは契約先と連絡先を一覧にするところから始めると、窓口をまとめる必要があるかを判断しやすくなります。
窓口をまとめると、いまの保守会社との契約は結び直しになりますか
結び直さずに済む場合もあります。各社との保守契約はそのままにして、連絡の入口と報告の先をまとめ役の窓口にする取り決めを加える形です。ただし、まとめ役がほかの会社に調査を依頼できるかどうかは契約の書き方によるため、各社の契約を確かめてから進めてください。
シングルベンダーに切り替えたほうがよいですか
一概には言えません。1社にまとめると問い合わせ先は1つになりますが、移行の手間がかかり、その会社に頼りきりになる心配も出てきます。いまの各社の対応に大きな不満がなければ、契約先は変えずに窓口だけをまとめる方法から検討すると、切り替えより小さな手間で始められます。
複数の保守会社の窓口の一本化のご相談
複数の保守会社にまたがる問い合わせ窓口の一本化から、責任分界点の整理、障害時の切り分けの手順づくりまで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：経済産業省「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）〈第一版〉」（2007年4月）（https://www.meti.go.jp/policy/it_policy/keiyaku/model_keiyakusyo.pdf）。出典：複数の会社が連携する方式の必要性と類型、発注者の責任範囲、全体管理・調整業務を委託する場合の契約（準委任）、第13条の解説の記述を参照（2026年10月確認）
- *2 参考：独立行政法人情報処理推進機構（IPA）・経済産業省「情報システム・モデル取引・契約書 第二版の公表にあたって」（2020年12月22日）（https://www.ipa.go.jp/files/000087450.pdf）。出典：第13条の調整業務の用語を言い換えた見直しの記述を参照（2026年10月確認）
- *3 参考：総務省「地方公共団体における情報セキュリティポリシーに関するガイドラインの改定等に係る検討会（第13回）議事概要」（https://www.soumu.go.jp/main_content/000967535.pdf）。出典：複数の会社で進める場合の自治体側の調整役、責任分界点とSLAの確認についての意見を参照（2026年10月確認）
- *4 参考：デジタル庁「ガバメントクラウドの共同利用方式の推進と複数の事業者間のシステム間連携の検証事業」公募結果（https://www.digital.go.jp/news/932080d0-ea5f-40d4-a5db-1718f3c49850）。出典：複数の事業者の利用環境を想定したシステム間のデータ連携の検証についての記述を参照（2026年10月確認）
